Quoting Vincent Lefevre (vinc...@vinc17.net): > On 2015-08-21 08:36:43 -0500, David Wright wrote: > > Quoting Erwan David (er...@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.
