From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Re: autoloads not working correctly for org-table.el?
Date: Tue, 10 Mar 2015 11:07:41 +0800 [thread overview]
Message-ID: <87a8zlmtxe.fsf@ericabrahamsen.net> (raw)
In-Reply-To: 87vbi9mwcv.fsf_-_@ericabrahamsen.net
[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Eric S Fraga <e.fraga@ucl.ac.uk> 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
And just for the heck of it, here's another patch that does it with
narrowing.
E
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Narrow-to-message-body-when-filling-in-message-mode.patch --]
[-- Type: text/x-diff, Size: 1062 bytes --]
From c51cdb35453ae8c2964508fc1e98b89e6c709abb Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Tue, 10 Mar 2015 11:03:23 +0800
Subject: [PATCH] Narrow to message body when filling in message mode
* lisp/org.el (org-adaptive-fill-function): Only take the message body
into account when calculating the fill prefix.
---
lisp/org.el | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/lisp/org.el b/lisp/org.el
index c566152..cf952ad 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -23015,6 +23015,12 @@ matches in paragraphs or comments, use it."
((looking-at org-outline-regexp)
(throw 'exit (make-string (length (match-string 0)) ?\s))))))
(org-with-wide-buffer
+ (when (derived-mode-p 'message-mode)
+ (save-excursion
+ (goto-char (point-min))
+ (when (re-search-forward mail-header-separator)
+ (narrow-to-region
+ (line-beginning-position 2) (point-max)))))
(unless (org-at-heading-p)
(let* ((p (line-beginning-position))
(element (save-excursion
--
2.3.2
next prev parent reply other threads:[~2015-03-10 3:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 10:12 autoloads not working correctly for org-table.el? Eric Abrahamsen
2015-02-27 10:35 ` Nicolas Richard
2015-02-27 17:28 ` Nicolas Goaziou
2015-02-28 0:39 ` Eric Abrahamsen
2015-03-04 9:28 ` Eric Abrahamsen
2015-03-04 15:23 ` Eric S Fraga
2015-03-05 1:36 ` Eric Abrahamsen
2015-03-10 2:15 ` [PATCH] " Eric Abrahamsen
2015-03-10 3:07 ` Eric Abrahamsen [this message]
2015-03-10 8:24 ` Nicolas Goaziou
2015-03-10 8:48 ` Eric Abrahamsen
2015-03-10 11:02 ` Nicolas Goaziou
2015-03-22 13:52 ` Eric Abrahamsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a8zlmtxe.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).