[PATCH]_place_cursor_after_inserted_chars

[andrew_b]

Could you attach uncompressed patches? It will allow us to view them on-line.

[angel_il]

branch: 319_cursor_after_pasted
based on: master

[angel_il]

for test:
select text trought F3 with arrows.
move cursor another position.
press F5.
Text inserted but cursor not after pasted text.

Please rework.

[ossi]

i'm not positive about the idea as such.
most editors advance the cursor when pasting, and it generally makes sense. however, i often find mcedit's non-advancing behavior advantageous as well.

kate/kdevelop solve this problem by overloading the vertical block selection mode switch with also doing non-advancing insertions. obviously, this is not applicable to mcedit, as no vertical selection mode is planned, only vertical selection actions.

the new qt creator ide has a different approach: insertions do advance the cursor, but if you change the line afterwards without doing something else in between, the column is reset to the pre-insertion one - you get optimal behavior for both "flowed" and "blocked" operations.

[vit_r]

my kate/kde seems, acts like all others editors of Slack 12.2, so this is a try to clarify direction. ps.: Sorry for my broken en. Vit

[vit_r]

Replying to angel_il:

for test:
select text trought F3 with arrows.
move cursor another position.
press F5.
Text inserted but cursor not after pasted text.

Please rework.

place_curs2.diff attached 2009-03-29 20

[vit_r]

Replying to ossi:

i'm not positive about the idea as such.
most editors advance the cursor when pasting, and it generally makes sense. however, i often find mcedit's non-advancing behavior advantageous as well.

kate/kdevelop solve this problem by overloading the vertical block selection mode switch with also doing non-advancing insertions. obviously, this is not applicable to mcedit, as no vertical selection mode is planned, only vertical selection actions.

the new qt creator ide has a different approach: insertions do advance the cursor, but if you change the line afterwards without doing something else in between, the column is reset to the pre-insertion one - you get optimal behavior for both "flowed" and "blocked" operations.

place_curs2.diff attached 2009-03-29 20
my kate/kde seems, acts like all others editors of Slack 12.2,
so this is a try to clarify direction.

ps
Sorry for my broken en.

Vit

[ossi]

kate behaves as i said. you just did not enable the vertical selection mode i talked about. ctrl-shift-b and things look different.

ps: ​http://www.netmeister.org/news/learn2quote.html

[Vit R]

ossi, thanks !

Right: kate acts either one or another way.

But your idea attracts me

And i'm going to add keys Up, PageUp?, etc

Vit

[angel_il]

Replying to vit_r:

Replying to ossi:

i'm not positive about the idea as such.

I think it there should be optional, for example an option: [x] cursor after inserted text.

obviously, this is not applicable to mcedit, as no vertical selection mode is planned, only vertical selection actions.

hmm... Shift+F3 ?!

[ossi]

@ilia: ahhh, even more option-mania. ;)
an option does not help - having to go to the options dialog to change the mode makes it virtually useless. and having a hotkey for an option from the config dialog is just awkward.

shift-f3 is different from kate's vertical selection mode, as it is an exclusive mode with a very limited lifetime ("modal mode", heh). but one could still use that: if the copied selection is a block selection in the first place, then do a non-advancing insertion. this has two minor problems, though: a) even small selections within one line (which pose the majority for the purpose of copying something into multiple adjacent lines) need to be done as vertical selections and b) mc's clipboard does not know whether something comes from a vertical or flowed selection (shift-f5 insertions are always flowed). a) is a non-issue when the alt-shift-arrow selections are implemented (these are way easier to use than shift-f3) and b) is solvable via an extension of the clipboard format.

@vit: which idea do you mean? then one from qt creator? it certainly is the optimum ...

[angel_il]

Replying to ossi:

@ilia: ahhh, even more option-mania. ;)

no, it way to compatibility with old mc-users, nothin more :)

an option does not help - having to go to the options dialog to change the mode makes it virtually useless. and having a hotkey for an option from the config dialog is just awkward.

for this case i try make macros engine for bind no any hotkeys any macros.
For example in FAR you can bind macros like this:
"F4, F7, "ABC", Enter, CtrlShiftLeft?, CtrlIns?, Esc, ShiftF4, ShiftIns?, Enter"
(open cur file, exec search dialog, type "ABC", do search, select one word to left, copy to clip, close editor, create new file, paste word from clipboard, press enter)

i make macros engine in mc like a FAR (experemental branch).

for example: i need swich on option "[ ] &Backspace through tabs" from maros and bind it on Alt-B (for example).
i'm put in ~/.mc/macros
macro1={edit_options_dialog}"B""\n"
(execute edit_options_dialog, press "B", press Enter)
and in file
~/.mc/hotkeys
i'm put
macro1=<my hotkey>

and anytime that i need change "Backspace through tabs" mode i press <my hotkey>

i hope have clearly described idea...

[angel_il]

*for this case i try make macros engine for bind no any hotkeys any macros.
for this case i try make macros engine for bind ON any hotkeys any macros.

