PreviousNextTracker indexSee it online !

(68/212) 204 - Smarter "End" key

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:56 Assigned
Priority 5 Labels
Status open Group None
Resolution None

Comments

2008-04-29 04:47:57
nalfeo

Logged In: YES
user_id=2074875
Originator: NO

For a class project, my partner and I implemented this feature.

For patch, see
http://sourceforge.net/tracker/index.php?func=detail&aid=1953878&group_id=588&atid=300588

Thanks
2008-05-02 00:43:37
cmcqueen1975

Logged In: YES
user_id=1579704
Originator: 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:56
cmcqueen1975

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

Some issues:
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:13
ezust

rolled back part of it in 15996.
We will see if we can debug it and incorporate it into jEdit though.