Extending zed

Extending zed

[Sebastian Gniazdowski]

Hello,
zed isn't that fun editor for large files and functions, however with
fast-syntax-highlighting it has colorizing that is unachievable with
vim or emacs. Example of 2 themes active at the same time (eval has
own theme):

http://psprint.blinkenshell.org/eval3.png

So editor cannot interpret "eval" as special recursive command, Zsh can.

That's why I'm thinking about extending Zed. I wonder if one could
code a status bar for it? What else can be added? Some time ago I've
added pg-up, pg-down bindings, similar are needed too.

-- 
Best regards,
Sebastian Gniazdowski

Re: Extending zed

[Peter Stephenson]

On Sun, 3 Jun 2018 07:57:12 +0200
Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> That's why I'm thinking about extending Zed.

I'd suggest calling it something else --- such as ezed.  Zed itself
is deliberately a minimal function that's designed for the
limited purpose of editing small functions inline; bells and
whistles belong somewhere else.

pws

Re: Extending zed

[Sebastian Gniazdowski]

On 4 June 2018 at 10:37, Peter Stephenson <p.stephenson@samsung.com> wrote:
> On Sun, 3 Jun 2018 07:57:12 +0200
> Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
>> That's why I'm thinking about extending Zed.
>
> I'd suggest calling it something else --- such as ezed.  Zed itself
> is deliberately a minimal function that's designed for the
> limited purpose of editing small functions inline; bells and
> whistles belong somewhere else.

It seems that name `ezed' would actually help the idea of not-so-bad
Zsh-builtin-editor. It's somewhat natural to use name ezed for it, not
zed, but cannot explain why.

Zed always gives me impression that I will touch something improper
and break the function or file I'm editing. Maybe we could set up few
things that will make zed more predictable? The page-up, page-down are
good example, before those binding the keys were calling history and
really breaking the viewport. Currently "u" key doesn't do undo and
breaks viewport, could I bind it? I would send a patch. Also, would it
be possible to implement ESC:wq, i.e. regular way of leaving vim-like
editor.

-- 
Best regards,
Sebastian Gniazdowski

Re: Extending zed

[Peter Stephenson]

On Mon, 4 Jun 2018 11:41:56 +0200
Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> Zed always gives me impression that I will touch something improper
> and break the function or file I'm editing. Maybe we could set up few
> things that will make zed more predictable? The page-up, page-down are
> good example, before those binding the keys were calling history and
> really breaking the viewport. Currently "u" key doesn't do undo and
> breaks viewport, could I bind it? I would send a patch. Also, would it
> be possible to implement ESC:wq, i.e. regular way of leaving vim-like
> editor.

bindkey extensions ought to be unproblematic --- you'll see there's
already a zed keymap which binds ^x^w to accept-line.

What we really need is to separate that out so we can set up a default
keyboard and map early before zed actually runs, giving the user the
opportunity to override it.  Perhaps this could be a zed-setup function
that zed will call itself if it hasn't yet been run.

pws

Re: Extending zed

[Sebastian Gniazdowski]

On 4 June 2018 at 11:50, Peter Stephenson <p.stephenson@samsung.com> wrote:
>
> bindkey extensions ought to be unproblematic --- you'll see there's
> already a zed keymap which binds ^x^w to accept-line.

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.


I've added those to zed to check the bindings:
        bindkey -M zed-vicmd | egrep -i '("u"|\^_)'
        bindkey -M zed | egrep -i '("u"|\^_)'
-- 
Best regards,
Sebastian Gniazdowski

Re: Extending zed

[Oliver Kiddle]

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

Re: Extending zed

[Sebastian Gniazdowski]

On 4 June 2018 at 18:08, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> -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.

It hurts me a little too. For my plugin functions, I use "-", i.e.
"-zed_pg_up", but didn't propose this as it is somewhat controversial
– requires to use "--" when handling the function, e.g. when passing
to `autoload -- -zed_pg_up`. But we might take the decision to use
that scheme. Also, completion handling code could use pattern
`[_][^_]`, I do it already in Zplugin. This is also a solution.

> 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.

True, I do following to have fine-grained undo in vim:

inoremap <Space> <Space><C-g>u
inoremap <Tab> <Tab><C-g>u
inoremap <Return> <Return><C-g>u

Although not sure if vim is more end-user than vi, if so Zsh could follow vim.

> 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).

I was using zle -la in Zplugin, z-sy-h used it, then both switched to
use $widgets. Still the argument about idempotent zle -N is valid.

-- 
Best regards,
Sebastian Gniazdowski

Re: Extending zed

[Sebastian Gniazdowski]

śOn Tue, 5 Jun 2018 at 16:40, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> On 4 June 2018 at 18:08, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> > -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.
>
> It hurts me a little too. For my plugin functions, I use "-", i.e.
> "-zed_pg_up", but didn't propose this as it is somewhat controversial
> – requires to use "--" when handling the function, e.g. when passing
> to `autoload -- -zed_pg_up`.

A proposal for a function naming scheme. The prefix and then its description:

- . (dot) - for normal yet private functions, i.e. functions that
shouldn't interfere with command-line completion, i.e. shouldn't be
completed when user enters e.g. "$ z<TAB>",

- + - for IO functions, e.g.: +myprj_print_msg or +myprj-print-msg

- @ - for API-like functions, i.e. functions that are used across
projects, that are exposed for use by some code with another ogigin,
.e.g @myprj-register-hook

- / - for debug-like functions, e.g. /myprj-dbg-print. The slash makes
the function impossible to be autoloaded, but the assumption is that
the debug functions shouldn't need this, at least not that it cannot
be resigned from,

- : - for a handler- or callback-, etc like functions; so e.g.
add-zsh-hook precmd :my-precmd-handler

So an example condensed code would look like this:

.prjid_register_hooks() {
    integer ret
    add-zsh-hook precmd :prjid-precmd-handler; ret+=$?
    /prjid-dmsg "Installed precmd hook with result: $ret"
    @otherprj-notice-hook precmd-hook :prjid-precmd-handler; ret+=$?
    +prjid-print "Initialization complete (errors: $ret)"
}

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

Re: Extending zed

[Peter Stephenson]

On Mon, 4 Jun 2018 10:50:42 +0100
Peter Stephenson <p.stephenson@samsung.com> wrote:
> bindkey extensions ought to be unproblematic --- you'll see there's
> already a zed keymap which binds ^x^w to accept-line.
> 
> What we really need is to separate that out so we can set up a default
> keyboard and map early before zed actually runs, giving the user the
> opportunity to override it.  Perhaps this could be a zed-setup
> function that zed will call itself if it hasn't yet been run.

I'd forgotten zed -b does that.

Still might be neater to separate it out.

pws