Thread: Re: [CEDET-devel] semantic-decorate-mode.el
Brought to you by:
zappo
From: David P. <dav...@wa...> - 2004-06-14 09:17:56
|
Hi Eric, > I've added `semantic-decorate-mode.el' to the CVS repository. This > represents a replacement for `semantic-highlight-by-attribute-mode' > and `semantic-show-tag-boundaries-mode'. It encapsulates what I > learned making those modes as a set of macros. [...] This is a good idea to regroup decoration modes in one library. Following is a small patch that fixes two bad references to semantic-util-modes. If you like I can commit it. David 2004-06-14 David Ponce <da...@dp...> * cedet/semantic/semantic-decorate-mode.el (global-semantic-decoration-mode): Fix :require. Index: semantic-decorate-mode.el =================================================================== RCS file: /cvsroot/cedet/cedet/semantic/semantic-decorate-mode.el,v retrieving revision 1.1 diff -c -r1.1 semantic-decorate-mode.el *** semantic-decorate-mode.el 13 Jun 2004 02:50:41 -0000 1.1 --- semantic-decorate-mode.el 14 Jun 2004 09:16:32 -0000 *************** *** 1,4 **** ! ;;; semantic-util-modes.el --- Semantic minor modes ;;; Copyright (C) 2000, 2001, 2002, 2003, 2004 Eric M. Ludlam --- 1,4 ---- ! ;;; semantic-decorate-mode.el --- Minor mode for decorating tags ;;; Copyright (C) 2000, 2001, 2002, 2003, 2004 Eric M. Ludlam *************** *** 76,82 **** `semantic-decoration-secondary-alist' will be enabled." :group 'semantic :type 'boolean ! :require 'semantic-util-modes :initialize 'custom-initialize-default :set (lambda (sym val) (global-semantic-decoration-mode (if val 1 -1)))) --- 76,82 ---- `semantic-decoration-secondary-alist' will be enabled." :group 'semantic :type 'boolean ! :require 'semantic-decorate-mode :initialize 'custom-initialize-default :set (lambda (sym val) (global-semantic-decoration-mode (if val 1 -1)))) |
From: David P. <dav...@wa...> - 2004-06-14 15:08:05
|
> Yes, a good idea. Thanks OK. I committed the change. WDYT of the following patch that renames the functions `semantic-dso-after-full-reparse-hook' and `semantic-decorate-reparse-hook' to respectively `semantic-decorate-tags-full' and `semantic-decorate-tags'. I find those new names more consistent with what the functions do, and it is more evident that they are not hook-only functions. David Index: semantic-decorate-mode.el =================================================================== RCS file: /cvsroot/cedet/cedet/semantic/semantic-decorate-mode.el,v retrieving revision 1.2 diff -c -r1.2 semantic-decorate-mode.el *** semantic-decorate-mode.el 14 Jun 2004 12:15:36 -0000 1.2 --- semantic-decorate-mode.el 14 Jun 2004 14:53:27 -0000 *************** *** 107,117 **** ;; Add hooks (semantic-make-local-hook 'semantic-after-partial-cache-change-hook) (add-hook 'semantic-after-partial-cache-change-hook ! 'semantic-decorate-reparse-hook nil t) (semantic-make-local-hook 'semantic-after-toplevel-cache-change-hook) (add-hook 'semantic-after-toplevel-cache-change-hook ! 'semantic-dso-after-full-reparse-hook nil t) ! (semantic-decorate-reparse-hook (semantic-fetch-tags)) ) ;; Cleanup tag boundaries highlighting (semantic-dso-clear (semantic-fetch-tags)) --- 107,117 ---- ;; Add hooks (semantic-make-local-hook 'semantic-after-partial-cache-change-hook) (add-hook 'semantic-after-partial-cache-change-hook ! 'semantic-decorate-tags nil t) (semantic-make-local-hook 'semantic-after-toplevel-cache-change-hook) (add-hook 'semantic-after-toplevel-cache-change-hook ! 'semantic-decorate-tags-full nil t) ! (semantic-decorate-tags (semantic-fetch-tags)) ) ;; Cleanup tag boundaries highlighting (semantic-dso-clear (semantic-fetch-tags)) *************** *** 119,127 **** (semantic-dso-flush-rogue-overlays) ;; Remove hooks (remove-hook 'semantic-after-partial-cache-change-hook ! 'semantic-decorate-reparse-hook t) (remove-hook 'semantic-after-toplevel-cache-change-hook ! 'semantic-dso-after-full-reparse-hook t) ) semantic-decoration-mode) --- 119,127 ---- (semantic-dso-flush-rogue-overlays) ;; Remove hooks (remove-hook 'semantic-after-partial-cache-change-hook ! 'semantic-decorate-tags t) (remove-hook 'semantic-after-toplevel-cache-change-hook ! 'semantic-decorate-tags-full t) ) semantic-decoration-mode) *************** *** 181,199 **** (setq tag-list (cdr tag-list))) ) ! (defun semantic-dso-after-full-reparse-hook (tag-list) ! "Called after a complete reparse of the current buffer. ! Eventually calls `semantic-decorate-reparse-hook'. ! Argument TAG-LIST is the list of tags recently parsed." ;; Flush everything (semantic-dso-flush-rogue-overlays) ;; Add it back on ! (semantic-decorate-reparse-hook tag-list)) ! (defun semantic-decorate-reparse-hook (tag-list) ! "Called when the new tags TAG-LIST are created in a buffer. ! Adds decorations to these fresh tags, and makes sure old decorations ! in the area are completely flushed." (while tag-list (let ((oldoverlays (semantic-tag-get-secondary-overlay (car tag-list) 'semantic-dso))) --- 181,203 ---- (setq tag-list (cdr tag-list))) ) ! (defun semantic-decorate-tags-full (tag-list) ! "Add decorations to tags in TAG-LIST, after flushing existing ones. ! Call `semantic-decorate-tags' to add decorations. ! Typically called from `semantic-after-toplevel-cache-change-hook', ! after a complete reparse of the current buffer, in which case TAG-LIST ! is the list of tags recently parsed." ;; Flush everything (semantic-dso-flush-rogue-overlays) ;; Add it back on ! (semantic-decorate-tags tag-list)) ! (defun semantic-decorate-tags (tag-list) ! "Add decorations to tags in TAG-LIST. ! Also make sure old decorations in the area are completely flushed. ! Typically called from `semantic-after-partial-cache-change-hook', when ! new tags are created in a buffer, in which case TAG-LIST is the list ! of newly created tags." (while tag-list (let ((oldoverlays (semantic-tag-get-secondary-overlay (car tag-list) 'semantic-dso))) *************** *** 220,226 **** (funcall (car (cdr (car secondary))) (car tag-list))) (setq secondary (cdr secondary)))) ;; Recurse on the children of all tags ! (semantic-decorate-reparse-hook (semantic-tag-components-with-overlays (car tag-list))) (setq tag-list (cdr tag-list)))) --- 224,230 ---- (funcall (car (cdr (car secondary))) (car tag-list))) (setq secondary (cdr secondary)))) ;; Recurse on the children of all tags ! (semantic-decorate-tags (semantic-tag-components-with-overlays (car tag-list))) (setq tag-list (cdr tag-list)))) |
From: Eric M. L. <er...@si...> - 2004-06-14 17:48:47
|
>>> David PONCE <dav...@wa...> seems to think that: >> Yes, a good idea. Thanks > >OK. I committed the change. > >WDYT of the following patch that renames the functions >`semantic-dso-after-full-reparse-hook' and >`semantic-decorate-reparse-hook' to respectively >`semantic-decorate-tags-full' and `semantic-decorate-tags'. > >I find those new names more consistent with what the functions do, >and it is more evident that they are not hook-only functions. [ ... ] That sounds like a good idea to me. Thanks. Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Eric M. L. <er...@si...> - 2004-06-15 16:49:55
|
>>> David PONCE <dav...@wa...> seems to think that: >Hi Eric, > >> I agree with your assessment of the -update- in the name, but >> `semantic-decorate-tags' sounds like something that could be really >> useful when this function is very specific about apply decorations >> for semantic-decoration-mode which is less useful. >> >> Maybe I should have named all those internal functions using the >> semantic-decorate--* convention used elsewhere for internal >> functions. > >I worked a bit more on the new semantic-decoration-mode, and wrote >the following cleaned up implementation. For now, I renamed the library >semantic-decoration-mode to avoid confusion. I'm at work at the moment and cannot run it, but it looks good. >The main changes I did are: > >- elimination of implementation terms like primary/secondary overlay, > replaced by primary tag highlighting versus independent decoration. I had those two modes (the attribute, and boundary modes) separate and so different for so long it never occurred to me that the interface was essentially the same. Amazing. >- to provide a basic API to manage independent decorations, > introducing a level of abstraction from tags' secondary overlays. This was much needed. Nifty. >- unification of the notion of decoration style. This simplifies the > interface, as the distinction between primary and secondary > decoration style appeared to me not really necessary. The consequence is > that there is only one `define-semantic-decoration-style' to define > any kind of decoration style. The distinction between a primary > highlighting and an independent decoration being actually handled by > the `NAME-highlight' overload. > >I finally tried to find a good naming scheme for the various >functions in that library. It would be nice if you could have a look >at the code and give me your feedback. I will examine this more closely soon as it still needs a bit of customization magic and perhaps a senator menu. It also needs some smarts about the call to `semantic-fetch-tags' which needs to be postponed till after a buffer is displayed. >FYI, I tried it in Java and Elisp buffers, and it seems to work >nicely ;-) To try it, just load the library and enable/disable >`semantic-decoration-mode'! [ ... ] Great! >(defun semantic-decorate-clear-tag (tag &optional deco) > "Remove decorations from TAG. >If optional argument DECO is non-nil, remove only that decoration." > (assert (or (null deco) (semantic-decoration-p deco))) > ;; Clear primary decorations. > ;; For now, just unhighlight the tag. How to deal with other > ;; primary decorations like invisibility, etc. ? Maybe just > ;; restoring default values will suffice? > (semantic-unhighlight-tag tag) > (semantic-tag-delete-secondary-overlay > tag (or deco 'semantic-decoration))) This function no longer recurses on tag members. Is this happening elsewhere and I just can't see it? As for your comment about invisibility, etc, those decorate api calls could each leave a trace on how to remove itself late. I will contemplate this some more. Thanks Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Eric M. L. <er...@si...> - 2004-06-17 15:40:19
|
>>> David PONCE <dav...@wa...> seems to think that: >Eric, > >Following your remark below, about `semantic-decoration-mode': > >> I will examine this more closely soon as it still needs a bit of >> customization magic and perhaps a senator menu. It also needs some >> smarts about the call to `semantic-fetch-tags' which needs to be >> postponed till after a buffer is displayed. > >WDYT of the following approach to postpone calls to >`semantic-fetch-tags', by replacing them by calls to a new >(simplistic) function: `semantic-fetch-available-tags', that just >returns the tags currently in the cache, provided that the >`semantic-after-*-hook' hooks will DTRT when new tags become >available? [ ... ] Strange, I had that same thought while driving in to work today, but you beat me to it. Such a function would be useful for those other modes where I had removed the fetching of the tag list already. That would be a great addition, especially if the .texi file gets updated too. ;) Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Eric M. L. <er...@si...> - 2004-06-18 19:02:17
|
>>> David PONCE <dav...@wa...> seems to think that: >Hi Eric, > >[...] >>>WDYT of the following approach to postpone calls to >>>`semantic-fetch-tags', by replacing them by calls to a new >>>(simplistic) function: `semantic-fetch-available-tags', that just >>>returns the tags currently in the cache, provided that the >>>`semantic-after-*-hook' hooks will DTRT when new tags become >>>available? >> >> [ ... ] >> >> Strange, I had that same thought while driving in to work today, but >> you beat me to it. Such a function would be useful for those other >> modes where I had removed the fetching of the tag list already. >> >> That would be a great addition, especially if the .texi file gets >> updated too. ;) > >OK, I committed these changes: > >2004-06-18 David Ponce <da...@dp...> > > * cedet/semantic/semantic-decorate-mode.el > > (semantic-decoration-mode-setup): Use > `semantic-fetch-available-tags' to postpone parse till after the > buffer is displayed. > > * cedet/semantic/semantic.el > > (semantic-fetch-available-tags): New function. Great! Thanks. >Does the following change to the "Language Support Developer's >Guide" look good for you? [ ... ] It looks right, though you may need to add a blank line between paragraphs for it to print out properly. Thanks! Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: David P. <dav...@wa...> - 2004-06-14 15:24:57
|
> WDYT of the following patch that renames the functions > `semantic-dso-after-full-reparse-hook' and > `semantic-decorate-reparse-hook' to respectively > `semantic-decorate-tags-full' and `semantic-decorate-tags'. I wonder if `semantic-add-tag-decorations' and `semantic-update-tag-decorations' wouldn't even be better names? David |
From: Eric M. L. <er...@si...> - 2004-06-14 18:03:58
|
>>> David PONCE <dav...@wa...> seems to think that: >> WDYT of the following patch that renames the functions >> `semantic-dso-after-full-reparse-hook' and >> `semantic-decorate-reparse-hook' to respectively >> `semantic-decorate-tags-full' and `semantic-decorate-tags'. > >I wonder if `semantic-add-tag-decorations' and `semantic-update-tag-decorations' >wouldn't even be better names? [ ... ] I dunno. As long as it is consistent I don't have a strong opinion between the two. They do practically the same thing, except the first flushes rogue secondary overlays due to when it comes in as a hook. Perhaps the first would be `semantic-decorate-tags-after-full-reparse', since that is the only thing it can do, and then as you suggest, `semantic-decorate-update-tags' to keep the prefix and use your secondly suggested term. Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: David P. <dav...@wa...> - 2004-06-14 18:38:00
|
>>>WDYT of the following patch that renames the functions >>>`semantic-dso-after-full-reparse-hook' and >>>`semantic-decorate-reparse-hook' to respectively >>>`semantic-decorate-tags-full' and `semantic-decorate-tags'. >> >>I wonder if `semantic-add-tag-decorations' and `semantic-update-tag-decorations' >>wouldn't even be better names? > > [ ... ] > > I dunno. As long as it is consistent I don't have a strong opinion > between the two. They do practically the same thing, except the > first flushes rogue secondary overlays due to when it comes in as a > hook. > > Perhaps the first would be > `semantic-decorate-tags-after-full-reparse', since that is the only > thing it can do, and then as you suggest, > `semantic-decorate-update-tags' to keep the prefix and use your > secondly suggested term. That makes sense. Anyway, `semantic-decorate-tags-after-full-reparse' is clearer that `semantic-dso-after-full-reparse-hook', and I agree with you that this function is certainly hook-oriented. About `semantic-decorate-update-tags', I prefer the name `semantic-decorate-tags'. I find it less confusing than `semantic-decorate-update-tags' which seems to suggest that the function updates tags. Also, I find `semantic-decorate-tags' a good name for the basic function that actually decorates tags ;-) If you agree with that, I will commit the change. Thanks! David |
From: Eric M. L. <er...@si...> - 2004-06-14 20:11:45
|
>>> David Ponce <dav...@wa...> seems to think that: > >>>WDYT of the following patch that renames the functions > >>>`semantic-dso-after-full-reparse-hook' and > >>>`semantic-decorate-reparse-hook' to respectively > >>>`semantic-decorate-tags-full' and `semantic-decorate-tags'. > >> > >>I wonder if `semantic-add-tag-decorations' and `semantic-update-tag-decorations' > >>wouldn't even be better names? > > > > [ ... ] > > > > I dunno. As long as it is consistent I don't have a strong opinion > > between the two. They do practically the same thing, except the > > first flushes rogue secondary overlays due to when it comes in as a > > hook. > > > > Perhaps the first would be > > `semantic-decorate-tags-after-full-reparse', since that is the only > > thing it can do, and then as you suggest, > > `semantic-decorate-update-tags' to keep the prefix and use your > > secondly suggested term. > >That makes sense. Anyway, `semantic-decorate-tags-after-full-reparse' >is clearer that `semantic-dso-after-full-reparse-hook', and I agree with >you that this function is certainly hook-oriented. > >About `semantic-decorate-update-tags', I prefer the name >`semantic-decorate-tags'. I find it less confusing than >`semantic-decorate-update-tags' which seems to suggest that the >function updates tags. Also, I find `semantic-decorate-tags' a good >name for the basic function that actually decorates tags ;-) > >If you agree with that, I will commit the change. [ ... ] I agree with your assessment of the -update- in the name, but `semantic-decorate-tags' sounds like something that could be really useful when this function is very specific about apply decorations for semantic-decoration-mode which is less useful. Maybe I should have named all those internal functions using the semantic-decorate--* convention used elsewhere for internal functions. Eric -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Eric M. L. <er...@si...> - 2004-06-14 12:07:49
|
Yes, a good idea. Thanks Eric >>> David PONCE <dav...@wa...> seems to think that: >Hi Eric, > >> I've added `semantic-decorate-mode.el' to the CVS repository. This >> represents a replacement for `semantic-highlight-by-attribute-mode' >> and `semantic-show-tag-boundaries-mode'. It encapsulates what I >> learned making those modes as a set of macros. >[...] > >This is a good idea to regroup decoration modes in one library. >Following is a small patch that fixes two bad references to >semantic-util-modes. If you like I can commit it. > >David > >2004-06-14 David Ponce <da...@dp...> > > * cedet/semantic/semantic-decorate-mode.el > > (global-semantic-decoration-mode): Fix :require. > >Index: semantic-decorate-mode.el >=================================================================== >RCS file: /cvsroot/cedet/cedet/semantic/semantic-decorate-mode.el,v >retrieving revision 1.1 >diff -c -r1.1 semantic-decorate-mode.el >*** semantic-decorate-mode.el 13 Jun 2004 02:50:41 -0000 1.1 >--- semantic-decorate-mode.el 14 Jun 2004 09:16:32 -0000 >*************** >*** 1,4 **** >! ;;; semantic-util-modes.el --- Semantic minor modes > > ;;; Copyright (C) 2000, 2001, 2002, 2003, 2004 Eric M. Ludlam > >--- 1,4 ---- >! ;;; semantic-decorate-mode.el --- Minor mode for decorating tags > > ;;; Copyright (C) 2000, 2001, 2002, 2003, 2004 Eric M. Ludlam > >*************** >*** 76,82 **** > `semantic-decoration-secondary-alist' will be enabled." > :group 'semantic > :type 'boolean >! :require 'semantic-util-modes > :initialize 'custom-initialize-default > :set (lambda (sym val) > (global-semantic-decoration-mode (if val 1 -1)))) >--- 76,82 ---- > `semantic-decoration-secondary-alist' will be enabled." > :group 'semantic > :type 'boolean >! :require 'semantic-decorate-mode > :initialize 'custom-initialize-default > :set (lambda (sym val) > (global-semantic-decoration-mode (if val 1 -1)))) > > > -- Eric Ludlam: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |