Skip to content
This repository has been archived by the owner on Jun 15, 2021. It is now read-only.

"Accelerating" undo #335

Closed
rrees opened this issue Feb 11, 2015 · 9 comments
Closed

"Accelerating" undo #335

rrees opened this issue Feb 11, 2015 · 9 comments

Comments

@rrees
Copy link
Contributor

rrees commented Feb 11, 2015

Rather than undoing character by character users would like to switch from character to word-based undo if they are repeatedly hitting the undo key combo.

@robinedman
Copy link
Contributor

It's worth noting that we don't technically undo character by character. Rather we undo the last "transaction" (managed by Scribe's transaction manager), which could be more e.g. if you select and then erase a paragraph then that would be one transaction.

Example:
scribe-undo

I wonder how other text editors solve this. It's clearly useful but it might make Scribe more complex.

@theefer
Copy link
Contributor

theefer commented Feb 11, 2015

@OliverJAsh tried to understand how OS/browsers do it but there was no obvious pattern. One way would be to debounce the history recording. There may or may not be subtle implications, given that some of the hack applied to normalise content editable across browsers sometimes have to fiddle with the history stack IIRC.

But featurewise, it would be nice to be closer to native undo, whatever the hell that actually is.

@sihil
Copy link
Contributor

sihil commented Feb 11, 2015

Suggest someone looks at the behaviour of InCopy as that seems the logical thing to copy.

@theefer
Copy link
Contributor

theefer commented Feb 11, 2015

horse-cart-car
Beware the obscure consequences of legacy on modernity :-)

@blishen
Copy link

blishen commented Feb 11, 2015

Those who fail to learn from history are doomed to repeat it

On 11 February 2015 at 22:46, Sébastien Cevey notifications@github.com
wrote:

[image: horse-cart-car]
https://cloud.githubusercontent.com/assets/36964/6158151/be970d92-b23f-11e4-8ff3-1e77ad0ec8f5.jpg
Beware the obscure consequences of legacy on modernity :-)


Reply to this email directly or view it on GitHub
#335 (comment).

PGP Public Key http://bit.ly/Rxbzi0


Visit theguardian.com. On your mobile and tablet, download the Guardian
iPhone and Android apps theguardian.com/guardianapp and our tablet editions
theguardian.com/editions. Save up to 57% by subscribing to the Guardian
and Observer - choose the papers you want and get full digital access.
Visit subscribe.theguardian.com

This e-mail and all attachments are confidential and may also be
privileged. If you are not the named recipient, please notify the sender
and delete the e-mail and all attachments immediately. Do not disclose the
contents to another person. You may not use the information for any
purpose, or store, or copy, it in any way. Guardian News & Media Limited
is not liable for any computer viruses or other material transmitted with
or as part of this e-mail. You should employ virus checking software.

Guardian News & Media Limited is a member of Guardian Media Group plc. Registered
Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP. Registered
in England Number 908396

@rrees
Copy link
Contributor Author

rrees commented Feb 12, 2015

So the initial situation discussed with Jon Hayes is that after two letter by letter undoes it would switch to word by word undo (so go through the transaction history until we see a non-letter character). This would be a bit challenging but has quite a tight focus.

@rrees
Copy link
Contributor Author

rrees commented Feb 13, 2015

This was bumped again today. I think prototyping something might be a good idea @na7hangood, I feel we're going to hear this over and over again

@rrees
Copy link
Contributor Author

rrees commented Feb 14, 2015

Can we also look at #334 when we do this?

@aaalsaleh
Copy link
Contributor

Possible ways to define a new transaction:

  1. On every change.
  2. After a given interval of the last input if no new input has been made since.
  3. On space key (repeated ones can be ignored).
  4. On return key (repeated ones can be ignored).
  5. On backspace and/or delete (repeated ones can be ignored).
  6. On paste event.
  7. On execution of any command (e.g. Bold, Italic, ...etc).
  8. If the cursor/selection location was changed, and a new input has been made.
  9. Combination of all or some of the above.

Previously, 1 was the default behavior. With the new undo manager, 2 is now the default. 3, 4, and 5 are possible with extra checking, but can be annoying to some users. 6 is the easiest, and can be implemented with a small change. 7, is also easy to implement, but there is a need to do minor changes on all the commands (passing a flag to force a new transaction with each command). 8 is not so trivial, especially taking into account the inconsistency with the Selection API across the browsers, but it can be made. Also with low interval, 8 becomes useless, since changing cursor location will pass that interval.

@rrees rrees closed this as completed Jun 26, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants