Re: Can index lines be wrapped?

[nunojsilva]

On 2021-08-13, Cameron Simpson wrote:

> On 13Aug2021 08:17, Chris Green  wrote:
>>On Fri, Aug 13, 2021 at 08:15:26AM +0200, Alexander Dahl wrote:
>>> On Thu, Aug 12, 2021 at 08:30:11AM +0100, Chris Green wrote:
>>> > I read my mail (via ssh) on quite a variety of devices, one is an
>>> > Android phone running termux which has rather short lines which
>>> > truncate much of the subject in index view.
>>> >
>>> > I could rearrange the index_format but that would change it for all my
>>> > viewing devices and I don't really want to do that, and anyway I'd
>>> > still lose some information.
>>>
>>> What about a macro or shortcut to toggle between different settings?
>>>
>>That's possible but it's just one more thing that one has to to
>>manually which isn't really necessary.
>
> I always invoke via a script (named "+") which has assorted 
> figure-it-out logic before invoking mutt. You could sniff the terminal 
> size and choose a narrower index_format for narrow terminals. (_And_ 
> bind that to a keyboard toggle macro as well if you wanted.)
>
> I've got a ttysize script which does this:
>
> stty -a  | sed -n '
>   s/.* rows \([0-9][0-9]*\); columns \([0-9][0-9]*\).*/\2 \1/p
>   t
>   s/.*; *\([0-9][0-9]*\) rows; *\([0-9][0-9]*\) columns.*/\2 \1/p
>   t'
>
> but I'm sure there must be a more direct way.
>
> Anyway, given the tty width you could make a choice about index_format.
>
> Cheers,
> Cameron Simpson 
>

I've had this problem with gpg key selection menus. Customizing a format
probably didn't occur to me when I asked about this in 2018[0], but,
looking at manual.txt, I should try customizing pgp_entry_format.

While changing formats will help mitigating the problem, I expect it to
resurface occasionally. I wonder if there's anything that could be done
in general to avoid truncated lines or to make these readable - either
allowing left-right scroll or having a "line-wrap mode" for indices?

(Or is one of these a mutt feature I haven't learned about yet?)

[0] news://news.gmane.io/pq6sad$sp4$1...@blaine.gmane.org
or http://marc.info/?i=pq6sad$sp4$1...@blaine.gmane.org

-- 
Nuno Silva

Re: Color display question

[nunojsilva]

On 2021-07-21, isdtor wrote:

> I realize my config has a lot of moving parts and non-default
> settings, but I still hope someone can shine a light on this.
>
> I use less instead of the internal pager (note -R option),
>
> set pager="less -eiMR"
>
> and elinks for html display
>
> text/html; /usr/bin/elinks -localhost 1 -no-connect 1 -force-html
> -dump '%s' ; copiousoutput
>
> The terminal is gnome-terminal which defaults to TERM=xterm, supports
> 80 colors according to tput, and muttrc sources a terminal-specific
> file with color settings the original source of which I don't
> remember.
>
> color header  red black  .* # (match regexp in the message header)
> color header  yellow black  ^To: # (match regexp in the message header)
> color header  green black  ^Subject: # (match regexp in the message 
> header)
> color index   white black .* # index
> color indicator   white  blue   # index
> color markers redgreen  # `+' markers at beginning of wrapped lines
> color message white black
> color normal  white  black  # pager body
>
> Sometimes I receive email with text emphasized by color, say, yellow
> background. The described setup, while coloring the index view, shows
> all text in monochrome, so I'm missing some information and need to
> open the message in firefox.
>
> elinks can handle color, so I added this setting to ~/elinks/elinks.conf
>
> set document.dump.color_mode = 4
>
> The result is that when a html message is viewed, the headers continue
> to be shown normally - white background, black text - but the message
> text is now less readable with white background and light grey
> text. Any highlighted text is displayed in black with grey background
> (not matching background-color style from the html source, but I can
> lvie with that).
>
> The main problem is that the text is light grey, which is barely
> readable on white background. Any idea where I can tweak this? My
> first guess was this is controlled by less, but I played with various
> settings for LESS_TERMCAP_md, with no tangible results.

