Multiple selection additions

[Neil Hodgson]

   Attached is a patch that implements multiple-selection behaviour for:

1) Horizontal movement and selection commands. Bound to the cursor Left, Right, Home, End, ‘\’, and ‘/' keys in conjunction with various combinations of modifier keys. Some are not bound by default or may be bound by the application in different modes such as wrap.aware.home.end.keys in SciTE.

Controlled with SCMS_MULTISELECT_MOVEH flag.

The commands are: SCI_CHARLEFT, SCI_CHARLEFTEXTEND, SCI_CHARRIGHT, SCI_CHARRIGHTEXTEND, SCI_WORDLEFT, SCI_WORDLEFTEXTEND, SCI_WORDRIGHT, SCI_WORDRIGHTEXTEND, SCI_WORDLEFTEND, SCI_WORDLEFTENDEXTEND, SCI_WORDRIGHTEND, SCI_WORDRIGHTENDEXTEND, SCI_WORDPARTLEFT, SCI_WORDPARTLEFTEXTEND, SCI_WORDPARTRIGHT, SCI_WORDPARTRIGHTEXTEND, SCI_HOME, SCI_HOMEEXTEND, SCI_HOMEDISPLAY, SCI_HOMEDISPLAYEXTEND, SCI_HOMEWRAP, SCI_HOMEWRAPEXTEND, SCI_VCHOME, SCI_VCHOMEEXTEND, SCI_VCHOMEDISPLAY, SCI_VCHOMEDISPLAYEXTEND, SCI_VCHOMEWRAP, SCI_VCHOMEWRAPEXTEND, SCI_LINEEND, SCI_LINEENDEXTEND, SCI_LINEENDDISPLAY, SCI_LINEENDDISPLAYEXTEND, SCI_LINEENDWRAP, SCI_LINEENDWRAPEXTEND.

The patch also reimplements some rectangular commands but these just switch to rectangular mode: SCI_CHARLEFTRECTEXTEND, SCI_CHARRIGHTRECTEXTEND, SCI_HOMERECTEXTEND, SCI_VCHOMERECTEXTEND, SCI_LINEENDRECTEXTEND.

2) Word and line deletion commands. Bound to Backspace and Delete keys in conjunction with Ctrl and with or without Shift. 

Controlled with SCMS_MULTISELECT_DELETEWORDLINE flag.

The commands are: SCI_DELWORDLEFT, SCI_DELWORDRIGHT, SCI_DELWORDRIGHTEND (not bound by default), SCI_DELLINELEFT, SCI_DELLINERIGHT.

3) Line up/down movement and selection commands. Bound to the cursor Up and Down keys with or without Shift.

Controlled with SCMS_MULTISELECT_MOVEV flag.

The commands are: SCI_LINEDOWN, SCI_LINEDOWNEXTEND, SCI_LINEUP, SCI_LINEUPEXTEND.

The patch also reimplements some rectangular commands: SCI_LINEDOWNRECTEXTEND and SCI_LINEUPRECTEXTEND.

   Line up and down actions are likely to merge carets on one line when they move to an empty line. Only the main caret has a lastXChosen value that it will spring back to. While the selection data could include a lastXChosen value for each caret, this is a large change which I will not be working on for now. The current implementation may be worthwhile when virtual space is turned on or when the vertical movement is short and over lines of similar length.

   Other vertical movement keys do not support multiple cursors. It does not seem useful to me to support movement of multiple cursors over large vertical distances. If others want to produce implementations then they may be included.

   A new setting MultipleSelectionOptions determines which of these work. All are turned on by default in the patch. This was done since some applications have constructed their own multiple selection functionality which may break if these were on by default. It would be simpler if MultipleSelectionOptions were not needed or could be simplified to a single boolean. Please speak up if you need this degree of control. If you don’t have multiple selection turned on then none of these will be active.

   This is a large patch which changes how selections and related actions are performed. It is very likely there are bugs. Watch out for problems like overlapping selections: in Scintilla’s model of multiple selection, selections should never overlap. There are many functions associated with selection movement including correct and minimal redrawing, scrolling when needed, primary selection claiming on Unix/X, and reporting the movement to the application. Report if any of these behaviours have stopped working.

   The patch is against current Hg and depends on recent changes in Hg.

   This change set has not been committed to Mercurial. 

   The Mercurial repositories are:

hg clone http://hg.code.sf.net/p/scintilla/code scintilla

hg clone http://hg.code.sf.net/p/scintilla/scite

   

   This change is also available from

http://www.scintilla.org/scite.zip  Source

http://www.scintilla.org/wscite.zip Windows executable

   Neil

[johnsonj]

How cool!

[Philippe Lhoste]

On 16/06/2015 06:36, Neil Hodgson wrote:
> Attached is a patch that implements multiple-selection behaviour for:
>
> 1) Horizontal movement and selection commands. Bound to the cursor Left, Right, Home, End,
> ‘\’, and ‘/' keys in conjunction with various combinations of modifier keys. Some are not
> bound by default or may be bound by the application in different modes such as
> wrap.aware.home.end.keys in SciTE.
> Controlled with SCMS_MULTISELECT_MOVEH flag.

> The commands are: [...]

>
> 2) Word and line deletion commands. Bound to Backspace and Delete keys in conjunction with
> Ctrl and with or without Shift.
> Controlled with SCMS_MULTISELECT_DELETEWORDLINE flag.
> The commands are: SCI_DELWORDLEFT, SCI_DELWORDRIGHT, SCI_DELWORDRIGHTEND (not bound by
> default), SCI_DELLINELEFT, SCI_DELLINERIGHT.
>
> 3) Line up/down movement and selection commands. Bound to the cursor Up and Down keys with
> or without Shift.
> Controlled with SCMS_MULTISELECT_MOVEV flag.
> The commands are: SCI_LINEDOWN, SCI_LINEDOWNEXTEND, SCI_LINEUP, SCI_LINEUPEXTEND.
> The patch also reimplements some rectangular commands: SCI_LINEDOWNRECTEXTEND and
> SCI_LINEUPRECTEXTEND.
>
> Line up and down actions are likely to merge carets on one line when they move to an
> empty line. Only the main caret has a lastXChosen value that it will spring back to. While
> the selection data could include a lastXChosen value for each caret, this is a large
> change which I will not be working on for now. The current implementation may be
> worthwhile when virtual space is turned on or when the vertical movement is short and over
> lines of similar length.

Mmm, I am used to just move the caret to go out of rectangular selection / multiple
selection... Which trips me often as I am using Brackets (based on CodeMirror) which
supports such moves. But I suppose I can get used to it. It is globally useful, in some
cases, I think (mostly for horizontal movements, though).

But then, how do we go out of this mode? I suppose a single click can do it, but with
keyboard? In the mentioned editors, Esc do the job.

>
> The patch is against current Hg and depends on recent changes in Hg.
>
> This change set has not been committed to Mercurial.

A bit confused here... Is this code only available in the zip files mentioned below?

> The Mercurial repositories are:
> hg clone http://hg.code.sf.net/p/scintilla/code scintilla
> hg clone http://hg.code.sf.net/p/scintilla/scite
> This change is also available from
> http://www.scintilla.org/scite.zip Source
> http://www.scintilla.org/wscite.zip Windows executable

