[EMAIL PROTECTED] (Daniel Jensen) writes: > Daniel Brockman <[EMAIL PROTECTED]> writes: > >> [EMAIL PROTECTED] (Daniel Jensen) writes: >> >>> I don't think it is a good idea to mix unmarking with a stack growing >>> behind the scenes, that's messy. Better to let the user manage this >>> stack separately. How about `* k', `* y' and `* w', kind of like in >>> Gnus? That is, if we want the stack after all. >> >> But what about things like `e'? If that doesn't push the >> set to the stack before unmarking, I think the usefulness of >> the mark stack is reduced significantly. > > How is usefulness of the stack reduced? This is an honest question, > because I don't understand the meaning of what you're saying. If > anything, the usefulness of the stack would increase in this case?
You're right. The usefulness of the mark stack would increase. But the usefulness of the whole idea of letting the `e' command unmark all tracks would, in my opinion, decrease. That is, I think `* k e * y' is too inconvenient, not only because it is long, but because it requires you to remember to type `* k' before `e'. Sorry I was unclear. > I suppose this could be a customizable feature, to use the stack for > automatically saving marks, but I really don't like it. I'd rather > have a separate variable for automatically saved marks in that case. I don't really like it either. >> The `* *' command toggles between a set of marks and the >> empty set of marks. > > If I understand you correctly; this is like without the stack, > only with a handy key? Yes, except that without it (and without the stack), there is no key at all (handy or no). > Sure, I think that complements the original > suggestion (`U' and `C-u U') well. What was the original suggestion? That `C-u U' undo the last `U'? >>> Invert it is, then. If we go with the stack commands, it is also >>> consistent with that in the Gnus-wannabe way. >> >> I don't know why, but I kind of like monkeying after Gnus. >> Everyone knows Gnus is cool. You know. Right? > > Hey, it makes sense to follow the cool kids. And Bongo is > pretty cool already, don't you think? It's not water-cooler cool yet. Nobody is talking about it. It has its early adopters, and they know that it's pretty cool, but I don't think there is much of a buzz yet. At the rate Bongo is improving, however, eventual world domination appears inevitable. :-) >> Note: This still has not been implemented. We should probably >> implement it or file a feature request in the tracker. > > Does it have to be anything fancier than this? > > (defun bongo-invert-marks () > "Mark unmarked tracks, and unmark marked tracks in the buffer." > (interactive) > (save-excursion > (goto-char (point-min)) > (while (not (eobp)) > (if (bongo-marked-track-line-p) > (bongo-unmark-line) > (when (bongo-track-line-p) > (bongo-mark-line))) > (forward-line 1)))) No. At first sight, I thought that would be a little inefficient, since `bongo-unmark-line' will perform a linear search for each marked track. (It won't matter if the tracks are marked in order, but what if they are reversed?) However, I couldn't see any performance improvement when using this function, which avoids the repeated linear search.
binV9sgjZqI53.bin
Description: application/emacs-lisp
Maybe I'm confused? By the way, what do you think of using the term `marking' to refer to a set of marks? Then that function would be called `bongo-invert-marking'. -- Daniel Brockman <[EMAIL PROTECTED]>
_______________________________________________ bongo-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bongo-devel
