From: MON KEY <monkey@sandpframing.com>
To: 6283@debbugs.gnu.org
Subject: bug#6283: doc/lispref/searching.texi reference to octal code `0377' correct?
Date: Thu, 27 May 2010 18:59:13 -0400 [thread overview]
Message-ID: <AANLkTikUvizSP3fd3m6GbcQIBySUYcp7unrC5PPvRvhB@mail.gmail.com> (raw)
In-Reply-To: <83vda9md09.fsf@gnu.org>
On Thu, May 27, 2010 at 2:10 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> `---- :FILE doc/lispref/searching.texi (info "(elisp)Regexp Special")
>>
>> Shouldn't that be:
>>
>> "characters have codes above octal #o377"
>
> What's the difference between what's written and what you suggest?
>
(string-equal "0377" "#o377") => nil
(string-equal "0377" "0377") => t
(string-equal "#o377" "#o377") => t
The latter forms read syntax being more in keeping with how the lisp
reader would interpret what the info docs are referring to as `octal
0377', and is at in keeping with what is presented in
(info "(elisp)Integer Basics"):
(eval #o377) => 255
What isn't at all clear in the infos in general is that the octal (or
FTM decimal, hex, etc. representations) for the literal raw-byte \255
is arrived at with something more like:
(insert (char-to-string #o17777655))
(insert (char-to-string #x3fffad))
(insert (char-to-string 4194221))
e.g. decimal 4194221 -> octal #o17777655 -> hex #x3fffad
Without knowing what do with that octal value simply referencing \255
as octal 0377 or hex X3FFFAD isn't all that informative of itself.
FWIW It took me a coupla years to figure out what how to frob those
values into a raw-byte and I still require to relearn it from the docs
whenever I need to manually revert some raw-bytes or improperly
encoded bit-rotted text using regexps.
--
/s_P\
next prev parent reply other threads:[~2010-05-27 22:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-27 17:28 bug#6283: doc/lispref/searching.texi reference to octal code `0377' correct? MON KEY
2010-05-27 18:10 ` Eli Zaretskii
2010-05-27 22:59 ` MON KEY [this message]
2010-05-29 14:28 ` Kevin Rodgers
[not found] ` <AANLkTikjCByug1U69tbhsnmS4c1VXSNzoqAOAxmbt3bI@mail.gmail.com>
2010-05-28 7:15 ` Eli Zaretskii
2010-05-28 23:20 ` MON KEY
2010-05-29 6:45 ` Eli Zaretskii
2010-05-31 5:35 ` MON KEY
2010-05-31 18:49 ` Eli Zaretskii
2010-06-01 0:24 ` MON KEY
2010-06-01 18:38 ` Eli Zaretskii
2010-06-02 19:41 ` MON KEY
2010-06-03 14:39 ` Kevin Rodgers
2010-05-31 14:45 ` MON KEY
2010-05-31 18:51 ` Eli Zaretskii
2010-05-31 23:44 ` MON KEY
2010-06-02 16:06 ` MON KEY
2010-06-02 17:30 ` Chong Yidong
2010-06-02 17:46 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTikUvizSP3fd3m6GbcQIBySUYcp7unrC5PPvRvhB@mail.gmail.com \
--to=monkey@sandpframing.com \
--cc=6283@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).