Re: auto-fill in body after "^[A-Za-z]: "

Re: auto-fill in body after "^[A-Za-z]: "

[Kai Großjohann]

Oliver Scholz <epameinondas@gmx.de> writes:

> This is the offspring from a discussion on gnu.emacs.gnus about the
> fact that something like "Suggestion: bla bla ..." breaks auto-fill in
> message buffer. I have added the following to my .emacs to correct
> that behaviour while still inhibiting auto-fill in the header. Kai
> suggested that I should mail my code to this list.

I have just committed a modified form of your changes to CVS.  The
text property is added from message-setup-1 rather than from a hook
(this also avoids searching), and the fill variables are set from
message-setup-fill-variables rather than from a hook.

Please test.

Does this work on XEmacs?  Not sure about the support of text
properties there.  Does this code work on Emacs 20 on a tty?

kai
-- 
Linux provides a nice `poweroff' command, but where is `poweron'?

auto-fill in body after "^[A-Za-z]: "

[Oliver Scholz]

Many Greetings to the Gnus Towers!

This is the offspring from a discussion on gnu.emacs.gnus about the
fact that something like "Suggestion: bla bla ..." breaks auto-fill in
message buffer. I have added the following to my .emacs to correct
that behaviour while still inhibiting auto-fill in the header. Kai
suggested that I should mail my code to this list.

(add-hook 'message-mode-hook (lambda ()
			       (setq auto-fill-function
				     'message-do-auto-fill)))

(add-hook 'message-setup-hook (lambda ()
				(os-header-set-text-property)
				(setq auto-fill-inhibit-regexp nil)))


(defun os-header-set-text-property ()
  "Put a text-property \"field\" with value \"header\" to the header lines."
  (save-excursion
    (put-text-property (point-min)
		       (re-search-forward
			(concat "^"
				mail-header-separator) nil nil 1)
		       'field 'header)))


(defun message-do-auto-fill ()
  "Test if point is in message-header before auto-filling."
  (unless (text-property-any (line-beginning-position) (point) 'field 'header)
    (do-auto-fill)))



    'oliver

-- 
Oliver Scholz
Taunusstr. 25
60329 Frankfurt am Main
Tel. 069  97 40 99 42

Re: auto-fill in body after "^[A-Za-z]: "

[David S. Goldberg]

Just tried it.  line-beginning-position doesn't exist in XEmacs 21.1.7
at least.

Adding

(defun line-beginning-position ()
  (save-excursion
    (beginning-of-line)
    (point)))

to my .emacs solves the problem for me and your fix to message.el now
does the right thing for auto fill in the body versus in the headers.

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: auto-fill in body after "^[A-Za-z]: "

[Simon Josefsson]

Oliver Scholz <epameinondas@gmx.de> writes:

> This is the offspring from a discussion on gnu.emacs.gnus about the
> fact that something like "Suggestion: bla bla ..." breaks auto-fill in
> message buffer. I have added the following to my .emacs to correct
> that behaviour while still inhibiting auto-fill in the header. Kai
> suggested that I should mail my code to this list.
>
> (defun os-header-set-text-property ()
>   "Put a text-property \"field\" with value \"header\" to the header lines."
>   (save-excursion
>     (put-text-property (point-min)
> 		       (re-search-forward
> 			(concat "^"
> 				mail-header-separator) nil nil 1)
> 		       'field 'header)))
>
>
> (defun message-do-auto-fill ()
>   "Test if point is in message-header before auto-filling."
>   (unless (text-property-any (line-beginning-position) (point) 'field 'header)
>     (do-auto-fill)))

This doesn't work if I manually add a header, right?  It wouldn't have
the proper text property.

Maybe the above be replaced by something such as the following?

(defun message-do-auto-fill ()
  (when (> (point) (save-excursion (rfc822-goto-eoh)))
    (do-auto-fill)))

(Btw, use `gnus-point-at-bol' instead of `line-beginning-position' to
make it works in XEmacs as well.)

Re: auto-fill in body after "^[A-Za-z]: "

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> This doesn't work if I manually add a header, right?  It wouldn't
> have the proper text property.

If `foobar' has a text property and I add something in the middle to
get `fooXXXbar', then surely XXX also has this text property, no?

I just tested this by adding stuff to the Subject header and saying
M-x list-text-properties-at RET -- the `field' property was there,
even in the new stuff.

> Maybe the above be replaced by something such as the following?
> 
> (defun message-do-auto-fill ()
>   (when (> (point) (save-excursion (rfc822-goto-eoh)))
>     (do-auto-fill)))

I wanted to avoid this...

> (Btw, use `gnus-point-at-bol' instead of `line-beginning-position' to
> make it works in XEmacs as well.)

No, gnus-point-at-bol might not be such a good choice, either, since
it is defined in gnus-util.el, and message*.el is supposed to be
independent from gnus*.el.

Suggestions?

kai
-- 
Linux provides a nice `poweroff' command, but where is `poweron'?

Re: auto-fill in body after "^[A-Za-z]: "

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:
> Simon Josefsson <jas@extundo.com> writes:
>> (Btw, use `gnus-point-at-bol' instead of `line-beginning-position' to
>> make it works in XEmacs as well.)
>
> No, gnus-point-at-bol might not be such a good choice, either, since
> it is defined in gnus-util.el, and message*.el is supposed to be
> independent from gnus*.el.
>
> Suggestions?

Move it to message.el, rename it to message-point-at-bol, and update
all the code that uses it?


paul

Re: auto-fill in body after "^[A-Za-z]: "

[ShengHuo ZHU]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:


[...]

>> (Btw, use `gnus-point-at-bol' instead of `line-beginning-position' to
>> make it works in XEmacs as well.)
>
> No, gnus-point-at-bol might not be such a good choice, either, since
> it is defined in gnus-util.el, and message*.el is supposed to be
> independent from gnus*.el.
>
> Suggestions?

message.el is supposed to be independent from gnus*.el.  However, some
special codes require gnus*.el, for example, checking bogus
newsgroups.  Because of this, some autoload codes are added into
message.el.  gnus-point-at-bol was used by message.el before you added
the do fill code.  And I've changed l-b-p to g-p-a-b.

ShengHuo

Re: auto-fill in body after "^[A-Za-z]: "

[Paul Jarc]

I wrote:
> Move [gnus-point-at-bol] to message.el, rename it to
> message-point-at-bol, and update all the code that uses it?

Hmm.  But is message.el supposed to be only for composing outgoing
messages?  If so, then maybe we should have a new file containing
generic message utilities, which can be used by both Message and Gnus.


paul

Re: auto-fill in body after "^[A-Za-z]: "

[Kai Großjohann]

prj@po.cwru.edu (Paul Jarc) writes:

> Move it to message.el, rename it to message-point-at-bol, and update
> all the code that uses it?

Whee.  Yeah, that's what should be done, I'm afraid.

kai
-- 
Linux provides a nice `poweroff' command, but where is `poweron'?

Re: auto-fill in body after "^[A-Za-z]: "

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> This doesn't work if I manually add a header, right?  It wouldn't
>> have the proper text property.
>
> If `foobar' has a text property and I add something in the middle to
> get `fooXXXbar', then surely XXX also has this text property, no?
>
> I just tested this by adding stuff to the Subject header and saying
> M-x list-text-properties-at RET -- the `field' property was there,
> even in the new stuff.

Oh.  Ok, all fine then.

>> (Btw, use `gnus-point-at-bol' instead of `line-beginning-position' to
>> make it works in XEmacs as well.)
>
> No, gnus-point-at-bol might not be such a good choice, either, since
> it is defined in gnus-util.el, and message*.el is supposed to be
> independent from gnus*.el.
>
> Suggestions?

`gnus-point-at-bol' is autoloaded in message.el, but otherwise Paul's
idea is probably the best.

Re: auto-fill in body after "^[A-Za-z]: "

[Kai Großjohann]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> message.el is supposed to be independent from gnus*.el.  However, some
> special codes require gnus*.el, for example, checking bogus
> newsgroups.  Because of this, some autoload codes are added into
> message.el.  gnus-point-at-bol was used by message.el before you added
> the do fill code.  And I've changed l-b-p to g-p-a-b.

I didn't know that the function was used already.  Okay, then.  Thanks
a lot for your help!

kai
-- 
Linux provides a nice `poweroff' command, but where is `poweron'?

Re: auto-fill in body after "^[A-Za-z]: "

[Oliver Scholz]

* "Simon" == Simon Josefsson <jas@extundo.com> writes:

> Oliver Scholz <epameinondas@gmx.de> writes:
>> This is the offspring from a discussion on gnu.emacs.gnus about the
>> fact that something like "Suggestion: bla bla ..." breaks auto-fill
>> in message buffer. I have added the following to my .emacs to
>> correct that behaviour while still inhibiting auto-fill in the
>> header. Kai suggested that I should mail my code to this list.
>> 
>> (defun os-header-set-text-property () "Put a text-property
>> \"field\" with value \"header\" to the header lines."
>> (save-excursion (put-text-property (point-min) (re-search-forward
>> (concat "^" mail-header-separator) nil nil 1) 'field 'header)))
>> 
>> 
>> (defun message-do-auto-fill () "Test if point is in message-header
>> before auto-filling."  (unless (text-property-any
>> (line-beginning-position) (point) 'field 'header) (do-auto-fill)))

