Re: [bongo-devel] Re: Marks

[Daniel Brockman]

First of all, I apologize for the long delay.  I have been
chipping at this for some time, and I believe the sculpture
is finally starting to show.  I think we can merge this soon.

Daniel Jensen <address@hidden> writes:

> Daniel Brockman <address@hidden> writes:
>
>> We could bind `* RET' to `bongo-play-marked', but it would
>> be nice to have a key that always played the Right Thing.
>> For example, there's no way to play an album from library.
>
> I have no idea ... How about `C-c RET' or `!'? Nah, I dunno.

I like `C-c RET'.  Good idea.

>>> I considered using text properties from the start instead,
>>> but I was attached to the idea that the user could mark
>>> tracks in a certain order.  Also, remarking a track would
>>> pop the marker to the front of the list.
>>
>> Hmm... do you have a use case for that?  It's an interesting idea,
>> but if it isn't useful it will probably just be confusing.
>
> This is a feature that, in my opinion, is both useful and
> nonintrusive. I don't see how it could be confusing.  In the common use
> cases, marking with `% m' and friends, order is preserved as expected.
> But when you mark tracks in an explicit order, it follows what you do.

Okay, I'm convinced --- especially since _not_ implementing
the feature will almost be more difficult than _doing_ so.

>>> Also, remarking a track would pop the marker to the
>>> front of the list.

This part, however, is not trivially easy to implement.
Undoing such a change should restore the list of marks to
its original state, so we have to save the origial position
of the marker and store it in the undo list.

That sounded a lot easier than I imagined it would, so I
suppose we'll just implement it then. :-)

(I haven't yet, though.)

> You use Gnus, so you can try its marking commands. I think most of
> them operate like this. For example, to reply to several messages,
> mark them in the order you want them to appear in the reply.

Heh, I have now finally figured out how to do this in Gnus.
Do you mean, for example, `# # M-& R' (i.e., process-mark two
articles, force `process/prefix convention', and then reply)?
That sort of works, but it creates two reply buffers ---
one buffer contains one quoted message; the other, both.

Weird, but beside the point.  Well, at least now I know how
to mark stuff in Gnus. :-)

> I thought I had implemented this in my draft for Bongo, but I guess it
> was just a thought. It's only a line of code, actually.

I have added this feature.

I'm starting to like the way marking looks and feels now.
Please try the patch.  I'm going to keep it here for a while
and let it mature before I migrate it to the main repository:

       <http://www.brockman.se/software/bongo-marks/>

It's bound to introduce quite a few bugs.  Maybe even bugs
unrelated to marking.  (It might fix a few such bugs, too.)

I have attempted to make sure undo works correctly with
marking and unmarking commands, which is not trivial due to
the need to keep `bongo-marked-track-line-markers' updated.
There are likely still some bugs related to this.

I also switched around the proposed priority for high-level
user commands like `bongo-kill', which now prefers to kill N
objects (if N is given), then the region (if active), then
the marked tracks (if any), and finally the object at point.

The order I originally proposed was to operate on the marked
tracks, if any, or else the region, if active, or else the
next N objects, if N was given, or else the object at point.
(The new order is almost the exact opposite of this, and it
is better for several reasons.)

There is one incompatible change.  The function `bongo-play',
which has been an obsolete alias for `bongo-play-file' for
quite some time, has a new definition.  It is now the command
bound to `C-c RET', which we have discussed in this thread.

(Well, _at least_ one incompatible change --- there may be
others that I am forgetting to mention.  Oh, I removed `w',
as we previosly agreed.)

Discussion about the design of this thing is very welcome,
as of course are bug reports.  I want to migrate this ASAP,
but I want it to be really good before I do so.

Again, mad props to Daniel Jensen for prototyping the code.


Best regards,

-- 
Daniel Brockman <address@hidden>