From: Toby Cubitt <tsc25@cantab.net>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Allow more control over inserted whitespace in capture templates
Date: Mon, 16 Apr 2012 15:21:57 +0200 [thread overview]
Message-ID: <20120416132157.GA21083@c3po.home> (raw)
In-Reply-To: <20120213122609.GA5966@c3po>
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
--
Dr T. S. Cubitt
Mathematics and Quantum Information group
Department of Mathematics
Complutense University
Madrid, Spain
email: tsc25@cantab.net
web: www.dr-qubit.org
next prev parent reply other threads:[~2012-04-16 13:22 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 [this message]
2012-04-17 23:28 ` Bernt Hansen
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=20120416132157.GA21083@c3po.home \
--to=tsc25@cantab.net \
--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).