> From: Marco Cimarosti [mailto:firstname.lastname@example.org]
> This also casts some light on the fact that some fonts
> (notably JIS fonts)
> have a big black box glyphs at position 0x7F: it is probably
> for overwriting
> a character already printed on paper, so that it cannot be
> read anymore.
Probably not. A big black box (big hollow boxes are also used for
this) is a polite way to represent a character which has no glyph.
> But a few people also raised some "contemporary" issues,
> which is what I was
> trying to obtain with my question:
> Doug Ewell wrote:
> > You have probably already tested this, but in Windows [...]
> > it simply displays as a box [...]
> > Actually, I wasn't expecting this. I tested a file
> > containing the text
> > "ABC*DEF" (where * = DEL) and expected that at least one
> > process would
> > display "ABDEF" where the DEL character had deleted the C.
I would not expect any system to display "ABDEF". DEL is a bit of a
"one way" character - it triggers a deletion when sent as (interactive)
input, but should not cause the same effect when stored as data. Note that
this is an "active" character which exists in Unicode for compatibility
issues (in this case, there's quite a lot to compat with), and does not fit
neatly into the character encoding model. Specifically, DEL is meant to be
interpreted by a filter between sender and receiver, as are all the code
points 0x00-0x1F. Many of these no longer require intermediary
interpretation (example: carriage return (0x0D) originally triggered
physical action on the receiving printer, but now is a logical marker).
> John Cowan wrote:
> > In general it has none. Some systems interpret it (erroneously) as
> > either "cancel previous character" (usually BS) or
> "interrupt process"
> > (usually ^C).
> Which systems interpret 0x7F as "interrupt process"? I know
> that this would
> be 0x03 in DOS (^C), and 0x03, 0x04 or 0x1A in Unix (^C, ^D, and ^Z,
> respectively), but I know nothing about other systems, e.g. Macintosh.
HPUX by default interprets DEL as "interrupt process", when received
> Valery E Ushakov (Uwe) wrote:
> > On DEC (and, I belive other) terminals the <-- "Rubout" key (PC
> > keyboards has "BackSpace" key in this position) generates DEL. So
> > emacs, The One True Editor :-), uses ^H key (i.e.
> backspace) for help
> > - which causes a lot of confusion for new users who have PC
> > that generate backspace (^H) for <-- key.
> This leads me to some more questions:
> 1) What happens if emacs loads Doug Ewell's text file (I.e. a
> text file
> containing "ABC<del>DEF") and then saves it? Would the file's
> content be
> changed to "ABDEF"?
No. That DEL would be loaded as data, not sent to the input
handler, which is what interprets DEL as "delete character".
> 2) Could emacs be invoked with a text file as the keyboard
> input? I mean a
> thing like:
> emacs < mycmd.txt
Probably, but it wouldn't be done like that, I think. You could
certainly write some elisp to do this.
> 3) If 2 above is possible, what would happen if mycmd.txt contains
> "ABC<del>DEF<^X><^W>mytxt.txt<newline>"? Would mytxt.txt
> contain "ABDEF"?
> (Note: I understand that ^X+^W+filename is the command to
> save a new file in
> emacs; sorry if this is wrong)
In principle, this would work.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:19 EDT