Greater than, less than bug in emacs-lisp source block

Greater than, less than bug in emacs-lisp source block

[Charles Millar]

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

Re: Greater than, less than bug in emacs-lisp source block

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

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
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2315 bytes --]

Re: Greater than, less than bug in emacs-lisp source block

[Arthur Miller]

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> 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.

I wasn't able to get that to work in my Emacs. I did something simpler though,
that seems to work for me:

#+begin_src emacs-lisp
(defmacro gt (n1 n2)
  `(> ,n1 ,n2))

(defmacro gte (n1 n2)
  `(>= ,n1 ,n2))

(defmacro lt (n1 n2)
  `(< ,n1 ,n2))

(defmacro lte (n1 n2)
  `(<= ,n1 ,n2))

;; example usage

(dolist (s templist)
 (while (lt (length s) l)
 (setq s (concat s " ")))
 (push (concat "[ " s " ]") kwdlist))

#+end_src

re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Charles Millar]

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
>>
>>
>>
>>
> 

Fwd: Greater than, less than bug in emacs-lisp source block

[Charles Millar]

Thank you, Arthur.


-------- Forwarded Message --------
Subject: Re: Greater than, less than bug in emacs-lisp source block
Date: Fri, 03 Sep 2021 00:36:23 +0200
From: Arthur Miller <arthur.miller@live.com>
To: John Kitchin <jkitchin@andrew.cmu.edu>
CC: Charles Millar <millarc@verizon.net>, emacs-orgmode@gnu.org 
<emacs-orgmode@gnu.org>

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> 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.

I wasn't able to get that to work in my Emacs. I did something simpler 
though,
that seems to work for me:

#+begin_src emacs-lisp
(defmacro gt (n1 n2)
   `(> ,n1 ,n2))

(defmacro gte (n1 n2)
   `(>= ,n1 ,n2))

(defmacro lt (n1 n2)
   `(< ,n1 ,n2))

(defmacro lte (n1 n2)
   `(<= ,n1 ,n2))

;; example usage

(dolist (s templist)
  (while (lt (length s) l)
  (setq s (concat s " ")))
  (push (concat "[ " s " ]") kwdlist))

#+end_src

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

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
> >>
> >>
> >>
> >>
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 3929 bytes --]

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Tim Cross]

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
>  >>
>  >>
>  >>
>  >>
>  > 

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[John Kitchin]

[-- Attachment #1: Type: text/plain, Size: 5659 bytes --]

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 <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
> >  >>
> >  >>
> >  >>
> >  >>
> >  >
>
>
>

[-- Attachment #2: Type: text/html, Size: 8130 bytes --]

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Tim Cross]

John Kitchin <jkitchin@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 <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.
>

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?

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Arthur Miller]

Tim Cross <theophilusx@gmail.com> writes:

> John Kitchin <jkitchin@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 <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.
>>
>
> 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 haven't tested the updated version of JK's proposal, but looking at the source
it seems to be a tad bit resource heavy. If it isn't a hassle for the OP to use
aliases like lt, gt or similar, I would suggest that either using macros or
simple defalias to rename those few functions, <,<=,> and >= is more resource
effective way. If code is tangled and byte compiled, macros will be expanded in
byte code, so effectively the runtime cost is almost none.

>                                         I have to wonder why it hasn't
> given how long this issue has been known about?

That is a good question, maybe proper solution is very hard if not impossible?
Like you said, Emacs is really not meant to be used with several major modes
active as once. Seems like this is one of those places where it shows off.

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Tim Cross]

Arthur Miller <arthur.miller@live.com> writes:

> I haven't tested the updated version of JK's proposal, but looking at the source
> it seems to be a tad bit resource heavy. If it isn't a hassle for the OP to use
> aliases like lt, gt or similar, I would suggest that either using macros or
> simple defalias to rename those few functions, <,<=,> and >= is more resource
> effective way. If code is tangled and byte compiled, macros will be expanded in
> byte code, so effectively the runtime cost is almost none.
>

Have to say I really don't like that proposal as a work-around. Main
reason is that it obscures the code intent (readers of the code need to
know 'gt" means greater than while '>' intention is much clearer) and it
requires all code generated (such as via tangle) to include the macro
definitions. However, above all, it just feels wrong to require code
alteration in order to address a limitation in the tool being used to
create the code.

>>                                         I have to wonder why it hasn't
>> given how long this issue has been known about?
>
> That is a good question, maybe proper solution is very hard if not impossible?
> Like you said, Emacs is really not meant to be used with several major modes
> active as once. Seems like this is one of those places where it shows off.

That is my suspicion as well, but I'm wasn't sure as I don't understand
the internals sufficiently to assess the impact of the regex search. I do
think the underlying point is correct i.e. adjusting the syntax table
entry for the < and > characters. This would seem to be the result of
the one buffer one mode design as you only have a single syntax table
per buffer. 

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Arthur Miller]

