emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Build fail with emacs 24.3.1


From: Bastien
Subject: Re: [O] Build fail with emacs 24.3.1
Date: Thu, 14 Mar 2013 12:26:05 +0100
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)

Hi Achim,

Achim Gratz <address@hidden> writes:

> Bastien <bzg <at> altern.org> writes:
>> One potential problem in the first test is the use of "parent" as the
>> name of the symbol to pass to the macro... since this is the very same
>> name than the macro second argument.  At least this reminded me this
>> section of Elisp manual:
>
> I've actually tested this by renaming the macro arguments and no symbol
> capturing seems to be involved via this path.  The symbol is never used 
> unquoted
> in the macro expansion anyway.

So, I'm not alone.

>> So... instead of fixing the macro calls in the tests, I've been
>> wondering why using a macro for `org-export-define-derived-backend'
>> and `org-export-define-backend' would be better?
>
> I think that these are proper uses of macros since Nicolas is introducing
> special syntax for defining a backend.  

Yes -- but what I'm arguing about is that the special syntax is not
needed.  Or more specifically, it is not needed to have

  (org-export-define-backend html
    ((bold . org-html-bold)

instead of just

  (org-export-define-backend 'html
    '((bold . org-html-bold)

> In any case before anything is changed
> we should know why this is happening at all.

If we agree the macros are not really needed we can make the change.
We will always be free to find why the macros are causing problems
later one.  I know the move looks like I want to avoid the problems
instead of fixing them, but it's not: it's about fixing the approach
upstream instead of fighting with some obscure consequences of the
unnecessary approach.

Anyway, I'll wait Nicolas opinion on this for sure.

-- 
 Bastien



reply via email to

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