> This doesn't work if I manually add a header, right?  It wouldn't
> have the proper text property.

Oh, it does. In the header the character at point inherits the text
property in question from the preceding one. This is at least true of
GNU Emacs 21. As soon as I know how to use cvs I will test it with
Emacs 20.7 and XEmacs 21.1.14

> Maybe the above be replaced by something such as the following?

> (defun message-do-auto-fill () (when (> (point) (save-excursion
> (rfc822-goto-eoh))) (do-auto-fill)))

> (Btw, use `gnus-point-at-bol' instead of `line-beginning-position'
> to make it works in XEmacs as well.)

Ah, thank you for that information.

    'oliver

-- 
Oliver Scholz
Taunusstr. 25
60329 Frankfurt am Main
Tel. 069  97 40 99 42

Re: auto-fill in body after "^[A-Za-z]: "

[Oliver Scholz]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Oliver Scholz <epameinondas@gmx.de> writes:
> 
>> This is the offspring from a discussion on gnu.emacs.gnus about the
>> fact that something like "Suggestion: bla bla ..." breaks auto-fill in
>> message buffer. I have added the following to my .emacs to correct
>> that behaviour while still inhibiting auto-fill in the header. Kai
>> suggested that I should mail my code to this list.
> 
> I have just committed a modified form of your changes to CVS.  The
> text property is added from message-setup-1 rather than from a hook
> (this also avoids searching), and the fill variables are set from
> message-setup-fill-variables rather than from a hook.
> 
> Please test.
> 
> Does this work on XEmacs?  Not sure about the support of text
> properties there.  Does this code work on Emacs 20 on a tty?
[...]

Emacs 20: It does work on Emacs 20 on a tty. However I found two bugs:

*  In `message-setup-1':
     (put-text-property
        (point)
        (progn
        (insert mail-header-separator "\n")
        (1- (point)))
        'read-only nil) ;; that should be 'read-only t

* there are some headers that are inserted *after* the text-property
  'field 'header is set. In my header the whole block:

>  Date: Fri, 12 Oct 2001 22:33:24 +0200
>  In-Reply-To: <vafsncphu81.fsf@INBOX.auto.gnus.tok.lucy.cs.uni-dortmund.de> (Kai.Grossjohann@CS.Uni-Dortmund.DE's message of "Fri, 12 Oct 2001 15:18:54 +0200")
>  Message-ID: <m3wv207g4r.fsf@ID-87814.user.dfncis.de>
>  Gcc: nnfolder+archive:misc-mail
>  From: Oliver Scholz <epameinondas@gmx.de>
>  X-attribution: os
>  --text follows this line--

So they have not the 'header text property and if you add a header
line manually between these lines it will not have this property, too.

I did not investigate in this yet, because I'm too tired. I will look
at it again tomorrow.

    'oliver

-- 
Oliver Scholz
Taunusstr. 25
60329 Frankfurt am Main
Tel. 069  97 40 99 42

Re: auto-fill in body after "^[A-Za-z]: "

[Kai Großjohann]

Oliver Scholz <epameinondas@gmx.de> writes:

> * there are some headers that are inserted *after* the text-property
>   'field 'header is set. In my header the whole block:

Hm.  I hope that it is okay to insert the headers at a later time.
But maybe the problem is that the headers are inserted outside of the
region of the text property?  That would be bad.

Hm.

I just now tried to type something after the last header.  It was not
wrapped.  Right now, the header region looks like this:

/----
| X-Draft-From: ("nnimap:INBOX.auto.gnus" 7800)
| To: Oliver Scholz <epameinondas@gmx.de>
| Cc: ding@gnus.org
| Subject: Re: auto-fill in body after "^[A-Za-z]: "
| References: <m3y9mht2b0.fsf@ID-87814.user.dfncis.de>
| 	<vafsncphu81.fsf@INBOX.auto.gnus.tok.lucy.cs.uni-dortmund.de>
| 	<m3vghk7f7e.fsf@ID-87814.user.dfncis.de>
| --text follows this line--
\----

And typing in the line just before `text follows this line' means that
the text does not wrap -- and it is not supposed to wrap.

kai
-- 
Linux provides a nice `poweroff' command, but where is `poweron'?

Re: auto-fill in body after "^[A-Za-z]: "

[Oliver Scholz]

* "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> Oliver Scholz <epameinondas@gmx.de> writes:
>> * there are some headers that are inserted *after* the
>> text-property 'field 'header is set. In my header the whole block:

