Invia l'output del processo al buffer * Messaggi *, ma ignora l'area dell'eco

È possibile inviare l'output da un filtro di processo al *Messages*buffer e sopprimere l'output del messaggio dall'area di eco, in modo tale da poter utilizzare simultaneamente i comandi interattivi senza minibuffer-promptessere cancellato dall'output del filtro di subpress in corso?

(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 gennaio 2015): Il seguente è un collegamento a una domanda simile, tuttavia, non sono ancora stato in grado di farlo funzionare con una stringa di processo in cui la stringa esatta non è nota - il titolo del thread è: Emacs - Disabilita alcuni messaggi del Minibuffer :

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

minibuffer process echo-area

— lawlist
fonte

Non penso che tu possa. Perché non accedere a un altro buffer? Questo è ciò che fanno la maggior parte delle modalità che trattano i processi ...

— lunaryorn,

@lunaryorn - Grazie per il suggerimento - un buffer dedicato è un'opzione valida per risolvere il problema. Ci sono alcuni output di processo che ho una preferenza personale per essere inviato al *Messages*buffer - i progetti relativi alla sincronizzazione sono uno di questi. Ci sono ancora un paio di cose che non ho provato ( perché pensavo che ci potesse essere una soluzione integrata ), come rendere il *Messages*buffer temporaneamente scrivibile inhibit-read-onlye usare insertat point-max- Non so se verrà visualizzato in anche l'area dell'eco. Ci lavorerò di nuovo stasera. . .

— elenco delle leggi

Una nota di interesse è che le funzioni C per la messaggistica sono molto separate da preoccupazioni di "eco" e "registrazione", ma questa distinzione non è esposta a elisp. Forse potresti M-x report-emacs-buge richiederlo come funzionalità?

— phils,

@phils | @lunaryorn: sono stato in grado di ottenere l'effetto desiderato utilizzando

(let ((inhibit-read-only t)) (with-current-buffer (get-buffer-create "*Messages*") (goto-char (point-max)) (insert string)))

e ho pubblicato una bozza di risposta, che sarà ammissibile per l'accettazione dopo che è scaduto il periodo di attesa obbligatorio sulla domanda di un utente. Ho presentato una richiesta di funzione con report-emacs-bug: debbugs.gnu.org/cgi/bugreport.cgi?bug=19495

— elenco delle leggi

elenco delle leggi: non avevo intenzione di suggerire quell'approccio perché potresti scontrarti con la logica per la gestione di messaggi duplicati, ecc. (Ma potrebbe anche andare bene; non lo so davvero.) Probabilmente dovresti usare (messages-buffer)per ottenere il buffer , se segui questo metodo e noti che (point-max)non sarà sempre l'inizio di una nuova riga (ad esempio, usa C-g).

— phils,

Risposte:

È possibile sopprimere la visualizzazione nel minibuffer impostando minibuffer-message-timeoutsu 0.

Ad esempio, utilizzo qualcosa del genere in alcuni punti in cui desidero attivare una modalità minore mentre mi viene richiesto un minibuffer (come ido find-file) senza essere interrotto da un messaggio 'mode enabled':

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

— Glucas
fonte

Grazie per il suggerimento; tuttavia, ciò non ha ottenuto l'effetto desiderato. La stampa dell'output del processo in corso con (let ((minibuffer-message-timeout 0)) (message "%s" string))ancora viene visualizzata nell'area eco / minibuffer quando si digitano funzioni interattive come execute-extended-commando switch-to-buffer-other-window- ovvero, il completamento e il completamento suggerito vengono cancellati dai messaggi di output del processo.

— elenco delle leggi

First Rough Draft (3 gennaio 2015): revisione della bozza iniziale basata sull'utile commento di @phils sull'utilizzo della funzione messages-bufferper individuare o creare il buffer appropriato (e inserirlo messages-buffer-mode); e, aggiunto un controllo per verificare se si point-maxtrova all'inizio della riga (in caso contrario, quindi inserire una nuova riga prima di inserire la stringa di messaggio).

EDIT (4 gennaio 2015): ci sono situazioni in cui la stringa inserita potrebbe non finire necessariamente in una nuova riga e la funzione messagenon ha un controllo per assicurarsi che sia all'inizio di una nuova riga, quindi ci occupiamo di ciò in questa funzione. Pertanto, in qualsiasi momento quando si messageinserisce una nuova riga, detta riga inizierà a livello di colore sinistro del buffer.

(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"))))))

— lawlist
fonte

Passando attraverso la docstring di messagesembra che dovrebbe essere possibile ottenere quello che vuoi chiamando messaggio con un nilargomento subito dopo la chiamata messagecon il contenuto desiderato. Dalla dotstring dimessage

Se il primo argomento è zero o la stringa vuota, la funzione cancella qualsiasi messaggio esistente; questo consente di mostrare il contenuto del minibuffer.

Quindi, modificando la tua funzione in qualcosa di simile al seguente dovrebbe funzionare

(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)))

L'ho provato facendo quanto segue

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

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

e sembra funzionare

— Iqbal Ansari
fonte

Grazie per il suggerimento Questa idea, quando viene testata con un output del processo in esecuzione nel *Messages*buffer e quindi chiamando il comando interattivo execute-extended-command, mostra quanto segue: il prompt interattivo (ovvero M-xeventuali completamenti parziali) e l'output del processo - ovvero, i due tornano indietro e avanti alla velocità della luce, ma lo sfarfallio tra i due è percepibile. Questo sembra essere il caso perché il particolare processo in questione sputa costantemente nuovi messaggi e quel nuovo messaggio viene visualizzato per una frazione di secondo nell'area dell'eco.

— elenco delle leggi