bongo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bongo-devel] Context menu (was: I want to make `f' and `b' move point)


From: Daniel Brockman
Subject: [bongo-devel] Context menu (was: I want to make `f' and `b' move point)
Date: Thu, 24 May 2007 13:36:21 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.92 (gnu/linux)

address@hidden (Daniel Jensen) writes:

> Daniel Brockman <address@hidden> writes:
>
>> 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>.
>
> I think it's best to keep `mouse-save-then-kill' from
> clashing with the menu. That is, when menus are on mouse-3,
> only menus are on mouse-3.  That way we stay away from
> having special rules for areas in the buffer, rules that
> would at best be compromises.

OK.

> I believe what you wrote about mouse users and menu haters
> supports this.

I'm not even sure I believe in the existence of the alleged
menu-hating mouse users, any more than I believe in the
existence of keyboard users who hate keyboard shortcuts.

But I do believe in the existence of mouse users who hate
neither context menus nor `mouse-save-then-kill' (which is
why I suggested providing both features at the same time).

Anyway, just abandoning `mouse-save-then-kill' for now seems
by far the easiest and perhaps also the best solution.

> The C-mouse-3 idea is OK.

It'll be real easy to implement if we put the context menu
on the entire buffer, as you suggest.  I made that change.

>> 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?
>
> It is kind of like that, but that's only one aspect of it.
> Let me give you an example:
>
>     CL-USER> (defclass point ()
>                ((x :accessor point-x)
>                 (y :accessor point-y)))
>     #<STANDARD-CLASS POINT>
>     CL-USER> (make-instance 'point)
>     #<POINT {AB5C971}>
>
> The return values are presentations in the buffer. I can click mouse-2
> on them to copy to the input line, and use them like this:
>
>     CL-USER> (setf (point-x #<POINT {AB5C971}>) 12
>                    (point-y #<POINT {AB5C971}>) 34)
>
> But note that #<...> is not readable, SLIME does some magic to allow
> this. The presentation menu also has commands for inspecting and so on.

Ah, I see.  Very cool!

I understand more of what you mean now.

>>> 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.
>
> Here's an article about CLIM and user interface design. It starts
> talking about presentations somewhere along the middle:
>
>     http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/clim-intro.html
>

That was an interesting read, if a bit hard to digest.

> I had to snip your thoughts on the deep nature of stuff,
> because I don't have much to add. Good stuff!

Hah, thanks.

-- 
Daniel Brockman <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]