* Extending zed @ 2018-06-03 5:57 ` Sebastian Gniazdowski 2018-06-04 8:37 ` Peter Stephenson 0 siblings, 1 reply; 9+ messages in thread From: Sebastian Gniazdowski @ 2018-06-03 5:57 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Extending zed 2018-06-03 5:57 ` Extending zed Sebastian Gniazdowski @ 2018-06-04 8:37 ` Peter Stephenson 2018-06-04 9:41 ` Sebastian Gniazdowski 0 siblings, 1 reply; 9+ messages in thread From: Peter Stephenson @ 2018-06-04 8:37 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Extending zed 2018-06-04 8:37 ` Peter Stephenson @ 2018-06-04 9:41 ` Sebastian Gniazdowski 2018-06-04 9:50 ` Peter Stephenson [not found] ` <20180604105042.69c54bee@camnpupstephen.cam.scsc.local> 0 siblings, 2 replies; 9+ messages in thread From: Sebastian Gniazdowski @ 2018-06-04 9:41 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Extending zed 2018-06-04 9:41 ` Sebastian Gniazdowski @ 2018-06-04 9:50 ` Peter Stephenson 2018-06-04 10:17 ` Sebastian Gniazdowski [not found] ` <20180604105042.69c54bee@camnpupstephen.cam.scsc.local> 1 sibling, 1 reply; 9+ messages in thread From: Peter Stephenson @ 2018-06-04 9:50 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Extending zed 2018-06-04 9:50 ` Peter Stephenson @ 2018-06-04 10:17 ` Sebastian Gniazdowski 2018-06-04 16:08 ` Oliver Kiddle 0 siblings, 1 reply; 9+ messages in thread From: Sebastian Gniazdowski @ 2018-06-04 10:17 UTC (permalink / raw) To: Peter Stephenson; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Extending zed 2018-06-04 10:17 ` Sebastian Gniazdowski @ 2018-06-04 16:08 ` Oliver Kiddle 2018-06-05 14:40 ` Sebastian Gniazdowski 0 siblings, 1 reply; 9+ messages in thread From: Oliver Kiddle @ 2018-06-04 16:08 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Extending zed 2018-06-04 16:08 ` Oliver Kiddle @ 2018-06-05 14:40 ` Sebastian Gniazdowski 2019-07-28 11:01 ` Sebastian Gniazdowski 0 siblings, 1 reply; 9+ messages in thread From: Sebastian Gniazdowski @ 2018-06-05 14:40 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Extending zed 2018-06-05 14:40 ` Sebastian Gniazdowski @ 2019-07-28 11:01 ` Sebastian Gniazdowski 0 siblings, 0 replies; 9+ messages in thread From: Sebastian Gniazdowski @ 2019-07-28 11:01 UTC (permalink / raw) To: Oliver Kiddle; +Cc: Zsh Users ś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 ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20180604105042.69c54bee@camnpupstephen.cam.scsc.local>]
* Re: Extending zed [not found] ` <20180604105042.69c54bee@camnpupstephen.cam.scsc.local> @ 2018-06-04 9:56 ` Peter Stephenson 0 siblings, 0 replies; 9+ messages in thread From: Peter Stephenson @ 2018-06-04 9:56 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-07-29 0:05 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20180603055854epcas5p1e92f5a41384aeb9d1555751df74f57ee@epcas5p1.samsung.com> 2018-06-03 5:57 ` Extending zed 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 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
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).