>>> ryk@... seems to think that:
>Hi all,
>
>I cut and pasted all of the old semantic.texi to the new files under
>the semantic/doc directory. I'll be taking an inventory of what we
>already have by reading it all in the next day or two.
[ ... ]
>* Started using "Infrastructure for parser based text analysis in Emacs."
> whenever a brief description of semantic is uses such as info menu
> line. I think "parser generator" doesn't do justice to semantic,
> since it is far more than that. Let's see if we can think of better
> catchy phrase :)
I like your catch-phrase. Perhaps some of the tools (senator,
analyze, speedbar, etc) should be moved into their own dependent
package under cedet.
>* Created "Glossary" chapter for now. I think it would be a good idea
> to define all the terms here so that we can reference them, e.g.,
> @ref{lexical tokens}. I remember being confused early on between
> "lexical tokens" and "semantic tokens".
>
> I don't know whether we need to have a
> separate glossary chapter when we are done with the manual.
> We may instead choose to disperse all the definitions into other
> chapters.
>
> I defined the following macro for declaring each keyword.
>
> @c To be used within the glossary section.
> @macro keyword{kw}
> @anchor{\kw\}
> @b{\kw\}
> @end macro
>
> The only thing it does for now is to use the @anchor{} command so
> that you can use @ref{} to link to it.
[ ... ]
This is neat. I had no idea you could do this in texinfo.
Thanks!
Eric
--
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

Hi all,
I cut and pasted all of the old semantic.texi to the new files under
the semantic/doc directory. I'll be taking an inventory of what we
already have by reading it all in the next day or two.
I list some of the changes I made so far.
Please let me know if any one of them needs to be changed.
* Copied Free Document Licensing fil, fdl.texi, from wisent directory
and cut and pasted FDL related lines from wisent to new semantic manual.
* Changed copyright to
Copyright @copyright{} 1999, 2000, 2001, 2002, 2003 Eric M. Ludlam
Copyright @copyright{} 2001, 2002, 2003 David Ponce
* Started using "Infrastructure for parser based text analysis in Emacs."
whenever a brief description of semantic is uses such as info menu
line. I think "parser generator" doesn't do justice to semantic,
since it is far more than that. Let's see if we can think of better
catchy phrase :)
* Created "Glossary" chapter for now. I think it would be a good idea
to define all the terms here so that we can reference them, e.g.,
@ref{lexical tokens}. I remember being confused early on between
"lexical tokens" and "semantic tokens".
I don't know whether we need to have a
separate glossary chapter when we are done with the manual.
We may instead choose to disperse all the definitions into other
chapters.
I defined the following macro for declaring each keyword.
@c To be used within the glossary section.
@macro keyword{kw}
@anchor{\kw\}
@b{\kw\}
@end macro
The only thing it does for now is to use the @anchor{} command so
that you can use @ref{} to link to it.

The token access code has now all moved. The new semantic-token.el
file just has all the good ol' code from before.
You can read in the commentary of that file a little bit about how I
think it could be organized.
Next up is to prototype a new API. This is a bit of a hybrid of what
David had proposed a while back.
A generic token may be created like this:
(semantic-token name type-symbol &rest plist)
;; Note, doc-string could be found in the plist, and properties and
overlay are set up after creation.
Special tokens could be created like this:
(semantic-token-new-variable name type default-value &rest extra-specifiers)
(semantic-token-new-function name type arg-list &rest extra-specifiers)
(semantic-token-new-type name type part-list parents &rest extra-specifiers)
(semantic-token-new-include name system-flag &rest plist)
(semantic-token-new-package name detail &rest plist)
where the extra-specifiers are a plist. In the existing storage
mechanism, they would be put into the extra-specifier slot, and
reduced (removing nils).
I think the special token constructors would be useful for language
authors who need encouragement to fill in all the right pieces.
Eric
--
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

