bug#56685: OBOE in string-truncate-left?

[Stephen Berman <stephen.berman@gmx.net>]

On Fri, 22 Jul 2022 14:31:03 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> Cc: 56685@debbugs.gnu.org
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Fri, 22 Jul 2022 12:26:09 +0200
>>
>> Yes, and I also think it's counterintuitive that LENGTH includes the
>> length of "...".  Worse, if STRING is short enough, the resulting string
>> (with "...") can be longer than LENGTH:
>>
>> (string-truncate-left "band" 3)
>> "...d"
>> (string-truncate-left "band" 2)
>> "...d"
>> (string-truncate-left "band" 1)
>> "...d"
>> (string-truncate-left "and" 2)
>> "...d"
>> (string-truncate-left "and" 1)
>> "...d"
>
> The above calls make no sense to me: since it is known up front that
> the function will prepend "...", what else does the caller expect from
> such calls?
>
>> Note that with the last two examples, the result is longer than the
>> original string, contradicting the meaning of truncation.
>
> The function truncates STRING, not the result it returns.  So I see no
> contradiction here.  And again, what would you do instead?  Because
> this:
>
>>  (defun string-truncate-left (string length)
>> -  "Truncate STRING to LENGTH, replacing initial surplus with \"...\"."
>> +  "Return STRING's last LENGTH characters prefixed with \"...\".
>> +If the resulting string with the prefix is not shorter than the
>> +original length of STRING, return STRING unchanged."
>
> again makes no sense to me: you have forcibly prevented any Lisp
> program from truncating STRING because you personally don't like the
> result in these cases.  But the fact that you don't like it doesn't
> yet mean it isn't a valid use case.  If your applications don't want
> truncation in those case, it is easy to provide a trivial wrapper
> around string-truncate-left.

Currently, the result of applying string-truncate-left to STRING can be
a string just as long as STRING but beginning with "..." instead of the
first three letters of STRING.  What is a valid use case for that?

Steve Berman