Quoting Erwan David (er...@rail.eu.org): > On Fri, Aug 21, 2015 at 04:56:54AM CEST, David Wright > <deb...@lionunicorn.co.uk> said: > > Quoting Vincent Lefevre (vinc...@vinc17.net): > > > On 2015-08-19 16:33:09 -0500, David Wright wrote: > > > > Quoting Thomas Schmitt (scdbac...@gmx.net): > > > > > But the typographical purpose of NO-BREAK SPACE is to look > > > > > like space without inviting an automatic line break. > > > > > So making it look not like space would be absurd. > > > > > > > > But shell input is not a typographical context. Most source code > > > > isn't, except in literals. Documents generally are because they are > > > > displayed/printed. > > > > > > The point is that the terminal cannot do the difference between > > > a NBSP coming from shell input and a NBSP coming from a displayed > > > document. So, it should render a NBSP exactly like a normal space. > > > And it is up to the application (the shell, an editor in some > > > mode, etc.) to render NBSP in a special way if needed. > > > > Why not? Let's substitute TAB TAB for NBSP in your comment. > > My terminal happily swallows TAB TAB with cat > file, and renders > > it correctly with cat file. But when I type TAB TAB as shell input, > > I get "Display all 3402 possibilities? (y or n)". It seems to be able > > to "do the difference" in this case. > > 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 Now I don't know about you, but nothing I type has been displayed *directly* since I started computing in 1971. I once saw an IBM 3270 which allegedly did this but it was returned to IBM "in the box" as unsuitable for that very reason. I suppose one might include the ASR 33, but only when it was being used to duplicate a paper tape. > 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. 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. I disagreed, and gave a counter-example (shell's treatment of TAB TAB). So all this is about output, viz: cat, xpdf, document displays, printers: NBSP -> a space that doesn't lead to a break. buffer in an editor: NBSP -> a visible glyph (in emacs I think I see a cyan underscore character). 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). Cheers, David.