From: Bernt Hansen <bernt@norang.ca>
To: Toby Cubitt <toby-dated-1335792145.9a3403@dr-qubit.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Allow more control over inserted whitespace in capture templates
Date: Tue, 17 Apr 2012 19:28:51 -0400 [thread overview]
Message-ID: <87d376kkek.fsf@norang.ca> (raw)
In-Reply-To: <20120416132157.GA21083@c3po.home> (Toby Cubitt's message of "Mon, 16 Apr 2012 15:21:57 +0200")
This patch is sitting on the patchwork server. It's not lost.
http://patchwork.newartisans.com/project/org-mode/list/
-Bernt
Toby Cubitt <tsc25@cantab.net> writes:
> Was there any feedback on this patch, or did it get lost in the noise?
>
> At least for me, org-capture breaks the document heading layout by
> inserting incorrect amounts of whitespace. And there's no way to
> configure capture templates to make it work correctly.
>
> The patch I posted fixes this behaviour.
>
> (Or am I missing some already-existing way of doing this? See below for a
> detailed description of the problem.)
>
> Toby
>
>
>
>
> On Mon, Feb 13, 2012 at 01:26:09PM +0100, Toby Cubitt wrote:
>> When capturing an item as a subheading, the capture template :empty-lines
>> property is not sufficient to ensure the correct document layout is
>> maintained after capturing.
>>
>> This patch fixes the capture behaviour to insert new subheadings
>> immediately after the previous heading (rather than immediately before
>> the next one). And it adds new :empty-lines-before and :empty-lines-after
>> capture template properties. (I can split these two changes into
>> separated patches, if desired.)
>>
>> When set, the new :empty-lines-before and :empty-lines-after properties
>> take precedence over :empty-lines in determining the amount of whitespace
>> to add before or after the captured item, respectively. Together, these
>> changes allow the correct document layout to be achieved after capturing,
>> without any manual editing.
>>
>> (Since the whole idea of org-capture is to rapidly capture new ideas or
>> todos, having to manually edit whitespace after capturing to fix the
>> document layout is far from ideal.)
>>
>>
>> To give a more detailed example of why I think these changes are needed,
>> consider for example an org-mode document in which headings are separated
>> by two empty lines, and subheadings are separated by a single empty
>> line. (This is a natural layout if one wants headings to be separated by
>> whitespace when folded, but subheadings not to be separated when folded):
>>
>> ------------------------
>> * heading 1
>> ** subheading 1.1
>>
>> ** subheading 1.2
>>
>>
>> * heading 2
>> ** subheading 2.1
>> ------------------------
>>
>> Let's say I want add a captured item as a new "subheading 1.3" under
>> "heading 1", preserving this layout structure. Then we need to add the
>> new item immediately after "subheading 1.2", inserting one empty line
>> before and two empty lines after. There appears to be no way to do this
>> using :empty-lines.
>>
>> In fact, the existing implementation adds the new capture item
>> immediately *before* the *following* heading ("heading 2" in this case),
>> which seems to be altogether wrong, as it effectively forces two empty
>> lines before the new item, regardless of the :empty-lines setting.
>>
>> Currently, setting :empty-lines to 0 leaves the document looking like
>> this:
>>
>> ------------------------
>> * heading 1
>> ** subheading 1.1
>>
>> ** subheading 1.2
>>
>>
>> ** subheading 1.3
>> * heading 2
>> ** subheading 2.1
>> ------------------------
>>
>> whilst setting :empty-lines to 1 leaves the document looking like this:
>>
>> ------------------------
>> * heading 1
>> ** subheading 1.1
>>
>> ** subheading 1.2
>>
>>
>>
>> ** subheading 1.3
>>
>> * heading 2
>> ** subheading 2.1
>> ------------------------
>>
>> neither of which are likely to ever be what we want.
>>
>> With this patch, setting the new :empty-lines-before to 1 and
>> :empty-lines-after to 2 results in the correct structure after capturing:
>>
>> ------------------------
>> * heading 1
>> ** subheading 1.1
>>
>> ** subheading 1.2
>>
>> ** subheading 1.3
>>
>>
>> * heading 2
>> ** subheading 2.1
>> ------------------------
>>
>>
>> I think this patch is largely orthogonal to the recent "removing
>> whitespace from new captures" patch (currently in patchwork). That patch
>> causes `whitespace-cleanup' to be called in the CAPTURE buffer before
>> finalizing, which doesn't affect the additional whitespace inserted later
>> on by the :empty-lines property. This patch allows more control over the
>> latter, by providing a fairly simple extension of the existing
>> :empty-lines property.
>>
>> Toby
next prev parent reply other threads:[~2012-04-17 23:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-13 12:26 [PATCH] Allow more control over inserted whitespace in capture templates Toby Cubitt
2012-04-16 13:21 ` Toby Cubitt
2012-04-17 23:28 ` Bernt Hansen [this message]
2012-04-20 11:58 ` Bastien
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=87d376kkek.fsf@norang.ca \
--to=bernt@norang.ca \
--cc=emacs-orgmode@gnu.org \
--cc=toby-dated-1335792145.9a3403@dr-qubit.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).