Z <[email protected]> wrote in
<6168c6f9.5hkc7xygjkohfxnu%[email protected]>:
|Steffen Nurpmeso <[email protected]> wrote:
|> Z <[email protected]> wrote in
|> <61684b71.hlwju2xf9gm3gcoz%[email protected]>:
|>|Steffen Nurpmeso <[email protected]> wrote:
|>|> Z <[email protected]> wrote in
|>|> <61676f30.O/q/a8uppae86zoh%[email protected]>:
|>|>|I was wondering if there was a way to define a new internal variable
|>|>|that could then be updated as needed via folder hooks. Specifially
|>|>|I'd like to isolate the IMAP [/path] value which is present in both
|>|>|the 'mailbox-displayed' and 'mailbox-resolved' internal variables
|>|>|whenever an IMAP mailbox is accessed.
|>|>|
|>|>|My end goal is to use the IMAP [/path] value in the s-mailx prompt
|>|>|along with the 'account' variable so as to always display the active
|>|>|IMAP account name and folder without showing the entire protocol:// \
|>|>|URI.
...
|> commands. For now *folder-hook* has to be used, which .. should
|> satisfy your reported needs? I mean we could introduce
|> a *mailbox-basename* variable. Ok i did that. Be warned you got
|> credited.
|
|Well.. I hope I can handle the infamy. ;) I'm not the admin on several
|of the systems where I use s-mailx so making use of 'mailbox-basename'
|will have to wait but thanks just the same.
|
|Okay, so this is what I have in my ~/.mailrc file which appears to work
|exactly as desired:
|
| # macro & folder-hook for custom prompt:
| define custom-prompt {
| localopts yes;
| vput vexpr prompt regex "$mailbox-resolved" ([^/]+)$ '[\$account/\$1] \
| > ';
|}
| call custom-prompt
| set folder-hook=custom-prompt
|
|Does that look right? It seems to work just fine with or without the
|"localopts yes" which I included because it's in the manpage example.
You can leave off the semicolons here; "localopts yes" is
automatically enabled when called via *folder-hook* mechanism, it
will revert the setting once the folder is left, but when you call
custom-prompt directly _like this_ then localopts will revert the
new *prompt* setting directly, so that call is likely useless.
Note that with the next release (around Christmas maybe)
`localopts' is finally deprecated, and we make use of a "local"
keyword, as is known from the shell, for example, so you would say
"local vput .." or "local call .." or "local set x=y" etc. It
likely should have been like that from the beginning, but, eh,
i have forgotten why it was not :)
The \`{..} extension i mentioned will not be part of the next
release, i need to iterate the machinery once more before i get
there, which will bring "local" support for much more commands, we
get "global" support to overcome "local" etc etc. In fact if
i would design the stuff from scratch i would surely follow suit
Donald Knuth and his TeX and be local by default and only have
"global" to escape locality, but that would have been totally
impossible with the codebase you for example are using :) and
would have required a complete rewrite ... where we will end up
with, unfortunately.
|Regards,
|Z of Denver Colorado, US
I think that is nice with all the national parks. Just too cold!!
--End of <6168c6f9.5hkc7xygjkohfxnu%[email protected]>
Ciao from Germany,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
