Subject: bug#71364: Fix Table.el export

From: Pranshu <[email-masked]>
Date: Tue, 09 Jul 2024 17:05:08 +1000

Hello Vladimir

Lockywolf Laptop <[email-masked]> writes:

>>should or should not expect LaTeX markup
>
> How much of LaTeX markup?
> What if you add some mysterious \makeatletter there?
>

My idea was that the default should still be that all latex specific
charecters are escaped by default, and the variable is customized by
those who know what the specific function or markup does.

>
> If I may, I would ask Mr Pranshu to spend a bit more work on this patch,
> and do some straightforward, albeit a little tedious work to make this
> patch more pleasant. May I?
>

Yeah sure, but not rn.  I am kind of busy for 2 weeks, then I will be
able to do it.

> 1. Add a check to table--generate-source-scan-lines, which would
> actually check that the variable _language equals to latex, and bail out
> if it is not. Silently doing export to latex if html output is requested
> is even worse than politely refusing.

Is that really neccasary, because all that the function does it latex
specific. Why not just rename the function to something latex specific,
eg table--generate-source-scan-lines-latex.

> 2. Implement a defcustom table-el-cell-export-function-latex, which would be
> called on each cell.
> 3. Implement a default value for this function, which should basically
> amount to factoring out the code already in
> table--generate-source-scan-lines. This way nothing will break.
> This function maybe called table-el-cell-export-latex-default
> 3. Implement a copy of this function, with support for additional
> escaping tricks needed by Mr Pranshu. It can be called
> table-el-cell-export-latex. I do not think that a special defcustom
> for the regexp is needed, because such export functions can be expected
> to be written by people who need them necessarily in an ad-hoc way, and
> customisations might not be well described by just a regexp.
>
> It is a bit of work, but at least it will add some necessary extension
> points. And org-mode, when exporting to table.el used in org files,
> could override that cell export function to its own benefit.
>
> (By the way, I haven't checked, but probably org-mode already has some
> additional support for exporting table.el? I remember successfully
> exporting org-files with table.el tables into html, which is seemingly
> not supported in table.el itself.)

I haven't really played with the html org export, but as of now table.el
does have an html export.  All org mode does is calles the appropiate
export, so it does no sort checking text inside the table.  For example
you cannot do org itallics, citing, and any of that stuff inside the table.

To change this I think table.el would need a major rewrite that allows
for something like your idea of having a function called to all of the
text inside the table.

Instead of just improving the latex export and leaving the others in the
dust, how about we do what you suggested, but instead of having seperate
functions for each export, we make the exports a list.

All of the table exports basiclly do the same thing:
- Add some header text
- Replace column and row delimeters
- add end text
- optional: escape text

Honestly I think table.el is due for a rewrite, if you have used it
before yk what I mean, on average it's about half a second latency to
type one charecter.  Personally I think that instead of having a
table.el version of every basic command, eg self insert, kill line, it
would be better to add a post command hook and do damage control
depending on the last command.

Kind Regards,
Pranshu