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

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

bug#15667: 24.3.50; ns-win.el -- keymap assignments for isearch-repeat-b


From: Alan Third
Subject: bug#15667: 24.3.50; ns-win.el -- keymap assignments for isearch-repeat-backward/forward.
Date: Thu, 21 Jan 2021 21:47:04 +0000

On Wed, Jan 20, 2021 at 03:42:50AM +0100, Lars Ingebrigtsen wrote:
> Keith David Bershatsky <esq@lawlist.com> writes:
> 
> > The global-map key assignments within ns-win.el for
> > isearch-repeat-backward and isearch-repeat-forward are insufficient to
> > achieve the behavior contemplated by the source code of isearch.el.
> > Specifically, the isearch-mode terminates immediately after invoking
> > the repeat functions and the sticky highlight of searches found does
> > not automatically cleanup.  Invoking these repeat functions should
> > keep isearch-mode active, and then sticky highlight should
> > automatically clean up when exiting the isearch (e.g., by pressing the
> > return key after the search).  The problem is corrected by the
> > following keymap assignments, which mirrors the usage within the
> > source code of isearch.el
> >
> > (define-key global-map [?\s-f] 'isearch-forward)
> > (define-key esc-map [?\s-f] 'isearch-forward-regexp)
> > (define-key minibuffer-local-isearch-map [?\s-f] 
> > 'isearch-forward-exit-minibuffer)
> > (define-key isearch-mode-map [?\s-f] 'isearch-repeat-forward)
> >
> > (define-key global-map [?\s-F] 'isearch-backward)
> > (define-key esc-map [?\s-F] 'isearch-backward-regexp)
> > (define-key minibuffer-local-isearch-map [?\s-F] 
> > 'isearch-reverse-exit-minibuffer)
> > (define-key isearch-mode-map [?\s-F] 'isearch-repeat-backward)
> 
> (I'm going through old bug reports that unfortunately got no response at
> the time.)
> 
> I don't really use the Emacs on Macos much, but perhaps Alan has an
> opinion here?  Added to the CCs.

I don't ever really use these macOS shortcuts, TBH. I've generally
followed the rule that if it's replicating standard behaviour and it
doesn't interfere with something else then it may as well go in.
-- 
Alan Third





reply via email to

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