>>> David PONCE <david.ponce@...> seems to think that:
>> Could you also examine the possibility of turning this mode-bindings
>> feature into a stand-alone option? It is indispensable for
>> semantic's code readability, and I was contemplating it's use in EDE,
>> which also has mode-specific features. There are, in fact, lots and
>> lots of Emacs features that could be best handled this way and a
>> stand-alone version of it could be more easily depended on by others.
>> The real trick is in the complex set of mode-change type hooks in
>> semantic.el. This feature would be needed in a stand alone version,
>> and semantic could then just piggy-back it's local functionality off
>> of this feature. That would simplify more complex aspects of
>I started to think about that, and got some questions. Here they are:
>- The first and simplest one is what name to choose for the new
> library (which I guess will go into the common package)? I thought
> to cedet-fw, but perhaps have you a better idea?
I think the utility of it goes beyond just cedet. I suspect
something like mode-bindings.el would be nifty.
You could create an entire custom major mode with only minimal
touching of the main mode creation function since all custom mode
values and functions could be specified via this utility.
>- About the hook machinery I thought that a general implementation
> could be easily derived from what is now in semantic-fw.el, with one
> significant difference: instead of calling the hard-coded function
> `semantic-new-buffer-fcn', the change mode hook could run a new
> `cedet-init-hook'. For Semantic to use the new common mechanism, it
> should suffice to add `semantic-new-buffer-fcn' to the new hook.
> Here is what the code could look to:
I agree. The specifics of semantic start up could be done via a hook
type mechanism from the mode bindings library.
> ;;; Hook machinery to setup a new file buffer
> ;; Public hook to setup a new buffer
> (defvar cedet-init-hook nil
> "Hook run after a new file buffer is created.
> The current buffer is the newly created file buffer.")
> ;; Internal generic change mode hook mechanism
> (defvar cedet-changed-mode-buffers nil
> "List of buffers whose `major-mode' has changed recently.")
> (defun cedet-post-major-mode-change ()
> "`post-command-hook' run when there is a `major-mode' change.
> This makes sure semantic-init type stuff can occur."
> (remove-hook 'post-command-hook 'cedet-post-major-mode-change)
> (while cedet-changed-mode-buffers
> (let ((buf (pop cedet-changed-mode-buffers)))
> (and (buffer-live-p buf)
> (buffer-file-name buf)
> (with-current-buffer buf
> ;; Make sure variables are set up for this mode.
> (run-hook 'cedet-init-hook))))))
> (defun cedet-on-major-mode-change ()
> "Function called in `change-major-mode-hook'."
> (add-to-list 'cedet-changed-mode-buffers (current-buffer))
> (add-hook 'post-command-hook 'cedet-post-major-mode-change))
> (add-hook 'find-file-hooks 'cedet-post-major-mode-change)
> (add-hook 'change-major-mode-hook 'cedet-on-major-mode-change)
> ;;; In semantic.el
> (add-hook 'cedet-init-hook 'semantic-new-buffer-fcn)
> Do you see other needs?
That would certainly do it. A hard thing we dealt with was calling
the semantic setup only once in some situations. Fortunately that
machinery is handled nicely by copying the old code.
>- The core semantic bindings API actually doesn't depend on semantic
> and should be easily generalizable. The only problem I can see is
> with the overload mechanism which assumes that `semantic-' is the
> default prefix of overloads, particularly through the function
> `semantic-overload-symbol-from-function'. The easy way to fix that
> would be to no more allow overload symbol like: `parse-stream' but
> to require a full name: `semantic-parse-stream'. So overloads will
> obey the general naming convention used in Emacs to prevent
> name conflicts between different libraries. The major problem will
> be incompatibility with existing semantic overloads!
> Unfortunately, for now, I don't have a better idea to propose :-(
> Maybe have you already thought about something else?
[ ... ]
The fancy short-name variety existed for documentation purposes and
so that they could be added to via the old association function.
By removing the semantic- removal process so that semantic- prefix is
then included, old code would be made safe by modifying
semantic-install-function-overrides to re-add the semantic- prefix
since at this time, there are no non-semantic overload symbols.
It could also reference some master list of overrides to see if there
is a semantic- equivalent.
With the new api you proposed, it should be unnecessary to use an
install-function-overrides type function, except perhaps in a
multi-mode satiation where I have one override fcn for multiple modes
like C and C++.
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org