Comment interrompre emacs lorsque control-g ne fonctionne pas dans des fichiers très volumineux?

J'ai rencontré une sorte de comportement O (n ^ 2) ou pire lors de la visualisation de fichiers très volumineux (par exemple 128 Mo) dans Emacs et du saut à la fin du fichier. Je pense que cela peut avoir à voir avec mon algorithme de coloration pour colorer le texte contextuellement. Si je tape control-g (keyboard-quit), l'opération n'est pas affectée. Je voudrais un moyen de récupérer ma session emacs sans simplement la tuer. J'ai essayé d'envoyer un SIGINT, mais emacs vient de sortir. Y a-t-il des signaux que je peux envoyer, ou d'une autre manière (peut-être dans un débogueur) pour forcer l'action en cours d'exécution à abandonner et à me rendre le contrôle?

emacs syntax-highlighting

— WilliamKF
source

Je ne connais pas de moyen de rendre le verrouillage des polices interruptible, mais vous pourriez trouver quelque chose d'utile dans cette page Wiki Emacs sur l'accélération du verrouillage des polices .

— Aaron Miller

Avez-vous essayé de frapper escape 3 fois?

— yPhil

Oui, je pense que votre propre code de verrouillage de police est probablement en cause ici. Examinez font-lock-keywordsattentivement vos expressions rationnelles pour essayer de trouver le problème.

— Drew

EMACS: huit mégaoctets et

— échange

Frapper trois fois la fuite ne fait rien pour moi.

— WilliamKF

Réponses:

Je doute que ce soit le mode de verrouillage des polices. Cela ne fait probablement que des sections proches de ce qui est visible. Il s'agit probablement de copier des données en mémoire.

sigusr1

sigusr2

Ces événements sont générés lorsque le processus Emacs reçoit les signaux SIGUSR1et SIGUSR2. Ils ne contiennent aucune donnée supplémentaire car les signaux ne transportent pas d'informations supplémentaires. Ils peuvent être utiles pour le débogage (voir Débogage d'erreur ).

Source: Manuel de référence GNU Emacs Lisp: Événements divers

Je ne sais pas ce que cela ferait (ou quelle version d'emacs vous utilisez) mais vous pouvez essayer un signal PROBABLY non destructif (USR1 ou USR2).

$ kill -USR1 pid

Ou vous pouvez vous endormir et voir si elle se rétablit.

— 9mjb
source

Je me demande à quel point votre ordinateur est occupé (CPU et disque). Cela pourrait vous en dire un peu plus sur ce qu'il fait. .. et vous pourrez peut-être exécuter une autre copie d'emacs et "kill -USR1 pid" cette nouvelle pour voir ce qui se passe avant de faire celle qui vous intéresse.

— 9mjb

Wow, l'envoi kill -USR2à emacs-mac a fonctionné pour moi dans une situation similaire - a chargé un gros fichier en mode js2 et a commencé une recherche. USR2 quitte l'isearch et entre dans le débogueur. Bien mieux que de tuer le processus!

— William

Je suis en désaccord avec vos doutes. Le kill a fonctionné pour moi. Cela m'a donné un coup de pied au débogueur et la région de font-lock-default-fontify-était où il était bloqué.

— Brian C.

Je ne suis pas au courant de la gestion du signal qu'emacs fait, mais vous pouvez utiliser le serveur Emacs en plaçant server-startvotre fichier ~ / .emacs afin que vous puissiez faire RPC sur votre instance d'emacs en cours d'exécution.

Ensuite, lorsque vous voulez tuer emacs et écrire, vous pouvez appeler depuis votre shell emacsclient -e '(save-buffers-kill-emacs t)'.

— Dwight Spencer
source