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: Sat, 20 Nov 2021 16:08:16 +0800 [thread overview]
Message-ID: <874k87850s.fsf@gmail.com> (raw)
In-Reply-To: <87pmqwt6zi.fsf@gmail.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 [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 [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 \
--in-reply-to=874k87850s.fsf@gmail.com \
--to=tecosaur@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=theophilusx@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).