Re: Towards a cleaner build

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 17 May 2019 05:32:58 +0200
> 
> In xselect--encode-string:
> select.el:475:24:Warning: ‘string-make-unibyte’ is an obsolete function (as of
>     26.1); use ‘encode-coding-string’.
> 
> This is the code:
> 
> 	   ((eq type 'C_STRING)
> 	    (setq str (string-make-unibyte str)))
> 
> (string-make-unibyte "á☪foo")
> => "\341*foo"

This example is not relevant, because C_STRING is for strings that are
actually binary blobs, i.e. sequences of raw bytes.  If you use
examples of human-readable text, you get the wrong impression of what
is intended.

> I'm guessing the point here is to make an 8-bit string that is somewhat
> congruent with the (possibly) multibyte string that we have here?

The point here is to convert our internal multibyte representation of
raw bytes into their external single-byte representation.

> Do we have a library function (or a coding system) that does the
> same thing?

Yes, it's called string-make-unibyte ;-)

I'm not sure we have anything else, but let me dwell on this for a
while.

Btw, your other change in select.el was incorrect, and I reverted it.
For starters, when we need to _decode_ text (which is what
gui-get-selection does, since it imports text into Emacs), it can
never be TRT to _encode_ it.  And second, there's no such
coding-system as 'eight-bit', that's a name of a charset.

  (coding-system-p 'eight-bit) => nil

So something like (encode-coding-string FOO 'eight-bit) will do
nothing useful, and just signal an error.

In general (with the possible exception of Gnus ;-), the places where
we left those string-make/to/as-uni/multibyte thingies are there not
because we were lazy, but because the replacements are either not
trivial or don't exist.  The deprecation message's advice in most of
these cases is simply misleading.  So I welcome work on these places,
but my advice is to discuss each one of them before making changes,
lest we break the code in some more or less subtle use cases.

Thanks.