Re: Towards a cleaner build

[Lars Ingebrigtsen]

Eli Zaretskii <address@hidden> writes:

>>         ((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.

Yeah, I was looking at the doc string for that function, which begins

---
Multibyte character codes are converted to unibyte according to
‘nonascii-translation-table’ or, if that is nil, ‘nonascii-insert-offset’.
---

which makes it sound like it's made for doing human-readable translation
somehow.  And I was fooled by ☪ happening to have * as the lower byte,
so it looked that way, too.  :-)

But I see that you've now removed that bit from the doc string, so now
it makes more sense.

>> 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.

Ok.  :-)

> 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.

Oh, sorry; thinko.

> 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.

Right.  Should we slap a with-no-warnings around this call, then?
Warning about a usage where we have verified that it's what we really,
really want to do seems counter productive...

                     ;; We want to convert each non-ASCII byte to the
                     ;; corresponding eight-bit character, which has
                     ;; a codepoint >= #x3FFF00.
                     (string-to-multibyte data))))

> 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.

Will do.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no