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

[Arthur Miller <arthur.miller@live.com>]

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.