From: Tim Cross <theophilusx@gmail.com>
To: Timothy <tecosaur@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Accept more :tangle-mode specification forms
Date: Sun, 21 Nov 2021 06:49:21 +1100 [thread overview]
Message-ID: <87ee7a5xif.fsf@gmail.com> (raw)
In-Reply-To: <874k87850s.fsf@gmail.com>
Timothy <tecosaur@gmail.com> writes:
> The parsing of “555” to the integer 555 is done by
> org-babel-parse-header-arguments, and so can’t really be changed. For a simple
> octal notation our best bet is adding non-digit characters so it is left as a
> string, e.g. “o555”.
I don't understand this. Why can't it be changed? Doing so may not be
trivial, but I cannot see any reason it cannot be changed if we wanted
to. However, perhaps all we really need to do is look at the value
returned and if the value for mode is not a string, throw an error and
if it is a string, either match symbolic format or verify it has a
leading 'o' or '#o' and treat as octal, else throw an error.
> Giving errors when a base 10 value has been given by accident would be a nice
> idea, but in practice isn’t easy as many base 10 values are valid octal values,
> e.g. #o555 = 365. Likewise, I don’t think Tim’s suggestion of disallowing base
> 10 values is feasible.
>
Did you mean many base 10 values are valid mode setting values? All base
10 values can be expressed in octal, so I'm assuming you meant some base
10 values will translate into octal values which are valid mode setting
values. My point here is that such translations are unlikely to be what
the user expected.
I have never seen anyone use base 10 to specify mode settings. It takes
a lot more mental agility to derive a base 10 version for a valid mode
setting than it does to use octal, which has a clear and natural mapping
of the octal characters to the underlying bits used to represent the
mode for user, grop and other (as well as setuid, setgid and sticky
bit).
When I said disable base 10 values, what I meant was generate an error
if the value looks like it is base 10 i.e. does not have a leading o or
#o. This makes it clear it has to be specified as an octal value and
will alert users to this fact.
> Regarding the concern that “we are making a rod for our back by trying to make
> this overly clever” and that the change makes it too complex — I disagree.
> Having had this discussion earlier we’ve ended up with,
> • a shorthand for octal
> • ls-style
> • chmod-style
> I think this small collection of distinct and simple input methods isn’t overly
> clever or complex, and feel that it strikes the right balance between too many
> options and too little flexibility.
>
We will probably have to disagree here as I remain unconvinced. I guess
time will tell.
> Octal is great, for those that are familiar with it. Likewise, chmod-style is
> quite natural for those who are used to chmod. There’s little added complexity
> to the Org code base as we simply pass this to the Emacs function
> file-modes-symbolic-to-number. I think the ls-style is quite valuable for two
> reasons. It’s well-established thanks to ls, and is particularly good for
> understanding permissions at a glance.
I would agree it is an established way to display the permissions
associated with a filesystem object, but disagree it is a well
established way to set such values - I know of no other tool which uses
this format. It is also not the same as the ls -l display (no object
type indicator). The ls -l also displays sticky bit, uid and gid. Does
your format also support setting these values (something which can be
done with the octal or symbolic formats) i.e. support s, S, t and T for
the 'executable' bit for user/group?
>For reading Org files I think this is
> advantageous compared to the other styles. I’m don’t find assertions that this
> is non-typical or unpredictable well-founded. Each style/syntax is well-defined,
> simple, distinct, and taken from very common/wide spread usage.
>
Again, I know of no other tool which uses the ls -l format to set file
mode permissions, so I cannot agree with the assertion it is well
established. Personally, I prefer the symbolic form as it is shorter and
clear. I find the ls -l form too easy to get wrong (especially with
getting the number of '-' correct).
> Tim suggested that invalid forms should cause tangling to fail, but I feel this
> may be a bit much. Personally I’m inclined to either
> • warn, and don’t touch the file permissions (this is what currently occurs)
> • use a very conservative file permission (e.g. rw——-).
I'm unsure on this. My concern is people may not notice the warning and
then be surprised later. Given the potential security issues, a later
surprise is something to be avoided even if it is inconvenient. With
respect to the default action to take, I would suggest we also need to
look at the default umask setting for the user and if that is more
restrictive, use that rather than some value like rw------- For all we
know, the user has set a specific umask for a valid reason and will be
surprised if emacs just ignores that to do what it wants (another
surprise to be avoided).
The user is not required to specify a mode. However, if they do and if
we cannot interpret what they have specified without ambiguity, we
should throw an error and cease processing. Making a guess as to what
they intended in this situation is IMO a big mistake.
>
> So, as I see it the main decision that needs to be made is how to handle the
> octal shorthand, now that it’s clear that the original plan is flawed? I’m
> thinking either “o555” or “#o555” would be a good improvement over “(identity
> #o555), but am open to other suggestions.
>
I agree the (identity ...) approach doesn't feel terribly 'natural'.
My only preference for "#o" over just "o" prefix is to clearly signal to
the user that it is an octal value and avoid the situation where you
might glance a value and see the leading 'o' as a '0', missing the point
it is an octal value not a decimal one. However, this seems like a low
risk, so I'm happy either way.
next prev parent reply other threads:[~2021-11-20 21:27 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
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 [this message]
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=87ee7a5xif.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=tecosaur@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).