CEDET

>>> Michael Reiher <redm@...> seems to think that:
>Hi Eric
>
>I have a few small adjustments for XEmacs sitting on my disc for a while now. 
>And I thought I might tell you, so you can add them to CVS somehow.

Excellent.  Last time I tried to put a new distribution together, I
couldn't get it to test on XEmacs, and eventually gave up.  This
should help.

>The first this is in semantic-fw.el: semantic-find-file-noselect:
>
>XEmacs' find-file-noselect has only 3 parameters, so I get an error about 
>wrong number of arguments (being 4). The wildcards parameter GNU Emacs has, 
>is missing in XEmacs.
>
>Patch for illustration:
  [ ... ]

Thanks.  I'll do that.

>
>The other issues are in semantic-decorate-include.el:
>
>First it uses a face "region" for highlighting includes, which doesn't exist 
>in XEmacs and gives an error. I'd suggest to use "highlight" instead. It 
>seems fitting and exists in both GNU Emacs and XEmacs.

Good idea, thanks.

>Another (less important) thing here is, that it uses mouse-3 for for the right 
>mouse button, which doesn't exist in XEmacs. It's called button3 there.

Thanks for the info.

>Then semantic-decoration-include-menu even seems to be called, however 
>something is wrong about the argument.
>
>Debugger entered--Lisp error: (wrong-type-argument listp #<buttondown-event 
>button3>)
>  semantic-decoration-include-menu(#<buttondown-event button3>)
>  call-interactively(semantic-decoration-include-menu)
  [ ... ]

In Emacs, the event is a list.  Presumably in XEmacs it is some custom
lisp object?  Is there an API for extracting the window from an event
in XEmacs?

>Something else, not specific to XEmacs: I use push-tag-mark to save positions 
>when jumping. This works quite well for jumping backwards. Maybe you might 
>want to add it as well. (The push-mark mechanism is IMHO pointless in this 
>case. And mru-bookmark-mode, while looking promising, I found it not to be 
>really efficiently usable.)

You can pop the global mark to go back from where you came.  The tag
mark seems like a fine idea too.  Emacs does not have a fcn to do that
other than the raw ring-insert.

  [ ... ]
>
>Oh, on a related note: in semantic-ia--fast-jump-heper (I guess there is an 
>"l" missing? ;) there is a comment:
>
>  ;; We have a tag, but in C++, we usually get a prototype instead
>  ;; because of header files.  Lets try to find the actual
>  ;; implementaion instead.
>
>Is this supposed to be working? Because it doesn't for me... :) Would be great 
>to have though. It always jumps to the prototype i.e. the .h file. Even when 
>the implementation is actually in the same .cpp file.
  [ ... ]

Yes, that is supposed to be working.  If the file with the
implementation in it has never been parsed, then the fast-jump feature
won't be able to find it.  You can solve this by pre-parsing your
files.  There is a semanticdb.sh script that can do that for
you... though upon investigation I should re-write bits of it.

Fortunately for everyone, I'm partway through getting GNU Global
hooked in, so this type of thing should be more easily solvable.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

On Wednesday 26 November 2008 22:38, you wrote:
> >>> Michael Reiher <redm@...> seems to think that:

> >Then semantic-decoration-include-menu even seems to be called, however
> >something is wrong about the argument.
> >
> >Debugger entered--Lisp error: (wrong-type-argument listp
> > #<buttondown-event button3>)
> >  semantic-decoration-include-menu(#<buttondown-event button3>)
> >  call-interactively(semantic-decoration-include-menu)
>
>   [ ... ]
>
> In Emacs, the event is a list.  Presumably in XEmacs it is some custom
> lisp object?  Is there an API for extracting the window from an event
> in XEmacs?

I found (event-window EVENT). Using this makes it work. Then however there is 
a problem with the menu definition. The keywords :visible and :help don't 
exist in XEmacs. Removing them makes the menu show up and it mostly seems to 
work even :)

Just actions which require the point to be in the #include line ("What Is 
This?", "Visit This Include" and "Parse This Include") have a little problem. 
I have to move the cursor manually into the #include line, otherwise I get 
errors. I guess that's what (mouse-set-point event) is supposed to take care 
off? So maybe this is an XEmacs bug ...

I attached a patch with what I did to make it work with XEmacs so far. You'll 
probably want to change it to make it work with both Emacs and XEmacs, and 
not have too much duplication. How to do that best is a bit above my elisp 
programming "skills" ;)

>
> >Something else, not specific to XEmacs: I use push-tag-mark to save
> > positions when jumping. This works quite well for jumping backwards.
> > Maybe you might want to add it as well. (The push-mark mechanism is IMHO
> > pointless in this case. And mru-bookmark-mode, while looking promising, I
> > found it not to be really efficiently usable.)
>
> You can pop the global mark to go back from where you came.
Hmm, it's been a while ... but IIRC the push-mark mechanism has some problems 
in principle. It only saves one mark per buffer, so you can't jump back via 
several places within the same buffer. Also lots of other marks, which have 
nothing to do with jumping, "pollute" the global mark ring and thus interfere 
with jumping. Which in turn made it practically useless for me, as far as 
jumping (back) is concerned.
 
> The tag 
> mark seems like a fine idea too.  Emacs does not have a fcn to do that
> other than the raw ring-insert.
You mean Emacs has no push-tag-mark function? It has pop-tag-mark though .. 
interesting ... :)


