[BUG] multibyte never set according to setopt/unsetopt output

[BUG] multibyte never set according to setopt/unsetopt output

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

5.9, running on macOS. zsh fires up with multibyte enabled by default,
which is visible in the way it handles multibyte characters (e.g. x=ā; echo
$#x shows 1). I can turn the option off, and the behavior changes (e.g. the
same parameter has a length of 2).

But `unsetopt` always shows `nomultibyte`, and `setopt` never shows
`multibyte`, regardless of the actual setting.

--
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 760 bytes --]

Re: [BUG] multibyte never set according to setopt/unsetopt output

[Peter Stephenson]

> On 20/12/2023 16:04 GMT Mark J. Reed <markjreed@gmail.com> wrote:
> 
> 
> 5.9, running on macOS. zsh fires up with multibyte enabled by default, which is visible in the way it handles multibyte characters (e.g. x=ā; echo $#xshows 1). I can turn the option off, and the behavior changes (e.g. the same parameter has a length of 2). 
> 
> But `unsetopt` always shows `nomultibyte`, and `setopt` never shows `multibyte`, regardless of the actual setting.

You've fallen foul of the slightly odd way that options are shown by default.

The key phrase in the manual for setopt is "minimize the differences from
the default options".  Since multibyte is on by default, it's not a
difference.

You should find if you unset it, however, that it shows up in setopt
as "nomultibyte".  If it didn't (it does for me but I'm on a recent
unreleased version) that would indeed be a bug.

If you want this to be a bit more rational, try "setopt kshoptionprint"
which I use myself (except when trying out the above).  It's still a
bit quirky as it shows nomultibyte as off or on, i.e. it's still
trying to show you differences form the default.

I don't know of a "just show the **** options" option but it's possible
as a function...

pws

Re: [BUG] multibyte never set according to setopt/unsetopt output

[Bart Schaefer]

On Wed, Dec 20, 2023 at 8:22 AM Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
>
> I don't know of a "just show the **** options" option

There isn't one, but "set -o" will do what you want, I think.

Re: [BUG] multibyte never set according to setopt/unsetopt output

[Mikael Magnusson]

On 12/20/23, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Wed, Dec 20, 2023 at 8:22 AM Peter Stephenson
> <p.w.stephenson@ntlworld.com> wrote:
>>
>> I don't know of a "just show the **** options" option
>
> There isn't one, but "set -o" will do what you want, I think.

I usually go for this,
printf '%-20s := %s\n' "${(@kv)options}"

-- 
Mikael Magnusson

Re: [BUG] multibyte never set according to setopt/unsetopt output

[Peter Stephenson]

> On 20/12/2023 16:44 GMT Bart Schaefer <schaefer@brasslantern.com> wrote:
> 
>  
> On Wed, Dec 20, 2023 at 8:22 AM Peter Stephenson
> <p.w.stephenson@ntlworld.com> wrote:
> >
> > I don't know of a "just show the **** options" option
> 
> There isn't one, but "set -o" will do what you want, I think.

That's still not got no negatives, for people who don't not
hate complicated logic, but you can do something like

print -l ${(ko)options//(#m)*/${(r:21:)MATCH} $options[$MATCH]}

pws

Re: [BUG] multibyte never set according to setopt/unsetopt output

[Mikael Magnusson]

On 12/20/23, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>> On 20/12/2023 16:04 GMT Mark J. Reed <markjreed@gmail.com> wrote:
>>
>>
>> 5.9, running on macOS. zsh fires up with multibyte enabled by default,
>> which is visible in the way it handles multibyte characters (e.g. x=ā;
>> echo $#xshows 1). I can turn the option off, and the behavior changes
>> (e.g. the same parameter has a length of 2).
>>
>> But `unsetopt` always shows `nomultibyte`, and `setopt` never shows
>> `multibyte`, regardless of the actual setting.
>
> You've fallen foul of the slightly odd way that options are shown by
> default.
>
> The key phrase in the manual for setopt is "minimize the differences from
> the default options".  Since multibyte is on by default, it's not a
> difference.
>
> You should find if you unset it, however, that it shows up in setopt
> as "nomultibyte".  If it didn't (it does for me but I'm on a recent
> unreleased version) that would indeed be a bug.

To add to this, another quirk is that "unsetopt" does not do 'the same
as setopt but for unset options', but rather it shows all currently
unset options (with their set names, confusingly), while as Peter
mentioned, setopt shows the option set differing from the default (of
the current emulation?) and not inverted like unsetopt does. The
consequence of this is that (since multibyte is on by default), one of
setopt and unsetopt will always show "nomultibyte" in its output :).
(setopt says nomultibyte is set, unsetopt says nomultibyte is unset
(eg multibyte is set)).

-- 
Mikael Magnusson

Re: [BUG] multibyte never set according to setopt/unsetopt output

[Mikael Magnusson]

