Por que alguns comandos terminam ao sair do minibuffer (isearch) enquanto outros não (find-file)?

6

Ocasionalmente, começo a abrir um arquivo e, antes de selecioná-lo, por algum motivo, executo C-x oantes de responder ao prompt. Então, toda vez que eu tento executar find-filenovamente, ele reclama que o Command tentou usar o minibuffer enquanto estava no minibuffer . No entanto, se eu usar um comando como isearch-forward-regexp(mesmo se já estiver em um find-fileprompt), o erro não será gerado e não posso voltar ao minibuffer usando other-window.
Por que alguns prompts atualizam temporariamente o minibuffer de modo que o other-windowconsidere um possível alvo e outros não?

Só para esclarecer, não estou perguntando como se soltar.
Originalmente, quando eu encontrava isso, eu alternava para o minibuffer e fazia Esc Esc Escou C-gescapava do prompt, para poder iniciar um novo comando que usa o minibuffer. No entanto, ao refletir sobre essa questão, percebi que abort-recursive-edit( C-]) encerraria esse minibuffer em andamento sem ter que fazer other-window+ keyboard-quit.

Ainda assim, não tenho muita certeza para que serve o caso de uso original. Talvez isso tenha como objetivo ajudar a colar a cópia em um prompt de minibuffer ou auxiliar na execução de um comando no meio de uma macro?

O que eu não quero saber é se existe uma maneira de desativar este recursividade do jeito que está com isearch. É isearchseguro porque está usando evento de leitura em vez de um prompt de bloqueio? Existe um gancho para disparar abort-recursive-editao sair do minibuffer?

TL; DR

  1. Por que alguns comandos do minibuffer atualizam o minibuffer para um destino other-windowe bloqueiam a execução de novos comandos do minibuffer, enquanto outros, como isearch, não?
  2. Existe uma maneira de desativar isto?
  3. Qual é o caso de uso pretendido desse recurso?
minibuffer recursive-edit dgtized
fonte
2
Sua pergunta não está clara para mim. Apenas o que você está tentando fazer? C-]aborta um nível de minibuffer, sim. O Isearch não usa o minibuffer. E o que " preso no prompt " tem a ver com o restante do que você descreve? Você não precisa usar switch-window, em tais contextos. Mas não está claro o que você está tentando fazer. Tente separar as várias partes da sua descrição e tente criar uma única pergunta.
Tirou
2
Tente configurar enable-recursive-minibufferspara tevitar que o comando tente usar o minibuffer enquanto estiver na mensagem do minibuffer . Pode ajudar a esclarecer a pergunta original, se você a postou recursive-editseparadamente.
Vamsi

Respostas:

5
  1. Muitos comandos interativos leem a entrada do minibuffer. find-fileé um desses comandos. A leitura da entrada do minibuffer "ativa" a janela do minibuffer, e é por isso que você pode alternar para ela com o other-windowcomando Interativo isearché especial porque é implementado como um modo secundário. Tecnicamente, ele não lê sua string de pesquisa no minibuffer, mas captura as teclas pressionadas enquanto você digita e as repete no minibuffer message. É por isso que você vê um other-windowcomportamento diferente.
  2. Isso pode ou não ajudá-lo, mas tecnicamente você pode modificar o comportamento imediato find-file, modificando a função armazenada em read-file-name-function. Eu não tentei aconselhar a função com base na resposta do @ kaushalmodi, mas se isso funcionar, atualizarei isso.
  3. Não posso falar por nenhum dos hackers que trabalharam no código no minibuffer.el, mas pela descrição a seguir no manual , acho que o comportamento foi projetado para permitir que você mate e puxe o texto:

Quando o minibuffer está ativo, a área de eco é tratada como uma janela comum do Emacs. Por exemplo, você pode alternar para outra janela (com Cx o), editar o texto lá e retornar à janela do minibuffer para finalizar o argumento. Você pode até matar o texto em outra janela, retornar à janela do minibuffer e puxar o texto para o argumento.

purple_arrows
fonte
2

O trecho abaixo [ Fonte ] interrompe a edição recursiva quando o foco se afasta do minibuffer. Isso evita as ocasiões irritantes em que C-gpressionar repetidamente não edita o mini-buffer quando o foco do cursor sai dele.

(desativar o comando stop-using-minibuffer ()
  "mate o minibuffer"
  (quando (e (> = (profundidade da recursão) 1) (janela do minibuffer ativo)))
    (abortar-recursiva-editar)))
(adicionar gancho 'mouse-deixar-buffer-gancho' parar de usar o minibuffer)
Kaushal Modi
fonte
1

Drew já comentou sobre isso, mas ...

isearch1 realmente não usar o minibuffer, o que provavelmente é responsável por parte de sua confusão. Ele exibe itens na área de eco (que fica na mesma janela do minibuffer, mas na verdade não é o minibuffer).

Sendo esse o caso, a noção de alternar de e para o mini-buffer durante a execução de uma pesquisa não faz nenhum sentido.

1 comandos Ignorando como isearch-edit-stringo que fazer usar o minibuffer, mas não fazem parte dos mais básicos isearch workflow.

phils
fonte