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:
>
>> address@hidden (Daniel Jensen) writes:
>>
>>> Daniel Brockman <address@hidden> writes:
>>>
>>>> Can't we just say `fuck it!' or `rock'n'roll!' or something
>>>> and bind <mouse-3> to a context menu?
>>
>> [For the record, I done did that a couple of weeks ago.]
>
> Yes, I haven't really tried it out. I don't care for it, but I'm not
> opposing it. I don't mind discussing the details.

Cool. :-)

>>>> I sometimes use the region-selecting/killing binding of
>>>> <mouse-3>, but I don't think anyone will miss it much in
>>>> Bongo buffers.
>
> By the way, this might be because it wasn't fully integrated.

Good point!  It's still a good idea to make it more integrated.
Looking at the code for `mouse-save-then-kill', I think we
would have to roll our own command, because it has code like

   (kill-new (buffer-substring (point) (mark t)) t).

>>> Preview-latex only does it on images, so it's not really a
>>> context menu.
>>
>> How is that not a context menu?  The context is the image.
>
> I meant that it's not a menu that changes depending on context. It's
> just a menu, not a consistent user interface. So I wouldn't call it a
> context menu. Well, that's my definition anyway.

Okay, I see what you mean.  That makes sense.

> I think you're halfway (or more) to a context menu in Bongo.
> There are different menus for header lines and track lines.
> So why not a menu for the areas that are not object lines?
> That could be the main mode menu, for example.

I like this idea (I hope that doesn't disappoint you).
I think it would be useful, and it makes a lot of sense.

We could designate some part of the buffer to the mark, save and
kill functionality (right now, the indentation space immediately
to the right of the left fringe still has that binding).

In addition, of course, we should have a customizable
setting for disabling the context menu altogether and for
changing its binding to the more conventional <C-mouse-3>.

>>> SLIME also has a menu on "presentations", those are printed
>>> representations of objects

I like that: presentation --- printed representation.

>>> that you can inspect or copy in the REPL.  But again,
>>> you get the standard `mouse-save-then-kill' on text.
>>
>> Well, aren't the "presentations" text?
>
> Sort of, kind of, yes, but no. This is a digression, really.

Cool, I love abstract digressions.

> The point of presentations is to present types of objects
> to the user, for direct manipulation.

Types of objects?  Do you mean "objects of various types"?

> You don't think of it as text, it is the very object
> right there.

I guess at least a printed representation of it. :-)

> So instead of having to use `*' and friends in the REPL
> (they are variables bound to recent values, in case you
> didn't know),

I didn't.  I've only used SLIME a few times.

> you click the presentation.

I see.  Kind of like how in Shell mode (and other comint
derivatives) you can <mouse-2> previous input to re-insert
it at the prompt?

> SLIME is of course limited to using only text for this, since it's
> nothing more than a glorified comint mode, but on the Lisp machines (and
> also in the Common Lisp Interface Manager, the heir to the Lisp machine
> GUI system) it was a general construct for programs to use and build
> user interfaces.

Hmm, that sounds pretty damn cool.  I want to read about it.

> Anyway. I'm wondering how you look at object lines in Bongo
> buffers. They are both text and presentations, in a way.
> (They could be more like presentations some day, if the
> track objects you've been talking about come to life.)

Yeah... well, they certainly are presentations --- opaque
(strictly speaking) representations of underlying "objects".

Compare Bongo track lines to lines in a Dired buffer.
Track lines are opaque, while Dired lines are transparent.
That's why something like `wdired' would not work in Bongo
without being clever about it.

(I'm not sure what `bongo-file-name-from-infoset' thinks it
might be able to do.)

The text on a Bongo track line does not say anything
conclusive whatsoever about the underlying object.

I think this is a very deep issue.  In many ways, it is what
separates Emacs from other environments, like GNOME.

In GNOME, everything is an opaque representation.
In Emacs, most things are transparent, direct.

I think one should aim for transparency, or, when that is
too limiting, at least try to make up for the missing
transparency by painting a rich (though opaque) image.

> This also concerns the mapping of Bongo to text editing
> ideas, as you mentioned. It's a little confusing, don't
> you think, like the duality of light?

Yes, it is quite confusing, and Bongo is not firmly on
either side of this transparency-opaqueness duality.

It gets a point for transparency because Bongo tracks _are_
their textual "representations".  (This is only possible
because "text" in Emacs may contain embedded data.)

That's why you can kill a Bongo track, yank it in any old
scratch buffer where you keep junk, and then later kill it
and yank it back in another Bongo buffer and it Just Works.

(This would still be true if we introduced "track objects",
because track lines would just contain references to them.)

This property is what I used to refer to as "buffer-oriented":
the fundamental data structure of Bongo is the buffer.

But then of course that point is undone by the fact that you
can't meaningfully edit the text of a Bongo track (the old
text will just be restored at some semi-unpredictable time).

So I suppose Bongo attempts to maintain the text editing
paradigm on a buffer level, but abandons it on a track level.

> Well, this is getting a little too abstract.

Thank you for the "digression", as you called it.

>> I guess we could put the context menus only on the icons.
>>
>> What do you think about that?
>
> I don't know. That sounds like a bad compromise. I think
> that if you really want the menu, it's a shame to hide it
> away like that.

I think you're right.  That is a bad compromise.  At least
it's a way out if in the future someone complains that they
want to be able to get to the context menu if they need it
but it annoys them to have it pop up all over the place.

To sum up, I think the `mouse-save-then-kill' <mouse-3>
binding is obscure even for normal text editing (who uses
the mouse anyway?), and a lot more obscure in Bongo.

I think people who use the mouse (including myself, rarely)
prefer being able to do lots of stuff that you regularly
want to do (play, pause, enqueue, etc., etc.,) using only
the mouse --- prefer that over being able to kill text.

We could even add a menu entry, "Select Region".

I think people who do use the mouse but dislike the Bongo
context menu (a minority, I believe) won't have any trouble
turning it off once they notice it's there.

So I think the menu should stay.


Thanks again for the reply, and best regards,

-- 
Daniel Brockman <address@hidden>