bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#71364: Fix Table.el export


From: Reuben Thomas
Subject: bug#71364: Fix Table.el export
Date: Sat, 8 Jun 2024 11:05:25 +0100

On Sat, 8 Jun 2024 at 07:38, Eli Zaretskii <eliz@gnu.org> wrote:

It is strange to hear that this is so basically broken.  This code
exists since more than 20 years ago, and several people contributed
changes to the LaTeX export, so I'd expect it to be at least somewhat
useful and working.

I think the explanation is that it is somewhat useful and working, and also basically broken.

Specifically, it works fine if, like me, you do not want to put LaTeX markup in tables. This was certainly my case, as I was using it with org-mode. In this case, any character that is active in LaTeX can and should simply be escaped on output.

What is basically broken is the ability to export to LaTeX when the table contains LaTeX markup.
 
Reuben and Vladimir, would you please comment on the usability of
exporting to LaTeX in table.el, and on the proposed improvements?

Personally, I think trying to make this work is a mug's game, and having wrestled as a maintainer with other Emacs code that is over-complicated because it tries to understand the syntax of e.g. LaTeX or mail buffers (for example, ispell.el), I would resist adding further support for specific syntaxes to code that is not part of an editing package for that syntax.

Again, taking ispell.el, with which I am much more familiar, what I would like to do there is to strip out all the support for LaTeX and mail buffers, and instead require LaTeX- or mail-editing modes to call the spell-checking routines. That would require a different approach globally: some of the existing ispell commands work on a whole buffer, so they cannot interact with language-specific code. I guess the code was originally written like this because it could be created from scratch without changing anything about other modes.

I think this example of ispell.el is relevant to table.el because much the same considerations apply: table.el was originally written independent of other code, but that's not a good design for interacting with other syntaxes, as you end up implementing half-baked support for them, rather than allowing an editing mode that already understands the syntax to interact with the table routines.

Therefore, I recommend not attempting to improve table.el's LaTeX support, documenting clearly that it doesn't support embedded LaTeX, and designing functions that allow table.el to cooperate with other packages to export different embedded syntaxes. Otherwise, we will frustrate users (who will find the code broken and, if they try to understand it, baffling) and maintainers (who will spend effort for many years maintaining code that is half-baked, complicates the modules it lives in, but has to be maintained).

--
https://rrt.sc3d.org

reply via email to

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