Request to give more flexibility to vm initialization
blueman
- You want to to advise the function vm or add some hook to it
- So you put the advice or in your vm-init-file
- But vm-init-file itself is called by vm (on the second line)
- So it only works the second time around.
So, I am suggesting that a little recursion be used to get around
this.
Say something like:
(defun vm (&optional folder read-only access-method)
(interactive (list nil current-prefix-arg))
+ (if (boundp 'vm-session-beginning) nil
(vm-session-initialization)
+ (vm folder read-only access-method))
....
You might want to do this also for the handful of other functions that
can be the first entry into vm and thereby call vm-session-initialization.
blueman
Or slightly cleaner:
(defun vm (&optional folder read-only access-method)
(interactive (list nil current-prefix-arg))
+ (when (boundp 'vm-session-beginning)
(vm-session-initialization)
+ (vm folder read-only access-method)))
newsspam5...@robf.de
> I have encountered the following catch-22 several times.
> - You want to to advise the function vm or add some hook to it
Why are you not using vm-visit-folder-hook?
You could also use your own entry function jjk-vm or advise vm in
~/.emacs ... well I see your point, but it looks so odd to do it
like this ...
Robert.
blueman
> blueman <NOS...@nospam.com> writes:
>
>> I have encountered the following catch-22 several times.
>> - You want to to advise the function vm or add some hook to it
>
> Why are you not using vm-visit-folder-hook?
Because I believe that hook is called to late after the buffer is
changed to the new folder. I would like to hit vm *before* it leaves
the current buffer.
>
> You could also use your own entry function jjk-vm or advise vm in
> ~/.emacs ... well I see your point, but it looks so odd to do it
> like this ...
But my point is still generally true that it is hard to add *any*
advice to vm because of the catch-22 that I described. I mean fixing
it only requires the very simple patch I suggested and it allows vm to
act more consistently.
And I don't really think my proposed workaround is any more awkward
then some of the fset stuff that I was just looking at to debug the
qp-encode problem I just posted on another thread. e.g.,
(defun vm-insert-char (char &optional count ignored buffer)
(condition-case nil
(progn
(insert-char char count ignored buffer)
(fset 'vm-insert-char 'insert-char))
(wrong-number-of-arguments
(fset 'vm-insert-char 'vm-xemacs-compatible-insert-char)
(vm-insert-char char count ignored buffer))))
Actually, my patch could be written slightly cleaner as...
(defun vm (&optional folder read-only access-method)
(interactive (list nil current-prefix-arg))
+ (unless (boundp 'vm-session-beginning)
newsspam5...@robf.de
John J Foerch
> (defun vm (&optional folder read-only access-method)
> (interactive (list nil current-prefix-arg))
> + (unless (boundp 'vm-session-beginning)
> (vm-session-initialization)
> + (vm folder read-only access-method))
> ....
Hi blueman,
With all respect, in my opinion, this is rather strange and an abuse
of the advice mechanism. Just use your .emacs. This is an
unnecessary complication.
--John
John J Foerch
I hope my previous comment isn't perceived as rude. I want to follow
up with something more constructive.
The right way to solve this problem is by adding a new hook to the VM
startup process that runs at the point you need, like immediately
after loading the .vm. Advice is a messy way to extend behavior
because it is hard to debug. Even the elisp manual stresses that
advice is a last resort to be used only when you cannot modify the
program in question. That said, altering a function to accomodate the
advice mechanism in a rare corner-case is a hack on top of a hack.
Introducing recursion where none is needed makes the source code more
difficult to understand.
From (info "(elisp)Advising Functions") :
> *Usage note:* Advising a function can cause confusion in debugging,
> since people who debug calls to the original function may not notice
> that it has been modified with advice. Therefore, if you have the
> possibility to change the code of that function (or ask someone to do
> so) to run a hook, please solve the problem that way. Advice should be
> reserved for the cases where you cannot get the function changed.
Thank you, sincerely,
John Foerch
newsspam5...@robf.de
> Hi,
>
> I hope my previous comment isn't perceived as rude. I want to follow
> up with something more constructive.
>
> The right way to solve this problem is by adding a new hook to the VM
> startup process that runs at the point you need, like immediately
> after loading the .vm. Advice is a messy way to extend behavior
> because it is hard to debug. Even the elisp manual stresses that
> advice is a last resort to be used only when you cannot modify the
> program in question. That said, altering a function to accomodate the
> advice mechanism in a rare corner-case is a hack on top of a hack.
> Introducing recursion where none is needed makes the source code more
> difficult to understand.
You are right about this. Advice is a mighty tools which caused
me headaches not just once ...
Blueman, could please once again state fro what purpose you are
using the advice and if a new `vm-startup-hook' called just after
reading the ~/.vm would solve your problem?
Robert.
blueman
I was using the advice for several things including:
1. Checking for previously leftover queued mail
2. Reading in mail from other spool-like folders when I enter vm
That being said I understand the pros and cons of advice and still
find it useful as a wrapper around functions so I think it would still
be useful to have work wherever possible. In fact, I use both hooks
and advice as seems best to me so I prefer the flexibility of having
both available.
The problem I find with hooks is that they often run to late or don't
give you the wrapper-like ability to change/set local variables or
preserve environments.
John J Foerch
> I was using the advice for several things including:
> 1. Checking for previously leftover queued mail
> 2. Reading in mail from other spool-like folders when I enter vm
>
> That being said I understand the pros and cons of advice and still
> find it useful as a wrapper around functions so I think it would still
> be useful to have work wherever possible. In fact, I use both hooks
> and advice as seems best to me so I prefer the flexibility of having
> both available.
>
> The problem I find with hooks is that they often run to late or don't
> give you the wrapper-like ability to change/set local variables or
> preserve environments.
Hi Blueman,
defadvice is useful, true enough, but I really think it is not the
appropriate tool in this situation. The fact that the program has to
be altered to accomodate the advice mechanism is, to me, a red flag
showing that this is not in line with the intent of defadvice. It's
not a question of whether defadvice should be available along with
hooks--it is available and it works perfectly for its intended use.
It is just a logical contradiction for a script to advise the function
that loaded the script. The loader should not be changed to fudge
around an improper use of defadvice.
It is clear to me that `vm-startup-hook' would be a useful feature,
and the provide people the means to customize vm at this point in the
standard way, consistent with the rest of vm and emacs.
Thanks, and I intend no offense by my criticism,
John Foerch
newsspam5...@robf.de
> newsspam5...@robf.de writes:
>> John J Foerch <jjfo...@earthlink.net> writes:
>>
>>> Hi,
>>>
>>> I hope my previous comment isn't perceived as rude. I want to follow
>>> up with something more constructive.
>>>
>>> The right way to solve this problem is by adding a new hook to the VM
>>> startup process that runs at the point you need, like immediately
>>> after loading the .vm. Advice is a messy way to extend behavior
>>> because it is hard to debug. Even the elisp manual stresses that
>>> advice is a last resort to be used only when you cannot modify the
>>> program in question. That said, altering a function to accomodate the
>>> advice mechanism in a rare corner-case is a hack on top of a hack.
>>> Introducing recursion where none is needed makes the source code more
>>> difficult to understand.
>>
>> You are right about this. Advice is a mighty tools which caused
>> me headaches not just once ...
>>
>> Blueman, could please once again state fro what purpose you are
>> using the advice and if a new `vm-startup-hook' called just after
>> reading the ~/.vm would solve your problem?
>>
>> Robert.
>
> I was using the advice for several things including:
> 1. Checking for previously leftover queued mail
At the end of my ~/.vm I have the following for the same reason:
(when (and (> (car (feedmail-look-at-queue-directory
feedmail-queue-directory)) 0))
(feedmail-queue-reminder-medium)
(sit-for 2)
(if (y-or-n-p "Send messages now? ")
(feedmail-run-the-queue)))
> 2. Reading in mail from other spool-like folders when I enter
> vm
Probably you could also do both things in ~/.vm.
I also have the following there
;; at the start
(defvar rf-vm-first-startup t)
;; where needed
(when rf-vm-first-startup
...)
...
;; at the end
(setq rf-vm-first-startup nil)
> That being said I understand the pros and cons of advice and still
> find it useful as a wrapper around functions so I think it would still
> be useful to have work wherever possible. In fact, I use both hooks
> and advice as seems best to me so I prefer the flexibility of having
> both available.
>
> The problem I find with hooks is that they often run to late or don't
> give you the wrapper-like ability to change/set local variables or
> preserve environments.
A vm-startup-hook still is a good idea, so eventually I will
again remove the hack in favor of the hook.
Robert.