ajaxorg / ace Goto Github PK

This problem only occurs when the initial document opened is the empty string. The first line of text typed in is invisible, it only appears when the return key is pressed to go to the second line. The line number in the gutter does not show initially either. This happens from commit 8d87f4a, possibly earlier.

The scrolling of the text feels way too fast in chrome. The code shows in the mouse wheel handler not browser normalization. Just take a look at the qooxdoo mouse wheel event of qooxdoo to see how we recently changed it:
http://qooxdoo.svn.sourceforge.net/viewvc/qooxdoo/trunk/qooxdoo/framework/source/class/qx/event/type/MouseWheel.js?revision=22904&view=markup

(by wittemann)
@Gissues:{"order":98.13664596273293,"status":"backlog"}

I know Julian was working on this, but I thought it would be nice to have a ticket for this to be able to track the state.

In order to implement proper vim mode, one will need to be able to change cursor's behavior depending on a mode (normal / insert / visual). In all the modes except insert in vim you have a block cursor that is placed behind the letter instead of being on the right side to it.

Editor does not loads in safari since latest version does not yet implements .classList property

cliView.js:272TypeError: Result of expression 'this.completer.classList' [undefined] is not an object. 

Probably IE does not has it either, so probably it's broken there as well

When Ace is ordered to setValue(getValue) new line is added.
Test: http://jsfiddle.net/zalun/WpJms/

Example:
http://shiftedit.net/tests/ace-annotations

This can be fixed by using hasOwnProperty:

this.setAnnotations = function(annotations) {
    // iterate over sparse array
    this.$annotations = [];
    for (var row in annotations) {
        if (annotations.hasOwnProperty(row) ){
            var rowInfo = this.$annotations[row] = {
                text: []
            };
            var rowAnnotations = annotations[row];
            for (var i=0; i<rowAnnotations.length; i++) {
                var annotation = rowAnnotations[i];

                rowInfo.text.push(annotation.text.replace(/"/g, "&quot;").replace(/'/g, "&rsquo;").replace(/</, "&lt;"));
                var type = annotation.type;
                if (type == "error")
                    rowInfo.className = "ace_error";
                else if (type == "warning" && rowInfo.className != "ace_error")
                    rowInfo.className = "ace_warning";
                else if (type == "info" && (!rowInfo.className))
                    rowInfo.className = "ace_info";
            }
        }
    }
};

PS -- I will figure out how to submit patches properly :)

I'd like Ace to fit inside a container div.

See:
http://shiftedit.net/tests/ace-resize

The key stroke for moving one word to the left for example on windows is Ctrl-Left. In the editor, the cursor jumps to the start of the line. Same is true for select left, right and select right.

I've been trying to figure out how to use ACE. My first instinct was to read the README, alas — no usage was there. So I opened up the docs folder and got a generated XML document back. Then I tried to check out ace.ajax.org and there seemed to be no help there at all. So I tried searching for textarea in the source of the demo page, but couldn't find anything.

How do you use ACE? What are the config options? What javascript files do I include?

I'm kind of feeling retarded asking these questions and really hope that I'm an idiot and missed something terribly obvious.

Example: http://jsfiddle.net/zalun/WpJms/6/

I think that this issue might be a problem with ace since one of the few changes was updating ace to dab3347d8

With wordwrap turned on an error is thrown on startup:

The fix is simple (ace\lib\ace\edit_session.js):
this.getRowHeight = function(config, row) {
var rows;
- if (!this.$useWrapMode) {
+ if (!this.$useWrapMode || !this.$wrapData[row]) {
rows = 1;
} else {
rows = this.$wrapData[row].length + 1;
}

     return rows * config.lineHeight;
}

I have created a simple method to attomatically wrap text to the size of the visible area on resize. It is very handy for embedded editors like Acebug. Maybe you may want to include in the editor? I guess I could have used xpath but I am lazy and the document is always almost empty ;o)

editor.session.setUseWrapMode(true);

editorWin.addEventListener("resize", function() {
    var editor = env.editor;
    var session = editor.session;

    if(session.getUseWrapMode()) {
        var characterWidth = editor.renderer.layerConfig.characterWidth;
        var contentWidth = editor.container.ownerDocument.getElementsByClassName("ace_scroller")[0].clientWidth;

        session.setWrapLimit(parseInt(contentWidth / characterWidth, 10));
    }
}, true);

Ace could be a ideal editor on IOS devices (iPad, iPhone) if you just could type, but unfortunately virtual keyboard never shows up with ACE, also I believe someone had a patch for bespin to make that work.
@Gissues:{"order":96.27329192546586,"status":"backlog"}

The width of the editor div does not seem to affect the width of the wrapped lines.

See:
http://shiftedit.net/tests/ace-wrap2

I'd expect the horizontal scrollbar to be inactive.
Changing the width of the editor div would adjust the wrapping and keep the horiz scrollbar inactive.

syntax highlighting for html/ css and js in php mode.
@Gissues:{"order":94.40993788819878,"status":"backlog"}

If i try to write/delete something at the end of this line, the editor get´s "confused"

{{{ var const2 = /\b(?:A(?:B(?:DAY(?:1|2|3|4|5|6|7)|MON(?:1(?:0|1|2|)|2|3|4|5|6|7|8|9))|LT_DIGITS|M_STR|SSERT(?:ACTIVE|BAIL|CALLBACK|QUIET_EVAL|WARNING))|C(?:ASE(?:LOWER|UPPER)|HAR_MAX|O(?:DESET|NNECTION(?:ABORTED|NORMAL|TIMEOUT)|UNT(?:NORMAL|RECURSIVE))|R(?:EDITS(?:ALL|DOCS|FULLPAGE|G(?:ENERAL|ROUP)|MODULES|QA|SAPI)|NCYSTR|YPT(?:BLOWFISH|EXT_DES|MD5|S(?:ALT_LENGTH|TD_DES)))|URRENCY_SYMBOL)|D(?:AY(?:1|2|3|4|5|6|7)|ECIMAL_POINT|IRECTORY_SEPARATOR|(?:FMT|T_FMT))|E(?:NT(?:COMPAT|NOQUOTES|QUOTES)|RA(?:(?:D(?:FMT|T_FMT)|T_FMT|YEAR)|)|XTR(?:IF_EXISTS|OVERWRITE|PREFIX(?:ALL|I(?:F_EXISTS|NVALID)|SAME)|SKIP))|FRAC_DIGITS|GROUPING|HTML(?:ENTITIES|SPECIALCHARS)|IN(?:FO(?:ALL|C(?:ONFIGURATION|REDITS)|ENVIRONMENT|GENERAL|LICENSE|MODULES|VARIABLES)|I(?:ALL|PERDIR|SYSTEM|USER)|T(?:CURR_SYMBOL|FRAC_DIGITS))|L(?:C(?:ALL|C(?:OLLATE|TYPE)|M(?:ESSAGES|ONETARY)|NUMERIC|TIME)|O(?:CK(?:EX|NB|SH|UN)|G(?:A(?:LERT|UTH(?:PRIV|))|C(?:ONS|R(?:IT|ON))|D(?:AEMON|EBUG)|E(?:MERG|RR)|INFO|KERN|L(?:OCAL(?:0|1|2|3|4|5|6|7)|PR)|MAIL|N(?:DELAY|EWS|O(?:TICE|WAIT))|ODELAY|P(?:ERROR|ID)|SYSLOG|U(?:SER|UCP)|WARNING)))|M(?:ON(?:1(?:0|1|2|)|2|3|4|5|6|7|8|9|DECIMAL_POINT|GROUPING|THOUSANDS_SEP)|(?:1_PI|2(?:PI|SQRTPI)|E|L(?:N(?:10|2)|OG(?:10E|2E))|PI(?:(?:2|4)|)|SQRT(?:1_2|2)))|N(?:EGATIVE_SIGN|O(?:EXPR|STR)|(?:CS_PRECEDES|S(?:EP_BY_SPACE|IGN_POSN)))|P(?:ATH(?:INFO(?:BASENAME|DIRNAME|EXTENSION)|SEPARATOR)|M_STR|OSITIVE_SIGN|(?:CS_PRECEDES|S(?:EP_BY_SPACE|IGN_POSN)))|RADIXCHAR|S(?:EEK(?:CUR|END|SET)|ORT(?:ASC|DESC|NUMERIC|REGULAR|STRING)|TR_PAD(?:BOTH|LEFT|RIGHT))|T(?:HOUS(?:ANDS_SEP|EP)|FMT(?:_AMPM|))|YES(?:EXPR|STR))\b/
}}}

I used the editor in our qooxdoo playground and saw that scrolling is in some cases, if the code lines are not long, scrolling is still possible. I found out that it is due to the print margin which triggers the overflow. Disabling the margin with setShowPrintMargin did not solve the problem. Setting the print margin column to a very low number and hide is a workaround which worked for me well.

(by wittemann)
@Gissues:{"order":0.6211180124226415,"status":"backlog"}

On FF on OSX three finger gesture up / down are shortcut for Home / End. Unfortunately gestures are ignored by ace, would've be nice if it was behaving as expected.
@Gissues:{"order":93.78881987577643,"status":"backlog"}

See:
http://shiftedit.net/tests/ace-wrap

Check out the demo of the editor in Opera and hold the tab key while editing. All other browsers add tabs consecutively. Opera changes its focus to the input fiels in the demo for example.
http://ajaxorg.github.com/ace/demo/editor-build.html

One of the most useful features of vim are split views. I would really love to have build-in support for them in ace.
@Gissues:{"order":97.51552795031057,"status":"backlog"}

If you double-click a word to select it, highlight all occurrences of that word with some theme-appropriate color. This makes it easy to spot uses of a variable or function.

ability to drag and drop selected code with the mouse

I checked out the current editor and it seems to fail the loading in IE8 on vista. The errors is in the included require.js file which seems to rely on getAttribute (line 925).

(by wittemann)

now when cursor is at the end of document and out of view
pressing down doesn't scroll cursor into view

Given this case:

var editor = ace.edit("editor");
var session = editor.getSession();
var document = session.getDocument();

session.setUseWrapMode(true);

document.insertLines(0, ["a", "b"]);
document.insertLines(2, ["c", "d"]);
document.removeLines(1, 2);

It works as expected when wrap mode is off, but crashes otherwise:

Uncaught TypeError: Cannot call method 'trimRight' of undefined
$computeWrapSplits src/ace-uncompressed.js:7203
$updateWrapData src/ace-uncompressed.js:7191
$updateWrapDataOnChange src/ace-uncompressed.js:7177
onChange src/ace-uncompressed.js:6569
bound src/ace-uncompressed.js:180
EventEmitter._emit.EventEmitter._dispatchEvent src/ace-uncompressed.js:2330
insertLines src/ace-uncompressed.js:8748

Removing these lines from EditSession.$updateWrapMode seems to fix the bug:

if (action.indexOf("Lines") != -1) {
    if (action == "insertLines") {
        lastRow = firstRow + e.data.lines.length;
    } else {
        firstRow = lastRow - e.data.lines.length;
    }
}

Moving the cursor with "move word" behaves different than the native implementation. Usually, moving a word left ignores the space infront of it and jumps to the beginning of the word. The editor jumps first to the end of the word and then to the beginning. This is true for mac and windows.

I copied the source of the editor into the editor itself..
almost all lines then became clock commented !

solution: disable automatic stuff while pasting :)

