Re: [scite] Re: Patch for column/rectangular editing , feature for 545068
Neil Hodgson
scintilla-interest as this affects other editors]
haimag ren:
> but at line ending position, all the carets may not in the same column.
Yes, the idea is the user should be able to see where their typing will go.
> and all column cares blinking, it's not good for eyes.
The place that the typing will go is shown by a caret. Its up to
the user whether the caret will blink, its blink rate, width and
colour. I suppose there could be an extra option for not blinking a
multi-line caret but this shouldn't be the default.
> Can realized caret at the same column at this position( comment // Draw
> the Caret) ? Like code below.
> //
> int edgeX = pdoc->GetColumn(currentPos) * vsDraw.spaceWidth;
> rcSegment.left = edgeX + xStart;
> rcSegment.right = rcSegment.left + 1;
> surface->FillRectangle(rcSegment, vsDraw.caretcolour.allocated);
> //
Again, this does not work for proportional text.
For short lines there needs to be some way to display the caret
assuming the space filling that would occur if the user types a
character.
Neil
haimag
mode,
It's better to add a column mode option, when set column mode,
changed to monospaced font .
> int edgeX = pdoc->GetColumn(currentPos) * vsDraw.spaceWidth;
> rcSegment.left = edgeX + xStart;
> rcSegment.right = rcSegment.left + 1;
> surface->FillRectangle(rcSegment, vsDraw.caretcolour.allocated);
I have update Editor.cxx for suport Overtype char input .
file at: http://groups.google.com/group/scintilla-interest/web/Editor.cxx_for_ColumnEdit
on windows, column drag worked well.
but on Linux, when column drag, text put on wrong position. why ?
haimag
please see :
http://www.ultraedit.com/support/tutorials_power_tips/ultraedit/column_mode.html
On May 2, 7:11 pm, haimag <hai...@gmail.com> wrote:
> The feature(work for proportional text) is not useful in column edit
> mode,
> It's better to add a column mode option, when set column mode,
> changed to monospaced font .
>
> > int edgeX = pdoc->GetColumn(currentPos) * vsDraw.spaceWidth;
> > rcSegment.left = edgeX + xStart;
> > rcSegment.right = rcSegment.left + 1;
> > surface->FillRectangle(rcSegment, vsDraw.caretcolour.allocated);
>
> when used this mode, the drag caret worked well.
> I have update Editor.cxx for suport Overtype char input .
Neil Hodgson
> The feature(work for proportional text) is not useful in column edit
> mode,
It is useful for proportional text just as the current rectangular
selection behaviour is.
> It's better to add a column mode option, when set column mode,
> changed to monospaced font .
It is better to make column editing work in proportional text.
>> int edgeX = pdoc->GetColumn(currentPos) * vsDraw.spaceWidth;
>> rcSegment.left = edgeX + xStart;
>> rcSegment.right = rcSegment.left + 1;
>> surface->FillRectangle(rcSegment, vsDraw.caretcolour.allocated);
>
> when used this mode, the drag caret worked well.
I got the drag caret working by changing the earlier code to take
note of posDrag
if (lineDoc == lineCaret || (multiLineCaret && selType == selRectangle)) {
int offset = Platform::Minimum(posCaret - rangeLine.start,
ll->maxLineLength);
if (multiLineCaret && (selType == selRectangle) && (posDrag < 0)) {
offset = Platform::Minimum(
((xStartSelect < xEndSelect) ? lineIterator.endPos :
lineIterator.startPos) - rangeLine.start,
ll->maxLineLength);
}
> I have update Editor.cxx for suport Overtype char input .
OK.
Neil
jeroenh
>
> > The feature(work for proportional text) is not useful in column edit
> > mode,
>
> It is useful for proportional text just as the current rectangular
> selection behaviour is.
>
I'm pretty new to this group, so I apologize if this has been
discussed before.
I'm curious about the use case(s) both for rectangular selection and
column
mode editing with proportional text. At first sight, I would agree
with haimag
that column mode editing is mainly useful with fixed-width font.
Thoughts?
greetz,
jeroen
Neil Hodgson
> I'm curious about the use case(s) both for rectangular selection and
> column mode editing with proportional text.
Same as for fixed width text: you have some text that lines up in
columns, possibly from using tabs, and want to change it in one
operation. One example is adding or changing a modifier on a sequence
of method definitions: adding "virtual" or changing "char" to
"wchar_t".
Neil
jeroenh
However (disclaimer: I just started looking at the code, so I'm
probably not
yet in a position to judge this properly, but still:), supporting this
feature
also for proportional text seems to make it harder than necessary to
implement.
Would it not be an option to introduce a 'Column Mode' as haimag has
suggested previously? For rectangular operations, the user can switch
to column mode and (automatically) scintilla switches to a fixed width
font. When leaving column mode, scintilla would revert to whatever
the font was before.
This way, one doesn't really loose anything over the current way of
working,
but would be able to add more features to the rectangular selection
mode (e.g., inserting a range of incrementing numbers comes to mind)
(Column Mode is similar to the way UltraEdit implements it. I don't
use this
tool anymore now, but this particular feature has worked quite well
for me
in the past, and is something I consistently miss in other editors.)
greetz,
jeroen
Philippe Lhoste
> I'm curious about the use case(s) both for rectangular selection and
> column
> mode editing with proportional text. At first sight, I would agree
> with haimag
> that column mode editing is mainly useful with fixed-width font.
I also have some lexers with proportional font for code and fixed one for comments...
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Neil Hodgson
> However (disclaimer: I just started looking at the code, so I'm
> probably not yet in a position to judge this properly, but
> still:), supporting this feature also for proportional text seems
> to make it harder than necessary to implement.
The difficulty seems completely necessary to me.
> Would it not be an option to introduce a 'Column Mode' as haimag has
> suggested previously? For rectangular operations, the user can switch
> to column mode and (automatically) scintilla switches to a fixed width
> font. When leaving column mode, scintilla would revert to whatever
> the font was before.
No. This would require entering special modes for what could be a
simple operation.
Scintilla has a wide range of features that should all work well
together. It is easier for someone to implement a new feature that
doesn't respect existing features like multi-byte characters,
combining characters or proportional text but it increases the
difficulty in adding other features that can not depend on this new
feature working in all situations. It also increases the difficulty in
using Scintilla leading to more bug reports which, in the majority of
cases end up being handled by me and not by the original feature
implementer.
Neil
haimag ren
please see the attachment( Editor.cxx) , modified base on scintilla 1.78 .
column_edit.diff is a diff file .
Neil Hodgson
> replace "pdoc->GetColumn" with "XFromPosition" in the patch code , it seem
> work well with multi-byte characters and proportional text.
That helps.
When I mentioned the multiLineCaret setting I meant that if
multiLineCaret is false then none of this new behaviour should occur.
No multiple line insertions when typing and old code used for
deletion. This is to ensure maximum compatibility with existing
software unless the user wants this function. Thus AddCharUTF, Clear,
and DelCharBack should start with
if (multiLineCaret && wasSelection && selType == selRectangle ) {
> please see the attachment( Editor.cxx) , modified base on scintilla 1.78
Instead of finding c1 and c2 and then using offset = c1 < c2 ? c1 :
c2, a shorter way is to use Platform::Minimum:
int offset = Platform::Minimum(XFromPosition(currentPos),
XFromPosition(anchor));
Neil
haimag ren
Neil Hodgson
multiple lines, I named the fields and their associated APIs so that
the whole feature is controlled by multiLineCaret and blinking by
multiLineCaretBlinks. The APIs are SCI_SETMULTILINECARET and
SCI_SETMULTILINECARETBLINKS with corresponding GET calls. Also changed
the code to match the style of the rest of Scintilla.
Source code available from
http://www.scintilla.org/multiline.zip
Neil
haimag ren
diff to Editor.cxx in http://www.scintilla.org/multiline.zip
@@ -3854,7 +3854,7 @@ void Editor::DelCharBack(bool allowLineS
unsigned int chars = endPos - startPos;
if (0 != chars) {
pdoc->DeleteChars(startPos, chars);
- } else
+ } else if(!IsEOLChar(pdoc->CharAt(startPos-1)))
pdoc->DelCharBack(startPos);
}
}
Neil Hodgson
> take into account backspace operation at line-start position.
OK.
For experimentation, uploaded this to
http://www.scintilla.org/scite.zip Source
http://www.scintilla.org/wscite.zip Windows executable
Behaviour is turned on with caret.multi.line=1
Blinking can be turned off in favour of a multi-line bar with
caret.multi.line.blinks=0
Neil
Philippe Lhoste
> For experimentation, uploaded this to
> http://www.scintilla.org/scite.zip Source
> http://www.scintilla.org/wscite.zip Windows executable
Brief test:
Add the lines
caret.multi.line=1
caret.multi.line.blinks=0
to the properties.
Add
style.hypertext.32=fore:#000000,font:Andale Mono,size:9
to the html.properties.
Most styles are displayed in fixed width font -- works also with Courier New.
Load SciTEFAQ.html.
Click after the first <meta, hit Alt+Shift+Down twice.
Type Wa: the a skips the space and goes just before the attribute name.
Further typing goes before the a!
If I hit Ctrl+F11 to go monospace mode, it behaves better... But note that technically,
the three styles around this area (1, 8, 3) use a monospaced font already.
But perhaps the patch uses the space width of style 0, which is Verdana by default...
Same if, for example, I select 'name' with Alt down: when I type to replace, caret skips a
char.
I understand there might be technical issues there but having typing not collapsed in undo
buffer is disturbing (we are not used to it).
Otherwise, it works quite well and it is a useful addition. Thanks!
Neil Hodgson
> Load SciTEFAQ.html.
> Click after the first <meta, hit Alt+Shift+Down twice.
> Type Wa: the a skips the space and goes just before the attribute name.
> Further typing goes before the a!
That was because the 'W' had not been styled yet so was in style 0
and thus wider when the new rectangular area was calculated. Then
styling occurred during the paint which reduced the width of the 'W'.
The 'a' is then inserted at the place the 'W' used to end. Fixed by
adding a call to style up to the end of modifications inside character
addition before setting the rectangular selection:
pdoc->EnsureStyledTo(pdoc->LineEnd(Platform::Maximum(anchor, currentPos)));
Possibly should be moved into SetRectangularRange.
> I understand there might be technical issues there but having typing not collapsed in undo
> buffer is disturbing (we are not used to it).
Yes, this is hard to detect and fix.
Neil
Neil Hodgson
that this had been feeling wrong to me. Really, rectangular selection
is just a special case of discontiguous selection and implementing
discontiguous selection may solve this more generally. To select
several separated ("discontiguous") pieces of text in many editors,
use the control key in conjunction with mouse selecting after the
initial selection. Common applications that support discontiguous
selection include Open Office Writer and Firefox. They do not support
simultaneously typing into each selection at once but this could be
useful - it is similar to what snippet-supporting editors do when
there are multiple locations for a single placeholder. It may also
prove useful in normal editing. Say there was a function
void GetRTFStyleChange(char *delta, char *last, char *current) {
and I wanted to make all the parameters const. With discontiguous
selection I could click before the first "char", then Ctrl+click
before the two other instances of "char", type "const " and it would
be done. There would probably have to be an option whether to support
simultaneous typing since it may be confusing.
The small addition mentioned earlier was to add a new selection
mode, SC_SEL_THIN, which is like SC_SEL_RECTANGLE except that only the
currentPos (caret) is used to decide what is selected, not the anchor.
This is similar to making the selection zero width after a rectangular
selection has been typed into, or Delete or Backspace typed and
ensures that no characters are selected after these operations. This
makes further actions more predictable when the text is variable
width.
Code with SC_SEL_THIN implemented is available from
http://www.scintilla.org/scite.zip Source
http://www.scintilla.org/wscite.zip Windows executable
Neil
Mike Lischke
> several separated ("discontiguous") pieces of text in many editors,
> use the control key in conjunction with mouse selecting after the
> initial selection.
Actually, the usual sequence is: click and...
1) No modifier: clear selection, move selection anchor to click pos
2) Shift: select everything from anchor to click pos
3) Control: move selection anchor to click pos
2 + 3 can be combined too. Often also the caret is moved to the click
position, but doesn't necessarily have to.
For Scintilla we'd add Alt for rectangular selection, which could be
combined with 2 and 3 too. However on OS X we have a problem then,
since Scintilla does not have a flag for the command key (apple key)
which is therefore simulated by setting Alt and Control (in the Cocoa
port) or Shift+Alt+Control (Carbon port) when pressed. Hence we lose
all these combinations for selection. That could be solved easily by
adding more modifier flags to Scintilla, though (at least for command,
but I could even imagine something like: LShift, RShift, LCtrl, RCtrl
etc., you get the picture).
> Common applications that support discontiguous
> selection include Open Office Writer and Firefox.
Windows Explorer does this too (right pane, the listview) as well as
many applications which use my Virtual Treeview.
> They do not support
> simultaneously typing into each selection at once but this could be
> useful - it is similar to what snippet-supporting editors do when
> there are multiple locations for a single placeholder. It may also
> prove useful in normal editing. Say there was a function
> void GetRTFStyleChange(char *delta, char *last, char *current) {
> and I wanted to make all the parameters const. With discontiguous
> selection I could click before the first "char", then Ctrl+click
> before the two other instances of "char", type "const " and it would
> be done. There would probably have to be an option whether to support
> simultaneous typing since it may be confusing.
Indeed, for an editor this is a very nice idea and I can see some very
useful applications. However, this implementation would require to
decouple the current selection display (which characters are selected)
and the selection anchor as well as the caret position. This opens up
other useful things like moving the caret to the begin or end of a
selection block etc.
> The small addition mentioned earlier was to add a new selection
> mode, SC_SEL_THIN, which is like SC_SEL_RECTANGLE except that only the
> currentPos (caret) is used to decide what is selected, not the anchor.
> This is similar to making the selection zero width after a rectangular
> selection has been typed into, or Delete or Backspace typed and
> ensures that no characters are selected after these operations. This
> makes further actions more predictable when the text is variable
> width.
If I understand you correctly then you don't plan an indicator to show
at which positions the next input will be inserted? Could become very
confusing then. I think this "multi insertion" feature (which it
becomes when you have a zero width discontiguous selection) needs a
new paradigm of marking the current input location. However, I really
like the idea to paste something once and it appears in several places
in the editor :-)
Mike
--
Mike Lischke, Senior Software Engineer
Database Group, Developer Tools
Sun Microsystems Inc., www.sun.com
Philippe Lhoste
> Really, rectangular selection
> is just a special case of discontiguous selection and implementing
> discontiguous selection may solve this more generally.
Although I never (think to) use this feature in Firefox, I can see the usefulness in a
text editor!
Your example is a good one, and if you ever implement it, I hope we will be able to copy a
discontiguous selection too (copy those lines, skipping some in the middle - might need to
be able to deselect parts too).
Neil Hodgson
> For Scintilla we'd add Alt for rectangular selection, which could be
> combined with 2 and 3 too. However on OS X we have a problem then,
> since Scintilla does not have a flag for the command key (apple key)
You can't map the modifiers consistently between environments since
their meanings overlap: on GTK+ Alt means rectangular selection when
using the keyboard but Ctrl is used for rectangular selection when
using the mouse because Alt+Mouse Drag is often intercepted by the
window manager. It can be easier to have the platform layer interpret
modifier keys before sending them up to the platform independent code.
> Indeed, for an editor this is a very nice idea and I can see some very
> useful applications. However, this implementation would require to
> decouple the current selection display (which characters are selected)
> and the selection anchor as well as the caret position.
Its really an extension of the anchor to caret paradigm to support
a list of anchor to caret selections. One selection (probably the most
recent) would be used for ensuring that the display shows a caret
although it should strive to show all selections if possible. I'm not
sure which actions occur on all selections.
> This opens up
> other useful things like moving the caret to the begin or end of a
> selection block etc.
That can be done currently if you feel like defining a command for it.
> If I understand you correctly then you don't plan an indicator to show
> at which positions the next input will be inserted?
There is a caret at each point where input will be inserted except
possibly for a rectangular selection when caret.multi.line.blinks is
off and a non-blinking vertical line displayed instead.
Neil
Neil Hodgson
> Although I never (think to) use this feature in Firefox, I can see the usefulness in a
> text editor!
> Your example is a good one, and if you ever implement it, I hope we will be able to copy a
> discontiguous selection too (copy those lines, skipping some in the middle - might need to
> be able to deselect parts too).
I think that copying is the reason this feature is in Firefox.
Neil
Mike Lischke
> You can't map the modifiers consistently between environments since
> their meanings overlap: on GTK+ Alt means rectangular selection when
> using the keyboard but Ctrl is used for rectangular selection when
> using the mouse because Alt+Mouse Drag is often intercepted by the
> window manager. It can be easier to have the platform layer interpret
> modifier keys before sending them up to the platform independent code.
Indeed, how modifiers are interpreted at the end is dependent on the
platform. However, simulating one key by a combination of others is
rather suboptimal. So it would good to have more modifier flags
available. I'm aware this would require to change some backend code,
as there are a few functions which don't pass the modifer keys as an
enum/bitfield but as individual parameters.
>> This opens up
>> other useful things like moving the caret to the begin or end of a
>> selection block etc.
>
> That can be done currently if you feel like defining a command for
> it.
Hmm, how can that work if the selection is defined by the range
between anchor and caret? Moving the caret will then change the
selection implicitely due to that definition.
>> If I understand you correctly then you don't plan an indicator to
>> show
>> at which positions the next input will be inserted?
>
> There is a caret at each point where input will be inserted except
> possibly for a rectangular selection when caret.multi.line.blinks is
> off and a non-blinking vertical line displayed instead.
Very nice, thanks.
Neil Hodgson
> Hmm, how can that work if the selection is defined by the range
> between anchor and caret? Moving the caret will then change the
> selection implicitely due to that definition.
Here is a command in SciTE for swapping the caret to the opposite end:
function SwapSelection()
anchor = editor.Anchor
currentPos = editor.CurrentPos
editor.Anchor = currentPos
editor.CurrentPos = anchor
end
Neil
haimag ren
Neil Hodgson
> Can add this code to cvs ?
I am extensively rewriting the selection code. This new code will
not be committed to CVS until after Scintilla 1.79 is released.
Neil