From: Timothy <email@example.com> To: Tim Cross <firstname.lastname@example.org> Cc: email@example.com Subject: Re: [PATCH] Accept more :tangle-mode specification forms Date: Sat, 20 Nov 2021 16:08:16 +0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 3195 bytes --] Hi Tom, Tim, Thomas, and Greg, Thank you all for your thoughts. I’ll try to respond to all the main points raised below. First off, in case it wasn’t clear in my earlier email when I said “#o555 works” or the like I was being lazy and really meaning “(identity #o555)” works. 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”. ┌──── │ 1 -> (org-babel-parse-header-arguments ":tangle-mode 555" light) │ 1 <- org-babel-parse-header-arguments: ((:tangle-mode . 555)) │ ====================================================================== │ 1 -> (org-babel-parse-header-arguments ":tangle-mode o555" light) │ 1 <- org-babel-parse-header-arguments: ((:tangle-mode . "o555")) └──── So while I’d like it if we could easily apply Tom’s suggestion to “change the radix for bare integers to 8 when reading that particular header”, I don’t think that’s very feasible, unfortunately. 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. 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. 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. 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. 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——-). 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. All the best, Timothy
next prev parent reply other threads:[~2021-11-20 11:02 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 [this message] 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 \ --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).