Does SciTE have a property to enable this? Or do we have to use Lua to enable it?

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[Neil Hodgson]

Philippe Lhoste:

> Mmm, I am used to just move the caret to go out of rectangular selection / multiple selection... Which trips me often as I am using Brackets (based on CodeMirror) which supports such moves. But I suppose I can get used to it. It is globally useful, in some cases, I think (mostly for horizontal movements, though).
>
> But then, how do we go out of this mode? I suppose a single click can do it, but with keyboard? In the mentioned editors, Esc do the job.

When “Selection Add Next” was added a week ago, Esc was made to exit multiple selection.

> A bit confused here... Is this code only available in the zip files mentioned below?

Either from the zip files or by applying the attached MultiMove3.patch file to the current repository.

> Does SciTE have a property to enable this? Or do we have to use Lua to enable it?

For experimentation, its currently enabled by default so you would have to use Lua to disable it in SciTE.

I’m unsure how much control is needed. If people want to control each facet then that could be implemented. If not, then turning selection.additional.typing on could be made to enable this behaviour.

Neil

[Neil Hodgson]

Since no one expressed a need for control over which of these commands will work over multiple selections, I have simplified the implementation to use the same setting as is used for additional typing: SCI_SETADDITIONALSELECTIONTYPING.

The attached patch also implements typing newlines into multiple selections.

Neil

[Neil Hodgson]

   This has now been committed as

http://sourceforge.net/p/scintilla/code/ci/ab7f836d3a26d5dff5783454a180275fb7329a9a/

   Available from the Mercurial repositories:

hg clone http://hg.code.sf.net/p/scintilla/code scintilla

hg clone http://hg.code.sf.net/p/scintilla/scite

   and from

http://www.scintilla.org/scite.zip  Source

http://www.scintilla.org/wscite.zip Windows executable

   Neil

[Teodor Petrov]

Hi,

I'm testing this new feature and I have some questions (in unspecified
order):
1. Is it expected that if I create multiple cursors with the ctrl+mouse
in scite 3.7.5,
these multiple cursors doesn't support these new features? Pressing
left arrow
removes all but the main cursor.
2. It seems undoing while there are multiple cursors also removes all
but the main
cursor. This is quite annoying and not very user friendly. Is this
a deliberate
decision or just it hasn't been implemented? Is it something that
is easy to
implement?
3. "Selection add next" is a useful feature, but sometimes it is useful
to have the
"selection skip next". Do you think this is something that should
be implemented
in scintilla or the application?
4. What about auto-completion? Can it be done to apply to all cursors?
Using the
selected item with the main cursor for example. Also can it be done
in the
application if you don't want to add this to scintilla itself?
5. Is there any way to create multiple cursors with the keyboard only?

Best regards,
Teodor

BTW: multi select paste is cool :)

[Neil Hodgson]

Teodor Petrov:

> 1. Is it expected that if I create multiple cursors with the ctrl+mouse in scite 3.7.5,
> these multiple cursors doesn't support these new features?

Should work. Perhaps you have changed settings.

> 2. It seems undoing while there are multiple cursors also removes all but the main
> cursor. This is quite annoying and not very user friendly. Is this a deliberate
> decision or just it hasn't been implemented? Is it something that is easy to
> implement?

It is not user friendly to trap people in a multiple selection mode they may not be aware of.

> 3. "Selection add next" is a useful feature, but sometimes it is useful to have the
> "selection skip next". Do you think this is something that should be implemented
> in scintilla or the application?

You should be able to implement this in a Lua script.

> 4. What about auto-completion? Can it be done to apply to all cursors? Using the
> selected item with the main cursor for example. Also can it be done in the
> application if you don't want to add this to scintilla itself?

See http://www.scintilla.org/ScintillaDoc.html#SCI_AUTOCSETMULTI

> 5. Is there any way to create multiple cursors with the keyboard only?

Neither Scintilla not SciTE implement any way to freely create multiple selections with the keyboard.

Neil

[Teodor Petrov]

Hello,

And thanks for the answers. I'll answer in separate posts to make the
discussion
a bit more focused and easier to follow.

On 07/05/2017 01:48 AM, Neil Hodgson wrote:
>> 4. What about auto-completion? Can it be done to apply to all cursors? Using the
>> selected item with the main cursor for example. Also can it be done in the
>> application if you don't want to add this to scintilla itself?
> See http://www.scintilla.org/ScintillaDoc.html#SCI_AUTOCSETMULTI

I've found this call yesterday, but it turns out we (Code::Blocks)
cannot us it. The reason is
that our list with completions doesn't contain just the function names
or variables names, but
we're adding type information. Our completion list might look like this:

var1 : int
var2 : float
myFunc() : int

So if I select var1 in the list using the scintilla's mechanisms I'll
end up with "var1 : int" in the
editor. Thus it seems we're inserting the text manually after we change
it using information
stored in our parser.
By looking at the documentation it doesn't seem possible to do it using
the auto completion
API's. Is this really the case? I'm looking at the SCN_AUTOCSELECTION,
but the
documentation doesn't state if I'm allowed to change the text. Is this
the case?

