help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Reserved namespaces
Date: Sun, 12 Mar 2023 12:24:45 -0700	[thread overview]
Message-ID: <CAH+w=7YoYfAw7VTVPJkQOuj+ooY_qLTWGYUtuL=JH8TPpLUpNg@mail.gmail.com> (raw)
In-Reply-To: <CAKc7PVD+-ft3a-D_Y=_cYNf3C+xGBt8mi0Rzf5eXZAPFfcJFBA@mail.gmail.com>

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=(


and change utils.c:spdist() to check getsparam(".interact.layout")
before examining the DVORAK option (for backward compatibility).

      reply	other threads:[~2023-03-12 19:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-11  4:56 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 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7YoYfAw7VTVPJkQOuj+ooY_qLTWGYUtuL=JH8TPpLUpNg@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=sgniazdowski@gmail.com \
    --cc=zsh-workers@zsh.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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).