Ticket #319 (closed enhancement: fixed)
[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
Change History
comment:1 follow-up: ↓ 2 Changed 16 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 16 years ago by andrew_b
Could you attach uncompressed patches? It will allow us to view them on-line.
comment:3 Changed 16 years ago by angel_il
- Keywords rework added; review removed
branch: 319_cursor_after_pasted
based on: master
comment:4 follow-up: ↓ 6 Changed 16 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 16 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 16 years ago by vit_r
- Attachment place_curs2.diff added
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 16 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 16 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 16 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.
comment:9 Changed 16 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 16 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 16 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 16 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 16 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 16 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 16 years ago by angel_il
comment:16 in reply to: ↑ 11 ; follow-up: ↓ 17 Changed 16 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 16 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
comment:18 in reply to: ↑ 17 Changed 16 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 :)
Changed 16 years ago by vit_r
- Attachment 0001-flow-column-insertion.patch added
flow column insertion
comment:20 Changed 16 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:22 Changed 15 years ago by Vit R
to angel_il
Thanks
Vit
comment:27 Changed 15 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 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.
What about this try (2009-10-30). Vit
comment:30 Changed 15 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 15 years ago by vit_r
Vit
comment:32 Changed 15 years ago by slavazanko
- Owner changed from vit_r to slavazanko
- Status changed from new to accepted
- 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: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.
comment:37 Changed 12 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 12 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