Re: How come i wrote a NO-BREAK SPACE in xterm+bash ?
Quoting Vincent Lefevre (vincent@vinc17.net):
> 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.
Mark that last sentence.
> > 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).
So we may be talking at cross-purposes here as I'm distinguishing the
shell (command interpreter/application launcher) from applications,
much as Erwan appears to in that sentence. Sorry; but that's why I wrote
(AIUI) just there.
> 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").
This may come down to terminology again. I don't know. To me, input to
the shell is what the keys produce (scan codes) and then the keymap
turns them into. That's what I was struggling with yesterday in
another thread, playing about with /etc/console-setup/remap.inc.
When a character goes into the shell, it is interpreted. What then
reflects on the screen, to me, is output from the shell. In other
words, I press the keys [l] [s] [ ] [.] [.] [Alt-Space] [.] [.] [Return]
and the shell reflects (outputs in my terminology) 'ls .. ..
' on the screen and hands '..NBSP..' to ls which complains that there's
no such entry.
What I want reflected (output) is 'ls ..·..
' where my · character does not masquerade as an ordinary space.
> > 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.
This was written just by way of illustrating "typographical context".
My "->" stands for your "filtering". (Yes, cat is not a very good
example. I used it thoughtlessly as a way of dumping a file onto
the screen in order to admire the text, rather than, say, editing it
on the screen. Obviously cat mustn't do anything to the characters.)
> 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).
Ditto here in emacs -nw. I don't know why my colours differ from each other.
> 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.
Yes, I find that useful, along with undesirables like Space Tab sequences.
> > 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.
That is a good point. Colour or shading might work well.
> This is probably possible with zsh.
You've aroused my curiosity. I've looked at the slide show, installed
it, and must try it out...
Cheers,
David.
Reply to: