zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: Re: Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var})
Date: Fri, 23 Feb 2024 15:38:16 -0800	[thread overview]
Message-ID: <CAH+w=7Y3RJf1FbNSA8rSZH4b-BR=JwCuEY6KOG5K+DWLcbACBQ@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7bTFowrTNu8rorLzSbQyW70oGuppYYvPdF40RTJk4bQ8w@mail.gmail.com>

On Fri, Feb 23, 2024 at 2:32 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> More relevant to this discussion is that math errors are one of the
> two existing callers using the %l format, so any attempt to improve
> this is going to require changing those calls anyway.
>
> we have just the one known case of wanting something different for
> ${var?msg}.
>
> There's exactly one case so far of wanting output to contain NUL, and
> per the "only caller can interpret" assertion, it seems worthwhile to
> use %l for the NUL case and let the other 3 callers decide to "nice"
> the strings they pass (or not).

That last sentence should be "other 3 calls" not callers (there are only 2).

Having worked out that issue with bin_print() [other thread], it
appears to me that NONE of the existing calls using %l want their
output nice'd (for example, the only way to get consistent readable
errors from math garble is to output the strings raw, or at least
something less than nice'd and yet to be determined).

This suggests strongly to me that changing %l and scrapping the %S
idea is the way to go.


  reply	other threads:[~2024-02-23 23:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13  8:02 $var not expanded in ${x?$var} Stephane Chazelas
2023-01-16  8:35 ` Daniel Shahaf
2023-01-16 17:15 ` Peter Stephenson
2024-02-20  7:05   ` Stephane Chazelas
2024-02-20 17:45     ` Bart Schaefer
2024-02-20 19:39       ` Stephane Chazelas
2024-02-21  4:44         ` Bart Schaefer
2024-02-21 19:45           ` Stephane Chazelas
2024-02-21 19:52             ` Bart Schaefer
2024-02-21 20:21               ` Stephane Chazelas
2024-02-22  0:46                 ` [PATCH] unmetafy " Bart Schaefer
2024-02-22  7:23                   ` Stephane Chazelas
2024-02-22  7:55                     ` Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var}) Stephane Chazelas
2024-02-22 17:02                       ` Bart Schaefer
2024-02-22 22:31                         ` Bart Schaefer
2024-02-23  0:49                           ` Bart Schaefer
2024-02-23 19:27                           ` Stephane Chazelas
2024-02-23 22:32                             ` Bart Schaefer
2024-02-23 23:38                               ` Bart Schaefer [this message]
2024-02-24  9:47                               ` Stephane Chazelas
2024-02-24 10:36                                 ` Stephane Chazelas
2024-02-25  4:35                                   ` [PATCH] 'bad interpreter' error garbled Bart Schaefer
2024-02-25  5:26                                     ` Bart Schaefer
2024-02-25  2:17                                 ` Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var}) Bart Schaefer
2024-02-25  6:05                                   ` Bart Schaefer
2024-02-25  7:29                                     ` Stephane Chazelas
2024-02-25  8:28                                       ` typeset -<non-ASCII> (Was: metafication in error messages) Stephane Chazelas
2024-02-25  8:35                                         ` Stephane Chazelas
2024-02-25 21:02                                         ` Bart Schaefer
2024-02-23  0:33                       ` Metafication in error messages (Was: [PATCH] unmetafy Re: $var not expanded in ${x?$var}) Bart Schaefer
2024-02-25  5:06                       ` [PATCH] count multibyte and metafied characters correctly for math ops errors Bart Schaefer
2024-02-22  8:34                     ` [PATCH] unmetafy Re: $var not expanded in ${x?$var} Roman Perepelitsa
2024-02-22 17:07                       ` Bart Schaefer

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CAH+w=7Y3RJf1FbNSA8rSZH4b-BR=JwCuEY6KOG5K+DWLcbACBQ@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

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