If it is not possible to use the scintilla's mechanisms for completion
then this is the second
case where I need to insert text and preserve multiple cursors. The
other is when we do
brace completions. When the user types any brace character ([{ we insert
the closing brace
and put the cursor between the two braces.

Can you explain what I need to do to preserve multiple cursors after I
programmatically modify
the document - insert or delete some text at multiple places? Is there a
calls for adding text to
the document that preserves multiple cursors?

Best regards,
Teodor

[Neil Hodgson]

Teodor:

> I've found this call yesterday, but it turns out we (Code::Blocks) cannot us it. The reason is
> that our list with completions doesn't contain just the function names or variables names, but
> we're adding type information.

> … By looking at the documentation it doesn't seem possible to do it using the auto completion

> API's. Is this really the case? I'm looking at the SCN_AUTOCSELECTION, but the
> documentation doesn't state if I'm allowed to change the text. Is this the case?

The text provided in the notification is read-only. You could start a mode with SCN_AUTOCSELECTION which ends with SCN_AUTOCCOMPLETED and call SCI_CHANGEINSERTION for every SC_MOD_INSERTCHECK when in that mode.

> Can you explain what I need to do to preserve multiple cursors after I programmatically modify
> the document - insert or delete some text at multiple places? Is there a calls for adding text to
> the document that preserves multiple cursors?

Loop for each selection: set target to selection then replace target.

Neil

[Teodor Petrov]

On 07/06/2017 01:01 AM, Neil Hodgson wrote:
> The text provided in the notification is read-only. You could start a
> mode with SCN_AUTOCSELECTION which ends with SCN_AUTOCCOMPLETED and
> call SCI_CHANGEINSERTION for every SC_MOD_INSERTCHECK when in that mode.

This looks harder to do, but I'll try it.

> Loop for each selection: set target to selection then replace target.

Thanks, this works well, so I'll use this. I've seen places in the code
where we're already
using it, but I'm new to scintilla, so I don't know all the neat tricks
one can do with it.

Thanks for the help,
Teodor

[Teodor Petrov]

On 07/05/2017 01:48 AM, Neil Hodgson wrote:

> Teodor Petrov:
>
>> 1. Is it expected that if I create multiple cursors with the ctrl+mouse in scite 3.7.5,
>> these multiple cursors doesn't support these new features?
> Should work. Perhaps you have changed settings.

These are my user settings:

buffers.zorder.switching=1
position.width=-1
position.height=-1
line.margin.visible=1
save.recent=1
tabsize=4
indent.size=4
use.tabs=1
selection.multiple=1
selection.additional.typing=1
selection.multipaste=1
indent.opening=1
indent.closing=1
check.if.already.open=1
highlight.current.word=1

And these are the exact steps to reproduce the problem:
0. create new file
1. type something, for example 'test' without quotes
2. ctrl-d several times to duplicate the line
3. create multiple cursors using ctrl+mouse left; I create the cursors
at the end of the test words
4. use left arrow key to move the cursors one character to the left

What I see after step 4 is that there is only one cursor left in the
editor. The left-arrow key works similarly
to the escape key - it cancels the multi-cursor mode.

Using the steps below, I don't see the above problem:
0. create new file
1. type something, for example 'test' without quotes
2. ctrl-d several times to duplicate the line
3. create multiple cursors using ctrl+shift+d to select all duplicated
words created in step 2
4. use left arrow key to move the cursors one character to the left

This problem happens in both scite 3.7.5 and codeblocks using
wxscintilla updated to 3.7.5

Best regards,
Teodor

[Neil Hodgson]

Teodor Petrov:

> And these are the exact steps to reproduce the problem:
> 0. create new file
> 1. type something, for example 'test' without quotes
> 2. ctrl-d several times to duplicate the line
> 3. create multiple cursors using ctrl+mouse left; I create the cursors at the end of the test words
> 4. use left arrow key to move the cursors one character to the left
>
> What I see after step 4 is that there is only one cursor left in the editor. The left-arrow key works similarly
> to the escape key - it cancels the multi-cursor mode.

I’m not seeing this with SciTE on Windows, GTK+/Linux, or macOS.

You could try using a debugger and placing a breakpoint on Selection::DropAdditionalRanges to find where this is occurring.

> Using the steps below, I don't see the above problem:
> 0. create new file
> 1. type something, for example 'test' without quotes
> 2. ctrl-d several times to duplicate the line
> 3. create multiple cursors using ctrl+shift+d to select all duplicated words created in step 2
> 4. use left arrow key to move the cursors one character to the left

This should be very similar to the first case but with non-empty selections initially. After the first left arrow, it should be the same as the first case.

Neil

[Teodor Petrov]

On 07/07/2017 01:24 AM, Neil Hodgson wrote:
> Teodor Petrov:
>
>> And these are the exact steps to reproduce the problem:
>> 0. create new file
>> 1. type something, for example 'test' without quotes
>> 2. ctrl-d several times to duplicate the line
>> 3. create multiple cursors using ctrl+mouse left; I create the cursors at the end of the test words
>> 4. use left arrow key to move the cursors one character to the left
>>
>> What I see after step 4 is that there is only one cursor left in the editor. The left-arrow key works similarly
>> to the escape key - it cancels the multi-cursor mode.
> I’m not seeing this with SciTE on Windows, GTK+/Linux, or macOS.

I'm using: SciTE Version 3.7.5 compiled for GTK+ 2.24.31 Jul 2 2017
18:22:37
And this is on gentoo linux using almost system provided ebuild (recipe
file used to build the file).
Also I'm using enlightenment as my wm.

> You could try using a debugger and placing a breakpoint on Selection::DropAdditionalRanges to find where this is occurring.

This function is called only when escape is pressed. It is not called at
step 4 in the first case described above.
Something else is removing my cursors. Any suggestions where else to put
breakpoints?

Do you want me to record a video with the above steps to see what is
happening?

/Teodor

[Neil Hodgson]

Teodor Petrov:

> I'm using: SciTE Version 3.7.5 compiled for GTK+ 2.24.31 Jul 2 2017 18:22:37
> And this is on gentoo linux using almost system provided ebuild (recipe file used to build the file).
> Also I'm using enlightenment as my wm.

On GTK+, Ctrl+Click is normally mapped to rectangular selection but that would have meant no extra carets. If you only have one caret at the end of step 3 then that is the issue and you should set rectangular.selection.modifier.

> Do you want me to record a video with the above steps to see what is happening?

Yes, if the above isn’t the issue.

Neil

[Teodor Petrov]

On Fri, Jul 7, 2017 at 2:07 AM, Neil Hodgson <nyama...@me.com> wrote:
> Teodor Petrov:
>
>> I'm using: SciTE Version 3.7.5 compiled for GTK+ 2.24.31 Jul 2 2017 18:22:37
>> And this is on gentoo linux using almost system provided ebuild (recipe file used to build the file).
>> Also I'm using enlightenment as my wm.
>
> On GTK+, Ctrl+Click is normally mapped to rectangular selection but that would have meant no extra carets. If you only have one caret at the end of step 3 then that is the issue and you should set rectangular.selection.modifier.

I have multiple carets at the end of step 3 in both cases, but step 4
behaves differently.
At this link: https://vimeo.com/224612144 you can see the broken case.
Unfortunately the software that printed pressed keys didn't work
during recording.
But I use ctrl while making the selection and left arrow when the
cursors disappear.

Best regards,
Teodor

[Neil Hodgson]

Teodor Petrov:

>> On GTK+, Ctrl+Click is normally mapped to rectangular selection but that would have meant no extra carets. If you only have one caret at the end of step 3 then that is the issue and you should set rectangular.selection.modifier.
>
> I have multiple carets at the end of step 3 in both cases

I think you have a rectangular selection. Change rectangular.selection.modifier, perhaps to 8 (Super), and try Ctrl+Click again.

Neil

[Teodor Petrov]

On Saturday, July 8, 2017 at 1:28:20 AM UTC+3, Neil Hodgson wrote:

Teodor Petrov:

   I think you have a rectangular selection. Change rectangular.selection.modifier, perhaps to 8 (Super), and try Ctrl+Click again.

Yes, this is rectangular selection that allows typing. So are you saying that it is different

from multiple cursors? If this is the case can you explain the reason/rationale for this

behaviour? I as a user see multiple cursors on the screen, I can type and all cursors 

produce the same characters, so I expect that the cursor movement will work, too, but it

doesn't.

/Teodor

[Neil Hodgson]

Teodor:

> Yes, this is rectangular selection that allows typing. So are you saying that it is different
> from multiple cursors?

There are 2 concepts here: rectangular selection is where you select a single rectangle of text and multiple selection where you select multiple pieces of text which may not be in a single rectangle. Rectangular selection was implemented early in Scintilla’s history and multiple selection much later.

When multiple selection was added, I was hopeful that it could be a superset of rectangular selection but did not prove possible as there is additional functionality possible with rectangular selections. One of the stronger features is that rectangular copies are pasted preserving the rectangularity. This rectangular paste even occurs into other applications on Windows where there are conventions for this.

> If this is the case can you explain the reason/rationale for this
> behaviour? I as a user see multiple cursors on the screen, I can type and all cursors
> produce the same characters, so I expect that the cursor movement will work, too, but it
> doesn’t.

Some changes could be made to rectangular mode behaviour but there will be many details, such as line start/end behaviour for right/left arrow and whether there is a decay from rectangular- to multiple-selection.

A visual indication of rectangular selection could be added to make it more identifiable, perhaps horizontal bars at the top/bottom of a rectangular selection to appear like ‘I’ (with serifs) or a thin (3-pixel) rectangular frame.

If you really want only a single concept of multiple selection then it may be possible to add a mode in which rectangular-specific functionality is suppressed.

Neil

[Teodor Petrov]

On 07/09/2017 02:56 AM, Neil Hodgson wrote:
> Some changes could be made to rectangular mode behaviour but there will be many details, such as line start/end behaviour for right/left arrow and whether there is a decay from rectangular- to multiple-selection.
>
> A visual indication of rectangular selection could be added to make it more identifiable, perhaps horizontal bars at the top/bottom of a rectangular selection to appear like ‘I’ (with serifs) or a thin (3-pixel) rectangular frame.
>
> If you really want only a single concept of multiple selection then it may be possible to add a mode in which rectangular-specific functionality is suppressed.

I'm not really sure if we (code::blocks) want to have only multiple
selections. I guess it is useful to have rectangular
selections, but I personally have never used the copy-paste feature, I
think. I don't find it useful, but I can't tell or decide
for the others. For my coding task multiple-cursors seems the more
useful feature.

For me it seems safe to decay to multiple-cursors mode if the user does
manipulations (types something, deletes
something, moves the cursor) when in rectangular selection mode. I guess
we could modify the copy-paste code to
check if the multiple cursor selections form rectangular block of text
(for most cases) and then emulate this feature.

How hard would it be to implement this decaying to multiple cursors?

BTW: I've just tried your suggestion (from an earlier mail) to set the
rect selection modifier to 8 and test again. I don't
think this mode is user-friendly. To create multiple cursors I have to
ctrl-click multiple times. If I ctrl-click-drag down
vertically I don't get multiple cursors, but I change the selection.

Best regards,
Teodor

[Neil Hodgson]

Teodor:

> For me it seems safe to decay to multiple-cursors mode if the user does manipulations (types something, deletes
> something, moves the cursor) when in rectangular selection mode.

For keyboard rectangular selection there is no distinct end event so it can’t be done then. So there would have to be code added to each of the above mentioned operations to set sel.selType to selStream.

> I guess we could modify the copy-paste code to
> check if the multiple cursor selections form rectangular block of text (for most cases) and then emulate this feature.

Not simple in the presence of tabs or proportional text.

> How hard would it be to implement this decaying to multiple cursors?

A few hours then occasional bug fixes as unexpected corner cases are uncovered.

> BTW: I've just tried your suggestion (from an earlier mail) to set the rect selection modifier to 8 and test again. I don't
> think this mode is user-friendly. To create multiple cursors I have to ctrl-click multiple times. If I ctrl-click-drag down
> vertically I don't get multiple cursors, but I change the selection.

With rectangular.selection.modifier=8, it should be possible to do what you want with <Super>+drag.

Neil

[Lex Trotman]

On 10 July 2017 at 10:04, Neil Hodgson <nyama...@me.com> wrote:
> Teodor:
>
>> For me it seems safe to decay to multiple-cursors mode if the user does manipulations (types something, deletes
>> something, moves the cursor) when in rectangular selection mode.

The change would have to be optional or applications that do not
support multiple cursors would lose significant functionality.

>
> For keyboard rectangular selection there is no distinct end event so it can’t be done then. So there would have to be code added to each of the above mentioned operations to set sel.selType to selStream.
>
>> I guess we could modify the copy-paste code to
>> check if the multiple cursor selections form rectangular block of text (for most cases) and then emulate this feature.
>
> Not simple in the presence of tabs or proportional text.
>
>> How hard would it be to implement this decaying to multiple cursors?
>
> A few hours then occasional bug fixes as unexpected corner cases are uncovered.
>
>> BTW: I've just tried your suggestion (from an earlier mail) to set the rect selection modifier to 8 and test again. I don't
>> think this mode is user-friendly. To create multiple cursors I have to ctrl-click multiple times. If I ctrl-click-drag down
>> vertically I don't get multiple cursors, but I change the selection.
>
> With rectangular.selection.modifier=8, it should be possible to do what you want with <Super>+drag.
>
> Neil
>

> --
> You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.
> To post to this group, send email to scintilla...@googlegroups.com.
> Visit this group at https://groups.google.com/group/scintilla-interest.
> For more options, visit https://groups.google.com/d/optout.

[Neil Hodgson]

With Fedora 25 and 26 (possibly earlier), the Alt key is available for mouse dragging in applications and thus rectangular selection in Scintilla. The modifier key used for rectangular selection on GTK+ was made an option with Ctrl as the default when some Linux desktop environments took over Alt+Drag for moving windows. I thought this was poor behaviour by the desktop environments as windows could be moved by dragging their title bars and it denied applications from receiving the Alt+Drags.

Current Ubuntu uses Unity which intercepts Alt+Drag but Ubuntu is replacing Unity with GNOME (as used by Fedora) in future releases.

Since Alt+Drag is used for rectangular selection on Windows and macOS, it should be the default on GTK+/Linux as well. The choice of rectangular selection modifier would still be available for other Linux desktops which capture Alt+Drag.

Neil

[Neil Hodgson]

> Since Alt+Drag is used for rectangular selection on Windows and macOS, it should be the default on GTK+/Linux as well. The choice of rectangular selection modifier would still be available for other Linux desktops which capture Alt+Drag.

This change has been committed along with a similar change to Qt on Linux.
https://sourceforge.net/p/scintilla/code/ci/ea9f62ea6153302a471d97fb83b0a7e1d8d81504/

Neil

[Matthew Brush]

Isn't Alt+drag captured by every X11 window manager? I've only used 4 or
5 different ones, but they all did, and I assumed this was standard
behaviour on X11.

Regards,
Matthew Brush

[Neil Hodgson]

Matthew Brush:

> Isn't Alt+drag captured by every X11 window manager? I've only used 4 or 5 different ones, but they all did, and I assumed this was standard behaviour on X11.

Alt+drag is not captured by the window manager used with current GNOME which I think is Mutter.

On Metacity it used to be possible to switch modifiers from a control panel but that disappeared although I expect there is still a config element somewhere that can be tweaked.

Applications can set Scintilla's rectangular selection modifier to Ctrl if they want to allow for other window managers but that will stop the user from directly creating multiple selections. It also led to the confusion at the start of this thread.

Rectangular selection can be performed through the keyboard but multiple selection can not. So having Ctrl owned by rectangular selection means that the user can not create multiple selections.

Its possible to set the modifier to Super (commonly the Windows key) but that is not the common binding for rectangular selection. The Super key is, generally, more strongly bound to system than application behaviour.

Neil

[Teodor Petrov]

On 07/10/2017 03:04 AM, Neil Hodgson wrote:
>> How hard would it be to implement this decaying to multiple cursors?
> A few hours then occasional bug fixes as unexpected corner cases are uncovered.

Hello again,

I've played a bit with the decaying feature. I've implemented most of
the behaviours
I could think of. See the attached patch. It applies on the longterm3
branch with
the patch -p6 < my.diff command.

The next step is to implement an option which allows users
enable/disable this
feature. Can you guide me about it? Where should I put it? How to name
it? What
should the semantics be?

For now I'm working on the longterm3 branch, but when the feature is
finalized I
could rework the patch to work with the main branch.

Best regards,
Teodor Petrov

[Neil Hodgson]

Teodor Petrov:

> The next step is to implement an option which allows users enable/disable this
> feature. Can you guide me about it? Where should I put it? How to name it? What
> should the semantics be?

Start from a similar example like SetAdditionalSelectionTyping and its Get* counterpart in include/Scintilla.iface and trace it through to SCI_ API implemented in Editor.

Names are difficult to make succinct yet understandable. Maybe something like “SelectionRectangularDecayToMultiple”. Explain more comprehensively in the documentation.

Default setting should be to behave like the current version.

Neil

[Teodor Petrov]

Hello,

Have you tried the patch? Am I missing some case? I've handled the most
obvious.
I'm not sure what should happens on page up/down.

On 08/18/2017 01:07 PM, Neil Hodgson wrote:
> Start from a similar example like SetAdditionalSelectionTyping and its Get* counterpart in include/Scintilla.iface and trace it through to SCI_ API implemented in Editor.
>
> Names are difficult to make succinct yet understandable. Maybe something like “SelectionRectangularDecayToMultiple”. Explain more comprehensively in the documentation.

I'll do this and post another patch.

> Default setting should be to behave like the current version.

Of course.

Best regards,
Teodor

[Neil Hodgson]

Teodor Petrov:

> Have you tried the patch? Am I missing some case? I've handled the most obvious.

Horizontal and vertical movement, such as cursor left or up, do not decay to multiple carets if additionalSelectionTyping is on. This makes rectangular selection *more* sticky. With tabs or proportional fonts, this can lead to multiple carets that do not line up but are still marked rectangular in the code leading to more weirdness.

To convert the selection from rectangular to multiple, sel.selType should be set to Selection::selStream like you have done in NewLine.

> I'm not sure what should happens on page up/down.

Page up/down currently converts to a simple selection.

Neil

[Teodor Petrov]

Hello again,

I've made an attempt to improve the change. See the attached patch.

Changes from previous patch:
1. Decay to multiple selections when movements are done.
2. Add support for expanding multiple selections with alt-shift-up/down.
3. Add an option and try to preserve current behaviour with the default
value.
4. When the selection is cancelled always force a stream selection.

The patch is made against the longterm3 branch but it applies against the
master/default if you update the ids for the new option.

At the moment there are 3 problems:
1. Inserting new lines from multiple cursors and auto-indenters doesn't
play well.
   The auto-indenter in codeblocks is totally broken in this new mode.
The auto-
   indenter in scite seems to disable itself and does nothing. The
problem is that
   there is no easy way to find what is the position of the current
addition in the
   char added event. Can we set the position of the addition in the
notification
   structure? Or even set a range?
2. The new multiple cursor creation with alt-shift-up/down doesn't work
when the
    selection is not empty. It just creates new cursor, but this looks
strange. Should
    we drop all selections in multi-cursor-mode? Should we try to
select x-characters
    back (on the left) of the cursor?
3. This new option would do strange things if additionalSelectionTyping
is not
    enabled. Should I test this case? Should I try to prevent it somehow?

Feedback is welcome.

Best regards,
Teodor

[Neil Hodgson]

Teodor Petrov:

> Changes from previous patch:
> 1. Decay to multiple selections when movements are done.
> 2. Add support for expanding multiple selections with alt-shift-up/down.

The change in CursorUpOrDown repeats the first and last line on both branches of the conditional. When I see something like this I expect there is a difference I’m not noticing and stare at the code for far too long.

> 3. Add an option and try to preserve current behaviour with the default value.
> 4. When the selection is cancelled always force a stream selection.

Needs documentation.

> 1. Inserting new lines from multiple cursors and auto-indenters doesn't play well.
> The auto-indenter in codeblocks is totally broken in this new mode. The auto-
> indenter in scite seems to disable itself and does nothing. The problem is that
> there is no easy way to find what is the position of the current addition in the
> char added event. Can we set the position of the addition in the notification
> structure? Or even set a range?

At the point that the application receives this, all the modifications have been made and the set of carets can be used. SciTE just works on the primary caret. The position could be pushed in the SCN_CHARADDED event but note that the set of successful new line insertions has been forgotten at this point. New line insertion failures can be from application refusal or read-only mode and may expand in the future.

> 2. The new multiple cursor creation with alt-shift-up/down doesn't work when the
> selection is not empty. It just creates new cursor, but this looks strange. Should
> we drop all selections in multi-cursor-mode? Should we try to select x-characters
> back (on the left) of the cursor?

For me pressing Shift+Right then Shift+Alt+Down creates a rectangular selection 2 lines high and one character wide.

> 3. This new option would do strange things if additionalSelectionTyping is not
> enabled. Should I test this case? Should I try to prevent it somehow?

It should be documented as requiring additionalSelectionTyping.

Neil

[Teodor Petrov]

On 01/02/2018 07:04 AM, Neil Hodgson wrote:
> Teodor Petrov:
>
>> Changes from previous patch:
>> 1. Decay to multiple selections when movements are done.
>> 2. Add support for expanding multiple selections with alt-shift-up/down.
> The change in CursorUpOrDown repeats the first and last line on both branches of the conditional. When I see something like this I expect there is a difference I’m not noticing and stare at the code for far too long.

I can fix this, but we need to clarify the final behaviour.

>> 3. Add an option and try to preserve current behaviour with the default value.
>> 4. When the selection is cancelled always force a stream selection.
> Needs documentation.

Which file should I modify?

>> 1. Inserting new lines from multiple cursors and auto-indenters doesn't play well.
>> The auto-indenter in codeblocks is totally broken in this new mode. The auto-
>> indenter in scite seems to disable itself and does nothing. The problem is that
>> there is no easy way to find what is the position of the current addition in the
>> char added event. Can we set the position of the addition in the notification
>> structure? Or even set a range?
> At the point that the application receives this, all the modifications have been made and the set of carets can be used. SciTE just works on the primary caret. The position could be pushed in the SCN_CHARADDED event but note that the set of successful new line insertions has been forgotten at this point.

I'm a bit perplexed about SCN_CHARADDED's behaviour, because if there
are multiple
cursors and the user types something the notification is sent once, but
if he/she presses
enter it is sent multiple times. Can you explain why this happens?

> New line insertion failures can be from application refusal or read-only mode and may expand in the future.

Can you clarify this , because I'm not sure I understand?

>> 2. The new multiple cursor creation with alt-shift-up/down doesn't work when the
>> selection is not empty. It just creates new cursor, but this looks strange. Should
>> we drop all selections in multi-cursor-mode? Should we try to select x-characters
>> back (on the left) of the cursor?
> For me pressing Shift+Right then Shift+Alt+Down creates a rectangular selection 2 lines high and one character wide.

Now start with multiple cursors and multiple selections and you'll see
the problem. The
more I think about it the more I'm convinced that we should drop all
selections in this case.

>> 3. This new option would do strange things if additionalSelectionTyping is not
>> enabled. Should I test this case? Should I try to prevent it somehow?
> It should be documented as requiring additionalSelectionTyping.

Same as the other: which file should I modify.

/Teodor

[Neil Hodgson]

Teodor Petrov:

>> Needs documentation.
>
> Which file should I modify?

doc/ScintillaDoc.html

> I'm a bit perplexed about SCN_CHARADDED's behaviour, because if there are multiple
> cursors and the user types something the notification is sent once, but if he/she presses
> enter it is sent multiple times. Can you explain why this happens?

I can’t recall the reasoning here. New lines are often a trigger and the intention may have been to ensure all lines are triggered but that would require more context.

>> New line insertion failures can be from application refusal or read-only mode and may expand in the future.
>
> Can you clarify this , because I'm not sure I understand?

The application can refuse an insertion through the SC_MOD_INSERTCHECK mechanism. Say your application has sections edited through some other tool like a GUI designer and it does not want user additions in that text. If the application refuses addition of one new line out of a multiple-selection set then that should not be reported.

> Now start with multiple cursors and multiple selections and you'll see the problem. The
> more I think about it the more I'm convinced that we should drop all selections in this case.

I’d more expect that the non-main selections would be dropped but the main selection would be extended just as it is when there are no other selections initially.

Neil

[Teodor Petrov]

On 01/02/2018 07:04 AM, Neil Hodgson wrote:
> Teodor Petrov:
>
>> Changes from previous patch:
>> 1. Decay to multiple selections when movements are done.
>> 2. Add support for expanding multiple selections with alt-shift-up/down.
> The change in CursorUpOrDown repeats the first and last line on both branches of the conditional. When I see something like this I expect there is a difference I’m not noticing and stare at the code for far too long.

See the attached patch with a fix. This patch should be applied over the
previous patch.

>
>> 2. The new multiple cursor creation with alt-shift-up/down doesn't work when the
>> selection is not empty. It just creates new cursor, but this looks strange. Should
>> we drop all selections in multi-cursor-mode? Should we try to select x-characters
>> back (on the left) of the cursor?
> For me pressing Shift+Right then Shift+Alt+Down creates a rectangular selection 2 lines high and one character wide.
>

The attached patch has 4 variants which improve this feature. I think, I
like variant 3 the most,
because it is the smartest. What do you think? And how to make variant 3
work well with
virtual space? At the moment if there is a shorter line it will create a
longer selection for this
line.

Best regards,
Teodor

[Teodor Petrov]

On 01/05/2018 12:08 PM, Neil Hodgson wrote:
>> I'm a bit perplexed about SCN_CHARADDED's behaviour, because if there are multiple
>> cursors and the user types something the notification is sent once, but if he/she presses
>> enter it is sent multiple times. Can you explain why this happens?
> I can’t recall the reasoning here. New lines are often a trigger and the intention may have been to ensure all lines are triggered but that would require more context.

I don't understand the meaning of trigger here. Can you try to explain
it better?

>>> New line insertion failures can be from application refusal or read-only mode and may expand in the future.
>> Can you clarify this , because I'm not sure I understand?
> The application can refuse an insertion through the SC_MOD_INSERTCHECK mechanism. Say your application has sections edited through some other tool like a GUI designer and it does not want user additions in that text. If the application refuses addition of one new line out of a multiple-selection set then that should not be reported.

So, do you have any suggestions how an application can implement
auto-indent for multiple cursors
and multiple new lines inserted with a single press of the enter key?

Best regards,
Teodor

[Neil Hodgson]

Teodor Petrov:

> The attached patch has 4 variants which improve this feature. I think, I like variant 3 the most,
> because it is the smartest.

1 and 3 are more likely to align with user expectations. My preference would be to minimize cleverness with variant 1 but its your feature.

Selection positions are measured in bytes so using x.caret.Position() - x.anchor.Position() is a byte length and subtracting this from another position may lead to character slicing for multi-byte characters. The minimum required here is to force the result to an inter-character boundary with MovePositionOutsideChar. Possibly also ClampPositionIntoDocument as we don’t want selections to go outside the document and avoiding invisible text. See Editor::MovePositionSoVisible and test with some multibyte characters like 開.

Also check with backwards selections as the subtraction then becomes an addition and may go past the line end. Another thing you may want is to count characters instead of bytes with the Document methods CountCharacters and GetRelativePosition.

> What do you think? And how to make variant 3 work well with
> virtual space? At the moment if there is a shorter line it will create a longer selection for this
> line.

I couldn’t find any similar code as rectangular selections use pixels for determining where the end of the selection goes and whether it is in virtual space. Likely requires writing some new code that handles the various possibilities here with some character movement used up within the line then some as virtual space.

>> I can’t recall the reasoning here. New lines are often a trigger and the intention may have been to ensure all lines are triggered but that would require more context.
>
> I don't understand the meaning of trigger here. Can you try to explain it better?

Automatic indentation and other features are performed (‘triggered’) when some event from Scintilla is sent to the application.

> So, do you have any suggestions how an application can implement auto-indent for multiple cursors
> and multiple new lines inserted with a single press of the enter key?

I haven’t implemented this so haven’t really examined it. Start by writing a loop over SCI_GETSELECTIONS / SCI_GETSELECTIONNCARET performing whatever indentation you want.

Neil

[Teodor Petrov]

On 01/10/2018 01:54 AM, Neil Hodgson wrote:
> Teodor Petrov:
>
>> The attached patch has 4 variants which improve this feature. I think, I like variant 3 the most,
>> because it is the smartest.
> 1 and 3 are more likely to align with user expectations. My preference would be to minimize cleverness with variant 1 but its your feature.

I'll try to make 3 work. It is not more complex then 1 because they only
differ in the last part.

> Selection positions are measured in bytes so using x.caret.Position() - x.anchor.Position() is a byte length and subtracting this from another position may lead to character slicing for multi-byte characters. The minimum required here is to force the result to an inter-character boundary with MovePositionOutsideChar. Possibly also ClampPositionIntoDocument as we don’t want selections to go outside the document and avoiding invisible text. See Editor::MovePositionSoVisible and test with some multibyte characters like 開.
>
> Also check with backwards selections as the subtraction then becomes an addition and may go past the line end. Another thing you may want is to count characters instead of bytes with the Document methods CountCharacters and GetRelativePosition.

Thanks for the suggestions, I'll see what I can do about them.

>> What do you think? And how to make variant 3 work well with
>> virtual space? At the moment if there is a shorter line it will create a longer selection for this
>> line.
> I couldn’t find any similar code as rectangular selections use pixels for determining where the end of the selection goes and whether it is in virtual space. Likely requires writing some new code that handles the various possibilities here with some character movement used up within the line then some as virtual space.

Is there anywhere an explanation what is virtual space and how it works?
I saw that there is a
second member for this in the SelectionPosition objects, but I'm not
100% sure how it works.

> Automatic indentation and other features are performed (‘triggered’) when some event from Scintilla is sent to the application.

Now it is clear. Thanks.

>> So, do you have any suggestions how an application can implement auto-indent for multiple cursors
>> and multiple new lines inserted with a single press of the enter key?
> I haven’t implemented this so haven’t really examined it. Start by writing a loop over SCI_GETSELECTIONS / SCI_GETSELECTIONNCARET performing whatever indentation you want.

Which notification should I use? SCN_CHARADDED is not good, because it
is sent multiple
times from Editor::NewLine. I could probably check if the indentation is
already done and skip
it for the duplicated notifications, but this might be error prone. I
could store the cursor index in
the notification, but I'm not sure if the data will be intact after I
add my indention strings.

/Teodor

[Teodor Petrov]

On 01/10/2018 02:36 AM, Teodor Petrov wrote:
> On 01/10/2018 01:54 AM, Neil Hodgson wrote:
>>     I couldn’t find any similar code as rectangular selections use
>> pixels for determining where the end of the selection goes and
>> whether it is in virtual space. Likely requires writing some new code
>> that handles the various possibilities here with some character
>> movement used up within the line then some as virtual space.
>
> Is there anywhere an explanation what is virtual space and how it
> works? I saw that there is a
> second member for this in the SelectionPosition objects, but I'm not
> 100% sure how it works.

I don't need the explanation for virtual space any more. The explanation
how rect selection works
helped me realize I can use the same code for the anchor. So doing:

#elif VARIANT==4
            const SelectionPosition posNewAnchor =
MovePositionSoVisible(
                PositionUpOrDown(rangeBase.anchor, direction, -1),
direction);

            sel.AddSelection(SelectionRange(posNew, posNewAnchor));
#endif // VARIANT

makes the feature work really well for all cases I could think of. :)

/Teodor

[Neil Hodgson]

Teodor Petrov:

> Which notification should I use? SCN_CHARADDED is not good, because it is sent multiple
> times from Editor::NewLine. I could probably check if the indentation is already done and skip
> it for the duplicated notifications, but this might be error prone.

SCN_CHARADDED is the best notification to use. Indentation code should be stable and produce the same result even if applied multiple times.

> I could store the cursor index in
> the notification, but I'm not sure if the data will be intact after I add my indention strings.

Adding selection index or position to SCN_CHARADDED is possible but that expands the scope of this change and may be more complex.

> I don't need the explanation for virtual space any more. The explanation how rect selection works
> helped me realize I can use the same code for the anchor. So doing:
>
> #elif VARIANT==4
> const SelectionPosition posNewAnchor =
> MovePositionSoVisible(
> PositionUpOrDown(rangeBase.anchor, direction, -1),
> direction);
>
> sel.AddSelection(SelectionRange(posNew, posNewAnchor));
> #endif // VARIANT
>
> makes the feature work really well for all cases I could think of. :)

OK.

Allowing a negative lastX parameter to PositionUpOrDown really should have been documented.

Neil

[Teodor Petrov]

On 01/11/2018 05:56 AM, Neil Hodgson wrote:
> Teodor Petrov:
>
>> Which notification should I use? SCN_CHARADDED is not good, because it is sent multiple
>> times from Editor::NewLine. I could probably check if the indentation is already done and skip
>> it for the duplicated notifications, but this might be error prone.
> SCN_CHARADDED is the best notification to use. Indentation code should be stable and produce the same result even if applied multiple times.

Yep, I've added a check if the indentation is already correct and now I
do not apply it again.
This solves the problem. The only problem left for solving is that if I
have 1000 cursors and
press enter the notification will be sent 1000*1000 times, which won't
be fast and all
1000*1000-1 notifications will cause waste of time and resources. So an
improvement is
desired here.

>> I could store the cursor index in
>> the notification, but I'm not sure if the data will be intact after I add my indention strings.
> Adding selection index or position to SCN_CHARADDED is possible but that expands the scope of this change and may be more complex.

I'll leave it for now.

>> I don't need the explanation for virtual space any more. The explanation how rect selection works
>> helped me realize I can use the same code for the anchor. So doing:
>>
>> #elif VARIANT==4
>> const SelectionPosition posNewAnchor =
>> MovePositionSoVisible(
>> PositionUpOrDown(rangeBase.anchor, direction, -1),
>> direction);
>>
>> sel.AddSelection(SelectionRange(posNew, posNewAnchor));
>> #endif // VARIANT
>>
>> makes the feature work really well for all cases I could think of. :)
> OK.

