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

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

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


From: David Cadé
Subject: bug#13143: 24.2; mpc.el: mpc-songs-refresh: Args out of range
Date: Wed, 12 Dec 2012 13:55:50 +0100 (CET)
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

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

reply via email to

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