Re: `read-from-minibuffer' seems to always return a multibyte string, but why?
Eli Zaretskii <[email protected]>
| Newsgroups | gmane.emacs.devel |
|---|---|
| Message-ID | <[email protected]> |
> From: Nickolai Dobrynin <[email protected]> > Cc: [email protected] > Date: Tue, 25 Aug 2026 16:11:45 +0200 > > Eli Zaretskii <[email protected]> writes: > > >> From: Nickolai Dobrynin <[email protected]> > >> Date: Tue, 25 Aug 2026 05:47:52 +0200 > >> > >> I ran M-x ielm, executed > >> > >> (set-buffer-multibyte nil) > >> (read-from-minibuffer "Input: ") > >> > >> and got a multibyte string back. > > > > Please show exactly what you did. If I do this: > > > > emacs -Q > > M-: (set-buffer-multibyte nil) RET > > M-: (multibyte-string-p (read-from-minibuffer "? " nil nil nil nil nil t)) RET > > > > and type "foo RET" at the prompt, I get nil as the result, as > > expected. > > I evaluated the two forms above but did not use the -Q command line option. > > I noticed that the final argument in your example is set to t. In my > example, it defaulted to nil. > > Your example does work as expected. OK, so everything is fine, IMO, since the last argument should be non-nil to force inheritance of multibyte-ness. > >> 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. > > > > Why do you care, may I ask? > > I've been looking at `gnus-search-make-spec' in gnus-search.el and > asking myself what kind of string this function returns. The final > argument in the call to `read-from-minibuffer' defaults to nil. I must > have understood the meaning of that argument in reverse. OK, but still: why did you care whether gnus-search-make-spec returns a unibyte or a multibyte string? You see, usually functions that return strings to the application level (including UI) should always return multibyte strings when non-ASCII characters are involved, and either multibyte or unibyte strings when only ASCII characters are involved. Anything else is either a bug or a very special situation. So you should always expect a multibyte string if there's non-ASCII text, and complain if somehow that's not what you get.