I think that might be elinks. I'm not sure about what all the relevant
options are, but document.colors.text (default foreground) may be what
is giving you light gray text. You probably also want
document.colors.use_document_colors to be 2 and document.css.enable to
be enabled (1)?

-- 
Nuno Silva

Re: IMAP authentication in one domain (my institution) and redirect to Gmail

[nunojsilva]

On 2020-08-12, Marcelo Laia wrote:

> On 12/08/20 at 11:18, Nuno Silva wrote:
>> 
>> ls -l /home/myuser/.oauth2token
>> 
>
>
> myuser@myuser:~$ ls -l /home/myuser/.oauth2token 
> -rwxr-xr-x 1 myuser myuser 1957 ago 11 21:58 /home/myuser/.oauth2token
> myuser@myuser:~$ 
>
> myuser@myuser:~$ ls -l /home/myuser/.oauth2.py
> -rwxr-xr-x 1 myuser myuser 12616 ago 11 11:15 /home/myuser/.oauth2.py
> myuser@myuser:~$

Then lacking permissions in the filesystem isn't it.

This is reminding me of your issues (apparmor-related, IIRC?) when
opening evince from mutt. If your system still has apparmor running,
could that possibly be the cause in this case as well?

-- 
Nuno Silva

Re: IMAP authentication in one domain (my institution) and redirect to Gmail

[nunojsilva]

On 2020-08-12, Marcelo Laia wrote:

[...]
>
> My msmtprc is like this:
>
> account YZYZYZ
> host smtp.gmail.com
> from mylo...@yzyzyz.edu.br
> port 587
> protocol smtp
> tls on
> tls_trust_file /etc/ssl/certs/ca-certificates.crt
> auth oauthbearer
> user mylo...@yzyzyz.edu.br
> passwordeval /home/myuser/.oauth2token mylo...@yzyzyz.edu.br YZYZYZ
>
> However, when I try to send a message, I got:
>
> sh: 1: /home/myuser/.oauth2token: Permission denied
> msmtp: was not possible to read the stdout from
> "/home/myuser/.oauth2token mylo...@yzyzyz.edu.br YZYZYZ"

I have not used anything like this so far, but my guess would be that
.oauth2token is lacking the execute permission.

What is the output of

ls -l /home/myuser/.oauth2token

?

-- 
Nuno Silva

Re: Creating HTML emails with mutt

[nunojsilva]

On 2019-10-29, martin f krafft wrote:

[...]
> Society has moved on, and we all risk sounding like grumpy old folks
> reminiscing at the times when everyone knew what netiquette was if we
> don't embrace the progress that's been happening around us. And
> text/html is part of that progress, whether you like it or not.
>
> If we don't embrace progress, then mutt will not have any users in a
> decade or two.

There are users who don't need text/html. It's okay to want some way to
use HTML for e-mail in mutt, but I'd say it's not okay to say everybody
needs it.

-- 
Nuno Silva

Re: Creating HTML emails with mutt

[nunojsilva]

On 2019-10-29, John Long wrote:

> On Tue, 29 Oct 2019 14:50:05 -0400
> Patrick Shanahan  wrote:
>
>> * Grant Edwards  [10-29-19 13:10]:
[...]
>> > Muttdown (a "sendmail" filter) which creates mutlipart alternative
>> > html/text messages is the only reason I've been able to continue to
>> > use mutt for the past 5-6 years.  About 90% of the people to whom I
>> > send email can't deal with plaintext only. The display of plaintext
>> > is butchered horribly by Outlook, 
>
> This is sadly, absolutely true. It's beyond frustrating to format an
> email carefully in ASCII text and then have it look like a telegram
> from Charles Manson by the time Outlook is done with it.
[...]

What about composing html in the text editor and changing the
content-type to text/html with ^T in mutt?

It might be inconvenient for more complex messages, but could perhaps
help in these cases where you're sending something that would otherwise
go as plain text to Outlook users.

-- 
Nuno Silva

Re: Really strange problem with evince PDF reader and .mutt directory

[nunojsilva]

On 2019-10-21, Chris Green wrote:

