NickD

@PatrickNicodemus forgot to @you in the messag above

Also Eli Z. in the bug report threads noticed that your Emacs build does not include libsystemd. Have you tried reconfiguring the build and rebuilding Emacs with that option?

Apparently notify requires that Emacs send a message back to systemd (see the description of notify in the systemd.service(5) man page). The man page also recommends the exec type over the simple type. Nice report BTW.

@PatrickNicodemus Can you post the link to the bug report? I'd like to read it.

@PatrickNicodemus: I'll have to refresh my memory, but sure I'd be happy to help if I can. It might take me some time to get back to it and reconstruct my setup, but I'll re-read the question and we'll go from there.

I don't know off the top of my head and I think it would be difficult. Does the emacs server stop or is it only emacsclient that stops? If the server does not stop (check with journalctl , then you have to look at the communication channel between the two: what is different for that channel when you use systemd vs. not? Also assuming that the server does not die and restart, check the *Messages* buffer after the client dies: is there anything in there that indicates what happened to it? You might also turn on server-log and check the buffer whose name is the value of server-buffer.

How do you run the emacs server? Are you using systemd? How exactly does the unit file look? How do you run emacsclient? Are you running emacs or emacsclient under GDB? Did you do a ps of process 11115? If not, can you repeat the experiment and do so for the emacs process and the emacsclient process, so that when one or the other or both die, we have an idea of who died? Basically, if I wanted to reproduce the problem, how do I set up as similar an environment to yours as possible? And please add the information to your question as you go - not in comments.

The linked question was answered: the OP tried it on a stable release and it worked. I do understand that you are asking a different question, but I wanted to correct the record. Be that as it may: Are you on an unstable release? If so, have you tried with a stable release? What are you doing to trigger this exit? You are asking us to imagine a hypothetical situation (hypothetical, since we are not experiencing the problem) and come up with ways to debug it: there could be millions of reasons and thousands of possible debugging techniques. You need to narrow down the problem.