Greets 

Michael

On Wednesday 26 November 2008 22:38, Eric M. Ludlam wrote:
> >>> Michael Reiher <redm@...> seems to think that:

Separating this into a separate topic ...

> >Oh, on a related note: in semantic-ia--fast-jump-heper (I guess there is
> > an "l" missing? ;) there is a comment:
> >
> >  ;; We have a tag, but in C++, we usually get a prototype instead
> >  ;; because of header files.  Lets try to find the actual
> >  ;; implementaion instead.
> >
> >Is this supposed to be working? Because it doesn't for me... :) Would be
> > great to have though. It always jumps to the prototype i.e. the .h file.
> > Even when the implementation is actually in the same .cpp file.
>
>   [ ... ]
>
> Yes, that is supposed to be working.  If the file with the
> implementation in it has never been parsed, then the fast-jump feature
> won't be able to find it.  You can solve this by pre-parsing your
> files.  There is a semanticdb.sh script that can do that for
> you... though upon investigation I should re-write bits of it.
>
Hmm, as far as I can see the files have been parsed. At least there is 
meaningful information in the cache file.
Still this little example (below) fails to work. When I move the curser over 
bbb in main.cpp:main() and call semantic-ia-fast-jump, it happily jumps to 
the header file, as it always did :) But not to the implementation in 
main.cpp (nor if I put it into a separate foo.cpp).

---- main.cpp ------
#include "foo.h"

int Foo::bbb( const char* y )
{

}

int main(int argc, char **argv )
{
  Foo* bar;
  bar->bbb( ccc );
}

---- foo.h ---------
class Foo
{
public:
  Foo();
  ~Foo();

  int bbb( const char* y );
};

Greets 

Michael

Hi,

  Apparently I had done all my testing with either no namespaces, or
namespaces 2 deep or more.  I checked in a fix for this bug.

Eric

>>> Michael Reiher <redm@...> seems to think that:
>On Wednesday 26 November 2008 22:38, Eric M. Ludlam wrote:
>> >>> Michael Reiher <redm@...> seems to think that:
>
>Separating this into a separate topic ...
>
>> >Oh, on a related note: in semantic-ia--fast-jump-heper (I guess there is
>> > an "l" missing? ;) there is a comment:
>> >
>> >  ;; We have a tag, but in C++, we usually get a prototype instead
>> >  ;; because of header files.  Lets try to find the actual
>> >  ;; implementaion instead.
>> >
>> >Is this supposed to be working? Because it doesn't for me... :) Would be
>> > great to have though. It always jumps to the prototype i.e. the .h file.
>> > Even when the implementation is actually in the same .cpp file.
>>
>>   [ ... ]
>>
>> Yes, that is supposed to be working.  If the file with the
>> implementation in it has never been parsed, then the fast-jump feature
>> won't be able to find it.  You can solve this by pre-parsing your
>> files.  There is a semanticdb.sh script that can do that for
>> you... though upon investigation I should re-write bits of it.
>>
>Hmm, as far as I can see the files have been parsed. At least there is 
>meaningful information in the cache file.
>Still this little example (below) fails to work. When I move the curser over 
>bbb in main.cpp:main() and call semantic-ia-fast-jump, it happily jumps to 
>the header file, as it always did :) But not to the implementation in 
>main.cpp (nor if I put it into a separate foo.cpp).
>
>---- main.cpp ------
>#include "foo.h"
>
>int Foo::bbb( const char* y )
>{
>
>}
>
>int main(int argc, char **argv )
>{
>  Foo* bar;
>  bar->bbb( ccc );
>}
>
>---- foo.h ---------
>class Foo
>{
>public:
>  Foo();
>  ~Foo();
>
>  int bbb( const char* y );
>};
  [ ... ]

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

