I would like to be able to position the cursor anywhere within the editor window and begin typing at that location.

The current behavior is to force me back to the beginning of the line at the left hand side.

My Windows based editor does this but I am trying to move in to linux full time.

Thanks,
Jon

When I had 4.1 installed using the Windows installer, I could right click on multiple files and I would get an option to Open All of the files in the same editor. With 4.2, that feature seems to be missing. Now I just get the "Open with jEdit", but it will open each file in a separate editor. Why was this feature removed in 4.2?

When I had 4.1 installed using the Windows installer, I could right click on multiple files and I would get an option to Open All of the files in the same editor. With 4.2, that feature seems to be missing. Now I just get the "Open with jEdit", but it will open each file in a separate editor. Why was this feature removed in 4.2?

I would appreciate option to choose character encoding in Open file dialog.
jEdit has troubles when opened document is not in default encoding: Utilities - Buffef options - Character encoding doesnt help, jEdit often converts wrong displayed characters to another encoding instead of reloading document with proper encoding

bumpyCaps are a very common convention for variable names etc. It would be cool if jEdit offered the option of separating words based on capitalization as well. "bumpyCaps" would then be two words.

If implemented, this option should probably be relative to the edit mode and, of course, optional.

One of the frequent things I run into is that I search for a word or a tag in my
C program and end up somewhere in a file. I end up scrolling up the screen to know
which function the cursor is in and come back to the cursor position. A nice feature
would be if the CodeBrowser plugin can highlight the function in which the cursor is
currently located.

--Hemanth P.S.

I can't select entire line/multiple lines by clicking line numbers column (I find this very useful)

No drag'n'drop edit (ok, I can live without that one)

Docked panels/windows aren't clickable on the edge of the window (they're shifted 1 pixel off the edge).
That is a waste in terms of Fittz's Law - you lose "infinite" clickable area.

for us j2me monkeys.

They're simple text files, so not too difficult...

There are many options/plugins in jEdit that offer the option between a floating window, or one which is docked (top/right/bottom/left). It would be nice to have a floating window always ontop. Sometimes docking the window uses too much space, but you don't want to love the floating window when you change focus back to your code.

In Project Viewer, when adding a new project, I'm limited to choosing a local location for project root, but I often work on remote files. I can add files from VFS and get my remote files, but I can only add one file at a time. That's very time-consuming. Would like to be able to import files from directories on remote servers. Also: projects can only consist of files, but not directories? Would like to add directories/folders as part of a project, to be able to organize my project similarly to how it will exist on the filesystem when deployed.

hi!

it would be very useful to set encoding to entire project, not only when opening files by one.

thank you!

Several very useful plugins are not adapted for development under Java 5.0,
e.g. JBrowse, JExplorer, JavaStyle and (maybe) some core plugins.

As a grateful user of these tools, I *humbly* ask if there are efforts on the way to adapt these or other tools to Java 5.0 language features?

If not, then Java 5.0 language support is my "Feature Request".

I have opened buffer1, buffer2 and buffer3. I decide to move buffer3 before buffer2, so I have buffer1, buffer3, buffer2. But when I am in buffer1 and choose command "Go to next buffer", it switches to buffer2, not to buffer 3, which is next to buffer1. imho it is a little bit anoying

Able to support beautify buffer when we use JAVASCRIPT

There's already a commandline option for putting the carret at a specificied line (+line:123). It would be nice if there was another option to specify the column too.

"Backspace unindents" is the last one feature I miss from jEdit, after we got back wrapping text at window edge in 4.3pre1. jEdit is great, but this feature is the one, that makes me still using Delphi and Eclipse -- their editors all can unindent by backspace. Please?!

Hello,

I recently gave jEdit a test drive. Some background: I'm an emacs user (5+
years) who is looking to switch editors. My reasons are that (a) hacking on
emacs is hard, I hate lisp, and accomplishing anything serious is just way too
much trouble (b) emacs development has slowed down, to the point that emacs is
now missing some of the features that the newer editors have e.g. folding (c)
the emacs syntax highlighting and indent for the languages I use most is broken
in very annoying ways. On the other hand I love emacs because (a) I can do
everything without using the mouse and (b) I can do everything without opening
any windows or dialogs outside my one editing window. I cannot stress these
two features enough. Not that I don't like having the gui stuff - it is a
great learning tool until you memorize all the shortcuts, and then great to get
the less-often-used stuff. No gui makes emacs very hard to learn. But being
forced to interact with a gui all the time while editing is a deal-breaker. I
edit with the keyboard.

I have now tried out jEdit pretty thoroughly, including configuring it exactly
the way I want, installing a whole bunch of plugins, using it for about half my
editing needs for a week, and writing a simple plugin.

