* New exporter and defgroup
@ 2013-04-19 12:52 Christian Egli
2013-04-19 17:43 ` Suvayu Ali
0 siblings, 1 reply; 4+ messages in thread
From: Christian Egli @ 2013-04-19 12:52 UTC (permalink / raw)
To: emacs-orgmode
Hi all
The new exporter engine has changed the defcustom names but seems to
have kept the names of the defgroups (at least in the case of
taskjuggler). This is good as it allowed me to make some
backward-incompatible changes. On the other hand when I do a M-x
customize-group RET org-export-taskjuggler I get a list of both the old
defcustom vars and the new ones. This is very confusing to the user as
you appear to have the same cutomizable var twice in the group.
Is this a problem with my setup or is this inherent in the new exporter.
If the latter how can we deal with this?
Thanks
Christian
--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: New exporter and defgroup
2013-04-19 12:52 New exporter and defgroup Christian Egli
@ 2013-04-19 17:43 ` Suvayu Ali
2013-04-20 7:26 ` Bastien
0 siblings, 1 reply; 4+ messages in thread
From: Suvayu Ali @ 2013-04-19 17:43 UTC (permalink / raw)
To: emacs-orgmode
Hi Christian,
On Fri, Apr 19, 2013 at 02:52:46PM +0200, Christian Egli wrote:
> Hi all
>
> The new exporter engine has changed the defcustom names but seems to
> have kept the names of the defgroups (at least in the case of
> taskjuggler). This is good as it allowed me to make some
> backward-incompatible changes. On the other hand when I do a M-x
> customize-group RET org-export-taskjuggler I get a list of both the old
> defcustom vars and the new ones. This is very confusing to the user as
> you appear to have the same cutomizable var twice in the group.
>
> Is this a problem with my setup or is this inherent in the new exporter.
> If the latter how can we deal with this?
I think I have seen this before. Those old variables come from the
shadowed older version of Org bundled with Emacs. Not sure if this can
be avoided.
Can we have some sort of a check while loading Org that picks up these
shadowed variables and "deletes" them? My lisp foo is too bad to know
if this is even possible.
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: New exporter and defgroup
2013-04-19 17:43 ` Suvayu Ali
@ 2013-04-20 7:26 ` Bastien
2013-04-20 7:54 ` Achim Gratz
0 siblings, 1 reply; 4+ messages in thread
From: Bastien @ 2013-04-20 7:26 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode
Hi,
yes, this *is* a problem.
Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
> Can we have some sort of a check while loading Org that picks up these
> shadowed variables and "deletes" them?
I think Achim has been thinking about some incantation for this
(at install time). Maybe if this can be done after installation,
we could document it somewhere... not really sure.
I didn't want to change defgroup, it would have been confusing
to have to groups for the same purpose -- with no real clue on
which one was the most recent one.
--
Bastien
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: New exporter and defgroup
2013-04-20 7:26 ` Bastien
@ 2013-04-20 7:54 ` Achim Gratz
0 siblings, 0 replies; 4+ messages in thread
From: Achim Gratz @ 2013-04-20 7:54 UTC (permalink / raw)
To: emacs-orgmode
Bastien writes:
>> Can we have some sort of a check while loading Org that picks up these
>> shadowed variables and "deletes" them?
>
> I think Achim has been thinking about some incantation for this
> (at install time). Maybe if this can be done after installation,
> we could document it somewhere... not really sure.
It would have to be done each time Org is loaded. Unfortunately Emacs
doesn't provide an interface for removing such definitions, so you'd
have to traverse a number of not-too-well documented data structures to
get rid of them. I'm still not sure I found all of these nor if there
are adverse effects of doing that. Eric Frage (IIRC) was testing a
rough version of what I was trying to do, he reported he was seeing
problems that he wanted to investigate further. Now, with the dust from
all the other changes settling, we might pick up where we left before:
--8<---------------cut here---------------start------------->8---
;;
;; Kill our ancestors
;;
;; clean load-path
(setq load-path
(delq nil (mapcar
(function (lambda (p)
(unless (string-match "lisp/org$" p)
p))
load-path)))
;; remove property list to defeat cus-load and remove autoloads
(mapatoms (function (lambda (s)
(let ((sn (symbol-name s)))
(when (string-match "^\\(org\\|ob\\|ox\\)-?" sn)
(setplist s nil)
(when (autoloadp s)
(unintern s)))))))
(add-to-list 'load-path "/path/to/org")
(load "org-loaddefs.el" nil nil 'nosuffix)
--8<---------------cut here---------------end--------------->8---
This assumes it is run before any Org functions have been used and makes
no attempt to check if that's true. Another unverified assumption is
that nothing has polluted the namespaces that Org uses.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-04-20 7:54 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-19 12:52 New exporter and defgroup Christian Egli
2013-04-19 17:43 ` Suvayu Ali
2013-04-20 7:26 ` Bastien
2013-04-20 7:54 ` Achim Gratz
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).