On Thursday 27 November 2008 19:02, Eric M. Ludlam wrote:
> Hi,
>
>   Apparently I had done all my testing with either no namespaces, or
> namespaces 2 deep or more.  I checked in a fix for this bug.
>
> Eric
>
Awesome, it works now! I have wished for something like that so for long. You 
are my hero of the week! :)

Greets

Michael

>>> Michael Reiher <redm@...> seems to think that:
>On Wednesday 26 November 2008 22:38, you wrote:
>> >>> Michael Reiher <redm@...> seems to think that:
  [ ... ]
>I found (event-window EVENT). Using this makes it work. Then however there is 
>a problem with the menu definition. The keywords :visible and :help don't 
>exist in XEmacs. Removing them makes the menu show up and it mostly seems to 
>work even :)
>
>Just actions which require the point to be in the #include line ("What Is 
>This?", "Visit This Include" and "Parse This Include") have a little problem. 
>I have to move the cursor manually into the #include line, otherwise I get 
>errors. I guess that's what (mouse-set-point event) is supposed to take care 
>off? So maybe this is an XEmacs bug ...
>
>I attached a patch with what I did to make it work with XEmacs so far. You'll 
>probably want to change it to make it work with both Emacs and XEmacs, and 
>not have too much duplication. How to do that best is a bit above my elisp 
>programming "skills" ;)
  [ ... ]

I've checked in a range of fixes related to your patch, and got them
to be Emacs friendly.  It turns out that senator had some
infrastructure for the menu stuff already, so I adapted that.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Michael Reiher <redm@...> writes:

> First it uses a face "region" for highlighting includes, which
> doesn't exist in XEmacs and gives an error. I'd suggest to use
> "highlight" instead. It seems fitting and exists in both GNU Emacs
> and XEmacs.

FWIW, I raised that issue on xemacs-beta a couple of weeks ago.

http://thread.gmane.org/gmane.emacs.xemacs.beta/28650

We should perhaps maintain a list of Emacs standard faces in the
fsf-compat package.

But if Eric is fine changing this, I surely won't object ;)

Regards
Marcus

