From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: [PATCH] Re: autoloads not working correctly for org-table.el? Date: Tue, 10 Mar 2015 11:07:41 +0800 Message-ID: <87a8zlmtxe.fsf@ericabrahamsen.net> References: <87mw3z4q9j.fsf@ericabrahamsen.net> <877fv33ame.fsf@yahoo.fr> <87ioens1px.fsf@nicolasgoaziou.fr> <87vbihglgs.fsf@ericabrahamsen.net> <87mw3slrav.fsf@delle7240.chemeng.ucl.ac.uk> <87h9u0fcop.fsf@ericabrahamsen.net> <87vbi9mwcv.fsf_-_@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVAWR-0004TE-Dk for emacs-orgmode@gnu.org; Mon, 09 Mar 2015 23:07:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVAWM-0005Bf-A4 for emacs-orgmode@gnu.org; Mon, 09 Mar 2015 23:07:55 -0400 Received: from plane.gmane.org ([80.91.229.3]:39646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVAWL-0005BM-Nw for emacs-orgmode@gnu.org; Mon, 09 Mar 2015 23:07:49 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YVAWJ-0004BN-Vv for emacs-orgmode@gnu.org; Tue, 10 Mar 2015 04:07:48 +0100 Received: from 114.248.6.199 ([114.248.6.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Mar 2015 04:07:47 +0100 Received: from eric by 114.248.6.199 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Mar 2015 04:07:47 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Eric Abrahamsen writes: > Eric Abrahamsen writes: > >> Eric S Fraga 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 --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Narrow-to-message-body-when-filling-in-message-mode.patch >From c51cdb35453ae8c2964508fc1e98b89e6c709abb Mon Sep 17 00:00:00 2001 From: Eric Abrahamsen 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 --=-=-=--