Wednesday, August 09, 2006

Smart End

Since KDE 3.5.4 Kate Part supports "smart end". Right now it behaves like this when pressing "end":
  1. go to last non-space character
  2. go to the last character (i.e. hit end twice)
I'm writing this blog to get feedback about what's the right/expected behaviour. Is it as described above, or should we first go to the very last character, and to the last non-space only when hitting then end-key twice?

Feedback along with why you prefer solution A or B is welcome!

13 comments:

logixoul said...

I prefer to go to the very last character with End, and to the last non-space only when hitting End for the second time. That's because I often inadvertently leave spaces at the ends of lines, which is bad. If an end doesn't take me to the very last char, it'll get worse.

kevin said...

I agree very much with logixoul. Additionally, I often stop writing (sometimes just after typing a space) to correct a mistake earlier in the line and then jump back to continue hitting End. So the current behaviour provokes superfluous spaces at the end.

superstoned said...

can't a third End go to the end of the document, btw? same with Home three times...

dhaumann said...

@superstoned: no, use ctrl+end/home for that.

Víctor said...

The first pulsation should go to the last non-space character, and the second pulsation should go to the end of the line. Logixoul solution is completely unintuitive (the second pulsation would bring the cursor back, but the 'end' key has the "forward" connotation).

I fully agree with three end's going to the end of the document.

Rafa said...

I'd go with solution a) due to victor's very same reasons...

pipitas said...

I support

* go to the *very* end with first pulsation
* go to last non-space char with second pulsation

In fact, it is not very important to *me* personally -- I could easily learn either way.

But I *assume* [1] that newbies would expect the above behaviour...

Assume the following scenario:

* kate is set to not show spaces
* user is unaware that there currently *are* spaces at the end

I also make the followintg assumption:

* most users will never learn about the "hit [END] twice" trick; they'll only use that key once per incident

Ask yourself: what is the more "naturally expected" behaviour of the [END] key in an editor, if never ever anyone had invented the trick to hit it twice? How would you rather expect it to behave?

So I suspect newbies would prefer it, if those spaces where somehow *shown* to them by the cursor (in-expectely) goign beyond the EOL place they assumed.

A "hit [END]" that takes them to the *real* EOL would *shows* them there is space at the end of the line (probably lots of it, and unwanted one).

It also should not be too difficult for them now to manouver the cursor back to the last non-space char (if that's where they had intended to go), even if they do never find out about the second pulsation option.

Now assume the other behaviour: first pulsation does move to last non-space char. This can possibly *hide* info from the user (she may not be aware of the unwanted space, and have no chance to find out unless she deliberately looks for it). And she'll *not* even try to move further unless she is aware of the additional space, and leave the space(s) in that document forever...

The proposed behaviour increases the chances for the user to learn additional information (about his document, about his kate editor's functions).

victor's argument has something to it ("it is unintuitive when the 2nd stroke makes the cursor go *backward*"). But remember: 2nd stroke is for advanced users. Also, how "intuitive" is it for a relatively unexperienced user of a simple text editor (who knows that "spaces" are facts of life, are printable, are important, are parts of a line of characters, and can even occur on the very end of a line) that hitting the EOL will indicate to him "I'm *not* going to take you to the real EOL -- my developers told me to go to the last 'non-space' character instead; they think it's more intuitive, and I expect you to know that there may be some hidden spaces after that cursor position." Bah!

[1] To find out for sure, we should ask OpenUsability.org for their input. They have means to find out what's easier to learn for newbie users. What I argued is just my rather un-educated guess.

mahoutsukai said...

@pipitas: The users will very quickly notice that pressing Home in Kate makes the cursor jump to the first non-space character. Therefore a similar behavior of End would be only logical.

In order to make the behavior (first jump after the last non-space character, then jump to the very last character) less surprising I suggest to show trailing whitespace by default. Then it will be obvious. Moreover, on the very first press of End (or alternatively on the very first press of End which doesn't take the user to the very end of the line because the line has trailing whitespace) you could show a "Tip of the day" telling the user about Smart End.

IMO it's much better to tell the user how Kate works than to hide the smart end behind a double End. The cursor jumping forward on the second press of End will completely confuse newbies and will surely provoke a few bug reports.

Víctor said...

Another idea... when you use end to go to the last non-space character, the true last character in the line would flash. This way, you know if there are spaces.

logixoul said...

After reading the recent comments, I've changed my mind.

I now prefer to go to the last non-space with End and to the very last character only when hitting End for the second time.

However, I suggest that whitespace is unconditionally displayed when at the end of the line. This way everybody should be happy.

dhaumann said...

Thanks for all the input so far. As expected both versions have their pro & contra. For now we stick to the current implementation, i.e. go to last non-space, and then to EOL.

If this does not feel right in the long run, we can change it for kde4.

pipitas said...

@mahoutsukai:

Even if it is a "lost battle" :-) because the decision is already made, let me respond with one thing.

You said: "The users will very quickly notice that pressing Home in Kate makes the cursor jump to the first non-space character. Therefore a similar behavior of End would be only logical."

Whatever may be "logical" in the formal sense, is not necessarily user-friendly.

See, a cursor-jump to the first non-space character leaves still very well visible to the user the fact that there are still spaces at the beginning of the line. The user can discover that easily.

Spaces at the end of the line are "invisible"; at the front of the line they are "visible".

That's why I would have preferred the other behaviour.

Jason Stubbs said...

Agreeing with pipitas...

Unless I've missed something, there is only one point for the first End stroke jumping to the last non-whitespace:
* A second End moving backward is unintuitive
* Home goes to the first non-whitespace character.

And for the first End jumping to the real last character? As follows:
* Unrealized spaces at the end of a line
* Heading back to the end after correcting text earlier in the line

Now logixoul decided to change his/her opinion after reading comments so I'll call the above 1.5 for End going to the end (pipitas also mentioned point #1) versus 2 for End not going to the end. For the record, I often head back to the end after correcting text earlier in the line. Also for the record, I think Smart End was a good invention and should remain (albeit triggered by the second End stroke).

However, are any of those points really representative of general usage? Does Kate (and by extension KWrite and KDevelop) even fall into the "general usage" group? Isn't Kate a programmer's editor? So now to discredit the points against my preference... ;)

"A second End moving backward is unintuitive". Well, a third End moving backward is just as unituitive. Need I say more?

"Home goes to the first non-whitespace character". This is logical for programming. Regardless of whether it's C++ or HTML, whitespace at the start of line is almost always used to show structure. When editing, there is very little need to edited said structure after defining it. But where does whitespace at the end of a line fit it? How often is it that one wants to not edit at or after whitespace at the end of a line?

I may be wrong, but I think that Smart End is the default in KDE 3.5.4? Adding to the list of points against End jumping to the last non-whitespace character, isn't that a change in *existing functionality* for a dot release?

Finally, while I agree that this choice should really go to openusability.org rather than being decided by 12 blog comments, I would really like to ask you Dominik:

How often do you find the need to edit the non-whitespace characters immediately preceding the end-of-line whitespace and does that exceed how often you want to jump to the real end-of-line?