Re: How come i wrote a NO-BREAK SPACE in xterm+bash ?
On 2015-08-21 08:36:43 -0500, David Wright wrote:
> Quoting Erwan David (erwan@rail.eu.org):
> > 1) You're speaking input, Vincent was speaking output
>
> Eh? The OP was speaking input. To summarise,
> . Q: How come i wrote a NO-BREAK SPACE in xterm+bash ?
> . A: I touched the key to the left of the space bar at the same time.
> . Fix: Redefine Alt-Space to type an ordinary space.
>
> Since then, the discussion moved on to how NBSP should be *displayed* in
> various contexts. This happened at the last substantive (UK sense)
> paragraph of https://lists.debian.org/debian-user/2015/08/msg00360.html
And if you follow the quotes, this subthread is a descendent of this,
about output:
[...]
It's not too bad if only NO-BREAK SPACE had a visible glyph.
Something like four dots at the corners of its rectangle.
[...]
Well, until you re-introduced input...
> > 2) it's the shell which makes a different treatment than cat. Exactly
> > what Vincent said. It is up to the application running in the shell to
> > do what is needed.
>
> Which application are you speaking of, specifically in the case under
> discussion, ie typing characters like NBSP and TAB TAB into the shell.
The process that will get the character. It may be the shell or some
other process. Details: https://en.wikipedia.org/wiki/Process_group
> I've said here (and you just snipped it out of the quotation above):
> 'So my point is, "rendering NBSP in a special way *is* needed" (because NBSP
> is not treated as firstclass whitespace and, it appears, never can be).'
>
> So your reply "It is up to the application running in the shell to do
> what is needed" just begs the question. I've already said what is
> needed (IMO) and Vincent said (AIUI) that it couldn't be done.
No, here's what I said:
| In general, one wants NO-BREAK SPACE to be displayed just like
| a space. The differentiation is useful mainly in source code
| and when editing, thus it must be done by the application via
| configuration (actually applications running in the terminal
| rather than the terminal itself).
What I'm saying is that the *terminal* cannot know the context
(at least in a standard way) to determine whether NBSP should
be displayed like a space or with a special glyph.
> I disagreed, and gave a counter-example (shell's treatment of TAB TAB).
Your "counter-example" is something different because it is about
input (though this doesn't really matter since the notion of context
is the same for both input and output) and because the TAB handling
is not done by the terminal, but by two different applications
running in the terminal (the shell and "cat"). As I've said later,
both applications receive TAB in input. They behave differently only
because they interpret TAB differently, i.e. the differentiation is
done by the application (the shell and "cat").
> So all this is about output, viz:
>
> cat, xpdf, document displays, printers: NBSP -> a space that doesn't
> lead to a break.
The "cat" utility never breaks lines. It just sends the characters
to the output.
For PDF and printers (after filtering), the formatting is already
done. So, whether you have a NBSP or a normal space in your PDF,
this won't change anything.
NBSP makes sense, for instance, in HTML.
> buffer in an editor: NBSP -> a visible glyph (in emacs I think I see
> a cyan underscore character).
Magenta in my case (but this may depend on the background). If Emacs
runs in a terminal, I get a normal space with a magenta background
(the NBSP is not preserved by copy-paste).
In Emacs, this feature is configurable. So, if I'm just reading a text
document in Emacs and do not care about the NBSP characters, I can
choose to disable this feature. See Emacs manual:
14.19 How Text Is Displayed
[...]
Some non-ASCII characters have the same appearance as an ASCII space
or hyphen (minus) character. Such characters can cause problems if they
are entered into a buffer without your realization, e.g., by yanking;
for instance, source code compilers typically do not treat non-ASCII
spaces as whitespace characters. To deal with this problem, Emacs
displays such characters specially: it displays ‘U+00A0’ (no-break
space) with the ‘nobreak-space’ face, and it displays ‘U+00AD’ (soft
hyphen), ‘U+2010’ (hyphen), and ‘U+2011’ (non-breaking hyphen) with the
‘escape-glyph’ face. To disable this, change the variable
‘nobreak-char-display’ to ‘nil’. If you give this variable a non-‘nil’
and non-‘t’ value, Emacs instead displays such characters as a
highlighted backslash followed by a space or hyphen.
Emacs can also display trailing spaces with a different background.
> shell reflecting the user's typing: NBSP -> a visible glyph indicating
> that something other than white space is there, eg Thomas's four dots
> at the corners of its rectangle. It might, for example, be used as
> or in a filename (unquoted).
This needs to be done by the shell. But if you use a different glyph,
it will break copy-paste. A NBSP with a different background would be
better, IMHO. This is probably possible with zsh.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: