* changes to paragraph fill?
@ 2012-08-11 4:27 Eric Abrahamsen
2012-08-15 3:53 ` Katsumi Yamaoka
0 siblings, 1 reply; 3+ messages in thread
From: Eric Abrahamsen @ 2012-08-11 4:27 UTC (permalink / raw)
To: ding
Hitting M-q on the first paragraph of a message used to not munge the
message headers into one big block of text. It does now, and I'm
wondering is commit 436a2a323 the reason? I'm sure that commit was made
for good reasons, etc, but could we add something back in (if only just
a re-definition of paragraph-start to include `mail-header-separator',
or whatever the recommended solution is to this sort of issue), so that
filling the first paragraph doesn't fill the headers too?
Or is this something I've mucked up locally?
E
--
GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.11)
of 2012-08-06 on pellet
Ma Gnus v0.6
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: changes to paragraph fill?
2012-08-11 4:27 changes to paragraph fill? Eric Abrahamsen
@ 2012-08-15 3:53 ` Katsumi Yamaoka
2012-08-15 5:45 ` Eric Abrahamsen
0 siblings, 1 reply; 3+ messages in thread
From: Katsumi Yamaoka @ 2012-08-15 3:53 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: ding
Eric Abrahamsen wrote:
> Hitting M-q on the first paragraph of a message used to not munge
> the message headers into one big block of text. It does now, and I'm
> wondering is commit 436a2a323 the reason?
Hm, it doesn't modify the headers here now. Reverting the changes
makes no difference, either.
> I'm sure that commit was made for good reasons, etc,
The main reason I made the changes was to fill long address lines
in the header part of a reply message according to the value of
`message-field-fillers' (in which `message-fill-field-address' is
mapped to To, Cc, and From headers by default).
> but could we add something back in (if only just
> a re-definition of paragraph-start to include `mail-header-separator',
> or whatever the recommended solution is to this sort of issue), so that
> filling the first paragraph doesn't fill the headers too?
In my case the value of `paragraph-start' in a message-mode
buffer is:
"--text follows this line--$\\|[ \t]*$\\|-- $\\|---+$\\|^\f$..."
This is the result of what `message-setup-fill-variables' does,
not due to my customization.
> Or is this something I've mucked up locally?
Doesn't something modify it outside of the message-mode?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: changes to paragraph fill?
2012-08-15 3:53 ` Katsumi Yamaoka
@ 2012-08-15 5:45 ` Eric Abrahamsen
0 siblings, 0 replies; 3+ messages in thread
From: Eric Abrahamsen @ 2012-08-15 5:45 UTC (permalink / raw)
To: ding
On Wed, Aug 15 2012, Katsumi Yamaoka wrote:
> Eric Abrahamsen wrote:
>> Hitting M-q on the first paragraph of a message used to not munge
>> the message headers into one big block of text. It does now, and I'm
>> wondering is commit 436a2a323 the reason?
>
> Hm, it doesn't modify the headers here now. Reverting the changes
> makes no difference, either.
Sorry for the red herring! Dumb assumption on my part, and one I could
have checked myself.
> Doesn't something modify it outside of the message-mode?
Turns out that a message-mode-hook that ran (turn-on-orgstruct++) was
clobbering this. I've been using the hook for a while now with no
adverse effect, but looking at the orgmode list I see there have been
other, previous notes about this. My apologies for
poorly-researched complaint! I'll try plain (turn-on-orgstruct) for now.
E
--
GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 2.24.11)
of 2012-08-14 on pellet
Ma Gnus v0.6
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-08-15 5:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-11 4:27 changes to paragraph fill? Eric Abrahamsen
2012-08-15 3:53 ` Katsumi Yamaoka
2012-08-15 5:45 ` Eric Abrahamsen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).