Attached please find a patch to sort cycling completion candidates by
the text property :completion-cycle-penalty (lower is better).
Thanks
Ted
=== modified file 'lisp/minibuffer.el'
--- lisp/minibuffer.el 2011-02-12 18:30:13 +
+++ lisp/minibuffer.el 2011-03-08 14:51:07 +
@@ -704,7
I thought that would be easier too, but it's counter-intuitive.
It's only counter intuitive if you think of it (and name it) something
like score. So yes, we need another name to make it less
counter-intuitive. E.g. `completion-penalty'. And I think it would be
good to make it clear that this
On Mon, 28 Feb 2011 18:50:20 -0500 Stefan Monnier monn...@iro.umontreal.ca
wrote:
The only thing I need to clarify is sorting. Right now shorter string
wins. In the new method, higher score should win.
SM I think it's easier if lower scores win, so it's consistent with the
SM current use
On Mon, 28 Feb 2011 00:17:05 -0500 Stefan Monnier monn...@iro.umontreal.ca
wrote:
TZ Maybe accept the score as a property to the candidate strings and use
TZ that property, if it exists, instead of the string length?
TZ That would side-step the current completion mechanism nicely, requiring
TZ
The only thing I need to clarify is sorting. Right now shorter string
wins. In the new method, higher score should win.
I think it's easier if lower scores win, so it's consistent with the
current use of `length'. It's really not a big issue: just negate the
values you put on the property
On Wed Feb 23 2011 Ted Zlatanov wrote:
SM Currently, the cycling code is fairly naive and it uses a fixed ordering
SM based on string length (shorter first). Patches to make it more
SM customizable (by the completion table, not just by the end-user) would
SM be very welcome (e.g. for file
TZ Maybe accept the score as a property to the candidate strings and use
TZ that property, if it exists, instead of the string length?
TZ That would side-step the current completion mechanism nicely, requiring
TZ little extra code except in the final sort of candidates. If the
TZ strings aren't
On Thu, 17 Feb 2011 11:09:28 -0600 Ted Zlatanov t...@lifelogs.com wrote:
TZ On Mon, 14 Feb 2011 02:03:55 -0500 Stefan Monnier
monn...@iro.umontreal.ca wrote:
IMO the cycling should only be based on scores. That would, I think,
accomplish all your items and produce less DWIM but that's not
On Mon, 14 Feb 2011 02:03:55 -0500 Stefan Monnier monn...@iro.umontreal.ca
wrote:
IMO the cycling should only be based on scores. That would, I think,
accomplish all your items and produce less DWIM but that's not it.
SM Currently, the cycling code is fairly naive and it uses a fixed
On Tue Feb 15 2011 Stefan Monnier wrote:
In any case, it appears to me that this function is one of the
features of BBDB some people really like, so that at best one could
use alternative approach and let the users choose what they want.
I think it makes a lot of sense to provide:
-
On Mon Feb 14 2011 Stefan Monnier wrote:
- Individual completions can be pretty long. Not everybody has a
short address f...@gnu.org. So just a few completions can easily
occupy a lot of screen space, which adds to the confusion.
I'm not sure I understand what you're referring to.
My
IMO the cycling should only be based on scores. That would, I think,
accomplish all your items and produce less DWIM but that's not it.
Currently, the cycling code is fairly naive and it uses a fixed ordering
based on string length (shorter first). Patches to make it more
customizable (by the
On Fri Feb 11 2011 Stefan Monnier wrote:
To tell you the truth, the infrastructure might have some missing
elements, but I'm interested in addressing those issues.
Some more thoughts on this:
- One problem with completion in BBDB can be that if the algorithm
isn't optimized enough for its
On Thu Feb 10 2011 Stefan Monnier wrote:
Since BBDB3 only works on Emacs 23, its completion could use
completion-at-point-functions and/or completion-in-region.
I looked into completion-in-region. Here the problem is that the
completion done by bbdb-complete-name is not a comventional
On Fri Feb 11 2011 Stefan Monnier wrote:
Indeed, we have a problem here, and I think that part of the problem is
on the side of bbdb-complete-name's behavior: it should include the name
(with quotes) along with the email address so that it is actually
a completion rather than a lookup.
Of
On Fri Feb 11 2011 Stefan Monnier wrote:
Joe Smith f...@bar.org
Now the idea is that typing foo would give you the above line.
`substring' completion does that since `foo' is a substring of the
above string.
Fine!
Also, this command implements the concept of cycling, which is yet
Currently bbdb-complete-mail (the new name of bbdb-complete-name)
really has no well-defined return values whatsoever. Would it help
if it returned non-nil whenever it had done something?
Yes, that's generally the expected behavior of completion functions.
Would this be the right thing??
In any event, a simple t after (run-hooks 'bbdb-complete-mail-hook)
does the trick, but it probably needs to be changed in some other
places.
Note also that I've already installed a hack in message.el (at least in
Emacs's trunk) that checks that the buffer really was not modified
before
Hi, thanks for looking into it!
06/02/11 17:45, Roland Winkler
On Fri Feb 4 2011 Antoine Levitt wrote:
I've got an issue with the bbdb-complete-name function.
It seems you are using BBDB 2.xx. Recently BBDB has been upgraded
significantly. You might want to try BBDB 3 which is avaiable at
On Sun Feb 6 2011 Antoine Levitt wrote:
When using another completion in message mode, such as
(setq message-tab-body-function (lambda () (interactive) (dabbrev-expand
nil)))
, a successful BBDB completion also triggers the dabbrev-expand
completion.
I am not sure I understand
Hi,
I've got an issue with the bbdb-complete-name function. When using
another completion in message mode, such as
(setq message-tab-body-function (lambda () (interactive) (dabbrev-expand
nil)))
, a successful BBDB completion also triggers the dabbrev-expand
completion.
Suppose I've got Bob
21 matches
Mail list logo
