* Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. @ 2012-03-16 11:05 Vitalie Spinu 2012-03-16 12:18 ` Vitalie Spinu 2012-03-16 17:20 ` Stefan Monnier 0 siblings, 2 replies; 14+ messages in thread From: Vitalie Spinu @ 2012-03-16 11:05 UTC (permalink / raw To: emacs-devel Hi, The completion in emacs 24 is called twice. For example (defun foo-completion () (when (save-excursion (re-search-backward "\\<\\w*" (point-at-bol) t)) (let ((token (match-string-no-properties 0)) (beg (match-beginning 0)) (end (match-end 0))) (message "%s:" token) (when (= end (point)) (list beg end (list "aaaa" "aaaaaaa" "bbbb" "truncat") :exclusive 'no))))) (add-to-list 'completion-at-point-functions 'foo-completion) ;; it is now (foo-completion lisp-completion-at-point t) Place your point at the end of 'aaaa and you try to complete. I am getting aaa: aaaa: in my message buffer. Which means the completion is called twice. I hope this is not an intended behavior, as it might seriously interfere with custom completion. For example I might want to have a different behavior on the second consequent invocation of the completion (give a message, modify the candidates etc). Second problem is that if the completion is sole, the handling is not passed over. For example after 'truncat I am getting a message "Sole completion" and the lisp-completion-at-point is not reached at all. I believe it's not how it should work. In all the rest, new completion system is virtually perfect, thanks. Vitalie. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-16 11:05 Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion Vitalie Spinu @ 2012-03-16 12:18 ` Vitalie Spinu 2012-03-16 17:20 ` Stefan Monnier 1 sibling, 0 replies; 14+ messages in thread From: Vitalie Spinu @ 2012-03-16 12:18 UTC (permalink / raw To: emacs-devel >>>> Vitalie Spinu <spinuvit@gmail.com> >>>> on Fri, 16 Mar 2012 12:05:14 +0100 wrote: > Hi, > The completion in emacs 24 is called twice. For example > (defun foo-completion () > (when (save-excursion (re-search-backward "\\<\\w*" (point-at-bol) t)) > (let ((token (match-string-no-properties 0)) > (beg (match-beginning 0)) > (end (match-end 0))) > (message "%s:" token) > (when (= end (point)) > (list beg end (list "aaaa" "aaaaaaa" "bbbb" "truncat") :exclusive 'no))))) > (add-to-list 'completion-at-point-functions 'foo-completion) > ;; it is now (foo-completion lisp-completion-at-point t) > Place your point at the end of 'aaaa and you try to complete. I am > getting > aaa: > aaaa: > in my message buffer. Which means the completion is called twice. I hope > this is not an intended behavior, as it might seriously interfere with > custom completion. For example I might want to have a different behavior > on the second consequent invocation of the completion (give a message, > modify the candidates etc). A related issue. Position after 'aaaa, try to complete. You will get a "Sole completion" message. Press "space" or "M-b", or whatever, you will get a message "aaaa:" which means that completion is repeated after any other command. This is really bad, as my completion is calling an external process and stalls emacs for a second, badly interfering with the editing. > Second problem is that if the completion is sole, the handling is not > passed over. For example after 'truncat I am getting a message "Sole > completion" and the lisp-completion-at-point is not reached at all. I > believe it's not how it should work. > In all the rest, new completion system is virtually perfect, thanks. > Vitalie. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-16 11:05 Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion Vitalie Spinu 2012-03-16 12:18 ` Vitalie Spinu @ 2012-03-16 17:20 ` Stefan Monnier 2012-03-16 19:33 ` Vitalie Spinu 1 sibling, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2012-03-16 17:20 UTC (permalink / raw To: Vitalie Spinu; +Cc: emacs-devel > The completion in Emacs 24 is called twice. For example > (defun foo-completion () > (when (save-excursion (re-search-backward "\\<\\w*" (point-at-bol) t)) > (let ((token (match-string-no-properties 0)) > (beg (match-beginning 0)) > (end (match-end 0))) > (message "%s:" token) > (when (= end (point)) > (list beg end (list "aaaa" "aaaaaaa" "bbbb" "truncat") :exclusive 'no))))) > (add-to-list 'completion-at-point-functions 'foo-completion) > ;; it is now (foo-completion lisp-completion-at-point t) > Place your point at the end of 'aaaa and you try to complete. I am > getting > aaa: > aaaa: > in my message buffer. Which means the completion is called twice. Not sure why, but not terribly problematic either. > I hope this is not an intended behavior, as it might seriously > interfere with custom completion. For example I might want to have > a different behavior on the second consequent invocation of the > completion (give a message, modify the candidates etc). No, completion-at-point-functions should return completion data and can't know what that data will be used for. Could be for TAB completion, for on-the-fly popup completion à la auto-complete, for display of the *Completions* buffer, or to decide whether we're still in the same completion field (so as to pop-down the *Completions* buffer when we leave that field), ... > Second problem is that if the completion is sole, the handling is not > passed over. That's expected: completion is only passed over if the text doesn't match any candidate. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-16 17:20 ` Stefan Monnier @ 2012-03-16 19:33 ` Vitalie Spinu 2012-03-17 22:34 ` Stefan Monnier 0 siblings, 1 reply; 14+ messages in thread From: Vitalie Spinu @ 2012-03-16 19:33 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel >>>> Stefan Monnier <monnier@iro.umontreal.ca> >>>> on Fri, 16 Mar 2012 13:20:19 -0400 wrote: >> Place your point at the end of 'aaaa and you try to complete. I am >> getting >> aaa: >> aaaa: >> in my message buffer. Which means the completion is called twice. > Not sure why, but not terribly problematic either. Right, unless the completion retrieval is computationally intensive. Please see my other message with a more serious related issue. It might give some clues. >> I hope this is not an intended behavior, as it might seriously >> interfere with custom completion. For example I might want to have >> a different behavior on the second consequent invocation of the >> completion (give a message, modify the candidates etc). > No, completion-at-point-functions should return completion data and > can't know what that data will be used for. Could be for TAB > completion, for on-the-fly popup completion à la auto-complete, for > display of the *Completions* buffer, or to decide whether we're still in > the same completion field (so as to pop-down the *Completions* buffer > when we leave that field), ... In my case it's meaningful, as I retrieve completions from a process. And if there is no process associated with a buffer, I want to message: "Dude stop pressing TAB, there is no proc!!"" Also I think, popup functions should use a different list (like completion-popup-functions). As users might want to use different sets of completions. Also popup completions *must* be considerably less computationally intensive, so it's probably a different set of functions anyhow. >> Second problem is that if the completion is sole, the handling is not >> passed over. > That's expected: completion is only passed over if the text doesn't > match any candidate. IMHO, this is far form an ideal default. Take an example of two completions, one for symbols, another for functions. Or, even the etags completion which is always the last, and might give many more candidates with the same prefix. Best, Vitalie. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-16 19:33 ` Vitalie Spinu @ 2012-03-17 22:34 ` Stefan Monnier 2012-03-17 22:43 ` Lennart Borgman 2012-03-17 23:33 ` Vitalie Spinu 0 siblings, 2 replies; 14+ messages in thread From: Stefan Monnier @ 2012-03-17 22:34 UTC (permalink / raw To: Vitalie Spinu; +Cc: emacs-devel >> Not sure why, but not terribly problematic either. > Right, unless the completion retrieval is computationally intensive. That could be a problem, but I haven't seen a circumstance where this is the case yet. This computation is only meant to decide which completion table to use at a given buffer position. The exact set of candidates can be computed later. > Please see my other message with a more serious related issue. > It might give some clues. I do not see your other message. Is it on emacs-devel or a bug-report? > In my case it's meaningful, as I retrieve completions from a > process. Then you should probably get your completions from the completion-table, rather than from completion-at-point-functions. IOW your completion-at-point-functions should return (without contacting any process, other than maybe checking whether a process exists) a completion table that's a function, e.g. built with completion-table-dynamic, or using complete-with-action and it's *that* function which contacts the process. > Also I think, popup functions should use a different list (like > completion-popup-functions). That might be right (tho I hope it's not), but it doesn't eliminate the fact that completion-at-point-functions might be called in various circumstances. > As users might want to use different sets of completions. I expect completion-at-point-functions to be setup by major modes rather than by users. > Also popup completions *must* be considerably less computationally > intensive, so it's probably a different set of functions anyhow. The way I see it, completion-at-point-functions would instead include in the `props' it returns, enough info to determine whether to use that completion data for popup completion. >>> Second problem is that if the completion is sole, the handling is not >>> passed over. >> That's expected: completion is only passed over if the text doesn't >> match any candidate. > IMHO, this is far form an ideal default. Take an example of two > completions, one for symbols, another for functions. Or, even the > etags completion which is always the last, and might give many more > candidates with the same prefix. You might be right. The current behavior of "fall over" for non-exclusive completion data is not cast in stone and is known to have limitations. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-17 22:34 ` Stefan Monnier @ 2012-03-17 22:43 ` Lennart Borgman 2012-03-17 23:33 ` Vitalie Spinu 1 sibling, 0 replies; 14+ messages in thread From: Lennart Borgman @ 2012-03-17 22:43 UTC (permalink / raw To: Stefan Monnier; +Cc: Vitalie Spinu, emacs-devel On Sat, Mar 17, 2012 at 23:34, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >>> Not sure why, but not terribly problematic either. >> Right, unless the completion retrieval is computationally intensive. > > That could be a problem, but I haven't seen a circumstance where this is > the case yet. This computation is only meant to decide which completion > table to use at a given buffer position. The exact set of candidates > can be computed later. If a parser is involved to make the candidate it can of course take long time. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-17 22:34 ` Stefan Monnier 2012-03-17 22:43 ` Lennart Borgman @ 2012-03-17 23:33 ` Vitalie Spinu 2012-03-18 2:03 ` Stefan Monnier 1 sibling, 1 reply; 14+ messages in thread From: Vitalie Spinu @ 2012-03-17 23:33 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel >>>> Stefan Monnier <monnier@iro.umontreal.ca> >>>> on Sat, 17 Mar 2012 18:34:31 -0400 wrote: >> Please see my other message with a more serious related issue. >> It might give some clues. > I do not see your other message. Is it on emacs-devel or a bug-report? Yes to emacs-devel, http://lists.gnu.org/archive/html/emacs-devel/2012-03/msg00249.html >> In my case it's meaningful, as I retrieve completions from a >> process. > Then you should probably get your completions from the completion-table, > rather than from completion-at-point-functions. > IOW your completion-at-point-functions should return (without contacting > any process, other than maybe checking whether a process exists) > a completion table that's a function, e.g. built with > completion-table-dynamic, or using complete-with-action and it's *that* > function which contacts the process. Thanks for the pointer. I was not aware of this distinction. But why would that make a difference? Isn't the end result the same? Info is silent on this. >> Also I think, popup functions should use a different list (like >> completion-popup-functions). > That might be right (tho I hope it's not), but it doesn't eliminate the > fact that completion-at-point-functions might be called in > various circumstances. I've written auto-complete support and emacs-24 completion at point for R. And it turned out that these two are really distinct features. One is fast, cache based and sloppy, as it should not interfere with the editing. Another one is exact and might be very slow, because it contacts the associated process. The TAB completions can afford to be slow, as there is no editing. >> As users might want to use different sets of completions. > I expect completion-at-point-functions to be setup by major modes rather > than by users. Take auto-complete as an example. There are plenty of different ac-sources, and users use whatever completion they want. Related topic. It would be great to have a separate "namespace" for all buildin completions, or even a dedicated package. Then users and developers can easily find buildin stuff. For instance `completion-filename' instead of `comint-filename-completion', `completion-etags' instead of `tags-completion-at-point-function' etc. Auto-complete package is a good example here - all sources start with "ac-source-". >> Also popup completions *must* be considerably less computationally >> intensive, so it's probably a different set of functions anyhow. > The way I see it, completion-at-point-functions would instead include in > the `props' it returns, enough info to determine whether to use that > completion data for popup completion. To return the props it still must be called, right? Indeed if the completion function were aware that it was called from popup, then it can simply return nil to be skipped. But, AFAICT, this is not currently the case. Vitalie. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-17 23:33 ` Vitalie Spinu @ 2012-03-18 2:03 ` Stefan Monnier 2012-03-18 9:35 ` Vitalie Spinu 0 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2012-03-18 2:03 UTC (permalink / raw To: Vitalie Spinu; +Cc: emacs-devel >> I do not see your other message. Is it on emacs-devel or a bug-report? > Yes to emacs-devel, > http://lists.gnu.org/archive/html/emacs-devel/2012-03/msg00249.html Ah, not sure why I didn't see it, OK here it is: > A related issue. Position after 'aaaa, try to complete. You will get a > "Sole completion" message. Press "space" or "M-b", or whatever, you will > get a message "aaaa:" which means that completion is repeated after any > other command. This is really bad, as my completion is calling an > external process and stalls emacs for a second, badly interfering with > the editing. Again, you're confused: the completion-at-point-functions do not perform completion, they just return the data about what completion table to use at point. >> Then you should probably get your completions from the completion-table, >> rather than from completion-at-point-functions. >> IOW your completion-at-point-functions should return (without contacting >> any process, other than maybe checking whether a process exists) >> a completion table that's a function, e.g. built with >> completion-table-dynamic, or using complete-with-action and it's *that* >> function which contacts the process. > Thanks for the pointer. I was not aware of this distinction. But why > would that make a difference? Because the completion table may or may not be used after being returned by completion-at-point-function. And it may be called with a different string than the one in the buffer. >>> Also I think, popup functions should use a different list (like >>> completion-popup-functions). >> That might be right (tho I hope it's not), but it doesn't eliminate the >> fact that completion-at-point-functions might be called in >> various circumstances. > I've written auto-complete support and emacs-24 completion at point > for R. And it turned out that these two are really distinct features. > One is fast, cache based and sloppy, as it should not interfere with > the editing. Another one is exact and might be very slow, because it > contacts the associated process. The TAB completions can afford to be > slow, as there is no editing. Interesting. So the completion candidates displayed in R-mode for auto-complete are different than the ones used for TAB? > Take auto-complete as an example. There are plenty of different > ac-sources, and users use whatever completion they want. From what I can tell, this is largely because the major modes don't provide this info themselves yet. > Related topic. It would be great to have a separate "namespace" for all > buildin completions, or even a dedicated package. Then users and > developers can easily find buildin stuff. > For instance `completion-filename' instead of `comint-filename-completion', > `completion-etags' instead of `tags-completion-at-point-function' > etc. Auto-complete package is a good example here - all sources start > with "ac-source-". Hmm... more consistency in the naming might be good here, indeed. It's important to keep the "<package>-" prefix since I don't want to consider all of this as part of Emacs's "core", but maybe we could settle on "<something>-completion-at-point-function" or maybe something shorter than that. >>> Also popup completions *must* be considerably less computationally >>> intensive, so it's probably a different set of functions anyhow. >> The way I see it, completion-at-point-functions would instead include in >> the `props' it returns, enough info to determine whether to use that >> completion data for popup completion. > To return the props it still must be called, right? Indeed if the > completion function were aware that it was called from popup, then it > can simply return nil to be skipped. But, AFAICT, this is not currently > the case. As mentioned, completion-point-functions should not work hard: it should just return the boundaries of what it would consider as "the text to complete if we were to complete it", and what code to use to get the completion candidates (again, in case we do decide to perform completion). For auto-complete, we might need to look at the completion candidates very often, in order to decide whether or not to popup a set of completions. But I'd hope that the `props' can provide the needed data (e.g. a predicate function to decide whether or not it's worth the trouble getting the list of candidates). Linking completion-at-point-functions and auto-complete is not done yet, clearly (and will probably also add more completion-metadata). Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-18 2:03 ` Stefan Monnier @ 2012-03-18 9:35 ` Vitalie Spinu 2012-03-18 15:42 ` Stefan Monnier 0 siblings, 1 reply; 14+ messages in thread From: Vitalie Spinu @ 2012-03-18 9:35 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel >>>> Stefan Monnier <monnier@iro.umontreal.ca> >>>> on Sat, 17 Mar 2012 22:03:44 -0400 wrote: >> A related issue. Position after 'aaaa, try to complete. You will get a >> "Sole completion" message. Press "space" or "M-b", or whatever, you will >> get a message "aaaa:" which means that completion is repeated after any >> other command. This is really bad, as my completion is calling an >> external process and stalls emacs for a second, badly interfering with >> the editing. > Again, you're confused: the completion-at-point-functions do not perform > completion, they just return the data about what completion table to use > at point. Ok, I see it more clearly now, with your auto-complete point latter, thanks. Will rewrite and see if it gets better. (...) >> I've written auto-complete support and emacs-24 completion at point >> for R. And it turned out that these two are really distinct features. >> One is fast, cache based and sloppy, as it should not interfere with >> the editing. Another one is exact and might be very slow, because it >> contacts the associated process. The TAB completions can afford to be >> slow, as there is no editing. > Interesting. > So the completion candidates displayed in R-mode for auto-complete are > different than the ones used for TAB? Yes, and no. What I meant is that the underlying mechanisms are very different. 99.99% of the time the completion candidates are the same, but there are objects which are not meaningful to cache, like arguments of the user functions, or components of the recursive structures (lists, environments, data.frames etc.). In this cases AC also calls the process, and it's usually fast. But in some extreme corner cases, like if user changed a function in an attached package, AC will still use the cached version.' > Hmm... more consistency in the naming might be good here, indeed. > It's important to keep the "<package>-" prefix since I don't want to > consider all of this as part of Emacs's "core", but maybe we could > settle on "<something>-completion-at-point-function" or maybe something > shorter than that. I am a fan of the -completion postfix convention. It's easy to match in apropos, anything or IDO regexp: comint-filename-completion, tags-completion, imenu-completion, imenu-in-same-mode-completion, words-in-same-buffer-commpletion etc. It can get pretty long by itself, so a short postfix is better. Best, Vitalie. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-18 9:35 ` Vitalie Spinu @ 2012-03-18 15:42 ` Stefan Monnier 2012-03-18 19:18 ` Vitalie Spinu 0 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2012-03-18 15:42 UTC (permalink / raw To: Vitalie Spinu; +Cc: emacs-devel > Yes, and no. What I meant is that the underlying mechanisms are very > different. 99.99% of the time the completion candidates are the same, > but there are objects which are not meaningful to cache, like arguments > of the user functions, or components of the recursive structures (lists, > environments, data.frames etc.). In this cases AC also calls the > process, and it's usually fast. But in some extreme corner cases, like > if user changed a function in an attached package, AC will still use the > cached version.' So, IIUC it would be perfectly OK for TAB completion to use the AC code. >> Hmm... more consistency in the naming might be good here, indeed. >> It's important to keep the "<package>-" prefix since I don't want to >> consider all of this as part of Emacs's "core", but maybe we could >> settle on "<something>-completion-at-point-function" or maybe something >> shorter than that. > I am a fan of the -completion postfix convention. It's easy to match in > apropos, anything or IDO regexp: comint-filename-completion, > tags-completion, imenu-completion, imenu-in-same-mode-completion, > words-in-same-buffer-commpletion etc. It can get pretty long by itself, > so a short postfix is better. But I suspect it will generate false positives because it's not specific enough. Maybe "-completion-data"? Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-18 15:42 ` Stefan Monnier @ 2012-03-18 19:18 ` Vitalie Spinu 2012-03-19 0:53 ` Stefan Monnier 0 siblings, 1 reply; 14+ messages in thread From: Vitalie Spinu @ 2012-03-18 19:18 UTC (permalink / raw To: emacs-devel >>>> Stefan Monnier <monnier@iro.umontreal.ca> >>>> on Sun, 18 Mar 2012 11:42:27 -0400 wrote: >> Yes, and no. What I meant is that the underlying mechanisms are very >> different. 99.99% of the time the completion candidates are the same, >> but there are objects which are not meaningful to cache, like arguments >> of the user functions, or components of the recursive structures (lists, >> environments, data.frames etc.). In this cases AC also calls the >> process, and it's usually fast. But in some extreme corner cases, like >> if user changed a function in an attached package, AC will still use the >> cached version.' > So, IIUC it would be perfectly OK for TAB completion to use the AC code. Indeed, you could be right that always one-for-all completion function might be made enough for the prefix completion. But I don't see how popup menu can properly deal with partial completions for example, or expansions a la yas. So you would still need a separate list for those. And the old argument still stands - would the user like to have the same redundant list of completion functions for C-M-i and popup menu? >>> Hmm... more consistency in the naming might be good here, indeed. >>> It's important to keep the "<package>-" prefix since I don't want to >>> consider all of this as part of Emacs's "core", but maybe we could >>> settle on "<something>-completion-at-point-function" or maybe something >>> shorter than that. >> I am a fan of the -completion postfix convention. It's easy to match in >> apropos, anything or IDO regexp: comint-filename-completion, >> tags-completion, imenu-completion, imenu-in-same-mode-completion, >> words-in-same-buffer-commpletion etc. It can get pretty long by itself, >> so a short postfix is better. > But I suspect it will generate false positives because it's not > specific enough. Maybe "-completion-data"? Maybe -c-a-p, or -c-a-p-data? Vitalie. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-18 19:18 ` Vitalie Spinu @ 2012-03-19 0:53 ` Stefan Monnier 2012-03-19 8:35 ` Vitalie Spinu 0 siblings, 1 reply; 14+ messages in thread From: Stefan Monnier @ 2012-03-19 0:53 UTC (permalink / raw To: Vitalie Spinu; +Cc: emacs-devel >>> Yes, and no. What I meant is that the underlying mechanisms are very >>> different. 99.99% of the time the completion candidates are the same, >>> but there are objects which are not meaningful to cache, like arguments >>> of the user functions, or components of the recursive structures (lists, >>> environments, data.frames etc.). In this cases AC also calls the >>> process, and it's usually fast. But in some extreme corner cases, like >>> if user changed a function in an attached package, AC will still use the >>> cached version.' >> So, IIUC it would be perfectly OK for TAB completion to use the AC code. > Indeed, you could be right that always one-for-all completion function > might be made enough for the prefix completion. But I don't see how popup > menu can properly deal with partial completions for example, I'd expect popup menus wouldn't use the partial-completion style, but that's not a problem: the completion-styles only care about what to do once we have the completion data, whereas completion-at-point-function does not care about it at all since it only cares about providing that completion data. Every kind of completion UI can use its own (set of) completion style(s). If AC can be made to use a partial-completion style, great, but if not that's just as well. > or expansions a la yas. I guess you're referring to some part of yasnippet, but I don't know which part, nor why it is related to completion-at-point-functions. > So you would still need a separate list for those. As explained, partial-completion is another problem. As for abbrev-like "completion+expansion", I don't see why it can't work with AC (and if it can't work, the completion-at-point-function can return some data in its `props' making it clear it can't be used for AC). > And the old argument still stands - would the user like to have the same > redundant list of completion functions for C-M-i and popup menu? I don't see why not. Tho, for completions like etags-completion or dabbrev-completion, i.e. forms of completions which don't actually know whether the candidates they return are actually relevant at point, maybe we'd like to make exceptions (like we already do for dabbrev-completions which are bound to a special key rather than to TAB). >>>> Hmm... more consistency in the naming might be good here, indeed. >>>> It's important to keep the "<package>-" prefix since I don't want to >>>> consider all of this as part of Emacs's "core", but maybe we could >>>> settle on "<something>-completion-at-point-function" or maybe something >>>> shorter than that. >>> I am a fan of the -completion postfix convention. It's easy to match in >>> apropos, anything or IDO regexp: comint-filename-completion, >>> tags-completion, imenu-completion, imenu-in-same-mode-completion, >>> words-in-same-buffer-commpletion etc. It can get pretty long by itself, >>> so a short postfix is better. >> But I suspect it will generate false positives because it's not >> specific enough. Maybe "-completion-data"? > Maybe -c-a-p, or -c-a-p-data? I used "-capf" within the code of completion-at-point, but I think it's too cryptic for use outside of that context. Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-19 0:53 ` Stefan Monnier @ 2012-03-19 8:35 ` Vitalie Spinu 2012-03-19 12:49 ` Stefan Monnier 0 siblings, 1 reply; 14+ messages in thread From: Vitalie Spinu @ 2012-03-19 8:35 UTC (permalink / raw To: emacs-devel >>>> Stefan Monnier <monnier@IRO.UMontreal.CA> >>>> on Sun, 18 Mar 2012 20:53:11 -0400 wrote: >> or expansions a la yas. > I guess you're referring to some part of yasnippet, but I don't know > which part, nor why it is related to completion-at-point-functions. Yes, I mean the expansion of abbreviations at point, like yasnippet does. But, it looks like you don't consider it as a completion in the first place. >> So you would still need a separate list for those. > As explained, partial-completion is another problem. As for abbrev-like > "completion+expansion", I don't see why it can't work with AC (and if > it can't work, the completion-at-point-function can return some data > in its `props' making it clear it can't be used for AC). Hmm, ... right, still cannot get used to the concept. >> And the old argument still stands - would the user like to have the same >> redundant list of completion functions for C-M-i and popup menu? > I don't see why not. Tho, for completions like etags-completion or > dabbrev-completion, i.e. forms of completions which don't actually know > whether the candidates they return are actually relevant at point, maybe > we'd like to make exceptions (like we already do for dabbrev-completions > which are bound to a special key rather than to TAB). Good point, given the current mechanism, it's trivial to write a custom completion, with custom list of capfs and bind it to a key. > I used "-capf" within the code of completion-at-point, but I think it's > too cryptic for use outside of that context. Sounds great to me! It's easy to spell, search for and remember, and is more specific than -data. At the end it's just a convention to be used to, and from each function's documentation it will be clear what it means. Thanks, Vitalie. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion. 2012-03-19 8:35 ` Vitalie Spinu @ 2012-03-19 12:49 ` Stefan Monnier 0 siblings, 0 replies; 14+ messages in thread From: Stefan Monnier @ 2012-03-19 12:49 UTC (permalink / raw To: Vitalie Spinu; +Cc: emacs-devel >>> or expansions a la yas. >> I guess you're referring to some part of yasnippet, but I don't know >> which part, nor why it is related to completion-at-point-functions. > Yes, I mean the expansion of abbreviations at point, like yasnippet > does. But, it looks like you don't consider it as a completion in the > first place. I don't know yasnippet's abbreviation's expansion behavior, but assuming it works basically along the same lines as abbrev, then the completion part is only the part that finds an abbrev based on the text already typed (and there may be several such abbrevs, so you get the usual behavior of completions), whereas the expansion is a post-processing step which only happens if the completion found a single candidate (and this is performed with the :exit-function that can be set in completion-data's `props'). See bibtex.el for an example use of this functionality. >> I used "-capf" within the code of completion-at-point, but I think it's >> too cryptic for use outside of that context. > Sounds great to me! It's easy to spell, search for and remember, and is > more specific than -data. At the end it's just a convention to be used > to, and from each function's documentation it will be clear what it > means. Then maybe we should go with "-completion-capf" (more specific than -data, but still makes it clear it's related to completion, even for people not familiar with -capf). Stefan ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-03-19 12:49 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-03-16 11:05 Completion with (:exclusive 'no) is called twice, and doesn't pass over on sole completion Vitalie Spinu 2012-03-16 12:18 ` Vitalie Spinu 2012-03-16 17:20 ` Stefan Monnier 2012-03-16 19:33 ` Vitalie Spinu 2012-03-17 22:34 ` Stefan Monnier 2012-03-17 22:43 ` Lennart Borgman 2012-03-17 23:33 ` Vitalie Spinu 2012-03-18 2:03 ` Stefan Monnier 2012-03-18 9:35 ` Vitalie Spinu 2012-03-18 15:42 ` Stefan Monnier 2012-03-18 19:18 ` Vitalie Spinu 2012-03-19 0:53 ` Stefan Monnier 2012-03-19 8:35 ` Vitalie Spinu 2012-03-19 12:49 ` Stefan Monnier
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.