> >> You may want to consider a "fast" answer, and a "detailed" answer
> >> solution.  The immediate feedback variant would use the 'fast'
> >> answer, and an idle mode could then enable a better answer later.
> >
> > For me, the feedback from the idle service seems fast enough, but I
> > only did very limited testing.
> >
> > Please let me know whether the attached patch can be applied
> > (provided I add docstrings and clean up, of course).
> Having more modes is always good.  I'm not fond of the 'breadcrumb'
> name though. It doesn't tell me what it does. Not that stickyfunc is much
> better, of course. In the case of this mode, it seems like it would
> be the end-all variant of "show me the tag under the cursor" feature.=20
> Giving it a clean name like 'show-current-tag-name' or something
> similar seems important for discover-ability.

I think it is the canonical name of the user-interface design pattern
(see http://en.wikipedia.org/wiki/Breadcrumb_(navigation)). It doesn't
have to be breadcrumbs for me thought. After all, names in Emacs are
expected to be non-standard, aren't they? ;)

How about show-path-to-current-tag, show-nesting-of-current-tag or

> Also, this bit:
> +(defcustom semantic-idle-breadcrumbs-format-tag-function
> +  #'semantic-format-tag-abbreviate
> +  "*"
> +  :group 'semantic
> +  :type  'function)
> There is a special custom type for formatting tag functions.  Here is
> an example:
> (defcustom semantic-idle-summary-function
>    'semantic-format-tag-summarize-with-file
>    "Function to call when displaying tag information during idle time.
> This function should take a single argument, a Semantic tag, and
> return a string to display.
> Some useful functions are found in `semantic-format-tag-functions'."
>    :group 'semantic
>    :type semantic-format-tag-custom-list)


> There is also a header line prefix.  The stickyfunc code has a way to=20
> calculate the prefix that might work for you if the X: is just a
> spacer, as opposed to meaning something.

I used the value of the stickyfunc custom option as default. This is not
optimal since it depends on the evaluation order, but I didn't want to
just copy the code.

> Other than that, things look pretty good to me after a quick read.

So is it OK to commit this version?