* Re: `isearch-complete1' should use `completion-at-point' or `completion-in-region' (was: bug#39015) [not found] <7da1738e-1e8a-3c12-31bf-741ee171db5c@Alexander.Shukaev.name> @ 2020-01-12 23:36 ` Juri Linkov 2020-01-13 14:35 ` `isearch-complete1' should use `completion-at-point' or `completion-in-region' Alexander Shukaev 2020-01-13 19:38 ` Stefan Monnier 0 siblings, 2 replies; 6+ messages in thread From: Juri Linkov @ 2020-01-12 23:36 UTC (permalink / raw) To: Alexander Shukaev; +Cc: emacs-devel > Not sure why in the first place `isearch-complete1' uses some custom > auto-completion implementation that is different from a conventional > solution, perhaps historical reasons. Thus, I believe that reusing either > `completion-at-point' or `completion-in-region' to implement that > functionality is much better in the long run. This would also allow > packages, which customize completion behavior, to hook into `isearch' > auto-completion as well. See also [1] for example. > > [1] https://github.com/abo-abo/swiper/issues/1882 Indeed, Isearch uses custom completion for historical reasons, and there is no reason for this anymore. But there is one thing I don't understand: how packages prefer to hook into auto-completion? Is it enough to convert `isearch-complete1' to just `completing-read' in the minibuffer activated by `isearch-edit-string'? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: `isearch-complete1' should use `completion-at-point' or `completion-in-region' 2020-01-12 23:36 ` `isearch-complete1' should use `completion-at-point' or `completion-in-region' (was: bug#39015) Juri Linkov @ 2020-01-13 14:35 ` Alexander Shukaev 2020-01-13 19:38 ` Stefan Monnier 1 sibling, 0 replies; 6+ messages in thread From: Alexander Shukaev @ 2020-01-13 14:35 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel On 13/01/2020 00:36, Juri Linkov wrote: >> Not sure why in the first place `isearch-complete1' uses some custom >> auto-completion implementation that is different from a conventional >> solution, perhaps historical reasons. Thus, I believe that reusing either >> `completion-at-point' or `completion-in-region' to implement that >> functionality is much better in the long run. This would also allow >> packages, which customize completion behavior, to hook into `isearch' >> auto-completion as well. See also [1] for example. >> >> [1] https://github.com/abo-abo/swiper/issues/1882 > > Indeed, Isearch uses custom completion for historical reasons, > and there is no reason for this anymore. > > But there is one thing I don't understand: how packages prefer to hook > into auto-completion? Is it enough to convert `isearch-complete1' to > just `completing-read' in the minibuffer activated by `isearch-edit-string'? > Exactly, e.g. `ivy' [1] would pick it up out of the box. [1] https://github.com/abo-abo/swiper/blob/master/ivy.el ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: `isearch-complete1' should use `completion-at-point' or `completion-in-region' 2020-01-12 23:36 ` `isearch-complete1' should use `completion-at-point' or `completion-in-region' (was: bug#39015) Juri Linkov 2020-01-13 14:35 ` `isearch-complete1' should use `completion-at-point' or `completion-in-region' Alexander Shukaev @ 2020-01-13 19:38 ` Stefan Monnier 2020-01-14 23:51 ` Juri Linkov 1 sibling, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2020-01-13 19:38 UTC (permalink / raw) To: Juri Linkov; +Cc: Alexander Shukaev, emacs-devel > But there is one thing I don't understand: how packages prefer to hook > into auto-completion? Is it enough to convert `isearch-complete1' to > just `completing-read' in the minibuffer activated by `isearch-edit-string'? First, there are 2 different cases: `isearch-complete-edit` and `isearch-complete`. For `isearch-complete-edit` we could indeed use `completing-read`, but I don't think I like this idea (e.g. I think it'd be odd for Icomplete to kick in when in `isearch-edit`). So I think the better solution is to set `completion-at-point-functions` and then turn `isearch-complete-edit` into an alias for `completion-at-point`. For `isearch-complete`, it's a bit more tricky because it's a form of completion that is performed on a text that's kept inside a string rather than inside a buffer, so I think we'll still need some ad-hoc code, but it could better use our completion framework. Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: `isearch-complete1' should use `completion-at-point' or `completion-in-region' 2020-01-13 19:38 ` Stefan Monnier @ 2020-01-14 23:51 ` Juri Linkov 2020-01-15 13:57 ` Stefan Monnier 0 siblings, 1 reply; 6+ messages in thread From: Juri Linkov @ 2020-01-14 23:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: Alexander Shukaev, emacs-devel > First, there are 2 different cases: `isearch-complete-edit` and `isearch-complete`. > > For `isearch-complete-edit` we could indeed use `completing-read`, but > I don't think I like this idea (e.g. I think it'd be odd for Icomplete > to kick in when in `isearch-edit`). But the original request was just about allowing completion packages to kick in when in `isearch-edit`, and Icomplete is one kind of such packages. > So I think the better solution is to set `completion-at-point-functions` > and then turn `isearch-complete-edit` into an alias for `completion-at-point`. Maybe something like this: (defun isearch-completion-at-point-function () (list (minibuffer-prompt-end) (point-max) (if isearch-regexp regexp-search-ring search-ring))) (defun isearch-completion-at-point () (interactive) (let* ((completion-ignore-case case-fold-search) (completion-at-point-functions '(isearch-completion-at-point-function))) (completion-at-point))) (define-key minibuffer-local-isearch-map "\M-\t" 'isearch-completion-at-point) But I'm not sure whether this could help completion packages like swiper to hook into isearch completion. > For `isearch-complete`, it's a bit more tricky because it's a form of > completion that is performed on a text that's kept inside a string > rather than inside a buffer, so I think we'll still need some ad-hoc > code, but it could better use our completion framework. `isearch-complete` already activates the minibuffer conditionally when there are completions. It could activate the minibuffer always, then immediately exit the minibuffer when completion-at-point finds no completions. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: `isearch-complete1' should use `completion-at-point' or `completion-in-region' 2020-01-14 23:51 ` Juri Linkov @ 2020-01-15 13:57 ` Stefan Monnier 2020-01-15 23:24 ` Juri Linkov 0 siblings, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2020-01-15 13:57 UTC (permalink / raw) To: Juri Linkov; +Cc: Alexander Shukaev, emacs-devel > Maybe something like this: > > (defun isearch-completion-at-point-function () > (list (minibuffer-prompt-end) (point-max) > (if isearch-regexp regexp-search-ring search-ring))) Looks fine, yes. > (defun isearch-completion-at-point () > (interactive) > (let* ((completion-ignore-case case-fold-search) > (completion-at-point-functions '(isearch-completion-at-point-function))) > (completion-at-point))) Ah, no I was thinking rather of something like (minibuffer-with-setup-hook (lambda () (setq-local completion-ignore-case case-fold-search) (add-hook 'completion-at-point-functions #'isearch-completion-at-point-function nil t)) ...) This way, things like `company-mode` can use it (tho IIUC company-mode currently doesn't work in the minibuffer) and `isearch-complete-edit` can be an obsolete alias of `completion-at-point`. >> For `isearch-complete`, it's a bit more tricky because it's a form of >> completion that is performed on a text that's kept inside a string >> rather than inside a buffer, so I think we'll still need some ad-hoc >> code, but it could better use our completion framework. > `isearch-complete` already activates the minibuffer conditionally > when there are completions. It could activate the minibuffer always, > then immediately exit the minibuffer when completion-at-point > finds no completions. Yes. What I meant is that `isearch-complete` can't be turned into a mere obsolete alias of `completion-at-point`. FWIW, I think it might be worthwhile trying to rewrite isearch such that it always uses the minibuffer (instead of using a transient keymap and displaying the search string in the echo area). Then `isearch-edit` would simply change the minibuffer's keymap such that we only exit the minibuffer in the "usual" way. In such a setting `isearch-complete` could be a simple alias of `completion-at-point`. Stefan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: `isearch-complete1' should use `completion-at-point' or `completion-in-region' 2020-01-15 13:57 ` Stefan Monnier @ 2020-01-15 23:24 ` Juri Linkov 0 siblings, 0 replies; 6+ messages in thread From: Juri Linkov @ 2020-01-15 23:24 UTC (permalink / raw) To: Stefan Monnier; +Cc: Alexander Shukaev, emacs-devel > FWIW, I think it might be worthwhile trying to rewrite isearch such that > it always uses the minibuffer (instead of using a transient keymap and > displaying the search string in the echo area). For the sake of backward-compatibility it would be easier to write a new package implementing just a mapping from keys typed in the isearch minibuffer to the search functions from isearch.el invoked on the original buffer. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-01-15 23:24 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <7da1738e-1e8a-3c12-31bf-741ee171db5c@Alexander.Shukaev.name> 2020-01-12 23:36 ` `isearch-complete1' should use `completion-at-point' or `completion-in-region' (was: bug#39015) Juri Linkov 2020-01-13 14:35 ` `isearch-complete1' should use `completion-at-point' or `completion-in-region' Alexander Shukaev 2020-01-13 19:38 ` Stefan Monnier 2020-01-14 23:51 ` Juri Linkov 2020-01-15 13:57 ` Stefan Monnier 2020-01-15 23:24 ` Juri Linkov
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).