Re: How to disable mailbox shortcuts in mailbox browser
On Fri, Jun 03, 2022 at 05:48:55AM +, Sam Lee via Mutt-users wrote: Is there some kind of setting similar to "set sidebar_use_mailbox_shortcuts=no", but for the mailbox browser? 'unset browser_abbreviate_mailboxes' might work for you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: How to disable mailbox shortcuts in mailbox browser
On 2022-06-03 05:48 +, Sam Lee via Mutt-users wrote: > In the sidebar, my mailbox is displayed in a format like > "imaps://john-...@example.com/INBOX". However, in the mailbox browser > (accessed using keybinding 'y' or :exec browse-mailboxes), it is > displayed as "=INBOX". In the mailbox browser, how do I make Mutt > display it as "imaps://john-...@example.com/INBOX" instead? > > Is there some kind of setting similar to > "set sidebar_use_mailbox_shortcuts=no", but for the mailbox browser? OP here. By the way, I am aware of that I can explicitly give labels to each mailbox by using mailboxes' "-label" argument. However, I am using "set imap_check_subscribed" instead of explicitly listing each mailbox in the configuration file, so the "-label" method is not practical (especially with multiple email accounts, each with many folders, some of which I may change/rename through the email provider's web interface).
How to disable mailbox shortcuts in mailbox browser
In the sidebar, my mailbox is displayed in a format like "imaps://john-...@example.com/INBOX". However, in the mailbox browser (accessed using keybinding 'y' or :exec browse-mailboxes), it is displayed as "=INBOX". In the mailbox browser, how do I make Mutt display it as "imaps://john-...@example.com/INBOX" instead? Is there some kind of setting similar to "set sidebar_use_mailbox_shortcuts=no", but for the mailbox browser?
Re: Getting more useful information in file browser - possible with maildir?
Quoting Chris Green from 02 Oct (a Friday in 2020) at 1657 hours... > > ... by the way I just timed a 'du' on my main directory full of > (maildir) directories:- > > chris$ time du -sm * > real0m0.109s > user0m0.032s > sys 0m0.076s > > > (and, no, I didn't cheat, that was a 'cold start' du, I hadn't just > run one before) > > Even *copying* the whole of my 1.5Gb mail hierarchy takes only 8 > seconds. To provide a second datapoint here (list of my mail storage hoarding not included) 36661 total du -smc .??* 1.42s user 27.85s system 28% cpu 1:42.13 total ...that's running on a VM which nfs mounts $HOME from the host machine, and is RAID6 backed on spinning rust. That said, this is academic to me as I never use the in-mutt browser anyway. mutt's startup time is effectively zero, so I have a quick and dirty wrapper shell script which tells me the mail folders with new messages (via a fast `find` command (provided below) provides that info, along with how many are new), and it then starts mutt with the folder of choice. When finished I quit mutt and am returned to a refreshed folder list automatically :) """ find ~/Maildir -name tmp -prune -o -name cur -prune \ -o -path *archive -prune \ -o -path \*/new/\* \ -not -name \*:\*T\* -not -name \.\* \ -type f -printf '%h\n' | sed -e 's,.*/Maildir/\(.*\)/new,\1,g' \ | uniq -c | sort -gr """ (this should work on both .dot.seperated.sub.folders and slash/seperated/sub/folders, and runs fast enough that a version that simply `| wc -l` is part of my tmux status line) .../Nemo -- - - earth native
Re: Getting more useful information in file browser - possible with maildir?
On 03Oct2020 08:51, Chris Green wrote: >On Sat, Oct 03, 2020 at 02:47:46PM +1000, Cameron Simpson wrote: >> >Even *copying* the whole of my 1.5Gb mail hierarchy takes only 8 >> >seconds. >> >> Looks like your filesystem is superior to mine. Mine's MacOS apfs, I >> presume yours is a good Linux fs of some kind. I'd be surprised if the >> SSD hardware were very relevant (other than being an SSD, that is). >> >Linux default ext4 filesystem. It's an nvme SSD, I had a SATA SSD >before and the improvement is *huge*! :-) This is on fairly old >hardware, I had to put an adapter card in the PCIExpress slot and >play quite a few games with Grub and /boot. That is useful to know. My Mac's a modern 2020 model so should also have an nvme SSD; I'm glad to hear the nvme is subjectively obviously faster than a SATA one, I'd wondered what the difference was like. I've been replacing the spinning rust drives in some of our old Macs with SATA SSDs, which itself brings a huge performance difference. Cheers, Cameron Simpson
Re: Getting more useful information in file browser - possible with maildir?
On Sat, Oct 03, 2020 at 02:47:46PM +1000, Cameron Simpson wrote: > On 02Oct2020 16:57, Chris Green wrote: > >... by the way I just timed a 'du' on my main directory full of > >(maildir) directories:- > > > >chris$ time du -sm * > [...] > >real0m0.109s > >user0m0.032s > >sys 0m0.076s > > > >(and, no, I didn't cheat, that was a 'cold start' du, I hadn't just > >run one before) > > > >Even *copying* the whole of my 1.5Gb mail hierarchy takes only 8 > >seconds. > > Looks like your filesystem is superior to mine. Mine's MacOS apfs, I > presume yours is a good Linux fs of some kind. I'd be surprised if the > SSD hardware were very relevant (other than being an SSD, that is). > Linux default ext4 filesystem. It's an nvme SSD, I had a SATA SSD before and the improvement is *huge*! :-) This is on fairly old hardware, I had to put an adapter card in the PCIExpress slot and play quite a few games with Grub and /boot. -- Chris Green
Re: Getting more useful information in file browser - possible with maildir?
On 02Oct2020 16:57, Chris Green wrote: >... by the way I just timed a 'du' on my main directory full of >(maildir) directories:- > >chris$ time du -sm * [...] >real0m0.109s >user0m0.032s >sys 0m0.076s > >(and, no, I didn't cheat, that was a 'cold start' du, I hadn't just >run one before) > >Even *copying* the whole of my 1.5Gb mail hierarchy takes only 8 >seconds. Looks like your filesystem is superior to mine. Mine's MacOS apfs, I presume yours is a good Linux fs of some kind. I'd be surprised if the SSD hardware were very relevant (other than being an SSD, that is). Cheers, Cameron Simpson
Re: Getting more useful information in file browser - possible with maildir?
On Fri, Oct 02, 2020 at 10:36:44AM -0500, Derek Martin wrote: > > I haven't made this point yet since I regard it as almost irrelevant > given the above, but I would also argue it's not particularly useful > information, except in the context of disk space management--which has > nothing to do with Mutt. > I actually think it's probably the most relevant point! :-) It's why, when I started this thread, I said that it's not a deal breaker. I'm staying with maildir. ... by the way I just timed a 'du' on my main directory full of (maildir) directories:- chris$ time du -sm * 90 apexLodge 30 archive 190 boating 1 cl 1 entertainment 29 family 1 france 5 friends 6 greville 2 gwymca 15 hardware 87 holidays 35 houseHome 27 internet 52 isbd 3 jrml 9 maxMum 10 money 7 pcc 2 personal 11 reshapers 3 riding 1 segurossainfo 2 selling 236 shopping 6 software 12 telecoms 1 tractor 21 travel 2 ukraa 28 vehicles real0m0.109s user0m0.032s sys 0m0.076s (and, no, I didn't cheat, that was a 'cold start' du, I hadn't just run one before) Even *copying* the whole of my 1.5Gb mail hierarchy takes only 8 seconds. -- Chris Green
Re: Getting more useful information in file browser - possible with maildir?
On Thu, Oct 01, 2020 at 10:01:21AM +0100, Chris Green wrote: > On Wed, Sep 30, 2020 at 02:56:56PM -0500, Derek Martin wrote: > > On Wed, Sep 30, 2020 at 02:21:22PM +0100, Chris Green wrote: > > > On Tue, Sep 29, 2020 at 09:49:52AM -0500, Derek Martin wrote: > > I can't say why Christian gets dates and proper sorting on > > his mail folder directories and you're not; that would take some > > investigation. I could guess that it might be that maildir-aware MDAs > > update the utimes on the folder directory when it delivers a file... > > and even if it's not that, you could do that in your MDA with > > os.utime(), which should force the issue. > > > Now that's a point, thank you, I see a small revision of my Python > filter coming up! :-) Great, hope that helps you out. Meanwhile... > > They may be maildirs, but in the file browser they are directories, > > for the purpose of navigating the file system. In that context, the > > fact that they are maildirs is not relevant: In the context of > > browsing files, you want info about the files, which is what Mutt > > gives you. This is somewhat configurable (see the manual about > > folder_format), but it's not going to give you any info about the mail > > that's in those directories... Wrong context. > > > But in the mutt/mail context they're mailboxes, Mutt doesn't have just one context, it has a number of them. That's why you have a file brower, a message index, a compose menu, etc... The jobs of those features are not the same, and the functionality provided by them is dependent on their function and the context in which they are meant to operate. The file selection dialog box in Thunderbird isn't going to give you mail-related information about maildirs it sees; but that is the same function and context of Mutt's file browser. > Surely mutt can take a look into directories and, if they're maildir > mailboxes, act accordingly and present the user with useful > information. Putting programmer hat on again, maybe make this an > option as it might take too long on slow systems. But as Cameron and I have both tried to point out to you repeatedly, even on a fast system, it's too expensive. Cameron showed the performance for just one large maildir, taking > 4s, on a fast system with SSD. If you have a lot of these, it's going to take on the order of MINUTES for mutt to calculate all the folder sizes, before it can show you the file listing... on the fastest systems available at consumer-level prices. On slower systems, you're looking at going to make a sandwich, and eating it, before the directory can be displayed. It DOES NOT MAKE SENSE to put this functionality in. The context of the file browser has nothing to do with mailbox management, and the properties of this style of mail store make it prohibitive, so doing it just for the sake of convenience is nonsensical--which is exactly why Mutt has never had it. I'm repeating myself now, but again, the only reason you get it with mbox is because in that case your folders just happen to be ordinary files--it's very fast to get file sizes directly from the file system, and displaying that info is relevant to the actual purpose of the file browser. It is not its purpose to display mail-related info in any capacity, and the overlap exists purely due to coincidental properties of that specific implementation (that is, all of the one-file-per-mail-folder variants) of the mailbox abstraction. With just about any other implementation, providing that information is prohibitively expensive. I haven't made this point yet since I regard it as almost irrelevant given the above, but I would also argue it's not particularly useful information, except in the context of disk space management--which has nothing to do with Mutt. Context is everything. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On Wed, Sep 30, 2020 at 02:56:56PM -0500, Derek Martin wrote: > On Wed, Sep 30, 2020 at 02:21:22PM +0100, Chris Green wrote: > > On Tue, Sep 29, 2020 at 09:49:52AM -0500, Derek Martin wrote: > > > On Tue, Sep 29, 2020 at 08:30:42AM +0100, Chris Green wrote: > > > > The same place in a mbox hierarchy shows me the size of the maibox and > > > > the date of the last change. > > > > > > You're looking at this all wrong. It's purely a side effect of how > > > the mailbox abstraction is represented: you get that only because they > > > just happen to be files--exactly what the file browser was meant to > > > handle. > > > > > "I'm" a user! :-) I want the information I used to get. That it's > > "purely a side effect" of some technical change is unipoortant to the > > user. Yes, with my techie hat on I understand why it is, but I can > > also see that there are ways to get the information I want, albeit > > with some more code. > > It's not just more code, it's expensive code, at least in some cases. > Without reviewing the messages to get the exact details, I think some > of what you want is doable, and some is really not. > > Some of it really isn't Mutt's purview, per se--it's your MDA's > purview. I can't say why Christian gets dates and proper sorting on > his mail folder directories and you're not; that would take some > investigation. I could guess that it might be that maildir-aware MDAs > update the utimes on the folder directory when it delivers a file... > and even if it's not that, you could do that in your MDA with > os.utime(), which should force the issue. > Now that's a point, thank you, I see a small revision of my Python filter coming up! :-) > Recursively calculating the space used by the mail folder, on the > other hand... just no. =8^) > If on Unix/Linux there's the ready made du utility but I think using that sounds more like a personal, one-off customisation rather than something to build into mutt. -- Chris Green
Re: Getting more useful information in file browser - possible with maildir?
On Wed, Sep 30, 2020 at 02:21:22PM +0100, Chris Green wrote: > On Tue, Sep 29, 2020 at 09:49:52AM -0500, Derek Martin wrote: > > On Tue, Sep 29, 2020 at 08:30:42AM +0100, Chris Green wrote: > > > The same place in a mbox hierarchy shows me the size of the maibox and > > > the date of the last change. > > > > You're looking at this all wrong. It's purely a side effect of how > > the mailbox abstraction is represented: you get that only because they > > just happen to be files--exactly what the file browser was meant to > > handle. > > > "I'm" a user! :-) I want the information I used to get. That it's > "purely a side effect" of some technical change is unipoortant to the > user. Yes, with my techie hat on I understand why it is, but I can > also see that there are ways to get the information I want, albeit > with some more code. It's not just more code, it's expensive code, at least in some cases. Without reviewing the messages to get the exact details, I think some of what you want is doable, and some is really not. Some of it really isn't Mutt's purview, per se--it's your MDA's purview. I can't say why Christian gets dates and proper sorting on his mail folder directories and you're not; that would take some investigation. I could guess that it might be that maildir-aware MDAs update the utimes on the folder directory when it delivers a file... and even if it's not that, you could do that in your MDA with os.utime(), which should force the issue. Recursively calculating the space used by the mail folder, on the other hand... just no. =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On Tue, Sep 29, 2020 at 09:49:52AM -0500, Derek Martin wrote: > On Tue, Sep 29, 2020 at 08:30:42AM +0100, Chris Green wrote: > > I have 'set folder_format="%N %-32.32f %m %n"'. I did have a date as > > well but all that shows is 'Sep 25' the date of creation of the > > maildir which is no use at all, it's just the date that the maildir was > > created nothing to do with the dates of mail inside tne maildir. > > Yup. > > > The same place in a mbox hierarchy shows me the size of the maibox and > > the date of the last change. > > You're looking at this all wrong. It's purely a side effect of how > the mailbox abstraction is represented: you get that only because they > just happen to be files--exactly what the file browser was meant to > handle. > "I'm" a user! :-) I want the information I used to get. That it's "purely a side effect" of some technical change is unipoortant to the user. Yes, with my techie hat on I understand why it is, but I can also see that there are ways to get the information I want, albeit with some more code. -- Chris Green
Re: Getting more useful information in file browser - possible with maildir?
* Derek Martin on Tuesday, September 29, 2020 at 09:49:52 -0500: On Tue, Sep 29, 2020 at 08:30:42AM +0100, Chris Green wrote: I have 'set folder_format="%N %-32.32f %m %n"'. I did have a date as well but all that shows is 'Sep 25' the date of creation of the maildir which is no use at all, it's just the date that the maildir was created nothing to do with the dates of mail inside tne maildir. Yup. Hm, the %d in my folder_format definitely updates when the (Maildir) mailbox has changed. As man muttrc says: %d date/time folder was last modified and the mailboxes are sorted as per sort_browser jsut fine; maybe I misunderstand. Finally, I find %N to indicate new mail very useful. -- LAST SHIP HOME --->> https://lastshiphome.de Official Selection DOK.fest München 2018 German Ocean Film AwardCineMare Kiel 2019 Best Documentary Feature Wales International Film Festival 2020
Re: Getting more useful information in file browser - possible with maildir?
On Tue, Sep 29, 2020 at 08:30:42AM +0100, Chris Green wrote: > On Mon, Sep 28, 2020 at 07:01:25PM -0500, Derek Martin wrote: > > On Sat, Sep 26, 2020 at 08:29:22PM +0100, Chris Green wrote: > > > > > This is by no means a show stopper, I'm going to stay with maildir, > > > > > but it woud be nice to be able to improve it a bit. > > > > > > > > I'd recommend using a "maildir browser" which knows how to interpret the > > > > information you're looking for (and which mutt is very good at). > > > > > > > ?? I'm a bit lost here, you recommend a "maildir browser" and say "... > > > which mutt is very good at", so is mutt a maildir browser? > > > > Translation: The file browser is for files (and directories, which are > > also files, albeit special ones) and tells you information that is > > generally useful for file-things. For mail, use the message index > > and/or the sidebar. Most directories *are not* mail folders, and > > therefore attempting to display information useful for mail folders on > > directories in the file browser is the Wrong Thing™. > > Yes, but maildir 'mailboxes' *are* directories [...] No, actually, they aren't. They're an abstraction that is composed of a multi-level directory structure, which as you have seen can be structured a couple different ways. The file browser is not intended to deal with that... it's for dealing with files, and allowing you to navigate around the file system. Sometimes that is so that you can select folders that happen to contain mail, like when you're using the change folder command, and other times it has absolutely nothing to do with that, like when you're saving file attachments. > and when I navigate to one in mutt the date is the date the > directory was created (nothing to do with the date(s) of the latest > mail in there) and no sizes or anything are displayed. Correct. Updating the message files will update its parent directory, but the maildir's top-level directory is not that directory. It's cur, or new, or tmp... Adding a sub-folder would, however, update the maildir's top-level directory. > For example I have a directory /home/chris/mail/folder/apexLodge/agm > which is a maildir:- > > chris@esprimo$ ls -l /home/chris/mail/folder/apexLodge/agm > total 12 > drwx-- 2 chris chris 4096 Sep 25 12:38 cur > drwx-- 2 chris chris 4096 Sep 25 12:38 new > drwx-- 2 chris chris 4096 Sep 25 12:38 tmp > chris@esprimo$ [...] > I have 'set folder_format="%N %-32.32f %m %n"'. I did have a date as > well but all that shows is 'Sep 25' the date of creation of the > maildir which is no use at all, it's just the date that the maildir was > created nothing to do with the dates of mail inside tne maildir. Yup. > The same place in a mbox hierarchy shows me the size of the maibox and > the date of the last change. You're looking at this all wrong. It's purely a side effect of how the mailbox abstraction is represented: you get that only because they just happen to be files--exactly what the file browser was meant to handle. You can't expect that different implementations of the abstraction will always have the exact same properties. If the mail was instead in a database, it would completely defy external inspection via file browser, though of course the file browser would still let you navigate to the on-disk files that comprised the database (assuming they're not on some sort of database-specific partition, like Oracle or other databases may use). You could get a hint about its size, but depending on the implementation, you may have no way to know what portion of those files comprised the database's indexes, views, internal structures, or other implementation-specific details. Different implementations have different properties, which provide different advantages and disadvantages. Maildir is not mbox. If you want mbox behavior, use mbox. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On Mon, Sep 28, 2020 at 06:55:51PM -0500, Derek Martin wrote: > On Sat, Sep 26, 2020 at 05:02:08PM +0100, Chris Green wrote: > > However there is a minor downside in the file browser (well directory > > browser really isn't it), the information shown against the > > directories (at the bottom level these are maildir mailboxes) is > > pretty useless, what I am seeing now is like the following:- > > > > selling/ Sep 25 12:39 0K > > shopping/Sep 25 12:39 0K > > software/Sep 25 12:39 0K > > telecoms/Sep 25 12:39 0K > > > > No size information and the date is just the date of creation of the > > parent directory, not the latest message. With mbox you get a 'last > > message' date and a meaningful size. > > They may be maildirs, but in the file browser they are directories, > for the purpose of navigating the file system. In that context, the > fact that they are maildirs is not relevant: In the context of > browsing files, you want info about the files, which is what Mutt > gives you. This is somewhat configurable (see the manual about > folder_format), but it's not going to give you any info about the mail > that's in those directories... Wrong context. > But in the mutt/mail context they're mailboxes, I (the user) don't care what the underlying technology is. Surely mutt can take a look into directories and, if they're maildir mailboxes, act accordingly and present the user with useful information. Putting programmer hat on again, maybe make this an option as it might take too long on slow systems. -- Chris Green
Re: Getting more useful information in file browser - possible with maildir?
On Mon, Sep 28, 2020 at 07:01:25PM -0500, Derek Martin wrote: > On Sat, Sep 26, 2020 at 08:29:22PM +0100, Chris Green wrote: > > > > This is by no means a show stopper, I'm going to stay with maildir, > > > > but it woud be nice to be able to improve it a bit. > > > > > > I'd recommend using a "maildir browser" which knows how to interpret the > > > information you're looking for (and which mutt is very good at). > > > > > ?? I'm a bit lost here, you recommend a "maildir browser" and say "... > > which mutt is very good at", so is mutt a maildir browser? > > Translation: The file browser is for files (and directories, which are > also files, albeit special ones) and tells you information that is > generally useful for file-things. For mail, use the message index > and/or the sidebar. Most directories *are not* mail folders, and > therefore attempting to display information useful for mail folders on > directories in the file browser is the Wrong Thing™. Yes, but maildir 'mailboxes' *are* directories and when I navigate to one in mutt the date is the date the directory was created (nothing to do with the date(s) of the latest mail in there) and no sizes or anything are displayed. For example I have a directory /home/chris/mail/folder/apexLodge/agm which is a maildir:- chris@esprimo$ ls -l /home/chris/mail/folder/apexLodge/agm total 12 drwx-- 2 chris chris 4096 Sep 25 12:38 cur drwx-- 2 chris chris 4096 Sep 25 12:38 new drwx-- 2 chris chris 4096 Sep 25 12:38 tmp chris@esprimo$ All the file browser shows me at the level above is:- ../ -> agm/ ardavan/ barnet/ boilerbreakdowns/ brunoSuarez/ buildingsInsurance/ charles.rustin/ clearance2019/ crawford/ .. .. I have 'set folder_format="%N %-32.32f %m %n"'. I did have a date as well but all that shows is 'Sep 25' the date of creation of the maildir which is no use at all, it's just the date that the maildir was created nothing to do with the dates of mail inside tne maildir. The same place in a mbox hierarchy shows me the size of the maibox and the date of the last change. -- Chris Green
Re: Getting more useful information in file browser - possible with maildir?
On Mon, Sep 28, 2020 at 10:10:28PM -0400, Josef 'Jeff' Sipek wrote: > On Mon, Sep 28, 2020 at 18:55:51 -0500, Derek Martin wrote: > ... > > On Unix systems, at least > > for most file systems, the size of a directory is the space occupied > > by the blocks needed to hold the internal representation of the > > listing of the directory... > > Yes, the size on directories is essentially meaningless on POSIX systems (to > the user anyway). It's not *completely* useless... it does have one very useful function--the one it was intended for: It tells you exactly how much of your disk space was consumed by that directory's metadata. That might be useful to the user if, for example, they have a disk quota. Such things are rare these days but probably still exist in places like universities, or other such places where computing resources are shared amongst a community of users who don't necessarily have a vested interest in conserving the limited resources... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On Mon, Sep 28, 2020 at 18:55:51 -0500, Derek Martin wrote: ... > On Unix systems, at least > for most file systems, the size of a directory is the space occupied > by the blocks needed to hold the internal representation of the > listing of the directory... Yes, the size on directories is essentially meaningless on POSIX systems (to the user anyway). Many file systems do what you say. Others (e.g., ZFS) make the returned directory size equal to the number of directory entries. Note that this doesn't help with maildir either, since the mailbox directory has exactly 5 entries: . .. cur new tmp Just my 2 cents worth of trivia. Jeff. signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On Mon, Sep 28, 2020 at 06:09:49PM -0700, Kevin J. McCarthy wrote: > Yes, Olaf Hering submitted a patch in 1.10, zeroing out the directory size > for the reason you site below: > > > However the size of a directory is very likely not what you think it is, > > and is not particularly useful to you. On Unix systems, at least for > > most file systems, the size of a directory is the space occupied by the > > blocks needed to hold the internal representation of the listing of the > > directory... NOT the size of the contents of the directory. > > I don't feel strongly one way or another, but the listing does look a bit > cleaner with the (useless) sizes zeroed out. Feel free to bring it up on > mutt-dev if you feel it should be changed back. I see... Well, I would say I don't really get the point or the motivation for displaying 0K instead of the actual value... If users thought to put it in their folder format, presumably they actually cared about that info, and now they can't have it... I don't see that this change saves anything either--you still have to stat() the directory to get the other info (like access times) so you already will have the info anyway. You could remove %s from folder_format, but I s'pose people still want it for the sizes of files. Or, perhaps a new format specifier like %S (I'm not bothering to check if that's available for folder_format) which displays the size for files, but displays nothing for directories... But honestly, if you're already displaying sizes for files, it seems to me that not displaying directory sizes will just look weird. No one noticed for over 2 years (that I recall hearing about anyway), so I'm not sure that it matters in practice, but from a purely philosophical standpoint, do I feel strongly about actively choosing to display information that's factually wrong, especially when the only upside (as far as I can see) is a completely subjective cosmetic improvement. If I'd noticed, I certainly would have argued against it. But, I didn't... =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On 26Sep2020 20:29, Chris Green wrote: >On Sat, Sep 26, 2020 at 01:13:11PM -0400, Ben Boeckel wrote: >> That's most likely a "last edited" date. Adding flags or labels to a >> message would have reset that time as well. These directories were last >> edited on the date you created them, so not much is going to change >> that. But if it reported this for the new and cur subdirs if could be useful. Very dependent on the file browser of course. Setting flags on maildir items renames then, so the directory's mod time will get a bump. Editing labels (within mutt) is editing a message, and in mutt that is done by making a new modified file and marking the old one deleted, so that too would bump the directory mod time. [...] >They're on a fast SSD on the same system as mutt is running on so >'very expensive' is probably not an issue. Hmm. On a fast SSD here: [~/mail/python]fleet2*> time du -sh 1.4G. du -sh 0.04s user 1.44s system 34% cpu 4.275 total so over 4s. Admittedly I went out of my way to pick a big maildir. [...] >> I'd recommend using a "maildir browser" which knows how to interpret >> the >> information you're looking for (and which mutt is very good at). >> >?? I'm a bit lost here, you recommend a "maildir browser" and say "... >which mutt is very good at", so is mutt a maildir browser? Just anything which knows it is browsing maildirs. Since they have a little directory hierarchy underneath them a plain file browser won't tell you much from outside unless you can extend the file browser. Ben's suggestion of mutt is because mutt knows about maildirs, so its browse-folders facility has some of the functionality you seek. Personally I rarely look at my mail folders from a file browser. My mail filer does the delivery, and my ruleset causes alerts to pop up if something important arrives. Cheers, Cameron Simpson
Re: Getting more useful information in file browser - possible with maildir?
On Mon, Sep 28, 2020 at 06:55:51PM -0500, Derek Martin wrote: There IS size info, although it's wrong... That appears to be a bug introduced some time after 1.9.4, which I have lying around, that has it right. I also have 1.12.2 where it is wrong, so... somewhere in between. Yes, Olaf Hering submitted a patch in 1.10, zeroing out the directory size for the reason you site below: However the size of a directory is very likely not what you think it is, and is not particularly useful to you. On Unix systems, at least for most file systems, the size of a directory is the space occupied by the blocks needed to hold the internal representation of the listing of the directory... NOT the size of the contents of the directory. I don't feel strongly one way or another, but the listing does look a bit cleaner with the (useless) sizes zeroed out. Feel free to bring it up on mutt-dev if you feel it should be changed back. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On Sat, Sep 26, 2020 at 08:29:22PM +0100, Chris Green wrote: > > That's most likely a "last edited" date. Adding flags or labels to a > > message would have reset that time as well. These directories were last > > edited on the date you created them, so not much is going to change > > that. You'd want access time, but that isn't reliable anyways (see > > relatime and noatime mount options) because it makes reads potentially > > very expensive writes to update atimes all the way up the tree. Whether you'd want mtime or atime (last modified time, last access time) is perhaps debatable... One tells you when you (or more accurately, *something*) looked at the file (e.g. read your mail), the other tells you when it was last updated (e.g. mail was delivered there). > > > This is by no means a show stopper, I'm going to stay with maildir, > > > but it woud be nice to be able to improve it a bit. > > > > I'd recommend using a "maildir browser" which knows how to interpret the > > information you're looking for (and which mutt is very good at). > > > ?? I'm a bit lost here, you recommend a "maildir browser" and say "... > which mutt is very good at", so is mutt a maildir browser? Translation: The file browser is for files (and directories, which are also files, albeit special ones) and tells you information that is generally useful for file-things. For mail, use the message index and/or the sidebar. Most directories *are not* mail folders, and therefore attempting to display information useful for mail folders on directories in the file browser is the Wrong Thing™. Mutt could perhaps special-case the ones it knows (via configuration) are mail folders, but main purpose of showing directories in the file browser is to navigate them, and I suspect most users rarely look at most of the info on directories in the file browser for that reason... So that still seems like the Wrong Thing™ to me. [The fact that no one seems to have noticed/reported the file size bug for at least a year seems to support that, too...] -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On Sat, Sep 26, 2020 at 05:02:08PM +0100, Chris Green wrote: > However there is a minor downside in the file browser (well directory > browser really isn't it), the information shown against the > directories (at the bottom level these are maildir mailboxes) is > pretty useless, what I am seeing now is like the following:- > > selling/ Sep 25 12:39 0K > shopping/Sep 25 12:39 0K > software/Sep 25 12:39 0K > telecoms/Sep 25 12:39 0K > > No size information and the date is just the date of creation of the > parent directory, not the latest message. With mbox you get a 'last > message' date and a meaningful size. They may be maildirs, but in the file browser they are directories, for the purpose of navigating the file system. In that context, the fact that they are maildirs is not relevant: In the context of browsing files, you want info about the files, which is what Mutt gives you. This is somewhat configurable (see the manual about folder_format), but it's not going to give you any info about the mail that's in those directories... Wrong context. There IS size info, although it's wrong... That appears to be a bug introduced some time after 1.9.4, which I have lying around, that has it right. I also have 1.12.2 where it is wrong, so... somewhere in between. However the size of a directory is very likely not what you think it is, and is not particularly useful to you. On Unix systems, at least for most file systems, the size of a directory is the space occupied by the blocks needed to hold the internal representation of the listing of the directory... NOT the size of the contents of the directory. The size increases with the number of files in the directory (but not their size), and it is a multiple of the disk block size, so it's almost always (exactly) 1K, 4K, 8K, 16K, or an exact multiple thereof... Mutt could, in theory, get the size of the contents of the directory for you... but in order to do that it would need to do the equivalent of du -s ON EVERY SUBDIRECTORY IN THE DIRECTORY YOU ARE BROWSING, which is prohibitively expensive, no matter what hardware you are on. If you had that feature, I'm fairly positive you would turn it off immediately. I don't think any sane maintainer would commit a patch for that... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On Sun, Sep 27, 2020 at 10:07:41 +0100, Chris Green wrote: > Are you using maildir? Have been from the start. I use offlineimap to sync my mail from a number of accounts and then let mutt work with those. --Ben
Re: Getting more useful information in file browser - possible with maildir?
On Sat, Sep 26, 2020 at 06:52:23PM -0400, Ben Boeckel wrote: > On Sat, Sep 26, 2020 at 21:59:43 +0100, Chris Green wrote: > > Er, um, that is what I'm using - and have been using for more years > > than I like to remember! > > Hmm. The dates I have in my folder listing seem to be "last modified" > including messages being added or removed: > > 0.1K Sep 26 11:55 ~/.local/share/mail/XXX > > The size is wrong, but I'm not too worried about that myself. My > folder_format: > > set folder_format = '%2C %t %N %F %-8.8u %-8.8g %8s %d %f' > > I think the `%d` is what you'd be interested in for the date like I > have. > Are you using maildir? -- Chris Green
Re: Getting more useful information in file browser - possible with maildir?
On Sat, Sep 26, 2020 at 21:59:43 +0100, Chris Green wrote: > Er, um, that is what I'm using - and have been using for more years > than I like to remember! Hmm. The dates I have in my folder listing seem to be "last modified" including messages being added or removed: 0.1K Sep 26 11:55 ~/.local/share/mail/XXX The size is wrong, but I'm not too worried about that myself. My folder_format: set folder_format = '%2C %t %N %F %-8.8u %-8.8g %8s %d %f' I think the `%d` is what you'd be interested in for the date like I have. --Ben
Re: Getting more useful information in file browser - possible with maildir?
On Sat, Sep 26, 2020 at 04:54:56PM -0400, Ben Boeckel wrote: > On Sat, Sep 26, 2020 at 20:29:22 +0100, Chris Green wrote: > > They're on a fast SSD on the same system as mutt is running on so > > 'very expensive' is probably not an issue. > > Typical tools like `ls` don't know that. GUI browsers might be smarter, > but that hasn't been consistent IME. Not sure about terminal browsers so > much. > > > As I said 'very expensive' may not be an issue. > > Maybe there's an option to do so in whatever you are browsing? > > > ?? I'm a bit lost here, you recommend a "maildir browser" and say "... > > which mutt is very good at", so is mutt a maildir browser? > > It essentially is... Shows the subjects rather than whatver wacky > filenames actually exists on disks too. You seem to be asking direfctory > browsers to rush towards the Law of Software Envelopment: > > Every program attempts to expand until it can read mail. Those > programs which cannot so expand are replaced by ones which can. > > For email stored in files, use an email-aware program. Mutt is one of > them. > Er, um, that is what I'm using - and have been using for more years than I like to remember! -- Chris Green
Re: Getting more useful information in file browser - possible with maildir?
On Sat, Sep 26, 2020 at 20:29:22 +0100, Chris Green wrote: > They're on a fast SSD on the same system as mutt is running on so > 'very expensive' is probably not an issue. Typical tools like `ls` don't know that. GUI browsers might be smarter, but that hasn't been consistent IME. Not sure about terminal browsers so much. > As I said 'very expensive' may not be an issue. Maybe there's an option to do so in whatever you are browsing? > ?? I'm a bit lost here, you recommend a "maildir browser" and say "... > which mutt is very good at", so is mutt a maildir browser? It essentially is... Shows the subjects rather than whatver wacky filenames actually exists on disks too. You seem to be asking direfctory browsers to rush towards the Law of Software Envelopment: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. For email stored in files, use an email-aware program. Mutt is one of them. --Ben
Re: Getting more useful information in file browser - possible with maildir?
On Sat, Sep 26, 2020 at 01:13:11PM -0400, Ben Boeckel wrote: > On Sat, Sep 26, 2020 at 17:02:08 +0100, Chris Green wrote: > > However there is a minor downside in the file browser (well directory > > browser really isn't it), the information shown against the > > directories (at the bottom level these are maildir mailboxes) is > > pretty useless, what I am seeing now is like the following:- > > > > selling/ Sep 25 12:39 0K > > shopping/Sep 25 12:39 0K > > software/Sep 25 12:39 0K > > telecoms/Sep 25 12:39 0K > > > > No size information and the date is just the date of creation of the > > parent directory, not the latest message. With mbox you get a 'last > > message' date and a meaningful size. > > That's most likely a "last edited" date. Adding flags or labels to a > message would have reset that time as well. These directories were last > edited on the date you created them, so not much is going to change > that. You'd want access time, but that isn't reliable anyways (see > relatime and noatime mount options) because it makes reads potentially > very expensive writes to update atimes all the way up the tree. They're on a fast SSD on the same system as mutt is running on so 'very expensive' is probably not an issue. > > > Are there any configuration options to improve this for maildir? > > Not really? You might be able to get recursive size info, but that's > potentially very expensive to compute, so isn't usually done by default. > As I said 'very expensive' may not be an issue. > > This is by no means a show stopper, I'm going to stay with maildir, > > but it woud be nice to be able to improve it a bit. > > I'd recommend using a "maildir browser" which knows how to interpret the > information you're looking for (and which mutt is very good at). > ?? I'm a bit lost here, you recommend a "maildir browser" and say "... which mutt is very good at", so is mutt a maildir browser? -- Chris Green
Re: Getting more useful information in file browser - possible with maildir?
On Sat, Sep 26, 2020 at 17:02:08 +0100, Chris Green wrote: > However there is a minor downside in the file browser (well directory > browser really isn't it), the information shown against the > directories (at the bottom level these are maildir mailboxes) is > pretty useless, what I am seeing now is like the following:- > > selling/ Sep 25 12:39 0K > shopping/Sep 25 12:39 0K > software/Sep 25 12:39 0K > telecoms/Sep 25 12:39 0K > > No size information and the date is just the date of creation of the > parent directory, not the latest message. With mbox you get a 'last > message' date and a meaningful size. That's most likely a "last edited" date. Adding flags or labels to a message would have reset that time as well. These directories were last edited on the date you created them, so not much is going to change that. You'd want access time, but that isn't reliable anyways (see relatime and noatime mount options) because it makes reads potentially very expensive writes to update atimes all the way up the tree. > Are there any configuation options to improve this for maildir? Not really? You might be able to get recursive size info, but that's potentially very expensive to compute, so isn't usually done by default. > This is by no means a show stopper, I'm going to stay with maildir, > but it woud be nice to be able to improve it a bit. I'd recommend using a "maildir browser" which knows how to interpret the information you're looking for (and which mutt is very good at). --Ben
Getting more useful information in file browser - possible with maildir?
As per my recent questions and (successful) report I have just moved from using mbox to maildir. I'm generally happy with the result, apart from anything else it simplifies my custom MDA script and also some other utilities. However there is a minor downside in the file browser (well directory browser really isn't it), the information shown against the directories (at the bottom level these are maildir mailboxes) is pretty useless, what I am seeing now is like the following:- selling/ Sep 25 12:39 0K shopping/Sep 25 12:39 0K software/Sep 25 12:39 0K telecoms/Sep 25 12:39 0K No size information and the date is just the date of creation of the parent directory, not the latest message. With mbox you get a 'last message' date and a meaningful size. Are there any configuation options to improve this for maildir? This is by no means a show stopper, I'm going to stay with maildir, but it woud be nice to be able to improve it a bit. -- Chris Green
Re: Odd problem with filename passed to browser, underscores replace spaces
On Fri, Jun 12, 2020 at 12:41:00PM -0700, Kevin J. McCarthy wrote:
> On Fri, Jun 12, 2020 at 11:53:24AM +0100, Chris Green wrote:
> > I have a small script to handle PDF (among other) attachments which is
> > called via mailcap.
> >
> > The mailcap entry is simply:-
> >
> >application/pdf; /home/chris/bin/muttfox %s
> >
> > The muttfox script gives the PDF file to firefox to be viewed.
> >
> > This works fine *except* when there are spaces in the filename,
> > something is changing the spaces in the filename to underscores before
> > the name is handed to muttfox in the %s parameter.
>
> Mutt does this for received email attachments automatically, but the
> filename itself should have underscores too. What do you mean by it not
> "working"?
>
> > So what is changing the spaces to underscores? Does mutt do it and,
> > if so, is there a parameter setting to change what it does?
>
> $mailcap_sanitize appears to be applied to %{} and %t expandos, but %s is
> always sanitized regardless of the setting.
>
Ah, thank you, that "%s is always sanitised" helps somewhat. It at
least explains why I don't get the expected filename.
It turned out that my issue was a bit further down the line in the way
Firefox handled it (misconfiguration on my part basically). The
change of spaces to underscores was just confusing me.
--
Chris Green
Re: Odd problem with filename passed to browser, underscores replace spaces
On Fri, Jun 12, 2020 at 11:53:24AM +0100, Chris Green wrote:
I have a small script to handle PDF (among other) attachments which is
called via mailcap.
The mailcap entry is simply:-
application/pdf; /home/chris/bin/muttfox %s
The muttfox script gives the PDF file to firefox to be viewed.
This works fine *except* when there are spaces in the filename,
something is changing the spaces in the filename to underscores before
the name is handed to muttfox in the %s parameter.
Mutt does this for received email attachments automatically, but the
filename itself should have underscores too. What do you mean by it not
"working"?
So what is changing the spaces to underscores? Does mutt do it and,
if so, is there a parameter setting to change what it does?
$mailcap_sanitize appears to be applied to %{} and %t expandos, but %s
is always sanitized regardless of the setting.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: Odd problem with filename passed to browser, underscores replace spaces
On Fri, Jun 12, 2020 at 11:53:24AM +0100, Chris Green wrote: > I have a small script to handle PDF (among other) attachments which is > called via mailcap. > > The mailcap entry is simply:- > > application/pdf; /home/chris/bin/muttfox %s > > The muttfox script gives the PDF file to firefox to be viewed. > > This works fine *except* when there are spaces in the filename, > something is changing the spaces in the filename to underscores before > the name is handed to muttfox in the %s parameter. > > I have checked by simply putting "echo $1 >/tmp/mffn" as the first > line of the script. > > When I hit 'v' in mutt I see (for example) :- > > -- Mutt: Attachments > -> I 1[text/html, quoted, utf-8, 15K] > A 2 Your policy documents.pdf [applica/pdf, base64, 772K] > > > But in /tmp/mffn there is:- > > chris$ more /tmp/mffn > /tmp/Your_policy_documents.pdf > > So what is changing the spaces to underscores? Does mutt do it and, > if so, is there a parameter setting to change what it does? > > > If I simply s[ave] the PDF file from mutt I get the filename with > spaces in it, the change is something to do with how mutt and mailcap > interact (I guess). > Forgot to say, I'm running Mutt 1.10.1 on xubuntu. It isn't $mailcap_sanitize doing this is it? -- Chris Green
Odd problem with filename passed to browser, underscores replace spaces
I have a small script to handle PDF (among other) attachments which is called via mailcap. The mailcap entry is simply:- application/pdf; /home/chris/bin/muttfox %s The muttfox script gives the PDF file to firefox to be viewed. This works fine *except* when there are spaces in the filename, something is changing the spaces in the filename to underscores before the name is handed to muttfox in the %s parameter. I have checked by simply putting "echo $1 >/tmp/mffn" as the first line of the script. When I hit 'v' in mutt I see (for example) :- -- Mutt: Attachments -> I 1[text/html, quoted, utf-8, 15K] A 2 Your policy documents.pdf [applica/pdf, base64, 772K] But in /tmp/mffn there is:- chris$ more /tmp/mffn /tmp/Your_policy_documents.pdf So what is changing the spaces to underscores? Does mutt do it and, if so, is there a parameter setting to change what it does? If I simply s[ave] the PDF file from mutt I get the filename with spaces in it, the change is something to do with how mutt and mailcap interact (I guess). -- Chris Green
Sort mailboxes vs. file browser
Hi all, It's bugged me forever that when I set sort_browser=unsorted, so that my mailboxes are shown to me in the order I list them, Mutt also shows me file listings in the file browser unsorted. I think this is insane. Mailboxes list != file list; the two have different properties and should be treated (and sorted) separately. Is there an existing patch or other solution to this problem? -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpw8UJD2cy4o.pgp Description: PGP signature
Re: new mail indicator in browser view
On Fri, Jul 15, 2016 at 11:37:18PM +0200, famfop wrote: Hi, I solved it the following way. I wanted to have a "startup-mailbox" folder with unread messages. Using mairix I set up the "maildir" and "mfolder" var in the rc and now I run mairix F:-s. It's a bit hacky but it shows all unread messages. Maybe you'll find a solution by digging into mairix In any way I'd say the way to go is indexing your mailfolders. Thanks for the suggestion - I'll look into this. I basically have three folders for each account into which mail is sorted automatically - Inbox, Spam, and Unsure - and I'd like to be able to quickly monitor the number of new messages in each when working in the MUA so I know whether to bother looking at Unsure or not. I'll see if something like mairix can provide this. It seems like the built-in mutt functionality be able to do this but maybe my expectations need recalibration. Jeremy
new mail indicator in browser view
Hello,
I've been giving mutt a spin for the past few days. I like it quite a
bit except for one issue I have been unable to solve: how to get the
mailbox browser to properly display new message status.
Platform: Debian jessie running NeoMutt (latest from git but have tried
mutt from official repo with same result)
Use case: I have two IMAP accounts I'm accessing. I have tried using
mutt's built-in IMAP functionality as well as using mbsync to sync to
local maildir and mutt to access that. Both ways work fine except for
the issue described below.
Expected behavior: When I switch to mailbox browser view ()
or start in browser view ("mutt -y") I expect to see a new message
indicator (for mbsync/maildir setup) or new message count (for IMAP
setup) for each folder defined using "mailboxes". The status should be
updated whenever mutt checks for new mail.
Observed behavior: Most of the time the indicators are empty or zero
regardless of new mail status. Using IMAP directly, the new message
count will be correct for a given mailbox after viewing it and returning
to the browser view, but will be "forgotten" after two or more other
mailboxes are visited. Using the mbsync/maildir setup, the only time the
"N" status indicator is set is when there is new mail present when
starting as "mutt -y" - it never appears in response to new mail
received after mutt is started, regardless of what I try. I should note
that new mail behavior from within index view works fine - the message
appears (along with a note in the status bar) shortly after the mail
actually arrives on the server with no action necessary on my part.
What I've tried: Turning on and off various combinations of settings
that my manual/mailing list/interwebs searches have suggested might be
relevant: "timeout", "mail_check", "imap_passive", "imap_idle".
Is my expected behavior incorrect? My apologies if this has been
answered already, but I've spent a lot of time searching for previous
solutions and testing more setups than I can remember and nothing has
solved my own situation. Does this "just work" for others? If so, can
anyone share a .muttrc MWE? I'd love to start using mutt more
extensively but this has been a significant stumbling block.
Thanks for any help.
Jeremy
How to display old messages (unread) in browser menu
Hi everybody, I'm writing to ask how to display old messages (unread) in the browser menu. In my .muttrc I've: set folder_format = "%4C [%d] %2N %2t %2f " I've no idea if it's possible and about which "code" I've to add. Thanks a lot Alan -- Alan Leoni signature.asc Description: Digital signature
Re: Exiting Mutt from browser menu
Hi all, I posted a replay to David message yesterday morning, but looking at mail-archive.com web site, that message is not shown... Now, I'm not sure if it's just a problem of that web site or my message was not received by any recipients of mutt-users mailing list. Anyway I can see my mail on an other archive on the web, You can see it at the following address: http://marc.info/?l=mutt-users=144101559823568=raw Did you receive that message properly? If you look at following links, my message appears only on the first one. I cannot see It on mail-archive.com instead... http://marc.info/?t=14404587526=1=2 https://www.mail-archive.com/mutt-users@mutt.org/maillist.html Can you confirm if you received my message?
Re: Exiting Mutt from browser menu
* Joe joe.on.l...@gmail.com [2015-08-25 09:32 -0400]: 2- I'd like to isolate a whole thread from the rest of messages/threads opening it in a new clean screen containing just that thread. Same behaviour of tin newsreader: - topics of a newsgroup are listed one per line So this would be threads collapsed to only show the parent email... that's doable (AFAIK) with mutt. - let's open a topic contains more than one message by typing right arrow key A binding of the right arrow key to uncollapse the thread... - tin shows on a new screen the opened topic with all threaded articles. plus other things (possibly). In this screen other topics are hidden (we are in a menu that Mutt doesn't seem to provide), could call it thread menu. - from there we can open single articles and then return to the topic menu. You may want to check out the thread with the subject, temporarily modifying thread display in the index? In that thread a macro was posted [1] that does something similar to what you want. The goal of the macro was to view a sub-thread alone on screen without the surrounding context of the original thread and with the indentation adjusted as if the sub-thread were the only part of the thread. While this is not exactly what you want, if you use the macro listed and select the thread instead of the sub-thread, and chain that with the uncollapse command bound to the right arrow key, then I believe you'd have the behavior you want. [1]: http://marc.info/?l=mutt-usersm=135819127711700 Anyway, that's what struck me when I read your email. Hope that helps. Regards, -- dave [ please don't CC me ] signature.asc Description: PGP signature
Re: N Flags don't appear in Browser Menu
On Thursday 27.08.15 15:54, Ian Zimmerman wrote: On 2015-08-28 00:36 +0200, Joe wrote: set folder = $HOME/Mail set spoolfile = +inbox mailboxes `echo +*` Manual section 3.14: Note The folders in the mailboxes command are resolved when the command is executed, so if these names contain shortcut characters (such as “=” and “!”), any variable definition that affects these characters (like $folder and $spoolfile) should be set before the mailboxes command. If none of these shortcuts are used, a local path should be absolute as otherwise Mutt tries to find it relative to the directory from where Mutt was started which may not always be desired. Likely since my bad english, I don't well understand the above sentence: - I defined, set $folder before use mailboxes command - I had used shortcut + to expand $HOME/Mail/ directory So I expected something resolved like this: /home/joe/Mail/mbox_1 /home/joe/Mail/mbox_2 ...and so on... It doesn't seem to work like that... So, frankly I don't well understand the quoted manual sentence. try this: mailboxes `echo $HOME/Mail/+*` This doesn't work for me... Peraphs you included a + that has to be removed, indeed I tried the following: mailboxes `echo $HOME/Mail/*` This finally works!:) Now I can view N-flags properly also in browser menu. I've tested buffy-list and check-new... seems all works as expected now. So, mutt needs mailboxes command is in its rc file to consider files in Mail directory as real mailboxes and show if they contain new message. Side effect of that new mailboxes command was that I had to edit some macros used to quit/exit cause they didn't work as before... I also added some macro to remap the function of arrow keys: --- set sendmail=/usr/bin/formail -s /usr/bin/procmail -t -m /home/joe/.procmailoutrc set mbox_type = mbox set folder = $HOME/Mail set spoolfile = +inbox set move = no set record = set use_from = no push c? macro browser q 'exitexit' macro browser right enter macro index right enter macro pager left exit macro pager down enter macro index left change-folder? open another folder macro index q change-folder? open another folder set mail_check_recent = no mailboxes `echo $HOME/Mail/*` macro generic,browser,index,pager ò check-new set date_format = !%A %d.%m.%y %H:%M set index_format = %4C %Z %30D %-30.30L (%4l) %s set sort_aux=last-date-received set folder_format = %4C %t %-35.35f %15.15d %10N set sort_browser = reverse-date set mask = '!^\.' set sort = threads set strict_threads = yes set alias_file = ~/.mail/aliases.mutt set sort_alias = alias set reverse_alias = yes source $alias_file macro generic,index,pager,browser \ea !vim $HOME/.mail/aliases.mutt\n:source $HOME/.mail/aliases.mutt\n macro index,pager,browser,generic G !fetchmail /dev/null \n Invoke fetchmail folder-hook address1@domain my_hdr From: address1@domain folder-hook address2@domain my_hdr From: address2@domain folder-hook address3@domain my_hdr From: address3@domain auto_view text/html set mailcap_path = ~/.mailcap:/etc/mailcap:/usr/lib/mime/mailcap --- Thanks again for your help! Hope this thread could be usefull for other users too. Bye.
Re: N Flags don't appear in Browser Menu
On Thursday 27.08.15 21:40, Patrick Shanahan wrote: * Joe joe.on.l...@gmail.com [08-27-15 18:41]: Hope this will be usefull to solve... Very difficult solving problems when one does not know all the parameters and doesn't have access. This information is necessary you *you* to provide when you have a problem and are seeking help. Crystal Balls are not much good any more. You are all right, if I posted my rc files at the begining of this thread, it would have been much much shorter... Thanks for your suggest! :) bye
Re: N Flags don't appear in Browser Menu
On 27.08.15 13:40, Joe wrote: Nothing changes... still no N-flag in browser menu... That is peculiar. Have we compared a positive buffy-check, i.e. hitting '.' and being told that there's new mail, then hitting 'y' to look for 'N's? If that is negative, please change your folder_format to put the %N first. What happens then? Here, if four mailboxes are nominated by '.', then they also have 'N's in the browser. For an instant check on one, sending myself an email suffices. Erik -- Sometime when you least expect it, Love will tap you on the shoulder... and ask you to move out of the way because it still isn't your turn. - N.V. Plyter
Re: N Flags don't appear in Browser Menu
On Thursday 27.08.15 23:43, Erik Christiansen wrote: On 27.08.15 13:40, Joe wrote: Nothing changes... still no N-flag in browser menu... That is peculiar. Have we compared a positive buffy-check, i.e. hitting '.' and being told that there's new mail, then hitting 'y' to look for 'N's? I've tried to sen myself a mail message so that my test-mail mailbox is filled with a new mail. I sent it using mailx, so that mutt is not opened/closed and so on... Then I ran fetchmail... And finally I've opened Mutt. Using 'push cTAB' in my muttrc, I'm directly in browser menu at mutt start up, in front of my mailboxes list contained in ~/Mail. Here I've pressed . as suggested, but nothing happened... Mailboxes list doesn't change... Before go on, I sent this message. So no response by hitting .
Re: N Flags don't appear in Browser Menu
* Joe joe.on.l...@gmail.com [08-27-15 12:10]:
[...]
Then I ran fetchmail...
And finally I've opened Mutt.
Using 'push cTAB' in my muttrc, I'm directly in browser menu at
mutt start up, in front of my mailboxes list contained in ~/Mail.
Here I've pressed . as suggested, but nothing happened...
Mailboxes list doesn't change...
Before go on, I sent this message.
So no response by hitting .
Post or provide access to ~/.muttrc and /etc/Muttrc or any {M,m}uttrc on
your system. Obfuscate anything that is sensitive to you or your system.
You are having an awful lot of difficulty for something that Just
Works!tm
--
(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: N Flags don't appear in Browser Menu
On 2015-08-28 00:36 +0200, Joe wrote: set folder = $HOME/Mail set spoolfile = +inbox mailboxes `echo +*` Manual section 3.14: Note The folders in the mailboxes command are resolved when the command is executed, so if these names contain shortcut characters (such as “=” and “!”), any variable definition that affects these characters (like $folder and $spoolfile) should be set before the mailboxes command. If none of these shortcuts are used, a local path should be absolute as otherwise Mutt tries to find it relative to the directory from where Mutt was started which may not always be desired. try this: mailboxes `echo $HOME/Mail/+*` -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: N Flags don't appear in Browser Menu
On Thursday 27.08.15 12:58, Patrick Shanahan wrote:
* Joe joe.on.l...@gmail.com [08-27-15 12:10]:
[...]
Then I ran fetchmail...
And finally I've opened Mutt.
Using 'push cTAB' in my muttrc, I'm directly in browser menu at
mutt start up, in front of my mailboxes list contained in ~/Mail.
Here I've pressed . as suggested, but nothing happened...
Mailboxes list doesn't change...
Before go on, I sent this message.
So no response by hitting .
Post or provide access to ~/.muttrc and /etc/Muttrc or any {M,m}uttrc on
your system. Obfuscate anything that is sensitive to you or your system.
You are having an awful lot of difficulty for something that Just
Works!tm
~/.muttrc
---
set sendmail=/usr/bin/formail -s /usr/bin/procmail -t -m
/home/joe/.procmailoutrc
set mbox_type = mbox
set folder = $HOME/Mail
set spoolfile = +inbox
set move = no
set record =
set use_from = no
push cTAB
macro browser q 'exitenterquit'
macro index q change-folderTAB open another folder
set mail_check_recent = no
mailboxes `echo +*`
macro generic,browser,index,pager ò check-new
set date_format = !%A %d.%m.%y %H:%M
set index_format = %4C %Z %30D %-30.30L (%4l) %s
set sort_aux=last-date-received
set folder_format = %4C %t %-35.35f %15.15d %N
set sort_browser = reverse-date
set mask = '!^\.'
set sort = threads
set strict_threads = yes
set alias_file = ~/.mail/aliases.mutt
set sort_alias = alias
set reverse_alias = yes
source $alias_file
macro generic \ea !vim $HOME/.mail/aliases.mutt\n:source
$HOME/.mail/aliases.mutt\n
macro index \ea !vim $HOME/.mail/aliases.mutt\n:source
$HOME/.mail/aliases.mutt\n
macro pager \ea !vim $HOME/.mail/aliases.mutt\n:source
$HOME/.mail/aliases.mutt\n
macro browser \ea !vim $HOME/.mail/aliases.mutt\n:source
$HOME/.mail/aliases.mutt\n
macro index G !fetchmail /dev/null \n Invoke fetchmail
macro pager G !fetchmail /dev/null \n Invoke fetchmail
macro browser G !fetchmail /dev/null \n Invoke fetchmail
folder-hook addr_1@domain.invalid my_hdr From: addr_1@domain.invalid
folder-hook addr_2@domain.invalid my_hdr From: addr_2@domain.invalid
folder-hook addr_3@domain.invalid my_hdr From: addr_3@domain.invalid
folder-hook addr_4@domain.invalid my_hdr From: addr_4@domain.invalid
folder-hook addr_5@domain.invalid my_hdr From: addr_5@domain.invalid
folder-hook addr_6@domain.invalid my_hdr From: addr_6@domain.invalid
auto_view text/html
set mailcap_path = ~/.mailcap:/etc/mailcap:/usr/lib/mime/mailcap
---
I found also following files in /etc, I don't know if they are really
read by mutt at startup, anyway here they are:
---
$ cat /etc/mutt/Muttrc|sed '/^#/d;/^$/d'
---
ignore *
unignore from: subject to cc date x-mailer x-url user-agent
hdr_order date from to cc subject
macro index \eb search~b search in message bodies
macro index,pager,attach,compose \cb \
enter-command set my_pipe_decode=\$pipe_decode pipe_decodeEnter\
pipe-message urlviewEnter\
enter-command set pipe_decode=\$my_pipe_decode; unset my_pipe_decodeEnter \
call urlview to extract URLs out of a message
macro generic,pager F1 shell-escape less
/usr/doc/mutt-1.5.23/manual.txtEnter show Mutt documentation
macro index,pager y change-folder?toggle-mailboxes show incoming
mailboxes list
bind browser y exit
mime_lookup application/octet-stream
attachments +A */.*
attachments -A text/x-vcard application/pgp.*
attachments -A application/x-pkcs7-.*
attachments +I text/plain
attachments -A message/external-body
attachments -I message/external-body
---
$ cat /etc/mutt/Muttrc.orig|sed '/^#/d;/^$/d'
---
ignore *
unignore from: subject to cc date x-mailer x-url user-agent
hdr_order date from to cc subject
macro index \eb search~b search in message bodies
macro index,pager,attach,compose \cb \
enter-command set my_pipe_decode=\$pipe_decode pipe_decodeEnter\
pipe-message urlviewEnter\
enter-command set pipe_decode=\$my_pipe_decode; unset my_pipe_decodeEnter \
call urlview to extract URLs out of a message
macro generic,pager F1 shell-escape less
/usr/doc/mutt-1.5.21/manual.txtEnter show Mutt documentation
macro index,pager y change-folder?toggle-mailboxes show incoming
mailboxes list
bind browser y exit
mime_lookup application/octet-stream
attachments +A */.*
attachments -A text/x-vcard application/pgp.*
attachments -A application/x-pkcs7-.*
attachments +I text/plain
attachments -A message/external-body
attachments -I message/external-body
---
Hope this will be usefull to solve...
Thanks a lot for your help! :)
Bye
Re: N Flags don't appear in Browser Menu
* Joe joe.on.l...@gmail.com [08-27-15 18:41]: [...] mailboxes `echo +*` Ian probably solved your problem here :) I found also following files in /etc, I don't know if they are really read by mutt at startup, anyway here they are: Explained in the very fine manual which really should be read if you plan on making the type configuration changes you have in your ~/.muttrc Hope this will be usefull to solve... Very difficult solving problems when one does not know all the parameters and doesn't have access. This information is necessary you *you* to provide when you have a problem and are seeking help. Crystal Balls are not much good any more. -- (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: N Flags don't appear in Browser Menu
On Wednesday 26.08.15 17:34, Ian Zimmerman wrote: Check the code, in buffy.c, buffy_mbox_hasnew(). It's a good deal more complicated, and there are quite a few more ways it could be messed up. Including, but maybe not limited to, the config options check_mbox_size and mail_check_recent. Thanks for your hint! I've gave it a look... Even if my C skills are not good at all... And unfortunately I haven't understood anything more related to my reported issue. :( It seems that my sentence (reported by mbox manual) was not completely wrong: --- if mtime atime --- mailbox has new mail --- Am I wrong? Anyway in my muttrc I've not setted check_mbox_size nor mail_check_recent variable, they has default value (boolean: no for the first and yes for the second one, maybe here is the matter..). manual.txt says: 3.119. mail_check_recent Type: boolean Default: yes When set, Mutt will only notify you about new mail that has been received since the last time you opened the mailbox. When unset, Mutt will notify you if any new mail exists in the mailbox, regardless of whether you have visited it recently. When $mark_old is set, Mutt does not consider the mailbox to contain new mail if only old messages exist. --- I'll try to set this variable to no... and report if something changes. See you! :)
Re: N Flags don't appear in Browser Menu
On Thursday 27.08.15 12:31, Joe wrote: manual.txt says: 3.119. mail_check_recent Type: boolean Default: yes When set, Mutt will only notify you about new mail that has been received since the last time you opened the mailbox. When unset, Mutt will notify you if any new mail exists in the mailbox, regardless of whether you have visited it recently. When $mark_old is set, Mutt does not consider the mailbox to contain new mail if only old messages exist. --- I'll try to set this variable to no... and report if something changes. See you! :) Nothing changes... still no N-flag in browser menu...
Re: N Flags don't appear in Browser Menu
On Tuesday 25.08.15 09:43, Ian Zimmerman wrote: On 2015-08-25 17:35 +0200, Joe wrote: %N should mean: show N flag for mailboxes containing New mail messages all mailboxes are in mbox format (at now) not in maildir format. I have many mailboxes, filled using fetchmail/procmail. With mbox, AFAIK mutt detects newness simply by comparing mtime with atime of the file. If they're the same, it is new. Are you possibly mounting the filesystem with the noatime option? In /etc/mtab I have the following set up for filesystem of root partition: --- /dev/sda5 / ext4 rw,commit=0 0 0 --- So, no noatime option...
Re: N Flags don't appear in Browser Menu
On Wednesday 26.08.15 08:03, Joe wrote: On Tuesday 25.08.15 09:43, Ian Zimmerman wrote: On 2015-08-25 17:35 +0200, Joe wrote: %N should mean: show N flag for mailboxes containing New mail messages all mailboxes are in mbox format (at now) not in maildir format. I have many mailboxes, filled using fetchmail/procmail. With mbox, AFAIK mutt detects newness simply by comparing mtime with atime of the file. If they're the same, it is new. Are you possibly mounting the filesystem with the noatime option? In /etc/mtab I have the following set up for filesystem of root partition: --- /dev/sda5 / ext4 rw,commit=0 0 0 --- So, no noatime option... I tried to send a message myself (sender and recipient are the same address). My procmail config deliver this type of messages in a mailbox called test-mail (~/Mail/test-mail), and it is mbox format. Now if I use stat command before opening that mailbox with mutt or any other client I can see (my shell returns that output in Italian instead of English): --- File: Mail/mail.tests Dim.: 41075 Blocchi: 88 Blocco di IO: 4096 file regolare Device: 805h/2053d Inode: 2434807 Coll.: 1 Accesso: (0600/-rw---) Uid: ( 1000/ joe) Gid: ( 16/ dialout) Accesso : 2015-08-26 17:16:35.0 +0200 Modifica : 2015-08-26 23:48:13.819996412 +0200 Cambio : 2015-08-26 23:48:13.819996412 +0200 Creazione: - --- So we have: mtime (Aug 26 17:16) atime (Aug 26 23:48) As explained by Ian Zimmerman and by man pages of mbox(5): --- If the modification-time (usually determined via stat(2)) of a nonempty mbox file is greater than the access-time the file has new mail. --- This should mean our mail.test mailbox contains new messages and I would expect Mutt shows N flag when I'm in browser menu. In my ~/.muttrc I've set: --- set folder_format = %4C %t %-40f %30.30d %-10.10N set sort_browser = reverse-date --- So I expected an N flag at the end of mail.test line in browser menu. But I can just view the following line when I open Mutt browser menu: --- 1 mail.tests Aug 26 23:48 --- So... There isn't any N flag following last modification date/time info (Aug 26 23:48)! :( If I don't open that mailbox, quit Mutt and recall stat command I still see the same report as above... as expected: --- $ stat Mail/mail.tests File: Mail/mail.tests Dim.: 41075 Blocchi: 88 Blocco di IO: 4096 file regolare Device: 805h/2053d Inode: 2434807 Coll.: 1 Accesso: (0600/-rw---) Uid: ( 1000/ joe) Gid: ( 16/ dialout) Accesso : 2015-08-26 17:16:35.0 +0200 Modifica : 2015-08-26 23:48:13.819996412 +0200 Cambio : 2015-08-26 23:48:13.819996412 +0200 Creazione: - --- Even though I've searched the net, I haven't found a solution yet. I suspected the problem was in folder_format variable, but also with default value (%2C %t %N %F %2l %-8.8u %-8.8g %8s %d %f) N flag doesn't appear anyway... Hope these info could be useful. If you have any hints would be greatly appreciated! :) Thanks again, see you!
Re: N Flags don't appear in Browser Menu
On Thu, Aug 27, 2015 at 01:00:04AM +0200, Joe wrote: On Wednesday 26.08.15 08:03, Joe wrote: On Tuesday 25.08.15 09:43, Ian Zimmerman wrote: On 2015-08-25 17:35 +0200, Joe wrote: %N should mean: show N flag for mailboxes containing New mail messages all mailboxes are in mbox format (at now) not in maildir format. I have many mailboxes, filled using fetchmail/procmail. With mbox, AFAIK mutt detects newness simply by comparing mtime with atime of the file. If they're the same, it is new. Are you possibly mounting the filesystem with the noatime option? In /etc/mtab I have the following set up for filesystem of root partition: --- /dev/sda5 / ext4 rw,commit=0 0 0 --- So, no noatime option... I tried to send a message myself (sender and recipient are the same address). My procmail config deliver this type of messages in a mailbox called test-mail (~/Mail/test-mail), and it is mbox format. Now if I use stat command before opening that mailbox with mutt or any other client I can see (my shell returns that output in Italian instead of English): --- File: Mail/mail.tests Dim.: 41075 Blocchi: 88 Blocco di IO: 4096 file regolare Device: 805h/2053d Inode: 2434807 Coll.: 1 Accesso: (0600/-rw---) Uid: ( 1000/ joe) Gid: ( 16/ dialout) Accesso : 2015-08-26 17:16:35.0 +0200 Modifica : 2015-08-26 23:48:13.819996412 +0200 Cambio : 2015-08-26 23:48:13.819996412 +0200 Creazione: - --- So we have: mtime (Aug 26 17:16) atime (Aug 26 23:48) As explained by Ian Zimmerman and by man pages of mbox(5): --- If the modification-time (usually determined via stat(2)) of a nonempty mbox file is greater than the access-time the file has new mail. --- This should mean our mail.test mailbox contains new messages and I would expect Mutt shows N flag when I'm in browser menu. In my ~/.muttrc I've set: --- set folder_format = %4C %t %-40f %30.30d %-10.10N set sort_browser = reverse-date --- So I expected an N flag at the end of mail.test line in browser menu. But I can just view the following line when I open Mutt browser menu: What is the character width of your terminal? By my count the N field starts at about the 84th character. Also, why specify a 10 char wide field for a 1 char piece of data? Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: N Flags don't appear in Browser Menu
On 2015-08-26 17:07 -0700, Ian Zimmerman wrote: On 2015-08-27 01:00 +0200, Joe wrote: mtime (Aug 26 17:16) atime (Aug 26 23:48) As explained by Ian Zimmerman and by man pages of mbox(5): --- If the modification-time (usually determined via stat(2)) of a nonempty mbox file is greater than the access-time the file has new mail. --- This should mean our mail.test mailbox contains new messages and I would expect Mutt shows N flag when I'm in browser menu. No, it is the opposite (as I had written correctly but you misinterpreted). When new mail is delivered, _both_ mtime and atime should under normal circumstances get bumped, so they're the same; this is the new state. When something reads the file (be it a MUA or something else by accident, for example if you manually view the mailbox with a pager), the atime is bumped but the mtime is not. This is the old state. I was wrong, but you aren't exactly right, either :-P Check the code, in buffy.c, buffy_mbox_hasnew(). It's a good deal more complicated, and there are quite a few more ways it could be messed up. Including, but maybe not limited to, the config options check_mbox_size and mail_check_recent. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: N Flags don't appear in Browser Menu
On 2015-08-27 01:00 +0200, Joe wrote: mtime (Aug 26 17:16) atime (Aug 26 23:48) As explained by Ian Zimmerman and by man pages of mbox(5): --- If the modification-time (usually determined via stat(2)) of a nonempty mbox file is greater than the access-time the file has new mail. --- This should mean our mail.test mailbox contains new messages and I would expect Mutt shows N flag when I'm in browser menu. No, it is the opposite (as I had written correctly but you misinterpreted). When new mail is delivered, _both_ mtime and atime should under normal circumstances get bumped, so they're the same; this is the new state. When something reads the file (be it a MUA or something else by accident, for example if you manually view the mailbox with a pager), the atime is bumped but the mtime is not. This is the old state. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: Exiting Mutt from browser menu
On Tuesday 25.08.15 16:14, Francesco Ariis wrote: On Tue, Aug 25, 2015 at 03:29:28PM +0200, Joe wrote: Let's test it... ... Ye it works! :) Question solved! Thanks a lot for your help. Glad it worked. I still don't know why our macros differ since we are using the exact same version - Mutt 1.5.23 (2014-03-12) - maybe Debian (which I am using) packages mutt with slightly different defaults. Maybe, I'm on Slackware... 1- N flags in my browser menu do not appears even if my mailboxes contain brand new messages. This is really, *really* weird. If you are using maildirs, do those folders have files in your-folder/new/ subdirectory (upon new mail arrival)? Do other clients (sylpheed, etc.) recognise new mail? This should have an other subject. I'll send an other topic to this same mailing list. Let's talk about there. 2- I'd like to isolate a whole thread from the rest of messages/threads opening it in a new clean screen containing just that thread. I don't know if such a thing is possible (maybe, *maybe* there is a patched mutt version out there which does that, I cannot help because I have always used vanilla mutt). To navigate mailing-list threads easily, this is my setup; perhaps there is something you can grab: - set sort=threads - turn pager_index_lines on - have some 'collapse thread' keys handy: bind index c collapse-thread bind index C collapse-all - make liberal use of C-d (delete-thread) - have a macro to unsubscribe from mailing-lists threads http://ariis.it/static/articles/mutt-ml/page.html Thanks for your reply. See you! :)
Re: Exiting Mutt from browser menu
Joe wrote: On 24.08.15 18:09, Kevin J. McCarthy wrote: joe.on.l...@gmail.com wrote: Is there a way to quit mutt immediately when I'm in browser menu? uppercase Q is bound to quit. This will save changes to the mailbox and quit mutt. Perhaps this should work from index menu, when you are within a mailbox, but Q doesn't seem to be assigned when I press it from browser menu. I'm 0 for 2 this week... Sorry for some reason I misread and thought you meant pager menu. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA http://www.8t8.us/configs/gpg-key-transition-statement.txt signature.asc Description: PGP signature
Re: Exiting Mutt from browser menu
On Tue, Aug 25, 2015 at 03:29:28PM +0200, Joe wrote: Let's test it... ... Ye it works! :) Question solved! Thanks a lot for your help. Glad it worked. I still don't know why our macros differ since we are using the exact same version - Mutt 1.5.23 (2014-03-12) - maybe Debian (which I am using) packages mutt with slightly different defaults. There are still a couple of things I'd like to obtain, one should be easy and the other could be not possible at all: 1- N flags in my browser menu do not appears even if my mailboxes contain brand new messages. This is really, *really* weird. If you are using maildirs, do those folders have files in your-folder/new/ subdirectory (upon new mail arrival)? Do other clients (sylpheed, etc.) recognise new mail? 2- I'd like to isolate a whole thread from the rest of messages/threads opening it in a new clean screen containing just that thread. I don't know if such a thing is possible (maybe, *maybe* there is a patched mutt version out there which does that, I cannot help because I have always used vanilla mutt). To navigate mailing-list threads easily, this is my setup; perhaps there is something you can grab: - set sort=threads - turn pager_index_lines on - have some 'collapse thread' keys handy: bind index c collapse-thread bind index C collapse-all - make liberal use of C-d (delete-thread) - have a macro to unsubscribe from mailing-lists threads http://ariis.it/static/articles/mutt-ml/page.html signature.asc Description: Digital signature
Re: Exiting Mutt from browser menu
On 25.08.15 15:29, Joe wrote: Mmmm, this differs on my machine: from browser menu I can see mailboxes in ~/Mail directory. If I type :exec exit, mutt ask me for which mailbox I want to open, doesn't switch to the last opened automatically. I have to type enter to open last seen mailbox. Is your quit quadoption by any chance set to ask-yes or ask-no? Erik -- Ben and Paddy (police officers from Ramingining, about 20 kilometres away) came over and took it away from me. - Damien Lumsden referring to an unexploded WW2 bomb he'd been carting around in the backof his ute. http://www.abc.net.au/news/2015-08-25/wwii-bomb-loaded-on-ute-for-nt-show-and-tell-before-detonation/6723614
Re: Exiting Mutt from browser menu
On Wednesday 26.08.15 00:12, Erik Christiansen wrote: On 25.08.15 15:29, Joe wrote: Mmmm, this differs on my machine: from browser menu I can see mailboxes in ~/Mail directory. If I type :exec exit, mutt ask me for which mailbox I want to open, doesn't switch to the last opened automatically. I have to type enter to open last seen mailbox. Is your quit quadoption by any chance set to ask-yes or ask-no? Erik I have not set any quit variable in my muttrc. By reading man muttrc I see It should be setted to yes by default. This explains also why my default config let mutt quit without any confirm by typing q from within index menu. Now With macros reported in my other message it seems to work as expected. Thanks anyway for your reply.
Re: N Flags don't appear in Browser Menu
On 2015-08-25 17:35 +0200, Joe wrote: %N should mean: show N flag for mailboxes containing New mail messages all mailboxes are in mbox format (at now) not in maildir format. I have many mailboxes, filled using fetchmail/procmail. With mbox, AFAIK mutt detects newness simply by comparing mtime with atime of the file. If they're the same, it is new. Are you possibly mounting the filesystem with the noatime option? -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
N Flags don't appear in Browser Menu
As you can see by mail subject I noticed this unexpected behavoiur. Follows my folder_format setting from muttrc. --- set folder_format = %2C %t %-50.50f %N %20.20d --- %N should mean: show N flag for mailboxes containing New mail messages Thanks in advance to Francesco Ariis who replied: This is really, *really* weird. If you are using maildirs, do those folders have files in your-folder/new/ subdirectory (upon new mail arrival)? Do other clients (sylpheed, etc.) recognise new mail? 1- I'm using just mutt at this time... No other mail client a part mailx. (yes, I've used KMail/Akonadi for a long, but not for local mailboxes). 2- My email config: all mailboxes are in mbox format (at now) not in maildir format. I have many mailboxes, filled using fetchmail/procmail. ~/Mail Mail directory containing mailboxes mailbox1 mailbox2 mailbox3--- Mailboxes in mbox format not maildir mailbox4 mailbox5 3- When I'm in Index Menu I can view N flags near new messages as expected... Seems N flags disappears just in browser menu. Thanks in advance!
Re: Exiting Mutt from browser menu
On 24.08.15 18:09, Kevin J. McCarthy wrote: joe.on.l...@gmail.com wrote: Is there a way to quit mutt immediately when I'm in browser menu? uppercase Q is bound to quit. This will save changes to the mailbox and quit mutt. Perhaps this should work from index menu, when you are within a mailbox, but Q doesn't seem to be assigned when I press it from browser menu.
Re: Exiting Mutt from browser menu
On 25.08.15 02:19, Francesco Ariis wrote: macro browser q exitquit This doesn't work for me... When I press q mutt says something like: change to folder quit ? And if I press enter it says obviously that quit mailbox doesn't exists... Anyway this macro doesn't quit mutt at all... The only way I found to quit from browser menu is by Ctrl + c. With that sequence mutt ask if I really want to quit mutt (default yes), so I finnally press Enter and mutt quits. So the sequence I found would be: Ctrl+center But I don't know if it is a clean way to quit our mail client.. And I don't know how to automate that sequence (with a macro for example..). Anyway thaks for your reply. Ciao! :)
Re: Exiting Mutt from browser menu
On Tue, Aug 25, 2015 at 11:33:32AM +0200, Joe wrote: On 25.08.15 02:19, Francesco Ariis wrote: macro browser q exitquit This doesn't work for me... When I press q mutt says something like: change to folder quit ? And if I press enter it says obviously that quit mailbox doesn't exists... Anyway this macro doesn't quit mutt at all... Mhhh, weird. To diagnose this, let's see where our mutt behaviour differs: The browser menu is the one where all mailboxes/folders are listed. From there: - I type :exec exit and mutt returns to the last mailbox opened - Then I type :exec quit and mutt quits Does that work on your machine? I checked my .muttrc for related stuff but the only relevant lines were macro index q change-folder?toggle-mailboxes open another folder macro browser q exitquit
Re: Exiting Mutt from browser menu
On 25.08.15 13:18, Francesco Ariis wrote: The browser menu is the one where all mailboxes/folders are listed. From there: - I type :exec exit and mutt returns to the last mailbox opened Mmmm, this differs on my machine: from browser menu I can see mailboxes in ~/Mail directory. If I type :exec exit, mutt ask me for which mailbox I want to open, doesn't switch to the last opened automatically. I have to type enter to open last seen mailbox. Then, from within that mailbox (index menu), if I type :exec quit, mutt terminates as expected. So in my case a macro like this could work properly: --- macro browser q exitenterquit --- Let's test it... ... Ye it works! :) Question solved! Thanks a lot for your help. macro index q change-folder?toggle-mailboxes open another folder macro browser q exitquit Default index menu behaviour (when you are in a mailbox) is to quit Mutt by typing q. If I well understand your other macro, the one related to index menu would be to exit from current mailbox and go to mailbox list (browser menu). I don't know the meaning of question mark in that sequence, anyway in my case that doesn't work. I think it is a useful stuff: Read messages of a mailbox and then return to mailboxes listing of mail directory (~/Mail for me) by simply type q. I've just tried this: --- index q change-folderTAB open another folder --- And it seems to work as expected for me. PS. I'm trying to obtain a sort of hierarchical menu browsing: 1- list o mailboxes in Mail directory at startup (going in browser menu): push cTAB 2- enter in chosen mailbox (arrow keys and enter). 3- open a message 4- return to mailbox (index menu) by pressing q 5- return to mailboxes list (browse menu) by pressing q 6- quit Mutt by pressing q Ok, with those macros seems to work as I expected. There are still a couple of things I'd like to obtain, one should be easy and the other could be not possible at all: 1- N flags in my browser menu do not appears even if my mailboxes contain brand new messages. 2- I'd like to isolate a whole thread from the rest of messages/threads opening it in a new clean screen containing just that thread. Same behaviour of tin newsreader: - topics of a newsgroup are listed one per line - let's open a topic contains more than one message by typing right arrow key - tin shows on a new screen the opened topic with all threaded articles. In this screen other topics are hidden (we are in a menu that Mutt doesn't seem to provide), could call it thread menu. - from there we can open single articles and then return to the topic menu. I'll try to write a sort of analogy between tin and mutt menus/screens. --- Tin Newsreader Mutt MUA news-groups menu browser-menu (mailboxes list of ~/Mail) topics menu index-menu (message subjects list) thread menu -- missed -- article menu pager-menu (wher we read message --- Threads menu would be very useful for me especially to read mailing list threads in a more clean way, this could be the subject of a new thread on this mailing list...
Re: Exiting Mutt from browser menu
On Tue, Aug 25, 2015 at 01:23:04AM +0200, joe.on.l...@gmail.com wrote: Hi all, Is there a way to quit mutt immediately when I'm in browser menu? Thanks in advance! Regards Ciao Joe, macro browser q exitquit will this do?
Exiting Mutt from browser menu
Hi all, Is there a way to quit mutt immediately when I'm in browser menu? Thanks in advance! Regards
Re: Exiting Mutt from browser menu
joe.on.l...@gmail.com wrote: Is there a way to quit mutt immediately when I'm in browser menu? uppercase Q is bound to quit. This will save changes to the mailbox and quit mutt. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA http://www.8t8.us/configs/gpg-key-transition-statement.txt signature.asc Description: PGP signature
Re: What does check-new in browser menu actually do?
At the risk of following up to myself (one foot in internet hell!), having done another little investigation, here's what I found. The code responsible for the check-new command is in browser.c, in functions _mutt_select_file (public) and examine_mailboxes (static). examine_mailboxes ultimately passes the job to mutt_buffy_check, but calls the latter with the force argument set to 0, which means nothing will happen unless the mailbox checking timeout has expired. Since this code executes in response to an explicit user request, this seems strange. What is the reason for not passing force = 1 here? -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
What does check-new in browser menu actually do?
I often spend lots of time in the browser view, in fact it is my default interface to mutt. When I get bored I hit the check-new key combo. I think I have never once seen new mail detected that way, though. When I get _really_ bored I hit the y key to return to the index of the last mailbox I was in. And lo, many times _immediately_ after doing that I see a buffy notification on the bottom telling me about new mail in other mailboxes. So, I have a sneaking suspicion that check-new doesn't do what it's supposed to, or else I quite misunderstand its purpose. I cannot get any more detail from the documentation; I could of course check the source code but I feel lazy today. Can the experts help? As a bonus question, why can't mutt automatically check for new mail in the background when it is in the browser, the same way as it does in the index? It's yet another irritating inconsistency. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: File browser oddity
On 2015-06-07 17:23 -0700, Ian Zimmerman wrote:
Ian When I start the file browser view explicitly, either by hitting
Ian the y key or by passing -y on the shell command line, it comes up
Ian in the mailboxes only submode, i.e. things like my header cache
Ian directory are hidden. (They can be shown by activating the
Ian toggle-mailboxes function, bound to Tab by default). But when I
Ian start by hitting c and then ?, so as to show the browser merely as
Ian a temporary menu of mailboxes to switch to, it comes up with all
Ian files visible and the toggle key hides the non-mailboxes.
Ian I find this a very annoying inconsistency. Is there some setting I
Ian can turn on to make it behave the same in both situations? I'd
Ian prefer the non-mailboxes always hidden by default, but even always
Ian shown would be better than the current way.
I think this is in fact a flea, a very small one, to be sure. Patch
attached, relative to 1.5.21; if needed I can certainly rebase it on a
different version.
--
Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.
diff --git a/curs_lib.c b/curs_lib.c
index 7f88cc9..6e4e76e 100644
--- a/curs_lib.c
+++ b/curs_lib.c
@@ -559,6 +559,7 @@ int mutt_do_pager (const char *banner,
int _mutt_enter_fname (const char *prompt, char *buf, size_t blen, int *redraw, int buffy, int multiple, char ***files, int *numfiles)
{
event_t ch;
+ int flags;
mvaddstr (LINES-1, 0, (char *) prompt);
addstr (_( ('?' for list): ));
@@ -577,8 +578,12 @@ int _mutt_enter_fname (const char *prompt, char *buf, size_t blen, int *redraw,
{
mutt_refresh ();
buf[0] = 0;
-_mutt_select_file (buf, blen, M_SEL_FOLDER | (multiple ? M_SEL_MULTI : 0),
- files, numfiles);
+flags = M_SEL_FOLDER;
+if (multiple)
+ flags |= M_SEL_MULTI;
+if (buffy)
+ flags |= M_SEL_BUFFY;
+_mutt_select_file (buf, blen, flags, files, numfiles);
*redraw = REDRAW_FULL;
}
else
Re: File browser oddity
Ian Zimmerman wrote: On 2015-06-07 17:23 -0700, Ian Zimmerman wrote: Ian When I start the file browser view explicitly, either by hitting Ian the y key or by passing -y on the shell command line, it comes up Ian in the mailboxes only submode, i.e. things like my header cache Ian directory are hidden. (They can be shown by activating the Ian toggle-mailboxes function, bound to Tab by default). But when I Ian start by hitting c and then ?, so as to show the browser merely as Ian a temporary menu of mailboxes to switch to, it comes up with all Ian files visible and the toggle key hides the non-mailboxes. Ian I find this a very annoying inconsistency. Is there some setting I Ian can turn on to make it behave the same in both situations? I'd Ian prefer the non-mailboxes always hidden by default, but even always Ian shown would be better than the current way. I think this is in fact a flea, a very small one, to be sure. Patch attached, relative to 1.5.21; if needed I can certainly rebase it on a different version. I think you're right. Let me just test it and I'll push the patch out. Thank you for investigating and writing up a patch! -Kevin -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA http://www.8t8.us/configs/gpg-key-transition-statement.txt signature.asc Description: PGP signature
Re: File browser oddity
Kevin J. McCarthy wrote: Ian Zimmerman wrote: On 2015-06-07 17:23 -0700, Ian Zimmerman wrote: Ian When I start the file browser view explicitly, either by hitting Ian the y key or by passing -y on the shell command line, it comes up Ian in the mailboxes only submode, i.e. things like my header cache Ian directory are hidden. (They can be shown by activating the Ian toggle-mailboxes function, bound to Tab by default). But when I Ian start by hitting c and then ?, so as to show the browser merely as Ian a temporary menu of mailboxes to switch to, it comes up with all Ian files visible and the toggle key hides the non-mailboxes. Ian I find this a very annoying inconsistency. Is there some setting I Ian can turn on to make it behave the same in both situations? I'd Ian prefer the non-mailboxes always hidden by default, but even always Ian shown would be better than the current way. I think this is in fact a flea, a very small one, to be sure. Patch attached, relative to 1.5.21; if needed I can certainly rebase it on a different version. I think you're right. Let me just test it and I'll push the patch out. Thank you for investigating and writing up a patch! After looking and thinking this through, it may be somewhat controversial to make this change. I've made a couple modifications and will mail the patch to mutt-dev, but really need more feedback before I consider pushing it. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA http://www.8t8.us/configs/gpg-key-transition-statement.txt signature.asc Description: PGP signature
Re: File browser oddity
Ian Zimmerman wrote: On 2015-06-08 15:55 -0700, Kevin J. McCarthy wrote: Kevin After looking and thinking this through, it may be somewhat Kevin controversial to make this change. I've made a couple Kevin modifications and will mail the patch to mutt-dev, but really Kevin need more feedback before I consider pushing it. Would you care to explain what your concerns are? The biggest one is changing long-standing behavior of a very often used function. Mutt users can be a conservative bunch, and this change could goof up macros or who knows what. My days could be numbered if I pushed it without entertaining any feedback first. :-) Also, the file browser didn't even work if no mailboxes were defined. I've changed it to not abort and display an empty list, but this could still be confusing to newish users, or even users who define no mailboxes and for whom it just worked in the past. You can redirect me to another forum if mutt-users is not appropriate. I've Cc'ed you on the post to mutt-dev. (Sorry about that if you're subscribed; I do see your signature). As I mentioned there, I *do* think the patch makes sense, but it may not be much liked by others. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA http://www.8t8.us/configs/gpg-key-transition-statement.txt signature.asc Description: PGP signature
Re: File browser oddity
On 2015-06-08 15:55 -0700, Kevin J. McCarthy wrote: Kevin After looking and thinking this through, it may be somewhat Kevin controversial to make this change. I've made a couple Kevin modifications and will mail the patch to mutt-dev, but really Kevin need more feedback before I consider pushing it. Would you care to explain what your concerns are? You can redirect me to another forum if mutt-users is not appropriate. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
File browser oddity
When I start the file browser view explicitly, either by hitting the y key or by passing -y on the shell command line, it comes up in the mailboxes only submode, i.e. things like my header cache directory are hidden. (They can be shown by activating the toggle-mailboxes function, bound to Tab by default). But when I start by hitting c and then ?, so as to show the browser merely as a temporary menu of mailboxes to switch to, it comes up with all files visible and the toggle key hides the non-mailboxes. I find this a very annoying inconsistency. Is there some setting I can turn on to make it behave the same in both situations? I'd prefer the non-mailboxes always hidden by default, but even always shown would be better than the current way. Thanks for any insight. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: display html email in browser?
* On Tue, Apr 28, 2015 12:09PM -0400 Peter P. (peterpar...@fastmail.com) muttered: Is there a way to have an html email rendered and displayed in a browser window? There used to be a page about that in the mutt wiki (wiki.mutt.org) though I cannot find it right now. In short: ~/.muttrc # i prefere text/plain thank you (show text part of multipart messages # rather then html alternative_order text/enriched text/plain text/html # this is needed for the autoview part in mailcap auto_view text/html ~/.mailcap # used when (v)iewing (use any browser you like) # text/html; w3m -v -F -T text/html '%s'; nametemplate=%s.html # text/html; /usr/bin/opera -newpage '%s'; test=test $DISPLAY != # text/html; /usr/bin/firefox -new-tab '%s'; test=test $DISPLAY != text/html; links2 -codepage utf8 '%s'; nametemplate=%s.html; needsterminal # for autoview text/html; lynx -stdin -dump -force_html ; copiousoutput; needsterminal HTH, Michael -- PGP-Key-ID: EEE7D043 Jabber: in...@jabber.de
Re: display html email in browser?
* Michael Tatge tatg...@gmail.com [2015-04-29 03:32]: * On Tue, Apr 28, 2015 12:09PM -0400 Peter P. (peterpar...@fastmail.com) muttered: Is there a way to have an html email rendered and displayed in a browser window? There used to be a page about that in the mutt wiki (wiki.mutt.org) though I cannot find it right now. In short: ~/.muttrc # i prefere text/plain thank you (show text part of multipart messages # rather then html alternative_order text/enriched text/plain text/html # this is needed for the autoview part in mailcap auto_view text/html ~/.mailcap # used when (v)iewing (use any browser you like) # text/html; w3m -v -F -T text/html '%s'; nametemplate=%s.html # text/html; /usr/bin/opera -newpage '%s'; test=test $DISPLAY != # text/html; /usr/bin/firefox -new-tab '%s'; test=test $DISPLAY != text/html; links2 -codepage utf8 '%s'; nametemplate=%s.html; needsterminal # for autoview text/html; lynx -stdin -dump -force_html ; copiousoutput; needsterminal HTH, Michael Thanks to all of you for posting your suggestions! It will take me a few days to catch up on your examples, which I am very eager to try out! regards, P
Re: display html email in browser?
On Tue, Apr 28, 2015 at 12:09:34PM -0400, Peter P. wrote: Dear fellow mutt users, Is there a way to have an html email rendered and displayed in a browser window? Hello Peter, once opened the message, press 'v' (view-attachments) and then select the .html one and press enter, that should auto-invoke x-www-browser.
Re: display html email in browser?
* Francesco Ariis fa...@ariis.it [2015-04-28 12:47]: On Tue, Apr 28, 2015 at 12:09:34PM -0400, Peter P. wrote: Dear fellow mutt users, Is there a way to have an html email rendered and displayed in a browser window? Hello Peter, once opened the message, press 'v' (view-attachments) and then select the .html one and press enter, that should auto-invoke x-www-browser. Thanks Francesco, That way the message gets displayed inside mutt using w3m. In my .muttrc I have set auto_view text/html application/x-pgp-message and text/html; /usr/bin/w3m -dump -T text/html '%s'; copiousoutput; description=HTML Text; nametemplate=%s.html as the corresponding mailcap entry. I wonder if I could pipe the html message part to the browser. The way I did it, typing | and specifying firefox as the program to pipe it to, did not really render it nicely. best, P
display html email in browser?
Dear fellow mutt users, Is there a way to have an html email rendered and displayed in a browser window? I tried saving the html message part to disk and opened that file, but there was no formatting, and some symbols were wrong. Motivation: Wanting to print a few html emails in their original form (in full glory), not rendered through w3m, but wanting to get rid of icedove/thunderbird, which I am keeping just for that. Thanks for ideas! P
Re: display html email in browser?
On 2015-04-28, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2015-04-28, Grant Edwards grant.b.edwa...@gmail.com wrote: Yep. What many of us do is use w3m to view inside mutt, and then define a 'print' command to view it externally: text/html; w3m -T text/html -dump; copiousoutput; print = firefoxurl %s; Uh, in case your crystal ball was broken, that's a line from ~/.mimecap. Aargh. it's .mailcap, not .mimecap. -- Grant Edwards grant.b.edwardsYow! Hand me a pair of at leather pants and a CASIO gmail.comkeyboard -- I'm living for today!
Re: display html email in browser?
On 2015-04-28, Grant Edwards grant.b.edwa...@gmail.com wrote: Yep. What many of us do is use w3m to view inside mutt, and then define a 'print' command to view it externally: text/html; w3m -T text/html -dump; copiousoutput; print = firefoxurl %s; Uh, in case your crystal ball was broken, that's a line from ~/.mimecap. -- Grant Edwards grant.b.edwardsYow! Is this an out-take at from the BRADY BUNCH? gmail.com
Re: display html email in browser?
Peter P. peterpar...@fastmail.com writes: * Francesco Ariis fa...@ariis.it [2015-04-28 12:47]: On Tue, Apr 28, 2015 at 12:09:34PM -0400, Peter P. wrote: Dear fellow mutt users, Is there a way to have an html email rendered and displayed in a browser window? Hello Peter, once opened the message, press 'v' (view-attachments) and then select the .html one and press enter, that should auto-invoke x-www-browser. Thanks Francesco, That way the message gets displayed inside mutt using w3m. In my .muttrc I have set auto_view text/html application/x-pgp-message and text/html; /usr/bin/w3m -dump -T text/html '%s'; copiousoutput; description=HTML Text; nametemplate=%s.html as the corresponding mailcap entry. I wonder if I could pipe the html message part to the browser. The way I did it, typing | and specifying firefox as the program to pipe it to, did not really render it nicely. You can definitely do this, but I suspect most browsers are not designed to accept input from stdin (a pipe). You can write a script to save the HTML part in a temp file, and then display that in the browser. There are actually a number of such scripts around if you Google it. -pd -- Peter Davis The Tech Curmudgeon www.techcurmudgeon.com
Re: display html email in browser?
On Tue, Apr 28, 2015 at 01:02:52PM -0400, Peter P. wrote: Thanks Francesco, That way the message gets displayed inside mutt using w3m. In my .muttrc I have set auto_view text/html application/x-pgp-message and text/html; /usr/bin/w3m -dump -T text/html '%s'; copiousoutput; description=HTML Text; nametemplate=%s.html as the corresponding mailcap entry. I wonder if I could pipe the html message part to the browser. The way I did it, typing | and specifying firefox as the program to pipe it to, did not really render it nicely. Mhhh I am a puzzled on why saving (or piping, for what matters) ends up in a corrupted result. Which symbols were wrong? Do you think you can share the .html attachment or at least a picture depicting the missing formatting?
Re: display html email in browser?
On 2015-04-28, Peter P. peterpar...@fastmail.com wrote:
* Francesco Ariis fa...@ariis.it [2015-04-28 12:47]:
On Tue, Apr 28, 2015 at 12:09:34PM -0400, Peter P. wrote:
Dear fellow mutt users,
Is there a way to have an html email rendered and displayed in a browser
window?
Hello Peter,
once opened the message, press 'v' (view-attachments) and then
select the .html one and press enter, that should auto-invoke
x-www-browser.
Thanks Francesco,
That way the message gets displayed inside mutt using w3m.
Yep. What many of us do is use w3m to view inside mutt, and then
define a 'print' command to view it externally:
text/html; w3m -T text/html -dump; copiousoutput; print = firefoxurl %s;
-firefoxurl
#!/bin/bash
MRC=firefox -remote
URL=$1
CMD=${2:-new-tab}
echo $0 '$1' '$2' /dev/tty
test -f $URL URL=file://$URL
expr match $URL '.*://.*' /dev/null || URL=http://$URL;
if $MRC 'ping()' 2/dev/null ; then
echo 'firefox already running'
echo $MRC openURL($URL,$CMD)
$MRC openURL($URL,$CMD)
else
echo 'firefox not running'
echo firefox $URL
firefox $URL
fi
---
So after you hit 'v' so see the attachments, select the html one and
hit 'p'
--
Grant Edwards grant.b.edwardsYow! Am I elected yet?
at
gmail.com
Re: display html email in browser?
On 2015-04-28, Peter P. peterpar...@fastmail.com wrote: Dear fellow mutt users, Is there a way to have an html email rendered and displayed in a browser window? I tried saving the html message part to disk and opened that file, but there was no formatting, and some symbols were wrong. I use muttils (https://bitbucket.org/blacktrash/muttils) for this very purpose. By default it maps, iirc, F7 to 'view in browser' and F8 to 'view safely in browser' i.e. don't download images, etc. This way I can still autoview html parts with w3m. hth, larry Motivation: Wanting to print a few html emails in their original form (in full glory), not rendered through w3m, but wanting to get rid of icedove/thunderbird, which I am keeping just for that. Thanks for ideas! P
Re: How to prevent file disappearing before browser sees it?
On Fri, Jan 23, 2015 at 11:14:52AM -0500, Jon LaBadie wrote: On Fri, Jan 23, 2015 at 11:56:19AM +, Chris Green wrote: On Fri, Jan 23, 2015 at 01:41:57AM -0600, David Champion wrote: * On 23 Jan 2015, Gary Johnson wrote: #!/bin/sh COPY=$1.firefox.html ln $1 $COPY /usr/bin/firefox $COPY I'm surprised that linking works because it used to be that mutt overwrote the temporary file with 0s before deleting it. I thought it still did, but I don't know for sure. You're right, it does overwrite (at least for most cases). I don't think this was always true, but it's been a very long time since I used mailcap this way, so I'm pretty distant. So a hard link won't work. OK, so I'll copy the file, not a big problem. If the copied file is put somewhere in /tmp then it'll get cleared away at the next reboot. You should be able to remove it in the script that copies it and starts firefox. If more than a process has a file open and the file is removed, only the directory entry is deleted. The inode and data blocks not freed until the last close is done. So you may be able to do something like: copy start firefox in background pause a second or two remove the copy exit (or issue a wait for firefox to complete) Yes, OK, I can do that. I have the script working OK now so that should be an easy addition. Thanks all. -- Chris Green
Re: How to prevent file disappearing before browser sees it?
* On 23 Jan 2015, Jon LaBadie wrote: You should be able to remove it in the script that copies it and starts firefox. If more than a process has a file open and the file is removed, only the directory entry is deleted. The inode and data blocks not freed until the last close is done. So you may be able to do something like: copy start firefox in background pause a second or two remove the copy exit (or issue a wait for firefox to complete) The trouble here is usually that /usr/bin/firefox is, itself, a wrapper. It typically passes a message to firefox (perhaps also launching firefox as a background process first) and then exits, so the real firefox might not actually read the file until after /usr/bin/firefox exits. This is how things used to be anyway -- maybe it's changed but I wouldn't expect so since this approach (while a bit messier) is more responsive to the user POV. -- David Champion • d...@bikeshed.us
Re: How to prevent file disappearing before browser sees it?
On Thu, Jan 22, 2015 at 04:56:35PM -0600, David Champion wrote: * On 22 Jan 2015, Chris Green wrote: [snip excellent explanation and solution] While I'm about it how do the two text/html entries in .mailcap work so that lynx is used by default but 'v' takes me to firefox? I would think you've got it already. Mutt will only use a copiousoutput entry for auto_view, and the first appropriate match otherwise. There are a number of ways to control what appropriate means though; see http://dev.mutt.org/doc/manual.html#advanced-mailcap Are you seeing something different? No, no, I was just asking how it worked and you have told me what I wanted. It's the copiousoutput that flags the method used by mutt's pager. Thanks (and for the snipped bit). -- Chris Green
Re: How to prevent file disappearing before browser sees it?
On Fri, Jan 23, 2015 at 01:41:57AM -0600, David Champion wrote: * On 23 Jan 2015, Gary Johnson wrote: #!/bin/sh COPY=$1.firefox.html ln $1 $COPY /usr/bin/firefox $COPY I'm surprised that linking works because it used to be that mutt overwrote the temporary file with 0s before deleting it. I thought it still did, but I don't know for sure. You're right, it does overwrite (at least for most cases). I don't think this was always true, but it's been a very long time since I used mailcap this way, so I'm pretty distant. So a hard link won't work. OK, so I'll copy the file, not a big problem. If the copied file is put somewhere in /tmp then it'll get cleared away at the next reboot. Confidentiality isn't a big issue, the only things I look at this way are adverts generally (and very few of them!). -- Chris Green
Re: How to prevent file disappearing before browser sees it?
On Fri, Jan 23, 2015 at 11:56:19AM +, Chris Green wrote: On Fri, Jan 23, 2015 at 01:41:57AM -0600, David Champion wrote: * On 23 Jan 2015, Gary Johnson wrote: #!/bin/sh COPY=$1.firefox.html ln $1 $COPY /usr/bin/firefox $COPY I'm surprised that linking works because it used to be that mutt overwrote the temporary file with 0s before deleting it. I thought it still did, but I don't know for sure. You're right, it does overwrite (at least for most cases). I don't think this was always true, but it's been a very long time since I used mailcap this way, so I'm pretty distant. So a hard link won't work. OK, so I'll copy the file, not a big problem. If the copied file is put somewhere in /tmp then it'll get cleared away at the next reboot. You should be able to remove it in the script that copies it and starts firefox. If more than a process has a file open and the file is removed, only the directory entry is deleted. The inode and data blocks not freed until the last close is done. So you may be able to do something like: copy start firefox in background pause a second or two remove the copy exit (or issue a wait for firefox to complete) Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
How to prevent file disappearing before browser sees it?
I usually automatically turn HTML mails into text using lynx and view them in the mutt pager but occasionally I view them in Firefox by hitting 'v' and then enter against the HTML part of the message. Thus my .muttrc file has:- auto_view text/html ... and my mailcap has:- text/html; /usr/bin/firefox %s text/html; lynx -dump %s; copiousoutput; nametemplate=%s.html The trouble is I'm frequently seeing the temporary HTML file saved by mutt disappearing before firefox gets to see it, why does this happen sometimes (almost all the time now)? It used to work OK. I have just moved to a faster computer, would this affect it? While I'm about it how do the two text/html entries in .mailcap work so that lynx is used by default but 'v' takes me to firefox? -- Chris Green
Re: How to prevent file disappearing before browser sees it?
* On 22 Jan 2015, Chris Green wrote: The trouble is I'm frequently seeing the temporary HTML file saved by mutt disappearing before firefox gets to see it, why does this happen sometimes (almost all the time now)? It used to work OK. I have just moved to a faster computer, would this affect it? Yes, it's a race condition. Mutt removes the file when it regains control of your terminal. /usr/bin/firefox is just a launcher - it will detach and background the real firefox executable and come back to mutt. If Firefox starts up slower than mutt finishes, the file will be missing. text/html; /usr/bin/firefox %s text/html; lynx -dump %s; copiousoutput; nametemplate=%s.html To solve this you need a wrapper script around Firefox. The wrapper will take the file content from $1 and save it somehow for Firefox, so that mutt may delete the original. There are various techniques for this. I personally like the approach of hard-linking the temp file so that it doesn't use more storage. Something like this: #!/bin/sh COPY=$1.firefox.html ln $1 $COPY /usr/bin/firefox $COPY But no matter what option you choose, your wrapper will then be responsible for removing the saved copy! The only difference to not having a wrapper at all is that now it doesn't matter how long you wait to remove the extra copy, whereas with no wrapper the time that you wait is the time that it takes to get mutt back. So something like this should generally work. You can append it to the above. # background a subshell to clean up later ( sleep 120 rm $COPY ) While I'm about it how do the two text/html entries in .mailcap work so that lynx is used by default but 'v' takes me to firefox? I would think you've got it already. Mutt will only use a copiousoutput entry for auto_view, and the first appropriate match otherwise. There are a number of ways to control what appropriate means though; see http://dev.mutt.org/doc/manual.html#advanced-mailcap Are you seeing something different? -- David Champion • d...@bikeshed.us
Re: How to prevent file disappearing before browser sees it?
On 2015-01-22, David Champion wrote: To solve this you need a wrapper script around Firefox. The wrapper will take the file content from $1 and save it somehow for Firefox, so that mutt may delete the original. There are various techniques for this. I personally like the approach of hard-linking the temp file so that it doesn't use more storage. Something like this: #!/bin/sh COPY=$1.firefox.html ln $1 $COPY /usr/bin/firefox $COPY I'm surprised that linking works because it used to be that mutt overwrote the temporary file with 0s before deleting it. I thought it still did, but I don't know for sure. Another place that you might look for solutions, Chris, is here: http://www.spocom.com/users/gjohnson/mutt/#background Regards, Gary
Re: How to prevent file disappearing before browser sees it?
* On 23 Jan 2015, Gary Johnson wrote: #!/bin/sh COPY=$1.firefox.html ln $1 $COPY /usr/bin/firefox $COPY I'm surprised that linking works because it used to be that mutt overwrote the temporary file with 0s before deleting it. I thought it still did, but I don't know for sure. You're right, it does overwrite (at least for most cases). I don't think this was always true, but it's been a very long time since I used mailcap this way, so I'm pretty distant. So a hard link won't work. -- David Champion • d...@bikeshed.us
Re: Viewing HTML in a real browser
On 2013-12-14, Chris Down ch...@chrisdown.name wrote: Occasionally I get complex HTML e-mails that don't quite work in w3m (which is what I have in my mailcap to view text/html). In these instances, I would like to be able to somehow view these in my browser. Right now my procedure is this: - Go to attach - Save the html part as /tmp/foo.html - Open my browser - Open file:///tmp/foo.html Is there some way I can automate this better, say, by being able to hit a key and have the HTML part of the message open in the browser? My browser is Chromium, but I think any generic solution should be adaptable. Thanks. While I was reading this thread, I remembered that, in the past, it was more frequent to see email messages as files under Microsoft Windows. I am not sure if it is exactly the same thing, but there is MHTML and Wikipedia says The content of an MHTML file is encoded as if it were an HTML e-mail message, using the MIME type multipart/related. While vanilla Firefox does not support MHTML out of the box, I tried https://addons.mozilla.org/en-US/firefox/addon/unmht/ which is indeed able to render email messages with embedded pictures (you may need to add the .mht extension to the file, I'm not sure about this). I don't know if there is something similar for Google Chrome, but I thought this could help, at least, Firefox users. -- Nuno Silva (aka njsg) Helsinki, Finland
Re: charset in html in external browser
Hi Christian, Am Sonntag, den 28. Dezember 2014 um 09:25:27 Uhr (+) schrieb Christian Ebert: Images should be displayed, and do so for me[tm] - unless one uses the --safe option where remotely loaded images are not. I'd need an example HTML message to check. everything ist ok, it was my fault. The images weren't displayed as I wasn't aware that I was offline when testing. Happy New Year! Orm
