From: Timothy <tecosaur@gmail.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Accept more :tangle-mode specification forms
Date: Sun, 21 Nov 2021 12:02:07 +0800 [thread overview]
Message-ID: <87wnl26sxv.fsf@gmail.com> (raw)
In-Reply-To: <87ee7a5xif.fsf@gmail.com>
Hi Tim,
>> The parsing of “555” to the integer 555 is done by
>> org-babel-parse-header-arguments, and so can’t really be changed.
>
> I don't understand this. Why can't it be changed?
Well, it can't be changed without changing
org-babel-parse-header-arguments, which is quite a major change and I
suspect may be a breaking change.
Maybe it's fine? I just don't feel confident about this.
> 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.
This is all well and good, but the point I'm making is that since due to
the current behaviour of org-babel-parse-header-arguments we can't
distinguish between :tangle-mode (identity #o555) and :tangle-mode 365
putting this idea /into practice/ doesn't look like it will be easy.
It's also worth noting that with regard to the recent changes that have
been made, this is not a new issue.
>> 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.
The driving motivation here is that while the tools which you mention do
not use this for setting permissions (e.g. chmod), they are only used
for /setting/ permissions. Since Org files aren't write-only, and
occasionally we go back and look at what we've written :P I think
allowing a format that is optimised for ease-of-reading instead of
ease-of-writing makes some sense. It is in this respect that I think
ls -l style is a good idea.
> 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?
Ah, I'm afraid that I'm not that up-together on sticky bits. I suspect
that it's not just the ls -l style that will need tweaking. I'll read up
on this in the next few days and update the ML.
> 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).
Isn't choice a great thing? :D In seriousness, this is exactly why I
think it's worth providing these options. At least thinking back to when
I started using Linux a few years ago I would have said the same thing
about the octal form, and was completely unfamiliar with chmod. I expect
different people to have different preferences with these three options,
but for one of them to be something most people are happy with.
>> 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.
I don't see how using the default permissions is a potential security
risk? Could it surprise the user, yes, but that seems unavoidable when
the user is doing something invalid.
> 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.
Well, I've got "o" for now but that's not set in stone. With a lower
case "o" I feel the risk for confusion with "0" is quite low (besides
which a "0" prefix seems to be the C-style for octal anyway).
All the best,
Timothy
next prev parent reply other threads:[~2021-11-21 4:20 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 ` 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 [this message]
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=87wnl26sxv.fsf@gmail.com \
--to=tecosaur@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=theophilusx@gmail.com \
--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).