>>> "David PONCE" <David.Ponce@...> seems to think that:
>> A while back, we had a discussion about semantic token formats, and
>> concocting a single function for constructing them. Then both parsers
>> could use them to create tokens, and once that was safe, we could
>> change the underlying storage. (If desired).
>>
>> I'm going to take a first stab at this. Eventually, I'll check in
>> semantic-token.el with elements from semantic-fw and semantic-util in
>> it. After that, I'll build the constructors. Then we can look at
>> porting old parsers to the new constructors.
>>
>> Thoughts?
>> Eric
>>
>
>Will you use EIEIO objects to represent tokens or a simpler (more
>efficient?) property list approach, or a different mechanism?
>
>Anyway, that would be a great enhancement, that would probably require
>important changes to the existing code ;-)
[ ... ]
I intend to use the same internal format as before, and it may stay
that way for a while, until we are sure we have found and fixed all
code that may be using it. It is unclear to me how much ECB or JDE
or other unknown tool may be using that structure. Afterward, who
knows.
As far as new APIs are concerned, I was thinking a generic plist based
approach would be for generic access. It would work for any of the
mechanisms you suggest. Standard tokens (as described in the manual)
may get their own optimized constructors.
Eric
--
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

> A while back, we had a discussion about semantic token formats, and
> concocting a single function for constructing them. Then both parsers
> could use them to create tokens, and once that was safe, we could
> change the underlying storage. (If desired).
>
> I'm going to take a first stab at this. Eventually, I'll check in
> semantic-token.el with elements from semantic-fw and semantic-util in
> it. After that, I'll build the constructors. Then we can look at
> porting old parsers to the new constructors.
>
> Thoughts=3F
> Eric
>
Will you use EIEIO objects to represent tokens or a simpler (more
efficient=3F) property list approach, or a different mechanism=3F
Anyway, that would be a great enhancement, that would probably require
important changes to the existing code ;-)
David

A while back, we had a discussion about semantic token formats, and
concocting a single function for constructing them. Then both parsers
could use them to create tokens, and once that was safe, we could
change the underlying storage. (If desired).
I'm going to take a first stab at this. Eventually, I'll check in
semantic-token.el with elements from semantic-fw and semantic-util in
it. After that, I'll build the constructors. Then we can look at
porting old parsers to the new constructors.
Thoughts?
Eric
--
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

Hi Richard,
> I thought it might be good to move all the documentation from the old
> semantic.texi to approprate chapters in the new manual first before
> starting to add new stuff. I could do that unless you or David would
> like to get to it first. Let me know.
That would be great. Please do.
Thanks!
David

Hi Eric,
> There is a routine in semantic-util that finds externally defined
> children for a given type. This routine really bogged things down
> with the Emacs Lisp system db.
>
> The core routine for that is now in semanticdb-search and can be
> overriden by specific types of system databases. I removed the old
> code from semantic-util. I also changed semantic-analyze to use the
> new routine. While I was in semantic-util, I found some more
> functions that needed to be converted to `define-overload'.
>
> I also found an fixed some bugs in semantic-analyze. The analyzer
> mode for speedbar is now much more robust for C++, and significantly
> more accurate. If you use C++, give it a try.
All that looks good. Thanks!
Maybe it would be worth adding your comments below I found in
semanticdb-search.el, in the NEWS file=3F
;; There are three types of searches that can be implemented:
;;
;; Basic Search:
;; These searches allow searching on specific attributes of tokens,
;; such as name or type.
;;
;; Advanced Search:
;; These are searches that were needed to accomplish some tasks
;; during in utilities. Advanced searches include matching methods
;; defined outside some parent class.
;;
;; The reason for advanced searches are so that external
;; repositories such as the Emacs obarray, or java .class files can
;; quickly answer these needed questions without dumping the entire
;; symbol list into Emacs for a regular semanticdb search.
;;
;; Generic Search:
;; The generic search, `semanticdb-find-nonterminal-by-function'
;; accepts a Emacs Lisp predicate that tests tokens in Semantic
;; format. Most external searches cannot perform this search.
David

Eric,
I thought it might be good to move all the documentation from the old
semantic.texi to approprate chapters in the new manual first before
starting to add new stuff. I could do that unless you or David would
like to get to it first. Let me know.

