emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [PATCH] Accept more :tangle-mode specification forms


From: Christian Moe
Subject: Re: [PATCH] Accept more :tangle-mode specification forms
Date: Fri, 01 Oct 2021 10:39:07 +0200
User-agent: mu4e 0.9.19; emacs 25.3.2

Tom Gillespie writes:

> I strongly oppose this patch. It adds far too much complexity to the
> org grammar.  Representation of numbers is an extremely nasty part of
> nearly every language, and I suggest that org steer well clear of
> trying to formalize this.

I'd like to understand these objections better. Aren't you overstating
what is at issue? The patch allows a single keyword option,
:tangle-mode, to accept a few different ways of setting file
permissions. I'm not sure that amounts to formalizing representation of
numbers in Org, or even modifying Org grammar as such. (And I can't
think of other parts of Org where this would be relevant, so I wouldn't
expect demands for further feature creep.)

> With an eye to future portability I suggest
> that no special cases be given to something as important for security
> as tangle mode without very careful consideration.

When you say portability, what are you thinking about? If you're talking
about tangling Org-Babel code with other processors than Emacs Org-mode,
this seems like fairly trivial functionality to reproduce. In fact,
wouldn't this be easier than the current arrangements, which would
require the processor to be able to evaluate an arbitrary Emacs Lisp
expression outside Emacs?

What is the added security problem here, given that file permissions can
already be set by tangle mode?

I suppose that the greater complexity of the patch provides maintainers
with somewhat more opportunities for making code errors. And the greater
choice of representations perhaps gives the user more opportunities for
making user errors (though speaking strictly for myself, I'm more likely
to make those errors calculating octals than using the more intuitive
representations Timothy is helpfully making available). But these
problems seem marginal to me. Are there others?

> Emacs lisp closures have clear semantics in Org and the number syntax
> is clear. If users are concerned about the verbosity of (identity
> #o0600) they could go with the sorter (or #o0600).

But why would anyone want to write a lisp closure a number literal would
suffice? It's not what a user would expect.

Yours,
Christian



reply via email to

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