@Rusi: I sent you the modified version of `orgtbl-gather-send-defs' in gmail. Let me know if you encounter problems.

That's why the while loop is there. OTOH, you can only C-c C-c on the last one (the one that's just before the table - or on the table itself): doing so on the others again passes the C-c C-c through. So the fix I pastebinned is enough (modulo the fact that you say it does not work for you)

@Rusi: so I played around with ORGTBL SEND and I think I understand a little better now. First, although it's not mentioned in the docs, there can be NO lines (empty or otherwise) between the #+ORGTBL line and the start of the table. Otherwise, orgtbl-ctrl-c-ctril-c passes the C-c C-c through without acting on it, so it invokes whatever command is bound to C-c C-c in that buffer without orgtbl. Second, there can be multiple #+ORGTBL SEND lines above the table ...

@Rusi: ^^

Yeah, it's not a major problem and it has an easy workaround, so there is no hurry. There have been three bug-fix releases already since 9.7 was announced with 21 commits and there are already another 30 commits that have not been released yet: Org mode is a very active project. It's more important to fix it correctly than to fix it fast. Thanks for submitting the report.

@Rusi: I think it's buggy in other ways as well - I haven't checked the syntax, but if there is an empty line between the start of the table and the #+ORGTBL line, nothing happens with C-c C-c - but it's really late now and I need to get some sleep.

@Rusi: I forgot to ping you.

See a modified orgtbl-gather-send-defs here: pastebin.com/NYC6NspS - that seems to work in your case, but I haven't tried it in my case (but it should work there too - famous last words...)

Yes - there is an infinite loop in orgtbl-gather-send-defs. Not sure why that does not happen in the case I tried, but it's late for me, so I'll trace it in the morning. On second thought, it happens because (forward-line -1) at the beginning of the buffer is a no-op. That's why when you have a line above it, it does not happen. It should be easy to fix, but it's a rather unlikely scenario.

This started as a comment discussion on the following question: emacs.stackexchange.com/questions/81455/…

In any case, you should update the question here with your findings.

I take it this is Chrome on macOS? I tried viewing it in Chrome on Linux and it works fine there as well. You might try creating a new user and starting Chrome there (presumably with factory settings) or click on Settings/Reset Settings/Restore Settings to their original defaults and seeing if that helps. If it does, you can continue by debugging which setting(s) of yours is (are) responsible. If not, you might be able to open a bug for Chrome on macOS.

Your pastebinned HTML file is no longer HTML: every < has been replaced by a < entity and every > has been replaced by a > entity.

When I view cavendish-deneyi.com/math/Export-MathJax-test.html I can see italic ks and ns. So there might be a problem with your browser. Can you try a different one and see if it works better?

... or maybe add that script into your HTML file, right after the </script> tag at the end of the MathJax options and see if that fixes it.

So maybe that is the problem: you might want to pastebin your HTML file somewhere so we can look at it. Here's what mine looks like: pastebin.com/xkH4D0HC - see if that gives you the correct rendering. If so, then "all" you have to do is find out why your Org HTML exporter does not include the MathJax script into the output file.

The question is: does your HTML file load the MathJax Javascript library? If it does, then your math should be rendered through the library and so your m should be italic. If it loads the library and your m is not italic, then we have to search harder for the reason. In that case, please post a short Org mode file that misbehaves for you, so others can try it and see if it also misbehaves for them.

So check the HTML file that is produced and see if it contains the following: <script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtm‌​l.js"> </script>. You might also try \(m+0 = m\) instead of the dollar signs.

$m +0 = m$ renders the m as italic in both PDF and HTML export here. Are you using MathJax in your HTML export?

My suggestion is to rewrite the question a bit: start with what you had at the beginning (the github file you linked to in a comment) and explain what problem you encountered - but don't simplify it: the simplification distorted the question and made it into a not quite recognizable caricature of itself (you recognized it because you had the original question in mind, but for me - up until the point where I reread everything - it was confusing: I kept asking myself why would anybody do that?)

Yes, that was exactly my point in the comment above: "Even worse, what should Emacs do with ~foo?"

What does the example illustrate in relation to Emacs? I don't understand your point.

... except when a user foo exists.

I don't; understand the example: is that a shell command? Does a user foo exist?

Tilde is indeed a shell shorthand, just like ' is a lisp shorthand: they expand to something else. The fact that Emacs chooses in certain situations to expand tilde to what the shell would expand it to is irrelevant. Emacs does not do tilde expansion the same way that the shell does.

... command substitution that you have to quote because it contains special characters AND the program produces a path with a literal tilde in it). In that case, we both agree that the command should be made to produce a path without a tilde in it. That's why your answer is correct, but it is an answer to a different question than the one you ask.

Please don't get hung up on irrelevant points (ascribing fault is just a literary device to highlight the difference of opinion). I made a post to remind people not to use a literal tilde if they want to refer to their HOME directory: but that is not correct as I've pointed out repeatedly: export EMACSLOADPATH=~/foo:~/bar works fine (and has nothing to do with Emacs). It is only in certain specific situations (where you ask Emacs or some other program to produce a path through...

Even worse, what should Emacs do with ~foo?

Yes, indeed we disagree on what the problem is. You ascribe the fault to Emacs (it doesn't recognize the tilde in EMACSLOADPATH); I ascribe the fault to whoever constructed EMACSLOADPATH with an unexpanded tilde in it. But Emacs does not (and should not IMO) scan values of environment variables for problems: e.g. what should happen if a literal ~ occurs somewhere in the middle of a path? Now you either need to escape it or the scanner will have to be made "smarter" (i.e. more complicated).

Putting a literal ~ in EMACSLOADPATH is not the problem: the problem is that you quoted it. So the solution is: do not quote it. THAT is the problem with the question. But as you say in the comments, the tilde is a side effect of using a script that prints the value of user-emacs-directory - so that must be a part of the question: the question does not make sense otherwise.

On rereading everything, the answer is fine: it's the question that is problematic IMO, because you have "simplified" it too much. The answer to the question as it stands is in my first comment above - there is no need for anything else. But your actual question is different and it explicitly involves the fact that user-emacs-directory is a string containing a tilde. That appeared in the answer, but not in the question.

If there is a possibility that there will be a tilde in the output, then make sure that you get rid of it (e.g. use expand-file-name on user-emacs-directory). That way, it doesn't get a chance to pollute anything downstream. See en.wikipedia.org/wiki/Defensive_programming.

If you need to quote something, then quote that something but leave the tilde alone. E.g. if you have a directory foo* under your home directory, do export EMACSLOADPATH=~/foo"*". I fail to see why you think EMACSLOADPATH is somehow special or what this has to do with Emacs. The only parsing that Emacs (or any other program) does on a PATH-like environment variable is to split it at colons and construct a list - that's all.

Do not quote the RHS of the export. That will allow the shell to expand it properly.

... I haven't tried it out and macOS is probably the least-well tested platform, so YMMV.

Sorry - I wasn't watching. I saw the bug report and the resolution. I should have suggested a "mixed" installation: all the signs were there. I had forgotten about the SVG stuff until you mentioned it and I went looking: I can't remember anything any longer... I usually build my own emacs from the latest upstream - I do that every few months. IME, things are pretty solid even on the latest upstream, so my expectation is that 29.1 rc1 should be solid - BUT ...

@rogerl Yes, I was one of the RCE bunch (painful memories, I know :-) )

One more thing to try is to continue from where the debugger stopped (by pressing c) and see what happens: maybe the stack grows every time indicating that it will eventually run out.

Also, did you try byte-compiling any of the other files with the debug-on-... settings? Are their backtraces any different?

BTW, I knew a Roger Lipsett in the last century who worked at Intermetrics: any relation?

The backtrace is uninformative IMO: an undefined variable is not enough to explain running out of stack. The whole thing seems too weird for words to me and I don't have any other ideas: I would maybe suggest that you clean up everything (emacs and auctex) and do it again from scratch, but it's probably worth a bug report at this point, if only to get some guidance on next steps. Sorry I couldn't help.

BTW, debug-on-error is also needed. See gnu.org/software/emacs/manual/html_node/elisp/…