emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Arthur Miller
Subject: Re: Bug Re: Greater than, less than bug in emacs-lisp source block
Date: Sun, 05 Sep 2021 07:55:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]