From: Tim Cross <theophilusx@gmail.com>
To: Arthur Miller <arthur.miller@live.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 18:37:11 +1000 [thread overview]
Message-ID: <87a6krmm74.fsf@gmail.com> (raw)
In-Reply-To: <AM9PR09MB4977E146F2A2B8E6AB03DBBD96D19@AM9PR09MB4977.eurprd09.prod.outlook.com>
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.
>> 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.
next prev parent reply other threads:[~2021-09-05 9:01 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 [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a6krmm74.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=arthur.miller@live.com \
--cc=emacs-orgmode@gnu.org \
--cc=jkitchin@andrew.cmu.edu \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.