-- 
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

             (seen on http://www.veripool.com/verilog-mode_news.html)

On Thursday 27 November 2008 17:11, Michael Reiher wrote:
> On Wednesday 26 November 2008 22:38, you wrote:
> > >>> Michael Reiher <redm@...> seems to think that:
> > >
> > >Then semantic-decoration-include-menu even seems to be called, however
> > >something is wrong about the argument.
> > >
> > >Debugger entered--Lisp error: (wrong-type-argument listp
> > > #<buttondown-event button3>)
> > >  semantic-decoration-include-menu(#<buttondown-event button3>)
> > >  call-interactively(semantic-decoration-include-menu)
> >
> >   [ ... ]
> >
> > In Emacs, the event is a list.  Presumably in XEmacs it is some custom
> > lisp object?  Is there an API for extracting the window from an event
> > in XEmacs?
>
> I found (event-window EVENT). Using this makes it work. Then however there
> is a problem with the menu definition. The keywords :visible and :help
> don't exist in XEmacs. Removing them makes the menu show up and it mostly
> seems to work even :)
>
> Just actions which require the point to be in the #include line ("What Is
> This?", "Visit This Include" and "Parse This Include") have a little
> problem. I have to move the cursor manually into the #include line,
> otherwise I get errors. I guess that's what (mouse-set-point event) is
> supposed to take care off? So maybe this is an XEmacs bug ...
>
Hmm, the cause for this problem is the save-excursion around mouse-set-point 
and popup-menu in e.g. semantic-decoration-include-menu. Or maybe actually 
that popup-menu in XEmacs returns right after showing the menu, in contrast 
to Emacs where it waits until the user selected an entry (just guessing)? 
Anyway, with XEmacs the point position is already restored to the original 
position when the user eventually selects an entry => error.

So AFAICS a solution might be: instead of setting the point right away, just 
save the position and set the point to the saved position in the function the 
user selected e.g. semantic-decoration-include-describe.

I tried this and it works fine for me. I attached a patch for illustration 
(it's probably far from perfect;).

NOTE: In the menu definition of semantic-decoration-on-unknown-include-menu 
you had a :Help instead of :help. See patch.

Greets

Michael

>>> Michael Reiher <redm@...> seems to think that:
>On Thursday 27 November 2008 17:11, Michael Reiher wrote:
>> On Wednesday 26 November 2008 22:38, you wrote:
>> > >>> Michael Reiher <redm@...> seems to think that:
>> > >
>> > >Then semantic-decoration-include-menu even seems to be called, however
>> > >something is wrong about the argument.
>> > >
>> > >Debugger entered--Lisp error: (wrong-type-argument listp
>> > > #<buttondown-event button3>)
>> > >  semantic-decoration-include-menu(#<buttondown-event button3>)
>> > >  call-interactively(semantic-decoration-include-menu)
>> >
>> >   [ ... ]
>> >
>> > In Emacs, the event is a list.  Presumably in XEmacs it is some custom
>> > lisp object?  Is there an API for extracting the window from an event
>> > in XEmacs?
>>
>> I found (event-window EVENT). Using this makes it work. Then however there
>> is a problem with the menu definition. The keywords :visible and :help
>> don't exist in XEmacs. Removing them makes the menu show up and it mostly
>> seems to work even :)
>>
>> Just actions which require the point to be in the #include line ("What Is
>> This?", "Visit This Include" and "Parse This Include") have a little
>> problem. I have to move the cursor manually into the #include line,
>> otherwise I get errors. I guess that's what (mouse-set-point event) is
>> supposed to take care off? So maybe this is an XEmacs bug ...
>>
>Hmm, the cause for this problem is the save-excursion around mouse-set-point 
>and popup-menu in e.g. semantic-decoration-include-menu. Or maybe actually 
>that popup-menu in XEmacs returns right after showing the menu, in contrast 
>to Emacs where it waits until the user selected an entry (just guessing)? 
>Anyway, with XEmacs the point position is already restored to the original 
>position when the user eventually selects an entry => error.
>
>So AFAICS a solution might be: instead of setting the point right away, just 
>save the position and set the point to the saved position in the function the 
>user selected e.g. semantic-decoration-include-describe.
>
>I tried this and it works fine for me. I attached a patch for illustration 
>(it's probably far from perfect;).
>
>NOTE: In the menu definition of semantic-decoration-on-unknown-include-menu 
>you had a :Help instead of :help. See patch.

Howdy,

  Thanks for pointing this out.  I was a little worried about the
state your patch had to move around, but it clued me in that the
popup-menu wasn't blocking in XEmacs.

  I made a blocking version and alias for the two Emacsen, and used
that.  It worked in a XEmacs demo I wrote, but I haven't tested it in
Semantic yet.  Hopefully what I checked in will do what you need.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

>>> Marcus Harnisch <marcus.harnisch@...> seems to think that:
>Michael Reiher <redm@...> writes:
>
>> First it uses a face "region" for highlighting includes, which
>> doesn't exist in XEmacs and gives an error. I'd suggest to use
>> "highlight" instead. It seems fitting and exists in both GNU Emacs
>> and XEmacs.
>
>FWIW, I raised that issue on xemacs-beta a couple of weeks ago.
>
>http://thread.gmane.org/gmane.emacs.xemacs.beta/28650
>
>We should perhaps maintain a list of Emacs standard faces in the
>fsf-compat package.
>
>But if Eric is fine changing this, I surely won't object ;)
  [ ... ]

I'm not too picky about this sort of thing so long as it works. :)  Any
help I can get to make things work in XEmacs is appreciated.

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

On Friday 28 November 2008 21:06, Eric M. Ludlam wrote:
> Howdy,
>
>   Thanks for pointing this out.  I was a little worried about the
> state your patch had to move around, but it clued me in that the
> popup-menu wasn't blocking in XEmacs.
Yep, that was not exactly elegant... but I was lacking a better idea :)

>
>   I made a blocking version and alias for the two Emacsen, and used
> that.  It worked in a XEmacs demo I wrote, but I haven't tested it in
> Semantic yet.  Hopefully what I checked in will do what you need.
Yep, works perfectly, I would say! Thanks!

Greets

Michael