q> Hm.  I hope that it is okay to insert the headers at a later time.
> But maybe the problem is that the headers are inserted outside of
> the region of the text property?  That would be bad.

The Elisp-manual states[1] that that "ordinary text insertion
functions such as `insert' do not inherit any properties". To insert
text that inherits text properties one could use `insert-and-inherit'.

But: I had a look at XEmacs. `insert-and-inherit' is there, but it is
declared "obsolete" (?):

,----[ C-h f insert-and-inherit RET in XEmacs 21.1.14 ]
| `insert-and-inherit' is an alias for `insert', a built-in function
|   -- loaded from "/usr/local/src/xemacs-21.1.14/lisp/obsolete.elc"
| 
| Emacs Compatible; use `insert' instead.
| 
| Documentation:
| Insert the arguments, either strings or characters, at point.
| Point moves forward so that it ends up after the inserted text.
| Any other markers at the point of insertion remain before the text.
| If a string has non-null string-extent-data, new extents will be created.
`----

> I just now tried to type something after the last header.  It was
> not wrapped.  Right now, the header region looks like this:

> /---- | X-Draft-From: ("nnimap:INBOX.auto.gnus" 7800) | To: Oliver
> Scholz <epameinondas@gmx.de> | Cc: ding@gnus.org | Subject: Re:
> auto-fill in body after "^[A-Za-z]: " | References:
> <m3y9mht2b0.fsf@ID-87814.user.dfncis.de> |
> <vafsncphu81.fsf@INBOX.auto.gnus.tok.lucy.cs.uni-dortmund.de> |
> <m3vghk7f7e.fsf@ID-87814.user.dfncis.de> | --text follows this
> line-- \----

> And typing in the line just before `text follows this line' means
> that the text does not wrap -- and it is not supposed to wrap.
[...]

Hmm. That's definitely not the case on my system. I tested this with
`list-text-properties-at': If I use the message.el from CVS, some of
the header lines don't have the 'field 'header property.