Do you like this version? Do you see possible problems with it?

> Allowing a negative lastX parameter to PositionUpOrDown really should have been documented.

Do I need to do something about this?

And finally: I'll try to see if I can fix our brace completion code to
work with multiple cursors and
then I'll post a final patch. Do you prefer a set of patches or a single
monolithic one?

/Teodor

[Neil Hodgson]

Teodor Petrov:

> Do you like this version? Do you see possible problems with it?

I haven’t seen any problems with it.

> Do I need to do something about this?

No.

> And finally: I'll try to see if I can fix our brace completion code to work with multiple cursors and
> then I'll post a final patch. Do you prefer a set of patches or a single monolithic one?

Patch sets should cleanly do one thing. Do not send multiple patch sets when they are just documenting your history.

Neil

[Teodor Petrov]

Hello,

See the "final" version of the patch attached. It seems the code is now
usable.
The latest addition is support for horizontal extend-rect commands in
the new
mode, some requested documentation additions and clean up.

To be frank I'm not 100% sure I like how all this turned out in the end.
From the
user's point of view the feature will just works, but underneath it is
not 100%
clear when you'll get a rectangular selection and when you'll get
multiple cursors.
So it is a bit confusing. For the users it might be confusing, too,
because they
might not know when they have rect-selection which is copy-paste-able
and when
they don't have it.

