Re: Is linewrap dead?
On Mon, Sep 05, 2022 at 08:36:54AM +1000, Cameron Simpson wrote: But not space-stuffing, right? I just reread https://www.rfc-editor.org/rfc/rfc3676#section-4.4 to refresh my brain. Yeah, I don't think I'd want that when writing a message. Which I guess is why Mutt space-stuffs the format=flowed that it gets back from the editor. Aye. I avoid lines commencing with a ">" just because they look quoted to my eye anyway, so that aside "live" space stuffing in authoring is something I'd find distracting. Agreed, I wouldn't want space-stuffing maintained on the fly, while editing. It could be done at the end, when handing the message back to Mutt. It seems a little conceptually cleaner to have the editor do the whole job, rather than divide it between the editor and Mutt. But another complication is that you can edit a message more than once... I've just written something for Emacs, to use Emacs to compose format=flowed for Mutt. Well, I wrote two things, that do it two different ways. The first one does it like vim, maintaining format=flowed on the fly as you type, by adding things to the existing "fill" functions (re-wrap). I have it working -- I've used it to post a couple things here -- but I had to put fingers into existing Emacs mechanisms (by adding "advice" to functions), which I'm leery of, and I don't think it can be done in a buffer-local way. The second one works differently. It's a "major mode"; it has commands to convert both ways between format=flowed and one-line paragraphs, while you edit. The idea is to type with each paragraph being a single long line, and then "encode" that as format=flowed when you're done. That doesn't mess with existing mechanisms, and doesn't take much code. Emacs has something called "visual line mode" to make those long lines not ugly. I just got it working...I've tested it, but not extensively...I'm using it for this message... That second one is attached, for anyone who's interested (Cameron, I suppose you probably don't use Emacs). Set it up like this in .muttrc: set text_flowed = yes #compose text/plain format=flowed set editor = 'emacs --load=$HOME/elisp/mutt-flowed-text-mode.el %s --funcall=mutt-flowed-text-mode' set edit_headers = no #don't want to flow the header section Fire up Mutt, compose a message, and type C-h m to get help on the Emacs mode. (defvar mutt-flowed-text-mode-map (let ((map (make-sparse-keymap))) (set-keymap-parent map text-mode-map) (define-key map "\C-cd" 'flowed-text-decode-region) (define-key map "\C-ce" 'flowed-text-encode-region) (define-key map "\C-cD" 'flowed-text-decode-buffer) (define-key map "\C-cE" 'flowed-text-encode-buffer) (define-key map "\C-c\C-c" 'flowed-text-done) map) "Keymap for Mutt flowed text mode.") (define-derived-mode mutt-flowed-text-mode text-mode "Mutt flowed text" "Major mode to compose text/plain format=flowed for mail reader Mutt. Type and edit text with each paragraph being a single long line. When you're done, use a mode command to encode it as flowed text; that will insert soft line breaks. You can decode it (go back to one-line paragraphs) and encode it any time, but make sure the message body is encoded when you exit Emacs and hand the message back to Mutt. You could use visual-line-mode to display those long lines nicely. Also, you might want to make trailing whitespace visible by setting the variable show-trailing-whitespace, or by using whitespace-mode. This mode sets the buffer-local variable fill-column to a very large number, because Emacs text fill would damage both single-line paragraphs and text encoded as format=flowed. Don't encode/decode the message header section; that could possibly break things. It's best to tell Mutt set edit_headers = no to avoid that possibility. This mode does not space-stuff the message, because Mutt does that. For that reason, it may not be usable with other mail readers." :syntax-table=nil :abbrev-table=nil (setq-local delsp nil) (setq fill-column most-positive-fixnum)) (defun flowed-text-quote-level () (save-excursion (forward-line 0) (looking-at ">*") (length (match-string-no-properties 0 (defun flowed-text-decode-region (begin end) (interactive "r") (save-excursion (let (quote-level endm) (setq endm (set-marker (make-marker) end)) (set-marker-insertion-type endm t) (goto-char begin) (while (< (point) endm) (setq quote-level (flowed-text-quote-level)) (if (looking-at-p ".* \n") (progn (forward-line) (if (and (< (point) endm) (equal (flowed-text-quote-level) quote-level)) (progn (delete-char (if delsp -2 -1)) (delete-char quote-level)) (progn ;else: invalid space, remove it (backward-char 1)
Re: Is linewrap dead?
On 05Sep2022 08:37, raf via Mutt-users wrote:
> I like your indenting of code blocks, but it seems to
> put an additional blank line after each code block.
> That might not be intentional.
Not intentional. I just wanted to keep the 4 space indent used to trigger a
code block for the same visual effect, since I use that instead of the
triple backticks usually. Pandoc tosses those spaces.
That's correct behaviour for markdown.
Doesn't mean I like it :-)
If you want the
output to be indented four spaces, the markdown source
needs to be indented eight spaces. But for email use,
it's a nice idea to do what you're doing.
I'd like the HTML to resemble the source MarkDown, visually.
If you want to prevent the extra line, the sed command
can be changed to remove theindenyt before the closing
line of the code block:
sed '
s/^\(\)\(.*<\/code><\/pre>\)$/\1\2/
t post_pre_code
/^/,/<\/code><\/pre>$/{
s/^//
s/^\(\)/\1/
s/^\(<\/code><\/pre>\)/\1/
}
:post_pre_code
'
Ah, right. Thanks.
Cheers,
Cameron Simpson
Re: Re: Is linewrap dead?
On Sun, Sep 04, 2022 at 05:39:05PM +0200, Jan Eden via Mutt-users wrote: > On 2022-09-04 20:37, Cameron Simpson wrote: > > On 04Sep2022 15:34, raf via Mutt-users wrote: > > > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson > > > wrote: > > > > > The `md2html` script is my personal script, which wraps `pandoc` > > > > and post munges the HTML to indent the code blocks, which > > > > `pandoc`'s HTML does not please my eye. It's here: > > > > https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html if > > > > anyone wants a starting point. > > > > > > Thanks, Cameron. It's odd that there isn't an md2html program out > > > there already. I had to create one too (using python's markdown > > > module). > > There is a python script provided with mutt > (share/doc/mutt/samples/markdown2html), which can also be found at > https://fossies.org/linux/mutt/contrib/markdown2html . This one also > uses pandoc. > > - Jan Thanks. cheers, raf
Re: Is linewrap dead?
On Mon, Sep 05, 2022 at 08:36:54AM +1000, Cameron Simpson wrote: > On 05Sep2022 08:24, Cameron Simpson wrote: > > On 04Sep2022 11:33, Kurt Hackenberg wrote: > > > But not space-stuffing, right? > > I just reread https://www.rfc-editor.org/rfc/rfc3676#section-4.4 to refresh > my brain. Yeah, I don't think I'd want that when writing a message. > > > > Which I guess is why Mutt space-stuffs the format=flowed that it > > > gets back from the editor. > > Aye. I avoid lines commencing with a ">" just because they look quoted to my > eye anyway, so that aside "live" space stuffing in authoring is something > I'd find distracting. > > Cheers, > Cameron Simpson Hmm. I do "From-munging" on arrival. I should probably read rfc3676 properly. :-) cheers, raf
Re: Is linewrap dead?
On Sun, Sep 04, 2022 at 08:37:21PM +1000, Cameron Simpson
wrote:
> On 04Sep2022 15:34, raf via Mutt-users wrote:
> > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson
> > wrote:
> [...]
> > > So I've revisited the manual and found the
> > > `$send_multipart_alternative`
> > > option and its friend `$send_multipart_alternative_filter`. They work
> > > well!
> > >
> > > So now I have a mechanism to send: `format=flowed` MarkDown with a
> > > aparallel
> > > HTML alternative. The HTML should render in a "paragraphy" way for the
> > > HTML
> > > people, and the MarkDown keeps me happy.
> > >
> > > My default setting is now:
> > >
> > > set send_multipart_alternative=no
> > > set send_multipart_alternative_filter='echo text/html; echo; exec
> > > md2html'
> > >
> > > which is the inactive form, and I've added:
> > >
> > > message-hook . 'set send_multipart_alternative=no'
> > > message-hook '%f htmlees' 'set send_multipart_alternative=no'
> >
> > Oops. That should be =yes above.
>
> Whoops indeed. I just sketched this out this morning. Thanks for the catch.
> fix applied.
>
> > > The `md2html` script is my personal script, which wraps `pandoc` and
> > > post
> > > munges the HTML to indent the code blocks, which `pandoc`'s HTML does not
> > > please my eye. It's here:
> > > https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html
> > > if anyone wants a starting point.
> >
> > Thanks, Cameron. It's odd that there isn't an md2html
> > program out there already. I had to create one too
> > (using python's markdown module).
>
> Ah, that might be easier to customise. I just tried a few markdown
> converters and ended up with pandoc.
>
> > I like your indenting of code blocks, but it seems to
> > put an additional blank line after each code block.
> > That might not be intentional.
>
> Not intentional. I just wanted to keep the 4 space indent used to trigger a
> code block for the same visual effect, since I use that instead of the
> triple backticks usually. Pandoc tosses those spaces.
That's correct behaviour for markdown. If you want the
output to be indented four spaces, the markdown source
needs to be indented eight spaces. But for email use,
it's a nice idea to do what you're doing.
If you want to prevent the extra line, the sed command
can be changed to remove theindenyt before the closing
line of the code block:
sed '
s/^\(\)\(.*<\/code><\/pre>\)$/\1\2/
t post_pre_code
/^/,/<\/code><\/pre>$/{
s/^//
s/^\(\)/\1/
s/^\(<\/code><\/pre>\)/\1/
}
:post_pre_code
'
> Pandoc's conversion is a bit clunky (but better than discount and the other
> tool I tried).
>
> > And it looks like it
> > doesn't do titles (which default to "-"). I guess that
> > doesn't matter for email use, except that pandoc
> > whinges about it on stderr.
>
> Aye, annoying. There's no context for a title (eg the subject header), I may
> just have to provide something to shut it up. Or shift sideways to the
> Python module, particularly if that does a better job.
>
> > Do you have any advice for automating spaces at the end
> > of non-final paragraph lines for format=flowed in vim?
>
> I use these settings:
> https://github.com/cameron-simpson/css/blob/main/bin/vim-flowed
> which autowraps and leaves trailing spaces automatically.
>
> > Perhaps I could just post-process messages with perl
> > in my mutt-editor wrapper script.
>
> Vim can do 99% of it for you on the fly :-)
Thanks again.
> Cheers,
> Cameron Simpson
cheers,
raf
Re: Is linewrap dead?
On 05Sep2022 08:24, Cameron Simpson wrote: On 04Sep2022 11:33, Kurt Hackenberg wrote: But not space-stuffing, right? I just reread https://www.rfc-editor.org/rfc/rfc3676#section-4.4 to refresh my brain. Yeah, I don't think I'd want that when writing a message. Which I guess is why Mutt space-stuffs the format=flowed that it gets back from the editor. Aye. I avoid lines commencing with a ">" just because they look quoted to my eye anyway, so that aside "live" space stuffing in authoring is something I'd find distracting. Cheers, Cameron Simpson
Re: Is linewrap dead?
On 04Sep2022 11:33, Kurt Hackenberg wrote: On 2022/09/04 06:37, Cameron Simpson wrote: Vim can do 99% of it for you on the fly :-) But not space-stuffing, right? Which I guess is why Mutt space-stuffs the format=flowed that it gets back from the editor. I imagine it could be told to space stuff with a lot of work maybe? I was more thinking of the authoring side, where it word wraps and space-appends my input text as I type. As it's just done for me writing this. Cheers, Cameron Simpson
Re: Re: Is linewrap dead?
On 2022-09-04 20:37, Cameron Simpson wrote: > On 04Sep2022 15:34, raf via Mutt-users wrote: > > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson > > wrote: > > > The `md2html` script is my personal script, which wraps `pandoc` > > > and post munges the HTML to indent the code blocks, which > > > `pandoc`'s HTML does not please my eye. It's here: > > > https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html if > > > anyone wants a starting point. > > > > Thanks, Cameron. It's odd that there isn't an md2html program out > > there already. I had to create one too (using python's markdown > > module). There is a python script provided with mutt (share/doc/mutt/samples/markdown2html), which can also be found at https://fossies.org/linux/mutt/contrib/markdown2html . This one also uses pandoc. - Jan signature.asc Description: PGP signature
Re: Is linewrap dead?
On 2022/09/04 06:37, Cameron Simpson wrote: Do you have any advice for automating spaces at the end of non-final paragraph lines for format=flowed in vim? I use these settings: https://github.com/cameron-simpson/css/blob/main/bin/vim-flowed which autowraps and leaves trailing spaces automatically. Perhaps I could just post-process messages with perl in my mutt-editor wrapper script. Vim can do 99% of it for you on the fly :-) But not space-stuffing, right? Which I guess is why Mutt space-stuffs the format=flowed that it gets back from the editor.
Handling multiple From addresses
Hi, I use a couple of From addresses, and currently change the default From address and BCC address manually, and select the matching PGP key for signing afterwards (PGP menu → sign as → [From address] → select key). This can probably be done much more efficiently, so my questions are: - Can I define multiple From addresses to select them from a list? - Can mutt be configured to switch the default BCC address to a changed From address? - If there is only a single PGP private key for each address – is it possible to have that key selected automatically (or with a single keystroke) according to the current From address? I know I could work with different mutt profiles by starting the program with the -F parameter, but I regularly need to switch the From/BCC/PGP key combination while using mutt. Thanks, Jan signature.asc Description: PGP signature
Re: Re: Is linewrap dead?
> I smile, that was me. I agree with your point: email use is getting > relegated to corporate settings, dealing with banks/utilities, some > services (newsletters). It's worse than that: what is being relegated by most people is reading and writing "complex texts" (i.e. more than a few lines), and performing "complex tasks" as attaching a few images to an email or using a paper map; this is going backwards in the development of the Western human psyche, it's a very serious issue, but too much off topic for this list. Apart from that, the big difference between using whatsapp or email is that with email you get independence: I have my own email servers using my own domains that just a court can take away from me, use the OS and MTA of my choice that I can modify and compile from source, set up my spam filters, webmail and everything else just the way I want, and everything works the way I want. It's like being the owner of my own piece of land or just a poor peasant in somebody's else huge land.
Re: Is linewrap dead?
On 04Sep2022 15:34, raf via Mutt-users wrote: On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson wrote: [...] So I've revisited the manual and found the `$send_multipart_alternative` option and its friend `$send_multipart_alternative_filter`. They work well! So now I have a mechanism to send: `format=flowed` MarkDown with a aparallel HTML alternative. The HTML should render in a "paragraphy" way for the HTML people, and the MarkDown keeps me happy. My default setting is now: set send_multipart_alternative=no set send_multipart_alternative_filter='echo text/html; echo; exec md2html' which is the inactive form, and I've added: message-hook . 'set send_multipart_alternative=no' message-hook '%f htmlees' 'set send_multipart_alternative=no' Oops. That should be =yes above. Whoops indeed. I just sketched this out this morning. Thanks for the catch. fix applied. The `md2html` script is my personal script, which wraps `pandoc` and post munges the HTML to indent the code blocks, which `pandoc`'s HTML does not please my eye. It's here: https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html if anyone wants a starting point. Thanks, Cameron. It's odd that there isn't an md2html program out there already. I had to create one too (using python's markdown module). Ah, that might be easier to customise. I just tried a few markdown converters and ended up with pandoc. I like your indenting of code blocks, but it seems to put an additional blank line after each code block. That might not be intentional. Not intentional. I just wanted to keep the 4 space indent used to trigger a code block for the same visual effect, since I use that instead of the triple backticks usually. Pandoc tosses those spaces. Pandoc's conversion is a bit clunky (but better than discount and the other tool I tried). And it looks like it doesn't do titles (which default to "-"). I guess that doesn't matter for email use, except that pandoc whinges about it on stderr. Aye, annoying. There's no context for a title (eg the subject header), I may just have to provide something to shut it up. Or shift sideways to the Python module, particularly if that does a better job. Do you have any advice for automating spaces at the end of non-final paragraph lines for format=flowed in vim? I use these settings: https://github.com/cameron-simpson/css/blob/main/bin/vim-flowed which autowraps and leaves trailing spaces automatically. Perhaps I could just post-process messages with perl in my mutt-editor wrapper script. Vim can do 99% of it for you on the fly :-) Cheers, Cameron Simpson
