bug#48254: 28.0.50; minibuffer does not show the prompt of a command on first invocation

[max . brieiev]

Gregory Heytings <gregory@heytings.org> writes:

> (add-hook 'change-major-mode-hook (lambda () (or (minibufferp) 
> (set-input-method "english-dvorak"))))
> (add-hook 'minibuffer-setup-hook (lambda () (set-input-method 
> "english-dvorak")))
> ...
> Does that solve the problem you have?

Thanks, this solves the issue.

But I have some other issues related to input methods, which I don't
know how to reproduce reliably. Maybe you can give me some hints and I
will report them as separate bugs.

One issue is related to the prompts, where the input is a single key
like "y" or "!", like the prompt shown when you have some modified
buffers while exiting Emacs. Sometimes I have to press the key as it is
laid on qwerty layout, but sometimes it is as on dvorak layout. This is
quite annoying, since I always have to guess, which layout is active for
the shown yes-no prompt.

The other issue is probably somehow related to Edebug. I am learning
elisp, so I often run Edebug just to learn how some functionality
works. Once in a while, when some breakpoint is hit, something bad
happens to Emacs in a way that each keymap that defines just basic
characters (I mean without modifier bits), like Info buffer, or Edebug,
or Gnus is turned to think that underlying layout is dvorak. So pressing
"l" inside Info buffer runs actually 'Info-next' command, which is bound
to "n", istead of going back in history. So to make keybindings operate
normally again I have to press "C-\" in every buffer to reset input
method. The other side effect of this is that read-only edebug buffer
suddenly becomes editable and I can enter text there, though mode line
still shows '%%'.