Overall impression: jEdit is a very solid editor. It is a contender for emacs
replacement, and that is saying *a lot*! Superior in some regards (syntax
coloring, text folding, ease of writing extensions). Speed is about the same.
It has a few things which make it less ergonomic for heavy use though, and I
really want to fix those. I consider it to have enough promise that I would
actually spend time to improve it.

Now the problem areas:

major stuff:
* dialogs considered harmful: a lot of functions which can be done in emacs
without opening a modal dialog require one in jedit. examples include
open-file, save-as, find-and-replace, confirm-close. this is bad because (a)
it is slow (b) the dialogs are modal (c) it usually requires switching from
keyboard to mouse which is extremely unergonomic.

* many different text areas: a number of functions seem to have text areas
which are not JEditTextAreas, and in which the regular editing commands do not
work (try C+backspace). this includes the actionbar, search bar, autocomplete,
file browser, and many/most of the plugin interactions (e.g. console). this is
related to the fact that they are displayed in modal dialogs or other
specialized gui components instead of in regular text buffers (as in emacs).

* there is no way to pass parameters to an action in the action bar (other than
repeat count). e.g. C+enter open-file foo.txt or C+enter mode java . As a
result gui dialogs are necessary for each command like this.

* ambivalent about the way autocompletes work. I think I prefer the
completions showing in a temporary split pane (as in emacs). the
scrollable-menu-in-middle-of-screen approach is harder to use since you can't
(for example) page down or search, and a long list means you have to use the
mouse. also, one gets used to reading text that starts at the left margin and
has the regular text colors. using numbers to select choices is a nice touch
though.

minor stuff:
* action-bar history should not record simple keyboard navigation. perhaps
there should be a way to look at the complete history (CS+enter?), but
"prev-char" is not useful most of the time.

* autocomplete completes from the middle, not just start. this is potentially
useful, but only if there is no start-completion. the order of completions is
imperfect, typing "save" in actionbar and hitting tab shows a list in which
"save" itself is the third item.

* tab should always cycle through possible completions. C+b may be better as
C+tab, and should also cycle (and show the selected completion inserted into
the buffer).

* C+b only completes from the same buffer, not all opened buffers.

* buffers cannot be named without being stored on disk (or a vfs?). if buffers
are used for interaction (as in emacs), this would be very useful. also, there
is no command to switch to a named buffer.

* stress test: open 5Mb of text - works reasonably well, memory usage is 12Mb.
replace every 'a' with 'b' in 5Mb of text - works in 4.3pre1 (fast, but 44Mb
memory used), fails in 4.1 (out of memory, over 100Mb used). open 5Mb of
syntax-colored code - can view ok, but getting random exceptions when typing
into it (in 4.3pre1).

* need scratch buffers (not saved to file, not named, and no warning when
closing)

* selections should not go away when switching buffers.

* need to read man pages without leaving jedit. I have written a plugin that
does this (JManpagePlugin, I'll post that in a bit).

I realize that some of the things I would like to see are major changes, and
that many users may not like them In any case they should be optional.
If you think it is better, I could make them into a plugin (or plugins) instead
of adding them to the core. From looking at the plugin interface, I believe
it is possible to write plugins for actionbar-and-buffer-based (non-dialog)
file open/save, directory and archive browse, search-and-replace, autocomplete,
and console. I can do most of that, but I'm sure I would need some help when I
get stuck, and of course if anyone wants to work with me on these features that
would be great. Passing parameters using the actionbar and a few other
supporting core hooks would be very useful for this. Making the actionbar and
search bar into JEditTextAreas can only happen in the core and looks pretty
major (but very nice, if possible).

Well, there it is, what do you guys think?

-A.


P.S. I imagine you might think that "I just want to turn jedit into emacs". In a sense, I do, I want all the good (in my opinion) aspects of emacs. Using buffers for interaction instead of dialogs is one of the ways in which emacs is better (although I agree it is not for everyone, and so it should be optional). In another sense, no, I want an editor that is the same or better in all regards, not better in some but worse in others.

--------
I'm cross-posting this to jedit-devel and here so more people have a chance to comment. I'd post it under my account but for some reason I can't log in (using drupal.org).

Hi,

From what I can see, spell check is supported, but not as you type. Some editors support the ability to underline words as you type. It would be fantastic if JEdit can do that. I can imagine many users will be using JEdit to write Java code, for example, so this might not seem as important. However, I use JEdit to write XHTML and so having spell checking for content would be really good.

If it is to supported, I would guess that it should be configurable as to what types of content to spell check, e.g. comments in code would be useful.

The key thing is that it should be spell checking _as you type_

If this already exists, please let me know where it is, and apologies for posting!

When I use Search in directory for search&replace, it always opens all changed files. It is very annoying I would appreciate checkbox "do not open files"

When a user does Edit > Find and searches for all files within one or more directories, their search results can contain multiple files. But there does not appear to be an easy way to open up all of those files at once. In the Find results window (where all the files and matching lines are listed), the user should be able to right-click within the window and have an option to open all files.