* Defining capture-templates: custom and init file
@ 2011-03-08 2:17 Alan E. Davis
2011-03-08 5:39 ` Suvayu Ali
0 siblings, 1 reply; 6+ messages in thread
From: Alan E. Davis @ 2011-03-08 2:17 UTC (permalink / raw)
To: org-mode
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
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.
Thank you
Alan Davis
[-- Attachment #2: Type: text/html, Size: 1013 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Defining capture-templates: custom and init file
2011-03-08 2:17 Defining capture-templates: custom and init file Alan E. Davis
@ 2011-03-08 5:39 ` Suvayu Ali
2011-03-08 6:13 ` Alan E. Davis
0 siblings, 1 reply; 6+ messages in thread
From: Suvayu Ali @ 2011-03-08 5:39 UTC (permalink / raw)
To: Alan E. Davis; +Cc: org-mode
On Tue, 8 Mar 2011 12:17:58 +1000
"Alan E. Davis" <lngndvs@gmail.com> wrote:
> 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:
Sorry, can't be done. The customize interface stores the
(custom-set-variables ... ) block in the init file. Having more than
one such code block might lead to unpredictable Emacs behaviour. Your
only two choices are:
1. Use customize. Then your capture templates are stored with your other
emacs customisations in your init file (e.g. ~/.emacs,
~/.emacs.d/init.el or whatever).
2. Use setq to define your templates outside of customize. If you choose
this, you lose the ability to define templates using customize and
save it. You can still however save a template temporarily `C-c C-c'.
I hope this answers your query.
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Defining capture-templates: custom and init file
2011-03-08 5:39 ` Suvayu Ali
@ 2011-03-08 6:13 ` Alan E. Davis
2011-03-08 6:33 ` Suvayu Ali
0 siblings, 1 reply; 6+ messages in thread
From: Alan E. Davis @ 2011-03-08 6:13 UTC (permalink / raw)
To: Suvayu Ali; +Cc: org-mode
[-- Attachment #1: Type: text/plain, Size: 1992 bytes --]
Hello: Suvayu:
I have set the variable custom-file outside of the init file to
~/org/custom-local.el or some such, so there wouldn't be a conflict within
the same file. I can delay loading of that file until after the hand-made
capture templates have been loaded from ~/org/capture-templates.el .
Alternately, one could load the custom-file first, then the other. What I
am thinking/hoping/dreaming is that one could add to the capture-templates
variable, in the same way one adds to, say "load-path" by saying
(setq load-path (append load-path (list "/home/olaf/Emacs")))
I have noticed the message from within the customization interface that some
variable or another was set outside of customization, and there may be
unpredictable results. Wonder what that really means, though. It's still
a variable, isn't it?
Alan
On Tue, Mar 8, 2011 at 3:39 PM, Suvayu Ali <fatkasuvayu+linux@gmail.com>wrote:
> On Tue, 8 Mar 2011 12:17:58 +1000
> "Alan E. Davis" <lngndvs@gmail.com> wrote:
>
> > 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:
>
> Sorry, can't be done. The customize interface stores the
> (custom-set-variables ... ) block in the init file. Having more than
> one such code block might lead to unpredictable Emacs behaviour. Your
> only two choices are:
>
> 1. Use customize. Then your capture templates are stored with your other
> emacs customisations in your init file (e.g. ~/.emacs,
> ~/.emacs.d/init.el or whatever).
>
> 2. Use setq to define your templates outside of customize. If you choose
> this, you lose the ability to define templates using customize and
> save it. You can still however save a template temporarily `C-c C-c'.
>
> I hope this answers your query.
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>
[-- Attachment #2: Type: text/html, Size: 2629 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Defining capture-templates: custom and init file
2011-03-08 6:13 ` Alan E. Davis
@ 2011-03-08 6:33 ` Suvayu Ali
2011-03-08 11:05 ` Alan E. Davis
0 siblings, 1 reply; 6+ messages in thread
From: Suvayu Ali @ 2011-03-08 6:33 UTC (permalink / raw)
To: Alan E. Davis; +Cc: org-mode
Hi Alan,
On Tue, 8 Mar 2011 16:13:34 +1000
"Alan E. Davis" <lngndvs@gmail.com> wrote:
> I have noticed the message from within the customization interface
> that some variable or another was set outside of customization, and
> there may be unpredictable results. Wonder what that really means,
> though. It's still a variable, isn't it?
>
Say you customise the templates outside your custom-set-variables
block. Now if you use the customise your templates with customize and
save them, it will be saved in the custom-set-variables block. For the
current session of emacs you might not experience any problems, but
when you restart emacs depending on which comes first the setq or the
custom-set-variables your templates will be set accordingly. It is
difficult to predict for me which will be the case. For more on this
you can look here[1].
Hope this helps you understand the issue with what you are attempting.
[1] http://www.dotemacs.de/custbuffer.html
> Alan
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Defining capture-templates: custom and init file
2011-03-08 6:33 ` Suvayu Ali
@ 2011-03-08 11:05 ` Alan E. Davis
0 siblings, 0 replies; 6+ messages in thread
From: Alan E. Davis @ 2011-03-08 11:05 UTC (permalink / raw)
To: Suvayu Ali; +Cc: org-mode
[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]
Very revealing. However, that post was written in 2005, and the following
statement is found at the tail end:
The good news
The behaviour of custom due to more than one custom-set-... statement will
be changed in Emacs 21.xx. I've been told that
> Multiple calls to custom-set-variables should work in Emacs 21;
> if you customize, all the variables go into the first one,
> and the rest are deleted.
I can still dream. I have to say, though, thank you very, very much. This
certainly clarifies the issue well.
Alan
On Tue, Mar 8, 2011 at 4:33 PM, Suvayu Ali <fatkasuvayu+linux@gmail.com>wrote:
> Hi Alan,
>
> On Tue, 8 Mar 2011 16:13:34 +1000
> "Alan E. Davis" <lngndvs@gmail.com> wrote:
>
> > I have noticed the message from within the customization interface
> > that some variable or another was set outside of customization, and
> > there may be unpredictable results. Wonder what that really means,
> > though. It's still a variable, isn't it?
> >
>
> Say you customise the templates outside your custom-set-variables
> block. Now if you use the customise your templates with customize and
> save them, it will be saved in the custom-set-variables block. For the
> current session of emacs you might not experience any problems, but
> when you restart emacs depending on which comes first the setq or the
> custom-set-variables your templates will be set accordingly. It is
> difficult to predict for me which will be the case. For more on this
> you can look here[1].
>
> Hope this helps you understand the issue with what you are attempting.
>
> [1] http://www.dotemacs.de/custbuffer.html
>
> > Alan
>
> --
> Suvayu
>
> Open source is the future. It sets us free.
>
[-- Attachment #2: Type: text/html, Size: 2571 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Defining capture-templates: custom and init file
@ 2011-03-08 11:19 Rustom Mody
0 siblings, 0 replies; 6+ messages in thread
From: Rustom Mody @ 2011-03-08 11:19 UTC (permalink / raw)
To: emacs-orgmode
Alan Davis wrote:
> 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.
It may be worthwhile to ask this on the emacs list.
[I have seen somewhere emacs lead-dev Stefan Monnier recommend that
customize be used only for faces and ordinary other methods (setq?)
for everything else]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-03-08 11:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-08 2:17 Defining capture-templates: custom and init file Alan E. Davis
2011-03-08 5:39 ` Suvayu Ali
2011-03-08 6:13 ` Alan E. Davis
2011-03-08 6:33 ` Suvayu Ali
2011-03-08 11:05 ` Alan E. Davis
-- strict thread matches above, loose matches on Subject: below --
2011-03-08 11:19 Rustom Mody
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).