* Reserved namespaces
@ 2023-03-11 4:56 Bart Schaefer
2023-03-11 10:00 ` Sebastian Gniazdowski
0 siblings, 1 reply; 7+ messages in thread
From: Bart Schaefer @ 2023-03-11 4:56 UTC (permalink / raw)
To: Zsh hackers list
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Reserved namespaces
2023-03-11 4:56 Reserved namespaces Bart Schaefer
@ 2023-03-11 10:00 ` Sebastian Gniazdowski
2023-03-11 19:47 ` Bart Schaefer
0 siblings, 1 reply; 7+ messages in thread
From: Sebastian Gniazdowski @ 2023-03-11 10:00 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh hackers list
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Reserved namespaces
2023-03-11 10:00 ` Sebastian Gniazdowski
@ 2023-03-11 19:47 ` Bart Schaefer
2023-03-12 9:24 ` Sebastian Gniazdowski
0 siblings, 1 reply; 7+ messages in thread
From: Bart Schaefer @ 2023-03-11 19:47 UTC (permalink / raw)
To: Sebastian Gniazdowski; +Cc: Zsh hackers list
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Reserved namespaces
2023-03-11 19:47 ` Bart Schaefer
@ 2023-03-12 9:24 ` Sebastian Gniazdowski
2023-03-12 13:54 ` Eric Cook
2023-03-12 16:46 ` Sebastian Gniazdowski
0 siblings, 2 replies; 7+ messages in thread
From: Sebastian Gniazdowski @ 2023-03-12 9:24 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh hackers list
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Reserved namespaces
2023-03-12 9:24 ` Sebastian Gniazdowski
@ 2023-03-12 13:54 ` Eric Cook
2023-03-12 16:46 ` Sebastian Gniazdowski
1 sibling, 0 replies; 7+ messages in thread
From: Eric Cook @ 2023-03-12 13:54 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Reserved namespaces
2023-03-12 9:24 ` Sebastian Gniazdowski
2023-03-12 13:54 ` Eric Cook
@ 2023-03-12 16:46 ` Sebastian Gniazdowski
2023-03-12 19:24 ` Bart Schaefer
1 sibling, 1 reply; 7+ messages in thread
From: Sebastian Gniazdowski @ 2023-03-12 16:46 UTC (permalink / raw)
To: Bart Schaefer; +Cc: Zsh hackers list
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Reserved namespaces
2023-03-12 16:46 ` Sebastian Gniazdowski
@ 2023-03-12 19:24 ` Bart Schaefer
0 siblings, 0 replies; 7+ messages in thread
From: Bart Schaefer @ 2023-03-12 19:24 UTC (permalink / raw)
To: Sebastian Gniazdowski; +Cc: Zsh hackers list
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).
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-03-12 19:25 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-11 4:56 Reserved namespaces Bart Schaefer
2023-03-11 10:00 ` Sebastian Gniazdowski
2023-03-11 19:47 ` Bart Schaefer
2023-03-12 9:24 ` Sebastian Gniazdowski
2023-03-12 13:54 ` Eric Cook
2023-03-12 16:46 ` Sebastian Gniazdowski
2023-03-12 19:24 ` Bart Schaefer
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).