GNU bug report logs - #19924
24.4; incremental search for octal character

Previous Next

Full log

Message #29 received at 19924 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: vose <at> eecs.utk.edu, 19924 <at> debbugs.gnu.org
Subject: Re: bug#19924: 24.4; incremental search for octal character
Date: Fri, 06 Mar 2015 16:57:01 +0200

> Date: Thu, 5 Mar 2015 14:54:55 -0800 (PST)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: vose <at> eecs.utk.edu
> 
> > I anticipate that the following is an explanation of some kind:
> > 
> >  "As the screenshot shows, the problem is that the search doesn't find
> >   the character 213 in the `no-conversion' (binary) buffer, because
> >   there is a mismatch between the coding of the buffer and the search."
> > 
> > But I don't know what the above means.  In particular, I don't know how
> > to search for octal 213.  Given my current (lack of) understanding, it
> > seems that emacs is broken, or searching in octal is not possible.

It means that we have a missing feature: we don't have any reasonable
way of typing unibyte characters at Isearch's prompt.  We need to
provide one.  There was such a kludgey feature in the past, but it
conflicted with a much more useful possibility of inserting Unicode
codepoints with C-q, and so the kludge was deleted in one of the
previous versions.  We need to restore it, at least for when Isearch
was initiated from a unibyte buffer.

Another possibility would be to have an input method for that.

(The manual isn't wrong, strictly speaking: it says "non-ASCII
characters", not "raw bytes in unibyte buffers".)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.