GNU bug report logs - #71364
Fix Table.el export

Previous Next

Package: emacs;

Reported by: Pranshu <pranshusharma366 <at> gmail.com>

Date: Tue, 4 Jun 2024 14:44:02 UTC

Severity: normal

Merged with 71375

Found in version 30.0.50

Full log


View this message in rfc822 format

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Pranshu <pranshusharma366 <at> gmail.com>, Vladimir Nikishkin <lockywolf <at> gmail.com>, 71364 <at> debbugs.gnu.org
Subject: bug#71364: Fix Table.el export
Date: Sat, 8 Jun 2024 11:05:25 +0100
[Message part 1 (text/plain, inline)]
On Sat, 8 Jun 2024 at 07:38, Eli Zaretskii <eliz <at> 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
[Message part 2 (text/html, inline)]

This bug report was last modified 111 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.