lisp exceeds `max-lisp-eval-depth'

[yizhang-yiz]

Summary

It was driving me nuts and took me a while to narrow down to stan-mode but I'm still not 100% sure it's the cause of c++-mode losing all the highlighting and prompting

lisp exceeds `max-lisp-eval-depth'`

How to reproduce

use clean emacs init

rm -rf ~/.emacs.d; mkdir ~/.emacs.d

Add a minimalist init to ~/.emacs.d:

;; init.el

(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
;; Comment/uncomment this line to enable MELPA Stable if desired.  See `package-archive-priorities`
;; and `package-pinned-packages`. Most users will not need or want to do this.
;;(add-to-list 'package-archives '("melpa-stable" . "https://stable.melpa.org/packages/") t)
(package-initialize)

Test emacs with a c++ header

I use the following to test

// debug.cpp
#ifndef STAN_MATH_EVENT_HPP
#define STAN_MATH_EVENT_HPP

#include <stan/math/typedefs.hpp>
#include <stan/math/dsolve/ode_integrator.hpp>
#include <stan/math/mpi/precomputed_gradients.hpp>
#include <stan/math/model_solve.hpp>
#include<vector>

The file should be displayed normally:

add stan-mode

M-x package-install RET stan-mode
close & reopen emacs.

Open a stan model

I use the vanilla bernoulli.stan

open the c++ file and edit

Now open that c++ file and try to edit. For example, when I insert space, I'm getting (note the mini buffer)

and now if I close that file and reopen it, all highlighting is gone

OS

OS: mac os x 10.14.6 (18G7016)
Emacs: all 26.1-27.1 builds from https://emacsformacosx.com/builds

If I use builds from
https://vigou3.gitlab.io/emacs-modified-macos/
with same init.el and stan-mode installed when openning a stan file I'm getting

and I'm assuming they are caused by a same issue.

[kaz-yos]

Thanks for the super-detailed report! I'll try to reproduce it

Meanwhile, can you M-x describe-face on the C++ code when the highlight is gone? This may help if the face definitions are affected vs assigning colors to them is affected.

Also if you could obtain the full trace with M-x debug-on-error, it'll be helpful.

[kaz-yos]

It does reproduce in my environment. I have not done a clean environment test, yet.

The face is of the non-highlighted text becomes default.

[yizhang-yiz]

Meanwhile, can you M-x describe-face on the C++ code when the highlight is gone?

When it's normal it should be font-lock-preprocessor-face but when hl is gone I'm getting default.

Also if you could obtain the full trace with M-x debug-on-error, it'll be helpful.

I did use --init-debug but didn't see debugger popout when lisp-exceeds... issue occurs.

[kaz-yos]

Is it correct, if you add actual code (rather than headers starting with pound/hashtag #) you do get highlighted code?

[yizhang-yiz]

When typing it's still under default face.

[kaz-yos]

The most likely culprit is the handling of # in stan-mode.

stan-mode is a derivative of C++ mode, but try to cover the role of # as a comment in the older version of stan as well as headers with some hack. This may be affecting other C++ related modes.

[kaz-yos]

In my regular environment, it looks like this.

Perhaps, the # part is losing the syntactical meaning as preprocessor and syntax highlighter is getting confused.

I am not a C++ savvy (or Stan in that regard), so could you provide me with a code example that includes both preprocessor part and actual C++ code. It'll be useful for automated testing (defining the correct behavior) and fixing this issue.

Dropping the old stan # comment support is likely the solution, which I will investigate.

[yizhang-yiz]

https://github.com/stan-dev/stan/blob/develop/src/stan/mcmc/hmc/nuts/adapt_unit_e_nuts.hpp
This file has enough c++ gibberish & symbols.

IMO we'll be fine dropping old comment support if it solves the issue.

[kaz-yos]

Thanks! This will be very helpful. Even before things break, the ifndef line was not highlighted. Is this a usual behavior?

TODOs.

1. Describe correct behaviors for the C++ syntax highlighting with a realistic code example (check faces before it breaks and define them as buttercup expectations; can save the entire string with face properties?).
2. Test against these expectations before and after loading a stan file (The "after" test should fail).
3. Drop the old # comment support to see if the above tests pass
4. Drop corresponding old tests if other behaviors are preserved.

[yizhang-yiz]

Thanks! This will be very helpful. Even before things break, the ifndef line was not highlighted. Is this a usual behavior?

yes.