There is a routine in semantic-util that finds externally defined
children for a given type. This routine really bogged things down
with the Emacs Lisp system db.
The core routine for that is now in semanticdb-search and can be
overriden by specific types of system databases. I removed the old
code from semantic-util. I also changed semantic-analyze to use the
new routine. While I was in semantic-util, I found some more
functions that needed to be converted to `define-overload'.
I also found an fixed some bugs in semantic-analyze. The analyzer
mode for speedbar is now much more robust for C++, and significantly
more accurate. If you use C++, give it a try.
Eric
--
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

>>>>> "EL" == Eric M Ludlam <eric@...> writes:
EL>
EL> I think semantic/doc makes sense.
I took the liberty of adding semantic/doc directory to CVS.
I also created one file per each chapter.
A simple Makefile is also provided.
>> Could you suggest me where I could split the wisent manual up, and
>> where to insert parts in the global outline? I would really
>> appreciate it :-)
David, most of wisent manual provbably belongs in
lang-support-guide.texi file. However please feel free to
experiement with the overal organization.
EL> It would be great if the outline contained the include statements
EL> where you suggest sections of the manual could be written. This
EL> would answer David's question most succinctly.
For now each chapter is included by the master file.
I also cut and pasted rest of your comments into the texinfo
files. The comments were fenced out with @ignore .... @end ignore.
It is probably a good idea to comment out comments meant for
the authors with such fencing of @c comment lines.
In the next few days, I'll try to add more comments and more
sections so that we get settle down on the overall
structure.
Remember everything is open to changes. Please feel free to
try out different names, different organizations, etc.

>>> "David PONCE" <David.Ponce@...> seems to think that:
[ ... ]
>> Anyway, I have some doc for extending semanticdb I need to write
>> also, and was thinking it would be good to move it all into a
>> subdirectory such as "semantic/info". It would also be good to
>> split up the existing manual, as it is somewhat hard to edit at
>> 3000+ lines. As many functions it refers too are now obsolete, I
>> really need to go through and update it.
>[...]
>
>GNU Emacs uses emacs/man for manual sources (.texi) and emacs/info for
>manual in info format.
>
>Maybe we could use a such organization? However I would prefer
>"semantic/doc" to "semantic/man" because "man" is already reserved for
>Un*x manuals ;-)
I think semantic/doc makes sense.
[ ... ]
>> EL> Perhaps Richard has some suggestions on this topic.
>>
>> I would like to suggest that we merge all semantic
>> documentation info one manual. Of course this doesn't mean
>> that we can't split the manual into several files.
[ ... ]
>
>Thanks Richard, I love that idea! I found your outline very good.
>Maybe could you check it in in a new semantic/doc (or what we decide
>to use) directory. It would be an excellent starting point.
>
>Eric, what do you think?
I agree. I certainly think that getting things started is a good
idea.
>Could you suggest me where I could split the wisent manual up, and
>where to insert parts in the global outline? I would really
>appreciate it :-)
Your outline so far is great. I have the follow suggestions, most of
which are just enhancements on things you probably didn't get to.
It would be great if the outline contained the include statements
where you suggest sections of the manual could be written. This
would answer David's question most succinctly.
For the parser developer, I can think of two extra sections. One for
semanticdb extensions, (If a system database is needed.) A second
for the `semantic-ctxt' extensions. Many of the most interesting
tools will completely fail to work without local context parsing
support.
Perhaps even a section on foreign tokens. For example, putting a
Java token into a C++ file could auto-gen a native method, just as
putting a token into a Texinfo file converts it into documentation.
In addition, in the "writing grammars" section should have
subsections as listed in the examples of the overview section. It
might be useful to have a fourth section describing the similarities
between the two file types (by and wy) and how to use the grammar
mode. (I'm not sure if that should be covered elsewhere.)
With those sections, perhaps instead of "Parser Developer", a better
term is "Language Support Developer" where the parser is one subset
of a greater whole of completely abstracting the language so that it
can be used by generic tools.
An application developer section needs to know how to get token lists,
get details from tokens, extract and search those lists with and
without the database, and convert tokens into displayable text
strings in one of the many different formats.
Thanks!
Eric
--
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

>>> "Berndl, Klaus" <klaus.berndl@...> seems to think that:
>Hi Eric
>
>> This is indeed the right kind of solution. I just went back to
>> look at the implementation, and discovered the documentation is
>> incorrect for that hook. It claims that if a hook value returns
>> nil, then the cache is returned. This is no longer true. Parsing
>> will now also returns nil if a hook fails.
>
>Oh, does this mean: If one of these hooks fails then always nil is returned,
>regardless of the cache-contents??
>Why this change? What are the advantages compared to the previous
>behavior where simply the parsing is not performed and the cache returned??
[ ... ]
I think it is a bug that went unnoticed when we refactored the
parsing APIs. I'll add it to my list of things to fix.
Eric
--
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

Hi Eric
> This is indeed the right kind of solution. I just went back to
> look at the implementation, and discovered the documentation is
> incorrect for that hook. It claims that if a hook value returns
> nil, then the cache is returned. This is no longer true. Parsing
> will now also returns nil if a hook fails.
Oh, does this mean: If one of these hooks fails then always nil is returned,
regardless of the cache-contents??
Why this change? What are the advantages compared to the previous
behavior where simply the parsing is not performed and the cache returned??
Ciao,
Klaus
> I don't think this matters for Richard's case, but it may for other
> uses.
Eric
--
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

>>> Klaus Berndl <klaus.berndl@...> seems to think that:
>On Sun, 23 Feb 2003, ryk@... wrote:
>
>> Hi all,
>>
>> I use pcl-cvs (aka pcvs in emacs 21) daily. I use the cvs-mode-idiff
>> differencing command dozens if not hundreds of times each day.
>> Hence the extra 3 or 4 second delay that semantic causes while it
>> parses files cvs-mode-idiff loads for differencing purpose was too
>> much for me especially since these files are used only for
>> differencing and nothing else.
>>
>> So I wrote the code below to conditionally suppress semantic on
>> temporary files. I tracked semantic-activate-mode-bindings down by
>> starting with semantic-post-change-major-mode-function which was in
>> find-file-hook list.
>>
>> What do you think? Is there a better way? Should something like this
>> be a part of semantic?
>
>IMHO there is a better way, means an already builtin way ;-)
>Take a look at `semantic-before-toplevel-bovination-hook'.
>If i understand your problem and your solution right then the following should
>be enough:
>
>,----
>| (add-hook 'semantic-before-toplevel-bovination-hook
>| (lambda ()
>| (not (string-match "\\.\\(HEAD$\\|BASE\\)$" (buffer-name)))))
>`----
>
>Any hook-function returning nil prevents semantic from parsing.
>
>At least this should do what your solution does...
[ ... ]
Hi Klaus,
This is indeed the right kind of solution. I just went back to
look at the implementation, and discovered the documentation is
incorrect for that hook. It claims that if a hook value returns
nil, then the cache is returned. This is no longer true. Parsing
will now also returns nil if a hook fails.
I don't think this matters for Richard's case, but it may for other
uses.
Eric
--
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

