Berndl, Klaus | 6 May 2004 10:44
Picon

RE: ECB question....

Hi Javier, Eric, david:

Oviedo, Javier wrote:
> Hello Klaus. I've run come across an interesting scenario that I
> thought you could help me with. 
> 
> We have an internal programming language that is a pseudo C type of
> language. Very similar but not the same. In any case, since they are
> so similar, I have the associated file type set to open the buffer in
> c-mode. Now the problem...since file is not really in true C syntax,
> semantic displays most of the file in the
> semantic-unmatched-syntax-face. This is very annoying to look at. :-)

Yes, i can imagine ;-)

> 
> I've gone through the manual looking for a way to disable this on a
> file by file basis. So far I've only found a way to disable the
> semantic parsing on a mode basis using
> ecb-non-semantic-exclude-modes. I tried using a defalias of c-mode
> and adding that defalias to the excluded modes, but that didn't
> work...given that defalias will return c-mode.     

`ecb-non-semantic-exclude-modes' is not for excluding modes from
being parsed by semantic - its for exckluding modes by being
parsed by imenu or etags when no semantic-parser exists for
this modes. Currently there is no way in ECB to exclude modes
from being parsed by semantic if for such a mode a semantic-
parser exists. And AFAIK there is also no customizable way to
exclude files from being parsed by semantic when a parser for this
(Continue reading)

Oviedo, Javier | 6 May 2004 15:28

RE: ECB question....


> IMHO semantic should offer a mechanism to exclude major-modes and/or files
(e.g. on a regexp-basis) from being > setup for semantic-parsing - even if
there is a parser available. Eric, David, what do you say??

I agree. It would be quite useful.

Thanks.

 -------------
 Javier

-----Original Message-----
From: Berndl, Klaus [mailto:klaus.berndl <at> sdm.de] 
Sent: Thursday, May 06, 2004 4:45 AM
To: 'Oviedo, Javier'; ecb-list <at> lists.sourceforge.net;
cedet-devel <at> lists.sourceforge.net
Subject: RE: ECB question....

Hi Javier, Eric, david:

Oviedo, Javier wrote:
> Hello Klaus. I've run come across an interesting scenario that I 
> thought you could help me with.
> 
> We have an internal programming language that is a pseudo C type of 
> language. Very similar but not the same. In any case, since they are 
> so similar, I have the associated file type set to open the buffer in 
> c-mode. Now the problem...since file is not really in true C syntax, 
> semantic displays most of the file in the 
(Continue reading)

Oviedo, Javier | 6 May 2004 15:58

ECB/Semantic method buffer bug report

Hello all:

This is my first time reporting a bug to this list, so I bare with me. I'm
not sure if this is a semantic or ecb bug. Given the nature of the bug and
my limited knowledge of ecb, I would guess that it is a semantic bug, but I
will let more knowledgeable people decide that. :-)

I'm using the following versions:
ecb version: 2.24
cedet version: 1.0beta2b

Here it is:

From time to time, while viewing a file using the ecb package the method
buffer goes blank. In order to get it to come back, I have to run rebuild
the methods buffer.

I have managed to find a sort of reproducible case in which this happens. I
load a .c file, the methods buffer is built and displayed. A few seconds
later it goes blank. Below is the output of the *Message* buffer from two
different instances of this bug happening. I'm not sure how else to debug
this. I hope this helps...I do see an error statement on one occasion, but
not the other, after loading semantic-tag-ls...perhaps this is the culprit.
If more info is needed please let me know exactly what and I would be more
than happy to try and reproduce it. Thanks!

*Message* Buffer Output:

The ECB is now activated.
There are no incompatible or renamed options!
(Continue reading)

Oviedo, Javier | 6 May 2004 16:07

possible bug??

Hello all:

I've noticed a periodic message in the mode line that has been driving me
crazy. :-)

I'm using ecb version 2.24 and cedet version 1.0beta2b. 

I kept seeing an error about eldoc-message not being defined when using ecb.
I grep'ed ecb and cedet directories and found that semantic-idle.el called
this function, presumably during idle times. I also grep'ed for a require to
eldoc.el and found it in semantic-grammar.el. This "require" in
semantic-grammar.el, however, was not enough to actually pull this function
definition(presumably the "require" was never called???). When I add a
"require" for eldoc.el in my .emacs file, the error messages go away. I
didn't want to add the require in semantic-idle.el itself, though I believe
this is where it should really go.

Any thoughts on this? Thanks.

 -------------
 Javier

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
Berndl, Klaus | 6 May 2004 16:37
Picon

RE: ECB/Semantic method buffer bug report

As a first step further you could do:

1. Activate debug-on-error
2. Reproduce the bug
3. send us the backtrace

Klaus

Oviedo, Javier wrote:
> Hello all:
> 
> This is my first time reporting a bug to this list, so I bare with
> me. I'm not sure if this is a semantic or ecb bug. Given the nature
> of the bug and my limited knowledge of ecb, I would guess that it is
> a semantic bug, but I will let more knowledgeable people decide that.
> :-) 
> 
> I'm using the following versions:
> ecb version: 2.24
> cedet version: 1.0beta2b
> 
> Here it is:
> 
> From time to time, while viewing a file using the ecb package the
> method buffer goes blank. In order to get it to come back, I have to
> run rebuild the methods buffer.
> 
> I have managed to find a sort of reproducible case in which this
> happens. I load a .c file, the methods buffer is built and displayed.
> A few seconds later it goes blank. Below is the output of the
(Continue reading)

Eric M. Ludlam | 6 May 2004 18:08
Gravatar

Re[1]: [CEDET-devel] ECB question....

>>> "Oviedo, Javier" <joviedo <at> telogy.com> seems to think that:
>
>> IMHO semantic should offer a mechanism to exclude major-modes and/or files
>(e.g. on a regexp-basis) from being > setup for semantic-parsing - even if
>there is a parser available. Eric, David, what do you say??
>
>I agree. It would be quite useful.
  [ ... ]

There are several per-buffer startup issues of a similar natures I
would like to do near term.  For this particular problem in the short
term, you should probably just create your own derived mode with it's
own hook so you can do that disabling work more easily yourself.

Eric

--

-- 
          Eric Ludlam:                 zappo <at> gnu.org, eric <at> siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
Vardhan Varma | 6 May 2004 18:31
Picon

Re: possible bug??

load-library eldoc fixes this.

On Thu May 6 2004 19:37, Oviedo, Javier wrote:
> Hello all:
>
> I've noticed a periodic message in the mode line that has been driving me
> crazy. :-)
>
> I'm using ecb version 2.24 and cedet version 1.0beta2b.
>
> I kept seeing an error about eldoc-message not being defined when using
> ecb. I grep'ed ecb and cedet directories and found that semantic-idle.el
> called this function, presumably during idle times. I also grep'ed for a
> require to eldoc.el and found it in semantic-grammar.el. This "require" in
> semantic-grammar.el, however, was not enough to actually pull this function
> definition(presumably the "require" was never called???). When I add a
> "require" for eldoc.el in my .emacs file, the error messages go away. I
> didn't want to add the require in semantic-idle.el itself, though I believe
> this is where it should really go.
>
> Any thoughts on this? Thanks.
>
>
>  -------------
>  Javier
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
(Continue reading)

Oviedo, Javier | 6 May 2004 18:49

RE: possible bug??

That is what I did in my .emacs file, but shouldn't the semantic file that
is calling a eldoc function do the require of eldoc.el instead of having the
user figure it out?

 -------------
 Javier

-----Original Message-----
From: Vardhan Varma [mailto:vardhan <at> cadence.com] 
Sent: Thursday, May 06, 2004 12:31 PM
To: cedet-devel <at> lists.sourceforge.net
Subject: Re: [CEDET-devel] possible bug??

load-library eldoc fixes this.

On Thu May 6 2004 19:37, Oviedo, Javier wrote:
> Hello all:
>
> I've noticed a periodic message in the mode line that has been driving 
> me crazy. :-)
>
> I'm using ecb version 2.24 and cedet version 1.0beta2b.
>
> I kept seeing an error about eldoc-message not being defined when 
> using ecb. I grep'ed ecb and cedet directories and found that 
> semantic-idle.el called this function, presumably during idle times. I 
> also grep'ed for a require to eldoc.el and found it in 
> semantic-grammar.el. This "require" in semantic-grammar.el, however, 
> was not enough to actually pull this function definition(presumably 
> the "require" was never called???). When I add a "require" for 
(Continue reading)

Oviedo, Javier | 6 May 2004 18:50

RE: Re[1]: ECB question....

I guess that I will use the code snippet that Klaus gave earlier...it is
working. Thanks.

 -------------
 Javier

-----Original Message-----
From: Eric M. Ludlam [mailto:eric <at> siege-engine.com] 
Sent: Thursday, May 06, 2004 12:08 PM
To: Oviedo, Javier
Cc: klaus.berndl <at> sdm.de; ecb-list <at> lists.sourceforge.net;
cedet-devel <at> lists.sourceforge.net
Subject: Re[1]: [CEDET-devel] ECB question....

>>> "Oviedo, Javier" <joviedo <at> telogy.com> seems to think that:
>
>> IMHO semantic should offer a mechanism to exclude major-modes and/or 
>> files
>(e.g. on a regexp-basis) from being > setup for semantic-parsing - even 
>if there is a parser available. Eric, David, what do you say??
>
>I agree. It would be quite useful.
  [ ... ]

There are several per-buffer startup issues of a similar natures I would
like to do near term.  For this particular problem in the short term, you
should probably just create your own derived mode with it's own hook so you
can do that disabling work more easily yourself.

Eric
(Continue reading)

Oviedo, Javier | 6 May 2004 19:55

RE: ECB/Semantic method buffer bug report


I turned on debug-on-error, but no backtrace was produced. I verified with a
"C-h v debug-on-error" that the value was set to true.

I have been grep'ing through semantic files and in the process the problem
is reproducing itself. I notice that it seems to happen periodically
coinciding with the following output from the *Message* buffer: (I had
semantic-imenu.el open)

Building semantic-edit.el Semantic directory index imenu [2 times]
Fontifying semantic-format.el... (regexps................)
Building semantic-imenu.el Semantic directory index imenu [2 times]
Building semantic-edit.el Semantic directory index imenu [2 times]

I had semantic-imenu.el open for some time, with the method buffer
displaying properly. Then all of a sudden it began "Building" the files
shown above. This has just happened to me while parsing several different
files....but the disappearnce of the methods seems to coincide with some
periodic "Building <insert-file-name-here> Semantic directory index imenu"
output in the *Message* buffer. 

Do these "Building ..." messages mean that the method buffer is being
rebuilt and displayed, even though it is already showing the buffers? My
data points seem kind of scattered, but the common theme seems to be some
sort of parsing/reparsing being done by semantic.

I'd like to put a "debug-on-entry" on a function, but I'm not sure where to
even begin. I will continue investigating. If anyone has any thoughts,
please chime in. Thanks.

(Continue reading)


Gmane