in fact i have made one, if you think useful you can add this feature to new jedit versions. it find text like "content="text/html; charset=xxxxxx"" at the begin of the html.

[code]
BufferIORequest.java
    /**
     * Tries to detect if the stream is gzipped, and if it has an encoding
     * specified with an XML PI.
     */
    private Reader autodetect(InputStream in) throws IOException {
        in = new BufferedInputStream(in);

        String encoding = buffer.getStringProperty(Buffer.ENCODING);
        if (!in.markSupported())
            Log.log(Log.WARNING, this, "Mark not supported: " + in);
        else if (buffer.getBooleanProperty(Buffer.ENCODING_AUTODETECT)) {
            
            {// neoe add: detect html's encoding
                String enc = getHtmlEncoding(in);
                if (enc != null && MiscUtilities.isSupportedEncoding(enc)) {
                    buffer.setProperty(Buffer.ENCODING, enc);
                    return new InputStreamReader(in, enc);
                }
            }
	....
	(original lines)

/**add by neoedmund*/	
private String getHtmlEncoding(InputStream in) throws IOException {
        String enc = null;
        String key = "charset=";        
        int bufSize=1000;
        byte[] buf = new byte[bufSize];
        in.mark(bufSize);
        int len;
        if  ((len = in.read(buf,0,bufSize)) >0) {
            String line=new String(buf,0,len);    
            int p1 = line.indexOf(key);
            if (p1 >= 0) {
                int p2 = p1 + key.length();
                p1 += key.length();
                if (line.charAt(p1) == '\'' || line.charAt(p1) == '"') {
                    p1++;
                }
                while (p2 < line.length()
                        && "'\" >;,.".indexOf(line.charAt(p2)) < 0) {
                    p2++;
                }
                if (p2 <= line.length()) {
                    enc = line.substring(p1, p2);
                }
            }
        }
        in.reset();        
        return enc;
    }
[/code]

Hello

jEdit is great, but is there a switch somewhere to use a native OS file selector instead of the default java file selector ? I know the default java one can be extended beyond what a native selector could do, but right now the default in 4.2 is quite restricted, for example it doesn't support right-click contextual menus.

thanks
haki

Hi

I'd like to be able to copy text to the clipboard and paste it into the input field under "Search For" in the "Search and Replace" popup window. Can this be done in the Windows version?

Thanks

Peter Mount

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".

"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.

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.

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").

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.

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.

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 css.xml, top incorrectly supersedes top, and thus should be removed. Same for bottom.

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.

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.

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.

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.

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.

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.

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.

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.

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