Expanding selection

[Florian Balmer]

Hello all

I found that many editors and browsers (html display and textarea) on
Windows include whitespace following words (or non-word characters)
for selections initiated by double-clicking and continued by mouse
dragging. This may be an advantage for drag & drop and copy & paste
operations, as there's no need to manually delete and reinsert blanks
after the moved / pasted text block.

Here's a simple patch to achieve this (I will send the full modified
file directly to Neil):

--- scintilla-cvs\src\Document.cxx Sun Jun 29 11:18:44 2008
+++ scintilla-mod\src\Document.cxx Wed Aug 20 20:36:30 2008
@@ -898,0 +899,4 @@
+ char ch = cb.CharAt(pos);
+ while (pos < (Length()) && WordCharClass(ch) == ccSpace) {
+ ch = cb.CharAt(++pos);
+ }

This results in the same behaviour as currently experienced when
expanding the selection using Ctrl+Shift+Right Arrow. If this is
uncommon on non-Windows platforms, maybe this could go in as a
Windows-specific change?

I haven't searched the mailing list to see if this issue has already
been discussed, or maybe even rejected. If so, please ignore this
post.

Greetings
--Florian

[Paul Hutchinson]

On Wed, Aug 20, 2008 at 3:13 PM, Florian Balmer
<florian...@gmail.com> wrote:
> I found that many editors and browsers (html display and textarea) on
> Windows include whitespace following words (or non-word characters)
> for selections initiated by double-clicking and continued by mouse
> dragging. This may be an advantage for drag & drop and copy & paste
> operations, as there's no need to manually delete and reinsert blanks
> after the moved / pasted text block.

Maybe there should be a second set of word char's for the mouse double
clicks as well as the normal SCI_SETWORDCHARS and
SCI_SETWHITESPACECHARS?

I like the current double click behavior but can see why people might
want something different.

Paul Hutchinson
http://coderoar.com

[Florian Balmer]

> Maybe there should be a second set of word char's for the mouse double
> clicks as well as the normal SCI_SETWORDCHARS and
> SCI_SETWHITESPACECHARS?

I think it makes the Scintilla APIs too complicated if there's special
character sets for each different action. It's in fact the same case
as for Ctrl+Shift+Right Arrow, and the suggested solution works with
the CharClassify sets.

If this is not a widely accepted solution, could this have a chance to
go in if there's a new option to control mouse selection behaviour?

I've posted an outdated diff, the new one is pasted below.

--Florian

--- scintilla-cvs\src\Document.cxx Sun Jun 29 11:18:44 2008

+++ scintilla-mod\src\Document.cxx Thu Aug 21 10:06:51 2008
@@ -898,0 +899,2 @@
+ while (pos < (Length()) && (WordCharClass(cb.CharAt(pos)) ==
ccSpace))
+ pos++;

[Neil Hodgson]

Florian Balmer:

> I found that many editors and browsers (html display and textarea) on
> Windows include whitespace following words (or non-word characters)
> for selections initiated by double-clicking and continued by mouse
> dragging. This may be an advantage for drag & drop and copy & paste
> operations, as there's no need to manually delete and reinsert blanks
> after the moved / pasted text block.

Source code and general text differ in that you generally want to
be more precise with source code and will more often be selecting
pieces of words and attached operators. Automatically selecting
following spaces may require that a spurious space be trimmed off at
the destination. For general text, the right behaviour was defined by
Apple: remember that word ends were selected and ensure that they
remain word ends at their destination.
http://developer.apple.com/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGUserInput/chapter_12_section_5.html#//apple_ref/doc/uid/TP30000361-TPXREF36
I don't believe this is the best behaviour for a source code editor
although its possible that it could be an option.

A related behaviour that is less pleasant (for source code) is
automatically switching to word selection after swiping into a second
word as is done in Internet Explorer and some word processors.

Neil

[Florian Balmer]

The Apple way seems to be somewhat too intelligent. I don't like
things going on behind the curtains, and exchange with applications
not designed to handle intelligent clipboard text may be complicated.

The Internet Explorer way is not a good idea, I agree, but at least
you can see exactly what is being put to clipboard.

I will send my modified source and documentation files to control the
"mouse selection mode" to Neil.

--Florian

[Paul Hutchinson]

I agree that source is not the same as editing in a word processor and
I wouldn't what my text editor doing that (it would drive me nuts).

People sometimes use Scintilla for things other than source editing
though so I would still be in favor of added a second set of word
char's for mouse selections. If you want I can put together the code
for this, if you would like.

Paul Hutchinson

[Neil Hodgson]

Paul Hutchinson:

> People sometimes use Scintilla for things other than source editing
> though so I would still be in favor of added a second set of word
> char's for mouse selections.

I can't see how changing the set of word characters for mouse
selection would produce the result Florian wants. Say you double click
on "cat" in "the cat sat": if you include space in the set of word
characters then the whole text would be selected, not just "cat ".

Neil

[Florian Balmer]

Further experiments showed that my solution (submitted to Neil) also
affects both SCI_WORDSTARTPOSITION and SCI_WORDENDPOSITION.

Either "mouse selection mode" could be renamed to something more
general like "word selection mode", and could be adjusted before
calling any of the affected functions to achieve desired behaviour. Or
there would have to be a check if the select call originates from on
of the above messages, and handle everything as usual.

The current release candidate of Notepad2 uses the new selection mode
for testing, it's much more like what I'm used to on Windows (also
with source code, for me, I'm often transferring spaces along with
other parts). Notepad2 has a command to select a word (Ctrl+Space), so
selection mode is temporarily reset not to include spaces.

--Florian

[PhiLho]

On 20 août, 21:13, "Florian Balmer" <florian.bal...@gmail.com> wrote:
> I found that many editors and browsers (html display and textarea) on
> Windows include whitespace following words (or non-word characters)
> for selections initiated by double-clicking and continued by mouse
> dragging. This may be an advantage for drag & drop and copy & paste
> operations, as there's no need to manually delete and reinsert blanks
> after the moved / pasted text block.

Just my 0.02€: I hate this behaviour!
I am used to control precisely what I want to select, and if I want
the space after the word I selected after a double-click, I just hit a
Shift+right arrow after it. After all, sometime I want the space
before the word instead. And most often than not, no space at all.
I am annoyed each time IE or MS Word try to be smarter than me and
select more than I want.

That said, I am not against such behaviour... as long as it is
optional!

PS.: To be honest, FF does the same thing. And what annoys me the most
is this automatic space selection is also done (by IE, not by FF) on
drag selection. And unlike in FF, I cannot do a Shift+left arrow to
unselect this space!
I experimented a bit before posting, and I see I can control the
amount of selection (going a bit further, then slowly going back) but
it is delicate to control and still annoying.
That's slightly OT but my point is that all MS ideas are not good to
implement (or set as default!).

[Florian Balmer]

I have come back to the default behaviour, by now, as there's some
cases I don't like. If somebody is still interested, I can submit my
patch.

--Florian