From: Tim Cross <firstname.lastname@example.org> To: Timothy <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [PATCH] Accept more :tangle-mode specification forms Date: Sun, 21 Nov 2021 06:49:21 +1100 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Timothy <email@example.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 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 ` firstname.lastname@example.org 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] Accept more :tangle-mode specification forms' \ /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
Code repositories for project(s) associated with this 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).