> On Sun, Oct 20, 2019 at 05:08:01PM -0400, Nathan Stratton Treadway wrote:
>> On Sun, Oct 20, 2019 at 18:04:05 +0100, Chris Green wrote:
>> > I just removed apparmor from one of my systems (I can see no use for
>> > it anyway), I still get the error with evince.
>> 
>> I'm not using Ubuntu 19.04 myself and so can't say whether or not your
>> problem is caused by Apparmor, but if you just did "apt-get remove
>> apparmor" to remove the package, I'm not sure that operation actually
>> disables Apparmor enforcement.
>> 
> Well, I did "apt purge apparmor" and I also removed two other packages
> with apparmor in the name.
>
>
>> (That is, at least on my Bionic/18.04 system, with a quick look through
>> the /var/lib/dpkg/info/apparmor.{pre,post}rm scripts I'm not seeing
>> seeing any logic to turn off enforcement during a package-remove
>> operation.)
>> 
>> So, you may still want to look closely in your system log files to see
>> if there are any Apparmor access-denied messages, just in case removing
>> the package isn't enough to eliminate the evince-profile restriction
>> 
> No, nothing logged at all but I'm still getting the Permission Denied.

If you did not reboot, apparmor might still be running, try stopping the
"apparmor" service, see:
https://help.ubuntu.com/community/AppArmor#Disable_AppArmor_framework

-- 
Nuno Silva

Re: Really strange problem with evince PDF reader and .mutt directory

[nunojsilva]

On 2019-10-20, Marcelo Laia wrote:

> On 20/10/19 at 02:02, Nuno Silva wrote:
>  
>> Do these systems have apparmor? It seems to be some sort of security
>> tool which restricts access to files and directories based on rules.
>
>
> Bingo
>
> root@marcelo:~# dpkg -l apparmor
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Nome   Versão   Arquitectura Descrição
> +++-==---==
> ii  apparmor   2.13.3-5 amd64user-space parser utility for 
> AppArmor
> root@marcelo:~# 

By the way: it seems that the .mutt rule was added to the apparmor
upstream repository during November 2018[1], which would explain why
this is something that didn't happen before.

[1] 
https://gitlab.com/apparmor/apparmor/commit/170e8d6ac8eb867d40f3361e1814b2304d647860

-- 
Nuno Silva

Re: Really strange problem with evince PDF reader and .mutt directory

[nunojsilva]

On 2019-10-20, José María Mateos wrote:

> On Sun, 20 Oct 2019 10:15:34 -0300 Marcelo Laia 
> wrote:
>> root@marcelo:~# dpkg -l apparmor
>> Desired=Unknown/Install/Remove/Purge/Hold
>> |
>> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/
>> Nome   Versão   Arquitectura Descrição
>> +++-==---==
>> ii  apparmor   2.13.3-5 amd64user-space parser
>> utility for AppArmor root@marcelo:~# 
>
> Following up on this, I am pasting here below the contents of
> my /etc/apparmor.d/usr.bin.evince, which allows me to use .mutt as a
> folder for pdf files. I guess the culprit should be there (tl;dr: grep
> mutt /etc/apparmor.d/usr.bin.evince returns nothing).

Does "grep -R mutt /etc/apparmor.d/" return anything?

I suspect that, in a system with this issue, the problematic rule would
be in abstractions/private-files, and usr.bin.evince includes
abstractions/evince[1] which includes abstractions/private-files.

[1] 
https://www.apt-browse.org/browse/debian/jessie/main/all/apparmor-profiles-extra/1.4/file/etc/apparmor.d/abstractions/evince

-- 
Nuno Silva

Re: Really strange problem with evince PDF reader and .mutt directory

[nunojsilva]

On 2019-10-20, Chris Green wrote:

