Como depurar erros em sentinelas e durante o bloqueio de fonte


10

Quando ocorre um erro dentro de um sentinela de processo ou durante o bloqueio de fontes, o Emacs não mostra um backtrace, apesar de debug-on-errorter sido ativado anteriormente.

Entendo por que esses erros foram detectados, o mesmo erro pode ser acionado novamente ao tentar apresentar o backtrace. No entanto, quando eu quero realmente depurar esse erro, não é muito útil. Eu prefiro arriscar o Emacs a não responder, do que ter que trabalhar com isso:

error in process sentinel: Wrong type argument: stringp, nil

Afinal, posso começar uma segunda instância, se a primeira começar a enlouquecer. Um pouco mais de contexto ajudaria quando há muitos lugares em que esse erro poderia teoricamente ocorrer em uma sentinela.

Então, como posso forçar o Emacs a mostrar um retorno, mesmo nos casos em debug-on-errorque não tem efeito?


11
Eu já vi emacs.stackexchange.com/questions/3552/…, mas acho que deveria haver uma pergunta sobre isso em geral, não apenas um caso em particular. Também espero realmente que "use printf" não seja a única resposta, porque é isso que eu usei no passado e não é satisfatório, especialmente se o erro for "Referência de rosto inválida: alguém que eu saiba absolutamente -exists ", que pode ser acionado por praticamente todos os pacotes que eu instalei.
tarsius 14/11/14

O URL aponta para esta pergunta e, portanto, é bastante confuso no seu comentário, é intencional ou é um erro em seu nome?
wasamasa

Esse é o problema que eu quis dizer: ttp: //emacs.stackexchange.com/questions/1045/how-to-debug-startup-problem-if-debug-init-has-no-effect
tarsius

o link tarsius pretendia: emacs.stackexchange.com/questions/1045/… ug-init-has-no-effect
dcorking

Respostas:


10

Para sentinelas de processo, acho que não há uma boa razão. Acho que é apenas um recurso que falta, por isso sugiro M-x report-emacs-bug.

No caso do bloqueio de fonte, o problema é mais complicado, porque o que realmente acontece é que o erro é acionado durante o jit-lock, ou seja, durante a exibição novamente, e não podemos entrar facilmente no depurador naquele momento (IIRC em algum momento, Gerd tentou funcionou, mas ainda havia alguns problemas sérios). Portanto, você pode depurá-lo de uma das seguintes maneiras:

  • M-x jit-lock-debug-mode que altera o jit-lock para executar logo após a exibição novamente, para que possamos entrar no depurador.
  • M-: (setq font-lock-support-mode nil) RETe desabilite + reativar o bloqueio de fonte. Dessa maneira, o bloqueio de fonte não usa mais o jit-lock, portanto, ele é executado durante o comando do usuário e não durante a exibição posterior subsequente.

Na verdade, debug-on-errorparece funcionar bem em sentinelas de processo.
Stefan

@tarsius - por favor, postar um link para o seu problema debbugs
dcorking

a solicitação de recurso do tarsius é 19432, onde está marcada como improdutível. Stefan Monnier postou uma solução alternativa que usa --evalmais que não --debug-init . Também a sua solução não me ajuda a cair em um backtrace na minha real.emacs.d
dcorking

11
@dcorking: não, no bug # 19432, eu não publiquei uma "solução alternativa", mas uma tentativa fracassada de reproduzir seu bug. Por que você não envia uma receita para reproduzir seu problema?
Stefan
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.