Change default status of "eat_space_to_next_word"

[SvenG]

Sorry, that I was too fast

Still I would like to keep my vote for "Pale Moon should NOT select the space" because selecting foo in
foo bar
would be different from selecting foo in
foo. bar
or in other words selecting: a word at the end of a sentence or in front of a comma or any other sign (I guess everything that is not a word character or digit) would be different from selecting the same word at another position of the sentence. Also it would make a difference if I select bar in the first or in the second case cause in the first example I have added a space between bar and the linebreak which I did not in the second (unless the forum software removes trailing spaces but for example in the compose window in FossaMail it could happen that way).

That's not a really smart behavior and leading to different results even within the same application. So, actually, the situation in MS Word or Word Perfect or whatever application using that function is borked unless they managed to work around such issues (Pale Moon/Firefox/Mozilla isn't). But in that case it would make word selection even more unintuitive. And I really see no way how to handle this properly with trailing spaces.

BTW. for people not knowing that this is an option, this will get entirely illogical cause it far from obvious what is going on.

[Moonchild]

You have to understand that Pale Moon will not just "dumb" select anything plus space. If it reads punctuation it will not select the space because it will stop at the punctuation.

This pref only affects whether moving forward by word should go to the end of this word or start of the next word

iow: It only acts on word boundaries with multiple words separated by whitespace.
If you are interested in the actual code and selection routine (which has clear comments surrounding the code explaining what happens) the look up nsIFrame::PeekOffset(nsPeekOffsetStruct* aPos) in nsFrame.cpp in the source code.

[SvenG]

That is exactly how I understood it and how it works and how it is doing wrong. You don't even have to go into the source for that, the examples posted earlier in a compose window show hows borked and illogical that function is. Word selection should always select the same thing no matter of the surrounding not leading to something like this:

BorkedWordSelection.gif

That's in Fossa Mail. Selecting foo or bar that way, you don't have to add a space after pasting in the first example but you have to add one in the second while in both cases you wanted to copy and paste foo/bar, and you do exactly the same but get different results:

BorkedWordSelection2.jpg

That is really a desired behavior? Just forget for a second that you know the reason, why it leads to this result, even forget that you know about this pref. Just think as a user who wants to copy and paste foo or bar and gets different results.

The idea isn't that terrible, it's just far from well done. In RegEx it should match something like this ([a-zA-Z0-9]+\ *).

[Moonchild]

Word selection should always select the same thing no matter of the surrounding

No, it shouldn't. You claim it's "terribly broken" but it is not -- apparently you just don't see the logic in both ways of working.

There is just as much justification in selecting the whitespace as there is in not selecting it, but it is situational. Situational also means it's got to be adaptive and following a rigid set of rules to always apply doesn't always work. Also keep in mind that word selection also includes selecting multiple words when jumping by word (shift+ctrl+arrow) and selecting partial sentences instead of entire paragraphs or single words and pasting them elsewhere one after the other. It is just as much a chore in workflow to have to add whitespace when you want to build blocks of text as it is to delete whitespace when you just want the body.

I'm really not in a position to try and make you understand because I don't know how to properly explain it (I'm not a teacher). I also don't want this thread to become an argument because it would be endless as there are pros and cons to both ways of working, neither of the two is applicable to all situations and neither of the two is broken. What is needed in Pale Moon is the default that is:

• Catering to the most common use of the feature by the users, OR
• If there is no clear majority, to use what is established practice for the platform

[SvenG]

I guess we are not that far from each other, we are just talking different languages

I sure understand the logic behind that behavior and I am pretty well aware that this is by design, it's really not that complicated, just complicated to describe as you pointed out Actually, the main problem is, that this way the select process get's adjusted for the paste process (at least in the cases where the logic matches). It would be much smarter to have a situational paste process. The space is useless during selection (unless you want to cut/delete afterwards but in that case a leading space could be smarter), it is useless during copy, it is only of value after the paste process, so at that point the application should decide whether to add a space or not. That will lead to false positives as well but I would say less, a few of them could even be detected and auto-corrected.

I know that is nothing you can change cause you are not making the target application for the paste process, well, the vast majority of the at least, and it's also - most likely - not your fault cause this was already part of Mozilla code. And maybe the current solution to the process is the least evil - at least I can't figure out one that isn't equally flawed/borked/broken/weird or worse - but it is definitely not a really good one, that's something I don't buy even from you (and you can seeĺl me a lot, Moonchild), cause it leads to inhomogeneous results (at times unpredictable unless you know the exact "rigid set of rules") and inhomogeneous behavior in different applications. That's what happens when single (yet major) applications start doing things different and other (but not all) applications try to adapt to that.

BTW, you can have trailing spaces in Linux as well, when selecting multiple words, just jump to the next word and back, and it's a common in all the applications I have tested, which were quite a few. So, you have a very defined and most of all predictable process.

And concerning workflow... well, people get used to lot's of things.

[Moonchild]

At least we are one the same page, then.
None of the possible solutions are really good, because the way the clipboard is used *is* "inhomogenous". A "smart paste" isn't even a solution either because when you paste something from the clipboard, you generally don't want anything that isn't exactly what's on the clipboard, so even that wouldn't be flawless. There is no flawless solution, and.. well, semantics: you can either call all of them broken or none of them broken.

All I need is the default (since it's still configurable) that satisfies the most common or most used use case. With a vast majority so far in the survey of people preferring that the space isn't selected, regardless of platform, it looks like a change is in order (which will in fact be a minimal commit of removing the pref override on Windows). Pale Moon Commander can do with adding this as an option, when I get a free moment.

[Moonchild]

Interim results:

[Moonchild]

It's clear that most people have given their feedback on the quick survey by now - thank you all for your responses!
Here are the results: An overwhelming majority wants this default setting changed, with only 16.6% preferring Pale Moon's current behavior on Windows, so it will be changed in the next version of Pale Moon. You will still have all freedom of using it or not, of course

[KNTRO]

Wow! That was pretty shockin'!

Thanks all people for their comments! I wish all suggestions' processes were as good as this was:

• Request for suggestion
• Some debate
• Poll
• Results

That's it.

Will this be applied to both Pale Moon & FossaMail?

Thanks.

[squarefractal]

Will this be applied to both Pale Moon & FossaMail?

PM and FM are built from the same core, so yes.

Also, it's been "applied" already: https://github.com/MoonchildProductions ... 3e40e25252

[KNTRO]

Oh, thanks a lot for that headsup!