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

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 12/20/23, Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx> wrote:
>> On 20/12/2023 16:04 GMT Mark J. Reed <markjreed@xxxxxxxxx> 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