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.

When editing a Perl script containing references to array references and arrays of references (e.g., $$arrayRef and @$arrayRef), the first character (the leading $ or @) is not syntax highlighted like the rest of the string.

In Search > Find, when the file filter is set to "*.*", and jEdit's temp files are stored in one or more of the directories searched (which is the default), then if jEdit finds text in, let's say, x.txt, it will also find text in #x.txt#. In the case of many files, if the user is replacing several strings, then each time they do a Replace All, not only is the text changed in x.txt, but also #x.txt# gets changed, producing ##x.txt##. With more replacements, it gets worse. jEdit should ignore its own temporary files, or have that optional.

Most jEdit dialog boxes contain multiple buttons, and the user can tab from one button to another using the Tab key. Once the user has stopped at a button and it is highlighted, they quite rightly expect that action to be performed when they press the Enter key. But jEdit misleadingly performs whatever action whose button is selected when the dialog box first appeared, the default.

For example, in the Search > Find dialog box, if the user tabs to the Replace All button, that button is highlighted. But then pressing Enter does not execute the selected button. Instead it executes the Find button (which was the button selected when the dialog box first appeared).

For example, if the user makes changes to a file and then tries to close the file, the "File Not Save" dialog box appears, with the "Yes" button preselected. Pressing the Tab key then selects the "No" button. But pressing Enter does not execute the "No" button.

When editing DOS batch files (*.bat), every comment line (i.e., any line beginning with "::") is mistakenly considered to be a label by jEdit (as reflected in the coloring and font setting of the entire line), regardless of how many spaces are in between the two colons and the first word in the comment line. Actually, even if there were absolutely no spaces between the two colons and the first word (e.g., "::This block of code..."), then it should still be considered a valid comment, and not a label. It should only be considered a DOS batch label if there is only one colon and the label name is immediately adjacent to that colon, with no spaces in between (e.g., ":Label1").

When editing Perl scripts, jEdit highlights a regex syntax (blue by default), e.g., "m/\w\d/". But if the regex spans multiple lines, e.g.,

m/\w
\x/x"

then jEdit fails to syntax-highlight it correctly.

"Edit > Indent > Remove Trailing Whitespace" should be "Edit > Indent > Delete Trailing Whitespace", so the wording is consistent with other Delete commands, and so it then is sorted together with the other Delete commands in the Utilities > Global Options > Shortcuts list.

In the online Help information, within "Part III. Writing Macros", all of the BeanShell code listings use smart quotes ("curly quotes", as seen in Word documents that are auto formatted). These are syntactically incorrect and generate errors. They should be replaced with plain double quotes.

In "Chapter 13. Macro Basics" > "Predefined Variables in BeanShell", it repeats: "scriptPath - set to the full path of the script currently being executed."

In the information on Editing Source Code > Bracket Matching (bracket-matching.html), "shortcut: Control-E [" should be "shortcut: Control-E Control-[", and "shortcut: Control-E ]" should be "shortcut: Control-E Control-]".

In "Working With Paragraphs", under "Edit>Text>Format Paragraph", it instructs the user to "See the section called "Inserting and Deleting Text" for information and word wrap and changing the wrap column." But that section has no information on word wrap or changing the wrap column.

Also, "for information and word wrap" should be "for information on word wrap".

I just upgraded the two pc's and two macs I use to Jedit 4.2, and noticed that the "Insert" command was gone from the File menu! Any idea where it went or how I can replace the functionality?

Jedit's terrific - thanks to all involved.

How do you search for non-printing characters? ie: Searching for and replacing all carriage returns with tabs or vice versa...