Re: bug processing non emacs-lisp blocks
Hello, dmg writes: > org-babel-load-file will try to tangle any source block that contains > the substring emacs-lisp or elisp in their language. > > For example, the following code block will be tangled: > > #+begin_src emacs-lispDONOT > (use-package "org-sidebar") > #+end_src > > the following patch fixes that problem. The Regular expression should > be more stringent, so it does match exactly the string and not a > substring. Thank you. I applied an equivalent patch. Regards, -- Nicolas Goaziou
Re: bug processing non emacs-lisp blocks
On 29/07/2021 11:13, Tim Cross wrote: dmg writes: org-babel-load-file will try to tangle any source block that contains the substring emacs-lisp or elisp in their language. For example, the following code block will be tangled: #+begin_src emacs-lispDONOT (use-package "org-sidebar") #+end_src I think this is a regression. I used to comment out blocks from my .org init files by simply adding a XXX (as in emacs-lisp). In current org these blocks are tangled :( I think your right. The regexp should only match on complete string. I agree as well. Related code changed in 9.4: - https://orgmode.org/list/caloshornnlxjma6jnrt-ikie-b9f9o3clqdxfekrzvyiyze...@mail.gmail.com/T/#u - https://code.orgmode.org/bzg/org-mode/commit/be93859c78 The following is just my opinion, not a request for an update of the patch. Maybe it will be better to change `org-babel-tangle-collect-blocks' function in lisp/ob-tangle.el instead and to wrap passed argument in the suggested way (at first I thought of non-capturing group "\\(?:" "\\)", but it is not necessary since the regexp is passed to `string-match-p'). I suppose, it is more reliable default. If anyone really needs partial match, he may express it explicitly by adding ".*", "?", etc. I hope, such change will break no existing code.
Re: bug processing non emacs-lisp blocks
dmg writes: > org-babel-load-file will try to tangle any source block that contains > the substring emacs-lisp or elisp in their language. > > For example, the following code block will be tangled: > > #+begin_src emacs-lispDONOT > (use-package "org-sidebar") > #+end_src > > the following patch fixes that problem. The Regular expression should > be more stringent, so it does match exactly the string and not a > substring. > > I think this is a regression. I used to comment out blocks from my > .org init files by simply adding a XXX (as in emacs-lisp). In > current org these blocks are tangled :( I think your right. The regexp should only match on complete string. BTW an easy way to comment out code blocks from tangling is to just add :tangle no to the header. This will work better because the code block will still work for editing etc and have correct syntax highlighting etc. Regards, Tim -- *Tim Cross* /For gor sake stop laughing, this is serious!/
bug processing non emacs-lisp blocks
org-babel-load-file will try to tangle any source block that contains the substring emacs-lisp or elisp in their language. For example, the following code block will be tangled: #+begin_src emacs-lispDONOT (use-package "org-sidebar") #+end_src the following patch fixes that problem. The Regular expression should be more stringent, so it does match exactly the string and not a substring. I think this is a regression. I used to comment out blocks from my .org init files by simply adding a XXX (as in emacs-lisp). In current org these blocks are tangled :( -- --dmg --- D M German http://turingmachine.org patch Description: Binary data
