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 12:34:35 +0200 [thread overview]
Message-ID: <AM9PR09MB497786CC8B10AE5857F8272C96D19@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <87a6krmm74.fsf@gmail.com> (Tim Cross's message of "Sun, 05 Sep 2021 18:37:11 +1000")
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.
next prev parent reply other threads:[~2021-09-05 10:37 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
2021-09-05 8:37 ` Tim Cross
2021-09-05 10:34 ` Arthur Miller [this message]
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=AM9PR09MB497786CC8B10AE5857F8272C96D19@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).