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

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

[Stefan Kangas]

Try evaluating:

    (length (string-truncate-left "longstring" 8))
    => 9

But the docstring says "Truncate STRING to LENGTH".
This seems like a bug.

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

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On Thu, 21 Jul 2022 17:10:36 -0500 Stefan Kangas <stefan@marxist.se> wrote:

> Try evaluating:
>
>     (length (string-truncate-left "longstring" 8))
>     => 9
>
> But the docstring says "Truncate STRING to LENGTH".
> This seems like a bug.

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"

Note that with the last two examples, the result is longer than the
original string, contradicting the meaning of truncation.  I think
LENGTH should mean just the numbers of characters in STRING after
truncation (excluding "..."), and if the result with the prefix "..." is
not shorter than the original string, there should be no truncation.
The following patch does this.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: string-truncate-left patch --]
[-- Type: text/x-patch, Size: 933 bytes --]

diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el
index 5037ae47e8..6eefd5d141 100644
--- a/lisp/emacs-lisp/subr-x.el
+++ b/lisp/emacs-lisp/subr-x.el
@@ -107,12 +107,13 @@ 'string-reverse

 ;;;###autoload
 (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."
   (let ((strlen (length string)))
-    (if (<= strlen length)
+    (if (<= strlen (+ length 3))
 	string
-      (setq length (max 0 (- length 3)))
-      (concat "..." (substring string (max 0 (- strlen 1 length)))))))
+      (concat "..." (substring string (max 0 (- strlen length)))))))

 (defsubst string-blank-p (string)
   "Check whether STRING is either empty or only whitespace.

[-- Attachment #3: Type: text/plain, Size: 20 bytes --]


--
Steve Berman

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

[Eli Zaretskii]

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

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

[Stephen Berman]

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

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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: stefan@marxist.se,  56685@debbugs.gnu.org
> Date: Fri, 22 Jul 2022 14:35:02 +0200
> 
> 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?

When STRING is part of a longer string.

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

[Stephen Berman]

On Fri, 22 Jul 2022 16:33:07 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: stefan@marxist.se,  56685@debbugs.gnu.org
>> Date: Fri, 22 Jul 2022 14:35:02 +0200
>>
>> 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?
>
> When STRING is part of a longer string.

I don't see why that is relevant, and one of the few uses of
string-truncate-left in the Emacs sources seems to confirm my doubt,
namely, in gnus-shorten-url, which results in displaying
e.g. "cvs.savannah.gnu.org...emacs.svg?view=log" instead of
"https://cvs.savannah.gnu.org/viewvc/emacs/emacs/etc/images/icons/hicolor/scalable/apps/emacs.svg?view=log".
But if the too-long string is
"https://cvs.savannah.gnu.org/viewv/emacs/emacs/1/", then with the
current string-truncate-left gnus-shorten-url "shortens" it to
"cvs.savannah.gnu.org...ewv/emacs/emacs/1/".  AFAICS replacing the three
characters "/vi" by "..." here just loses information.  Can you show a
specific case where such a length-preserving substitution is preferable?

Steve Berman

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

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> But if the too-long string is
> "https://cvs.savannah.gnu.org/viewv/emacs/emacs/1/", then with the
> current string-truncate-left gnus-shorten-url "shortens" it to
> "cvs.savannah.gnu.org...ewv/emacs/emacs/1/".  AFAICS replacing the three
> characters "/vi" by "..." here just loses information.

What's the parameters when that happens?  I get:

(gnus-shorten-url "https://cvs.savannah.gnu.org/viewv/emacs/emacs/1/" 41)
=> "cvs.savannah.gnu.org/viewv/emacs/emacs/1/"

(gnus-shorten-url "https://cvs.savannah.gnu.org/viewv/emacs/emacs/1/" 40)
=> "cvs.savannah.gnu.org...wv/emacs/emacs/1/"

Anyway, I think the examples show that this function isn't very useful
if LENGTH is very small -- it really does want to add "..." to signal
that some shortening has happened, and that may make the string longer.
But just returning "d" for (string-truncate-left "and" 1) isn't correct
either.

I've now fixed the originally reported off-by-one error when shortening,
and documented the quirks of the function in Emacs 29.

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

[Stephen Berman]

On Sat, 23 Jul 2022 08:58:35 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> But if the too-long string is
>> "https://cvs.savannah.gnu.org/viewv/emacs/emacs/1/", then with the
>> current string-truncate-left gnus-shorten-url "shortens" it to
>> "cvs.savannah.gnu.org...ewv/emacs/emacs/1/".  AFAICS replacing the three
>> characters "/vi" by "..." here just loses information.
>
> What's the parameters when that happens?  I get:
>
> (gnus-shorten-url "https://cvs.savannah.gnu.org/viewv/emacs/emacs/1/" 41)
> => "cvs.savannah.gnu.org/viewv/emacs/emacs/1/"
>
> (gnus-shorten-url "https://cvs.savannah.gnu.org/viewv/emacs/emacs/1/" 40)
> => "cvs.savannah.gnu.org...wv/emacs/emacs/1/"

Same here; in my example, I used 40 since that's what
gnus-summary-browse-url (the caller of gnus-shorten-url) uses.

> Anyway, I think the examples show that this function isn't very useful
> if LENGTH is very small -- it really does want to add "..." to signal
> that some shortening has happened, and that may make the string longer.
> But just returning "d" for (string-truncate-left "and" 1) isn't correct
> either.

Yes.  My main motivation for proposing to omit truncation (and prefixing
with "...") of too-short lines was for using string-truncate-left in a
loop over differently sized input strings, but of course that can be
handled by suitable code in the loop.

> I've now fixed the originally reported off-by-one error when shortening,
> and documented the quirks of the function in Emacs 29.

Thanks, the doc string makes sense to me now.

Steve Berman