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
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=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 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).