bug#71364: Fix Table.el export

[Pranshu <pranshusharma366@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Pranshu <pranshusharma366@gmail.com>
>> Cc: 71364@debbugs.gnu.org
>> Date: Sat, 08 Jun 2024 12:10:32 +1000
>> 
>> > So you are saying that exporting to latex is basically completely
>> > broken in the current code?  Is that command use to export only to
>> > latex, or is the fact that the export is to latex is just one of the
>> > possibilities?
>> 
>> Yes.  The function that does the escaping is
>> `table--generate-source-scan-lines', which is a misleading name because
>> it is only called by table-generate-source when the language is exported
>> to latex.
>
> 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.

Yes, initially I was surprised as well.  Initially I was surprised as
well.  I found 2 questions on stack overflow in which they also came to
the same dead end, of not being able to put equations in table(.el)s.

>> >> What the diff does, is that it adds a variable that allows the user to
>> >> change what will be escaped.  Also as you can see in the above latex
>> >> table, the backslash had to be escaped in a different way, so using one
>> >> regexp variable would not be enough.  That is why the solution contains
>> >> a variable called 'table-source-latex-escape-characters', which is a
>> >> cons cell with the documentation:
>> >
>> > Why would a user need to customize this on the level of characters?
>> > Shouldn't there be a single boolean that causes latex-specific
>> > characters to be escape or not to be escaped, all of them or none?
>> >
>> 
>> The problem with that is that there are latex charecters such as '%',
>> which is comment, that will cause the whole table to break of not
>> escaped.
>
> Is % the only character with such problems, or are there others?
>

These characters: "#$~_^%{}&", will all mess something up to different
extents.  For some it's mostly harmless as with the '~', but characters
like '&' will fully mess up the table, as it is used to separate the
columns.

>> And since the variable is a regexp, it can possibly escape macros, such
>> as 'LaTeX' -> '\LaTeX'. 
>
> Not sure I understand: is it a Good Thing that it could escape macros,
> or is it a Bad Thing (which should be avoided)?

Yes, it is a good thing.  "Escaping macros" was bad wording, I meant
turning words into macros.  Normally it will not do that, but it can be
customised to do that.

> More generally, given these tricky considerations, how would a user
> determine which characters to include in the regexp?  If it's only by
> examining the texts in the table cells, then it could be not very
> practical, since a table could be very large.
>
>> >
>> > What is the purpose of the "tail", i.e. why would a user want to
>> > escape all the backslashes?
>> 
>> Mainly because some people might only use the latex export to turn their
>> table into a pdf, and escaping backslashes is not as simple as typing
>> two backslashes.  And also since it was the default behaviour, so those
>> who have already made tables will not need to escape all those
>> backslashes to make their documents exportable.
>> 
>> If you feel that is unnecessary, I can modify the diff not include
>> backslash escaping.
>
> I think it should be controlled by a separate variable.
>

Yeah, you probably know better about that then I do.  I will just say
that variables about table.el are extremely hard to find, since of you
"C-h v table ?", you will see 100s of variables thanks to org-mode
tables.  Personally I would avoid creating more variables with 'table' in
their name, but as I said you know a lot more about emacs than I do.

> I also added to the discussion two people who in the past contributed
> changes to table.el in the LaTeX-related areas, so they probably have
> some experience with exporting to LaTeX, and could help us figure out
> how best to handle this issue.
>

all good, more perspectives could help.