From: Timothy <tecosaur@gmail.com>
To: Tom Gillespie <tgbugs@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [PATCH] Accept more :tangle-mode specification forms
Date: Fri, 01 Oct 2021 14:59:35 +0800 [thread overview]
Message-ID: <87a6jtjj20.fsf@gmail.com> (raw)
In-Reply-To: <CA+G3_PODiQjsTasVcHw=sbsY31qgg834nCPAzvJ0_QmF1G-vxA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2738 bytes --]
Hi Tom,
Thanks for giving me your thoughts on this. I have a few thoughts in response :)
> 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’m not quite sure I see your point here, as I don’t see how this affects the
grammar of Org at all. The :attribute value syntax is unaffected, this just
changes how a particular :attribute’s value is interpreted. Attribute specific
interpretation is normal, with “:file ~/hello” you expect `~' to be interpreted as
`$HOME', but were I to give “:session ~/hello” I would not expect `~' to be
expanded etc.
Similarly, with regard to the representation of numbers, I’m not sure that
applies here, as the value is still a string not a number, it’s just
interpreted. Arguably, we’re not even representing numbers here but representing
file permissions which are currently abstracted by a numerical representation.
> With an eye to future portability I suggest that no special cases be given to
> [snipped for later] tangle mode without very careful consideration.
Mmmm, we defiantly want to think about what options we allow for, but I don’t
think that precludes us from accepting more than one common permissions
representations.
> [the snip]: something as important for security as tangle mode
Thank you for considering potential security implications, this is something
that I didn’t consider when writing the patch, but if we allow for a confusing
format that could deceive people into tangling files in modes they didn’t
realise they were tangling to.
I think there are two relevant points here
⁃ If we only allow very widely-understood, standard representations, I think the
risk of people misunderstanding a :tangle-mode value is acceptably low
⁃ If you consider things this way, since arbitrary lisp closures are currently
permitted, one can already trivially create a much more misleading
:tangle-mode value with the current code.
> Emacs lisp closures have clear semantics in Org and the number syntax is clear
See my earlier comments on the semantics being unaffected, and this not being a
number syntax.
> If users are concerned about the verbosity of (identity #o0600) they could go
> with the sorter (or #o0600).
Perhaps, but I personally find it easier to interpret “rwxr-xr–” for example
than “(or #o754)”, and I feel quite confident in guessing that
a. I’m not alone
b. Nobody that understands “#o754” will have difficult understanding “rwxr-xr–”
All the best,
Timothy
next prev parent reply other threads:[~2021-10-01 7:34 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 [this message]
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
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=87a6jtjj20.fsf@gmail.com \
--to=tecosaur@gmail.com \
--cc=emacs-orgmode@gnu.org \
--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).