New default change: Automatic article filling

New default change: Automatic article filling

[Lars Magne Ingebrigtsen]

gnus-treat-fill-long-lines now defaults to '(typep "text/plain"), and
this now points to `gnus-article-fill-cited-long-lines' instead of the
simpler version.  So Gnus will do article filling based on citation
parsing if the lines are wider than the frame width.

There are probably some issues with this here and there, so let me know
whether it's too annoying.  I've looked through about a 100 messages
from "real people" (i.e., just the kind of people that doesn't wrap
their lines when sending), and it looks much better to me than before.
But it may do totally the wrong thing with code.

Anybody have a good heuristic for seeing whether a paragraph is code?
:-)

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

Re: New default change: Automatic article filling

[Russ Allbery]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> gnus-treat-fill-long-lines now defaults to '(typep "text/plain"), and
> this now points to `gnus-article-fill-cited-long-lines' instead of the
> simpler version.  So Gnus will do article filling based on citation
> parsing if the lines are wider than the frame width.

Thank you!

> Anybody have a good heuristic for seeing whether a paragraph is code?
> :-)

Yeah, that was always my biggest concern with this too.

For a first pass, not wrapping anything that's indented with whitespace or
any paragraph with a ragged left margin would probably go a long way.
Most code has a ragged left margin due to indentation of block structure
and very little regular text does, except for numbered or bulletted lists
(which can probably be identified separately; Emacs wrapping seems to
already do a good job of recognizing those).

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: New default change: Automatic article filling

[Lars Magne Ingebrigtsen]

Russ Allbery <rra@stanford.edu> writes:

> For a first pass, not wrapping anything that's indented with whitespace or
> any paragraph with a ragged left margin would probably go a long way.
> Most code has a ragged left margin due to indentation of block structure
> and very little regular text does,

That's sounds like a very good idea.  I'll give it a whirl...

> except for numbered or bulletted lists (which can probably be
> identified separately; Emacs wrapping seems to already do a good job
> of recognizing those).

Yes, the citation code does a pretty good job of splitting stuff into
sensible regions.  I'll try the new code out in, say, gmane.linux.kernel
and add your suggested heuristic and see how it goes.

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

Re: New default change: Automatic article filling

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I'll try the new code out in, say, gmane.linux.kernel and add your
> suggested heuristic and see how it goes.

It seems to work quite well now in that group.  Stuff that's too long
and not code is filled, and code isn't filled.  At least from the about
50 articles I ran through.

This code probably needs more tweaking, and it's never going to be 100%
correct, but I hope the improved general readability will outweigh its
annoying behaviour when it does the wrong thing.

The new meaning for `C-u g' (don't do any washing, but do
Content-Transfer-Encoding decoding), will help with recovering from
overzealous formatting.

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

Re: New default change: Automatic article filling

[Greg Troxel]

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


  Anybody have a good heuristic for seeing whether a paragraph is code?

Perhaps make this conditional on sending MUA.  The problem seems to be
broken support for format=flowed, and confusion between an auto-filling
UI (which is fine) and proper encoding of a message from such a UI
(which seems rare).

As a data point, Apple's Mail.app is broken.


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: New default change: Automatic article filling

[Katsumi Yamaoka]

Lars Magne Ingebrigtsen wrote:
> gnus-treat-fill-long-lines now defaults to '(typep "text/plain"), and
> this now points to `gnus-article-fill-cited-long-lines' instead of the
> simpler version.  So Gnus will do article filling based on citation
> parsing if the lines are wider than the frame width.

It's the *window* width, isn't it?  There's an example of
vertically splitting windows in: (info "(gnus)Window Layout")
In such a case, perhaps we may need to override the value of
fill-column since a user leaves it the default.

In addition, isn't `gnus-article-natural-long-line-p' unnecessary?

Re: New default change: Automatic article filling

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> Lars Magne Ingebrigtsen wrote:
>> gnus-treat-fill-long-lines now defaults to '(typep "text/plain"), and
>> this now points to `gnus-article-fill-cited-long-lines' instead of the
>> simpler version.  So Gnus will do article filling based on citation
>> parsing if the lines are wider than the frame width.

> It's the *window* width, isn't it?  There's an example of
> vertically splitting windows in: (info "(gnus)Window Layout")
> In such a case, perhaps we may need to override the value of
> fill-column since a user leaves it the default.

> In addition, isn't `gnus-article-natural-long-line-p' unnecessary?

Moreover, I recalled the XEmacs version of `fill-region' inserts
a newline unless the region ends with a newline.  I.e.:

(with-temp-buffer
  (insert "foo bar baz")
  (setq fill-column 10)
  (fill-region (point-min) (point-max))
  (buffer-string))
"foo bar
baz
"

I've committed a fix for this and also replaced `frame-width'
with `window-width'.

Re: New default change: Automatic article filling

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> I've committed a fix for this and also replaced `frame-width'
> with `window-width'.

Thanks.

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

Re: New default change: Automatic article filling

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> In addition, isn't `gnus-article-natural-long-line-p' unnecessary?

Yeah, I just left it in there to see whether I'd get inspired some day,
but I haven't been, so far.  :-)  So I've removed it now.

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

Re: New default change: Automatic article filling

[Ralf Angeli]

* Lars Magne Ingebrigtsen (2010-10-31) writes:

> There are probably some issues with this here and there, so let me know
> whether it's too annoying.

