all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#56685: OBOE in string-truncate-left?
@ 2022-07-21 22:10 Stefan Kangas
  2022-07-22 10:26 ` Stephen Berman
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Kangas @ 2022-07-21 22:10 UTC (permalink / raw)
  To: 56685

Try evaluating:

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

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#56685: OBOE in string-truncate-left?
  2022-07-21 22:10 bug#56685: OBOE in string-truncate-left? Stefan Kangas
@ 2022-07-22 10:26 ` Stephen Berman
  2022-07-22 11:31   ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Berman @ 2022-07-22 10:26 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 56685

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

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* bug#56685: OBOE in string-truncate-left?
  2022-07-22 10:26 ` Stephen Berman
@ 2022-07-22 11:31   ` Eli Zaretskii
  2022-07-22 12:35     ` Stephen Berman
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2022-07-22 11:31 UTC (permalink / raw)
  To: Stephen Berman; +Cc: stefan, 56685

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#56685: OBOE in string-truncate-left?
  2022-07-22 11:31   ` Eli Zaretskii
@ 2022-07-22 12:35     ` Stephen Berman
  2022-07-22 13:33       ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Berman @ 2022-07-22 12:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 56685

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#56685: OBOE in string-truncate-left?
  2022-07-22 12:35     ` Stephen Berman
@ 2022-07-22 13:33       ` Eli Zaretskii
  2022-07-22 15:23         ` Stephen Berman
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2022-07-22 13:33 UTC (permalink / raw)
  To: Stephen Berman; +Cc: stefan, 56685

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#56685: OBOE in string-truncate-left?
  2022-07-22 13:33       ` Eli Zaretskii
@ 2022-07-22 15:23         ` Stephen Berman
  2022-07-23  6:58           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Berman @ 2022-07-22 15:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: stefan, 56685

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#56685: OBOE in string-truncate-left?
  2022-07-22 15:23         ` Stephen Berman
@ 2022-07-23  6:58           ` Lars Ingebrigtsen
  2022-07-23  8:51             ` Stephen Berman
  0 siblings, 1 reply; 8+ messages in thread
From: Lars Ingebrigtsen @ 2022-07-23  6:58 UTC (permalink / raw)
  To: Stephen Berman; +Cc: Eli Zaretskii, stefan, 56685

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.






^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#56685: OBOE in string-truncate-left?
  2022-07-23  6:58           ` Lars Ingebrigtsen
@ 2022-07-23  8:51             ` Stephen Berman
  0 siblings, 0 replies; 8+ messages in thread
From: Stephen Berman @ 2022-07-23  8:51 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, stefan, 56685

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-07-23  8:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-21 22:10 bug#56685: OBOE in string-truncate-left? Stefan Kangas
2022-07-22 10:26 ` Stephen Berman
2022-07-22 11:31   ` Eli Zaretskii
2022-07-22 12:35     ` Stephen Berman
2022-07-22 13:33       ` Eli Zaretskii
2022-07-22 15:23         ` Stephen Berman
2022-07-23  6:58           ` Lars Ingebrigtsen
2022-07-23  8:51             ` Stephen Berman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.