[Top][All Lists]

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

Re: CEDET discoverability

From: Eric M. Ludlam
Subject: Re: CEDET discoverability
Date: Wed, 14 Jul 2010 20:31:54 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre

On 07/14/2010 02:48 PM, David Kastrup wrote:
So the only actually_existing_  keybindings we find in the
Analyzer/Smart Jump subnode tells us about keybindings that don't
actually use the analyzer.

>  Do you have something specific in mind about what is missing?
There is so much in there that does not seem applicable without
reverting to Elisp programming that the few things that would likely
_be_  relevant are hard to find among the rest.

The manual needs to funnel out everything that is not at user interface

David's point is much like what I had mentioned in the past. CEDET is a big collection of little tools and commands. As a 3rd party package, many items are just provided to be bound on the keyboard where the user might want them. Others are specified as minor modes which need to be turned on, and are on C-c <punctuation> or may not have keybindings. ie - they just display decorations or operate on a timer.

I think it would behoove the Emacs community to think about the kinds of features you (or users) want, and where they go from an Emacs UI perspective. The emacs integration support of CEDET can then choose to bind these items to different keys. Should some of the items go into the global-keymap as base supported tools? Do others stay in minor-mode maps on C-c <punctuation?>

For example, in CEDET/CVS there is cedet-m3.el which binds mouse-3 to create a context-sensitive menu of options out of the CEDET suite that would be appropriate to use at that specific location clicked. What key could it also be bound to?

Of the items listed in the manual that you didn't feel like binding to keys, where should they be bound to to provide the desired UI?


reply via email to

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