Re: `read-from-minibuffer' seems to always return a multibyte string, but why?

On Tue, Aug 25, 2026 at 05:47:52AM +0200, Nickolai Dobrynin wrote:
> I ran M-x ielm, executed
> 
> (set-buffer-multibyte nil)
> (read-from-minibuffer "Input: ")
> 
> and got a multibyte string back.
> 
> The manual says: "If the argument inherit-input-method is non-nil, then
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the minibuffer inherits the current input method (see Input Methods) and
> the setting of enable-multibyte-characters (see Text Representations)
> from whichever buffer was current before entering the minibuffer". By
> this logic, I probably should have been given a unibyte string back
> instead. Is this a contradiction?

But in your example above, this argument /is/ nil (here's the call
template):

  (read-from-minibuffer PROMPT &optional INITIAL-CONTENTS KEYMAP READ HIST DEFAULT-VALUE INHERIT-INPUT-METHOD)

... you would have to invoke it like so:

  (read-from-minibuffer "Input: " "" nil nil nil "" t)

(or whatever values seem apropriate for all the other arguments).

If an optional argument is missing (in your case above this inherit-
input-method), it defaults to nil.

> The manual merely says that either a STRING (which one? Uni- or multi-?)
> or a Lisp object is returned.
> 
> By the way, a multibyte string was really what I wanted out of this. I
> just want to be sure that this behavior is not accidental.
> 
> It feels like I am missing something obvious.

Hope that helps

Cheers
-- 
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCao0iaQAKCRAFyCz1etHa
RtTPAJwPcn0w1ZlvQwfBLIy5Inkt51sh/wCfVw0hGzhygP4XcJR8N1K3hoWhQcc=
=qCQS
-----END PGP SIGNATURE-----