Hi Eric and Richard,
Thank you for your feedback!
[...]
> Anyway, I have some doc for extending semanticdb I need to write
> also, and was thinking it would be good to move it all into a
> subdirectory such as "semantic/info". It would also be good to
> split up the existing manual, as it is somewhat hard to edit at
> 3000+ lines. As many functions it refers too are now obsolete, I
> really need to go through and update it.
[...]
GNU Emacs uses emacs/man for manual sources (.texi) and emacs/info for
manual in info format.
Maybe we could use a such organization=3F However I would prefer
"semantic/doc" to "semantic/man" because "man" is already reserved for
Un*x manuals ;-)
> ps. Here is a short diff
[...]
Thanks Eric, I applied it.
------------------------------------------------------------
[...]
> EL> Perhaps Richard has some suggestions on this topic.
>
> I would like to suggest that we merge all semantic
> documentation info one manual. Of course this doesn't mean
> that we can't split the manual into several files.
>
> I provide a very rough outline below.
>
> If we agree on this approach, we can work on refining the
> structure (chapters and sections) and brief summaries of
> each chapters and sections. Then we can merge existing
> semantic/wisent documents first. Refining I'm sure would
> follow.
>
> I will be happy to act as the secretary in making pushing
> things along so that we have semantic 2.0 manual to go along
> with the first release.
[...]
Thanks Richard, I love that idea! I found your outline very good.
Maybe could you check it in in a new semantic/doc (or what we decide
to use) directory. It would be an excellent starting point.
Eric, what do you think=3F
Could you suggest me where I could split the wisent manual up, and
where to insert parts in the global outline=3F I would really
appreciate it :-)
David