Tim Cross <theophilusx@gmail.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I haven't tested the updated version of JK's proposal, but looking at the source
>> it seems to be a tad bit resource heavy. If it isn't a hassle for the OP to use
>> aliases like lt, gt or similar, I would suggest that either using macros or
>> simple defalias to rename those few functions, <,<=,> and >= is more resource
>> effective way. If code is tangled and byte compiled, macros will be expanded in
>> byte code, so effectively the runtime cost is almost none.
>>
>
> Have to say I really don't like that proposal as a work-around. Main
> reason is that it obscures the code intent (readers of the code need to
> know 'gt" means greater than while '>' intention is much clearer) and it
> requires all code generated (such as via tangle) to include the macro
> definitions. However, above all, it just feels wrong to require code
> alteration in order to address a limitation in the tool being used to
> create the code.

Well, in this case it is a tool deficiency, if you don't like gt, than use
use "greater-than", it can't be more clear intent? After all, this is a lisp, and
'>' is just a symbol name, like any other. For the inclusion of code, yes, but
that is why we have (with-eval-after-load 'org ...).

Don't get me wrong, I am not saying it is a proper way; it is a hack, everyone
can use whatever they like. I personally find org-babel already to be slow when
I have lots of code and blocks, and wanted something simple and efficient.
I found this to work quite well. It is much cheaper in terms of processing
to just defalias 4 symbols. I don't know, maybe it is just me; I am a practical
person who prefer simple solutions. Maybe someone writes a tree-sitter backend
now when we are getting tree-sitter into core? 

>>>                                         I have to wonder why it hasn't
>>> given how long this issue has been known about?
>>
>> That is a good question, maybe proper solution is very hard if not impossible?
>> Like you said, Emacs is really not meant to be used with several major modes
>> active as once. Seems like this is one of those places where it shows off.
>
> That is my suspicion as well, but I'm wasn't sure as I don't understand
> the internals sufficiently to assess the impact of the regex search. I do
> think the underlying point is correct i.e. adjusting the syntax table
> entry for the < and > characters. This would seem to be the result of
> the one buffer one mode design as you only have a single syntax table
> per buffer. 

Yes I know. I was thinking several times of this and have come to this
limitation in another little project. I would like to have major mode per
region, where region is a continuous span of buffer between two points. That
could help for some cases, for example in this particular case. I don't know how
 difficult that would be to implement, if even possible.

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Greg Minshall]

hi, all.

Arthur Miller <arthur.miller@live.com> wrote:

> Well, in this case it is a tool deficiency, if you don't like gt, than use
> use "greater-than", it can't be more clear intent? After all, this is a lisp, and
> '>' is just a symbol name, like any other. For the inclusion of code, yes, but
> that is why we have (with-eval-after-load 'org ...).

i'll note that in R, the assignment operator is (most often) "<-".  i
see issues there, also, in inline source blocks.  i then use [C-c '] to
open a source block, and can balance my parentheses to my heart's
content.  it's somewhat of an annoyance.

also, there's something called "polymode" (?) which might someday
provide this "multi-major" service in .org files.  i haven't been able
to make it work with org mode, and i think i've heard that same thing
from others on this list.

cheers, Greg

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Eric S Fraga]

I believe this has been mentioned in passing in this thread but I'll
repeat just in case: Unless you are working with xml or HTML in your org
documents, and even then, having these two lines in your org
configuration (e.g. org-mode-hook):

    (modify-syntax-entry ?< ".")
    (modify-syntax-entry ?> ".")

solves all the problems with languages that use these in an unbalanced
manner (comparison, assignment).  I've had this configuration for years
now and it just works (for me).

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-628-g366444
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[John Kitchin]

My current solution (which already differs from the last one I posted
here...) is here:

https://github.com/jkitchin/scimax/blob/master/scimax-org-src-blocks.el#L61

It is more selective, and only changes the syntax inside these src
blocks:

"jupyter-python" "python" "emacs-lisp"

and does not change the syntax if the character is in a string.

That way it still works with xml and html in strings, or in their own
blocks.

This might be the third iteration of fixing this issue, so I wouldn't
have the hubris to say it is the final solution yet.


Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> I believe this has been mentioned in passing in this thread but I'll
> repeat just in case: Unless you are working with xml or HTML in your org
> documents, and even then, having these two lines in your org
> configuration (e.g. org-mode-hook):
>
>     (modify-syntax-entry ?< ".")
>     (modify-syntax-entry ?> ".")
>
> solves all the problems with languages that use these in an unbalanced
> manner (comparison, assignment).  I've had this configuration for years
> now and it just works (for me).


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
Pronouns: he/him/his