Ticket #319 (closed enhancement: fixed)

Opened 15 years ago

Last modified 10 years ago

[PATCH]_place_cursor_after_inserted_chars

Reported by: vit_r Owned by: slavazanko
Priority: minor Milestone: 4.8.7
Component: mcedit Version: 4.6.2
Keywords: Cc:
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description


Attachments

place_curs.gz (696 bytes) - added by vit_r 15 years ago.
place_curs.patch (1.3 KB) - added by angel_il 15 years ago.
place_curs2.diff (2.4 KB) - added by vit_r 15 years ago.
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
flow_insert_col.diff (4.8 KB) - added by vit_r 15 years ago.
0001-flow-column-insertion.patch (11.1 KB) - added by vit_r 15 years ago.
flow column insertion
319-flow-column-insertion.patch (7.6 KB) - added by vit_r 14 years ago.

Change History

Changed 15 years ago by vit_r

comment:1 follow-up: ↓ 2 Changed 15 years ago by vit_r

  • Summary changed from 319_[PATCH]_place_cursor_after_inserted_chars to [PATCH]_place_cursor_after_inserted_chars

comment:2 in reply to: ↑ 1 Changed 15 years ago by andrew_b

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

Changed 15 years ago by angel_il

comment:3 Changed 15 years ago by angel_il

  • Keywords rework added; review removed

branch: 319_cursor_after_pasted
based on: master

comment:4 follow-up: ↓ 6 Changed 15 years ago by 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.

comment:5 follow-ups: ↓ 7 ↓ 28 Changed 15 years ago by ossi

  • Type changed from defect to enhancement

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.

Changed 15 years ago by 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

comment:6 in reply to: ↑ 4 Changed 15 years ago by vit_r

  • Type changed from enhancement to defect

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

comment:7 in reply to: ↑ 5 ; follow-up: ↓ 10 Changed 15 years ago by 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

comment:8 Changed 15 years ago by 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

comment:9 Changed 15 years ago by 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

comment:10 in reply to: ↑ 7 Changed 15 years ago by 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 ?!

comment:11 follow-ups: ↓ 12 ↓ 16 Changed 15 years ago by 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 ...

comment:12 in reply to: ↑ 11 ; follow-up: ↓ 14 Changed 15 years ago by 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...

comment:13 Changed 15 years ago by 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.

comment:14 in reply to: ↑ 12 ; follow-up: ↓ 15 Changed 15 years ago by 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.

comment:15 in reply to: ↑ 14 Changed 15 years ago by 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.

comment:16 in reply to: ↑ 11 ; follow-up: ↓ 17 Changed 15 years ago by 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

comment:17 in reply to: ↑ 16 ; follow-up: ↓ 18 Changed 15 years ago by 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

Changed 15 years ago by vit_r

comment:18 in reply to: ↑ 17 Changed 15 years ago by 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 :)

comment:19 Changed 15 years ago by vit_r

  • Keywords review added; rework removed

Changed 15 years ago by vit_r

flow column insertion

comment:20 Changed 15 years ago by vit_r

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

comment:21 Changed 15 years ago by angel_il

  • Type changed from defect to enhancement

comment:22 Changed 15 years ago by Vit R

to angel_il

Thanks

Vit

comment:23 Changed 15 years ago by angel_il

  • Milestone changed from 4.7 to 4.7.0-pre1

comment:24 Changed 15 years ago by angel_il

  • Milestone changed from 4.7.0-pre1 to 4.7

comment:25 Changed 15 years ago by winnie

  • Keywords review removed
  • severity set to on review

comment:26 Changed 15 years ago by angel_il

  • severity changed from on review to on rework

comment:27 Changed 14 years ago by vit_r

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

Very sorry for such long delay

Vit

2009-10-30

comment:28 in reply to: ↑ 5 Changed 14 years ago by 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

comment:29 Changed 14 years ago by vit_r

  • severity changed from on rework to on review

Changed 14 years ago by vit_r

comment:30 Changed 14 years ago by vit_r

Silence ...


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

Might be i'm doing something wrong

2009-11-03

comment:31 Changed 14 years ago by vit_r

Vit

comment:32 Changed 14 years ago by slavazanko

  • Status changed from new to accepted
  • Owner changed from vit_r to slavazanko
  • severity changed from on review to on hold

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.

comment:33 Changed 13 years ago by slavazanko

  • severity changed from on hold to no branch
  • Branch state set to on hold

comment:34 Changed 12 years ago by andrew_b

  • Milestone changed from 4.7 to Future Releases

comment:35 Changed 12 years ago by slavazanko

  • Branch state changed from on hold to on review
  • Milestone changed from Future Releases to 4.8.7

Created branch 319_edit_flow_column_insertion.

Review, please.

Last edited 11 years ago by angel_il (previous) (diff)

comment:36 Changed 12 years ago by angel_il

  • Votes for changeset set to angel_il

comment:37 Changed 11 years ago by andrew_b

  • Votes for changeset changed from angel_il to angel_il andrew_b
  • Branch state changed from on review to approved

comment:38 Changed 11 years ago by slavazanko

  • Status changed from accepted to testing
  • Votes for changeset changed from angel_il andrew_b to committed-master
  • Resolution set to fixed

Merged to master:

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

comment:39 Changed 11 years ago by slavazanko

  • Status changed from testing to closed

comment:40 Changed 10 years ago by andrew_b

  • Branch state changed from approved to merged
Note: See TracTickets for help on using tickets.