[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Nano-devel] RFC: entering characters by code -- what with 0x0A?
From: |
Benno Schulenberg |
Subject: |
[Nano-devel] RFC: entering characters by code -- what with 0x0A? |
Date: |
Wed, 21 Dec 2016 14:52:12 +0100 |
Hi all,
In section 4.1 of the manual ('info nano edit enter') it says
that one can enter characters that are not present on the
keyboard in two ways: with Esc Esc ddd and with M-V xxxxxx.
For both these methods it says that it enters the character
with the corresponding code. But that's not true.
For Esc Esc ddd nano acts as if the /key/ with that code was
pressed. But for M-V xxxxxx nano actually inserts the given
code into the file. For most characters this boils down to
the same thing. But not for control codes. For example,
pressing Esc Esc 0 1 1 will execute a ^K, that is: it will
delete the current line. But pressing M-V 0 0 0 0 0 B
(which is essentially the same code) will enter a literal
^K (byte 0x0b) into the buffer.
Okay, you will say, just adjust the description and all will
be fine. True. But there is a special case. M-V 0 0 0 0 0 A
will not enter a literal ^J but will act as if the user pressed
<Enter>. In a way, this makes sense, because ^J is the newline
character, and if nano had read in this character from a file,
it would have created a new line. But this behavior causes a
problem when for example at Write-Out prompt: if for some weird
reason the user wants to type a filename that contains a newline
(which is a silly thing to do, but valid), typing M-V 0 0 0 0 0 A
will cause nano to act as if the user typed <Enter> -- which is
unexpected and frustrating. Okay, the user could instead type
M-V 0 0 0 0 0 0 and that /would/ enter a literal ^J into the
filename (although in current releases it gets displayed as ^@;
in git this has been corrected), but that is odd and silly.
What I instead propose is that M-V 0 0 0 0 0 A will beep when
the user tries that in an edit buffer or at a search prompt,
and will enter a literal ^J when at a filename prompt. And
the sequence M-V 0 0 0 0 0 0 will beep at a filename prompt
(because a filename cannot contain byte 0x00) and will enter
a literal ^@ when in an edit buffer or at a search prompt.
Thoughts?
Benno
--
http://www.fastmail.com - A fast, anti-spam email service.
- [Nano-devel] RFC: entering characters by code -- what with 0x0A?,
Benno Schulenberg <=