New version of the patch attached. Follow-ups to unresolved discussion points below. On 22 Apr 2021, at 00:58, Bart Schaefer wrote: > On Wed, Apr 21, 2021 at 2:28 PM Daniel Shahaf wrote: >> Again, please wrap long lines in your prose. This is the third time you >> are being asked to do so. I would love to, but I’m not sure when it happens (everything looks fine on my end) and I haven’t found an explicit setting for it in my email client. Please let me know if this email has long lines or not. That would help me figure out which combination of settings might be causing this. >> As to PUSHD_MINUS and PUSHD_SILENT, it would be better to give an >> example doesn't change them from their default values. Why exactly? > Using "pushd -q ..." avoids the need for PUSHD_SILENT. Except `pushd -q` has the side effect of "the hook function chpwd and the functions in the array $chpwd_functions are not called" (according to the manual). That’s not something that I would want when changing dirs interactively. >>> + # Move the entire current multiline construct into the editor buffer. This >>> + # function is then aborted and we return to the top-level prompt, which >>> + # triggers the hook above. >>> + zle .push-line-or-edit >>> + return # Not actually necessary, but for clarity's sake >> >> How is it not necessary? If control flow continued past the «esac», >> code would be executed. > > Flow can't continue past «zle .push-line-or-edit» because it invokes > the equivalent of send-break and kills the widget. But I still don't > understand why he wants this here. If I would use push-input instead of push-line-or-edit, the buffer would not get restored immediately after using the widget. You’d end up with a blank command line instead. I want it to work the same from PS2 as it does from PS1. On 22 Apr 2021, at 00:27, Daniel Shahaf wrote: >> +ifnzman(noderef(Miscellaneous))). More precisely, it > > s/it/it:|it+DASH()-/ ? Sorry, I’m new to Yodl. What exactly would that do and why would we need that here? >> +enumeration( >> +myeit() pushes the buffer onto the buffer stack, >> +myeit() executes the supplied arguments, then >> +myeit() lets the ZLE pop the buffer off the top of the buffer stack and load >> + it into the editing buffer. > > Should the precise implementation be documented here? If the > implementation strategy is seen as an API promise, it would be more > difficult to change it later. > > Describing what the function actually _does_ (as distinguished from what > sort of context it's typically used in) is of course relevant; > cf. [workers/45152, fifth hunk]. It’s about the same level of detail as given for run-help, which-command and push-line-or-edit. >> +You can use this, for example, to create key bindings that let you instantly >> +change directories, even while in the middle of typing another command: >> + >> +example(autoload -Uz execute-command >> +setopt autopushd pushdminus pushdsilent > > AUTO_PUSHD is set but not used. If I wouldn’t set it, then the names cd-backward and cd-forward wouldn’t make any sense anymore. > As to PUSHD_MINUS and PUSHD_SILENT, it would be better to give an > example doesn't change them from their default values. That's again > 45149, which I mentioned just yesterday. Let’s suppose the following: I rewrite the example to use `pushd +1` and `pushd -0`, so it works with default shell options. A novice user has PUSHD_MINUS in their config (for whatever reason; they might not even know what it does). They copy-paste the example. Now the widgets won’t work at all as expected. It’s not even the reverse. Setting PUSHD_MINUS in the example guarantees that it will work out of the box for novice users. (More advanced users, I’m sure, will be able to figure out how to modify it to suit their needs.) As for PUSHD_SILENT, as I pointed out above, using `pushd -q` instead has unwanted side effects. It does not have an interchangeable alternative. >> +zle -N cd-upward ; cd-upward() { execute-command cd .. } >> +zle -N cd-backward; cd-backward() { execute-command pushd -1 } >> +zle -N cd-forward ; cd-forward() { execute-command pushd +0 } > > s/()/+LPAR()+RPAR()/ so they don't look like yodl macros (and > potentially throw build-time warnings). (For Vim users, the custom > ftplugin sets up concealing which does the reverse replacement while > editing.) Again, sorry, I’m new to Yodl. What exactly are you suggesting? >> +bindkey '^[^[[A' cd-upward; bindkey '^[^[OA' cd-upward > > -1 on using random escape sequences without any explanation of what they > do and how to find them out. > > Can the symbolic names of these escape sequences be used here? At least > . > % for k v in "${(@kv)terminfo}" ; [[ $v == (*\[A*|*OA*) ]] && echo $k > cuu1 > kcuu1 > . > if we don't have anything more human-readable than those. (I think this > was discussed somewhere in the "default zshrc" thread so I won't > elaborate here.) For cuu1 and cuf1, that would work, but ^[[B and ^[[D do not have entries in terminfo. I don’t think we should use $terminfo[cuu1] and $terminfo[cuf1] in some examples but then hard-code ^[[B and ^[[D elsewhere. Hard-coding all of ^[[{A..D} would be more clear. I’m fine using $terminfo for kcuu1, kcud1, kcuf1 and kcub1. Using $key[Up] would be even better, but we cannot rely on that being set.