Comment puis-je détecter que le mode de compilation attend une entrée

Cela me fait souvent trébucher lors de la construction de noyaux Linux. Je vais lancer une compilation et après un certain temps, je me rends compte qu'elle n'est pas terminée. Ce qui se passe généralement, c'est que la configuration par défaut a changé, elle attend l'entrée de l'utilisateur dans la fenêtre de compilation. Par exemple, je trouve la fenêtre de compilation bloquée sur les éléments suivants:

-*- mode: compilation; default-directory: "~/lsrc/kvm/kernel-v8.build/" -*-
Compilation started at Tue Nov 25 10:34:20

cd /home/alex/lsrc/kvm/kernel-v8.build && ARCH=arm64 make -j9
  GEN     ./Makefile
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* File systems
*
Second extended fs support (EXT2_FS) [Y/n/m/?] y
  Ext2 extended attributes (EXT2_FS_XATTR) [N/y/?] n
  Ext2 execute in place support (EXT2_FS_XIP) [N/y/?] n
Ext3 journalling file system support (EXT3_FS) [Y/n/m/?] y
  Default to 'data=ordered' in ext3 (EXT3_DEFAULTS_TO_ORDERED) [N/y/?] n
  Ext3 extended attributes (EXT3_FS_XATTR) [N/y/?] n
The Extended 4 (ext4) filesystem (EXT4_FS) [Y/n/m/?] y
  Ext4 POSIX Access Control Lists (EXT4_FS_POSIX_ACL) [N/y/?] n
  Ext4 Security Labels (EXT4_FS_SECURITY) [N/y/?] n
  EXT4 debugging support (EXT4_DEBUG) [N/y/?] n
JBD (ext3) debugging support (JBD_DEBUG) [N/y/?] n
JBD2 (ext4) debugging support (JBD2_DEBUG) [N/y/?] n
Reiserfs support (REISERFS_FS) [N/m/y/?] n
JFS filesystem support (JFS_FS) [N/m/y/?] n
XFS filesystem support (XFS_FS) [N/m/y/?] n
GFS2 file system support (GFS2_FS) [N/m/y/?] n
Btrfs filesystem support (BTRFS_FS) [N/m/y/?] n
NILFS2 file system support (NILFS2_FS) [N/m/y/?] n
Dnotify support (DNOTIFY) [Y/n/?] y
Inotify support for userspace (INOTIFY_USER) [Y/n/?] y
Filesystem wide access notification (FANOTIFY) [Y/n/?] y
  fanotify permissions checking (FANOTIFY_ACCESS_PERMISSIONS) [Y/n/?] y
Quota support (QUOTA) [N/y/?] n
Kernel automounter version 4 support (also supports v3) (AUTOFS4_FS) [N/m/y/?] n
FUSE (Filesystem in Userspace) support (FUSE_FS) [Y/n/m/?] y
  Character device in Userspace support (CUSE) [Y/n/m/?] y
Overlay filesystem support (OVERLAY_FS) [N/m/y/?] (NEW) 

Il serait utile que je puisse détecter cela par programme afin de pouvoir signaler une notification dans ma ligne de mode. Une idée comment je pourrais détecter cela?

Emacs ne peut pas détecter pourquoi un processus enfant attend. Il pourrait attendre parce qu'il appelle read()à stdin, mais il pourrait tout aussi bien juste effectuer un calcul coûteux tout en optimisant le code C.

Cependant, ce que vous pouvez détecter, c'est si le processus de compilation a écrit une invite. Le mode de compilation s'exécute compilation-filter-hookchaque fois qu'il a inséré la sortie du processus de compilation dans le tampon de compilation. Vous êtes libre d'y ajouter vos propres fonctions.

Par exemple, vous pouvez écrire une fonction qui recherche une invite particulière dans la sortie et émet un avertissement:

(defun my-compilation-mode-warn-about-prompt ()
  (save-excursion
    (let ((re '(rx "[" (one-or-more (any "n" "N" "m" "M" "Y" "y") "/") "?]"
                   (optional " (NEW)") (zero-or-more whitespace) buffer-end)))
      (when (re-search-backward re nil 'no-error)
        (lwarn 'emacs :warning "Compilation process in %s seems stalled!"
               (buffer-name))))))

(add-hook 'compilation-filter-hook
          #'my-compilation-mode-warn-about-prompt)

Cela fera apparaître un tampon d'avertissement chaque fois que le processus de compilation imprime une invite à la fin du tampon. L'invite est reconnue en recherchant les variations de la [Y/n/?]pièce. J'utilise rxpour écrire une expression régulière lisible.

Cela devrait gérer le cas où le processus de compilation imprime une invite et attend ensuite l'entrée. Dans ce cas, l'invite sera le dernier texte inséré dans le tampon.

Cela peut provoquer des faux positifs (je n'ai pas essayé), mais comme il ne s'agit que d'un avertissement, ceux-ci devraient être tolérables.