I used `edebug-defun' on `message-setup-1' to see, what happens where:
Everything is fine, until `(run-hooks 'message-setup-hook)' at the
end. Then a lot of stuff (posting-styles stuff) is added in the header
which does not inherit the 'field property.

Ah! But I see now: the difference is not so strange: In *your* header
the last header-line before "--text follows this line --" is
"References: ..." That header line has the text property in question
on my system, too.

I fiddled a bit with message.el.
I added the following right after `(run-hooks 'message-setup-hook) and
that works:

  (save-restriction
    (message-narrow-to-headers)
    (put-text-property (point-min) (point-max) 'field 'header))

Hmmm. Maybe that is not very nice, because then I have two times
`(save-restriction (message-narrow-to-headers) ....)' in the same
function?

    'oliver


Footnotes: 
[1] Usual caveat whenever *I* --being a newby -- say something about
the Elisp manual: `*if* I understand it correctly'.

-- 
22 Vendémiaire an 210 de la Révolution

Re: auto-fill in body after "^[A-Za-z]: "

[Oliver Scholz]

Hello.

For some reason I cannot post to ding.gnus via leafnode. I hope it
works now, when I access news.gnus.org via `B'.

* "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> Oliver Scholz <epameinondas@gmx.de> writes:
>> * there are some headers that are inserted *after* the
>> text-property 'field 'header is set. In my header the whole block:

q> Hm.  I hope that it is okay to insert the headers at a later time.
> But maybe the problem is that the headers are inserted outside of
> the region of the text property?  That would be bad.

The Elisp-manual states[1] that that "ordinary text insertion
functions such as `insert' do not inherit any properties". To insert
text that inherits text properties one could use `insert-and-inherit'.

But: I had a look at XEmacs. `insert-and-inherit' is there, but it is
declared "obsolete" (?):

,----[ C-h f insert-and-inherit RET in XEmacs 21.1.14 ]
| `insert-and-inherit' is an alias for `insert', a built-in function
|   -- loaded from "/usr/local/src/xemacs-21.1.14/lisp/obsolete.elc"
| 
| Emacs Compatible; use `insert' instead.
| 
| Documentation:
| Insert the arguments, either strings or characters, at point.
| Point moves forward so that it ends up after the inserted text.
| Any other markers at the point of insertion remain before the text.
| If a string has non-null string-extent-data, new extents will be created.
`----

> I just now tried to type something after the last header.  It was
> not wrapped.  Right now, the header region looks like this:

> /---- | X-Draft-From: ("nnimap:INBOX.auto.gnus" 7800) | To: Oliver
> Scholz <epameinondas@gmx.de> | Cc: ding@gnus.org | Subject: Re:
> auto-fill in body after "^[A-Za-z]: " | References:
> <m3y9mht2b0.fsf@ID-87814.user.dfncis.de> |
> <vafsncphu81.fsf@INBOX.auto.gnus.tok.lucy.cs.uni-dortmund.de> |
> <m3vghk7f7e.fsf@ID-87814.user.dfncis.de> | --text follows this
> line-- \----

> And typing in the line just before `text follows this line' means
> that the text does not wrap -- and it is not supposed to wrap.
[...]

Hmm. That's definitely not the case on my system. I tested this with
`list-text-properties-at': If I use the message.el from CVS, some of
the header lines don't have the 'field 'header property.

I used `edebug-defun' on `message-setup-1' to see, what happens where:
Everything is fine, until `(run-hooks 'message-setup-hook)' at the
end. Then a lot of stuff (posting-styles stuff) is added in the header
which does not inherit the 'field property.

Ah! But I see now: the difference is not so strange: In *your* header
the last header-line before "--text follows this line --" is
"References: ..." That header line has the text property in question
on my system, too.

I fiddled a bit with message.el.
I added the following right after `(run-hooks 'message-setup-hook) and
that works:

  (save-restriction
    (message-narrow-to-headers)
    (put-text-property (point-min) (point-max) 'field 'header))

Hmmm. Maybe that is not very nice, because then I have two times
`(save-restriction (message-narrow-to-headers) ....)' in the same
function?

    'oliver


Footnotes: 
[1] Usual caveat whenever *I* --being a newby -- say something about
the Elisp manual: `*if* I understand it correctly'.

-- 
22 Vendémiaire an 210 de la Révolution

Re: auto-fill in body after "^[A-Za-z]: "

[Oliver Scholz]

* "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> Oliver Scholz <epameinondas@gmx.de> writes:
>> * there are some headers that are inserted *after* the
>> text-property 'field 'header is set. In my header the whole block:

q> Hm.  I hope that it is okay to insert the headers at a later time.
> But maybe the problem is that the headers are inserted outside of
> the region of the text property?  That would be bad.

The Elisp-manual states[1] that that "ordinary text insertion
functions such as `insert' do not inherit any properties". To insert
text that inherits text properties one could use `insert-and-inherit'.

But: I had a look at XEmacs. `insert-and-inherit' is there, but it is
declared "obsolete" (?):

,----[ C-h f insert-and-inherit RET in XEmacs 21.1.14 ]
| `insert-and-inherit' is an alias for `insert', a built-in function
|   -- loaded from "/usr/local/src/xemacs-21.1.14/lisp/obsolete.elc"
| 
| Emacs Compatible; use `insert' instead.
| 
| Documentation:
| Insert the arguments, either strings or characters, at point.
| Point moves forward so that it ends up after the inserted text.
| Any other markers at the point of insertion remain before the text.
| If a string has non-null string-extent-data, new extents will be created.
`----

> I just now tried to type something after the last header.  It was
> not wrapped.  Right now, the header region looks like this:

> /---- | X-Draft-From: ("nnimap:INBOX.auto.gnus" 7800) | To: Oliver
> Scholz <epameinondas@gmx.de> | Cc: ding@gnus.org | Subject: Re:
> auto-fill in body after "^[A-Za-z]: " | References:
> <m3y9mht2b0.fsf@ID-87814.user.dfncis.de> |
> <vafsncphu81.fsf@INBOX.auto.gnus.tok.lucy.cs.uni-dortmund.de> |
> <m3vghk7f7e.fsf@ID-87814.user.dfncis.de> | --text follows this
> line-- \----

> And typing in the line just before `text follows this line' means
> that the text does not wrap -- and it is not supposed to wrap.
[...]

Hmm. That's definitely not the case on my system. I tested this with
`list-text-properties-at': If I use the message.el from CVS, some of
the header lines don't have the 'field 'header property.

I used `edebug-defun' on `message-setup-1' to see, what happens where:
Everything is fine, until `(run-hooks 'message-setup-hook)' at the
end. Then a lot of stuff (posting-styles stuff) is added in the header
which does not inherit the 'field property.

Ah! But I see now: the difference is not so strange: In *your* header
the last header-line before "--text follows this line --" is
"References: ..." That header line has the text property in question
on my system, too.

I fiddled a bit with message.el.
I added the following right after `(run-hooks 'message-setup-hook) and
that works:

  (save-restriction
    (message-narrow-to-headers)
    (put-text-property (point-min) (point-max) 'field 'header))

Hmmm. Maybe that is not very nice, because then I have two times
`(save-restriction (message-narrow-to-headers) ....)' in the same
function?

    'oliver


Footnotes: 
[1] Usual caveat whenever *I* --being a newby -- say something about
the Elisp manual: `*if* I understand it correctly'.

-- 
Oliver Scholz
Taunusstr. 25
60329 Frankfurt am Main
Tel. 069  97 40 99 42

Re: auto-fill in body after "^[A-Za-z]: "

[Kai Großjohann]

Oliver Scholz <oscholz@my.gnus.org> writes:

> The Elisp-manual states[1] that that "ordinary text insertion
> functions such as `insert' do not inherit any properties". To insert
> text that inherits text properties one could use `insert-and-inherit'.

Whee.  So maybe it is better to put a marker at the end of the header
and to have the auto-fill function check for that marker?

Opinions?  Suggestions?

kai
-- 
Linux provides a nice `poweroff' command, but where is `poweron'?

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Kai Großjohann]

Oliver Scholz <oscholz@my.gnus.org> writes:

> I worked a bit on the code. Please note that my lisp-writing is
> pure diletantism. It is very probable that this is not worth anything.

Quite the contrary.  I like your patches a lot.

But what do the others think about the read-only text property for
"--text follows this line--"?  Is it okay to `fix' this now?  There
must have been a reason that the line was not set read-only now.

kai
-- 
Linux provides a nice `poweroff' command, but where is `poweron'?

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Kai Großjohann]

Oliver Scholz <oscholz@my.gnus.org> writes:

> Furthermore: I never made a diff before. I followed the instructions
> in the Emacs Manual. I hope I made it right.

IMVHO you could have improved the patches by an epsilon (very small)
if you had used "-u" instead of "-c".  But this might be a matter of
taste.

kai
-- 
Linux provides a nice `poweroff' command, but where is `poweron'?

patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Oliver Scholz]

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

