all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Juri Linkov <juri@jurta.org>
Cc: 13402@debbugs.gnu.org
Subject: bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch]
Date: Wed, 20 Feb 2013 22:37:59 +0000	[thread overview]
Message-ID: <20130220223759.GA2644@acm.acm> (raw)
In-Reply-To: <87ip5nql4v.fsf@mail.jurta.org>

Hello again, Juri.

On Wed, Feb 20, 2013 at 12:49:04PM +0200, Juri Linkov wrote:

> I think you are overestimating the seriousness of the problem.

It is going to be a big problem for a small number of users.  I dare say
the majority won't notice.

> The highlighting effect that you don't like might seem peculiar
> but it has a logical explanation.  Trying to change its logic to
> more complicated will introduce other problems that might seem illogical
> to other users.

Just as activating `search-whitespace-regexp' has done, you mean.  ;-)

> For example, consider the following test case:

> With `search-whitespace-regexp' customized to nil, try to put the cursor
> to the second space character in the string "   Each entry" and type
> `C-M-s SPC'.  It lazy-highlights the previous space character too
> (it's the first space character in the string).  This is right.

> Now with your patch applied, add the character "+" to the search regexp,
> so that a complete search regexp is " +" and the cursor is on the second
> space character in the string "   Each entry".  The result is that
> the first space character is not lazy-highlighted.  I think this is wrong.

:-).  I'm not sure.  It has a certain logic behind it.  I think a missing
lazy-highlight is much less disturbing than an obtrusive one.

> If you assume that the boundary of the current match should begin only
> from the leading character of the search string, then you have to allow
> the preceding match to be lazy-highlighted separately in its own right
> (in the above case the first space character in the string) because
> it matches the search regexp.

That match overlaps the current match.

> IOW, what is more logical to do according to your approach is not to hide
> the lazy-highlighted match under point, but split it to two matches
> where the match preceding the current search position is lazy-highlighted
> and the second match under point is hidden.

I don't agree.  I think a match should either be highlighted completely
or not at all.  But we might be splitting hairs at this point.

> > We can't really document this either.

> Actually, documenting this effect is a very good idea
> that in any case should be done in emacs-24.

> > I'm surprised how difficult the fix is.

> That's is why I prefer to refrain from making hasty changes that might
> cause more problems in unexpected places making other users unhappy.

I think I must now reluctantly agree with you here.  There just aren't
enough pretests left before Emacs 24.3 to test it properly.  I grepped -l
isearch, and it came up with over 70 matching files.  grepping for
isearch-lazy-highlight produced just 4 matches, the already identified
files plus .../lisp/cedet/semantic/senator.el.

How about installing the change in the trunk so that people can try it
out?

Anyhow, just for the sake of completeness, here is the part of the patch
which fixes ispell.e:



=== modified file 'lisp/textmodes/ispell.el'
*** lisp/textmodes/ispell.el	2013-01-01 09:11:05 +0000
--- lisp/textmodes/ispell.el	2013-02-20 21:11:47 +0000
***************
*** 2491,2506 ****
  	(delete-overlay ispell-overlay)))
    (if (and ispell-lazy-highlight (boundp 'lazy-highlight-cleanup))
        (if highlight
! 	  (let ((isearch-string
! 		 (concat
! 		  "\\b"
! 		  (regexp-quote (buffer-substring-no-properties start end))
! 		  "\\b"))
! 		(isearch-regexp t)
! 		(isearch-case-fold-search nil))
! 	    (isearch-lazy-highlight-new-loop
! 	     (if (boundp 'reg-start) reg-start)
! 	     (if (boundp 'reg-end)   reg-end)))
  	(lazy-highlight-cleanup lazy-highlight-cleanup)
  	(setq isearch-lazy-highlight-last-string nil))))
  
--- 2491,2509 ----
  	(delete-overlay ispell-overlay)))
    (if (and ispell-lazy-highlight (boundp 'lazy-highlight-cleanup))
        (if highlight
! 	  (save-excursion
! 	    (goto-char start)
! 	    (let ((isearch-string
! 		   (concat
! 		    "\\b"
! 		    (regexp-quote (buffer-substring-no-properties start end))
! 		    "\\b"))
! 		  (isearch-regexp t)
! 		  (isearch-case-fold-search nil)
! 		  (isearch-other-end end))
! 	      (isearch-lazy-highlight-new-loop
! 	       (if (boundp 'reg-start) reg-start)
! 	       (if (boundp 'reg-end)   reg-end))))
  	(lazy-highlight-cleanup lazy-highlight-cleanup)
  	(setq isearch-lazy-highlight-last-string nil))))
  

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2013-02-20 22:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10 13:25 bug#13402: 24.2.92 pretest: bugs in isearch-yank-line in info page Alan Mackenzie
2013-01-10 18:21 ` Andreas Schwab
2013-01-11  0:43 ` Juri Linkov
2013-02-13  9:47   ` Alan Mackenzie
2013-02-13 17:53     ` Juri Linkov
2013-02-13 21:59       ` Alan Mackenzie
2013-02-14  9:16         ` Juri Linkov
2013-02-14 20:09 ` 24.2.92 pretest: bugs in isearch-yank-line in info page. [Patch] Alan Mackenzie
2013-02-14 23:53   ` bug#13402: " Glenn Morris
2013-02-15  7:47   ` Juri Linkov
2013-02-15 10:10     ` Juri Linkov
2013-02-15 11:55       ` Alan Mackenzie
2013-02-15 13:20       ` Alan Mackenzie
2013-02-16 21:50         ` Juri Linkov
2013-02-17 10:03           ` Juri Linkov
2013-02-19 14:50           ` Alan Mackenzie
2013-02-20 10:49             ` Juri Linkov
2013-02-20 22:37               ` Alan Mackenzie [this message]
2013-02-21  0:45                 ` Juri Linkov
2013-02-21 12:27                   ` Alan Mackenzie
2013-02-21 17:09                     ` Glenn Morris
2013-02-21 17:48                       ` Juri Linkov
2013-02-14 20:09 ` Alan Mackenzie

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130220223759.GA2644@acm.acm \
    --to=acm@muc.de \
    --cc=13402@debbugs.gnu.org \
    --cc=juri@jurta.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.