bug#13143: 24.2; mpc.el: mpc-songs-refresh: Args out of range

["David Cadé" <codename68@gmail.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2569 bytes --]

Hello,

On Tue, 11 Dec 2012, Stefan Monnier wrote:

>> I first launched the mpc interface by typing M-x mpc. I did not touch
>> any configuration parameter for this mode.
>> I then chose an album in the Albums | Playlists window by typing RET on
>> it.  This triggered the following error:
>> mpc-songs-refresh: Args out of range: "..." 0, -21
>
> I can't reproduce this here; I don't have any albums with japanese
> characters, but I when I tried with albums with non-ASCII chars, it
> worked fine.
>
> Could you select "Options => Enter debugger on error" and reproduce this bug?
> Hopefully this will give us a backtrace that gives us some clue of
> what's going on.

Here you go:

Debugger entered--Lisp error: (args-out-of-range "魔法少女リリカルなのは　サウンドステージ01 第2.5話「ドキ！水着でプールで大ピンチなの」" 0 -21)
   mpc-format("%2{Disc--}%3{Track} %-5{Time} %25{Title} %20{Album} %20{Artist} %10{Date}" ((file . "田村ゆかり・他 - 魔法少女リリカルなのは　サウンドステージ01 第2.5話「ドキ！水着でプールで大ピンチなの」/01 - 「なのは魔法の練習中」.flac") (Last-Modified . "2010-10-26T01:22:26Z") (Time . "295") (Title . "「なのは魔法の練習中」") (Artist . "田村ゆかり・他") (Album . "魔法少女リリカルなのは　サウンドステージ01 第2.5話「ドキ！水着でプールで大ピンチなの」") (Genre . "Anime") (Track . "1") (Date . "2004-01-01T00:00:00")))
   mpc-songs-refresh()
   mpc-selection-refresh()
   mpc-select(13)
   call-interactively(mpc-select nil nil)

>> Another maybe related bug: when there are japanese characters in the
>> album name and it is too long to be displayed without ellipsis (…), the
>> longer the less characters are present before the ellipsis.
>
> You mean that if the real title is longer, then it gets
> truncated earlier?  As in "toto" would be truncated to "tot…" but
> "wonderful" would be truncated to just "w…" rather than "won…"?

Exactly.

> Hmm... that might be a clue, indeed, tho it might be
> completely unrelated.

My take on the bug:
I looked at the code of this function, and from what I can gather, the bug 
seems to be in:
(substring text 0 (- size postwidth textwidth 1))
postwidth and textwidth are widths obtained with string-width, that is to 
say in number of columns, and may not have any relation with the number of 
characters present in the string text.
This seems wrong to me. It seems to me that truncate-string-to-width seems 
to be the function one would want to use in this case.

Greetings,

-- 
David