Hello Stephen. "Stephen Isard" <[email protected]> wrote: |Ok, I still get | |IMAP error: Mailbox doesn't exist: Mail/INBOX | |when my account definition just includes | |set folder=imaps://username@servername/Mail/ | |but when I put in an extra line | |set inbox=imaps://username@servername/INBOX | |s-nail starts up in my inbox and can also access the folders in my Mail |subdirectory. Good. | |I think that having a separate inbox variable is actually a clear and |rational way of specifying that on this server the inbox and the folders |are in different places, rather than having s-nail magically replace |Mail/ in the folder definition with INBOX behind the scenes to tell the |server where the inbox is, which is what mailx does. However, anyone |accustomed to using mailx with this style of imap server and expecting |compatibility needs to be warned.
You should see an obsoletion warning if you enable -d/*debug* or -v/*verbose*: the special treatment of *folder* for IMAP will vanish completely, only *inbox* will remain in v15. I don't think i can do more than keeping compatibility for the likely three years that will pass until then, looking into the manual once gives a prominent warning message on the first screen. And yes, i think this idea of yours is the best way to go. For v14.9 i had extended $MAIL for this purpose, but that way was completely wrong, because $MAIL is standardized to be an absolute pathname, and the new variable handling in v14.9 will automatically re-export an updated $MAIL to the environment, and most child processes started by mail won't be able to understand, e.g., MAIL=+sys.mbox. So *inbox* it will be. |The new inbox= line doesn't appear to do any harm in mailx, so |it looks safe to have it in a .mailrc to be used by both programs. Wuff wuff wuff. If no smart young student interferes and writes a beautiful mailx from scratch (or so), then i would say that we are mailx. And we need to proceed, and we _will_ turn to use shell-style argument quoting, which will break such compatibility in the, yet distant, future. You could use the $NAIL_EXTRA_RC (then $MAILX_EXTRA_RC) feature that Gunnar Ritter invented to load completely incompatible stuff, though. But for most use cases it is likely that it does no harm in real life. You won't even need "set colour-disable" in v14.9 to get rid of those terrible traffic light display no more. ^.^ Ciao! --steffen ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot __________________________________ [email protected]
