Text mode menu wishlist

Text mode menu wishlist

[Sacha Chua]

The EmacsWiki has a new node: http://www.emacswiki.org/cgi-bin/wiki.pl?TextMenu

---
We need a good replacement for tmm (f10) which does not confuse the
blind. A start is available as Lisp:textmenu.el. Read the
documentation for define-key and improve it.
---
Please define "confuse the blind." I need to know what people like or
don't like about tmm.el and textmenu.el. I have copious amounts of
free time and quite a great bit of interest in making this
work. Personal itches: changing keymaps and losing the ability to C-h
k.
--- (me)

I'd like to know people's thoughts on this. You can either add to the wiki,
post to emacs-devel or e-mail me directly, and I'll keep the wiki page updated. =)

-- 
Sacha Chua <sacha@free.net.ph> - 4 BS CS Ateneo geekette
interests: emacs, gnu/linux, wearables, teaching compsci

Re: Text mode menu wishlist

[Alex Schroeder]

Sacha Chua <sacha@free.net.ph> writes:

> I'd like to know people's thoughts on this. You can either add to
> the wiki, post to emacs-devel or e-mail me directly, and I'll keep
> the wiki page updated. =)

People like me would like a simple buffer where we can use up and down
and RET to select a menu entry.  This can be done in Lisp and works
for me.

Other people would like to see "real" menus in the console, but that
requires messing with the C code.  The basic stuff is already there in
the MSDOS port (which has "real" menus), all we need is to do is port
that to curses or something.  I think this would also work for the
blind which will probably use emacs -nw anyway.  But it would not be
enough for me if I wanted to use a buffer-based menu eventhough I am
running X.

Alex.

Re: Text mode menu wishlist

[Richard Stallman]

Could you possibly get textmenu.el and email me a copy?

Re: Text mode menu wishlist

[Sacha Chua]

Alex Schroeder <alex@emacswiki.org> writes:

> People like me would like a simple buffer where we can use up and down
> and RET to select a menu entry.  This can be done in Lisp and works
> for me.

tmm does that, doesn't it? Or, well, it uses the history mechanism,
and you can pageup to get to the completion buffer...

> Other people would like to see "real" menus in the console, but that
> requires messing with the C code.  The basic stuff is already there in

I can start studying ncurses and the Emacs C code if people feel that this is
important enough. =) 

> blind which will probably use emacs -nw anyway.  But it would not be
> enough for me if I wanted to use a buffer-based menu eventhough I am
> running X.

What would an ideal buffer-based menu be for you?  Simple buffer, up
and down and ret, tab, mouse clicks, ability to go up to the parent
menu.. what else? =)

-- 
Sacha Chua <sacha@free.net.ph> - 4 BS CS Ateneo geekette
interests: emacs, gnu/linux, wearables, teaching compsci

Re: Text mode menu wishlist

[Thien-Thi Nguyen]

Sacha Chua <sacha@free.net.ph> writes:

   I can start studying ncurses and the Emacs C code if people feel that
   this is important enough. =)

perhaps you can kill two birds w/ one stone by prototyping using
guile-ncurses, q.v.

thi

Re: Text mode menu wishlist

[Miles Bader]

Thien-Thi Nguyen <ttn@glug.org> writes:
>    I can start studying ncurses and the Emacs C code if people feel that
>    this is important enough. =)
> 
> perhaps you can kill two birds w/ one stone by prototyping using
> guile-ncurses, q.v.

Um, emacs doesn't use curses.

You probably want to do this at the emacs glyph-matrix level.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

(no subject)

[Thien-Thi Nguyen]

   From: Miles Bader <miles@lsi.nec.co.jp>
   Date: 10 Sep 2002 16:48:40 +0900

   Um, emacs doesn't use curses.

   You probably want to do this at the emacs glyph-matrix level.

sorry, i thought we were talking about text menus.
(however, note the weasle-word "prototyping". :-)

thi

Re: none

[Miles Bader]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:
>    Um, emacs doesn't use curses.
> 
>    You probably want to do this at the emacs glyph-matrix level.
> 
> sorry, i thought we were talking about text menus.

We were (or at least I was).

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: none

[Sacha Chua]

Miles Bader <miles@lsi.nec.co.jp> writes:

>>    Um, emacs doesn't use curses.
>>    You probably want to do this at the emacs glyph-matrix level.
>> sorry, i thought we were talking about text menus.
> We were (or at least I was).

I am definitely talking about text menus. =) I use emacspeak -nw often
(inside screen), and I rely on the keyboard a lot. Besides, how can I
use Emacs' funky mouse-friendly menus if I don't have graphical output
or an easy to use mouse? =)

