emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Bug Re: Greater than, less than bug in emacs-lisp source block
Date: Fri, 03 Sep 2021 23:40:06 +1000	[thread overview]
Message-ID: <87pmtpojq8.fsf@gmail.com> (raw)
In-Reply-To: <CAJ51ETpJ0yO5U67X5fGvtXbbF_rLOvsPPDyCFwV-J6xj_y9Kjw@mail.gmail.com>


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



  reply	other threads:[~2021-09-03 13:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <b2a35533-82cd-b585-b1ab-3ca21adcafdf.ref@verizon.net>
2021-09-02 18:10 ` Greater than, less than bug in emacs-lisp source block Charles Millar
2021-09-02 18:24   ` John Kitchin
2021-09-02 22:36     ` Arthur Miller
2021-09-03 11:14       ` Fwd: " Charles Millar
2021-09-03 11:12     ` Bug " Charles Millar
2021-09-03 12:00       ` John Kitchin
2021-09-03 13:40         ` Tim Cross [this message]
2021-09-03 16:02           ` John Kitchin
2021-09-04 21:05             ` Tim Cross
2021-09-05  5:55               ` Arthur Miller
2021-09-05  8:37                 ` Tim Cross
2021-09-05 10:34                   ` Arthur Miller
2021-09-06  4:29                     ` Greg Minshall
2021-09-07 11:31                       ` Eric S Fraga
2021-09-07 20:23                         ` John Kitchin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pmtpojq8.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).