zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: UTF-8 non-breaking spaces
Date: Fri, 26 Mar 2021 21:07:51 +0000	[thread overview]
Message-ID: <20210326210751.GF18178@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <CAH+w=7Z8-AOLSLD7dKD6bMJDv31-gyw2mAwKTiAHES6bWurBzA@mail.gmail.com>

Bart Schaefer wrote on Fri, Mar 26, 2021 at 11:15:47 -0700:
> > If you're copy-pasting from an edit in browser gmail, for example, it
> > has a tendency to insert non-breaking spaces whenever there is more
> > than one consecutive space, which the shell interprets as
> > non-whitespace and attempts to execute as commands.
> 
> Non-breaking space in this case is (bindkey syntax) "\M-B\M- ".  The
> error message is equally confusing because you still can't see the
> non-breaking spaces when "not found" is reported.
> 
> Handling this is complicated by bracketed-paste, which protects the
> non-breaking spaces from (for example) { bindkey -s '\M-B\M- ' ' ' }.
> 
> "unsetopt multibyte" does not affect this but LANG=C results in (for example)
> 
> (In gmail editor)
>  echo " " "  "
> (Pasted at shell prompt)
> % echo " " "<c2><a0> "
> 
> That's totally a ZLE display thing, the actual nbsp is output when the
> command executes, but at least you can see what's going on.
> 
> (The non-breaking spaces go back to normal spaces in sent email, I
> believe, or at least do so when the message is displayed in gmail;
> this is just a "thing" in the browser text editor.)
> 
> Similar goofiness can result when copy-pasting from other "smart"
> multibyte editors when zsh has a UTF-8 variant in $LANG.
> 
> Any good suggestions how to deal with this in a non-confusing fashion?

(I presume "Use a non-buggy MUA" isn't the answer you're after.)

With zsh-syntax-highlighting:

    . /path/to/zsh-syntax-highlighting
    ZSH_HIGHLIGHT_HIGHLIGHTERS=( pattern )                     # or += if you already use z-sy-h
    typeset -A ZSH_HIGHLIGHT_PATTERNS=($'\uA0' 'bg=blue,bold')

This'll highlight nbsp's.  Not change them, just highlight them.  To
change them, a custom s/nbsp/space/g widget might be convenient.

>  Everything I've thought of (short of hacking up the lexer) risks
> corrupting parts of the input that aren't intended to be word
> separators (the bindkey -s above has that problem, for example, if
> bracketed-paste is disabled).
> 


      reply	other threads:[~2021-03-26 21:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 18:15 Bart Schaefer
2021-03-26 21:07 ` Daniel Shahaf [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:
  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=20210326210751.GF18178@tarpaulin.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --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).