From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6HqbEFxomWFLZQEAgWs5BA (envelope-from ) for ; Sat, 20 Nov 2021 22:27:56 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id KIdODFxomWFRZgAAB5/wlQ (envelope-from ) for ; Sat, 20 Nov 2021 21:27:56 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AD5C55565 for ; Sat, 20 Nov 2021 22:27:55 +0100 (CET) Received: from localhost ([::1]:47502 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1moXtp-0001CM-Lk for larch@yhetil.org; Sat, 20 Nov 2021 16:27:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59290) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1moXsy-0001CB-B2 for emacs-orgmode@gnu.org; Sat, 20 Nov 2021 16:27:00 -0500 Received: from [2607:f8b0:4864:20::52d] (port=35409 helo=mail-pg1-x52d.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1moXsw-00072O-8S for emacs-orgmode@gnu.org; Sat, 20 Nov 2021 16:27:00 -0500 Received: by mail-pg1-x52d.google.com with SMTP id p17so11691780pgj.2 for ; Sat, 20 Nov 2021 13:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=Bel8t6zZ55FRnduoa0Og06XF2PPQ8LR8lwhgtobyFv0=; b=gaY0nubLI+Q5E5tsgzVXskFwBXSrXmeO6qmH1vn1Y8fzMxY0nyW/9m7MEXCm0fZvHX HHu2cXPMxTSM2N1kPi+YDqxQRunECJRBl/3ThZ+p9zd2dAsgOIZRIWXKnygt95Vu1FHY 4qL7ZugDgGfYgpkFcG1+uAVbVBto1735F2+cYNVtch7HGcUXj2Hmn+qNaciVm7NLtN8K w4oX8Ze7D6j/rKRrmV/B2ezVLkLJ0J6U5jn/cJSTXymKvtkziGxi/ngEiPcP5W/upTZ+ 1bkllorTLWFeLtn2K/UUaUtmNkl+nGp0HExgFGQ/l+lVMDh5Q4t7dtg/4g/qhvTBm7uO DtsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=Bel8t6zZ55FRnduoa0Og06XF2PPQ8LR8lwhgtobyFv0=; b=1rFnPA7jJKoiJwu7d7jyptpGjFFpoR7slmoO0wTjvq/RQKVRIgYdjqycAmiTBbeMb0 W6Gnm3Mgz8BXghQSfXQeM8fL2ecYr2HSXAiH7FEABy2D4HVPQu93yp9APNQBB4uVPeE3 tQQ6E5/RecosvC0mEKaOiII8B2qsVIpQpKOrqPSQc4RPOrPEUr+VvYeE7VSqUPLnYsTj r0nLc/ILxEjtRzAUTAOtHtoBdovJNFMi2F9sVOCNHqJTACUVj+tAuJKQHKWgEUa3Bz1o qSRS1V1LYepCVZmsuU8JWPMiWrywhugS5tzNsbmzLvm20WLO9vyv1x2ttay7vB39KFTO e97A== X-Gm-Message-State: AOAM531c6o45akI//eDitXTayOIndmogjBY4ic6yeS4q0rKGKrUmcWfp tM/S3OG4USKKY2d7Bhg+mtyAIx0kIHs= X-Google-Smtp-Source: ABdhPJyxt+go5rKtRPwUG/idJn25ECN5wpaMlYngWsl8Op39wyAvjS8y1rP8+sEmpwYGsmoipvWO3w== X-Received: by 2002:a62:18d2:0:b0:4a2:b2d0:c39f with SMTP id 201-20020a6218d2000000b004a2b2d0c39fmr52074204pfy.69.1637443616096; Sat, 20 Nov 2021 13:26:56 -0800 (PST) Received: from dingbat (2001-44b8-31f2-bb00-dc3a-49a1-b037-9957.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:dc3a:49a1:b037:9957]) by smtp.gmail.com with ESMTPSA id c6sm3468473pfd.114.2021.11.20.13.26.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 20 Nov 2021 13:26:55 -0800 (PST) References: <875yuh9b3t.fsf@gmail.com> <87czojh6m4.fsf@gmail.com> <8735ntg3ve.fsf@gmail.com> <87mtm1e5lt.fsf@gmail.com> <87pmqwt6zi.fsf@gmail.com> <874k87850s.fsf@gmail.com> User-agent: mu4e 1.7.5; emacs 28.0.60 From: Tim Cross To: Timothy Subject: Re: [PATCH] Accept more :tangle-mode specification forms Date: Sun, 21 Nov 2021 06:49:21 +1100 In-reply-to: <874k87850s.fsf@gmail.com> Message-ID: <87ee7a5xif.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::52d (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::52d; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x52d.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1637443675; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=Bel8t6zZ55FRnduoa0Og06XF2PPQ8LR8lwhgtobyFv0=; b=lJ3SacMd9rcQz8DoxnMJkHh8XDo8e1MwP0uYJMkGdgaTIONvddsIVjby75xgh+NPxM6y54 E0EV312B1zVBjex2u5M7r3MGn0/pm/J0uRLXBuk3B2N1cYriscecQP75Hikz1jmvSLNLrt qcHTrdmLmSe0X3Uy3jpEYXbhOzpOUBHLbIP6hBp7Se/4DQ+kJ0QNFYyVI2kTSCg71ujHwT wstQFZQ0GmwFbpo7w7qhj77iQ3aEhSZhoFCNstddiJbiTryJjnDTukqQgl37rYAQ8K1+vq QXMUW9wzxyJCeVdEKFVUhpV1gztq75VLcpi+xOicZV4ow8goWb75Vb0oS3s1ZQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1637443675; a=rsa-sha256; cv=none; b=gPF912sdHrkxEklcck45RljkJim5e3lLNx3MbVB0ubApfAGqyqkH7AvGnKC6G04pQIZNSn KcQhQ0jkvCfdLjc82a8Zrq5EqrwpktrhIE7gDz5SJioCKgKJcQNc1J65i543I1/oM2MPNT tKIlimdDpwSiqEalj2Ll1PG2ANZcGL+lu9kzEoiFKwB37jhnkk06fF4BSrZzVO+RedOjJ4 Z1QztQ0wbyizylUNYCTPnFP/ldaaRH0ELXfroCvl+a3vjSrfUsOkXgbRi/Ey8pFr+Zvhse bUqdqllAnlorxDK4WqoTegyn3ZFOdpkJ6Any+/yFHh/7ZfUmojDkZuvqtEWqqw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gaY0nubL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.07 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gaY0nubL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: AD5C55565 X-Spam-Score: -4.07 X-Migadu-Scanner: scn0.migadu.com X-TUID: L90occOxw6Ac Timothy writes: > The parsing of =E2=80=9C555=E2=80=9D to the integer 555 is done by > org-babel-parse-header-arguments, and so can=E2=80=99t 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. =E2=80=9Co555=E2=80=9D. 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.=20 > Giving errors when a base 10 value has been given by accident would be a = nice > idea, but in practice isn=E2=80=99t easy as many base 10 values are valid= octal values, > e.g. #o555 =3D 365. Likewise, I don=E2=80=99t think Tim=E2=80=99s suggest= ion 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.=20 > Regarding the concern that =E2=80=9Cwe are making a rod for our back by t= rying to make > this overly clever=E2=80=9D and that the change makes it too complex =E2= =80=94 I disagree. > Having had this discussion earlier we=E2=80=99ve ended up with, > =E2=80=A2 a shorthand for octal > =E2=80=A2 ls-style > =E2=80=A2 chmod-style > I think this small collection of distinct and simple input methods isn=E2= =80=99t 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-styl= e is > quite natural for those who are used to chmod. There=E2=80=99s little add= ed 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=E2=80=99s 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=E2=80=99m don=E2=80=99t find= assertions that this > is non-typical or unpredictable well-founded. Each style/syntax is well-d= efined, > 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 fee= l this > may be a bit much. Personally I=E2=80=99m inclined to either > =E2=80=A2 warn, and don=E2=80=99t touch the file permissions (this is wha= t currently occurs) > =E2=80=A2 use a very conservative file permission (e.g. rw=E2=80=94=E2=80= =94-). 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.=20 > > So, as I see it the main decision that needs to be made is how to handle = the > octal shorthand, now that it=E2=80=99s clear that the original plan is fl= awed? I=E2=80=99m > thinking either =E2=80=9Co555=E2=80=9D or =E2=80=9C#o555=E2=80=9D would b= e a good improvement over =E2=80=9C(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.=20