Right now I'm studying textmenu and tmm, trying to figure out what
kind of a menu system I really want. I guess most people don't think
tmm is broken (it's actually quite nice), but I wonder if it can be
improved. I'll go into hermit mode now and experiment with ways to do
so. Thanks for the input, and feel free to send more suggestions! 

-- 
Sacha Chua <sacha@free.net.ph> - 4 BS CS Ateneo geekette
interests: emacs, gnu/linux, wearables, teaching compsci

Re: Text mode menu wishlist

[Alex Schroeder]

Sacha Chua <sacha@free.net.ph> writes:

>> People like me would like a simple buffer where we can use up and down
>> and RET to select a menu entry.  This can be done in Lisp and works
>> for me.
>
> tmm does that, doesn't it? Or, well, it uses the history mechanism,
> and you can pageup to get to the completion buffer...

I dunno wether it does.  I just tried it and indeed it seems to go
"up" in the menu.  But I find it confusing.  It was so confusing, in
fact, that I understood it only after you told me.  :)  Part of this
problem is perhaps the multi-column display, and the lack of a
"selection" in the buffer.  All the activity is in the minibuffer.

>> Other people would like to see "real" menus in the console, but that
>> requires messing with the C code.  The basic stuff is already there in
>
> I can start studying ncurses and the Emacs C code if people feel
> that this is important enough. =)

I think Mario Lang already has a bunch of mails talking about the
basics of this.  Perhaps he can give you some more information.

> What would an ideal buffer-based menu be for you?  Simple buffer, up
> and down and ret, ability to go up to the parent menu

Yes

> tab

Hm, how would that work, as "next"?  I would not care about that (but
I would expect there to be a textmenu-mode-map I could change).

> mouse clicks

Not really -- if I expected that, I could have used the real menu.

Alex.

Re: none

[Miles Bader]

On Tue, Sep 10, 2002 at 09:56:55PM +0800, Sacha Chua wrote:
> Right now I'm studying textmenu and tmm, trying to figure out what
> kind of a menu system I really want. I guess most people don't think
> tmm is broken (it's actually quite nice), but I wonder if it can be
> improved.

I think tmm is `broken' too, because:

(1) It operates differently from other menus so it's bound to confuse
    beginners.

(2) Even once I got used to it a bit, I still found it very awkward to use:

    (a) Moving between menus and sub-menus (it just replaces the contents of
    	the `menu buffer') is way too heavy-weight. A typical drop-down menu
    	implementation allows you to quickly scan through submenus seeing
    	what's there, while also preserving all the `parent context' for you
    	to see.

    (b) The arrangement of menu items in the buffer seems often hard to read
        quickly.

    (c) I find the way the user-input (in the minibuffer) works annoying.  I
	don't really like using completion when choosing from a small set of
	displayed items (because doing so requires me to stop and think about
	which key to type corresponds to which displayed), I'd rather just
	select directly from the list.  You can scroll through the list in
	the minibuffer using direction keys, but the `disconnected' nature of
	it makes this awkward; it would be _much_ better to just manipulate a
	cursor in the displayed list directly (you can do this sort of by
	switching to the menu-window, but (1) that's an irritating extra step
	you have to take, and (2) moving between menu-items once you're there
	is still slow and clumsy [e.g., the huge initial comment that has to
	be skipped, the double-column arrangement of items]

    [I imagine that if you're using emacs-speak, BTW, you might disagree about
    some of this]

(3) It's ugly as hell.   Bleah.

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: none

[Sacha Chua]

Miles Bader <miles@gnu.org> writes:

>     (a) Moving between menus and sub-menus (it just replaces the contents of
>     	the `menu buffer') is way too heavy-weight. A typical drop-down menu
>     	implementation allows you to quickly scan through submenus seeing

Do you think it might be nice to have trees or outlines for menus,
like the way customize-browse does it? That seems like a fairly good
way of mimicking drop-down menus. Of course, there's something to be
said about native menus, but I think that native menus have been
discussed on this list before and there's probably a good reason why
we're still not using them.

> 	select directly from the list.  You can scroll through the list in
> 	the minibuffer using direction keys, but the `disconnected' nature of

tmm allows me to cycle through menu items in the minibuffer by
pressing the up and down arrow keys. This seems to make sense, and
it's actually quite usable with Emacspeak. I still don't like how
accelerators change if something gets added to the menu, and the fact
that there seems to be no easy way to go back to the previous menu,
but it's actually more usable than I thought.

It might be nice to see ido-like functionality in the menu, though. =)
That would be, like, fun!

-- 
Sacha Chua <sacha@free.net.ph> - 4 BS CS Ateneo geekette
interests: emacs, gnu/linux, wearables, teaching compsci

Re: none

[Richard Stallman]

    Of course, there's something to be
    said about native menus, but I think that native menus have been
    discussed on this list before and there's probably a good reason why
    we're still not using them.

If "native menus" means displaying something on the tty that looks
like a pull-down menu and letting the user move through it,
the reason we are not using them is that nobody has implemented them.
We would definitely like to switch to them, but it takes work,
so the question is who wants to do the work.