For me it is.  Probably because I am currently in a discussion about
problems with filling text in LaTeX files. (c:

The fact that `C-u g' changed its meaning did not really help.  At least
at first.  While it allowed me to see the mail without the unwanted
filling, I got the feeling of losing some of the control I had before.
But that all was better after I discovered `C-u C-u g'. (c:

As a side note: In the discussion about filling LaTeX files mentioned
above (<URL:http://mid.gmane.org/874obxjf44.fsf%40thinkpad.tsdh.de> if
you want to have a look.) the sample text in the original article was
protected with markers from `message-mark-inserted-region'.  Gnus does
not preserve these markers when following up and so the sample text was
displayed as being filled in my reply.  Wouldn't it be better if Gnus
preserved this stuff?

-- 
Ralf

Re: New default change: Automatic article filling

[Greg Troxel]

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


  [auto filling sometimes messy, but others think it's sometimes useful]

The real issue is that there are broken MUAs sending long text that is
wrappable, but there's no way to tell with standard headers.  So how
about a way to detect a list of broken MUAs and wrap that text, and
leave text from non-broken MUAs alone?

Certainly Apple Mail belongs on the list.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: New default change: Automatic article filling

[Lars Magne Ingebrigtsen]

Ralf Angeli <angeli@caeruleus.net> writes:

> As a side note: In the discussion about filling LaTeX files mentioned
> above (<URL:http://mid.gmane.org/874obxjf44.fsf%40thinkpad.tsdh.de> if
> you want to have a look.) the sample text in the original article was
> protected with markers from `message-mark-inserted-region'.  Gnus does
> not preserve these markers when following up and so the sample text was
> displayed as being filled in my reply.  Wouldn't it be better if Gnus
> preserved this stuff?

I don't quite understand what you mean...  could you give examples of
the unwanted behaviour, and what you wanted to have happen instead?

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

Re: New default change: Automatic article filling

[Ralf Angeli]

* Lars Magne Ingebrigtsen (2010-11-08) writes:

> Ralf Angeli <angeli@caeruleus.net> writes:
>
>> As a side note: In the discussion about filling LaTeX files mentioned
>> above (<URL:http://mid.gmane.org/874obxjf44.fsf%40thinkpad.tsdh.de> if
>> you want to have a look.) the sample text in the original article was
>> protected with markers from `message-mark-inserted-region'.  Gnus does
>> not preserve these markers when following up and so the sample text was
>> displayed as being filled in my reply.  Wouldn't it be better if Gnus
>> preserved this stuff?
>
> I don't quite understand what you mean...  could you give examples of
> the unwanted behaviour, and what you wanted to have happen instead?

As in the article referenced above, the following text is enclosed in
markers inserted by `message-mark-inserted-region':

--8<---------------cut here---------------start------------->8---
foo
--8<---------------cut here---------------end--------------->8---

Gnus, however, does not display these markers but highlights the
enclosed text with a different background color.  At least in my case.
Now this is all fine and dandy.  The problem is, if you reply to the
message, e.g. with `F', then the markers are not present in the quoted
text, i.e. you get something like this:

>
> foo
>

What I would have expected is this:

>
> --8<---------------cut here---------------start------------->8---
> foo
> --8<---------------cut here---------------end--------------->8---
>

-- 
Ralf

Re: New default change: Automatic article filling

[Lars Magne Ingebrigtsen]

Ralf Angeli <angeli@caeruleus.net> writes:

> As in the article referenced above, the following text is enclosed in
> markers inserted by `message-mark-inserted-region':
>
> --8<---------------cut here---------------start------------->8---
> foo
> --8<---------------cut here---------------end--------------->8---
>
> Gnus, however, does not display these markers but highlights the
> enclosed text with a different background color.  At least in my case.
> Now this is all fine and dandy.  The problem is, if you reply to the
> message, e.g. with `F', then the markers are not present in the quoted
> text, i.e. you get something like this:
>
>>
>> foo
>>

Ah, yeah...  Hm...  I'm not sure what the right fix here would be.
Perhaps make the --8<--- lines be invisible so that they could be
quoted?  But that might be ... unexpected.  I hate cutting and pasting
text, and then when it shows up in files after saving/loading, the
invisible text is there again.

So I don't know how to fix this.  Commands like `F' work on what's
actually displayed in the article buffer, and not what the original
encoding was.

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

Re: New default change: Automatic article filling

[Ludovic Courtès]

Hello,

FWIW I find it easier and less confusing to hit ‘W W’ when noticing an
article that needs filling, than to type ‘C-u g’ when guessing that an
article was badly filled behind my back.

It may depend on the ratio of unwrapped to wrapped messages, though.

Thanks,
Ludo’.

Re: New default change: Automatic article filling

[Ludovic Courtès]

I noticed that undoing automatic article filling with ‘C-u g’ also
disables citation syntax highlighting, which I find inconvenient.

Ludo’.

Re: New default change: Automatic article filling

[Lars Magne Ingebrigtsen]

ludo@gnu.org (Ludovic Courtès) writes:

> I noticed that undoing automatic article filling with ‘C-u g’ also
> disables citation syntax highlighting, which I find inconvenient.

`C-u g' inhibits all the washing functions now.  Having special commands
to undo each washing function doesn't sound very usable.

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

Re: New default change: Automatic article filling

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> `C-u g' inhibits all the washing functions now.  Having special
> commands to undo each washing function doesn't sound very usable.

My fingers were adapted to `C-u g' to show the raw article.

They still haven't adapted to that I now need to do `C-u C-u g'
to do the same...:-/

Re: New default change: Automatic article filling

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> My fingers were adapted to `C-u g' to show the raw article.
>
> They still haven't adapted to that I now need to do `C-u C-u g'
> to do the same...:-/

Yeah, I don't know whether to swap the two meanings...

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

Re: New default change: Automatic article filling

[Rupert Swarbrick]

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

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Steinar Bang <sb@dod.no> writes:
>
>> My fingers were adapted to `C-u g' to show the raw article.
>>
>> They still haven't adapted to that I now need to do `C-u C-u g'
>> to do the same...:-/
>
> Yeah, I don't know whether to swap the two meanings...

That might be nice. Reading this message, I've just worked out why my
hardcoded "view-source" synapses weren't working...

Rupert

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]