*blushes* I'm sorry for the spam. I was a bit careless as I posted my last
message. :-¬ 

I worked a bit on the code. Please note that my lisp-writing is
pure diletantism. It is very probable that this is not worth anything.

Furthermore: I never made a diff before. I followed the instructions
in the Emacs Manual. I hope I made it right.

1. Patch to message.el

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch to message.el --]
[-- Type: text/x-patch, Size: 1188 bytes --]

*** message.el	Fri Oct 12 16:39:31 2001
--- /home/egoge/message.el	Sat Oct 13 21:04:09 2001
***************
*** 3943,3955 ****
    (when message-default-headers
      (insert message-default-headers)
      (or (bolp) (insert ?\n)))
-   (put-text-property (point-min) (point) 'field 'header)
    (put-text-property
     (point)
     (progn
       (insert mail-header-separator "\n")
       (1- (point)))
!    'read-only nil)
    (forward-line -1)
    (when (message-news-p)
      (when message-default-news-headers
--- 3943,3954 ----
    (when message-default-headers
      (insert message-default-headers)
      (or (bolp) (insert ?\n)))
    (put-text-property
     (point)
     (progn
       (insert mail-header-separator "\n")
       (1- (point)))
!    'read-only t)
    (forward-line -1)
    (when (message-news-p)
      (when message-default-news-headers
***************
*** 3979,3984 ****
--- 3978,3986 ----
    (set-buffer-modified-p nil)
    (setq buffer-undo-list nil)
    (run-hooks 'message-setup-hook)
+   (save-restriction
+     (message-narrow-to-headers)
+     (put-text-property (point-min) (point-max) 'field 'header))
    (message-position-point)
    (undo-boundary))
  

[-- Attachment #3: Type: text/plain, Size: 195 bytes --]

a. This sets the 'field 'header property to the whole header.
b. This sets the read-only property of the mail-header-separator to t.
(changes are in `message-setup-1')

2. Patch to gnus-draft.el

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Patch to gnus.draft.el --]
[-- Type: text/x-patch, Size: 1799 bytes --]

*** gnus-draft.el	Sun Sep 23 12:37:11 2001
--- /home/egoge/gnus-draft.el	Sat Oct 13 21:42:02 2001
***************
*** 102,108 ****
      (save-excursion
        (save-restriction
  	(message-narrow-to-headers)
! 	(message-remove-header "date")))
      (save-buffer)
      (let ((gnus-verbose-backends nil))
        (gnus-request-expire-articles (list article) group t))
--- 102,109 ----
      (save-excursion
        (save-restriction
  	(message-narrow-to-headers)
! 	(message-remove-header "date")
! 	(put-text-property (point-min) (point-max) 'field 'header)))
      (save-buffer)
      (let ((gnus-verbose-backends nil))
        (gnus-request-expire-articles (list article) group t))
***************
*** 218,224 ****
  
  (progn
    (defun gnus-draft-setup (narticle group &optional restore)
!     (let (ga)
        (gnus-setup-message 'forward
  	(let ((article narticle))
  	  (message-mail)
--- 219,225 ----
  
  (progn
    (defun gnus-draft-setup (narticle group &optional restore)
!     (let (ga (inhibit-read-only t))
        (gnus-setup-message 'forward
  	(let ((article narticle))
  	  (message-mail)
***************
*** 232,238 ****
  	    (goto-char (point-min))
  	    (search-forward "\n\n")
  	    (forward-char -1)
! 	    (insert mail-header-separator)
  	    (forward-line 1)
  	    (setq ga (message-fetch-field gnus-draft-meta-information-header))
  	    (message-set-auto-save-file-name))))
--- 233,244 ----
  	    (goto-char (point-min))
  	    (search-forward "\n\n")
  	    (forward-char -1)
! 	    (put-text-property
! 	     (point)
! 	     (progn
! 	       (insert mail-header-separator)
! 	       (point))
! 	     'read-only t)
  	    (forward-line 1)
  	    (setq ga (message-fetch-field gnus-draft-meta-information-header))
  	    (message-set-auto-save-file-name))))

[-- Attachment #5: Type: text/plain, Size: 800 bytes --]

To change only message.el is not enough. When I save a message to the
drafts folder and edit it then, then the text properties are not set
accordingly and I cannot -- for example -- add a long Cc without
auto-filling.

And: The read-only property of the mail-header-separator causes an
error.

This change
a. sets the 'field property to the header again (in
   `gnus-draft-edit-message')

b. sets inhibit-read-only to t for the erasion of the buffer. (in
   `gnus-draft-setup').

I tested it with GNU Emacs 21.0.106 and GNU Emacs 20.7 (both only on a
tty if that matters). I'm not familiar with XEmacs, so I could not set
it up appropriately to run Gnus. But I checked in the Lispref that the
functions/variables I added are known to XEmacs.


    'oliver

-- 
22 Vendémiaire an 210 de la Révolution

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Henrik Enberg]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> But what do the others think about the read-only text property for
> "--text follows this line--"?  Is it okay to `fix' this now?  There
> must have been a reason that the line was not set read-only now.

I tried to do that a while back to prevent flyspell from changing it
when I use a swedish dictionary and `flyspell-maybe-correct-transposition'
in `flyspell-incorrect-hook'.  This, however made flyspell barf and
die.  Some experimentation seemed to indicate that this always happens
when flyspell encounters read-only text.

Henrik
-- 
I just forgot my whole philosophy of life!!!

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Kai Großjohann]

Oliver Scholz <oscholz@my.gnus.org> writes:

> Should I make new diffs without the read-only text property then?

Way cool.  Thanks a lot.  That way, the diffs might be < 10 lines,
which means we don't need paperwork from you.

kai
-- 
Linux provides a nice `poweroff' command, but where is `poweron'?

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Oliver Scholz]

* "Henrik" == Henrik Enberg <henrik@enberg.org> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> But what do the others think about the read-only text property for
>> "--text follows this line--"?  Is it okay to `fix' this now?  There
>> must have been a reason that the line was not set read-only now.

> I tried to do that a while back to prevent flyspell from changing it
> when I use a swedish dictionary and
> `flyspell-maybe-correct-transposition' in `flyspell-incorrect-hook'.
> This, however made flyspell barf and die.  Some experimentation
> seemed to indicate that this always happens when flyspell encounters
> read-only text.
[...]

Should I make new diffs without the read-only text property then?

    'oliver

-- 
24 Vendémiaire an 210 de la Révolution

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Oliver Scholz]

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

* "Kai" == Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> Oliver Scholz <oscholz@my.gnus.org> writes:
>> Should I make new diffs without the read-only text property then?

> Way cool.  Thanks a lot.  That way, the diffs might be < 10 lines,
> which means we don't need paperwork from you.
[...]

O.k. here they are.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: message.diff --]
[-- Type: text/x-patch, Size: 622 bytes --]

--- message.el	Fri Oct 12 16:39:31 2001
+++ /home/egoge/bin/emacs-lisp/message.el	Tue Oct 16 01:51:57 2001
@@ -3943,7 +3943,6 @@
   (when message-default-headers
     (insert message-default-headers)
     (or (bolp) (insert ?\n)))
-  (put-text-property (point-min) (point) 'field 'header)
   (put-text-property
    (point)
    (progn
@@ -3979,6 +3978,9 @@
   (set-buffer-modified-p nil)
   (setq buffer-undo-list nil)
   (run-hooks 'message-setup-hook)
+  (save-restriction
+    (message-narrow-to-headers)
+    (put-text-property (point-min) (point-max) 'field 'header))
   (message-position-point)
   (undo-boundary))
 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: gnus-draft.diff --]
[-- Type: text/x-patch, Size: 461 bytes --]

--- gnus-draft.el	Sun Sep 23 12:37:11 2001
+++ /home/egoge/bin/emacs-lisp/gnus-draft.el	Tue Oct 16 01:52:06 2001
@@ -102,7 +102,8 @@
     (save-excursion
       (save-restriction
 	(message-narrow-to-headers)
-	(message-remove-header "date")))
+	(message-remove-header "date")
+	(put-text-property (point-min) (point-max) 'field 'header)))
     (save-buffer)
     (let ((gnus-verbose-backends nil))
       (gnus-request-expire-articles (list article) group t))

[-- Attachment #4: Type: text/plain, Size: 58 bytes --]



    'oliver

-- 
25 Vendémiaire an 210 de la Révolution

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Kai Großjohann]

Oliver Scholz <oscholz@my.gnus.org> writes:

> O.k. here they are.

Installed.  Thanks!

kai
-- 
Linux provides a nice `poweroff' command, but where is `poweron'?

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Oliver Scholz <oscholz@my.gnus.org> writes:
> 
>> O.k. here they are.
> 
> Installed.  Thanks!

I changed the 'field' property to 'message-field', 'field' has a
special significance in Emacs 21.

BTW: I really think text properties are the wrong solution, text
properties tend to be sticky at the wrong times when moving text
around.  What we really want it to know whether we are before or after
the "--text follows this line--" line.  I therefore think Simon
Josefssons suggestion

           (defun message-do-auto-fill ()
             (when (> (point) (save-excursion (rfc822-goto-eoh)))
                 (do-auto-fill)))

is much cleaner.  It running the test everytime do-auto-fill is called
is  too slow, we could set a mark on seperator line and test for
that.  But I doubt it would be a problem.

Would anyone protest if I removed the text property, and installed
Simons solution instead?

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Kai Großjohann]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Would anyone protest if I removed the text property, and installed
> Simons solution instead?

After thinking about this, I agree with you that Simons solution is
better.  Thanks a lot for fixing this.

(I would prefer a mark rather than searching every time, but on the
other hand, it's probably not necessary, so why bother...)

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> After thinking about this, I agree with you that Simons solution is
> better.

I have made the change now, however as far as I can tell
message-do-auto-fill is never called!

(defun message-do-auto-fill ()
  "Like `do-auto-fill', but don't fill in message header."
  (debug)
  (when (> (point) (save-excursion (rfc822-goto-eoh)))
    (do-auto-fill)))

While "normal-auto-fill-function's value is message-do-auto-fill",
"auto-fill-function's value is do-auto-fill".  

What is going on here? 

...

Ah, message-mode is defined with 'define-derived-mode'.  Normal modes
run all hooks last when all local variables are set, but modes defined
with 'define-derived-mode' run the parent mode hook before the derived
variables are set.

This mean that the standard way to turn on auto-fill in text related
modes 

          (add-hook 'text-mode-hook 'turn-on-auto-fill)

will use the wrong value of normal-auto-fill-function in message mode.

The real solution is to make message-mode non-derived.

A quick hack would be to add

(when auto-fill-function
   (setq auto-fill-function normal-auto-fill-function))

near the end of message-mode.

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Kai Großjohann]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> The real solution is to make message-mode non-derived.

Maybe the real solution is to fix define-derived-mode?

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Maybe the real solution is to fix define-derived-mode?

I submitted an bug report for define-derived-mode, and committed this
to CVS.  define-derived-mode will not be easy to fix.

  ;; KLUDGE: auto fill might already be turned on in `text-mode-hook'.
  ;; In that case, ensure that it uses the right function.  The real
  ;; solution would be not to use `define-derived-mode', and run
  ;; `text-mode-hook' ourself at the end of the mode.
  ;; -- Per Abrahamsen <abraham@dina.kvl.dk> Date: 2001-10-19.
  (when auto-fill-function
    (setq auto-fill-function normal-auto-fill-function))

Re: patches (Re: auto-fill in body after "^[A-Za-z]: ")

[Kai Großjohann]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I submitted an bug report for define-derived-mode, and committed this
> to CVS.  define-derived-mode will not be easy to fix.

Perfect.  Thanks.

kai
-- 
GNU/Linux provides a nice `poweroff' command, but where is `poweron'?