Ticket #27 (closed enhancement: fixed)

Opened 10 years ago

Last modified 5 years ago

savannah: undo grouping wanted

Reported by: ossi Owned by: angel_il
Priority: minor Milestone: 4.7.5
Component: mcedit Version: master
Keywords: Cc: tux@…
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description (last modified by ossi) (diff)

Original: http://savannah.gnu.org/bugs/?13739

Submitted by:Oswald Buddenhagen <ossi>Submitted on:Mon 11 Jul 2005 09:24:04 PM UTC
Category:EditorSeverity:3 - Normal
Status:NonePrivacy:Public
Assigned to:NoneOpen/Closed:Open
Release:current (CVS or snapshot)Operating System:All

Original submission:

this is a very controversial topic, so i'm missing the "put 
flameshield on before joining thread" warning checkbox. :)

there are actually two main questions:
- are movements actions? for me, definitely yes. i hate editors 
that just pretend that there are no movements when it comes to undo.
- undo grouping should roughly predict what the user probably wants 
to undo at once, without grouping too much. i suggest an action/time
/space based grouping:
- if the user switches to another "action sequence" 
(inserting/overwriting, deleting, navigating, maybe more), he 
certainly wants it separated from the previous sequence
- if he makes a longer break while doing things, he probably 
expects it when undoing as well. what "longer" means is very 
subjective; a simple adaptive algorithm might make sense
- small moves are merged, while big ones aren't. i'm not even sure 
what the criteria should be here. maybe moves should be generally 
merged and we should only depend on the other two "break 
conditions". 

Change History

comment:1 Changed 10 years ago by styx

  • Milestone set to 4.7

comment:2 Changed 10 years ago by slavazanko

  • Milestone changed from 4.7 to future releases

comment:3 Changed 9 years ago by bilbo

  • Cc tux@… added
  • severity set to no branch

Well, doing some "adaptive" undoing may require some fine-tuning and won't please all users, but we can start with grouping the most obvious actions into one:

Movement actions: any movement between consecutive edits should be grouped into single undoable action. Currently, you edit something, then you scroll up and down the file to find out later that the edit is wrong. If you want to undo that, you have to undo also hundreds of movement commands

Typing actions: action where single character is typed could be also grouped, though there is risk of perhaps overgrouping, so pressing enter for newline should probably break the group. Perhaps even actions that does not involve anything undoable could break the typing group too (invoking help, menu, etc ...)

comment:4 Changed 9 years ago by angel_il

  • Status changed from new to accepted
  • Owner set to angel_il

comment:5 Changed 9 years ago by ossi

  • Cc ossi@… added

comment:6 Changed 8 years ago by angel_il

  • Version set to master
  • severity changed from no branch to on review
  • Milestone changed from Future Releases to 4.7.5

branch: 27_group_undo
changeset: d3e6361484feac667812107f8b13d559b58c969f

comment:7 follow-up: ↓ 10 Changed 8 years ago by ossi

well, it works like expected ...

i'd still like to see the addition of a "grouping timeout" in a second step. that could be probably done by inserting an artificial no-op command after a timeout which is retriggered on each real action. how long that timeout should be is debatable (see above), but two or three seconds should work for starters, i think.

comment:8 Changed 8 years ago by andrew_b

  • Votes for changeset set to andrew_b
  • Type changed from task to enhancement

comment:9 Changed 8 years ago by slavazanko

  • Votes for changeset changed from andrew_b to andrew_b slavazanko
  • severity changed from on review to approved

i'd still like to see the addition of a "grouping timeout" in a second step

In my opinion, this is should be another task... or you may publish patch with this feature... :)

comment:10 in reply to: ↑ 7 Changed 8 years ago by angel_il

Replying to ossi:

well, it works like expected ...

i'd still like to see the addition of a "grouping timeout" in a second step. that could be probably done by inserting an artificial no-op command after a timeout which is retriggered on each real action.

i think this is a reason... but we do not have a timer, and is a big problem at this stage ..

comment:11 Changed 8 years ago by angel_il

  • Status changed from accepted to testing
  • Votes for changeset changed from andrew_b slavazanko to committed-master
  • Resolution set to fixed
  • severity changed from approved to merged

comment:12 Changed 8 years ago by andrew_b

  • Status changed from testing to closed

comment:14 Changed 5 years ago by ossi

  • Cc ossi@… removed
  • Description modified (diff)
  • Branch state set to no branch
  • Reporter changed from slavazanko to ossi

comment:15 Changed 5 years ago by andrew_b

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