From: Christian Moe <mail@christianmoe.com>
To: Tom Gillespie <tgbugs@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>, Timothy <tecosaur@gmail.com>
Subject: Re: [PATCH] Accept more :tangle-mode specification forms
Date: Fri, 01 Oct 2021 10:39:07 +0200 [thread overview]
Message-ID: <87sfxl6swk.fsf@christianmoe.com> (raw)
In-Reply-To: <CA+G3_PODiQjsTasVcHw=sbsY31qgg834nCPAzvJ0_QmF1G-vxA@mail.gmail.com>
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
next prev parent reply other threads:[~2021-10-01 8:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-30 18:14 [PATCH] Accept more :tangle-mode specification forms Timothy
2021-10-01 1:24 ` Tom Gillespie
2021-10-01 6:59 ` Timothy
2021-10-01 8:00 ` Stefan Nobis
2021-10-01 10:05 ` Eric S Fraga
2021-10-01 10:29 ` tomas
2021-10-01 18:04 ` Tom Gillespie
2021-10-01 18:14 ` Timothy
2021-10-01 8:39 ` Christian Moe [this message]
2021-10-05 14:45 ` Timothy
2021-10-05 15:54 ` unknown@email.com
2021-10-05 16:13 ` Timothy
2021-10-05 16:06 ` tomas
2021-10-06 11:59 ` Max Nikulin
2021-11-18 10:20 ` Timothy
2021-11-18 17:22 ` Timothy
2021-11-18 23:33 ` Tom Gillespie
2021-11-19 16:31 ` Tim Cross
2021-11-19 18:10 ` tomas
2021-11-20 4:31 ` Greg Minshall
2021-11-20 8:08 ` Timothy
2021-11-20 12:25 ` tomas
2021-11-20 14:50 ` Timothy
2021-11-20 16:09 ` tomas
2021-11-20 21:32 ` Tim Cross
2021-11-21 4:08 ` Greg Minshall
2021-11-21 4:27 ` Timothy
2021-11-21 5:11 ` Greg Minshall
2021-11-20 19:49 ` Tim Cross
2021-11-21 4:02 ` Timothy
2021-11-21 13:51 ` Tim Cross
2021-11-21 14:33 ` Timothy
2021-11-29 18:57 ` Timothy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sfxl6swk.fsf@christianmoe.com \
--to=mail@christianmoe.com \
--cc=emacs-orgmode@gnu.org \
--cc=tecosaur@gmail.com \
--cc=tgbugs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).