On 03/31/2010 09:37 PM, Jan Moringen wrote:
[ ... ]
>> Making a new idle service is pretty easy, as you can use
>> define-semantic-idle-service to define your feature. There are plenty
>> of examples in semantic-idle.el with semantic-idle-tag-highlight being
>> pretty simple.
> I made semantic-breadcrumbs-minor-mode into an idle service and it
> worked like a charm. The sluggishness produced by the post-command-hook
> -version is (as expected) gone.
>> 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.
Giving it a clean name like 'show-current-tag-name' or something similar
seems important for discover-ability.
Also, this bit:
+ :group 'semantic
+ :type 'function)
There is a special custom type for formatting tag functions. Here is an
"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'."
There is also a header line prefix. The stickyfunc code has a way to
calculate the prefix that might work for you if the X: is just a spacer,
as opposed to meaning something.
Other than that, things look pretty good to me after a quick read.
> Btw, I noticed a possible inconsistency in the scope analysis code. Some
> languages, like Java or Common Lisp for example, have a non-lexical
> package/namespace declaration construct (Python is even more difficult,
> because containing directories and their contents matter):
> package foo.bar;
> in Java and
> (in-package :foo)
> in Common Lisp. These do not show up in the parents slots of the scope
> object. In my opinion, it would be useful to have them there. Or should
> the scope be understood to strictly describe the lexical structure of
> the code?
These languages probably need to create an override function for
semantic-ctxt-imported-packages. The one in semantic-c.el shows it
getting a bunch of using statements.
For going the opposite way (applying a namespace like construct to
declarations), adding a new semantic-ctxt-* type function may be needed.
Alternately, the parser could identify that statement, then apply a
:parent attribute to the tags created afterward. That would then feed
through the scope calculator ok.
> For the recently discussed calculation of qualified names, I did the
> following for Java:
> (define-mode-local-override semantic-tag-qualified-name
> java-mode (tag scope)
> "Get local variable declarations from the current context."
> (let* ((package (car (semantic-find-tags-by-class
> 'package (oref scope table)))) ;; TODO add this stuff to the scope
> (parents (oref scope parents))
> (parent-names (mapcar #'semantic-tag-name parents)))
> When writing this, I obviously felt that adding the package tag to the
> list of parents should be part of the scope calculation. This would make
> things like the breadcrumbs display work "correctly", too. What do you
This solution is similar to what we'd get if we added a new
semantic-ctxt function that would, in Java's case, just be the
find-tags-by-class code. We would then need to find all the necessary
locations to apply it. That might not be too bad, since those locations
may already be looking for :parent on function tags and the like.
If it is a very common language feature, then we would probably want to
use a semantic-ctxt feature to keep parsers simple. If it is uncommon,
then we probably can stick it into the parser as a hack.