Tim Cross <theophil...@gmail.com> writes: > Arthur Miller <arthur.mil...@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.