Envoyer la sortie du processus au tampon * Messages *, mais contourner la zone d'écho


9

Est-il possible d'envoyer la sortie d'un filtre de processus au *Messages*tampon et de supprimer cette sortie de message d'apparaître dans la zone d'écho, de sorte que je puisse utiliser simultanément des commandes interactives sans minibuffer-promptêtre effacé par la sortie du filtre de sous-presse en cours?

(defun rsync-process-filter (proc string)
  (when (not (or
      (string-match "files...\r" string)
      (string-match "files to consider\n" string)))
    (message "%s" string)))

EDIT (3 janvier 2015): Ce qui suit est un lien vers une question similaire, cependant, je n'ai pas encore pu le faire fonctionner avec une chaîne de processus où la chaîne exacte est inconnue - le titre du fil est: Emacs - Désactiver certains messages du mini-tampon :

/superuser/669701/emacs-disable-some-minibuffer-messages


Je ne pense pas que ce soit possible. Pourquoi ne pas simplement vous connecter à un autre tampon? C'est ce que font la plupart des modes qui traitent des processus…
lunaryorn

@lunaryorn - Merci pour la suggestion - un tampon dédié est une option valide pour résoudre le problème. Il y a quelques sorties de processus que j'ai une préférence personnelle pour être envoyées au *Messages*tampon - les projets liés à la synchronisation en font partie. Il y a encore quelques choses que je n'ai pas essayées ( parce que je pensais qu'il y avait peut-être une solution intégrée ), comme rendre le *Messages*tampon temporairement accessible en écriture inhibit-read-onlyet l'utiliser insertà point-max- je ne sais pas si cela apparaîtra dans la zone d'écho également. Je vais y travailler à nouveau ce soir. . .
lawlist

Une note intéressante est que les fonctions C pour la messagerie sont très séparées par des problèmes d '"écho" et de "journalisation", mais cette distinction n'est pas exposée à elisp. Peut-être pourriez-vous M-x report-emacs-buget demander cela en tant que fonctionnalité?
phils

@phils | @lunaryorn: J'ai pu obtenir l'effet souhaité en utilisant (let ((inhibit-read-only t)) (with-current-buffer (get-buffer-create "*Messages*") (goto-char (point-max)) (insert string)))et j'ai publié un projet de réponse, qui pourra être accepté après l'expiration de la période d'attente obligatoire sur la propre question d'un utilisateur. J'ai déposé une demande de fonctionnalité auprès de report-emacs-bug: debbugs.gnu.org/cgi/bugreport.cgi?bug=19495
lawlist le

lawlist: Je ne suggérez cette approche parce que vous pourriez aller à l' encontre de la logique pour le traitement des messages en double, etc. (mais il pourrait aussi bien, je ne sais pas vraiment.) Vous devriez probablement utiliser (messages-buffer)pour obtenir le tampon , si vous vous en tenez à cette méthode, et notez que (point-max)ce ne sera pas toujours le début d'une nouvelle ligne (par exemple, utilisation C-g).
phils

Réponses:


3

Vous pouvez supprimer l'affichage dans le mini-tampon en réglant minibuffer-message-timeoutsur 0.

Par exemple, j'utilise quelque chose comme ça à quelques endroits où je veux basculer un mode mineur dans une invite de mini-tampon (comme ido find-file) sans être interrompu par un message `` mode activé '':

(let ((minibuffer-message-timeout 0))
    (toggle-some-mode))

Merci pour la suggestion; cependant, cela n'a pas atteint l'effet souhaité. L'impression de sortie de processus en cours avec (let ((minibuffer-message-timeout 0)) (message "%s" string))toujours des affichages dans la zone d'écho / mini-tampon lors de la saisie de fonctions interactives comme execute-extended-commandou switch-to-buffer-other-window- c'est-à-dire que l'invite et les compléments suggérés sont effacés par les messages de sortie de processus.
Lawlist

3

Première ébauche (3 janvier 2015): ébauche initiale révisée basée sur le commentaire utile de @phils concernant l'utilisation de la fonction messages-bufferpour localiser ou créer la mémoire tampon appropriée (et la placer dans messages-buffer-mode); et, ajouté une vérification pour savoir si point-maxest au début de la ligne (sinon, insérez une nouvelle ligne avant d'insérer la chaîne de message).

EDIT (4 janvier 2015): Il y a des situations où la chaîne insérée ne se termine pas nécessairement par une nouvelle ligne, et la fonction messagen'a pas de vérification pour s'assurer qu'elle se trouve au début d'une nouvelle ligne, donc nous prenons soin de cela dans cette fonction. Ainsi, à tout moment où messageinsère une nouvelle ligne, cette ligne commencera à gauche de la mémoire tampon.

(defun rsync-process-filter (proc string)
  (let ((inhibit-read-only t))
    (when (not (or
        (string-match "files...\r" string)
        (string-match "files to consider\n" string)))
      (with-current-buffer (messages-buffer)
        (goto-char (point-max))
        (when (not (bolp))
          (insert "\n"))
        (insert string)
        (when (not (bolp))
          (insert "\n"))))))

2

En parcourant la docstring, messageil semble qu'il devrait être possible d'atteindre ce que vous voulez en appelant un message avec un nilargument immédiatement après avoir appelé messageavec le contenu souhaité. De la docstring demessage

Si le premier argument est nul ou la chaîne vide, la fonction efface tout message existant; cela permet d'afficher le contenu du mini-tampon.

Donc, modifier votre fonction en quelque chose comme ce qui suit devrait fonctionner

(defun rsync-process-filter (proc string)
  (when (not (or
      (string-match "files...\r" string)
      (string-match "files to consider\n" string)))
    (message "%s" string)
    (message nil)))

Je l'ai testé en procédant comme suit

(defun test ()
  (message "%s" "Test")
  (message nil))

(run-at-time 5 5 #'test)

Et ça semble marcher


Merci pour la suggestion. Cette idée, lorsqu'elle est testée avec une sortie de processus en cours d'exécution dans la *Messages*mémoire tampon, puis en appelant la commande interactive execute-extended-command, montre les éléments suivants: l'invite interactive (c'est-à-dire M-xet tout achèvement partiel) et la sortie du processus - c'est-à-dire que les deux commutent en arrière et à la vitesse de la lumière, mais le scintillement entre les deux est perceptible. Cela semble être le cas parce que le processus particulier en cause crache constamment de nouveaux messages et que ce nouveau message est affiché pendant une fraction de seconde dans la zone d'écho.
lawlist
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.