[ossi]

Replying to angel_il:

no, it way to compatibility with old mc-users, nothin more :)

don't overdo it. if at all, this should be a config-file-only option, hidden in a "obscure feats" section of the manual. no remotely normal person will insist on the old behavior when the new one is universally better.

an option does not help - having to go to the options dialog to change the mode makes it virtually useless. and having a hotkey for an option from the config dialog is just awkward.

for this case i try make macros engine for bind on any hotkeys any macros.

blah. you completely ignored the second sentence. this simply has no place in the options menu. it is a short-lived state/mode, unlike options which you don't want to touch too often. in gui apps, such things have at most a checkable menu item.

on the matter of a powerful macro processor: i don't object to the idea as such. but a) it is a bad idea to defer shortcuts for standard things to the user. nobody wants to configure each system separately and be totally lost when using some else's setup. b) the macros just script user interactions. that means that you get a rather flashy experience. not *too* nice. of course, you can simply disable repaints while the macro is executing - provided ncurses has such an option.

[angel_il]

Replying to ossi:

Replying to angel_il:

you completely ignored the second sentence.

sorry, but this too much text for me. I'll re-read more attentively.

[angel_il]

Replying to ossi:

shift-f3 is different from kate's vertical selection mode, as it is an exclusive mode with a very limited lifetime ("modal mode", heh).

what do you mean?

ok, are you mean: then we insert from file text, mc does not know what kind block "vertical" or "flowed", i understend you. It's mc trouble, and we need create new ticket.
As it nobody will tell mc what kind block type, we need manual set mode insertion. Maybe hotkey or menu. But it is a another ticket.

is solvable via an extension of the clipboard format.

I against it. We should not invent new clipbord engine.
​http://midnight-commander.org/ticket/321

[ossi]

Replying to angel_il:

Replying to ossi:

shift-f3 is different from kate's vertical selection mode, as it is an exclusive mode with a very limited lifetime ("modal mode", heh).

what do you mean?

it's really a bit tedious to explain the basics of ui design to you ...
kate's vertical selection mode is a session-wide switch. it is comparable to the caps-lock, only that it is limited to the current windows. that means that while some particular behavior is altered, the application is generally used the same way in both modes.
mcedit's (shift-)f3 selection is a short-lived state. you only use it to select something, then you end it. when using non-persistent (let's call them volatile) selections, you even can't do anything but selecting or doing something with the selection. consequently you cannot use this mode to signal mostly unrelated actions (inserting from clipboard) to behave differently. this is analogous to the typical modal dialog which only lets you get back to other work once you explicitly close it.

is solvable via an extension of the clipboard format.

I against it. We should not invent new clipbord engine.

while i do not insist on the format extension, this argument against it is "a bit". weak

[angel_il]

Replying to ossi:

Replying to angel_il:

Replying to ossi:

shift-f3 is different from kate's vertical selection mode, as it is an exclusive mode with a very limited lifetime ("modal mode", heh).

what do you mean?

it is comparable to the caps-lock, only that it is limited to the current windows. that means that while some particular behavior is altered, the application is generally used the same way in both modes.

mcedit's (shift-)f3 selection is a short-lived state.

ok, I've understood you, i like that as it now in mc... and rework all its great work, nobody want do it :)

is solvable via an extension of the clipboard format.

I against it. We should not invent new clipbord engine.

while i do not insist on the format extension, this argument against it is "a bit". weak

ok, maybe you right :) i need more time to think about this :)

[vit_r]

flow column insertion

[vit_r]

Please, have a look now what it is doing: (0001-flow-column-insertion.patch)
At least without any extra options

[Vit R]

to angel_il

Thanks

Vit

[vit_r]

reworked (master 2009-10-30 14:18)

Very sorry for such long delay

Vit

2009-10-30

[vit_r]

Replying to ossi:

i'm not positive about the idea as such.
most editors advance the cursor when pasting, and it generally makes sense. however, i often find mcedit's non-advancing behavior advantageous as well.

kate/kdevelop solve this problem by overloading the vertical block selection mode switch with also doing non-advancing insertions. obviously, this is not applicable to mcedit, as no vertical selection mode is planned, only vertical selection actions.

the new qt creator ide has a different approach: insertions do advance the cursor, but if you change the line afterwards without doing something else in between, the column is reset to the pre-insertion one - you get optimal behavior for both "flowed" and "blocked" operations.

What about this try (2009-10-30). Vit

[vit_r]

Silence ...

Seems, now this patch looks better but there is no discussion

Might be i'm doing something wrong

2009-11-03

[vit_r]

Vit

[slavazanko]

vit_r, don't worry, your patch not forgotten :)

But now 'master' branch don't able to accept 'Enhancement', 'Task' and other feature requests. Just bugfixing. Therefore your patch will applied after release out '4.7.0' version.

Now patch frozen.

[slavazanko]

Created branch 319_edit_flow_column_insertion.

Review, please.

[slavazanko]

Merged to master:

git log --pretty=oneline a1dd199..77c599b