Possibility of combining custom and init-file setup (Org mode capture templates)

Possibility of combining custom and init-file setup (Org mode capture templates)

[Alan E. Davis]

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]

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.

Thank you,

Alan Davis

[-- Attachment #2: Type: text/html, Size: 2453 bytes --]

RE: Possibility of combining custom and init-file setup (Org modecapture templates)

[Drew Adams]

> 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.

Too abstract for me to be able to help you.  Hopefully someone familiar with
org-mode or its code will be able to help.

In the abstract, you should be able to do everything via Lisp that you can do
using Customize.  Dunno what warning messages you are referring to, but as a
start try setting values using `custom-set-variables', not `setq'.  Check
whether the `defcustom' forms use :set or :init etc.  If so then you will need
to do something similar from Lisp - they mean that `setq' is not sufficient.
Keyword :type tells you what form the value must take.  And so on.  Use the
org-mode `defcustom' forms as your guide.

Re: Possibility of combining custom and init-file setup (Org mode capture templates)

[rusi]

On Mar 13, 3:24 am, "Alan E. Davis" <lngn...@gmail.com> 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
settings]
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.