On Sun, 23 Feb 2003, ryk@... wrote:
> Hi all,
>
> I use pcl-cvs (aka pcvs in emacs 21) daily. I use the cvs-mode-idiff
> differencing command dozens if not hundreds of times each day.
> Hence the extra 3 or 4 second delay that semantic causes while it
> parses files cvs-mode-idiff loads for differencing purpose was too
> much for me especially since these files are used only for
> differencing and nothing else.
>
> So I wrote the code below to conditionally suppress semantic on
> temporary files. I tracked semantic-activate-mode-bindings down by
> starting with semantic-post-change-major-mode-function which was in
> find-file-hook list.
>
> What do you think? Is there a better way? Should something like this
> be a part of semantic?
IMHO there is a better way, means an already builtin way ;-)
Take a look at `semantic-before-toplevel-bovination-hook'.
If i understand your problem and your solution right then the following should
be enough:
,----
| (add-hook 'semantic-before-toplevel-bovination-hook
| (lambda ()
| (not (string-match "\\.\\(HEAD$\\|BASE\\)$" (buffer-name)))))
`----
Any hook-function returning nil prevents semantic from parsing.
At least this should do what your solution does...
Thoughts?
Klaus
>
>
> (defadvice semantic-activate-mode-bindings
> (around suppress-tmp-files activate compile)
> "Don't setup semantic for tmp files such as files CVS loads for the
> purpose of differencing."
> (cond
> ;; Bypass files loaded by CVS for differencing.
> ;; This doesn't work on files retrieved with explicit version numbers.
> ((string-match "\\.\\(HEAD$\\|BASE\\)$" (buffer-name))
> ;; Hmm. I thought the line below would not be needed at first,
> ;; because bypassing the body of semantic-activate-mode-bindings
> ;; would not setup semantic variables. But this advice does not
> ;; work without the line below. -ryk2/23/03.
> (setq semantic-toplevel-bovine-table nil))
> (t ad-do-it)))
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> http://www.slickedit.com/sourceforge
--
Klaus Berndl mailto: klaus.berndl@...
sd&m AG http://www.sdm.de
software design & management
Thomas-Dehler-Str. 27, 81737 München, Germany
Tel +49 89 63812-392, Fax -220

Hi all,
I use pcl-cvs (aka pcvs in emacs 21) daily. I use the cvs-mode-idiff
differencing command dozens if not hundreds of times each day.
Hence the extra 3 or 4 second delay that semantic causes while it
parses files cvs-mode-idiff loads for differencing purpose was too
much for me especially since these files are used only for
differencing and nothing else.
So I wrote the code below to conditionally suppress semantic on
temporary files. I tracked semantic-activate-mode-bindings down by
starting with semantic-post-change-major-mode-function which was in
find-file-hook list.
What do you think? Is there a better way? Should something like this
be a part of semantic?
(defadvice semantic-activate-mode-bindings
(around suppress-tmp-files activate compile)
"Don't setup semantic for tmp files such as files CVS loads for the
purpose of differencing."
(cond
;; Bypass files loaded by CVS for differencing.
;; This doesn't work on files retrieved with explicit version numbers.
((string-match "\\.\\(HEAD$\\|BASE\\)$" (buffer-name))
;; Hmm. I thought the line below would not be needed at first,
;; because bypassing the body of semantic-activate-mode-bindings
;; would not setup semantic variables. But this advice does not
;; work without the line below. -ryk2/23/03.
(setq semantic-toplevel-bovine-table nil))
(t ad-do-it)))

