I would like to be able to run my HTA file from the jEdit editor window. I assume this would require adding a new entry to the Run_Script.bsh macro. Can anybody help?

Thanks.

Hey guys, why we don't have GUIEditor Plugin in jEit?If any 1 intrested in developing GUIEditor Plugin for jEdit, please share your ideas.

Is it currently possible to save or load whole sets of abbreviations for a particular mode? If not, this would be a useful feature, as it would allow users to share abbreviation sets and modify them rather than having to build their own from scratch.

Is it currently possible to save or load whole sets of abbreviations for a particular mode? If not, this would be a useful feature, as it would allow users to share abbreviation sets and modify them rather than having to build their own from scratch.

I created an abbreviation for Javascript mode; it works fine in a *.js buffer, but I find that it doesn't work within a Javascript block embedded in an *.html or *.hta buffer. Shouldn't mode-specific abbreviations work correctly within a delegated mode just as syntax highlighting does?

Is there some way for the user to make this work, or is this an ability that jEdit does not have yet?

Workarounds:
1. Copy the javascript abbreviations to the html mode.
2. Create the abbreviations in the global mode instead.

Both these approaches, of course, negate the principle of configuring each mode independently.

Hello,

the last beta release is from March 2005, so I just want to ask if there are plans to create new beta releases of jEdit or what's the future of this great tool. Thanks.


Regards,
Bernhard

It would good to see date and time of last save of the current buffer's file in the status bar.

Please: add a popup menu item to "save as ..." the current buffer.

Is there a way to disable smart indenting? When I'm at end of a line of code that's indented, and I hit Enter, I'd like the edit cursor to simply go to column 0, and not below the beginning of the line of code.

Is there any point to doing "return 1;" instead of "return;" at the end of a macro? Or even "return;" at all? I've seen that in a few of them, but haven't been doing it in mine.

Currently jEdit expands folded text when it is pasted, which forces the user to refold the text. It's especially annoying when the user is moving multiple chunks of folded text around. jEdit should keep the folded text folded.

Currently jEdit will fold code like...

    sub x() {
        yadda yadda
    }
    sub y() {
        yadda yadda
    }

...as...

    sub x() {
    }
    sub y() {
    }

jEdit should fold in any lines that only contain whitespace and one "}", so twice as much important code is displayed per screen, e.g.

    sub x() {
    sub y() {

Perhaps have it as an option, in case anyone prefers seeing those singleton }'s. My current workaround is to indent those visible }'s an extra space, which is a pain.

jEdit shows the matching brace or parenthesis when the edit cursor is to the right of a brace or parenthesis. It should do the same for matching double and single quotes, at least if they are on the same line of text.

The Search > Find dialog box often blocks the found text. It should automatically move up or down, revealing the found text, so the user doesn't have to do it manually. Surely the code that finds and highlights the text knows what screen line it is on, and the current position of the dialog box.

The Search > Find dialog dialog box has a default button, "Find", which does not have an Alt hotkey (unlike the other buttons). Even though the user can hit Enter, it would be more convenient to hit Alt + F, since the user is often already using Alt + R to make replacements when prompted.

When viewing a Help page, when the right hand pane (the one containing the actual Help text) has focus, it would be great to be able to search for a string on the page.

Also, Page Up and Page Down work, but the Up and Down arrow keys do not. They could raise or lower the text one line at a time.

Currently, jEdit does soft wrapping of long paragraphs so that the continuation lines (second, third, etc.) are indented to the same level as the first line of the paragraph. For example, if the paragraph is indented four spaces, then all continuation lines are also indented four spaces (using underscores as spaces in my examples):

    First line of long and wrapped paragraph...
    second line of same paragraph...
    third line...

However, there are many cases in which it would be nice to have all of the continuation lines indented to a different level than the first line. For example, most business correspondence is now formatted so that each paragraph has no indentation, and is separated from other paragraphs with one blank line. But many writers and editors still like the more traditional style, in which the paragraph is indented five spaces, and all continuation lines of that paragraph are not indented at all:

[Example #2:]

    First line of long and wrapped paragraph...
second line of same paragraph...
third line...

Another common example is source code whose lines extend past the right margin of the screen, and thus get wrapped:

    First line of first long and wrapped source code statement...
    second line of same code statement...
    third line...
    First line of second long and wrapped source code statement...
    second line of second code statement...

Far more readable would be (indenting continuation lines with four extra spaces):

    First line of first long and wrapped source code statement...
        second line of same code statement...
        third line...
    First line of second long and wrapped source code statement...
        second line of second code statement...

or my favorite: indenting continuation lines with eight extra spaces -- to distinguish them from lower block levels:

[Example #5:]

    First line of first long and wrapped source code statement...
            second line of same code statement...
            third line...
    First line of second long and wrapped source code statement...
            second line of second code statement...

Traditionally this wrapping of long source lines has been done with "hard wrapping" (i.e., inserting carriage return/newline pairs to force the wrapping), often with a limit of 80 characters per line, so all of the code fit on the screen, with none of it disappearing past the right margin. But now that programmer's editors are getting smarter, and allow soft word wrapping, it would be great if jEdit could allow the user to specify the number of spaces that the continuation lines should be indented relative to the first line (i.e., the indentation of the paragraph as a whole). For instance, in my Example #2, the user would indent the paragraph five spaces, and specify -5 (negative five) as the indentation for continuation lines. In Example #5, indentation of continuation lines would be set to 8. Setting the value to 0 (zero) would of course result in all of the lines of the paragraph lining up vertically. So far, I've been thinking of the indentation setting to be a relative value (i.e., relative to the indentation of the first line). Even better would be the option of specifying either a relative value, or an absolute value. For instance, an absolute value of 4 would cause all continuation lines to be indented four spaces, regardless of the indentation of the first line. I can imagine a number of scenarios in which that would be very useful.

In the Help pages and "Tip of the Day" pop-up boxes, the keystrokes given for any command are always the default keystrokes, even when the actual command keystrokes have been changed by the user (via Utilities > Global Settings). It would be terrific if these pages were dynamic -- in that when the user has changed the keystrokes for a command, it is reflected in the Help and Tip pages.

The Help window has two panes, the left one displaying an outline of all of the Help topics. The first six topics ("Welcome to jEdit" through "GNU Free Documentation License") cannot be collapsed into a single heading the same way that most of the other topics can. These six entries are rarely accessed, but consume a fair amount of space in the left pane. It would be great if they were grouped under one heading, and thus could be collapsed and hidden away.

In the online Help information, keyboard shortcuts are formatted as, for example, "Control-E X". But in the Utilities > Global Options > Shortcuts list it would be "C-e x". It would be much more clear if they were consistent, and if they followed the most common convention now in use, in this case, "Ctrl + E, X". One advantage to this convention is that it matches what is seen on almost all keyboards (of Intel machines), namely, "Ctrl", "Alt", "Shift", and capital letters for the alphabetic keys.

In css.xml, top incorrectly supersedes top, and thus should be removed. Same for bottom.