Re: Creating HTML emails with mutt
On Tue, Oct 29, 2019 at 12:41:44PM +1300, martin f krafft wrote: Script output would be the content-type, a blank line, then the generated content. This makes me itch, but I cannot really devise a better approach. I want to say that the script needs to return the complete MIME part, including Content-Transfer-Encoding and other headers, or are you confident that Mutt can deduce all these parameters from the generated content? The part creation (and removal) will be in Mutt's pipeline, and so will follow normal processing that Mutt does. That include encoding, delimiters, charset conversion, etc. So I would like the script to simply produce the HTML (or PDF, or whatever) output, without trying to "mailify" the output. I think it would be okay for a charset to optionally be included in the content-type. I have to think about whether to force-charset in that case, or still respect $send_charset. But I don't think allowing other headers would help. Mutt can determine the best content-encoding, and I think it's fair to set disposition to inline. If the approach turns out to be insufficient, we can add features. Reusing as a template would be resolved if we kept a local record of the messages without the generated content, similar to how `$fcc_attach` removes the attachments before storing. For this iteration, I didn't plan on going here. $fcc_attach would still just remove attachments, the main content would be stored as it were generated (i.e. including multipart/alternatives). Maybe in the next iteration I could add an option to strip the alternative. However — and I just experienced this — forwarding a message as attachment now means that it'll be plain-text only. Yes, this is one of the places I need to look at. My plan is the simplest, as you mentioned: discard the alternative when generating anything that goes through the compose menu. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
Matthias Apitz writes: > So, run mutt in an unicode-rxvt terminal. It presents URLs underlined > and click-able. I do so and sometimes I do hate it: you click into your Definitely not by default. I'm using rxvt-unicode, and I've tried the "matcher" and "selection" extensions but neither one worked for selecting multiline URLs. Do you know one that does? I only recently switched to urxvt and I've been surprised at how bad it is at URL selection compared to xterm (xterm has charClass and cutChars resources you can configure that work very well for URLs). I get the impression the mutt pager breaks long URLs anyway, which makes it harder for a terminal to select them. It would be great to have an option not to break them and just let the terminal wrap them (I know that makes it harder to predict how many lines the display is). If we're counting votes, I'm another longtime mutt fan who'd love to be able to compose and send simple HTML messages. There are lots of options for displaying incoming HTML messages -- none of them are perfect, e.g. the link-clicking problem, but they're okay -- but replying to HTML messages in mutt without losing all the formatting is much more difficult. I spent a week or so several years ago and never managed it (I ended up writing a python script for the once or twice a year when I really need to send HTML mail) so I'm reading this thread with interest to see what solutions other people come up with. ...Akkana
Re: Opening URLs from mutt (was: Creating HTML emails with mutt)
Regarding the following, written by “雨宫恋叶” on 2019-10-29 at 00:41 Uhr +: For this, I think we should design a pager for that purpose. Urlview could probably be extended accordingly. It’d still be disruptive. Imagine reading a long email, and 75% down you encounter a link you want to follow. If you now fire up the external pager, it won’t be scrolled to the right location in the email, so you’d first have to find that paragraph first… -- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "literature always anticipates life. it does not copy it, but moulds it to its purpose. the nineteenth century, as we know it, is largely an invention of balzac." -- oscar wilde spamtraps: madduck.bo...@madduck.net
Re: Opening URLs from mutt (was: Creating HTML emails with mutt)
October 29, 2019 8:38 AM, "martin f krafft" wrote: > Regarding the following, written by "Dave Woodfall" on 2019-10-29 at 00:10 > Uhr +: > >> Urlview handles long and short links just fine. I've been using it >> for over 10 years. > > Yes, it does. I think Chris' and José's points were more about > requiring an external tool to provide functionality which has become > so core to everyday email use that mutt could learn to do it. > > Urlview also obstructs your view to context when using it. I've > opened it a million times only to find myself staring at a list of > tracking URLs that all look the same, now knowing which one appeared > in the paragraph I was just reading. Mutt could do a much better > job, with a UI/UX similar to what rxvt-unicode offers (but cannot > due to ncurses…), i.e.: > > 1. enter URL selection mode; > 2. use arrow keys to select the URL you want, while the message is > being shown; > 3. press enter to fire up mailcap handler. For this, I think we should design a pager for that purpose. -- 旋转少女
Re: Creating HTML emails with mutt
El día lunes, octubre 28, 2019 a las 06:33:19p. m. -0400, José María Mateos escribió: > On Mon, Oct 28, 2019 at 11:11:31PM +0100, Matthias Apitz wrote: > >Well, do you speak for you or for a 'lot of people'? Who they are? > >I speak only for my own interests (as I said: I do not need this). > > Talking for myself, I really don't need point 1 (composing of HTML > messages), but number 2, opening links in an easy way, would be a nice > to have. I can always user urlview or send the HTML file to Firefox, but > any of these solutions is slower than simply being able to somehow tell > mutt "open URL #12 from this e-mail", and have that sent to the web > browser. So, run mutt in an unicode-rxvt terminal. It presents URLs underlined and click-able. I do so and sometimes I do hate it: you click into your terminal to get the focus to it, or even as an accident, and hit an URL and it jumps off to FF. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php
Re: Opening URLs from mutt (was: Creating HTML emails with mutt)
Regarding the following, written by "Dave Woodfall" on 2019-10-29 at 00:10 Uhr +: Urlview handles long and short links just fine. I've been using it for over 10 years. Yes, it does. I think Chris' and José's points were more about requiring an external tool to provide functionality which has become so core to everyday email use that mutt could learn to do it. Urlview also obstructs your view to context when using it. I've opened it a million times only to find myself staring at a list of tracking URLs that all look the same, now knowing which one appeared in the paragraph I was just reading. Mutt could do a much better job, with a UI/UX similar to what rxvt-unicode offers (but cannot due to ncurses…), i.e.: 1. enter URL selection mode; 2. use arrow keys to select the URL you want, while the message is being shown; 3. press enter to fire up mailcap handler. -- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "never attribute to malice what can be adequately explained by incompetence." -- mark twain spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Creating HTML emails with mutt
El día martes, octubre 29, 2019 a las 11:19:43a. m. +1300, martin f krafft escribió: > Regarding the following, written by "Matthias Apitz" on 2019-10-28 at 23:11 > Uhr +0100: > >Well, do you speak for you or for a 'lot of people'? Who they are? > >I speak only for my own interests (as I said: I do not need this). > > Matthias, any such feature would of course be optional, and probably > default to off for a long time, so you have nothing to worry about. I don't worry about this. I only do not like people expressing their own interests with a 'lot of people demand xyz'. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php
Re: Creating HTML emails with mutt
> 2. The ability to natively display a subset of HTML (the same subset) >with the ability to trigger links to open in a browser (or perhaps >execute an arbitrary configured command). Modern terminal windows >can handle all of the formatting required to do just this much... elinks -dump can display HTML using autoview, or it can be bound to run manually too, in its normal browser manner. urlview can open links in plain text messages. -- LIGHTHOUSE: A tall building on the seashore in which the government maintains a lamp and the friend of a politician.
Re: Opening URLs from mutt (was: Creating HTML emails with mutt)
On Tue, Oct 29, 2019 at 00:10:09 +, Dave Woodfall wrote: > Urlview handles long and short links just fine. I've been using it > for over 10 years. One issue I have with it is that context is lost. Marketing emails today tend to be massive strings with embedded IDs in them. Telling one from another in urlview means I'm bouncing back and forth between it and the message (or having 2 mutt instances to coordinate). Other than that, I really enjoy urlview. I even have a binding in tmux to this script: #!/bin/sh [ -z "$TMUX" ] && exit 1 tempfile="$( mktemp )" tmux capture-pane tmux save-buffer "$tempfile" tmux delete-buffer tmux new-window -n urlview "urlview $tempfile; rm $tempfile" which allows me to have wrapped lines work even with vertical splits (which confuses the terminal just like the sidebar does). --Ben
Re: Opening URLs from mutt (was: Creating HTML emails with mutt)
On Tue 29 Oct 2019 12:04,
martin f krafft put forth the proposition:
> Regarding the following, written by "Chris Green" on 2019-10-28 at 22:40 Uhr
> +:
> > Isn't that handled by your terminal program? Mine certainly allows
> > one to right click on any URL to open it.
>
> rxvt-unicode also has an extension ("matcher") that allows you to select
> and open URLs using the keyboard only.
>
> However, when URLs wrap across lines, things often break, and especially
> when you have the sidebar shown, then your terminal emulator has no way to
> make sense of the URL anymore. Mutt, however, does know about message
> contents, and can interpret line breaks much better.
Urlview handles long and short links just fine. I've been using it
for over 10 years.
-dw
--
Under a government which imprisons any unjustly, the true place for a
just man is also a prison.
-- Henry David Thoreau
Re: Creating HTML emails with mutt
Hi Kevin, Thanks for sharing your thoughts and plans on this. This all reads really well, and I think it would go most of the way towards the ideal solution. I have a couple of points/questions about some of the things you propose: If there were an error sending, the alternative would be stripped before returning to the compose menu. So it would not be exposed to the compose menu. I *might* add a function to preview the output as raw text and via mime from the compose menu though. The ability to preview sounds great, and I would greatly appreciate it. Script output would be the content-type, a blank line, then the generated content. This makes me itch, but I cannot really devise a better approach. I want to say that the script needs to return the complete MIME part, including Content-Transfer-Encoding and other headers, or are you confident that Mutt can deduce all these parameters from the generated content? Anyway, that's my current plan. The problem is cleaning up some other parts of mutt to deal with bouncing, reuse as a template, etc. Reusing as a template would be resolved if we kept a local record of the messages without the generated content, similar to how `$fcc_attach` removes the attachments before storing. However — and I just experienced this — forwarding a message as attachment now means that it'll be plain-text only. Processing a message to be attached, or a message to be bounced, seems to me like a really bad idea, especially since it should only ever be applied to messages that were locally authored. Maybe this would mean storing with the locally recorded message a little bit of metadata suggesting that Mutt generated an alternative part for this message when it was sent? Yeah, this can get ugly fast, and maybe the right way forward is instead to store the generated content when saving a message locally, but to teach Mutt to discard any multipart/alternative non-text/plain part when reusing a message as a template, similarly to how that part is discarded on error before it's returned to the compose menu? Best regards, -- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net the english take english for granted. but if we explore its paradoxes, we find that quicksand can work slowly. spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Opening URLs from mutt (was: Creating HTML emails with mutt)
Regarding the following, written by "Chris Green" on 2019-10-28 at 22:40 Uhr
+:
Isn't that handled by your terminal program? Mine certainly allows
one to right click on any URL to open it.
rxvt-unicode also has an extension ("matcher") that allows you to
select and open URLs using the keyboard only.
However, when URLs wrap across lines, things often break, and
especially when you have the sidebar shown, then your terminal
emulator has no way to make sense of the URL anymore. Mutt, however,
does know about message contents, and can interpret line breaks much
better.
--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
"syntactic sugar causes cancer of the semicolon."
-- epigrams in programming
spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Creating HTML emails with mutt
On Mon, Oct 28, 2019 at 10:40:16PM +, Chris Green wrote: Isn't that handled by your terminal program? Mine certainly allows one to right click on any URL to open it. Not if the URL spans several lines. I think it's a common issue across several terminal programs and last time I read about it I think it's due to the way mutt handles URLs, but perhaps I'm mistaken. -- José María (Chema) Mateos || https://rinzewind.org/
Re: Creating HTML emails with mutt
On Mon, Oct 28, 2019 at 06:33:19PM -0400, José María Mateos wrote: > On Mon, Oct 28, 2019 at 11:11:31PM +0100, Matthias Apitz wrote: > > Well, do you speak for you or for a 'lot of people'? Who they are? > > I speak only for my own interests (as I said: I do not need this). > > Talking for myself, I really don't need point 1 (composing of HTML > messages), but number 2, opening links in an easy way, would be a nice to > have. I can always user urlview or send the HTML file to Firefox, but any of > these solutions is slower than simply being able to somehow tell mutt "open > URL #12 from this e-mail", and have that sent to the web browser. > Isn't that handled by your terminal program? Mine certainly allows one to right click on any URL to open it. -- Chris Green
Re: Creating HTML emails with mutt
On Mon, Oct 28, 2019 at 11:11:31PM +0100, Matthias Apitz wrote: Well, do you speak for you or for a 'lot of people'? Who they are? I speak only for my own interests (as I said: I do not need this). Talking for myself, I really don't need point 1 (composing of HTML messages), but number 2, opening links in an easy way, would be a nice to have. I can always user urlview or send the HTML file to Firefox, but any of these solutions is slower than simply being able to somehow tell mutt "open URL #12 from this e-mail", and have that sent to the web browser. Cheers, -- José María (Chema) Mateos || https://rinzewind.org/
Re: Creating HTML emails with mutt
Regarding the following, written by "Matthias Apitz" on 2019-10-28 at 23:11 Uhr +0100: Well, do you speak for you or for a 'lot of people'? Who they are? I speak only for my own interests (as I said: I do not need this). Matthias, any such feature would of course be optional, and probably default to off for a long time, so you have nothing to worry about. -- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "if they can get you asking the wrong questions, they don't have to worry about answers." -- thomas pynchon spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Creating HTML emails with mutt
El día lunes, octubre 28, 2019 a las 04:50:40p. m. -0500, Derek Martin escribió: > > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks > > Perhaps not, but the fact that it keeps coming up here is pretty clear > indication that it's a feature that would be useful to a lot of > people... Well, do you speak for you or for a 'lot of people'? Who they are? I speak only for my own interests (as I said: I do not need this). matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php
Re: Creating HTML emails with mutt
On Mon, Oct 28, 2019 at 10:06:18PM +0100, Matthias Apitz wrote: > El día lunes, octubre 28, 2019 a las 03:59:01p. m. -0500, Derek Martin > escribió: > > > FWIW, my two biggest wishlist items for Mutt are: > > > > 1. the ability to create and send at least simple HTML messages, with > >or without multipart alternatives, specifically for basic text > >formatting (bold, italics, color) and hypertext links. [It's > >expected that an external HTML editor would need to be spawned to > >generate the HTML. It makes sense to be able to specify a filter > >to convert this to an alternative form for multipart.] > > > > 2. The ability to natively display a subset of HTML (the same subset) > >with the ability to trigger links to open in a browser (or perhaps > >execute an arbitrary configured command). Modern terminal windows > >can handle all of the formatting required to do just this much... > > > > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks Perhaps not, but the fact that it keeps coming up here is pretty clear indication that it's a feature that would be useful to a lot of people... -- 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: Creating HTML emails with mutt
El día lunes, octubre 28, 2019 a las 03:59:01p. m. -0500, Derek Martin escribió: > FWIW, my two biggest wishlist items for Mutt are: > > 1. the ability to create and send at least simple HTML messages, with >or without multipart alternatives, specifically for basic text >formatting (bold, italics, color) and hypertext links. [It's >expected that an external HTML editor would need to be spawned to >generate the HTML. It makes sense to be able to specify a filter >to convert this to an alternative form for multipart.] > > 2. The ability to natively display a subset of HTML (the same subset) >with the ability to trigger links to open in a browser (or perhaps >execute an arbitrary configured command). Modern terminal windows >can handle all of the formatting required to do just this much... > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub 3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 aus: https://www.jungewelt.de/2019/10-02/index.php signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
On Sun, Oct 27, 2019 at 10:02:38AM +0800, Kevin J. McCarthy wrote: > On Sat, Oct 26, 2019 at 11:16:25AM +1300, martin f krafft wrote: > Native support for multipart/alternative composition isn't in my todo list. > However, I do have a plan to allow external filter generation of the > alternative. Originally, this was on my list for the next development > cycle, but let me see what I can do before the 1.13 release. > > The current idea is a quadaption (names may change, but...) > $compose_multipart_alternative combined with a script > $compose_multipart_alternative_script. FWIW, my two biggest wishlist items for Mutt are: 1. the ability to create and send at least simple HTML messages, with or without multipart alternatives, specifically for basic text formatting (bold, italics, color) and hypertext links. [It's expected that an external HTML editor would need to be spawned to generate the HTML. It makes sense to be able to specify a filter to convert this to an alternative form for multipart.] 2. The ability to natively display a subset of HTML (the same subset) with the ability to trigger links to open in a browser (or perhaps execute an arbitrary configured command). Modern terminal windows can handle all of the formatting required to do just this much... While I still mostly prefer plain text for its brevity, being able to provide emphasis and other basic formatting is nice. It's hard to deny that HTML mail has become the defacto standard for most people, and I think Mutt really falls short in its ability to handle this stuff out of the box. -- 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: File locking on sshfs file system, possible?
On Mon, Oct 28, 2019 at 07:29:52PM +, Chris Green wrote: > On Mon, Oct 28, 2019 at 01:31:57PM -0500, Derek Martin wrote: > > You're probably better off using (local) IMAP over SSH with your Mutt > > mailboxes. That is, you can ssh into your mail server and run imapd > > locally (rather than having it listen to incoming connections), and > > Mutt supports this. > > > I've never got on well with IMAP and mutt. But have you tried running it locally over SSH? There are a lot of factors that matter (and I admit I don't use it, but I don't really deal with attachments much), but when I tried it I found it was a very different animal than network-based IMAP. It has different performance tradeoffs and benefits/drawbacks. If you haven't tried it, I would highly encourage you to do so. You do still have to transfer your messages and attachments over SSH (but you were doing that anyway), but you do get to display them locally, which makes a lot of difference. Or can, depending on your exact usage patterns. I think it may get you most of what you want, and if so you may be able to throw away any hacking you've done to deal with your 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. signature.asc Description: PGP signature
Re: File locking on sshfs file system, possible?
On Mon, Oct 28, 2019 at 01:31:57PM -0500, Derek Martin wrote:
> On Fri, Oct 25, 2019 at 08:58:06AM +0100, Chris Green wrote:
> > I just tried running mutt 'remotely' by mounting ~/.muttrc and my main
> > mail directory ~/Mail using sshfs and running a local copy of mutt.
> > This makes handling attachments and HTML E-Mail much faster and easier
> > than running mutt on the remote system via ssh.
>
> SSHFS is a horrible hack (albeit a clever one that has many
> convenient uses). Unfortunately I've forgotten the details, but I
> know that several important file system semantics do not work
> with it, and IMO you should not use this for anything you consider
> important that needs reliability.
>
I've decided that sshfs isn't going to provide what I want.
> You're probably better off using (local) IMAP over SSH with your Mutt
> mailboxes. That is, you can ssh into your mail server and run imapd
> locally (rather than having it listen to incoming connections), and
> Mutt supports this.
>
I've never got on well with IMAP and mutt.
I've discovered that I can extend my existing hack/bodge/clever script
that I already use for viewing HTML mails using Firefox (when simply
using lynx isn't good enough).
What I do for HTML to Firefox is to have a script that is called
(using ~/.mailcap) to copy the HTML E-Mail to my web server's
DocumentRoot and then run Firefox to view the file. This works for a
remote 'connected by ssh' client as well as locally because Firefox
uses a remote Firefox to display the file. Thus I get to view the
HTML in a local Firefox (i.e. on the ssh client) and, as I have copied
the file back to the client (using rsync) it all works fast and locally.
What I then realised was that Firefox can view PDFs and JPGs and
similar so the same can be done for viewing PDF and JPG attachments
'locally' on the remote ssh client. It works too! :-)
My ~/.mailcap (on the machine where mutt is running) has:-
text/html; /home/chris/bin/muttfox %s
text/html; lynx -dump %s; copiousoutput; nametemplate=%s.html
application/pdf; /home/chris/bin/muttfox %s
image/jpeg; /home/chris/bin/muttfox %s
... and the script muttfox is:-
#!/bin/bash
#
#
# muttfox: script called by mutt via mailcap to use firefox to view HTML,
and
# also some types attachments, currently:- PDF, JPG
#
# It is necessary for HTML files because /usr/bin/firefox exits
# before firefox has actually loaded the HTML file, this is especially
# true when it's remote but it also happens when running locally.
#
# It's not actually necessary for PDF and JPG files but it speeds up
# remote (i.e. running mutt via ssh) viewing considerably because it
# doesn't run the viewing program across the X connection. It works
# OK for local files so everything works the same.
#
# The temporary file to be viewed by Firefox is copied to directory
# /srv/mutt on esprimo if running locally or to the same place on the
# remote system if running via ssh. The copy to the remote system is
# done via an ssh reverse tunnel on port 50022 using a passwordless key
# and rrsync at the remote end to make it reasonably secure.
#
dir=/srv/mutt/
#
#
# if there's no DISPLAY variable then Firefox can't run, so skip the whole
thing
#
if [ -n "$DISPLAY" ]
then
chmod 0644 $1
if [ -n "$SSH_CLIENT" ]
then
rsync -e 'ssh -p 50022 -i /home/chris/.ssh/np_id_rsa' $1
localhost:$(basename $1)
else
cp $1 $dir$(basename $1)
fi
/usr/bin/firefox http://localhost/mutt/$(basename $1)
fi
#
#
# Clear out any old files left by this script, doing it here saves adding
# a special crontab task
#
find $dir -mtime +7 -exec rm {} \;
It works beautifully so now I can view PDF and other attachments
'fast' when I'm running mutt via ssh. I have to wait for the file to
copy but once that has happened scrolling, searching, etc. all work as
with a local file (which it is of course). It just relies on
Firefox's ability to view various file formats (or to find a program
that will do it).
--
Chris Green
Re: File locking on sshfs file system, possible?
On Fri, Oct 25, 2019 at 08:58:06AM +0100, Chris Green wrote: > I just tried running mutt 'remotely' by mounting ~/.muttrc and my main > mail directory ~/Mail using sshfs and running a local copy of mutt. > This makes handling attachments and HTML E-Mail much faster and easier > than running mutt on the remote system via ssh. SSHFS is a horrible hack (albeit a clever one that has many convenient uses). Unfortunately I've forgotten the details, but I know that several important file system semantics do not work with it, and IMO you should not use this for anything you consider important that needs reliability. You're probably better off using (local) IMAP over SSH with your Mutt mailboxes. That is, you can ssh into your mail server and run imapd locally (rather than having it listen to incoming connections), and Mutt supports this. -- 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
