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: Tim Cross
Subject: Re: Bug Re: Greater than, less than bug in emacs-lisp source block
Date: Sun, 05 Sep 2021 18:37:11 +1000
User-agent: mu4e 1.7.0; emacs 27.2.50

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. 



reply via email to

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