>> The first solution binds the variables lexically rather than
>> dynamically. That means that if those appear lexically inside
>> the things will work correctly, but if calls a function
>> which then refers to this reference will fail.
> Thank you for the clarification. The code in
> This variable contains forms that are evaluated using `eval',
> assuming that the variables appearing in this form are bound
> dynamically. - I believe that old coding schemes like this one,
There are two ways to do that with lexical-binding:
- use (eval `(( . ,) ( . ,) ...)
which will not
Direct editing maybe similar to wdired-mode could be, indeed, a
great thing. -- Yet as I said: I'll postpone such dreams till BBDB 3
has been released.
No! I want it now!
[...starts rolling on the floor screaming...]
Now! now! now! now! now!!
Stefan Damn adults!
A much fancier solution would be to reimplement bbdb-create from
scratch by using something like a form to fill, similar to what
customize is using.
I should add: Such a rather substantial change would have rather low
priority on my current BBDB agenda. Currently, I consider a proper
BBDB
(local-set-key : '(lambda () (interactive)
[...]
bbdb/gnus-update-records-p'(lambda ()
Hmm... running for The Useless Use of Quote Award?
Stefan
--
BlackBerryreg; DevCon Americas, Oct. 18-20, San
If I could add a rider request to this, it would be great to have a
single key command to copy the field contents to the kill ring (the way
'M' does now for the primary mail address). I often need to copy
people's details to other places, and every time I do I wish I had this…
I'd personally
I suggest change all these defcustom instances something like:
(defcustom bbdb-create-hook nil
:group 'bbdb
:type 'hook)
(add-hook 'bbdb-create-hook 'bbdb-creation-date)
Agreed and thanks, that looks much cleaner!
But then don't define them as defcustom but just defvars since Custom
gets
+ (when (boundp 'revert-buffer-function)
+(setq revert-buffer-function 'bbdb-revert-buffer))
I recommend to use (set (make-local-variable foo) bar) when setting
a buffer-local variable, even if you know that the variable is
automatically buffer-local. One of the benefits is that you
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
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
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
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
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
Well, my recent discovery was that the variable name change
bbdb-popup-target-lines - bbdb-popup-window-size in BBDB 3.x. They seem
to do the same thing (i.e. setting the target number of lines for the
bbdb-popup window). The default value was 5 but is now 0.5.
You are right. I guess the
I'd be OK with providing BBDB3 in a beta form through
elpa.gnu.org. As long as the version string states it clearly,
which it will. You are likely to get plenty of feedback.
Feedback is always appreciated!
Talking about feedback: is there some warning/discussion about the
change of format
Whenever I expand a bbdb name at To:, trailing whitespace gets added
when using the latest emacs.
It's probably the result of a change I made in message.el's completion
code. I've seen a few other reports about it, but I can't reproduce it.
Could you give me more details: which version of BBDB
When I invoke M-x bbdb from my minibuffer-only frame, BBDB burps with
the above error. The Elisp backtrace is:
split-window(#window 8 on *Minibuf-0* 0)
bbdb-pop-up-buffer(t nil)
bbdb-display-records-internal((...) multi-line nil t nil)
bbdb-display-records((...) multi-line nil t)
The patch below (against the head of the sf.net CVS trunk) fixes
a namespace-pollution bug (`digit' should have been `bbdb-digit'
at least, although the patch fixes it in a different way) and a bug
in the migration query which appears if your `display-buffer' chooses
to display the query in a
19 matches
Mail list logo