>>> David Ponce <david.ponce@...> seems to think that:
>Hi All,
>
>I checked an updated version of the Wisent's manual in.
>
>I took into account latest changes in both Wisent and Semantic, and
>cleaned up the texinfo code to follow what I saw in Emacs manuals ;-)
>
>Free free to proofread it, and maybe use better English ;-)
[ ... ]
Hi,
It looks good. I tried to read the new sections but am not sure I
read everything.
Anyway, I have some doc for extending semanticdb I need to write
also, and was thinking it would be good to move it all into a
subdirectory such as "semantic/info". It would also be good to
split up the existing manual, as it is somewhat hard to edit at
3000+ lines. As many functions it refers too are now obsolete, I
really need to go through and update it.
Perhaps Richard has some suggestions on this topic.
Eric
ps. Here is a short diff
*** wisent.texi.~1.18.~ Sun Feb 23 13:09:09 2003
--- wisent.texi Sun Feb 23 13:40:20 2003
***************
*** 134,140 ****
Wisent can generate compilers compatible with the Semantic tool set.
See the @ref{Top, Semantic Manual, , semantic}.
! It benefits of the main Bison's features:
@itemize @bullet
@item
--- 134,140 ----
Wisent can generate compilers compatible with the Semantic tool set.
See the @ref{Top, Semantic Manual, , semantic}.
! It benefits from these Bison features:
@itemize @bullet
@item
***************
*** 383,389 ****
@item $nterm
This variable is initialized with the nonterminal symbol
(@var{nonterm}) the rule belongs to. It could be useful to improve
! error reporting or debugging. It is used too, to automatically
provide the @code{reparse-symbol} property of a Semantic token
generated by the function @code{wisent-cooked-token}. See
@ref{Wisent Semantic}, for details.
--- 383,389 ----
@item $nterm
This variable is initialized with the nonterminal symbol
(@var{nonterm}) the rule belongs to. It could be useful to improve
! error reporting or debugging. It is also used to automatically
provide the @code{reparse-symbol} property of a Semantic token
generated by the function @code{wisent-cooked-token}. See
@ref{Wisent Semantic}, for details.
***************
*** 1116,1122 ****
It is important to understand that the parser does not parse
characters, but lexical tokens, and does not know anything about
! characters and streams!
@cindex lexical analysis
@cindex lexer
--- 1116,1122 ----
It is important to understand that the parser does not parse
characters, but lexical tokens, and does not know anything about
! characters in text streams!
@cindex lexical analysis
@cindex lexer
--
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

Hi All,
I checked an updated version of the Wisent's manual in.
I took into account latest changes in both Wisent and Semantic, and
cleaned up the texinfo code to follow what I saw in Emacs manuals ;-)
Free free to proofread it, and maybe use better English ;-)
Thanks!
David

Eric,
[...]
>>In case it will help, I did the following changes in my local copy of
>>cedet:
>
>
> Thanks for looking into all those spots for me. If you can check
> them all it, that would be a great first step in making the rest of
> CEDET compatible. Thanks!
Done. I also committed a small fix into wisent-python.wy and a more
important compatibility fix into semantic-grammar.el.
Here is a change log:
2003-02-22 David Ponce <david@...>
* ede/ede-speedbar.el
(ede-file-find): Replaced `speedbar-line-path' with
`speedbar-line-directory' used since speedbar 0.15.
* eieio/eieio-speedbar.el
(eieio-speedbar-create-engine): Replaced `speedbar-line-path' with
`speedbar-line-directory' used since speedbar 0.15.
* semantic/semantic-grammar.el
No more depend on `with-syntax-table' implementation. For
example, since GNU Emacs 21.4 `with-syntax-table' no more use a
copy of the given syntax table.
(semantic-grammar-skip-quoted-syntax-table): New variable.
(semantic-grammar-goto-grammar-indent-anchor): Use it.
(semantic-grammar-brackets-as-parens-syntax-table): New variable.
(semantic-grammar-do-lisp-indent): Use it.
* semantic/semantic-ia-sb.el
(speedbar-add-mode-functions-list "Analyse"): Replaced
`speedbar-line-path' with `speedbar-line-directory' used since
speedbar 0.15.
* semantic/semantic-sb.el
(semantic-sb-token-jump): Replaced `speedbar-line-path' with
`speedbar-line-directory' used since speedbar 0.15.
* semantic/wisent/wisent-python.wy
(goal): Fixed comment delimiter.
[...]
> This change that any future release of semantic (beta or otherwise)
> now requires also a new release of speedbar and a new release of
> eieio. Using those means also a new release of EDE. To make it all
> work we should release a CEDET commons with inversion. Zoiks. Lots
> to do now.
Maybe it would be worth providing global cedet releases, as I already
proposed sometimes ago ;-)
David