Re: List of pending patches
Bart Schaefer <[email protected]>
| Newsgroups | gmane.comp.shells.zsh.devel |
|---|---|
| Message-ID | <CAH+w=7bxctizJp40NWu4dCCLhqhYdaETBNiuoOm1PwHikEff-w@mail.gmail.com> |
Thanks, this is helpful, I try to flag them but sometimes lose track. Selected notes ... On Fri, Aug 14, 2026 at 4:26 PM Philippe Altherr <[email protected]> wrote: > > - More readable parameter definitions in params.c - workers/55022 > Only rename/refactor macros, no code change Anyone have comments on this? It's a bit like a patch that cleans up indentation in that it makes sense on its own but puts a crimp in tracing changes from before it to after it. > - The substitution flags (v!) are forbidden, also forbid (!v) - workers/54940 This one seems semantically OK but reading the diff leaves me searching for something *else* that *ceases to be* an error. Did an earlier patch change something related? > - Don't map ksh's ! to Zsh's (!k), map it to (k) - workers/55047 > Maybe controversial That one says "DO NOT COMMIT" so I haven't considered doing so. The only controversial bit for me is the part where ${!nameref} doesn't act like ksh any more; I have no objection to ${!hash} or ${!hash[key]} working like (k) when namerefs aren't involved. > - Restrict named directories to scalar parameters set to a path - workers/54760 > Maybe controversial I don't think I ever got an answer to my question at the end of workers/54779? The thread veered down the path of replacing workers/54759 with workers/54792 > The following two are rather simple but the first one has a trivial merge conflict (because a committed patch already added "for, " in an error message about loops). > > - Forbid break/continue in subshells - workers/55061 > - Forbid escaping past all enclosing loops in the same subshell - workers/55061 > Maybe controversial I don't have a strong opinion on this ... I have the impression that "break N" for a large N may have been used somewhere to escape from a stack of nested loops, possibly to force a function call stack to unwind, so I'm uncertain about making this case an error. > The following should probably wait after the work on inline assignments (and localized special parameters): > > - Don't export hidden parameters - workers/54987 > - In inline assignments, assign the reference, not its referent - workers/54944 Agree these should be folded into whatever comes of the "language design" threads.