GNU bug report logs - #15166
24.3.50; Isearch for an octal code

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15166 in the body.
You can then email your comments to 15166 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Isearch for an octal code
Date: Fri, 23 Aug 2013 13:23:10 +0200

Recipe from "emacs -Q":
  C-q 2 0 0 RET M-< C-s C-q 2 0 0 RET

I observe that Isearch fails; it's unable to find the character with
octal code `200'.

Why?  It should be able, no?


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-08-22 on LEG570
Bzr revision: 113971 monnier <at> iro.umontreal.ca-20130822040645-0fc4fi87eir72jnb
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --enable-checking CFLAGS='-O0 -g3'
 CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/usr/include''

Important settings:
  value of $LANG: ESN
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

-- 
Dani Moncayo

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 15166 <at> debbugs.gnu.org
Subject: Re: bug#15166: 24.3.50; Isearch for an octal code
Date: Sat, 24 Aug 2013 01:48:41 +0300

> Recipe from "emacs -Q":
>   C-q 2 0 0 RET M-< C-s C-q 2 0 0 RET
>
> I observe that Isearch fails; it's unable to find the character with
> octal code `200'.

This is due to this special casing in `isearch-quote-char':

      (and enable-multibyte-characters
	   (>= char ?\200)
	   (<= char ?\377)
	   (setq char (unibyte-char-to-multibyte char)))

But in `quoted-insert' the same code is commented out now.
So `isearch-quote-char' should be synced with `quoted-insert'
by adding the same comment from `quoted-insert':

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2013-07-05 20:15:32 +0000
+++ lisp/isearch.el	2013-08-23 22:42:25 +0000
@@ -2730,10 +2748,14 @@ (defun isearch-quote-char (&optional cou
 	(if (subregexp-context-p isearch-string (length isearch-string))
 	    (isearch-process-search-string "[ ]" " ")
 	  (isearch-process-search-char char count))
-      (and enable-multibyte-characters
-	   (>= char ?\200)
-	   (<= char ?\377)
-	   (setq char (unibyte-char-to-multibyte char)))
+      ;; This used to assume character codes 0240 - 0377 stand for
+      ;; characters in some single-byte character set, and converted them
+      ;; to Emacs characters.  But in 23.1 this feature is deprecated
+      ;; in favor of inserting the corresponding Unicode characters.
+      ;; (and enable-multibyte-characters
+      ;; 	   (>= char ?\200)
+      ;; 	   (<= char ?\377)
+      ;; 	   (setq char (unibyte-char-to-multibyte char)))
       (isearch-process-search-char char count))))
 
 (defun isearch-printing-char (&optional char count)

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 15166 <at> debbugs.gnu.org
Subject: Re: bug#15166: 24.3.50; Isearch for an octal code
Date: Sat, 24 Aug 2013 01:58:56 +0300

BTW, while looking at `isearch-quote-char' I noticed that it
requires a comment saying that `C-q SPC' is an obsolete feature
(that is now replaced by `M-s SPC').  Then it should be also
de-documented in the docstring of `isearch-forward-regexp':

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2013-07-05 20:15:32 +0000
+++ lisp/isearch.el	2013-08-23 22:42:25 +0000
@@ -823,7 +823,6 @@ (defun isearch-forward-regexp (&optional
 
 In incremental searches, a space or spaces normally matches any
 whitespace defined by the variable `search-whitespace-regexp'.
-To search for a literal space and nothing else, enter C-q SPC.
 To toggle whitespace matching, use `isearch-toggle-lax-whitespace'."
   (interactive "P\np")
   (isearch-mode t (null not-regexp) nil (not no-recursive-edit)))
@@ -2730,6 +2748,8 @@ (defun isearch-quote-char (&optional cou
     ;; single-byte character set, and convert them to Emacs
     ;; characters.
     (if (and isearch-regexp isearch-regexp-lax-whitespace (= char ?\s))
+	;; Obsolete feature: to search for a literal space
+	;; and nothing else, enter C-q SPC.
 	(if (subregexp-context-p isearch-string (length isearch-string))
 	    (isearch-process-search-string "[ ]" " ")
 	  (isearch-process-search-char char count))

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 15166 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#15166: 24.3.50; Isearch for an octal code
Date: Fri, 23 Aug 2013 21:15:46 -0400

> BTW, while looking at `isearch-quote-char' I noticed that it
> requires a comment saying that `C-q SPC' is an obsolete feature
> (that is now replaced by `M-s SPC').

