From: Nicolas Goaziou <firstname.lastname@example.org> To: Tom Gillespie <email@example.com> Cc: emacs-orgmode <firstname.lastname@example.org> Subject: Re: Bug: inconsistent escaping of coderef regexp Date: Thu, 01 Apr 2021 17:45:34 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CA+G3_PMLuRTmm0xKVazUJTBmbnRngfm5E0Wkzcr5BNjLSGuaAQ@mail.gmail.com> (Tom Gillespie's message of "Mon, 4 Jan 2021 15:33:19 -0500") Hello, Tom Gillespie <firstname.lastname@example.org> writes: > It is not possible to strip coderefs when tangling and also search for > those coderefs using org-link-search. This is because org-link-search > uses org-src-coderef-regexp which calls regexp-quote on the regexp > string while org-babel-tangle-single-block does not and uses the > regexp string directly without quoting it. I'm not sure about the best > way to fix this. It seems to me that the call to regexp-quote should > be removed but I'm not entirely sure of the consequences of doing > that. Thoughts? This would be wrong. A format string is not a regexp, and therefore needs to be quoted. E.g., one might want to use "/* %s */". `org-babel-tangle-single-block' should make use of `org-src-coderef-regexp' and, possibly, `org-src-coderef-format'. > PS While on the topic of coderefs, let me drop a note that is a > preview of some of the issues I have encountered while working on a > full formal grammar for org. Having the -l switch control this is an > awful design that induces more complexity into the org-mode grammar > than nearly any other feature. Source block switches are completely > inconsistent with the rest of org and completely undiscoverable. I had > no idea they even existed until I was trying to figure out which > header argument could be used to set the coderef regexp. The -l option > and switches in general need to have their behavior implemented as > part of the standard header arguments like everything else so that > users can migrate away from switches with an eye toward removing them > entirely. Switches predate Babel and its header arguments. Also, they are orthogonal to Babel. I don't know what a sound design would be here, tho. Regards, -- Nicolas Goaziou
next prev parent reply other threads:[~2021-04-01 15:46 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-04 20:33 Tom Gillespie 2021-04-01 15:45 ` Nicolas Goaziou [this message] 2021-04-01 16:09 ` Timothy 2021-04-04 22:01 ` Tom Gillespie 2021-04-04 23:12 ` Nicolas Goaziou 2021-04-05 5:22 ` Tom Gillespie 2021-04-05 7:42 ` Tom Gillespie 2021-04-07 17:58 ` Nicolas Goaziou 2021-04-07 19:44 ` Tom Gillespie 2021-04-09 22:19 ` Nicolas Goaziou
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: Bug: inconsistent escaping of coderef regexp' \ /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).