My previous solution seems like it stopped working for some reason. Here is a new version that "should" only change syntax inside src-blocks, but not inside strings. It looks like this does not impact html blocks, or xml blocks. It is probably possible to make it mode specific if needed. (defun scimax-org-mode-<>-syntax-fix (start end) "Change syntax of characters ?< and ?> to symbol within source code blocks." ;; I think this gets run in a special edit buffer for src-blocks. For now I ;; only run this in the src blocks, so that outside the src-blocks these still ;; act like b=open/close brackets. (when (org-src-edit-buffer-p) (let ((case-fold-search t)) (goto-char start) ;; this "fixes" <>, {} and [] that fixes some issues in src blocks, but ;; makes some new issues, which is now you cannot use them as brackets. ;; this tries to be fancy and not change the syntax in strings. (while (re-search-forward "[[<{]\\|[]>}]" end t) (unless (ppss-string-terminator (syntax-ppss (point))) (put-text-property (point) (1- (point)) 'syntax-table (string-to-syntax "_"))))))) (defun scimax-fix-<>-syntax () "Fix syntax of <> in code blocks. This function should be added to `org-mode-hook' to make it work." (setq syntax-propertize-function 'scimax-org-mode-<>-syntax-fix) (syntax-propertize (point-max))) (add-hook 'org-mode-hook #'scimax-fix-<>-syntax) John ----------------------------------- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Fri, Sep 3, 2021 at 9:47 AM Tim Cross wrote: > > I think what is happening here is that org is bumping up against > fundamental design limitations of Emacs. In basic terms, much of Emacs' > underlying design is based on an assumption that a file only has a > single major mode. Org works hard to get around this limitation, but it > comes with cost - usually either performance or complexity. > > I think this could probably be characterised as a bug without a workable > solution. While there are things youc an do, they all seem to have > unwanted side effects. To what extent those side effect impact you > depends on your use case (as John points out, if you have blocks of HTML > or XML or JSX etc, changing the syntax table to make < and > 'normal' > characters would fix the elisp issue, but break things in those source > blocks. > > So really, what we have is an issue without a clean solution. Best > anyone can do is select one of the proposed work-arounds which has > minimal impact on the user. Personally, I never edit source blocks > except in the special edit mode, so don't really notice the problem with > mismatched parens. > > John Kitchin writes: > > > That is probably a matter of opinion. > > > > If you use angle brackets as delimiters, e.g. in html, xml in > src-blocks, then the current syntax definition makes sense because > > you can use them to find open and closing brackets, navigate them, etc.. > If you don't use those, it makes less sense, and maybe > > isn't even something you want. > > > > John > > > > ----------------------------------- > > Professor John Kitchin (he/him/his) > > Doherty Hall A207F > > Department of Chemical Engineering > > Carnegie Mellon University > > Pittsburgh, PA 15213 > > 412-268-7803 > > @johnkitchin > > http://kitchingroup.cheme.cmu.edu > > > > On Fri, Sep 3, 2021 at 7:42 AM Charles Millar > wrote: > > > > Thank you, John. > > > > I will give it a try. > > > > However, is this a bug that should be fixed within org source code? > > > > Charlie Millar > > > > On 9/2/21 2:24 PM, John Kitchin wrote: > > > I think this issue is described in > > > > https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch > . > > > There are also some solutions there. > > > > > > > > > John > > > > > > ----------------------------------- > > > Professor John Kitchin (he/him/his) > > > Doherty Hall A207F > > > Department of Chemical Engineering > > > Carnegie Mellon University > > > Pittsburgh, PA 15213 > > > 412-268-7803 > > > @johnkitchin > > > http://kitchingroup.cheme.cmu.edu > > > > > > > > > > > > On Thu, Sep 2, 2021 at 2:10 PM Charles Millar > wrote: > > > > > >> Set up: > > >> GNU Emacs 28.0.50 (build 344, x86_64-pc-linux-gnu, GTK+ Version > 3.24.23, > > >> cairo version 1.16.0) of 2020-12-31 > > >> Org mode version 9.4.6 (release_9.4.6-637-gd70f28 @ > > >> /usr/local/share/org-mode/lisp/) > > >> > > >> The following code will evaluate > > >> > > >> #+begin_src emacs-lisp > > >> (defun Foo () > > >> (if (= 2 4) bar)) > > >> #+end_src > > >> > > >> #+RESULTS: > > >> : Foo > > >> and the opening and closing parentheses match. > > >> > > >> If a greater than is inserted instead of equals, thus > > >> > > >> #+begin_src emacs-lisp > > >> (defun Foo () > > >> (if (> 2 4) bar)) > > >> #+end_src > > >> > > >> it apparently evaluates, however, the closing parenthesis immediately > > >> following the "4" is paired with the opening paren before "if" and > not > > >> the opening paren immediately before the ">" > > >> > > >> A "less than" results with stranger parenthesis matching - the > closing > > >> paren after the "4" matches no others; the closing paren immediately > > >> after "bar" matches the opening paren before "if" > > >> > > >> Charlie Millar > > >> > > >> > > >> > > >> > > > > > >