zsh-users
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: Extending zed
Date: Mon, 04 Jun 2018 18:08:31 +0200	[thread overview]
Message-ID: <7026.1528128511@thecus> (raw)
In-Reply-To: <CAKc7PVB6JhtAQa+MUs0tm28211e4xJ4QRt-83=QYmuOczKwcOA@mail.gmail.com>

Sebastian Gniazdowski wrote:
> I've looked at the undo problem. Ctrl-/ (or Ctrl-_ that's the same
> control code as we know) works fine in insert mode, i.e. it does do
> undo. I've checked it's bound to widget "undo" (checking code at the
> end of post). Then I've checked the not-working "u" in zed-vicmd
> keymap. It is also bound to widget "undo". But it makes viewport
> blank, doesn't do smooth undo like Ctrl-/. What is the way out of
> this? Shoud vicmd keymap bind to vi-undo-change? Docs suggest it is a
> one-time undo.

We can prevent the viewport clearing by setting UNDO_LIMIT_NO in an
initialisation widget.

An init function setup in the bind mode seems useful anyway. Perhaps for
vi users it should also contain zle vi-cmd-mode. (I alias vared to vared
-i vi-cmd-mode). I followed the naming of the __zed_pg_up widgets in
naming this __zed_init but I'm not especially fond of this – it looks
like a completion function.

vi-undo-change was once the default. It alternates between undoing
and redoing just the last change. undo acts in a vim compatible way:
multiple undos with a separate redo widget. Other mechanisms are
perhaps better: nvi uses u followed by . to do multiple undo. However,
multiple undo is very useful and the vim mechanism is what we have
implemented so it is the default.

Undoing individual characters at a time is not how undo works in vi or
vim. You can bind a key to undo in viins and it'll do that. Otherwise,
undo events are merged when you go into vi command mode allowing
vi-compatible undo behaviour of undoing whole vi changes.

If you want undo from vicmd to be somewhat more fine-grained, you can
call split-undo from within certain widgets. Redefining self-insert to
call split-undo should work, for example.

By the way, the change in 42929 to bind Home and End seems harmless
enough given that PgUp/Down is already there. I'm not so sure about
the use of zle -la to test for widgets existing (zle -N is silent and
idempotent anyway).

Oliver

diff --git a/Functions/Misc/zed b/Functions/Misc/zed
index f571daf5e..94938871e 100644
--- a/Functions/Misc/zed
+++ b/Functions/Misc/zed
@@ -67,6 +67,12 @@ if (( bind )) || ! bindkey -M zed >&/dev/null; then
   # zed we may want to set this temporally.
   bindkey -A main zed-normal-keymap
 
+  # Define a widget to use at startup, undo shouldn't clear initial buffer
+  __zed_init() {
+    UNDO_LIMIT_NO=$UNDO_CHANGE_NO
+  }
+  zle -N __zed_init
+
   # Assign some default keys.
   # Depending on your stty's, you may be able to use ^J as accept-line, else:
 
@@ -105,11 +111,11 @@ if ((fun)) then
     var="${(q-)1} () {
 }"
   fi
-  vared -M zed -m zed-vicmd var && eval function "$var"
+  vared -M zed -m zed-vicmd -i __zed_init var && eval function "$var"
 else
   zed_file_name=$1
   [[ -f $1 ]] && var="$(<$1)"
-  while vared -M zed -m zed-vicmd var
+  while vared -M zed -m zed-vicmd -i __zed_init var
   do
     {
       print -r -- "$var" >| $zed_file_name


  reply	other threads:[~2018-06-04 16:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180603055854epcas5p1e92f5a41384aeb9d1555751df74f57ee@epcas5p1.samsung.com>
2018-06-03  5:57 ` Sebastian Gniazdowski
2018-06-04  8:37   ` Peter Stephenson
2018-06-04  9:41     ` Sebastian Gniazdowski
2018-06-04  9:50       ` Peter Stephenson
2018-06-04 10:17         ` Sebastian Gniazdowski
2018-06-04 16:08           ` Oliver Kiddle [this message]
2018-06-05 14:40             ` Sebastian Gniazdowski
2019-07-28 11:01               ` Sebastian Gniazdowski
     [not found]       ` <20180604105042.69c54bee@camnpupstephen.cam.scsc.local>
2018-06-04  9:56         ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7026.1528128511@thecus \
    --to=okiddle@yahoo.co.uk \
    --cc=sgniazdowski@gmail.com \
    --cc=zsh-users@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).