John Kitchin <jkitc...@andrew.cmu.edu> writes:
> 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 <theophil...@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. > If this does work without unwanted side effects or negative performance impact, then it probably should be considered for inclusion in org as it seem pretty clean and straight-forward. I have to wonder why it hasn't given how long this issue has been known about?