From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 8AF9LL9JMmEkWgEAgWs5BA (envelope-from ) for ; Fri, 03 Sep 2021 18:13:51 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 6IlHKL9JMmG0DQAAB5/wlQ (envelope-from ) for ; Fri, 03 Sep 2021 16:13:51 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 82B4425249 for ; Fri, 3 Sep 2021 18:13:50 +0200 (CEST) Received: from localhost ([::1]:41972 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMBp7-0006FV-Jn for larch@yhetil.org; Fri, 03 Sep 2021 12:13:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59488) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMBeL-0006SM-UV for emacs-orgmode@gnu.org; Fri, 03 Sep 2021 12:02:42 -0400 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:43968) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mMBeI-0005xg-HW for emacs-orgmode@gnu.org; Fri, 03 Sep 2021 12:02:41 -0400 Received: by mail-wm1-x335.google.com with SMTP id o39-20020a05600c512700b002e74638b567so3911336wms.2 for ; Fri, 03 Sep 2021 09:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andrew-cmu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pAlCNYUagprdA/tdVlDeOTKxr9XRy3edrE9ULHsGp4A=; b=JFyGxO3n89GjWo9rkzTH3lXqElpEkq+MokCzO+IOldRdoP+bS687YewBR3JrnI1M7h ZALqw509mVJjAq7zpjHfjkot4nYryuRiJsDCx2jCyC1jNIhiH93fiiJgl1iKhJ8ellz7 up4D1XWHgtDiGfBN+/MxiW3ZHQTYF5yJ96qFoXBASYvDl4+FJubSK8Hwelw2RjQOJwby 0aE9UgbjCsLnnaD9PuGgLXPz5+Kc8MqGO1sGPhs7+XdHim/E3xgpkQLxmPb0I7nA448l ujAaG3xKH8bgeYCxhUj6SJhHyHOtAiv5EQPDhcpY2ccjHz9QbUpU544ea87xI4eeVZEk aKJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pAlCNYUagprdA/tdVlDeOTKxr9XRy3edrE9ULHsGp4A=; b=Wm33xhyRRUsVttjru+SFhP5kJ306lVZ1JhLeXzSwlD398w/AQakIA+HP76iO1vz11E m0zOpKArYVwGXtRTdpKchI+McmnHoEWHsAo1vXMRjJAp82y0m6mAXaBshQTSeAgLU2Jl y79OJVF6mkYjqbBGPDkD0TbCa+z5nsAh2lvXlgEjYEWF/fhtyxSHkDH9UEHu5mQnqABV D3okaaD6xbD5NtCMh4POUBrvPuNIw2NUu8zrDoQ4K0030Kqg1oTLnf/3RNLgDqIgJGVT OPUH5AvS++wl5ljVtDEHN8KWTebO85Yg8QPKBS9KlfCkel/dlXEVzwAW1FEBl7V+e+05 w6yA== X-Gm-Message-State: AOAM530ArjV8chacdK9wkM+xzSI975jPj4uR7vYC4w3Rgwzm/HveYP8r HEHIt0MHJalps6VSX7zL1Yp+dZjnMi0ndoY3NXA= X-Google-Smtp-Source: ABdhPJxHmwIzY+//bBiwsOGCw91oRMyMCyK/1LNhAdNqBvBxtWahGD2XaI7OXk/HwD+gT8KfqbiFXhpFxwQcr0j3xDQ= X-Received: by 2002:a1c:98d5:: with SMTP id a204mr9061496wme.52.1630684956754; Fri, 03 Sep 2021 09:02:36 -0700 (PDT) MIME-Version: 1.0 References: <3b398cbe-19d5-7006-d854-4a8693d217bb@verizon.net> <87pmtpojq8.fsf@gmail.com> In-Reply-To: <87pmtpojq8.fsf@gmail.com> From: John Kitchin Date: Fri, 3 Sep 2021 12:02:25 -0400 Message-ID: Subject: Re: Bug Re: Greater than, less than bug in emacs-lisp source block To: Tim Cross Content-Type: multipart/alternative; boundary="00000000000096866605cb196d1e" Received-SPF: pass client-ip=2a00:1450:4864:20::335; envelope-from=johnrkitchin@gmail.com; helo=mail-wm1-x335.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: org-mode-email Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1630685630; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=pAlCNYUagprdA/tdVlDeOTKxr9XRy3edrE9ULHsGp4A=; b=WXIR7TKWrIOP6nX+5LjgA8hVPOnYumGS13Kxfo1cjEawZmQea2Fub/8O826I7aOr2L2PLY xpDYZ+ijJNQ7Z2qpTIeSk5PgJU+7h3mEdiP+kLk+efb2htsMCkKMZ9nqXf1Vh5PHMbymmC sNI58hEgGvoAG8ZkByRF9+Uew7oUrAN/cHPS5vovgECHVLyxdYlLQd7RIY61w/9uimF9/0 Fjy4JEjMcDe6NnTKHPrEKld7igoxWNwzdjLoJ6fzpZrbvsOtik7iUS4einFMuzLP2EolV2 8gphiE1hfdh4/NcRPe5ANosFkHniZsqrzAQlpweM5HkDIFRSZJzZoyTkzONo7g== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630685630; a=rsa-sha256; cv=none; b=kgeZyX6/IgCPT9oj1F0fXvE+XU4pouPdv3GuZPFw0+KqwpCa/k4zXo0JRpYFW91lijjHEM hdEmplYA8FByoMl5MatxT6agCJhYh17ZPf+qxikKO0nd5nawqJ7Jve2vfM1EDyEenjw4DX G1Nlab4/0aqwK2S4S3KIipt2zVICsEVSUardRKdAsHucnxKjxqBBm1Kei31cl2MkhwKXmI BpLoX0Lb9pqernUaZtAscxiJCsbZKhDg1UzG0c3wVXPqZuRxqbJAapgQxG4Vyk0gUf/A+b +F9hPk3h3fdeK7OC+iqA33+xbaZzMRqyd8gkbuNArXxi51fsIodW1zVDYQDneA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=andrew-cmu-edu.20150623.gappssmtp.com header.s=20150623 header.b=JFyGxO3n; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -1.52 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=andrew-cmu-edu.20150623.gappssmtp.com header.s=20150623 header.b=JFyGxO3n; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=andrew.cmu.edu (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 82B4425249 X-Spam-Score: -1.52 X-Migadu-Scanner: scn1.migadu.com X-TUID: CFoHz3iD4S9F --00000000000096866605cb196d1e Content-Type: text/plain; charset="UTF-8" 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 > > >> > > >> > > >> > > >> > > > > > > --00000000000096866605cb196d1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My previous solution seems like it stopped working for som= e 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 (star= t end)
=C2=A0 "Change syntax of characters ?< and ?> to symbo= l within source code blocks."
=C2=A0 ;; I think this gets run in a = special edit buffer for src-blocks. For now I
=C2=A0 ;; only run this in= the src blocks, so that outside the src-blocks these still
=C2=A0 ;; ac= t like b=3Dopen/close brackets.
=C2=A0 (when (org-src-edit-buffer-p)
= =C2=A0 =C2=A0 (let ((case-fold-search t))
=C2=A0 =C2=A0 =C2=A0 (goto-cha= r start)
=C2=A0 =C2=A0 =C2=A0 ;; this "fixes" <>, {} and= [] that fixes some issues in src blocks, but
=C2=A0 =C2=A0 =C2=A0 ;; ma= kes some new issues, which is now you cannot use them as brackets.
=C2= =A0 =C2=A0 =C2=A0 ;; this tries to be fancy and not change the syntax in st= rings.
=C2=A0 =C2=A0 =C2=A0 (while (re-search-forward "[[<{]\\|[= ]>}]" end t)
(unless (ppss-string-terminator (syntax-ppss (poin= t)))
=C2=A0(put-text-property (point) (1- (point))
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0'syntax-table (string-to-syntax "_")))))))

(defun scimax-fix-<>-syntax ()
=C2=A0 "Fix syntax o= f <> in code blocks.
This function should be added to `org-mode-ho= ok' to make it work."
=C2=A0 (setq syntax-propertize-function &= #39;scimax-org-mode-<>-syntax-fix)
=C2=A0 (syntax-propertize (poin= t-max)))

(add-hook 'org-mode-hook
=C2=A0#'scimax-fix-&l= t;>-syntax)


John

--------------------------------= ---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Departm= ent of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA= 15213
412-268-7803

On Fri, S= ep 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 > 'nor= mal'
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 wit= h
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-bloc= ks, 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:
>
>=C2=A0 Thank you, John.
>
>=C2=A0 I will give it a try.
>
>=C2=A0 However, is this a bug that should be fixed within org source co= de?
>
>=C2=A0 Charlie Millar
>
>=C2=A0 On 9/2/21 2:24 PM, John Kitchin wrote:
>=C2=A0 > I think this issue is described in
>=C2=A0 > https://emacs.stackexchange.com/questions/50216/org-mode-code-block-par= entheses-mismatch.
>=C2=A0 > There are also some solutions there.
>=C2=A0 >
>=C2=A0 >
>=C2=A0 > John
>=C2=A0 >
>=C2=A0 > -----------------------------------
>=C2=A0 > Professor John Kitchin (he/him/his)
>=C2=A0 > Doherty Hall A207F
>=C2=A0 > Department of Chemical Engineering
>=C2=A0 > Carnegie Mellon University
>=C2=A0 > Pittsburgh, PA 15213
>=C2=A0 > 412-268-7803
>=C2=A0 > @johnkitchin
>=C2=A0 > http://kitchingroup.cheme.cmu.edu
>=C2=A0 >
>=C2=A0 >
>=C2=A0 >
>=C2=A0 > On Thu, Sep 2, 2021 at 2:10 PM Charles Millar <millarc@verizon.net&g= t; wrote:
>=C2=A0 >
>=C2=A0 >> Set up:
>=C2=A0 >> GNU Emacs 28.0.50 (build 344, x86_64-pc-linux-gnu, GTK+= Version 3.24.23,
>=C2=A0 >> cairo version 1.16.0) of 2020-12-31
>=C2=A0 >> Org mode version 9.4.6 (release_9.4.6-637-gd70f28 @
>=C2=A0 >> /usr/local/share/org-mode/lisp/)
>=C2=A0 >>
>=C2=A0 >> The following code will evaluate
>=C2=A0 >>
>=C2=A0 >> #+begin_src emacs-lisp
>=C2=A0 >> (defun Foo ()
>=C2=A0 >> (if (=3D 2 4) bar))
>=C2=A0 >> #+end_src
>=C2=A0 >>
>=C2=A0 >> #+RESULTS:
>=C2=A0 >> : Foo
>=C2=A0 >> and the opening and closing parentheses match.
>=C2=A0 >>
>=C2=A0 >> If a greater than is inserted instead of equals, thus >=C2=A0 >>
>=C2=A0 >> #+begin_src emacs-lisp
>=C2=A0 >> (defun Foo ()
>=C2=A0 >> (if (> 2 4) bar))
>=C2=A0 >> #+end_src
>=C2=A0 >>
>=C2=A0 >> it apparently evaluates, however, the closing parenthes= is immediately
>=C2=A0 >> following the "4" is paired with the opening = paren before "if" and not
>=C2=A0 >> the opening paren immediately before the ">&quo= t;
>=C2=A0 >>
>=C2=A0 >> A "less than" results with stranger parenthes= is matching - the closing
>=C2=A0 >> paren after the "4" matches no others; the cl= osing paren immediately
>=C2=A0 >> after "bar" matches the opening paren before = "if"
>=C2=A0 >>
>=C2=A0 >> Charlie Millar
>=C2=A0 >>
>=C2=A0 >>
>=C2=A0 >>
>=C2=A0 >>
>=C2=A0 >


--00000000000096866605cb196d1e--