Re: [bongo-devel] Re: Marks

[Daniel Brockman]

address@hidden (Daniel Jensen) writes:

> Daniel Brockman <address@hidden> writes:
>
>> address@hidden (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.

binjOuXuOrI0w.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 <address@hidden>