Re: Press any key to continue
* Ian Zimmerman on Sunday, September 20, 2015 at 21:36:24 -0700 > Mutt asks me this after any pipe-message command. I can see how it is > necessary for commands that produce output; otherwise I wouldn't get a > chance to see the output. But what about commands that produce nothing > on stdout? Some non-interactive commands may save their output in a > file, so their stdout is empty. And then there are commands with an > interactive UI loop of their own, like lynx. For both of these types > the extra prompt to close the output is useless and annoying. Can I get > rid of it? set wait_key=no -- theatre - books - texts - movies Black Trash Productions at home: http://www.blacktrash.org Black Trash Productions on Facebook: http://www.facebook.com/blacktrashproductions
Re: Press any key to continue
On Mon, Sep 21, 2015 at 14:41:08 +1000, Cameron Simpson wrote: > I have: > > set wait_key=no > > In principle you can write macros to turn this on (or off) around specific > actions. Vim has the "silent" command. Maybe Mutt could have a similar one for such command executions. Having to write macros which turn it on and off is messy (and if the setting changes, may change the state if the macro isn't updated as well). --Ben
Re: Press any key to continue
* Ben Boeckel [09-21-15 11:18]: > On Mon, Sep 21, 2015 at 14:41:08 +1000, Cameron Simpson wrote: > > I have: > > > > set wait_key=no > > > > In principle you can write macros to turn this on (or off) around specific > > actions. > > Vim has the "silent" command. Maybe Mutt could have a similar one for > such command executions. Having to write macros which turn it on and off > is messy (and if the setting changes, may change the state if the macro > isn't updated as well). No, you don't chang mutt to accommodate vim as many, maybe most, use another editor. Mutt has a manner available to provide the state you wish, use it. And, as with many programs, you may have to keep track of the conditions you set to provide the environment you wish. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net
Re: scoring top posters
On 2015-09-20 09:06 +0200, Matthias Apitz wrote: > > ... so, no matter how "bad" a message is (let's say, a top post, a > > thread hijack, an ALL CAPS subject, and unlimited line length LOL), the > > worst it can score is 0. Am I right? I haven't used mutt scoring yet, > > so I am trying to learn how to best put it to my purposes. It seems > > to me that for flagging "badness" positive scores would be much more > > convenient. Am I missing something as usual? > > You missed, that you can score as well positive values and the rules are > summed up to a final score value, "rouded" to zero if at the end of the > day negative. See my score part of my ~/.muttrc (some mail addrs > overwritten with ). But you have to start with some arbitrary value as the default score (10 in your case) and you're still limited how low you can go before your negative scores are clipped (to use a photography term which seems oddly apt). What is the reason for this design decision in mutt, I wonder? Is it just the ambiguity when trying to parse score CONDITION -1 where -1 could be the negative score -1, or it could be an abbreviated range with upper bound +1. That could be easily fixed by changing the range separator, for example to "..". -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: Press any key to continue
On Mon, Sep 21, 2015 at 11:38:23 -0400, Patrick Shanahan wrote: > No, you don't chang mutt to accommodate vim as many, maybe most, use > another editor. Mutt has a manner available to provide the state you > wish, use it. And, as with many programs, you may have to keep track of > the conditions you set to provide the environment you wish. This was not saying to accomodate Vim, but to take a command it provides as inspiration for a command which could be useful in Mutt. Is there a way to push or save the current wait_key setting so that it gets set back to the original value when the macro is complete? --Ben
Re: Press any key to continue
* On 21 Sep 2015, Ben Boeckel wrote: > On Mon, Sep 21, 2015 at 11:38:23 -0400, Patrick Shanahan wrote: > > No, you don't chang mutt to accommodate vim as many, maybe most, use > > another editor. Mutt has a manner available to provide the state you > > wish, use it. And, as with many programs, you may have to keep track of > > the conditions you set to provide the environment you wish. > > This was not saying to accomodate Vim, but to take a command it provides > as inspiration for a command which could be useful in Mutt. > > Is there a way to push or save the current wait_key setting so that it > gets set back to the original value when the macro is complete? The pattern is: set my_wait_key=$wait_key unset wait_key set wait_key=$my_wait_key -- David Champion • d...@bikeshed.us
Header cache contention [Was: save in current folder?]
On 2015-09-19 12:21 +1000, Cameron Simpson wrote: > - sets the header_cache to a per-folder path also; mutt doesn't seem > to let me share the header cache between two open instances - this at > least reduces the conflict to that specific folder Is that because mutt needs to lock the file underlying the store (db, gdbm, etc.)? Would there be interest in a patch adding a hcache backend not needing a global lock? (sqlite comes to mind) -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: Press any key to continue
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:unset wait_keykillall -USR1 offlineimap:set wait_key = $my_wait_key:unset my_wait_key" \ "kick offlineimap" I still think some command or function to do this would help a lot. Wrapping all functions like this is…tedious to say the least. It also makes reading these things annoying since the meat of the binding is buried 65 characters into the line. Thanks, --Ben
Re: Press any key to continue
* Ben Boeckel [09-21-15 13:34]: > On Mon, Sep 21, 2015 at 11:38:23 -0400, Patrick Shanahan wrote: > > No, you don't chang mutt to accommodate vim as many, maybe most, use > > another editor. Mutt has a manner available to provide the state you > > wish, use it. And, as with many programs, you may have to keep track of > > the conditions you set to provide the environment you wish. > > This was not saying to accomodate Vim, but to take a command it provides > as inspiration for a command which could be useful in Mutt. > > Is there a way to push or save the current wait_key setting so that it > gets set back to the original value when the macro is complete? Certainly, as advised in the fine manuals: set wait_key=no set wait_key=yes one at the beginning of your macro and one at the close, or just: unset wait_key set wait_key I suggest you peruse tfm's -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net
Re: Press any key to continue
On Mon, Sep 21, 2015 at 02:36:34PM -0400, Ben Boeckel 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:unset > wait_keykillall -USR1 offlineimap:set wait_key = > $my_wait_key:unset my_wait_key" \ > "kick offlineimap" > > I still think some command or function to do this would help a lot. > Wrapping all functions like this is…tedious to say the least. It also > makes reading these things annoying since the meat of the binding is > buried 65 characters into the line. Can a macro be executed by another macro? Back in my troff days we used to write macros like "save_a_group_of_settings" and "restore_saved_settings". After the housekeeping macro calls appeared at the start and end of several other definitions, the mind learns to ignore them when considering the logic of the macro later. -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: Press any key to continue
* On 21 Sep 2015, Jon LaBadie wrote: > > > > I still think some command or function to do this would help a lot. > > Wrapping all functions like this is…tedious to say the least. It also > > makes reading these things annoying since the meat of the binding is > > buried 65 characters into the line. > > Can a macro be executed by another macro? > Back in my troff days we used to write macros like > "save_a_group_of_settings" and "restore_saved_settings". > > After the housekeeping macro calls appeared at the start > and end of several other definitions, the mind learns to > ignore them when considering the logic of the macro later. Yes. I do that pretty often and agree it's appropriate here. -- David Champion • d...@bikeshed.us
Re: Press any key to continue
* Jon LaBadie [09-21-15 17:27]: > On Mon, Sep 21, 2015 at 02:36:34PM -0400, Ben Boeckel 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:unset > > wait_keykillall -USR1 offlineimap:set wait_key > > = $my_wait_key:unset my_wait_key" \ > > "kick offlineimap" > > > > I still think some command or function to do this would help a lot. > > Wrapping all functions like this is…tedious to say the least. It also > > makes reading these things annoying since the meat of the binding is > > buried 65 characters into the line. > > Can a macro be executed by another macro? > Back in my troff days we used to write macros like > "save_a_group_of_settings" and "restore_saved_settings". > > After the housekeeping macro calls appeared at the start > and end of several other definitions, the mind learns to > ignore them when considering the logic of the macro later. I call one macro from another, but I assign the called micro to a key combination and call it via the key combination. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://linuxcounter.net
Re: Press any key to continue
On 21Sep2015 14:36, Ben Boeckel 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:unset wait_keykillall -USR1 offlineimap:set wait_key = $my_wait_key:unset my_wait_key" \ "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. So you might have ",y" mapped to a macro to save various settings (i.e. save everything that any of your macros fiddle with) and ",Y" mapped to pull the values back from $my_foo et al into the settings again. Then put ",y" at the start of your macros and ",Y" at the end. I still think some command or function to do this would help a lot. Wrapping all functions like this is…tedious to say the least. It also makes reading these things annoying since the meat of the binding is buried 65 characters into the line. 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) defining the "end of work point", (b) making the "pop settings" operation run even when something in the middle of your macro fails and (c) what about when you want your macro to change one setting by hack-and-preserve the rest of them. You'd need some kind of "set value in the outer set" or "set value in some global set" or something. Issue (c) would be nasty to define - one can imagine wanting all sorts of variations depending on circumstances. Cheers, Cameron Simpson
Re: Press any key to continue
* On 21 Sep 2015, Cameron Simpson wrote: > > So you might have ",y" mapped to a macro to save various settings (i.e. save > everything that any of your macros fiddle with) and ",Y" mapped to pull the > values back from $my_foo et al into the settings again. > > Then put ",y" at the start of your macros and ",Y" at the end. Similarly, I have macros that cycle through various values of $index_format. There are four of them, named something like "=y0", "=y1", etc. Each macro sets the $index_format, then macros "Y" to the next "=y" in the list. Upshot: each time I press Y my index_format changes, rotating through four options. > 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)". Before the my_ variables were introduced I had a patch for making variable stacks. I like your idea of push/pop all settings. I didn't have that but it sounds useful. Sort of like a gsave/grestore (for postscript nerds). > There are three trickinesses that spring to mind: (a) defining the "end of > work point", (b) making the "pop settings" operation run even when something > in the middle of your macro fails and (c) what about when you want your > macro to change one setting by hack-and-preserve the rest of them. You'd > need some kind of "set value in the outer set" or "set value in some global > set" or something. Issue (c) would be nasty to define - one can imagine > wanting all sorts of variations depending on circumstances. Keep thinking about this stuff. I'd be interested in a comprehensive plan that addresses multiple use cases and doesn't break existing configs. One passing thought that I haven't given much consideration to: fail-hook, defining what happens when something doesn't complete as intended. (But the _much_ harder problem is detecting failure in a consistent and useful way.) -- David Champion • d...@bikeshed.us
Re: Press any key to continue
On Tue, Sep 22, 2015 at 11:03:18AM +1000, Cameron Simpson wrote: > On 21Sep2015 14:36, Ben Boeckel 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:unset > > wait_keykillall -USR1 offlineimap:set wait_key > > = $my_wait_key:unset my_wait_key" \ > > "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. > > So you might have ",y" mapped to a macro to save various settings (i.e. save > everything that any of your macros fiddle with) and ",Y" mapped to pull the > values back from $my_foo et al into the settings again. > > Then put ",y" at the start of your macros and ",Y" at the end. > ... > 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. -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: Press any key to continue
On 21Sep2015 23:48, Jon LaBadie wrote: On Tue, Sep 22, 2015 at 11:03:18AM +1000, Cameron Simpson wrote: On 21Sep2015 14:36, Ben Boeckel 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:unset wait_keykillall -USR1 offlineimap:set wait_key = $my_wait_key:unset my_wait_key" \ > "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
