[O] [PATCH] Re: autoloads not working correctly for org-table.el?

[Eric Abrahamsen]

Eric Abrahamsen <address@hidden> writes:

> Eric S Fraga <address@hidden> writes:
>
>> On Wednesday,  4 Mar 2015 at 17:28, Eric Abrahamsen wrote:
>>
>> [...]
>>
>>> I'm still seeing an issue where, if I start right off typing a big
>>> paragraph of text at the top of the message (no salutation or anything),
>>> all the lines *after* the first line are indented by one tab. Subsequent
>>> paragraphs are unaffected.
>>
>> Hi Eric,
>>
>> I had this problem for a long time.  It disappeared a some time ago now
>> and I have no idea why.  However, while I had the problem, I trained
>> myself to always start an email (that was not a response like this one)
>> with some form of salutation!  More polite as well as avoiding the bug
>> :)
>
> Well, sure :) I guess I'll try being politer!
>
> I just poked around a little bit, edebugging
> `org-adaptive-fill-function'. I looked at the call to
> `fill-context-prefix' two-thirds of the way down. I tested this with the
> last email I sent, and I see that calling `org-adaptive-fill-function'
> on the first paragraph results in `fill-context-prefix' being called
> with the arguments 1 (the post-affiliated arg), and 447 (the end
> position of the first paragraph). The result of that call is a tab.
>
> If I move to the second paragraph and do the same thing, the
> post-affiliated arg was 447, and the end position is 475. The result of
> that call was nil, which is probably what I wanted.
>
> My value of adaptive-fill-regexp, in this case is:
>
> "\\(\\([      ]*[_.[:word:]]+>+\\|[   ]*[]>|]\\)+\\)[         ]*\\|[
> ]*\\([-–!|#%;>*·•‣⁃◦]+[       ]*\\)*"
>
> I will poke further as time allows. I don't know much about filling (and
> have never understood what "post-affiliated" actually means), but assume
> I can eventually get to the bottom of it...
>
> E

It looks like the problem was that all the message headers are parsed as
though they were part of the first paragraph of message body text. Why
that should result in a secondary TAB indent I don't know, but
regardless, Org probably should only be looking at the message body, and
nothing else.

The attached patch is a hack that adds the `mail-header-separator'
regexp to the `org-element-paragraph-separate' regexp. That means it
will only work for paragraphs, so there might still be weirdness if a
message body starts with a list or what have you.

Perhaps a better solution would be to narrow to the body of the message
before doing the fill prefix calculation.

Eric

0001-Change-paragraph-boundaries-in-message-mode.patch
Description: Text Data