Apologies for a delay. My life has been a little hectic recently. While I have, indeed, contributed a bit to the table.el's support for latex, I can't say that I am a big guru either on table.el or on latex. I used table.el instead of native org tables because table.el supports multiline cells, which I needed to write parallel texts in several languages, naturally having different number of lines per passage. So it is, indeed, "somewhat useful and working" for people not using mathematics. I have never tried writing latex code into table cells, and although I agree that multiline tables might be useful with support for mathematics, I also quite agree that making LaTeX work as expected is hard, even when not using language-to-language transformations. I can see why everything was escaped in the past, because it is the easiest way to make sure that "everything at least compiles" even if the result is not what one would expect naively. (As a side-note, using the dollar signs in LaTeX mathematics is a bad practice, because identical delimiters serving different roles when in an even or odd position easily confuse the parser. Using \(\) and \[\] is strongly preferred.) >So it's a YES, because I was saying the same thing. If you look at the const called table-source-languages, it should imply that there "should" be export to languages other than LaTeX, but as already mentioned, table--generate-source-scan-lines does not support any language other than LaTeX, because nobody implemented, I guess. >should or should not expect LaTeX markup How much of LaTeX markup? What if you add some mysterious \makeatletter there? I generally agree with Reuben that making this work is a thing hard to get right. Moreover, as I mentioned above, I only used table.el with org-mode, but I can't remember for sure what happens if one uses org-links in the table.el cells. Do they become latex href links? Or links to images? Do they turn into \includegraphics? Latex math is part of org, so I presume, it is expected to somehow work, but I am not sure how. >In any case, this is beyond the immediate issues discussed in this bug >report, I think. Broken code must be fixed. I don't think it is a bug. It is an intentional limitation of scope, which implements a crude but simple way of producing valid outputs, albeit not 100% functional. However I do not want to outright recommend rejection of the patch. After all, implementing "simple math" is a valid desire for someone who wants to print a table of integrals. 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? 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. 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.) P.S. Thank you Reuben for workign on ispell.el. I think that Emacs would benefit from improved spellchecking, but I myself didn't have time to explore it with sufficient assiduity. Eli Zaretskii writes: > Ping! Vladimir, could you please respond? > >> Cc: 71364@debbugs.gnu.org, rrt@sc3d.org >> Date: Sat, 22 Jun 2024 12:39:58 +0300 >> From: Eli Zaretskii >> >> > From: Pranshu >> > Date: Fri, 21 Jun 2024 18:25:46 +1000 >> > Cc: rrt@sc3d.org, lockywolf@gmail.com, 71364@debbugs.gnu.org >> > >> > How about now, it has been about 2 weeks >> >> I'd like to hear from Vladimir as well. >> >> Vladimir, would you please chime in and comment on this proposal? >> >> >> >> -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop)