message-do-auto-fill, to not fill some things

message-do-auto-fill, to not fill some things

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 218 bytes --]

I use auto-fill-mode in text modes, but in message-mode I wanted it
not to fill when editing headers or #part attachment lines.  Here's
what I came up with to do this, I think it'd be a good addition to
message-mode.


[-- Attachment #2: message-do-auto-fill.el --]
[-- Type: application/emacs-lisp, Size: 756 bytes --]

Re: message-do-auto-fill, to not fill some things

[Lars Magne Ingebrigtsen]

Kevin Ryde <user42@zip.com.au> writes:

> ;; as per message-goto-body
> (defun message-body-pos ()
>   (save-excursion
>     (goto-char (point-min))
>     (or (search-forward (concat "\n" mail-header-separator "\n") nil t)
> 	(search-forward "\n\n" nil t)
> 	(point-max))))
> 
> (defun message-do-auto-fill ()
>   (if (not (or (< (point) (message-body-pos))
> 	       (save-excursion (beginning-of-line) (looking-at "<#part"))))
>       (funcall (default-value 'normal-auto-fill-function))))

[...]

> 	     (if auto-fill-function
> 		 (setq auto-fill-function 'message-do-auto-fill))

Can one do this kind of predicate thing with the normal fill commands
as well?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: message-do-auto-fill, to not fill some things

[Kevin Ryde]

> Kevin Ryde <user42@zip.com.au> writes:
> 
> > (defun message-do-auto-fill ()
> >   ...

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> Can one do this kind of predicate thing with the normal fill commands
> as well?

Do you mean like fill-paragraph (M-q)?  Not with just the little spot
of code I made, but I didn't think I needed fill-paragraph in headers.

Presumably a "message-fill-paragraph" could just let some values for
paragraph-start, etc when in the headers, or do nothing in a #part
I guess fill-paragraph-function would be the right way to do it,
recursing into fill-paragraph for the real work.

Re: message-do-auto-fill, to not fill some things

[Lars Magne Ingebrigtsen]

Kevin Ryde <user42@zip.com.au> writes:

> Do you mean like fill-paragraph (M-q)?  Not with just the little spot
> of code I made, but I didn't think I needed fill-paragraph in headers.

It would be nice if all the filling commands could work as normal,
only differently in different parts of the buffer...

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: message-do-auto-fill, to not fill some things

[Kai Großjohann]

Kevin Ryde <user42@zip.com.au> writes:

> Presumably a "message-fill-paragraph" could just let some values for
> paragraph-start, etc when in the headers, or do nothing in a #part
> I guess fill-paragraph-function would be the right way to do it,
> recursing into fill-paragraph for the real work.

Hm.  There is a variable `auto-fill-inhibit-regexp' which is now set
by message-mode.  Hm.  Does setting this variable influence M-q, too?

[time passes]

No.  That's bad.  Hm.

[more time passes]

I was hoping that it is possible to play tricks with
adaptive-fill-regexp and adaptive-fill-first-line-regexp but couldn't
find out how to do that quickly.

kai
-- 
Beware of flying birch trees.

Re: message-do-auto-fill, to not fill some things

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
> I was hoping that it is possible to play tricks with
> adaptive-fill-regexp and adaptive-fill-first-line-regexp but couldn't
> find out how to do that quickly.

Below is something I came up with for a message-fill-paragraph.  It
seems to do mostly the right thing, someone smart can pick it up and
run with it, or kick it into touch.  To try it, start editing a
message and do

        (load "mfill.el")

Filling a long References: or Subject: is nice, but is it right to
fill mail addresses on space boundaries?  If not then the easy way of
just letting some variables might be doomed.

Kai, your new auto-fill-inhibit-regexp I guess won't inhibit on a
filled line in the headers, which is either good or bad depending on
your viewpoint.  If there's already some filling perhaps it's right to
do more.


[-- Attachment #2: mfill.el --]
[-- Type: application/emacs-lisp, Size: 1533 bytes --]