bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#56685: OBOE in string-truncate-left?
Date: Fri, 22 Jul 2022 14:31:03 +0300

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]