GNU bug report logs -
#71364
Fix Table.el export
Previous Next
Full log
Message #25 received at 71364 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Pranshu <pranshusharma366 <at> gmail.com>
>> Cc: 71364 <at> 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.
This bug report was last modified 110 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.