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