Why is C-q SPC obsolete?


        Stefan

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Juri Linkov <juri <at> jurta.org>
Cc: 15166 <at> debbugs.gnu.org
Subject: RE: bug#15166: 24.3.50; Isearch for an octal code
Date: Fri, 23 Aug 2013 18:25:33 -0700 (PDT)

> > BTW, while looking at `isearch-quote-char' I noticed that it
> > requires a comment saying that `C-q SPC' is an obsolete feature
> > (that is now replaced by `M-s SPC').
> 
> Why is C-q SPC obsolete?

I had the same question.  `C-q' should just work here, like
elsewhere - and it still does AFAICT.

I'm guessing that perhaps you (Juri) meant only that it is no
longer the *only* way to insert such a char into the search string,
so it need not be advertised as such.

But surely it should continue to be supported (and not considered
deprecated obsolete), unless there is some good reason otherwise.

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

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15166 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#15166: 24.3.50; Isearch for an octal code
Date: Sat, 24 Aug 2013 12:20:59 +0300

>> BTW, while looking at `isearch-quote-char' I noticed that it
>> requires a comment saying that `C-q SPC' is an obsolete feature
>> (that is now replaced by `M-s SPC').
>
> Why is C-q SPC obsolete?

The problem is that C-q SPC has limited applicability -
it works only in regexp isearch, and has no effect in
normal non-regexp isearch.  This might be too confusing
to users when typing the same key sequence unexpectedly
works differently in different isearch modes.

Initially C-q SPC was intended only for regexp isearch,
but after introduction of isearch-lax-whitespace mode
it can't be used in non-regexp mode because the C-q SPC
feature was based on regexps.

I don't propose to remove it now, keeping it for users
that rely on it in regexp search.  But to remove mentions
from documentation to not confuse users about the feature
that doesn't work in non-regexp mode.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> jurta.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15166 <at> debbugs.gnu.org
Subject: RE: bug#15166: 24.3.50; Isearch for an octal code
Date: Sat, 24 Aug 2013 07:47:30 -0700 (PDT)

> > Why is C-q SPC obsolete?
> 
> The problem is that C-q SPC has limited applicability -
> it works only in regexp isearch, and has no effect in
> normal non-regexp isearch.  This might be too confusing
> to users when typing the same key sequence unexpectedly
> works differently in different isearch modes.
> 
> Initially C-q SPC was intended only for regexp isearch,
> but after introduction of isearch-lax-whitespace mode
> it can't be used in non-regexp mode because the C-q SPC
> feature was based on regexps.
> 
> I don't propose to remove it now, keeping it for users
> that rely on it in regexp search.  But to remove mentions
> from documentation to not confuse users about the feature
> that doesn't work in non-regexp mode.

What doesn't work?  Can you please elaborate?

It's not clear to me what you mean by C-q SPC not working
for non-regexp isearch.  I can only guess that you mean that,
although C-q SPC does in fact add a SPC char to the search
string, that does not cause non-regexp isearch to search
for only one SPC (per SPC char added to the search string).

If that's what you mean then I don't see that as a problem.
At least not a problem wrt C-q SPC.  (The confusion is elsewhere.)

In that case, C-q SPC still does its job.  Anything confusing
coming from the result is confusion coming from the fact that
isearch now interprets any number of contiguous SPC chars in
the search string - including, in particular, just one SPC
char - as an arbitrarily long sequence of whitespace chars to
match.

I was not particularly in favor of that change to Emacs, as
you know, but so be it.

The point here is that given that change there is AFAICT
nothing broken, unexpected, or confusing about the behavior
of C-q SPC.  (As far as I can see.)

Perhaps you can give a recipe showing the confusion you
have in mind, if it is different from what I am supposing,
and if it is in fact something directly related to C-q SPC.
Thx.

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

From: Juri Linkov <juri <at> jurta.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15166 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#15166: 24.3.50; Isearch for an octal code
Date: Sun, 25 Aug 2013 02:38:48 +0300

> What doesn't work?

The docstring of `isearch-forward-regexp' says "To search
for a literal space and nothing else, enter C-q SPC."
The users might expect it to work the same way regardless of mode,
but it doesn't search for a literal space in non-regexp mode.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 15166 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: RE: bug#15166: 24.3.50; Isearch for an octal code
Date: Sat, 24 Aug 2013 17:43:29 -0700 (PDT)

> > What doesn't work?
> 
> The docstring of `isearch-forward-regexp' says "To search
> for a literal space and nothing else, enter C-q SPC."
> The users might expect it to work the same way regardless of mode,
> but it doesn't search for a literal space in non-regexp mode.

Got it. Yes, that text is now out of date.

It never should have said that C-q SPC affects what is
searched for, in any case.  It should only have said (and
can say now) that C-q SPC, as usual, appends a SPC char to
the search string.

What Isearch does with the text you put in the search string
is another matter.  But C-q SPC still works - it does what it
is supposed to do.  It is Isearch that is more complicated
now, and not necessarily intuitive.  But that cannot be blamed
on C-q.  ;-)

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 15166 <at> debbugs.gnu.org
Subject: Re: bug#15166: 24.3.50; Isearch for an octal code
Date: Tue, 27 Aug 2013 11:59:13 +0200

Hi,

It seems that everything is already clear regarding your two patches,
no?  (they are both fine).

So, how about committing them?


-- 
Dani Moncayo

Message #37 received at 15166-done <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 15166-done <at> debbugs.gnu.org
Subject: Re: bug#15166: 24.3.50; Isearch for an octal code
Date: Tue, 27 Aug 2013 18:58:45 +0300

> It seems that everything is already clear regarding your two patches,
> no?  (they are both fine).
>
> So, how about committing them?

I committed the patch that fixes the bug reported by you.
Thanks for the bug report.

But I left unchanged the comment about `C-q SPC' for the
chance if someone will have inclination to make it work in
non-regexp mode somehow, because internally they both use regexps.
You can see the internal regexp matching by typing too many spaces
in non-regexp mode, and Isearch will report the error
"Regular expression too big".

This error message is confusing in non-regexp Isearch.
So I propose another patch to make the error message
more suitable to whitespace-matching non-regexp mode.
And since regexp-based word-search mode reports the same
confusing error message when there are too many words
in the search string, it should be fixed as well:

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2013-08-08 23:59:14 +0000
+++ lisp/isearch.el	2013-08-27 15:58:01 +0000
@@ -2773,10 +2777,18 @@ (defun isearch-search ()
 
     (invalid-regexp
      (setq isearch-error (car (cdr lossage)))
-     (if (string-match
-	  "\\`Premature \\|\\`Unmatched \\|\\`Invalid "
-	  isearch-error)
-	 (setq isearch-error "incomplete input")))
+     (cond
+      ((string-match
+	"\\`Premature \\|\\`Unmatched \\|\\`Invalid "
+	isearch-error)
+       (setq isearch-error "incomplete input"))
+      ((and (not isearch-regexp)
+	    (string-match "\\`Regular expression too big" isearch-error))
+       (cond
+	(isearch-word
+	 (setq isearch-error "Too many words"))
+	((and isearch-lax-whitespace search-whitespace-regexp)
+	 (setq isearch-error "Too many spaces for whitespace matching"))))))
 
     (search-failed
      (setq isearch-success nil)

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

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15166: 24.3.50; Isearch for an octal code
Date: Thu, 29 Aug 2013 00:27:33 -0600

On 8/23/13 4:48 PM, Juri Linkov wrote:

> +      ;; This used to assume character codes 0240 - 0377 stand for
> +      ;; characters in some single-byte character set, and converted them
> +      ;; to Emacs characters.  But in 23.1 this feature is deprecated
> +      ;; in favor of inserting the corresponding Unicode characters.
> +      ;; (and enable-multibyte-characters
> +      ;; 	   (>= char ?\200)
> +      ;; 	   (<= char ?\377)
> +      ;; 	   (setq char (unibyte-char-to-multibyte char)))

Thank you! I thought I had lost my emacs-fu :-(

-- 
Kevin Rodgers
Denver, Colorado, USA

Previous Next

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