> On Sun, Oct 20, 2019 at 11:01:02AM +0200, Matthias Apitz wrote:
>> El día domingo, octubre 20, 2019 a las 09:25:46a. m. +0100, Nuno Silva 
>> escribió:
>> 
>> > On 2019-10-19, José María Mateos wrote:
>> > 
>> > > On Sat, 19 Oct 2019 19:17:06 +0100 Chris Green  wrote:
>> > >> Running 'evince ~/.mitt/fred.pdf' displays the PDF file successfully
>> > >> but running 'evince ~/.mutt/fred.pdf' produces a Permission Denied
>> > >> message in a pop-up window.  All directory names I have tried other
>> > >> than .mutt allow the PDF file to be read.
>> 
>> I can't reproduce this on FreeBSD. The OP could run on any Linux (don't
>> know if the problem is on Linux):
>> 
>> strace -o evince.tr -f  evince ~/.mutt/fred.pdf
>> 
>> and look into the file evince.tr which open(2) or stat(2) gives a
>> Permission Denied and why. If the OP can't see this, he/she should 
>> post this file somewhere.
>> 
>>  matthias
>> 
> I'm running xubuntu 19.04 on both systems which show this bug.  I
> don't have evince on any other system at the moment.
>
> I will try the strace and also I may try installing evince on a system
> which is running xubuntu 18.04 to see if the bug is there too.
>
> Thanks everyone and listen to this space! :-)

Do these systems have apparmor? It seems to be some sort of security
tool which restricts access to files and directories based on rules.

I don't use ubuntu (or ubuntu-based) systems nor apparmor, but this
looks like it might be related:

https://gitlab.com/apparmor/apparmor/raw/master/profiles/apparmor.d/abstractions/private-files

-- 
Nuno Silva

Re: Really strange problem with evince PDF reader and .mutt directory

[nunojsilva]

On 2019-10-19, José María Mateos wrote:

> On Sat, 19 Oct 2019 19:17:06 +0100 Chris Green  wrote:
>> Running 'evince ~/.mitt/fred.pdf' displays the PDF file successfully
>> but running 'evince ~/.mutt/fred.pdf' produces a Permission Denied
>> message in a pop-up window.  All directory names I have tried other
>> than .mutt allow the PDF file to be read.
>> 
>> Has anyone else here seen anything like this?  It would seem that it's
>> an error in evince but of some relevance to mutt use.
>
> I can't reproduce this on my end. I copied a PDF file in my ~/.mutt
> directory and all these options work:
>
> $ evince test.pdf (from inside ~/.mutt)
> $ evince .mutt/test.pdf (from my home directory)
> $ evince ~/.mutt/test.pdf (same)
>
> Cheers,

Any chance this is the same issue Marcelo Laia reported earlier this
year?

(see the thread starting with Message-ID:
<20190118120629.GE5678@localhost>, from 2019-01-18)

In that case, evince was being started from mutt, and the issue happened
with other applications as well.


URL of a web copy of the mentioned thread, at marc.info:
https://marc.info/?t=15478132762=1=2

-- 
Nuno Silva

Re: Openning attach - denied permission

[nunojsilva]

On 2019-01-30, Marcelo Laia wrote:

> Dear,
>
> I will try to clarify with a video.
>
> Please, could you see it here?
>
> https://www.dropbox.com/s/61sb07hx4stvbcs/mutt-file-not-open.mp4?dl=0
>
> In this video, I did:
>
> Opem mutt, go to message, open the attach view, hint the attach file.
>
> After, I close de evince and hit I to return to page.
>
> Any clue?

What is the exact evince command that is executed by mutt? 

Doing "ps -ef | grep evinc[e]" while evince is showing the error message
should be enough. If there is more than one entry, it should be the one
that has the name of the PDF file.

-- 
Nuno Silva

Re: [Mutt] Re: Group reply To-vs-Cc recipients

[nunojsilva]

On 2018-12-13, Derek Martin wrote:

> On Wed, Dec 12, 2018 at 01:18:04PM +1100, Erik Christiansen wrote:
>
>> Then the thoughts of the majority of the community bear
>> consideration, especially when based on reason. 
>
> The majority of the community said nothing at all, which suggests (as
> I suggested) that most people don't actually give a $#@! about this,
> as well they shouldn't.

Depending on the definitions of "community" and "most people", there's
also the problem that an undefined number of mutt users might not be
reading this list at all.

> I'll note that in response to Kevin's query,
> two people (Ariis and Christiansen) said preserving the To: line was
> sensible, and three people (Zimmerman, Yardley, and myself) said it
> seems pointless.  There were no other opinions provided.