Let me know what you think. The patch is made against the default
branch. But
it works with the 3.x branch, so if it is easy I'll be happy if it is
committed there, too.

Best regards,
Teodor

[Neil Hodgson]

Teodor Petrov:

> See the "final" version of the patch attached. It seems the code is now usable.
> The latest addition is support for horizontal extend-rect commands in the new
> mode, some requested documentation additions and clean up.

Appears OK.

> To be frank I'm not 100% sure I like how all this turned out in the end. From the
> user's point of view the feature will just works, but underneath it is not 100%
> clear when you'll get a rectangular selection and when you'll get multiple cursors.

While I understand why some will want this change, I don’t like it myself.

The code changes add to complexity and may not be understood completely by others maintaining or adding features to selection.

> So it is a bit confusing. For the users it might be confusing, too, because they
> might not know when they have rect-selection which is copy-paste-able and when
> they don't have it.

The “Rectangular Caret” thread contains some ideas for making this more visible.

Neil

[Teodor Petrov]

On 01/16/2018 09:17 AM, Neil Hodgson wrote:
> While I understand why some will want this change, I don’t like it myself.
>
> The code changes add to complexity and may not be understood completely by others maintaining or adding features to selection.

If you have ideas how to minimize complexity, I'll be happy to try them.
Also, is there a way to write regression tests for this thing?

