emacs-devel
[Top][All Lists]
Advanced

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

Re: more on anything.el inclusion


From: Thierry Volpiatto
Subject: Re: more on anything.el inclusion
Date: Fri, 09 Jul 2010 16:46:04 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

Hi Ted, sorry for late reply.

Ted Zlatanov <address@hidden> writes:

> On Thu, 01 Jul 2010 16:15:38 +0200 Thierry Volpiatto <address@hidden> wrote: 
>
> TV> Ted Zlatanov <address@hidden> writes:
>
>>> OK.  Thanks for explaining.  So from the user's viewpoint, it should be
>>> enough to autoload all the front-end anything-* functions (from
>>> anything.el ideally, so users don't have to know about
>>> anything-config.el as you had it in your autoload example).  Can you
>>> make the necessary changes?  Or will that require major work?
>
> TV> Maybe a function that autoload all as suggested by Dan?
> TV> Would not need major work, but need to discuss it with Rubikitch.
>
> Wonderful, thank you.

I don't think a function is neccessary as anything don't modify other
things in emacs.
There is now an anything-command-map that can be autoloaded at emacs
startup.

>>> Is there a list of the standard front-end functions (a subset of the
>>> autoloads below) that should always be exposed (through keyboard
>>> mappings, possibly in a menu) to Emacs users?  The xfonts and file
>>> selection ones should be in that list for sure.
>
> TV> In which menu should we add anything commands?
> TV> I mean this kind of menu:
>
> TV> (easy-menu-define nil global-map
> TV>   "`anything' menu"
> TV>   `("Anything commands"
> TV>     ["Find files" anything-find-files t]
> TV>     ["Show xfonts" anything-xfonts t]))
>
> TV> Here it is in global menu, but maybe that should go in tools or don't
> TV> know where.(i never used menus in emacs, toolbar is disabled here).
>
> The menu location is not so important.  The point is to make a list of
> "important" front-end functions that users should really know about.
> The keyboard mappings are IMO much more important because anything-*
> functions tend to be important while editing, not as an interactive
> exploration (which menus do well).  So when we have the list we can
> propose a list of mappings and depending on whether the list has 10 or
> 100 entries we can anticipate the mapping complexity.

The anything-command-map is now prefixed at '<f5> a', what can be
discussed.
If user like a command and want to replace it with standard
emacs command, he can bind it to global-map 
(e.g anything-find-files <=> find-file ==> C-x C-f)

There is also a menu showing important commands (again this list can be
discussed) that appear when autoloading anything-command-map.

> On Thu, 1 Jul 2010 16:48:48 +0200 Lennart Borgman <address@hidden> wrote: 
>
> LB> On Thu, Jul 1, 2010 at 4:15 PM, Thierry Volpiatto
> LB> <address@hidden> wrote:
>>> 
>>> In which menu should we add anything commands?
>
> LB> I have suggested long ago to create a top level menu for all minor
> LB> modes. That would make decisions like this easier.
>
> Exposing functionality creates UI complexity; Emacs is already really
> complex both in UI terms and in scope.  So I don't think adding a
> general menu like that (have you seen how many minor modes Emacs has?)
> would benefit the users.
>
> OTOH it would be very nifty if there was a anything-minor-mode function
> that let you browse (with some help text) and activate minor modes.
>
> Ted
>
>
>

-- 
Thierry Volpiatto
Gpg key: http://pgp.mit.edu/




reply via email to

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