* Allowing completion sources to customize completion display @ 2023-11-22 23:05 Spencer Baugh 2023-11-23 8:25 ` Eshel Yaron 2023-11-23 14:44 ` Dmitry Gutov 0 siblings, 2 replies; 19+ messages in thread From: Spencer Baugh @ 2023-11-22 23:05 UTC (permalink / raw) To: emacs-devel If I have multiple sources for completion active at once, I might prefer different completion sources to be displayed differently. For example, if a completion source returns individual symbols, displaying the symbols in the *Completions* buffer seems good. So the default completion-in-region-function is good. But if a completion source returns multi-line blocks of text, I might want to see those blocks of text displayed in context in the buffer, rather than in a separate buffer. Perhaps I'd see only the first completion candidate displayed in-buffer, and have some key bindings which let me cycle between them. The exact details of the UI aren't important, just that it's different from what I want for symbol completion. So I'd set completion-in-region-function to something different. I have completion-at-point-functions='(symbol-completion block-completion), so if symbol-completion returns nil then I get block-completion instead - exactly what I want. But the same completion-in-region-function and UI has to be used regardless of whether I'm getting symbol-completion or block-completion - I don't see a way to change completion-in-region-function based on the source. Maybe we should add one? Some possibilities: - Maybe completion table metadata could just include a completion-in-region-function to use? - Maybe completion-category-overrides could change completion-in-region-function based on the category? - Maybe something else entirely? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-22 23:05 Allowing completion sources to customize completion display Spencer Baugh @ 2023-11-23 8:25 ` Eshel Yaron 2023-11-23 8:47 ` Eli Zaretskii 2023-11-23 14:44 ` Dmitry Gutov 1 sibling, 1 reply; 19+ messages in thread From: Eshel Yaron @ 2023-11-23 8:25 UTC (permalink / raw) To: Spencer Baugh; +Cc: emacs-devel Spencer Baugh <sbaugh@janestreet.com> writes: > If I have multiple sources for completion active at once, I might prefer > different completion sources to be displayed differently. > > ... > > But the same completion-in-region-function and UI has to be used > regardless of whether I'm getting symbol-completion or block-completion > - I don't see a way to change completion-in-region-function based on the > source. > > Maybe we should add one? FWIW I had similar thoughts just the other day. Allowing capfs to request a certain selection UI makes sense in some situations, because sometimes the most appropriate UI may depend on the results of a specific capf. For example, say we have a legacy completion command, e.g. `ispell-complete-word`, that we want to port to a capf. But the legacy completion command comes with its bespoke completion selection UI, so it might be desirable to have the new capf mimic the legacy UI during the transition phase, without affecting other capfs, so other capfs still use the regular UI when they take effect. OTOH, IMO it's better to keep the UI as consistent and predictable as possible, so I would avoid using such a capability too liberally. > Some possibilities: > - Maybe completion table metadata could just include a > completion-in-region-function to use? > > - Maybe completion-category-overrides could change > completion-in-region-function based on the category? > > - Maybe something else entirely? How about something like the following? That seems simple enough and gives individual capfs full discretion to specify their selection UI. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 5c12d9fc914..ff5472040d3 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -2823,7 +2823,10 @@ completion-at-point (lambda () ;; We're still in the same completion field. (let ((newstart (car-safe (funcall hookfun)))) - (and newstart (= newstart start)))))) + (and newstart (= newstart start))))) + (completion-in-region-function + (or (plist-get plist :completion-in-region-function) + completion-in-region-function))) (completion-in-region start end collection (plist-get plist :predicate)))) ;; Maybe completion already happened and the function returned t. ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-23 8:25 ` Eshel Yaron @ 2023-11-23 8:47 ` Eli Zaretskii 2023-11-23 12:38 ` sbaugh 2023-11-23 21:20 ` Jim Porter 0 siblings, 2 replies; 19+ messages in thread From: Eli Zaretskii @ 2023-11-23 8:47 UTC (permalink / raw) To: Eshel Yaron; +Cc: sbaugh, emacs-devel > From: Eshel Yaron <me@eshelyaron.com> > Cc: emacs-devel@gnu.org > Date: Thu, 23 Nov 2023 09:25:19 +0100 > > How about something like the following? That seems simple enough and > gives individual capfs full discretion to specify their selection UI. IMNSHO, it will be a sad day when different completion sources will present different completion UI. There will be no end to user confusion. Completion UI is a user preference, and if we want to support different UIs (as we already do), we should leave it to the user to specify the UI he/she prefers, and then abide by that. Completion-related frameworks that cannot work like that should not pretend being "completion", but some different features, even if they use completion functions under the hood. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-23 8:47 ` Eli Zaretskii @ 2023-11-23 12:38 ` sbaugh 2023-11-23 13:48 ` Eli Zaretskii 2023-11-23 21:20 ` Jim Porter 1 sibling, 1 reply; 19+ messages in thread From: sbaugh @ 2023-11-23 12:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Eshel Yaron, sbaugh, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Eshel Yaron <me@eshelyaron.com> >> Cc: emacs-devel@gnu.org >> Date: Thu, 23 Nov 2023 09:25:19 +0100 >> >> How about something like the following? That seems simple enough and >> gives individual capfs full discretion to specify their selection UI. > > IMNSHO, it will be a sad day when different completion sources will > present different completion UI. There will be no end to user > confusion. > > Completion UI is a user preference, and if we want to support > different UIs (as we already do), we should leave it to the user to > specify the UI he/she prefers, and then abide by that. Sure. I, as a user, want to specify two different UIs for two different completion sources. Currently this is impossible. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-23 12:38 ` sbaugh @ 2023-11-23 13:48 ` Eli Zaretskii 2023-11-23 14:03 ` sbaugh 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2023-11-23 13:48 UTC (permalink / raw) To: sbaugh; +Cc: me, sbaugh, emacs-devel > From: sbaugh@catern.com > Date: Thu, 23 Nov 2023 12:38:22 +0000 (UTC) > Cc: Eshel Yaron <me@eshelyaron.com>, sbaugh@janestreet.com, > emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > > > > IMNSHO, it will be a sad day when different completion sources will > > present different completion UI. There will be no end to user > > confusion. > > > > Completion UI is a user preference, and if we want to support > > different UIs (as we already do), we should leave it to the user to > > specify the UI he/she prefers, and then abide by that. > > Sure. I, as a user, want to specify two different UIs for two different > completion sources. > > Currently this is impossible. It shouldn't be possible. Users should not need to be aware of the completion sources. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-23 13:48 ` Eli Zaretskii @ 2023-11-23 14:03 ` sbaugh 2023-11-23 14:35 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: sbaugh @ 2023-11-23 14:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: me, sbaugh, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: sbaugh@catern.com >> Date: Thu, 23 Nov 2023 12:38:22 +0000 (UTC) >> Cc: Eshel Yaron <me@eshelyaron.com>, sbaugh@janestreet.com, >> emacs-devel@gnu.org >> >> Eli Zaretskii <eliz@gnu.org> writes: >> > >> > IMNSHO, it will be a sad day when different completion sources will >> > present different completion UI. There will be no end to user >> > confusion. >> > >> > Completion UI is a user preference, and if we want to support >> > different UIs (as we already do), we should leave it to the user to >> > specify the UI he/she prefers, and then abide by that. >> >> Sure. I, as a user, want to specify two different UIs for two different >> completion sources. >> >> Currently this is impossible. > > It shouldn't be possible. Users should not need to be aware of the > completion sources. Why not? I just explained a use case where users are definitely already aware of the completion sources, and Eshel mentioned another one. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-23 14:03 ` sbaugh @ 2023-11-23 14:35 ` Eli Zaretskii 0 siblings, 0 replies; 19+ messages in thread From: Eli Zaretskii @ 2023-11-23 14:35 UTC (permalink / raw) To: sbaugh; +Cc: me, sbaugh, emacs-devel > From: sbaugh@catern.com > Date: Thu, 23 Nov 2023 14:03:37 +0000 (UTC) > Cc: me@eshelyaron.com, sbaugh@janestreet.com, emacs-devel@gnu.org > > Eli Zaretskii <eliz@gnu.org> writes: > >> From: sbaugh@catern.com > >> Date: Thu, 23 Nov 2023 12:38:22 +0000 (UTC) > >> Cc: Eshel Yaron <me@eshelyaron.com>, sbaugh@janestreet.com, > >> emacs-devel@gnu.org > >> > >> Eli Zaretskii <eliz@gnu.org> writes: > >> > > >> > IMNSHO, it will be a sad day when different completion sources will > >> > present different completion UI. There will be no end to user > >> > confusion. > >> > > >> > Completion UI is a user preference, and if we want to support > >> > different UIs (as we already do), we should leave it to the user to > >> > specify the UI he/she prefers, and then abide by that. > >> > >> Sure. I, as a user, want to specify two different UIs for two different > >> completion sources. > >> > >> Currently this is impossible. > > > > It shouldn't be possible. Users should not need to be aware of the > > completion sources. > > Why not? I just explained a use case where users are definitely already > aware of the completion sources, and Eshel mentioned another one. You _can_ be aware of the source, but we must not _require_ users to be aware. If the user is NOT aware, he/she will not be able to set up the UI according to the source. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-23 8:47 ` Eli Zaretskii 2023-11-23 12:38 ` sbaugh @ 2023-11-23 21:20 ` Jim Porter 2023-11-24 7:15 ` Eli Zaretskii 1 sibling, 1 reply; 19+ messages in thread From: Jim Porter @ 2023-11-23 21:20 UTC (permalink / raw) To: Eli Zaretskii, Eshel Yaron; +Cc: sbaugh, emacs-devel On 11/23/2023 12:47 AM, Eli Zaretskii wrote: > IMNSHO, it will be a sad day when different completion sources will > present different completion UI. There will be no end to user > confusion. I think Spencer's suggestion below would be ok (assuming it actually works). Then it's up to the users themselves to opt-in to different UI for different sources: On 11/22/2023 3:05 PM, Spencer Baugh wrote: > - Maybe completion-category-overrides could change > completion-in-region-function based on the category? Whether that's the best solution is another story, but I don't think it would cause any extra confusion, since nothing would change by default. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-23 21:20 ` Jim Porter @ 2023-11-24 7:15 ` Eli Zaretskii 2023-11-24 17:28 ` Spencer Baugh 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2023-11-24 7:15 UTC (permalink / raw) To: Jim Porter; +Cc: me, sbaugh, emacs-devel > Date: Thu, 23 Nov 2023 13:20:27 -0800 > Cc: sbaugh@janestreet.com, emacs-devel@gnu.org > From: Jim Porter <jporterbugs@gmail.com> > > On 11/23/2023 12:47 AM, Eli Zaretskii wrote: > > IMNSHO, it will be a sad day when different completion sources will > > present different completion UI. There will be no end to user > > confusion. > > I think Spencer's suggestion below would be ok (assuming it actually > works). Then it's up to the users themselves to opt-in to different UI > for different sources: > > On 11/22/2023 3:05 PM, Spencer Baugh wrote: > > - Maybe completion-category-overrides could change > > completion-in-region-function based on the category? I don't see how this resolves the issue I had in mind, which is that users should NOT be presented with different completion-related displays and use different completion-related commands depending on the source of the completion data. Quite the opposite: each source of the completion data should be able to adapt its presentation to the user preferences, as expressed via user options (if we have such UI-related options). Users should not re-learn how to use completion in Emacs each time we add some new source of completion data to some command that offers completion. E.g., consider the following half-theoretical example: suppose the file-name completion learns to offer completion candidates from some source other than the list of files in default-directory -- my point is that those additional files that come from those other sources should be displayed in exactly the same way as the "traditional" source, and let users use the same commands to complete. Anything else would be terribly confusing, and we should not do it. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-24 7:15 ` Eli Zaretskii @ 2023-11-24 17:28 ` Spencer Baugh 2023-11-24 20:52 ` [External] : " Drew Adams ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Spencer Baugh @ 2023-11-24 17:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Jim Porter, me, emacs-devel, Dmitry Gutov, Juri Linkov Eli Zaretskii <eliz@gnu.org> writes: >> Date: Thu, 23 Nov 2023 13:20:27 -0800 >> Cc: sbaugh@janestreet.com, emacs-devel@gnu.org >> From: Jim Porter <jporterbugs@gmail.com> >> >> On 11/23/2023 12:47 AM, Eli Zaretskii wrote: >> > IMNSHO, it will be a sad day when different completion sources will >> > present different completion UI. There will be no end to user >> > confusion. >> >> I think Spencer's suggestion below would be ok (assuming it actually >> works). Then it's up to the users themselves to opt-in to different UI >> for different sources: >> >> On 11/22/2023 3:05 PM, Spencer Baugh wrote: >> > - Maybe completion-category-overrides could change >> > completion-in-region-function based on the category? > > I don't see how this resolves the issue I had in mind, which is that > users should NOT be presented with different completion-related > displays and use different completion-related commands depending on > the source of the completion data. Quite the opposite: each source of > the completion data should be able to adapt its presentation to the > user preferences, as expressed via user options (if we have such > UI-related options). Users should not re-learn how to use completion > in Emacs each time we add some new source of completion data to some > command that offers completion. > > E.g., consider the following half-theoretical example: suppose the > file-name completion learns to offer completion candidates from some > source other than the list of files in default-directory -- my point > is that those additional files that come from those other sources > should be displayed in exactly the same way as the "traditional" > source, and let users use the same commands to complete. Anything > else would be terribly confusing, and we should not do it. Ah, yes, this cued me to think about it differently. I think you're right that I don't want to customize the UI based on the completion source. In my example, I was considering two sources, one which returns symbols and one which usually returns big multi-line strings. And I, as a user, wanted the default Completions buffer for the first, and inline preview for the second. But basing this on the source is totally wrong. Instead if I, as a user, think inline preview is better for multi-line completion candidates, then inline preview should be used for multi-line completion candidates regardless of where those candidates come from. So I, as a user, can just configure my completion UI to detect multi-line completion candidates and alter the UI in that case. No need to care about the sources of completion candidates. And such configuration options would be straightforward to add to any completion UI, including the default completion-in-region-function. So that seems great, and is obviously how it should work. --------------- Now just separately speculating about what concrete options might be nice to add at some point to the default completion UI, to get nice inline preview behavior for multi-line strings... Perhaps two options: - completions-ghost-preview=t shows, in the buffer or minibuffer, a grayed-out "ghost" preview of the currently selected completion candidate. - completions-multi-line-suppress=t makes the *Completions* buffer shrink down to just show completion-header-format and completion-show-help whenever there's multi-line candidates among the completions. (So you'd only have the preview from completions-ghost-preview.) ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [External] : Re: Allowing completion sources to customize completion display 2023-11-24 17:28 ` Spencer Baugh @ 2023-11-24 20:52 ` Drew Adams 2023-11-25 0:25 ` Dmitry Gutov 2023-11-25 6:59 ` Eli Zaretskii 2 siblings, 0 replies; 19+ messages in thread From: Drew Adams @ 2023-11-24 20:52 UTC (permalink / raw) To: Spencer Baugh, Eli Zaretskii Cc: Jim Porter, me@eshelyaron.com, emacs-devel@gnu.org, Dmitry Gutov, Juri Linkov > Now just separately speculating about what concrete options might be > nice to add at some point to the default completion UI, to get nice > inline preview behavior for multi-line strings... Perhaps two options: > - completions-ghost-preview=t shows, in the buffer or minibuffer, a > grayed-out "ghost" preview of the currently selected completion > candidate. > - completions-multi-line-suppress=t makes the *Completions* buffer > shrink down to just show completion-header-format and > completion-show-help whenever there's multi-line candidates among the > completions. (So you'd only have the preview from > completions-ghost-preview.) FWIW (I'm not following this thread) - Icicles has option `icicle-hide-non-matching-lines-flag', which you can toggle anytime during completion with `C-u C-x .': Non-nil means hide candidate lines that do not match input. This applies only to multi-line candidates in buffer `*Completions*'. Lines that do not contain text matched by your current minibuffer input are elided using ellipsis (`...'). Also option `icicle-hide-common-match-in-Completions-flag', which you can toggle during completion with just `C-x .': Non-nil means hide the common match for your input, in `*Completions*'. The common match used here is governed by option `icicle-expand-input-to-common-match'. It is elided using ellipsis (`...'). When you hide non-matching lines of completions or their common-match portions you still see all of the candidates. It's just that some of their text may be elided. Hiding common-match text can be especially useful when that portion of the candidates is large, as it often is with absolute file names having a common subdirectory. This is _not_ specific to any particular kind or category of completion. It's a question of what a particular user finds most useful at any given time. Do _you_ want to hide some candidate details right _now_, or not? As usual, my advice for this kind of thing is to give users control - don't just deciding on a "DWIM" behavior (which might be fine as a _default_ behavior but should not be the only one). Let _users_ decide what "I mean" means at any given time in any given context. A user option sets a user's preferred default behavior. But it's even more important to be able to control the behavior dynamically, by toggling or cycling among possible behaviors. It's good (imperative, really) to give users dynamic control. But it can also help to give them (and library writers) control over the default behavior of a _given command_. For hiding the common match among the current completions this is done by adding/removing property `icicle-hide-common-match' to/from a command symbol that uses completion. For example, by default command `icicle-locate-file' has (put 'icicle-locate-file 'icicle-hide-common-match t). But someone who wants that command to show common matches by default can put this it their init file: (put 'icicle-locate-file 'icicle-hide-common-match nil) HTH. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-24 17:28 ` Spencer Baugh 2023-11-24 20:52 ` [External] : " Drew Adams @ 2023-11-25 0:25 ` Dmitry Gutov 2023-11-25 17:36 ` sbaugh 2023-11-25 6:59 ` Eli Zaretskii 2 siblings, 1 reply; 19+ messages in thread From: Dmitry Gutov @ 2023-11-25 0:25 UTC (permalink / raw) To: Spencer Baugh, Eli Zaretskii; +Cc: Jim Porter, me, emacs-devel, Juri Linkov On 24/11/2023 19:28, Spencer Baugh wrote: > But basing this on the source is totally wrong. Instead if I, as a > user, think inline preview is better for multi-line completion > candidates, then inline preview should be used for multi-line completion > candidates regardless of where those candidates come from. Are multi-line completions better shown inline? If I had to choose, I might actually choose the opposite: show the shorter ones inline, and the long ones in a separate buffer -- so that the current buffer's text doesn't jump up and down as I'm typing something. But that strongly depends on how those long completions are going to be presented, whether they should replace the current text or just add new one (multiple lines of it), whether they are allowed to vary a lot, etc. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-25 0:25 ` Dmitry Gutov @ 2023-11-25 17:36 ` sbaugh 2023-11-25 18:27 ` Dmitry Gutov 0 siblings, 1 reply; 19+ messages in thread From: sbaugh @ 2023-11-25 17:36 UTC (permalink / raw) To: emacs-devel Dmitry Gutov <dmitry@gutov.dev> writes: > On 24/11/2023 19:28, Spencer Baugh wrote: >> But basing this on the source is totally wrong. Instead if I, as a >> user, think inline preview is better for multi-line completion >> candidates, then inline preview should be used for multi-line completion >> candidates regardless of where those candidates come from. > > Are multi-line completions better shown inline? If I had to choose, I > might actually choose the opposite: show the shorter ones inline, and > the long ones in a separate buffer -- so that the current buffer's > text doesn't jump up and down as I'm typing something. The idea is that multi-line completions are big, so you can only really afford to show one large completion candidate on-screen at a time. Whereas for shorter completions you can usefully fit multiple on screen at a time. To be clear, I haven't mentioned any in-buffer menus like company-mode has. If it was done with company certainly there would be in-buffer menus, and I think what I would want is "always show a preview frontend, and show a tooltip frontend only if the completion candidates are small. (not multi-line)". > But that strongly depends on how those long completions are going to > be presented, whether they should replace the current text or just add > new one (multiple lines of it), whether they are allowed to vary a > lot, etc. The long completions in my case are ones which can both modify or add text, both before or after point. But that's an interesting point. An in-buffer menu (like company-mode has) is a lot less suitable for completions which modify the text in complex ways. With such completions, an in-buffer preview is nicer. So perhaps that's another way a completion UI (such as company) could alter its behavior based on the completions: only show completion candidates in an in-buffer menu (a tooltip frontend) if they are "simple" (e.g. just symbol completion which leaves point after the newly inserted symbol). If they are complex, do an in-buffer preview. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-25 17:36 ` sbaugh @ 2023-11-25 18:27 ` Dmitry Gutov 2023-11-25 19:07 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Dmitry Gutov @ 2023-11-25 18:27 UTC (permalink / raw) To: sbaugh, emacs-devel On 25/11/2023 19:36, sbaugh@catern.com wrote: > Dmitry Gutov <dmitry@gutov.dev> writes: >> On 24/11/2023 19:28, Spencer Baugh wrote: >>> But basing this on the source is totally wrong. Instead if I, as a >>> user, think inline preview is better for multi-line completion >>> candidates, then inline preview should be used for multi-line completion >>> candidates regardless of where those candidates come from. >> >> Are multi-line completions better shown inline? If I had to choose, I >> might actually choose the opposite: show the shorter ones inline, and >> the long ones in a separate buffer -- so that the current buffer's >> text doesn't jump up and down as I'm typing something. > > The idea is that multi-line completions are big, so you can only really > afford to show one large completion candidate on-screen at a time. > Whereas for shorter completions you can usefully fit multiple on screen > at a time. > > To be clear, I haven't mentioned any in-buffer menus like company-mode > has. If it was done with company certainly there would be in-buffer > menus, and I think what I would want is "always show a preview frontend, > and show a tooltip frontend only if the completion candidates are > small. (not multi-line)". I hadn't considered company-mode in that context, but the preview frontend in there should look more or less like the "Completion Preview" feature proposed (or recently added?) to the core. >> But that strongly depends on how those long completions are going to >> be presented, whether they should replace the current text or just add >> new one (multiple lines of it), whether they are allowed to vary a >> lot, etc. > > The long completions in my case are ones which can both modify or add > text, both before or after point. > > But that's an interesting point. An in-buffer menu (like company-mode > has) is a lot less suitable for completions which modify the text in > complex ways. With such completions, an in-buffer preview is nicer. > > So perhaps that's another way a completion UI (such as company) could > alter its behavior based on the completions: only show completion > candidates in an in-buffer menu (a tooltip frontend) if they are > "simple" (e.g. just symbol completion which leaves point after the newly > inserted symbol). If they are complex, do an in-buffer preview. The menu can still be shown if the long candidates are "smartly" truncated in some way. And yeah, for that usage the preview frontend should probably be always-on, not just when there is just one completion. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-25 18:27 ` Dmitry Gutov @ 2023-11-25 19:07 ` Eli Zaretskii 2023-11-25 19:08 ` Dmitry Gutov 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2023-11-25 19:07 UTC (permalink / raw) To: Dmitry Gutov; +Cc: sbaugh, emacs-devel > Date: Sat, 25 Nov 2023 20:27:51 +0200 > From: Dmitry Gutov <dmitry@gutov.dev> > > I hadn't considered company-mode in that context, but the preview > frontend in there should look more or less like the "Completion Preview" > feature proposed (or recently added?) to the core. It is possible that providing an in-buffer preview for multi-line completions makes no sense, and we shouldn't even try. If the solutions are to show the preview in a separate window, then how is this different from popping up the *Completions* buffer? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-25 19:07 ` Eli Zaretskii @ 2023-11-25 19:08 ` Dmitry Gutov 2023-11-25 20:04 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Dmitry Gutov @ 2023-11-25 19:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sbaugh, emacs-devel On 25/11/2023 21:07, Eli Zaretskii wrote: >> Date: Sat, 25 Nov 2023 20:27:51 +0200 >> From: Dmitry Gutov<dmitry@gutov.dev> >> >> I hadn't considered company-mode in that context, but the preview >> frontend in there should look more or less like the "Completion Preview" >> feature proposed (or recently added?) to the core. > It is possible that providing an in-buffer preview for multi-line > completions makes no sense, and we shouldn't even try. If the > solutions are to show the preview in a separate window, then how is > this different from popping up the*Completions* buffer? I think when we say "preview", we usually mean "inline preview". Not separate window. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-25 19:08 ` Dmitry Gutov @ 2023-11-25 20:04 ` Eli Zaretskii 0 siblings, 0 replies; 19+ messages in thread From: Eli Zaretskii @ 2023-11-25 20:04 UTC (permalink / raw) To: Dmitry Gutov; +Cc: sbaugh, emacs-devel > Date: Sat, 25 Nov 2023 21:08:20 +0200 > Cc: sbaugh@catern.com, emacs-devel@gnu.org > From: Dmitry Gutov <dmitry@gutov.dev> > > On 25/11/2023 21:07, Eli Zaretskii wrote: > >> Date: Sat, 25 Nov 2023 20:27:51 +0200 > >> From: Dmitry Gutov<dmitry@gutov.dev> > >> > >> I hadn't considered company-mode in that context, but the preview > >> frontend in there should look more or less like the "Completion Preview" > >> feature proposed (or recently added?) to the core. > > It is possible that providing an in-buffer preview for multi-line > > completions makes no sense, and we shouldn't even try. If the > > solutions are to show the preview in a separate window, then how is > > this different from popping up the*Completions* buffer? > > I think when we say "preview", we usually mean "inline preview". Not > separate window. AFAIR, one of the proposals for handling the preview of multi-line candidates was to show a special buffer (supposedly, in a window, how else?). ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-24 17:28 ` Spencer Baugh 2023-11-24 20:52 ` [External] : " Drew Adams 2023-11-25 0:25 ` Dmitry Gutov @ 2023-11-25 6:59 ` Eli Zaretskii 2 siblings, 0 replies; 19+ messages in thread From: Eli Zaretskii @ 2023-11-25 6:59 UTC (permalink / raw) To: Spencer Baugh; +Cc: jporterbugs, me, emacs-devel, dmitry, juri > From: Spencer Baugh <sbaugh@janestreet.com> > Cc: Jim Porter <jporterbugs@gmail.com>, me@eshelyaron.com, > emacs-devel@gnu.org, Dmitry Gutov <dmitry@gutov.dev>, Juri Linkov > <juri@linkov.net> > Date: Fri, 24 Nov 2023 12:28:34 -0500 > > In my example, I was considering two sources, one which returns symbols > and one which usually returns big multi-line strings. And I, as a user, > wanted the default Completions buffer for the first, and inline preview > for the second. > > But basing this on the source is totally wrong. Instead if I, as a > user, think inline preview is better for multi-line completion > candidates, then inline preview should be used for multi-line completion > candidates regardless of where those candidates come from. > > So I, as a user, can just configure my completion UI to detect > multi-line completion candidates and alter the UI in that case. No need > to care about the sources of completion candidates. > > And such configuration options would be straightforward to add to any > completion UI, including the default completion-in-region-function. I'm not sure I understand what you mean by "multi-line completion candidates", but if I do, IMO we should display each supported format of completion candidates in a way that fits that format. IOW, there's no reason to ask the user to configure that; we should instead provide OOTB built-in UI for displaying candidates based on their "type". > Now just separately speculating about what concrete options might be > nice to add at some point to the default completion UI, to get nice > inline preview behavior for multi-line strings... > > Perhaps two options: > > - completions-ghost-preview=t shows, in the buffer or minibuffer, a > grayed-out "ghost" preview of the currently selected completion > candidate. > > - completions-multi-line-suppress=t makes the *Completions* buffer > shrink down to just show completion-header-format and > completion-show-help whenever there's multi-line candidates among the > completions. (So you'd only have the preview from > completions-ghost-preview.) If this is about preview of candidates specifically, using the *Completions* buffer doesn't sound like a good idea to me, since popping a buffer up and down and resizing its window as the user types produces annoying visual effects, and also will slow down the preview, since these operations are relatively expensive. How about showing a multiline "ghost" instead? Or maybe you should produce a few examples of such multiline candidates, so that this discussion is less academic? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Allowing completion sources to customize completion display 2023-11-22 23:05 Allowing completion sources to customize completion display Spencer Baugh 2023-11-23 8:25 ` Eshel Yaron @ 2023-11-23 14:44 ` Dmitry Gutov 1 sibling, 0 replies; 19+ messages in thread From: Dmitry Gutov @ 2023-11-23 14:44 UTC (permalink / raw) To: Spencer Baugh, emacs-devel On 23/11/2023 01:05, Spencer Baugh wrote: > But the same completion-in-region-function and UI has to be used > regardless of whether I'm getting symbol-completion or block-completion > - I don't see a way to change completion-in-region-function based on the > source. completion-in-region-function accepts COLLECTION, right? That's usually the completion table. From there, you can access the table's metadata and see its category or etc (if you control the table, it could contain some additional distinctions). So your custom completion-in-region-function could look up metadata and dispatch to one of the two specific interfaces, couldn't it? ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2023-11-25 20:04 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-11-22 23:05 Allowing completion sources to customize completion display Spencer Baugh 2023-11-23 8:25 ` Eshel Yaron 2023-11-23 8:47 ` Eli Zaretskii 2023-11-23 12:38 ` sbaugh 2023-11-23 13:48 ` Eli Zaretskii 2023-11-23 14:03 ` sbaugh 2023-11-23 14:35 ` Eli Zaretskii 2023-11-23 21:20 ` Jim Porter 2023-11-24 7:15 ` Eli Zaretskii 2023-11-24 17:28 ` Spencer Baugh 2023-11-24 20:52 ` [External] : " Drew Adams 2023-11-25 0:25 ` Dmitry Gutov 2023-11-25 17:36 ` sbaugh 2023-11-25 18:27 ` Dmitry Gutov 2023-11-25 19:07 ` Eli Zaretskii 2023-11-25 19:08 ` Dmitry Gutov 2023-11-25 20:04 ` Eli Zaretskii 2023-11-25 6:59 ` Eli Zaretskii 2023-11-23 14:44 ` Dmitry Gutov
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.