The "Smart End" function currently moves to the end of the line, excluding trailing
whitespace, on the first press of End. The second press of End goes to the real end
of the line.
Many languages allow "trailing comments", where everything following a certain character, up to the end of the line, is a comment. E.g. in C++:
Object.DoSomething(); // Does something
My idea for a "Smarter End" function is to have the first End keypress go to the end of the line, excluding trailing whitespace AND comments. So in the above example, the cursor would go to just after the semicolon.
|Submitted||cmcqueen1975 - 2008-02-28 - 01:35:56z||Assigned||nobody|
|2008-04-29 - 04:47:57z
|Logged In: YES
For a class project, my partner and I implemented this feature.
For patch, see
|2008-05-02 - 00:43:37z
|Logged In: YES
nalfeo -- interesting. Can I suggest an improvement. Rather than requiring a list of comment delimiters, use the pre-existing syntax awareness of jEdit -- for its syntax highlighting. That is, surely there is some way to read the syntax type that the cursor is on.
I have implemented this in the past for another editor (Ed for Windows). The logic is fairly simple, something like:
Go to end of line
while (not at the start of the line, and character left of cursor is whitespace or comment)
Go left one character
(I'd be interested in doing this myself for jEdit, but currently have neither the time nor the Java skills.)
|2009-02-25 - 06:07:56z
|I looked at the API docs to try to find a way to read the syntax highlighting at the
cursor. Unfortunately the API isn't simple and doesn't lend itself well to this usage
(it's more geared towards the specific task of styling, and not so helpful for machine-based
syntactical analysis for other purposes).
See the plug-in Syntax Helper for example source code. Probably see also the action edit-syntax-style (I haven't seen this myself).
1) The "token" API is geared towards iterating from the start of the line to the end of the line. Going from end to start will be inefficient. (One-way linked list.)
2) Within a comment block, there can be tokens that are something other than one of the "comment" styles. E.g. Doxygen tags in C files are highlighted as the "label" style. This makes it difficult to know for sure whether the cursor is within a comment block.
3) There isn't a syntax style for "whitespace".
So this isn't looking like an easy implementation unfortunately. To improve the situation:
1) Provide an API function to return the syntax highlighting ID of the current caret position directly
2) Ensure that syntax highlighting always gives tokens an ID that specifies definitively "within a comment block". E.g. Doxygen tags in C files should have an "tag in comment" style instead of just "label" style.
3) Add a "whitespace" syntax highlighting style ID.
4) Alternatively, provide API functions something like "caret within comment? (true/false)" and "caret on whitespace? (true/false).
|2009-08-19 - 21:50:13z
|rolled back part of it in 15996.
We will see if we can debug it and incorporate it into jEdit though.