Whatever ends up being done, I'd advise against *changing* the default
behaviour, either keep just the current behaviour or add an alternative,
but keep it disabled by default.

But I'm just a user.

-- 
Nuno Silva

Re: [Mutt] Re: Group reply To-vs-Cc recipients

[nunojsilva]

On 2018-12-11, Derek Martin wrote:

> On Tue, Dec 11, 2018 at 08:39:31PM +1100, Erik Christiansen wrote:
>> On 10.12.18 17:29, Derek Martin wrote:
>> >When a message is a reply to another message, the mailboxes of the
>> >authors of the original message (the mailboxes in the "From:"
>> >field) or mailboxes specified in the "Reply-To:" field (if it
>> >exists) MAY appear in the "To:" field of the reply since these
>> >would normally be the primary recipients of the reply.  If a reply
>> >is sent to a message that has destination fields, it is often
>> >desirable to send a copy of the reply to all of the recipients of
>> >the message, in addition to the author.  When such a reply is
>> >formed, addresses in the "To:" and "Cc:" fields of the original
>> >message MAY appear in the "Cc:" field of the reply, since these are
>> >normally secondary recipients of the reply.
>> > 
>> > It recomments Mutt's current behavior, for precisely the reasons I
>> > gave in support of it.  The person who opened the ticket stated that
>> > the expected behavior is for the recipients in the To: field to be
>> > preserved, but the RFC clearly states otherwise.
>> 
>> It clearly states that it "MAY" be otherwise. 
>
> Yes, I did not think I needed to say this explicity, but it also
> explains why:  Because that usage is the one that corresponds to the
> stated purpose of those fields.  As such it is the obvious, and should
> be preferred, way to use them on replies.  Using the fields the way
> they are intended to be used, to me, adheres to the principle of least
> surprise.

Can't what is the least surprising to you be more surprising to somebody
else?

> It certainly has (clearly) always matched my personal
> expectation such that I've never given it a second thought.  But I
> still say it mostly doesn't, and shouldn't, matter in practical use.
>
> [I'd obviously prefer the RFC should say "SHOULD" instead of "MAY" but
> you get what you get when someone else does it for you.]

-- 
Nuno Silva

Re: Composing in utf8 from latin1 terminal

[nunojsilva]

On 2018-10-25, Derek Martin wrote:

> On Thu, Oct 25, 2018 at 11:11:52AM -0500, Derek Martin wrote:
>> On Thu, Oct 25, 2018 at 12:53:43PM +0100, Nuno Silva wrote:
>> > When I use emacsclient, the interface locale is not broken: the terminal
>> > I/O encoding is correctly set from the locale. The only difference (that
>> > I know of) is that Emacs will use utf8 to read/write files. If this
>> > should match the terminal encoding, then it *is* broken.
>
> Also, depending on exactly why you're doing this multi-locale stuff,
> an even better solution may be to let Mutt's send_charset handle it
> for you.  If set properly, you should be able to compose your messages
> in UTF-8, and as long as you don't use any non-latin1 characters,
> send_charset *should* make sure the message goes out encoded as
> latin1.
>
> The biggest drawback to this approach is you have to be very careful
> to not use any non-latin1 characters, or else the message will be sent
> as unicode.  Otherwise, you'd need to check every message before you
> send it to make sure Mutt will send it as the desired encoding.  I
> have a vague notion that certain other message transforms, like PGP,
> may also interfere with this, but I'm not 100% sure.

But, if I understood the purpose of send_charset correctly, it only
affects the encoding of the outgoing message. It won't change the
encoding with which mutt reads the temporary file after I close the text
editor, will it?

-- 
Nuno Silva

Re: Composing in utf8 from latin1 terminal

[nunojsilva]

On 2018-10-24, Derek Martin wrote:

> On Tue, Oct 23, 2018 at 10:31:45PM +0100, Nuno Silva wrote:
>> On 2017-10-12, nunojsi...@ist.utl.pt wrote:
>> 
>> > Recently, I have tried to use mutt on a non-utf8 terminal.  Everything
>> > works as expected in an utf8 environment, but when I compose new e-mails
>> > in a latin1/ISO-8859-1 terminal, mutt will expect the file to be in the
>> > same encoding as the terminal, while my text editor will save the file
>> > in utf8. The result is that non-ASCII characters get misinterpreted,
>> > which can affect the message headers as well (e.g. real names in To: and
>> > Cc:).
>> [...]
>> > Is there some way to configure mutt so that it always uses utf8 to read
>> > the new message after I exit the editor? Or a way to enable some
>> > encoding autodetection that can tell utf8 apart from latin1?
>
> The bottom line is that your environment is misconfigured.  If you
> want this to work, you need to have LANG set properly at every point
> along the execution path.  Your terminal, terminal font, editor, and
> Mutt all need to know that you're using latin1 instead of Unicode, by
> having been started with a latin1 LANG setting.  You may need to
> configure your terminal to use the correct font, although with many
> modern terminals (like gnome-term, kterm, etc.) this should be
> unnecessary.
>
> If you are launching the latin1 terminal from a shell that has its
> LANG set to UTF-8, it could break (an example of this is starting
> hanterm, a terminal program expressly for Korean input with EUC-KR,
> with a UTF-8 locale--won't work).  If the shell running inside the
> terminal has LANG set to UTF-8, both Mutt and your editor could break.
> If you have manual settings on any of these programs to override the
> locale defined by the environment, it could break.  If you don't have
> all of these things set the same way, it could, and almost certainly
> will break.  Sometimes the breakage is subtle, e.g. if you dump the
> right characters to a terminal (say, with the cat command) tht has the
> right font, it will generally display them correctly, even if the
> locale is wrong.  But using them with programs that need to know the
> locale will still break.
>
> If you're using a Mutt setting to connect to an existing emacs
> instance (via emacsclient or similar) that's already running in a
> UTF-8 locale, that's broken.  You need to start a new instance of
> emacs whose locale is latin1.

I haven't noticed this before, but there *is* indeed a difference when
starting a fresh new Emacs instance instead of connecting to an existing
one using emacsclient: the new instance does use latin1 to read/write
files. (That is, the behaviour expected by mutt.)

When I use emacsclient, the interface locale is not broken: the terminal
I/O encoding is correctly set from the locale. The only difference (that
I know of) is that Emacs will use utf8 to read/write files. If this
should match the terminal encoding, then it *is* broken.

I might be happy with the way things are now (as my files are usually in
utf8, and mutt is the only context where I need the file encoding to
match the terminal), but I won't claim it isn't broken if it is.

> Lastly, you may need to adjust send_charset in Mutt.  It can have
> multiple locales, and Mutt will pick the first one that your document
> can be displayed in.  For example, mine is:
>
>   set send_charset="iso-8859-1:utf-8"
>
> If my e-mail contains no characters that need UTF-8, Mutt will choose
> to send the message as iso-8859-1, but otherwise as UTF-8.
>
> If you do those things, it should "just work" and if you don't it
> won't, at least without jumping through pointless hoops to force it,
> which will most likely just break other things.

send_charset appears to be working correctly here, I've checked it a
couple days ago. It isn't even set in any configuration file, so I
suppose it is using the default setting.

For now, I will leave the Emacs hack in place, as I prefer to use the
Emacs "server instance" instead of creating a new one. Everything else
is hopefully correctly set, as this has been the only encoding problem
I've had in the past months. (Now that I've said this, I will probably
discover a new one tomorrow...)

-- 
Nuno Silva

Re: Composing in utf8 from latin1 terminal

[nunojsilva]

On 2018-10-24, Ian Zimmerman wrote:

