[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possibility of combining custom and init-file setup (Org mode captur

From: rusi
Subject: Re: Possibility of combining custom and init-file setup (Org mode capture templates)
Date: Sun, 13 Mar 2011 20:29:07 -0700 (PDT)
User-agent: G2/1.0

On Mar 13, 3:24 am, "Alan E. Davis" <address@hidden> wrote:
> I am posting to this list after posting a similar message to the Org-mode
> list, at the suggestion of one respondent.
> Org mode provides a variable, "capture-templates" to set up the ability to
> capture on-the-fly in various pre-defined ways, as defined as a list of
> individual templates.   Org-mode has a facility to enable rapid definition
> of these templates using a custom buffer.  On the other hand, it is possible
> to provide this variable in the init file, for example.
> I find org-mode's custom interface for capture templates extremely helpful
> for quick, one-off templates, without having to edit the init-file.
> Especially for somewhat complicated templates it provides a starting point.
> However, to use this custom buffer interface seems to conflict, in many a
> non-obvious way, with the manually loaded templates.  One receives a message
> suggesting that unpredictable results may ensue from modifying this variable
> that was set outside of the custom interface.
> I would like to request advice, on how can I set up so most of my capture
> templates are loaded from a file (~/org/capture-templates.el in my case) and
> still retain the ability to define new capture templates on the fly.  I want
> the best of both worlds:
>    - capture-templates.el is easier for me to tweak by hand, and I can
> alphabetize the templates in various ways as needed.
>    - the capture custom feature is a fantastic way to deine one off
> templates on the fly.
> One imagines there must be a way to do this by loading one or the other of
> the methods first, perhaps ~/org/capture-templates.el, and then load the
> custom-file afterwards.
> My understanding of the system does not enable me to understand the
> underlying nuts and bolts of the system well enough to  know if either of
> these methods will work, or run aground.  It is suggested that this is not
> possible.  Some responses from the org-mode list members showed what the
> issues might be.  On the other hand, another list-member suggests to explore
> further on this list.
> How can one use both the manually edited variable, in conjunction with the
> same variable in the custom file.  I think that the fact that this variable
> is actually a list of individual customizations may suggest it is possible.

I dont think I know enough to answer this but since there is no other
satisfactory answer let me try..

Customize is two things: a browser(reader) and a customizer(writer).
As a reader it does a good job of allowing a user to navigate the many
thousands of options that emacs has into reasonable groups.

As a writer --ie customizer -- it is terrible.  <rant>It by default
throws crud unpredictably at your init file, hardly improved if you
separate your custom file from the init.  And its inability to
distinguish code -- .el files -- from data -- options settings --
would earn it an F in any typical CS101 course. </rant>

My own choice is to stay as far from customize (as a customizer) as
possible. [As I said above browsing is fine -- just make no permanent
When I do for whatever reasons make permanent settings I try and get
them out of customize into setqs.  But there are many subtleties here
setq vs setq-default etc -- that I dont understand.

I realize that this is not much help to you because you want to use
customize as a customizer.
So perhaps the usage 'outside customize' viz keeping the templates
nicely organized -- is something you could do inside the customize-
variables block.  IOW stay entirely inside customize and clean up the
generated code by hand.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]