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


On Fri, Sep 3, 2021 at 9:47 AM Tim Cross <theophilusx@gmail.com> 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 <jkitchin@andrew.cmu.edu> 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 <millarc@verizon.net> 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 <millarc@verizon.net> 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
>  >>
>  >>
>  >>
>  >>
>  >