Re: [CEDET-devel] Replacement for which-func advise
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2010-04-06 19:56:33
|
Hi, 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. Good news. >> 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: +(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 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 > cache? > (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 > think? 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. Thanks! Eric Eric |