On 12/20/23, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>
>> On 20/12/2023 16:44 GMT Bart Schaefer <schaefer@brasslantern.com> wrote:
>>
>>
>> On Wed, Dec 20, 2023 at 8:22 AM Peter Stephenson
>> <p.w.stephenson@ntlworld.com> wrote:
>> >
>> > I don't know of a "just show the **** options" option
>>
>> There isn't one, but "set -o" will do what you want, I think.
>
> That's still not got no negatives, for people who don't not
> hate complicated logic, but you can do something like
>
> print -l ${(ko)options//(#m)*/${(r:21:)MATCH} $options[$MATCH]}

Really? I get all options listed in the positive sense regardless of
their state:
% printf '%-20s := %s\n' "${(@kv)options}"|grep '^no'
notify               := off
nomatch              := on

Diffing the output (after adjusting the := format and sorting) shows
an empty diff for me.
% printf '%-21s %s\n' "${(@kv)options}" > mine
% print -l ${(k)options//(#m)*/${(r:21:)MATCH} $options[$MATCH]} > pws
% md5sum mine pws
9bc24b5a4ee8791d4b093f8727e15dd3  mine
9bc24b5a4ee8791d4b093f8727e15dd3  pws

-- 
Mikael Magnusson

Re: [BUG] multibyte never set according to setopt/unsetopt output

[Peter Stephenson]

> On 20/12/2023 17:06 GMT Mikael Magnusson <mikachu@gmail.com> wrote:
> On 12/20/23, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> >> On 20/12/2023 16:44 GMT Bart Schaefer <schaefer@brasslantern.com> wrote:
> Really? I get all options listed in the positive sense regardless of
> their state:

Yours and mine are equivalent, yes, it's the various versions just
using shell builtins that don't seem to allow a no-no form of output,
unless I'm missing something.

pws

Re: [BUG] multibyte never set according to setopt/unsetopt output

[Mikael Magnusson]

On 12/20/23, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>> On 20/12/2023 17:06 GMT Mikael Magnusson <mikachu@gmail.com> wrote:
>> On 12/20/23, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>> >> On 20/12/2023 16:44 GMT Bart Schaefer <schaefer@brasslantern.com>
>> >> wrote:
>> Really? I get all options listed in the positive sense regardless of
>> their state:
>
> Yours and mine are equivalent, yes, it's the various versions just
> using shell builtins that don't seem to allow a no-no form of output,
> unless I'm missing something.

For some reason I thought yours was sent in reply to mine, my
apologies for the confusion.

-- 
Mikael Magnusson

Re: [BUG] multibyte never set according to setopt/unsetopt output

[Mark J. Reed]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

Coming back a bit late to the thread I started a month ago...

Basically, because `multibyte` is on by default, the *`setopt`
commands behave as if there were instead an option with the inverted
meaning named `nomultibyte`, and it is that string rather than `multibyte`
which shows up in the output of one or the other. (I suppose one difference
between the actual situation and the postulated `nomultibyte` option is
that the inversion is `multibyte` rather than *`nonomultibyte`.)

Also, I was misinterpreting the output of `unsetopt`; the presence of
`nomultibyte` in its output means that option is _not_ set, or in other
words, the `multibyte` option _is_ set.

Thanks for the suggestions for alternative ways to display the options.
As far as I can tell, `kshoptionprint` just makes `setopt` produce the same
output as `set -o`; I'm happy to just use `set -o` in that case. I used ksh
for a long time. :)


On Wed, Dec 20, 2023 at 12:40 PM Mikael Magnusson <mikachu@gmail.com> wrote:

> On 12/20/23, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> >> On 20/12/2023 17:06 GMT Mikael Magnusson <mikachu@gmail.com> wrote:
> >> On 12/20/23, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> >> >> On 20/12/2023 16:44 GMT Bart Schaefer <schaefer@brasslantern.com>
> >> >> wrote:
> >> Really? I get all options listed in the positive sense regardless of
> >> their state:
> >
> > Yours and mine are equivalent, yes, it's the various versions just
> > using shell builtins that don't seem to allow a no-no form of output,
> > unless I'm missing something.
>
> For some reason I thought yours was sent in reply to mine, my
> apologies for the confusion.
>
> --
> Mikael Magnusson
>
>

-- 
Mark J. Reed <markjreed@gmail.com>

[-- Attachment #2: Type: text/html, Size: 2667 bytes --]

Re: [BUG] multibyte never set according to setopt/unsetopt output

[Bart Schaefer]

On Fri, Jan 19, 2024 at 7:02 AM Mark J. Reed <markjreed@gmail.com> wrote:
>
> Basically, because `multibyte` is on by default, the *`setopt` commands behave as if there were instead an option with the inverted meaning named `nomultibyte`, and it is that string rather than `multibyte` which shows up

History lesson time for the interested (and who haven't been here all along) ...

Originally most of zsh's options (dozens have been added since) were
based on BSD csh options.  In csh, the defaults were always on, and if
you wanted something to not happen, you had to assert a negative.
Hence for example issuing a "no match" error on a failed glob is
default behavior, and to disable that you assert "nonomatch".
Consequently zsh had "setopt nonomatch" and a number of other options
with a "no" prefix that meant to turn some behavior off.  This led to
a lot of double-negatives when trying to toggle an option via the
"unsetopt" command.

Zsh's first innovation to try to account for this was to start looking
for that leading "no" and reversing the meaning for setopt/unsetopt
based on its presence or absence -- but internally the options were
still named, and therefore documented, in the original forms.

Later (but before the code moved into CVS and thence git, so AFAIK
it's not findable in the commit logs) there was an effort made to
force as many options as possible to be coded and documented in the
"positive" sense, to remove the double negatives internally and make
it possible to do so in scripts -- but the operation of the setopt and
unsetopt commands with respect to a leading "no" was kept unchanged
for backward compatibility, and their respective output still follows
that convention.

Consequently most of the time when a function is asserting a
particular option state, you'll see a single "setopt localoptions"
followed by a mix of options with or without a "no" prefix, because
that's more concise than writing setopt to turn things on and
following that with unsetopt to turn other things off, even though the
option names are now arranged so as to permit exactly that.