* Possible issue with Completion/Unix/Type/_date_formats return value
@ 2021-01-20 22:43 Jacob Menke
2021-01-26 23:37 ` Daniel Shahaf
0 siblings, 1 reply; 4+ messages in thread
From: Jacob Menke @ 2021-01-20 22:43 UTC (permalink / raw)
To: zsh-workers
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
Hello,
I was wondering if _date_formats has an improper return value.
When called from _date (when $1 is unset, thus $1 == zsh is
false) _date_formats always returns 1 even when matches are generated from
_describe. This causes completion to continue erroneously.
Last two lines are shown:
_describe -t date-format-specifier 'date format specifier' specs \
-p "${(Q)PREFIX:-%}" -S ''
[[ $1 == zsh ]] && _message -e date-format-precision 'precision for %%.
(1-9)'
I believe the return value of _describe should be returned either by making
_describe last statement or storing its value in local var ret and then
returning ret.
Thanks,
Jacob Menke
[-- Attachment #2: Type: text/html, Size: 887 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible issue with Completion/Unix/Type/_date_formats return value
2021-01-20 22:43 Possible issue with Completion/Unix/Type/_date_formats return value Jacob Menke
@ 2021-01-26 23:37 ` Daniel Shahaf
2021-01-28 9:40 ` Jacob Menke
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Shahaf @ 2021-01-26 23:37 UTC (permalink / raw)
To: Jacob Menke; +Cc: zsh-workers
Jacob Menke wrote on Wed, Jan 20, 2021 at 17:43:31 -0500:
> Hello,
>
> I was wondering if _date_formats has an improper return value.
>
> When called from _date (when $1 is unset, thus $1 == zsh is
> false) _date_formats always returns 1 even when matches are generated from
> _describe. This causes completion to continue erroneously.
>
> Last two lines are shown:
> _describe -t date-format-specifier 'date format specifier' specs
> -p "${(Q)PREFIX:-%}" -S ''
> [[ $1 == zsh ]] && _message -e date-format-precision 'precision for %%.(1-9)'
>
> I believe the return value of _describe should be returned either by making
> _describe last statement or storing its value in local var ret and then
> returning ret.
Thanks for the report and sorry for the late answer. I agree that it's wrong
as it stands. Anyone wants to take it from here?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible issue with Completion/Unix/Type/_date_formats return value
2021-01-26 23:37 ` Daniel Shahaf
@ 2021-01-28 9:40 ` Jacob Menke
2021-01-28 18:39 ` Daniel Shahaf
0 siblings, 1 reply; 4+ messages in thread
From: Jacob Menke @ 2021-01-28 9:40 UTC (permalink / raw)
To: Daniel Shahaf; +Cc: zsh-workers
[-- Attachment #1.1: Type: text/plain, Size: 1599 bytes --]
Sure,
Patch is attached and here:
diff --git a/Completion/Unix/Type/_date_formats
b/Completion/Unix/Type/_date_formats
index 889a9577..226e1ef7 100644
--- a/Completion/Unix/Type/_date_formats
+++ b/Completion/Unix/Type/_date_formats
@@ -1,6 +1,6 @@
#autoload
-local flag
+local flag ret=1
local -aU specs
local -A exclusion
@@ -106,5 +106,6 @@ for flag in ${(s..)PREFIX#%}; do
done
_describe -t date-format-specifier 'date format specifier' specs \
- -p "${(Q)PREFIX:-%}" -S ''
+ -p "${(Q)PREFIX:-%}" -S '' && ret=0
[[ $1 == zsh ]] && _message -e date-format-precision 'precision for %%. (1-9)'
+return ret
On Tue, 26 Jan 2021 at 18:37, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Jacob Menke wrote on Wed, Jan 20, 2021 at 17:43:31 -0500:
> > Hello,
> >
> > I was wondering if _date_formats has an improper return value.
> >
> > When called from _date (when $1 is unset, thus $1 == zsh is
> > false) _date_formats always returns 1 even when matches are generated
> from
> > _describe. This causes completion to continue erroneously.
> >
> > Last two lines are shown:
> > _describe -t date-format-specifier 'date format specifier' specs
> > -p "${(Q)PREFIX:-%}" -S ''
> > [[ $1 == zsh ]] && _message -e date-format-precision 'precision for
> %%.(1-9)'
> >
> > I believe the return value of _describe should be returned either by
> making
> > _describe last statement or storing its value in local var ret and then
> > returning ret.
>
> Thanks for the report and sorry for the late answer. I agree that it's
> wrong
> as it stands. Anyone wants to take it from here?
>
[-- Attachment #1.2: Type: text/html, Size: 2216 bytes --]
[-- Attachment #2: _date_format-ret.patch --]
[-- Type: application/octet-stream, Size: 591 bytes --]
diff --git a/Completion/Unix/Type/_date_formats b/Completion/Unix/Type/_date_formats
index 889a9577..226e1ef7 100644
--- a/Completion/Unix/Type/_date_formats
+++ b/Completion/Unix/Type/_date_formats
@@ -1,6 +1,6 @@
#autoload
-local flag
+local flag ret=1
local -aU specs
local -A exclusion
@@ -106,5 +106,6 @@ for flag in ${(s..)PREFIX#%}; do
done
_describe -t date-format-specifier 'date format specifier' specs \
- -p "${(Q)PREFIX:-%}" -S ''
+ -p "${(Q)PREFIX:-%}" -S '' && ret=0
[[ $1 == zsh ]] && _message -e date-format-precision 'precision for %%. (1-9)'
+return ret
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible issue with Completion/Unix/Type/_date_formats return value
2021-01-28 9:40 ` Jacob Menke
@ 2021-01-28 18:39 ` Daniel Shahaf
0 siblings, 0 replies; 4+ messages in thread
From: Daniel Shahaf @ 2021-01-28 18:39 UTC (permalink / raw)
To: Jacob Menke; +Cc: zsh-workers
Jacob Menke wrote on Thu, Jan 28, 2021 at 04:40:46 -0500:
> Patch is attached and here:
Thanks a lot! Will leave it for someone else to review/apply, though.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-01-28 18:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-20 22:43 Possible issue with Completion/Unix/Type/_date_formats return value Jacob Menke
2021-01-26 23:37 ` Daniel Shahaf
2021-01-28 9:40 ` Jacob Menke
2021-01-28 18:39 ` Daniel Shahaf
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).