> On 2018-10-23 22:31, Nuno Silva wrote:
>
>> So far I did not find a way to change this on the mutt side, but I made
>> a new major mode for mutt messages in Emacs (the editor I use with
>> mutt), with a hook that changes the file encoding to latin1 if the file
>> was opened in a latin1 terminal and Emacs cannot detect a non-ASCII file
>> encoding.
>> 
>> It appears to work here. I'm sure someone who is more versed in Emacs
>> than me would be able to come up with a more elegant solution, but I'm
>> sharing mine here just in case it is useful to somebody else someday:
>> 
>> (define-derived-mode my-mutt-message-mode message-mode "MuttMSG")
>> (add-hook
>>  'my-mutt-message-mode-hook
>>  (lambda ()
>>(when (equal (terminal-coding-system) 'iso-latin-1-unix)
>>  (let ((encoding (detect-coding-region (point-min) (point-max
>>(when (or
>>   (equal encoding '(undecided-unix))
>>   (equal encoding '(undecided)))
>>  (setq buffer-file-coding-system 'iso-latin-1-unix))
>> (add-to-list 'auto-mode-alist '("/mutt" . my-mutt-message-mode))
>
> You could just hook message-mode-hook with a function that checks
> buffer-file-name,  I think that would be a bit more straightforward than
> adding a new mode.

Yes, it would be. In my case, I am also redefining a keybinding (C-c
C-c, and possibly more in the future), so the new mode is a way to keep
these mutt-related changes together.

> Other possibilities: you could handle this still in Emacs, but after you
> finish writing, at the point you save the temporary file (with one of
> the write hooks).  Or you can write a script that runs Emacs and then
> recodes the file outside of Emacs, using something like iconv(1).

-- 
Nuno Silva

Re: Composing in utf8 from latin1 terminal

[nunojsilva]

On 2017-10-12, nunojsi...@ist.utl.pt wrote:

> Recently, I have tried to use mutt on a non-utf8 terminal.  Everything
> works as expected in an utf8 environment, but when I compose new e-mails
> in a latin1/ISO-8859-1 terminal, mutt will expect the file to be in the
> same encoding as the terminal, while my text editor will save the file
> in utf8. The result is that non-ASCII characters get misinterpreted,
> which can affect the message headers as well (e.g. real names in To: and
> Cc:).
[...]
> Is there some way to configure mutt so that it always uses utf8 to read
> the new message after I exit the editor? Or a way to enable some
> encoding autodetection that can tell utf8 apart from latin1?

So far I did not find a way to change this on the mutt side, but I made
a new major mode for mutt messages in Emacs (the editor I use with
mutt), with a hook that changes the file encoding to latin1 if the file
was opened in a latin1 terminal and Emacs cannot detect a non-ASCII file
encoding.

It appears to work here. I'm sure someone who is more versed in Emacs
than me would be able to come up with a more elegant solution, but I'm
sharing mine here just in case it is useful to somebody else someday:


(define-derived-mode my-mutt-message-mode message-mode "MuttMSG")
(add-hook
 'my-mutt-message-mode-hook
 (lambda ()
   (when (equal (terminal-coding-system) 'iso-latin-1-unix)
 (let ((encoding (detect-coding-region (point-min) (point-max
   (when (or
  (equal encoding '(undecided-unix))
  (equal encoding '(undecided)))
 (setq buffer-file-coding-system 'iso-latin-1-unix))
(add-to-list 'auto-mode-alist '("/mutt" . my-mutt-message-mode))

-- 
Nuno Silva

Re: Line-wrapping the GPG key identity selection menu

[nunojsilva]

On 2018-08-30, nunojsi...@ist.utl.pt wrote:

> I've been sending GPG-encrypted e-mails with mutt, and I've noticed that
> the key ID selection menu, the one that shows up when there is more than
> one identity in a given recipient's key, is a bit too long for 80
> columns.
>
> This means that, when I send encrypted e-mails from an 80-column
> terminal, at least with some GPG keys, I can't read the e-mail address
> associated with each identity, as it goes beyond the 80th column.
>
> Is there any way to deal with this in mutt? An option to wrap long lines
> in menus, or keybindings to scroll the menu left/right?

I guess this applies to any menu with sufficiently long lines. Right
now, in the message index, I am unable to see the entire message subject
for some messages in an 80-column terminal.

In this case I can open the message in the pager and see the subject
there, but, out of curiosity, is there any other way to see the full
subject, line-wrapped?


But I start thinking what I really want is to be able to scroll
left/right...

-- 
Nuno Silva

Re: Mailing list status

[nunojsilva]

On 2018-03-12, Kevin J. McCarthy wrote:

> The new mailing list server uses GNU mailman.  There are likely a few
> things that need to be tweeked.  Please let me know about any issues.

I only noticed this now. As far as I can tell, it hasn't been mentioned
here yet: (I might have overlooked some message, though)

The web archive for this list at marc.info[0] stopped being updated
after the mailing list move. Same goes for mutt-dev[1].

[0] https://marc.info/?l=mutt-users
[1] https://marc.info/?l=mutt-dev


It seems that there are web archives for mutt-users and mutt-dev at
mutt.org[2,3]. Out of curiosity, why aren't these listed in the mutt
website[4]?

[2] http://lists.mutt.org/pipermail/mutt-users/
[3] http://lists.mutt.org/pipermail/mutt-dev/
[4] http://www.mutt.org/mail-lists.html

-- 
Nuno Silva

Line-wrapping the GPG key identity selection menu

[nunojsilva]

I've been sending GPG-encrypted e-mails with mutt, and I've noticed that
the key ID selection menu, the one that shows up when there is more than
one identity in a given recipient's key, is a bit too long for 80
columns.

This means that, when I send encrypted e-mails from an 80-column
terminal, at least with some GPG keys, I can't read the e-mail address
associated with each identity, as it goes beyond the 80th column.

Is there any way to deal with this in mutt? An option to wrap long lines
in menus, or keybindings to scroll the menu left/right?

-- 
TIA,
Nuno Silva

Re: Mailing list status

[nunojsilva]

On 2018-03-12, Kevin J. McCarthy wrote:

> On Mon, Mar 12, 2018 at 10:01:08PM +, Nuno Silva wrote:
>> It looks like the "nomail" subscription setting was lost in this
>> transition.
>> 
>> I have been subscribed that way for some time and today, for the first
>> time ever, I received a few emails from this mailing list.
>
> Sorry about that.  Yes, the 'nomail' and 'digest' options were lost, and
> I have no way to retrieve them.  I'll have to ask for your forgiveness
> and request you manually re-enable those settings for your account.
>
> Subscription settings can be edited at:
> https://lists.osuosl.org/mailman/listinfo/mutt-users
>
> Note, however, that the website and mailman are not integrated yet.
> Some of the mailman links in emails point to
>  prefixes which currently don't work.
> Please use the above osuosl.org URL for now.

To do this by e-mail:

1. The mailing list software now requires the password to be provided
   with some requests and it appears that passwords were reset with this
   migration. So, first send an email containing just "password" to
   mutt-users-requ...@mutt.org

2. After receiving the password, send a second e-mail to the same
   address with

   set authenticate your-password
   set delivery off

-- 
Nuno Silva

Re: Mailing list status

[nunojsilva]

On 2018-03-12, Kevin J. McCarthy wrote:

> Last Friday night, our mailing list and website server suffered a
> catastrophic failure.
>
> Fortunately, for the past couple months I have already been working on
> moving our mailing lists to OSUOSL.  I had planned a couple more steps
> to transition smoothly, but given the failure have accelerated things.
>
> The new mailing list server uses GNU mailman.  There are likely a few
> things that need to be tweeked.  Please let me know about any issues.
[...]

Hello,

It looks like the "nomail" subscription setting was lost in this
transition.

I have been subscribed that way for some time and today, for the first
time ever, I received a few emails from this mailing list.

-- 
Nuno Silva

Composing in utf8 from latin1 terminal

[nunojsilva]

Hello,

Recently, I have tried to use mutt on a non-utf8 terminal.  Everything
works as expected in an utf8 environment, but when I compose new e-mails
in a latin1/ISO-8859-1 terminal, mutt will expect the file to be in the
same encoding as the terminal, while my text editor will save the file
in utf8. The result is that non-ASCII characters get misinterpreted,
which can affect the message headers as well (e.g. real names in To: and
Cc:).

When replying to messages, this has not been an issue so far, as mutt
includes the quoted copy of the message I'm replying to and the editor
can use that to guess the encoding.

Is there some way to configure mutt so that it always uses utf8 to read
the new message after I exit the editor? Or a way to enable some
encoding autodetection that can tell utf8 apart from latin1?

-- 
Thanks in advance,
Nuno Silva