[EMAIL PROTECTED] (Daniel Jensen) writes: > Daniel Brockman <[EMAIL PROTECTED]> writes: > >>> The attached solution looks OK to me. Could it cause problems? >> >> I believe it could cause a slight problem since it assumes >> that `bongo-update-header-line-string' is only called in a >> few controlled situations. This assumption seems bad. > > Is it a bad assumption in practice? Will it ever happen in normal use?
I don't think so. But it would be really counter-intuitive if `bongo-update-header-line-string' could only be called in special situations. I think. :-) > Anyway, I'm looking at your code. I can't get it to work, > maybe I'm doing something wrong, but it /looks/ good! Hm. Now I can't get it to work either. I remember what happened. First it didn't work, even though it _should_ have worked. Then suddenly it started working. But now it doesn't work again. I'll play with it a bit and see if I figure out what's wrong. > I was thinking kind of in the same way. My idea was that it would > generally be useful to know whether a stop is between tracks. I agree. That may be useful. > It could be as simple as a variable that is bound non-nil > in certain functions (like `bongo-play-next'). I don't > have an example of when this would be useful, though, > other than with the header line updates. What do you think? So it would be as simple as renaming the variable `bongo-defer-status-indicator-updates' to something more generic? Something like `bongo-switching-track'? I guess the macro could be called `bongo-switch-track'. > Back to your patch. I think that you may need to use > `with-deferred-bongo-status-indicator-updates' in more > places, like `bongo-replay-current'. You're right. -- Daniel Brockman <[EMAIL PROTECTED]> _______________________________________________ bongo-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bongo-devel
