bug#15166: 24.3.50; Isearch for an octal code

bug#15166: 24.3.50; Isearch for an octal code

[Dani Moncayo]

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@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

bug#15166: 24.3.50; Isearch for an octal code

[Juri Linkov]

> 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)

bug#15166: 24.3.50; Isearch for an octal code

[Kevin Rodgers]

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

bug#15166: 24.3.50; Isearch for an octal code

[Juri Linkov]

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))

bug#15166: 24.3.50; Isearch for an octal code

[Stefan Monnier]

> 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

bug#15166: 24.3.50; Isearch for an octal code

[Drew Adams]

> > 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.

bug#15166: 24.3.50; Isearch for an octal code

[Juri Linkov]

>> 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.

bug#15166: 24.3.50; Isearch for an octal code

[Drew Adams]

> > 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.

bug#15166: 24.3.50; Isearch for an octal code

[Juri Linkov]

> 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.

bug#15166: 24.3.50; Isearch for an octal code

[Drew Adams]

> > 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.  ;-)

bug#15166: 24.3.50; Isearch for an octal code

[Dani Moncayo]

Hi,

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

So, how about committing them?


-- 
Dani Moncayo

bug#15166: 24.3.50; Isearch for an octal code

[Juri Linkov]

> 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)