>> So it is a bit confusing. For the users it might be confusing, too, because they
>> might not know when they have rect-selection which is copy-paste-able and when
>> they don't have it.
> The “Rectangular Caret” thread contains some ideas for making this more visible.

I saw it, but I don't like it.

/Teodor

[Neil Hodgson]

Teodor Petrov:

> Also, is there a way to write regression tests for this thing?

The test script that should be extended for this type of feature is scintilla/test/simpleTests.py .

Neil

[Teodor Petrov]

Is the only way to run it to build the qt module for pyside?
I'm running linux if this matters. Getting it built seems rather
complicated. :(

/Teodor

[Neil Hodgson]

Teodor Petrov:

> Is the only way to run it to build the qt module for pyside?
> I'm running linux if this matters. Getting it built seems rather complicated. :(

You should be able to download the PySide and Qt dependencies through your distribution’s package manager. See the comments at the top of scite/scripts/checkbuildlinux.sh for some lists of packages that may help although package names do sometimes change. Running checkbuildlinux.sh is also worthwhile for checking any changes although it does take a while and the last stage, cppcheck, shows spurious warnings.

After that you do have to build Scintilla for PySide. It would be great to support testing with GTK+ but someone would have to get that working.

Neil

[Teodor Petrov]

On 01/19/2018 12:46 AM, Neil Hodgson wrote:
>
> After that you do have to build Scintilla for PySide. It would be great to support testing with GTK+ but someone would have to get that working.

This is the part I was talking about, I have qt and probably pyside.
The multiple-step requirement for building everything bother me at the
moment...
So this will way a bit...

/Teodor

[Neil Hodgson]

Teodor Petrov:

> This is the part I was talking about, I have qt and probably pyside.
> The multiple-step requirement for building everything bother me at the moment...

> So this will way a bit…

I’m reasonably happy to accept this without tests if tests are too much trouble and you think the most recent patch is OK.

Neil

[Teodor Petrov]

> On 31 Jan 2018, at 7:15, Neil Hodgson <nyama...@me.com> wrote:
>
> I’m reasonably happy to accept this without tests if tests are too much trouble and you think the most recent patch is OK.

Are there any tests for the rectangular selections in the test suite? If there are I could try to add tests...

About stability - what I’ve tested worked, but I’m not using this patch daily yet, so I don’t know if there aren’t any hidden bugs.

/Teodor

[Neil Hodgson]

Teodor Petrov:

> Are there any tests for the rectangular selections in the test suite? If there are I could try to add tests…

In test/simpleTests.py, the 3 methods that start with “testRectangular” are testing rectangular selection.

Neil

[Teodor Petrov]

I'm getting this error:

$ python simpleTests.py
Traceback (most recent call last):
  File "simpleTests.py", line 12, in <module>
    import XiteQt as Xite
  File "/home/obfuscated/projects/libs/scintilla/test/XiteQt.py",
line 12, in <module>
    from bin import ScintillaEditPy
ImportError: ../bin/ScintillaEditPy.so: undefined symbol: SbkObject_Type

Any idea what is going on wrong here? I've run the scripts mentioned in
the docs,
I had to adjust the Makefiles here and there to add -std=c++11, but
other than that
everything built fine.

/Teodor

[Neil Hodgson]

Teodor Petrov:

> ImportError: ../bin/ScintillaEditPy.so: undefined symbol: SbkObject_Type
>
> Any idea what is going on wrong here?

SbkObject is from Shiboken which handles calling C++ from Python. Check that you have a Shiboken library installed as well as a Shiboken dev library. Try the normal .so checks - does the Shiboken shared library contain SbkObject_Type and can the Shiboken shared library be loaded.

Scintilla uses the original PySide. PySide2 is under development and I don’t think it is ready yet.

Some people split PySide's components up differently and its possible this was published in some Linux distributions. I check with current Fedora and Ubuntu.

> I've run the scripts mentioned in the docs,
> I had to adjust the Makefiles here and there to add -std=c++11, but other than that
> everything built fine.

Its normally better to change the Qt project (.pro) files than the generated makefiles so there are consistent flags.

Current repository Scintilla works with CONFIG+=c++1z and an explicit —std=gnu++17 in ScintillaEditPy.pro. I don’t know why the explicit —std is now needed since other Qt project files work with just CONFIG+=c++1z.

Neil

[Teodor Petrov]

On 02/03/2018 10:26 PM, Neil Hodgson wrote:
> Teodor Petrov:
>
>> ImportError: ../bin/ScintillaEditPy.so: undefined symbol: SbkObject_Type
>>
>> Any idea what is going on wrong here?
> SbkObject is from Shiboken which handles calling C++ from Python. Check that you have a Shiboken library installed as well as a Shiboken dev library. Try the normal .so checks - does the Shiboken shared library contain SbkObject_Type and can the Shiboken shared library be loaded.
>
> Scintilla uses the original PySide. PySide2 is under development and I don’t think it is ready yet.
>
> Some people split PySide's components up differently and its possible this was published in some Linux distributions. I check with current Fedora and Ubuntu.

I'm running gentoo and these are the package versions.

obfuscated@xlad ~/p/l/s/test> eix shiboken
[I] dev-python/shiboken
     Available versions:  1.2.2 {test PYTHON_TARGETS="python2_7
python3_4 python3_5 python3_6"}
     Installed versions:  1.2.2(12:51:38 PM 02/03/2018)(-test
PYTHON_TARGETS="python2_7 python3_4 -python3_5 -python3_6")
     Homepage:            http://qt-project.org/wiki/PySide
     Description:         A tool for creating Python bindings for C++
libraries

obfuscated@xlad ~/p/l/s/test> eix pyside
[I] dev-python/pyside
     Available versions:  1.2.2-r1 {X declarative designer help
multimedia opengl phonon script scripttools sql svg test webkit
xmlpatterns PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"}
     Installed versions:  1.2.2-r1(12:59:24 PM 02/03/2018)(X
-declarative -designer -help -multimedia -opengl -phonon -script
-scripttools -sql -svg -test -webkit -xmlpatterns
PYTHON_TARGETS="python2_7 python3_4 -python3_5 -python3_6")
     Homepage:            http://wiki.qt.io/PySide
     Description:         Python bindings for the Qt framework

As far as I can see these look correct.

Who is supposed to load this shiboken library?

I'm not relatively new hg-master-branch and the generated project files
has no -std=c++XX in them.

/Teodor

[Neil Hodgson]

Teodor Petrov:

> Who is supposed to load this shiboken library?

The Python script imports ScintillaEditPy.so. This has a reference to (depending on Python version and distribution choices) libshiboken-pythonx.y.so.version which should contain SbkObject_Type. On the installation I checked the shared library file was libshiboken-python2.7.so.1.2 and was located in /lib64.

> I'm not relatively new hg-master-branch and the generated project files has no -std=c++XX in them.

This change set modified ScintillaEditPy.pro (amongst others) to allow C++11:
https://sourceforge.net/p/scintilla/code/ci/b6da730f4d3af5774345fea79da17b062f39c34d/
Its possible the version test in that change is not accurate as it was tested on a limited set of Qt and C++ compiler versions.

Neil