(by Montago)

In file ace\build\src\theme-eclipse.js

b.cssClass="ace-eclipse"})define("text!ace/theme/eclipse.css"

should be:
b.cssClass="ace-eclipse"});define("text!ace/theme/eclipse.css"

or it obviously throws an error.

This file is generated by ace\Makefile.dryice.js and that is definitely not my territory or I would fix it there :o/

On a mac default behavior of Option + delete is to delete rest of the word on the left side of the caret. I think that should be default behavior for the ace as well.

Since splifing off cockpit and pilot the online demo is broken.

If you hold down the "Enter" key while using the editor in Internet Explorer, the editor gets into a bad state where it starts inserting strings of

undefinedundefined

into your text. This does not happen in Firefox/Chrome. This appears to occur for two reasons:

• Differences in key-event delivery. In IE, holding down the Enter key causes multiple newlines to be inserted at once, whereas in Firefox/Chrome, they are always delivered individually. As a result, the text being inserted is "\r\n\r\n" rather than simply "\r\n", and therefore the first case of the $insert function in document.js, "if (this.$isNewLine(text))", is false for IE (because isNewLine only looks for a single newline). So we end up in the third case (multi-line insertion), which should be handled correctly, but...
• Differences in String.split(). In IE, the string "\r\n\r\n".split(/\r\n|\r|\n/) returns a zero-length array, whereas in Firefox, it returns an array of length two (each of which is a zero-length string). The result of this split() is supposed to be the lines to be inserted in the multiline case, which assumes that the array size is greater than 0 (newLines[newLines.length - 1]). From web searches it appears that using regular expressions in the String.split() method is a potential cross-brower bug factory.

Lines of text have their vertical positioning set incorrectly when pressing enter at the end of a document causes the editor window to scroll. See the screenshot here: http://i.imgur.com/4Ld3V.png . The numbers in the document correspond the to line they are on and are out of alignment with the line numbers.

To reproduce, open the latest editor demo and begin to press enter at the bottom of the file. As soon as enough new lines are taken to cause the editor window to scroll, the lines will start to go out of sync. I have tested this in Chrome 8.0.552.237 and Safari 5.0.3. The bug does not seem to appear in Firefox.

I think this may be an issue or subtlety with the rendering engine of WebKit. Using the DOM Inspector shows the div.ace_content element to be shifted to the wrong place (also visible in the screenshot). If I manually remove the 'position: absolute' property from div.ace_scroller and then add it back in then div.ace_content is updated to the correct position. This seems to suggest that Ace is setting up the correct CSS properties, but something is going wrong in the rendering of them. I'm afraid at this point I don't know how to proceed with investigating the problem.

Please let me know if I can provide any more information or if you have any suggestions on how to track down the root cause of this bug. I stumbled across the editor a while ago, but only tried it out today. It's an amazing piece of work, thank you.

+1

Using firefox 3.6 on linux, the following snippet renders wrong:

print """This string
has many
lines"""
#this line should not be green

Toggling the gutter no longer collapses the lines to the left. This is easy to see using:
env.editor.renderer.setShowGutter(!env.editor.renderer.showGutter);

Resizing the window fixes them but strangely calling window.resize() doesn't. After resizing the window toggling the gutter again means that the line is on top of the gutter.

right now, dryice is directly included in Makefile.dryice.js. It should just work with the separate package.

Make line numbers select the corresponding line(s). A click on
a line number would select a unique line while a click+extend would select all
the lines between the initial mousedown and the mouseup.
@Gissues:{"order":95.03105590062114,"status":"backlog"}

Ace currently comes with a find command. It would be nice to also have a find+replace command.

we need some docs on how to embed this awesome component

Chromium browser version 10.0.610.0 gives me following error when I try the demo (demo/editor.html).
require.js:21 Uncaught SyntaxError: Invalid regular expression: /require("'["'])/: Invalid character range

It works after escaping the dash character in regexp, i.e changing line
cjsRequireRegExp = /require("'["'])/g,
to
cjsRequireRegExp = /require("'["'])/g,

in acebug we are loading ace into separate iframe
and editor displays flashing caret even when iframe isn't focused
since there are no other focusable elements in iframe calling editor.blur doesn't help

this behavior can interfere with multiple editor instances as well
so, maybe, removing focus call from constructor and letting startup.js to decide will be better

I think we'll want a release package similar to what we offered for Bespin.

Contents:

• prebuilt, ready-to-run .js file with HTML/JS/CSS highlighting
• docs
• complete source
• dryice (for building custom builds)

The various components that go into the package are in other issues. This is sort of a metabug to actually generate the release tarball from those parts.
@Gissues:{"order":93.16770186335407,"status":"backlog"}

I just updated the editor and sadly the editor does only show the first line of code in IE8. After setting some new code, the editor seems to work as expected.

Currently, the themes are directly part of the ACE package. They should really be separate plugins.
@Gissues:{"order":95.6521739130435,"status":"backlog"}

CMD + L opens jump to line dialog, which is annoying since it's quite frequently used as jump to location bar shortcut in Firefox :(

Can another non conflicting combination be used for that ?
@Gissues:{"order":96.89440993788821,"status":"backlog"}

Like most other editors, you should at least have an option to auto-close special characters. e.g. typing function( should automatically convert it to function() or, typing a single quote should change it to 2 single quotes with your cursor in the middle, etc.