On Thu, Mar 9, 2023 at 9:13 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> We're suggesting something like
>
> .zle.layout=$'\n\n\n\n\n\n\n\n\n\n\n\n\n\n etc etc'
>
> and then the spdist function would read the value of that variable.
There are at least 8 existing parameters that could be mapped into a
"zle" namespace:
zle_bracketed_paste
zle_highlight
ZLE_LINE_ABORTED
ZLE_RECURSIVE
ZLE_STATE
ZLE_REMOVE_SUFFIX_CHARS
ZLE_RPROMPT_INDENT
ZLE_SPACE_SUFFIX_CHARS
There are a couple of dozen more like BUFFER and CURSOR that could be
in "zle" but might fit better in a "widget" namespace. Of course it
would be a while before we could retire the existing names, and
because most of those variables act like locals there's less benefit
to isolating them.
It occurs to me that the CORRECT options and their behavior do not
depend on ZLE being active, so it might not be appropriate to put
keyboard layouts in that namespace. There are also the parameters
CORRECT_IGNORE and CORRECT_IGNORE_FILE to consider. Reserving
"correct" as a namespace feels odd as well, but I think mostly because
it can be used as both a verb and an adjective. Other ideas?
Other namespaces to reserve? For example there are a number of
variables starting with "zsh" though again there'd be a long period of
overlap.
I'm not fully following, but is this about adding namespace.*
prefixes? Like zle.CURSOR, for example?
On Sat, 11 Mar 2023 at 04:56, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Thu, Mar 9, 2023 at 9:13 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > We're suggesting something like
> >
> > .zle.layout=$'\n\n\n\n\n\n\n\n\n\n\n\n\n\n etc etc'
> >
> > and then the spdist function would read the value of that variable.
>
> There are at least 8 existing parameters that could be mapped into a
> "zle" namespace:
>
> zle_bracketed_paste
> zle_highlight
> ZLE_LINE_ABORTED
> ZLE_RECURSIVE
> ZLE_STATE
>
> ZLE_REMOVE_SUFFIX_CHARS
> ZLE_RPROMPT_INDENT
> ZLE_SPACE_SUFFIX_CHARS
>
> There are a couple of dozen more like BUFFER and CURSOR that could be
> in "zle" but might fit better in a "widget" namespace. Of course it
> would be a while before we could retire the existing names, and
> because most of those variables act like locals there's less benefit
> to isolating them.
>
> It occurs to me that the CORRECT options and their behavior do not
> depend on ZLE being active, so it might not be appropriate to put
> keyboard layouts in that namespace. There are also the parameters
> CORRECT_IGNORE and CORRECT_IGNORE_FILE to consider. Reserving
> "correct" as a namespace feels odd as well, but I think mostly because
> it can be used as both a verb and an adjective. Other ideas?
>
> Other namespaces to reserve? For example there are a number of
> variables starting with "zsh" though again there'd be a long period of
> overlap.
>
--
Best regards,
Sebastian Gniazdowski
On Sat, Mar 11, 2023 at 2:01 AM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> I'm not fully following, but is this about adding namespace.*
> prefixes? Like zle.CURSOR, for example?
Yes, though it would be ".zle.CURSOR" or possibly just ".zle.cursor"
since we'd no longer have to worry as much about name collisions with
users' variables.
yes, nice. I would go for zle.CURSOR, it's looking worse than zle.cursor,
however it follows upcase↔scalar convention.
On Sat, 11 Mar 2023 at 19:47, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> On Sat, Mar 11, 2023 at 2:01 AM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
> >
> > I'm not fully following, but is this about adding namespace.*
> > prefixes? Like zle.CURSOR, for example?
>
> Yes, though it would be ".zle.CURSOR" or possibly just ".zle.cursor"
> since we'd no longer have to worry as much about name collisions with
> users' variables.
--
Best regards,
Sebastian Gniazdowski
On 3/12/23 05:24, Sebastian Gniazdowski wrote:
> yes, nice. I would go for zle.CURSOR, it's looking worse than zle.cursor,
> however it follows upcase↔scalar convention.
>
That convention, as noted by bart, was to avoid name collisions with user variables.
Something that wouldn't be an issue with this, from what i understand.
Will be creating own namespaces allowed? It would be good, for
example, to create `my_plugin` namespace, instead of hash (typeset -gA
MyPlugin, e.g.), to store plugin's state. It would also serve as a
quite good poor man's nested vars.
On Sun, 12 Mar 2023 at 09:24, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> yes, nice. I would go for zle.CURSOR, it's looking worse than zle.cursor,
> however it follows upcase↔scalar convention.
>
>
> On Sat, 11 Mar 2023 at 19:47, Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > On Sat, Mar 11, 2023 at 2:01 AM Sebastian Gniazdowski
> > <sgniazdowski@gmail.com> wrote:
> > >
> > > I'm not fully following, but is this about adding namespace.*
> > > prefixes? Like zle.CURSOR, for example?
> >
> > Yes, though it would be ".zle.CURSOR" or possibly just ".zle.cursor"
> > since we'd no longer have to worry as much about name collisions with
> > users' variables.
>
>
>
> --
> Best regards,
> Sebastian Gniazdowski
--
Best regards,
Sebastian Gniazdowski
On Sun, Mar 12, 2023 at 9:46 AM Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > > Will be creating own namespaces allowed? Yes ... as of the current patches, namespaces are not significant except that parameters in namespaces don't show up in "set" / "typeset" output (unless asked for). It's an unresolved question whether to implement the ksh "namespace" keyword and its effects. This thread is about whether (and potentially which) identifiers we want to declare as reserved for the shell's own purposes. To that end ... On Fri, Mar 10, 2023 at 8:56 PM Bart Schaefer <schaefer@brasslantern.com> wrote: > > It occurs to me that the CORRECT options and their behavior do not > depend on ZLE being active, so it might not be appropriate to put > keyboard layouts in that namespace. There are also the parameters > CORRECT_IGNORE and CORRECT_IGNORE_FILE to consider. Reserving > "correct" as a namespace feels odd as well, but I think mostly because > it can be used as both a verb and an adjective. Other ideas? I'm presently thinking about a namespace "interact" to group variables that apply only (or mostly) to interactive shells. Then for the original "Colemak" question we'd have something like: typeset -gA .interact.keyboards=( [QWERTY]=$'\n\n\n\n\n\n\n\n\n\n\n\n\n\n'\ $'\t1234567890-=\t'\ $'\tqwertyuiop[]\t'\ $'\tasdfghjkl;\'\n\t'\ $'\tzxcvbnm,./\t\t\t'\ $'\n\n\n\n\n\n\n\n\n\n\n\n\n\n'\ $'\t!@#$%^&*()_+\t'\ $'\tQWERTYUIOP{}\t'\ $'\tASDFGHJKL:\"\n\t'\ $'\tZXCVBNM<>?\n\n\t'\ $'\n\n\n\n\n\n\n\n\n\n\n\n\n\n' [Dvorak]=$'\n\n\n\n\n\n\n\n\n\n\n\n\n\n'\ $'\t1234567890[]\t'\ $'\t\',.pyfgcrl/=\t'\ $'\taoeuidhtns-\n\t'\ $'\t;qjkxbmwvz\t\t\t'\ $'\n\n\n\n\n\n\n\n\n\n\n\n\n\n'\ $'\t!@#$%^&*(){}\t'\ $'\t\"<>PYFGCRL?+\t'\ $'\tAOEUIDHTNS_\n\t'\ $'\t:QJKXBMWVZ\n\n\t'\ $'\n\n\n\n\n\n\n\n\n\n\n\n\n\n' [Colemak]=$'\n\n\n\n\n\n\n\n\n\n\n\n\n\n'\ $'\t1234567890-=\t'\ $'\tqwfpgjluy;[]\t'\ $'\tarstdhneio\'\n\t'\ $'\tzxcvbkm,./\t\t\t'\ $'\n\n\n\n\n\n\n\n\n\n\n\n\n\n'\ $'\t!@#$%^&*()_+\t'\ $'\tQWFPGJLUY:{}\t'\ $'\tARSTDHNEIO\"\n\t'\ $'\tZXCVBKM<>?\n\n\t'\ $'\n\n\n\n\n\n\n\n\n\n\n\n\n\n' ) .interact.layout=${.interact.keyboards[Colemak]} and change utils.c:spdist() to check getsparam(".interact.layout") before examining the DVORAK option (for backward compatibility).