Re: [bongo-devel] Re: Bongo wishlist #9: make `d' work on header lines

[Daniel Brockman]

address@hidden (Daniel Jensen) writes:

> Romain Francoise <address@hidden> writes:
>
>> This is item #9: I would like `d' to take me to the
>> corresponding directory when used on a header line.
>> Right now it just complains that nil is not a string,
>> which isn't very helpful.
>
> How would you like Bongo to find the right directory? The easy way to
> implement this is to forward a few lines to the nearest track and use
> that for finding the directory. But that is not always the right one.

As a matter of fact, it is (assuming that the next track is
actually indented).  Header lines are determined completely
by the tracks below them.  Empty sections carry no
information whatsoever.

It can be argued whether this is good or bad (I'm not sure
what I think myself --- I'm leaning towards bad), but it is
how sections in Bongo currently work.

Header lines are rather ethereal in Bongo --- they come and
go as necessary.  Indeed, some commands insert a bunch of
header lines in case they are needed and let the redundant
ones disappear on their own.

Again, it can be argued whether this is good or bad (and I'm
leaning towards bad again).

If we want to think about changing this, we have to think
about semantics and what behavior we would like to have.

For example, what should happen if you insert a foreign
track into the middle of a section?  Should the foreign
track become part of the section?  Should the section be
chopped in two?  Should it be spliced into its parent?
Should the new track be inserted _before_ the section?

With the current behavior, it'll be chopped in two.

It would be interesting if the foreign track would become
part of the section.  If sections could contain arbitrary
groups of tracks (and sections), then you could create a
section to hold, for example, your favorite songs.

Is this the direction in which we want to go?  Turn the
control of sectioning over to the user.

I haven't thought through what changes this would require,
but intuitively I'd say it might very well simplify the code,
even though the required changes would likely be extensive.

I seem to be convincing myself with this little essay.
Is it convincing you?

-- 
Daniel Brockman <address@hidden>