Disons qu'emacs génère une erreur que je ne comprends pas. Ou peut-être que l'erreur indique "La valeur du symbole en tant que variable est vide: modes", mais il y a beaucoup d'occurrences du symbole modes
dans mon code, j'ai donc besoin d'un peu de contexte. Emacs peut-il être configuré pour mentionner le numéro de ligne du code lisp afin que je puisse savoir quel code est à l'origine de l'erreur?
J'ai essayé de le faire (setq stack-trace-on-error '(buffer-read-only))
et j'ai exécuté le code en question dans le but d'obtenir une trace de pile. Pas de trace de pile non plus.
J'ai également essayé d'appeler edebug-defun
ma fonction et de la franchir. Ce n'est que lorsque je quitte la fonction que l'erreur est levée.
(Je ne suis vraiment pas aussi intéressé par la cause de l'erreur particulière que je rencontre actuellement que par le développement de compétences générales de débogage pour elisp. Veuillez me conseiller sur la façon dont je peux faire briller un numéro de ligne, ou un sexp, ou une trace de pile à partir d'un Erreur.)
nil
debug-on-error
? Cela ne vous aide-t-il pas?t
, puis procéder à l'évaluation d'une fonction de lancement d'erreur.)debug-ignored-errors
liste ne contient aucune erreur. Si vous définissezdebug-on-signal
sur nonnil
, et que c'était le cas que l'autre code a traité l'erreur, vous pourrez obtenir l'erreur avant que l'autre code ne le fasse.Réponses:
Emacs fournit une bonne quantité de fonctionnalités de débogage, y compris
M-x toggle-debug-on-error
, leM-x toggle-debug-on-quit
débogage sur le signal (qui peut être utilisé en envoyantUSR2
à Emacs de l'extérieur),debug-on-entry
(d'une fonction),debug-on-message
(en voyant une correspondance d'expression rationnelle spécifique d'un message) et enfin,debug
lui - même comme alternative l'instrumentation d'une fonction avecC-u C-M-x
.Les deux
debug
etedebug
offrent des fonctionnalités suffisantes pour inspecter l' état d'Emacs pour évaluer le code qui vous intéresse, frappée
et entrez une expression.Cependant, tout en
edebug
sautant à la place dans la fonction instrumentée et vous donne donc un indice où chercher (ce qui est un peu idiot puisque vous savez déjà exactement ce que vous avez instrumenté),debug
ne le fait pas du tout. J'ai retiré un petit hack après avoir découvert que chaque foisdebug
qu'un tampon est évalué, il émet la valeur de point associée à l'erreur; en d'autres termes, l'utilisation de ces informations sur le tampon peut vous donner un numéro de ligne dans le backtrace!Avec cela, il faut répondre à la question originale dans le titre. Quant à votre problème avec l'obtention d'une trace en premier lieu, je suis à court d'idées utiles.
la source
M-x debug
...? Alors sur quoi dois-je appuyer?debug
traces créées par , vous pouvez vérifier en visitant un fichier elisp défectueux, en faisantM-x toggle-debug-on-error
etM-x eval-buffer
, puis une trace avec un numéro de ligne à la position problématique devrait apparaître.eval-buffer
? Par exemple, si vous appuyez simplement sur un raccourci clavier qui exécute une commande privée qui échoue et ouvre le débogueur dans le*Backtrace*
tampon.Peut-être parce que c'est 2018 maintenant, mais dans mon cas, je n'ai eu qu'à activer le débogage comme l'a suggéré wasamasa: Mx toggle-debug-on-error
Après cela, Mx eval-buffer sur mon fichier Elisp défectueux a donné le contexte en fournissant la position de l'erreur, comme ceci:
Debugger entered--Lisp error: (invalid-read-syntax ")") eval-buffer() ; Reading at buffer position 523 [....]
Mx goto-char saute à la position d'erreur:
M-x goto-char 523
la source
J'ai étendu la réponse de wasamasa pour inclure des informations supplémentaires:
la source