Re: Towards a cleaner build

[Eli Zaretskii]

> From: Lars Ingebrigtsen <address@hidden>
> Date: Fri, 17 May 2019 05:51:37 +0200
> 
> In ps-begin-job:
> ps-print.el:5773:17:Warning: ‘string-as-unibyte’ is an obsolete function (as
>     of 26.1); use ‘encode-coding-string’.
> ps-print.el:5775:17:Warning: ‘string-as-unibyte’ is an obsolete function (as
>     of 26.1); use ‘encode-coding-string’.
> 
> Here's the code:
> 
>       (cond ((eq ps-print-control-characters '8-bit)
>              (string-as-unibyte "[\000-\037\177-\377]"))
>             ((eq ps-print-control-characters 'control-8-bit)
>              (string-as-unibyte "[\000-\037\177-\237]"))
>             ((eq ps-print-control-characters 'control)
>              "[\000-\037\177]")
>             (t "[\t\n\f]"))
> 
> But...  aren't both those strings unibyte already?

The question is not whether the original strings are unibyte, the
question is does

  (setq foo "[\000-\037\177-\377]")

produce a unibyte or a multibyte string, including after processing by
the Lisp reader (and when this file is byte-compiled).  E.g., \377 is
above decimal 127, so it could, in principle, be interpreted as the
corresponding Unicode codepoint of a Latin character.

If you verified that removing string-as-unibyte here produces a
unibyte string in ps-control-or-escape-regexp, including after
byte-compilation, then yes, we can remove that function call here.
But for making this future-proof, I'd add an assertion there, or maybe
add a test to verify this stays that way, come what may.

Thanks.