emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Emacs-bug-tracker] bug#6283: closed (doc/lispref/searching.texi referen


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#6283: closed (doc/lispref/searching.texi reference to octal code `0377' correct?)
Date: Wed, 02 Jun 2010 17:31:02 +0000

Your message dated Wed, 02 Jun 2010 13:30:00 -0400
with message-id <address@hidden>
and subject line Re: bug#6283: doc/lispref/searching.texi reference to octal 
code `0377' correct?
has caused the GNU bug report #6283,
regarding doc/lispref/searching.texi reference to octal code `0377' correct?
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
6283: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6283
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: doc/lispref/searching.texi reference to octal code `0377' correct? Date: Thu, 27 May 2010 13:28:16 -0400
In doc/lispref/searching.texi is the following reference to octal code
`0377' correct?

,----
| You cannot always match all address@hidden characters with the
| regular expression @code{"[\200-\377]"}.  This works when searching a
| unibyte buffer or string (@pxref{Text Representations}), but not in a
| multibyte buffer or string, because many address@hidden
| characters have codes above octal 0377.  {....}
`---- :FILE doc/lispref/searching.texi  (info "(elisp)Regexp Special")

Shouldn't that be:

"characters have codes above octal #o377"

--
/s_P\



--- End Message ---
--- Begin Message --- Subject: Re: bug#6283: doc/lispref/searching.texi reference to octal code `0377' correct? Date: Wed, 02 Jun 2010 13:30:00 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2.50 (gnu/linux)
The manual discussion about how *not* to match non-ascii characters is
silly.  Instead of discussing the bad ways to match non-ascii
characters, I added a note about how to do it properly.

Since the text in question is now deleted, I am closing this bug.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]