On 21Sep2015 23:48, Jon LaBadie <mut...@jgcomp.com> wrote:
On Tue, Sep 22, 2015 at 11:03:18AM +1000, Cameron Simpson wrote:
On 21Sep2015 14:36, Ben Boeckel <maths...@gmail.com> wrote:
>On Mon, Sep 21, 2015 at 12:32:02 -0500, David Champion wrote:
>>set my_wait_key=$wait_key
>>unset wait_key
>>set wait_key=$my_wait_key
>
>Well, that looks nasty, but it works:
> macro generic \Cy \
> ":set my_wait_key = $wait_key<return>:unset wait_key<return><shell-escape>killall -USR1
offlineimap<enter>:set wait_key = $my_wait_key<return>:unset my_wait_key<return>" \
> "kick offlineimap"
I have macros like this. It is nasty, at least when expressed in precisely
this way. [...]
Jon LaBadie and David Champion's suggestion of having a pair of macros to
save the current config state and restore it (by stuffing the value of $foo
into $my_foo for various $foo) is probably the generic way to go there.
[...]
Then put ",y" at the start of your macros and ",Y" at the end.
The only point of this part was to make writing macros that temporarily change
a setting be more succinct in the save/restore sections.
...
I think about this issue frequently. My preferred general approach would be
some kind of stack of settings: "push settings", do work, "pop settings".
And possibly "push particular setting(s)".
There are three trickinesses that spring to mind: (a) ... (b) making the
"pop settings" operation run even when something in the middle of your
macro fails and (c) ...
That is no different than the situation in the above macro. The only code
that changes settings is the code between the save and restore. In the
above macro, the save and restore is explicit in dealing with one setting
instead of generically saving and restoring multiple settings. The problem
of something failing in the middle of the macro is unchanged.
Yes, hence concern (b) above; macros tend to abort partway through when
something goes wrong. Hence the settings can end up not restored.
I'm thinking that if I devised a push/pop settings facility it would have to be
able to work like a python context manager: the "exit" phase always runs even
in the face of failure.
On the other hand, maybe I'm missing your point here?
Cheers,
Cameron Simpson <c...@zip.com.au>
