emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Arthur Miller <arthur.miller@live.com>
To: Tim Cross <theophilusx@gmail.com>
Cc: org-mode-email <emacs-orgmode@gnu.org>,
	John Kitchin <jkitchin@andrew.cmu.edu>
Subject: Re: Bug Re: Greater than, less than bug in emacs-lisp source block
Date: Sun, 05 Sep 2021 07:55:56 +0200	[thread overview]
Message-ID: <AM9PR09MB4977E146F2A2B8E6AB03DBBD96D19@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <87eea4nj6f.fsf@gmail.com> (Tim Cross's message of "Sun, 05 Sep 2021 07:05:43 +1000")

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.


  reply	other threads:[~2021-09-05  5:56 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
2021-09-03 16:02           ` John Kitchin
2021-09-04 21:05             ` Tim Cross
2021-09-05  5:55               ` Arthur Miller [this message]
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=AM9PR09MB4977E146F2A2B8E6AB03DBBD96D19@AM9PR09MB4977.eurprd09.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=jkitchin@andrew.cmu.edu \
    --cc=theophilusx@gmail.com \
    /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).