[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 15 Aug 2014 12:18:36 -0300
The following is a simpler and more correct patch that also lets the
user (final user or major mode developer) control whether the submenus
are sorted or kept on top. The guiding idea is that there is two major
ways to offer an imenu, according to the mode:
1) Some modes show a hierarchy of language objects. For example:
python-mode will show class/method, function/nested function, etc.
relationships; org-mode will show section/subsection/subsubsection/...
hierarchies. In these cases keeping the submenus on top is not
adequate since it creates an artificial split of the list.
2) Some modes show top level submenus with fixed categories
(Functions, Classes, Variables, etc). These modes will presumably want
to keep the submenus on top and sorted in the order they were given.
3) Other modes would not fit either (1) or (2). Then, there is always
the possibility of turning off sorting and provide the menu structure
> (defcustom imenu-sort-submenus nil
> "Non-nil means Imenu should sort submenus also (using imenu-sort-function)."
> :type 'boolean
> :group 'imenu)
< (when (imenu--subalist-p item)
> (when (and (not imenu-sort-submenus)
> (imenu--subalist-p item))
On Thu, Aug 14, 2014 at 8:56 PM, Carlos Pita <address@hidden> wrote:
> Besides that, I see no point in the keep-at-top behaviour of
> imenu--split-menu, which pushes every submenu to the top of its parent
> menu. The user is looking for a name in a list sorted according to
> some required criterion. Splitting this list in two sorted lists in
> virtue of a totally different criterion will only bring confusion.
> It's ok to make this the default behaviour, in case the user isn't
> interested in any particular ordering (that is, imenu-sort-function is
> nil). But if a particular ordering is required, then it should be
> honoured. Or, at least, an option should be provided to turn off
> If you agree I will gladly provide a patch.