Re: [bongo-devel] Re: I want to make `f' and `b' move point

[Daniel Brockman]

address@hidden (Daniel Jensen) writes:

> Daniel Brockman <address@hidden> writes:
>
>> While we're at it, how about moving `l' [...]
>> Another key that's hanging very loose in my eyes is `g'. [...]
>> I also think I want to unbind `M', [...]
>
> I don't use these commands.

Okay.  I nuked `g' and `M'.

> I'm thinking `.' could be used for `bongo-recenter'.
> This is like in the calendar, where it is used to jump to
> today's date.

Good suggestion.  I don't remember why I wanted to move `l',
however, so I can't really motivate it anymore.  I guess I
felt I had to make up for wanting to grab `b' and `f'. :-)

Let's see... what else could we use `l' for?
Maybe something that one could think of as `last'.

We could bind it to a command that moved point to the
previously played track.  I suppose that could be useful ---
a sort of history ---, especially during random playback.

>> Finally, I want to move `d' to make room for a future
>> command that would do the opposite of `e' --- dequeue.
>
> I don't know what dequeue is supposed to do. Care to explain?

It's supposed to remove a track from the queue, which could
be either a playlist buffer or a playlist-internal queue.

One simple use case would be to undo an `e' command without
having to switch to the playlist buffer.

We don't have arbitrary-length playlist-internal queues yet,
but that's a natural extension of the `queued track' feature,
which by the way appears to have suffered severe bit rot ---
it is not on any key and has not been used for quite a while.

The fundamental difference between intra-playlist queues and
playlist buffers is only that the latter allows duplicates.

For intra-playlist queues, the plan is for `e' to enqueue,
or, if already enqueued, move forward in the queue, while
`d' would move backward, or, if already at the end, dequeue.

There is also `D' (supposed to be a counterpart of `E')
which would immediately dequeue a track.

I'm not sure what the semantics should be for playlist
buffers in more complex cases, but I think it would make
sense to parallel the intra-playlist semantics so that `d'
in a library buffer would find the bottommost copy of the
track in the playlist buffer and transpose it downwards ---
or remove it, if it was already at the end.  However, that
would make it asymmetrical with `e' in that `e' cannot move
existing playlist entries around.  We could let it do that.
Then `e e' would not (as now) enqueue two copies of a track,
but rather enqueue and then transpose upwards --- in effect
enqueuing at the next-to-last position.  That would mean we
would need another way to enqueue copies.  Perhaps `C-u e'.

Well, at least now you know what I'm talking about. :-)

You don't happen to have any thoughts about this?


-- 
Daniel Brockman <address@hidden>