* [PATCH] Increase $COLUMNS when generating long option completions @ 2021-08-01 19:24 Marlon Richert 2021-08-01 23:06 ` Bart Schaefer 0 siblings, 1 reply; 15+ messages in thread From: Marlon Richert @ 2021-08-01 19:24 UTC (permalink / raw) To: Zsh hackers list [-- Attachment #1: Type: text/plain, Size: 67 bytes --] Otherwise, option descriptions can appear cropped on wide screens. [-- Attachment #2: 0001-Increase-COLUMNS-when-generating-long-option-complet.txt --] [-- Type: text/plain, Size: 1047 bytes --] From 2075b9f42cb9f0ad3cd1ac330302208048d65a25 Mon Sep 17 00:00:00 2001 From: Marlon Richert <marlonrichert@users.noreply.github.com> Date: Sun, 1 Aug 2021 22:22:14 +0300 Subject: [PATCH] Increase $COLUMNS when generating long option completions Otherwise, option descriptions can appear cropped on wide screens. --- Completion/Base/Utility/_arguments | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Completion/Base/Utility/_arguments b/Completion/Base/Utility/_arguments index 3f1b39304..5db3926fb 100644 --- a/Completion/Base/Utility/_arguments +++ b/Completion/Base/Utility/_arguments @@ -95,7 +95,9 @@ if (( long )); then # option up to the end. tmp=() - _call_program $lflag options ${~words[1]} --help 2>&1 | + + # Increase $COLUMNS, so --help output won't get cropped. + _call_program $lflag options COLUMNS=999 ${~words[1]} --help 2>&1 | while IFS= read -r opt; do if (( ${#tmp} )); then # Previous line had no comment. Is the current one suitable? -- 2.30.1 (Apple Git-130) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-01 19:24 [PATCH] Increase $COLUMNS when generating long option completions Marlon Richert @ 2021-08-01 23:06 ` Bart Schaefer 2021-08-03 14:05 ` Marlon Richert 0 siblings, 1 reply; 15+ messages in thread From: Bart Schaefer @ 2021-08-01 23:06 UTC (permalink / raw) To: Marlon Richert; +Cc: Zsh hackers list I'm puzzled, doesn't this imply that the value of $COLUMNS is incorrect on entry to the function? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-01 23:06 ` Bart Schaefer @ 2021-08-03 14:05 ` Marlon Richert 2021-08-04 1:12 ` Lawrence Velázquez 0 siblings, 1 reply; 15+ messages in thread From: Marlon Richert @ 2021-08-03 14:05 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh hackers list On Mon, Aug 2, 2021 at 2:07 AM Bart Schaefer <schaefer@brasslantern.com> wrote: > > I'm puzzled, doesn't this imply that the value of $COLUMNS is > incorrect on entry to the function? No, the problem results from _call_program being connected to a pipe: _call_program $lflag options ${~words[1]} --help 2>&1 | while IFS= read -r opt; do When ${~words[1]} is an external command, it will then not see $COLUMNS, unless $COLUMNS has been exported. For example, compare the output of the following: % pip3 --help % _call_program tst pip3 --help % _call_program tst pip3 --help | cat % print -r -- "$( pip3 --help )" The first two will produce output that is as wide as the terminal, whereas the latter two will always produce 80 columns of output. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-03 14:05 ` Marlon Richert @ 2021-08-04 1:12 ` Lawrence Velázquez 2021-08-04 3:48 ` Bart Schaefer 2021-08-04 6:51 ` Marlon Richert 0 siblings, 2 replies; 15+ messages in thread From: Lawrence Velázquez @ 2021-08-04 1:12 UTC (permalink / raw) To: Marlon Richert, Bart Schaefer; +Cc: zsh-workers On Tue, Aug 3, 2021, at 10:05 AM, Marlon Richert wrote: > On Mon, Aug 2, 2021 at 2:07 AM Bart Schaefer <schaefer@brasslantern.com> wrote: > > > > I'm puzzled, doesn't this imply that the value of $COLUMNS is > > incorrect on entry to the function? > > No, the problem results from _call_program being connected to a pipe: > > _call_program $lflag options ${~words[1]} --help 2>&1 | > while IFS= read -r opt; do > > When ${~words[1]} is an external command, it will then not see > $COLUMNS, unless $COLUMNS has been exported. Isn't that the case in general? External commands *never* see COLUMNS if it isn't in the environment. The pipe is a red herring. > For example, compare the output of the following: > > % pip3 --help > % _call_program tst pip3 --help > % _call_program tst pip3 --help | cat > % print -r -- "$( pip3 --help )" Seems like pip is behaving differently depending on whether it's outputting to a tty or not. -- vq ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-04 1:12 ` Lawrence Velázquez @ 2021-08-04 3:48 ` Bart Schaefer 2021-08-04 6:51 ` Marlon Richert 1 sibling, 0 replies; 15+ messages in thread From: Bart Schaefer @ 2021-08-04 3:48 UTC (permalink / raw) To: Zsh hackers list On Tue, Aug 3, 2021 at 6:12 PM Lawrence Velázquez <larryv@zsh.org> wrote: > > On Tue, Aug 3, 2021, at 10:05 AM, Marlon Richert wrote: > > > > No, the problem results from _call_program being connected to a pipe: > > > > When ${~words[1]} is an external command, it will then not see > > $COLUMNS, unless $COLUMNS has been exported. > > Isn't that the case in general? External commands *never* see > COLUMNS if it isn't in the environment. I was thinking the same thing. > The pipe is a red herring. Well, not exactly. As you said: > Seems like pip is behaving differently depending on whether it's > outputting to a tty or not. Probably, if the output is a tty then when it finds no $COLUMNS, it reads the width from the tty, and when it has neither it falls back to 80. Still that would argue for using ... COLUMNS=$COLUMNS ${~words[1]} ... That is, export an accurate value rather than an arbitrarily large one. The next question would be, is _arguments the only place this is useful? Or would it be better if _call_program always did so? E.g. local -x COLUMNS ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-04 1:12 ` Lawrence Velázquez 2021-08-04 3:48 ` Bart Schaefer @ 2021-08-04 6:51 ` Marlon Richert 2021-08-04 7:19 ` Lawrence Velázquez 1 sibling, 1 reply; 15+ messages in thread From: Marlon Richert @ 2021-08-04 6:51 UTC (permalink / raw) To: Lawrence Velázquez; +Cc: Bart Schaefer, Zsh hackers list On Wed, Aug 4, 2021 at 4:12 AM Lawrence Velázquez <larryv@zsh.org> wrote: > > On Tue, Aug 3, 2021, at 10:05 AM, Marlon Richert wrote: > > On Mon, Aug 2, 2021 at 2:07 AM Bart Schaefer <schaefer@brasslantern.com> wrote: > > > > > > I'm puzzled, doesn't this imply that the value of $COLUMNS is > > > incorrect on entry to the function? > > > > No, the problem results from _call_program being connected to a pipe: > > > > _call_program $lflag options ${~words[1]} --help 2>&1 | > > while IFS= read -r opt; do > > > > When ${~words[1]} is an external command, it will then not see > > $COLUMNS, unless $COLUMNS has been exported. > > Isn't that the case in general? External commands *never* see > COLUMNS if it isn't in the environment. The pipe is a red herring. > > > For example, compare the output of the following: > > > > % pip3 --help > > % _call_program tst pip3 --help > > % _call_program tst pip3 --help | cat > > % print -r -- "$( pip3 --help )" > > Seems like pip is behaving differently depending on whether it's > outputting to a tty or not. I feel that cannot be the whole story, because if I do any of the following, I get terminal-width output, instead of 80 columns: % COLUMNS=$COLUMNS pip3 --help | cat % print -r -- "$( COLUMNS=$COLUMNS pip3 --help )" % _call_program tst COLUMNS=$COLUMNS pip3 --help | cat And pip isn't the only command that works that way. For example: % ls -x / Applications Library System Users Volumes bin cores dev etc home opt private sbin tmp usr var % ls -x / | cat Applications Library System Users Volumes bin cores dev etc home opt private sbin tmp usr var % COLUMNS=$COLUMNS ls -x / | cat Applications Library System Users Volumes bin cores dev etc home opt private sbin tmp usr var % ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-04 6:51 ` Marlon Richert @ 2021-08-04 7:19 ` Lawrence Velázquez 2021-08-05 6:19 ` Marlon Richert 0 siblings, 1 reply; 15+ messages in thread From: Lawrence Velázquez @ 2021-08-04 7:19 UTC (permalink / raw) To: Marlon Richert; +Cc: Bart Schaefer, Zsh hackers list > On Aug 4, 2021, at 2:53 AM, Marlon Richert <marlon.richert@gmail.com> wrote: > On Wed, Aug 4, 2021 at 4:12 AM Lawrence Velázquez <larryv@zsh.org> wrote: >> >> On Tue, Aug 3, 2021, at 10:05 AM, Marlon Richert wrote: >>> On Mon, Aug 2, 2021 at 2:07 AM Bart Schaefer <schaefer@brasslantern.com> wrote: >>>> I'm puzzled, doesn't this imply that the value of $COLUMNS is >>>> incorrect on entry to the function? >>> No, the problem results from _call_program being connected to a pipe: >>> _call_program $lflag options ${~words[1]} --help 2>&1 | >>> while IFS= read -r opt; do >>> When ${~words[1]} is an external command, it will then not see >>> $COLUMNS, unless $COLUMNS has been exported. >> >> Isn't that the case in general? External commands *never* see >> COLUMNS if it isn't in the environment. The pipe is a red herring. >> >>> For example, compare the output of the following: >>> % pip3 --help >>> % _call_program tst pip3 --help >>> % _call_program tst pip3 --help | cat >>> % print -r -- "$( pip3 --help )" >> >> Seems like pip is behaving differently depending on whether it's >> outputting to a tty or not. > > I feel that cannot be the whole story, because if I do any of the > following, I get terminal-width output, instead of 80 columns: > > % COLUMNS=$COLUMNS pip3 --help | cat > % print -r -- "$( COLUMNS=$COLUMNS pip3 --help )" Yes, these commands are explicitly setting COLUMNS in pip’s environment. As Bart said, the tty vs. not-tty distinction probably only matters when COLUMNS is not in pip’s environment. > % _call_program tst COLUMNS=$COLUMNS pip3 --help | cat > > And pip isn't the only command that works that way. For example: > > % ls -x / > Applications Library System Users Volumes bin cores dev etc home > opt private sbin tmp usr var > % ls -x / | cat > Applications Library System Users Volumes > bin cores dev etc home > opt private sbin tmp usr > var > % COLUMNS=$COLUMNS ls -x / | cat > Applications Library System Users Volumes bin cores dev etc home > opt private sbin tmp usr var > % Same thing here. You are explicitly setting COLUMNS in the environment of ls, and ls is respecting it. -- vq Sent from my iPhone ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-04 7:19 ` Lawrence Velázquez @ 2021-08-05 6:19 ` Marlon Richert 2021-08-05 6:24 ` Bart Schaefer 0 siblings, 1 reply; 15+ messages in thread From: Marlon Richert @ 2021-08-05 6:19 UTC (permalink / raw) To: Lawrence Velázquez; +Cc: Bart Schaefer, Zsh hackers list On Wed, Aug 4, 2021 at 10:19 AM Lawrence Velázquez <larryv@zsh.org> wrote: > > Yes, these commands are explicitly setting COLUMNS in pip’s environment. As Bart said, the tty vs. not-tty distinction probably only matters when COLUMNS is not in pip’s environment. > > Same thing here. You are explicitly setting COLUMNS in the environment of ls, and ls is respecting it. OK. Thanks for clearing that up. I don't think this all changes anything about the patch, though? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-05 6:19 ` Marlon Richert @ 2021-08-05 6:24 ` Bart Schaefer 2021-08-05 18:11 ` Marlon Richert 0 siblings, 1 reply; 15+ messages in thread From: Bart Schaefer @ 2021-08-05 6:24 UTC (permalink / raw) To: Marlon Richert; +Cc: Lawrence Velázquez, Zsh hackers list On Wed, Aug 4, 2021 at 11:20 PM Marlon Richert <marlon.richert@gmail.com> wrote: > > I don't think this all changes anything about the patch, though? On Tue, Aug 3, 2021 at 8:48 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > The next question would be, is _arguments the only place this is > useful? Or would it be better if _call_program always did so? E.g. > local -x COLUMNS If the answer to that is to leave it in _arguments, then I think COLUMNS=$COLUMNS is preferable to COLUMNS=999 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-05 6:24 ` Bart Schaefer @ 2021-08-05 18:11 ` Marlon Richert 2021-08-05 23:44 ` Bart Schaefer 0 siblings, 1 reply; 15+ messages in thread From: Marlon Richert @ 2021-08-05 18:11 UTC (permalink / raw) To: Bart Schaefer; +Cc: Lawrence Velázquez, Zsh hackers list On Thu, Aug 5, 2021 at 9:24 AM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Wed, Aug 4, 2021 at 11:20 PM Marlon Richert <marlon.richert@gmail.com> wrote: > > > > I don't think this all changes anything about the patch, though? > > On Tue, Aug 3, 2021 at 8:48 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > > > The next question would be, is _arguments the only place this is > > useful? Or would it be better if _call_program always did so? E.g. > > local -x COLUMNS Sorry, I missed this. I don't know if it makes sense to always set COLUMNS in _call_program, because it is not always called to produce visual output. On the other hand, if you think it won't hurt, then yes, that might be a better option. > If the answer to that is to leave it in _arguments, then I think > COLUMNS=$COLUMNS is preferable to COLUMNS=999 I made it 999, rather than $COLUMNS, because the output is cached and terminal emulators can be resized. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-05 18:11 ` Marlon Richert @ 2021-08-05 23:44 ` Bart Schaefer 2021-08-07 19:55 ` Marlon Richert 0 siblings, 1 reply; 15+ messages in thread From: Bart Schaefer @ 2021-08-05 23:44 UTC (permalink / raw) To: Marlon Richert; +Cc: Zsh hackers list On Thu, Aug 5, 2021 at 11:12 AM Marlon Richert <marlon.richert@gmail.com> wrote: > > I don't know if it makes sense to always set > COLUMNS in _call_program, because it is not always called to produce > visual output. On the other hand, if you think it won't hurt, then > yes, that might be a better option. I can't think of a case where it would be an issue ... if the program isn't producing output meant for the terminal, it shouldn't be bothered by either the presence or absence of $COLUMNS. I'm now pondering whether your original method does either a better or a worse (or neither) job if the called program uses a remote shell or the like. > I made it 999, rather than $COLUMNS, because the output is cached and > terminal emulators can be resized. Hrm. That sounds like a problem with the cache validation rules, but I suppose setting a large value of COLUMNS is a reasonable safeguard. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-05 23:44 ` Bart Schaefer @ 2021-08-07 19:55 ` Marlon Richert 2021-08-07 22:41 ` Bart Schaefer 0 siblings, 1 reply; 15+ messages in thread From: Marlon Richert @ 2021-08-07 19:55 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh hackers list [-- Attachment #1: Type: text/plain, Size: 1052 bytes --] On Fri, Aug 6, 2021 at 2:44 AM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Thu, Aug 5, 2021 at 11:12 AM Marlon Richert <marlon.richert@gmail.com> wrote: > > > > I don't know if it makes sense to always set > > COLUMNS in _call_program, because it is not always called to produce > > visual output. On the other hand, if you think it won't hurt, then > > yes, that might be a better option. > > I can't think of a case where it would be an issue ... if the program > isn't producing output meant for the terminal, it shouldn't be > bothered by either the presence or absence of $COLUMNS. I'm now > pondering whether your original method does either a better or a worse > (or neither) job if the called program uses a remote shell or the > like. > > > I made it 999, rather than $COLUMNS, because the output is cached and > > terminal emulators can be resized. > > Hrm. That sounds like a problem with the cache validation rules, but > I suppose setting a large value of COLUMNS is a reasonable safeguard. How does this patch look to you? [-- Attachment #2: 0001-Set-COLUMNS-in-_call_program-to-ensure-cached-comman.txt --] [-- Type: text/plain, Size: 1423 bytes --] From 1912a575fbdf34e4937eeea9387807351342fc37 Mon Sep 17 00:00:00 2001 From: Marlon Richert <marlonrichert@users.noreply.github.com> Date: Sat, 7 Aug 2021 22:52:21 +0300 Subject: [PATCH] Set $COLUMNS in _call_program to ensure cached command output is sufficiently wide --- Completion/Base/Utility/_call_program | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/Completion/Base/Utility/_call_program b/Completion/Base/Utility/_call_program index 73f3ef6d2..cc7c9adf9 100644 --- a/Completion/Base/Utility/_call_program +++ b/Completion/Base/Utility/_call_program @@ -1,6 +1,7 @@ #autoload +X -local curcontext="${curcontext}" tmp err_fd=-1 clocale='_comp_locale;' +local cmd clocale='_comp_locale;' cols='COLUMNS=999' curcontext="${curcontext}" +local -i err_fd=-1 local -a prefix if [[ "$1" = -p ]]; then @@ -22,14 +23,14 @@ fi { # Begin "always" block -if zstyle -s ":completion:${curcontext}:${1}" command tmp; then - if [[ "$tmp" = -* ]]; then - eval $clocale "$tmp[2,-1]" "$argv[2,-1]" +if zstyle -s ":completion:${curcontext}:${1}" command cmd; then + if [[ "$cmd" = -* ]]; then + eval $clocale $cols "$cmd[2,-1]" "$argv[2,-1]" else - eval $clocale $prefix "$tmp" + eval $clocale $cols $prefix "$cmd" fi else - eval $clocale $prefix "$argv[2,-1]" + eval $clocale $cols $prefix "$argv[2,-1]" fi 2>&$err_fd } always { -- 2.30.1 (Apple Git-130) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-07 19:55 ` Marlon Richert @ 2021-08-07 22:41 ` Bart Schaefer 2021-08-10 19:04 ` Marlon Richert 0 siblings, 1 reply; 15+ messages in thread From: Bart Schaefer @ 2021-08-07 22:41 UTC (permalink / raw) To: Marlon Richert; +Cc: Zsh hackers list On Sat, Aug 7, 2021 at 12:56 PM Marlon Richert <marlon.richert@gmail.com> wrote: > > How does this patch look to you? Frankly, it looks unnecessarily complicated. What's the rationale for using COLUMNS=999 as a command prefix in every "eval", rather than just declaring once local -x COLUMNS=999 at the start of the function?? Why rearrange the other declarations? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-07 22:41 ` Bart Schaefer @ 2021-08-10 19:04 ` Marlon Richert 2021-08-10 19:17 ` Marlon Richert 0 siblings, 1 reply; 15+ messages in thread From: Marlon Richert @ 2021-08-10 19:04 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh hackers list [-- Attachment #1: Type: text/plain, Size: 529 bytes --] On Sun, Aug 8, 2021 at 1:41 AM Bart Schaefer <schaefer@brasslantern.com> wrote: > > On Sat, Aug 7, 2021 at 12:56 PM Marlon Richert <marlon.richert@gmail.com> wrote: > > > > How does this patch look to you? > > Frankly, it looks unnecessarily complicated. What's the rationale for > using COLUMNS=999 as a command prefix in every "eval", rather than > just declaring once > local -x COLUMNS=999 > at the start of the function?? Why rearrange the other declarations? TIL you can export parameters locally. Here's a new patch. [-- Attachment #2: 0001-Set-COLUMNS-in-_call_program-to-ensure-cached-comman.txt --] [-- Type: text/plain, Size: 728 bytes --] From 0f7ed76a199710b1323c12cc7e7e17fb10f5f748 Mon Sep 17 00:00:00 2001 From: Marlon Richert <marlon.richert@gmail.com> Date: Tue, 10 Aug 2021 22:02:11 +0300 Subject: [PATCH] Set $COLUMNS in _call_program to ensure cached command output is sufficiently wide --- Completion/Base/Utility/_call_program | 1 + 1 file changed, 1 insertion(+) diff --git a/Completion/Base/Utility/_call_program b/Completion/Base/Utility/_call_program index 73f3ef6d2..55712b04b 100644 --- a/Completion/Base/Utility/_call_program +++ b/Completion/Base/Utility/_call_program @@ -1,5 +1,6 @@ #autoload +X +local -xi COLUMNS=999 local curcontext="${curcontext}" tmp err_fd=-1 clocale='_comp_locale;' local -a prefix -- 2.30.1 (Apple Git-130) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Increase $COLUMNS when generating long option completions 2021-08-10 19:04 ` Marlon Richert @ 2021-08-10 19:17 ` Marlon Richert 0 siblings, 0 replies; 15+ messages in thread From: Marlon Richert @ 2021-08-10 19:17 UTC (permalink / raw) To: Bart Schaefer; +Cc: Zsh hackers list [-- Attachment #1: Type: text/plain, Size: 713 bytes --] On Tue, Aug 10, 2021 at 10:04 PM Marlon Richert <marlon.richert@gmail.com> wrote: > > On Sun, Aug 8, 2021 at 1:41 AM Bart Schaefer <schaefer@brasslantern.com> wrote: > > > > On Sat, Aug 7, 2021 at 12:56 PM Marlon Richert <marlon.richert@gmail.com> wrote: > > > > > > How does this patch look to you? > > > > Frankly, it looks unnecessarily complicated. What's the rationale for > > using COLUMNS=999 as a command prefix in every "eval", rather than > > just declaring once > > local -x COLUMNS=999 > > at the start of the function?? Why rearrange the other declarations? > > TIL you can export parameters locally. Here's a new patch. And since we're on the topic, this patch adds `-x` to `local` completion. [-- Attachment #2: 0001-Complete-local-x.txt --] [-- Type: text/plain, Size: 779 bytes --] From 8742ba63ebccbba1c367663094e0f1c10dd2107b Mon Sep 17 00:00:00 2001 From: Marlon Richert <marlon.richert@gmail.com> Date: Tue, 10 Aug 2021 22:11:28 +0300 Subject: [PATCH] Complete `local -x` --- Completion/Zsh/Command/_typeset | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Completion/Zsh/Command/_typeset b/Completion/Zsh/Command/_typeset index 3f7de9706..5f7fb24fa 100644 --- a/Completion/Zsh/Command/_typeset +++ b/Completion/Zsh/Command/_typeset @@ -69,7 +69,7 @@ case ${service} in allargs[i]='-i+[specify arithmetic base for output]:: :_guard "[0-9]#" base' \ ;; readonly) use="${use/r/}" ;; - local) use="${use/[fkz]/}" ;& + local) use="${use/[fgkz]/}" ;; export) use="${${use//[gkz]/}/x/}" ;; esac -- 2.30.1 (Apple Git-130) ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-08-10 19:17 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-08-01 19:24 [PATCH] Increase $COLUMNS when generating long option completions Marlon Richert 2021-08-01 23:06 ` Bart Schaefer 2021-08-03 14:05 ` Marlon Richert 2021-08-04 1:12 ` Lawrence Velázquez 2021-08-04 3:48 ` Bart Schaefer 2021-08-04 6:51 ` Marlon Richert 2021-08-04 7:19 ` Lawrence Velázquez 2021-08-05 6:19 ` Marlon Richert 2021-08-05 6:24 ` Bart Schaefer 2021-08-05 18:11 ` Marlon Richert 2021-08-05 23:44 ` Bart Schaefer 2021-08-07 19:55 ` Marlon Richert 2021-08-07 22:41 ` Bart Schaefer 2021-08-10 19:04 ` Marlon Richert 2021-08-10 19:17 ` Marlon Richert
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).