Thread: [cedet-semantic] XEmacs adjustments
Brought to you by:
zappo
From: Michael R. <re...@gm...> - 2008-11-26 19:41:05
|
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. 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: --- semantic/semantic-fw.el 10 Oct 2008 21:33:52 -0000 1.64 +++ semantic/semantic-fw.el 26 Nov 2008 19:04:51 -0000 @@ -393,7 +393,10 @@ FILE, NOWARN, RAWFILE, and WILDCARDS are ;; Disable revision control (vc-handled-backends nil) ) + (if (featurep 'xemacs) + (find-file-noselect file nowarn rawfile) (find-file-noselect file nowarn rawfile wildcards) + ) )) 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. 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. 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) Patch for illustration: --- semantic/semantic-decorate-include.el 27 Oct 2008 01:39:39 -0000 1.17 +++ semantic/semantic-decorate-include.el 26 Nov 2008 19:04:51 -0000 @@ -47,7 +47,8 @@ Used by the decoration style: `semantic- (defvar semantic-decoration-on-include-map (let ((km (make-sparse-keymap))) - (define-key km [ mouse-3 ] 'semantic-decoration-include-menu) +; (define-key km [ mouse-3 ] 'semantic-decoration-include-menu) + (define-key km [ button3 ] 'semantic-decoration-include-menu) km) "Keymap used on includes.") @@ -108,7 +109,8 @@ Used by the decoration style: `semantic- (defvar semantic-decoration-on-unknown-include-map (let ((km (make-sparse-keymap))) ;(define-key km [ mouse-2 ] 'semantic-decoration-unknown-include-describe) - (define-key km [ mouse-3 ] 'semantic-decoration-unknown-include-menu) +; (define-key km [ mouse-3 ] 'semantic-decoration-unknown-include-menu) + (define-key km [ button3 ] 'semantic-decoration-unknown-include-menu) km) "Keymap used on unparsed includes.") @@ -161,7 +163,8 @@ Used by the decoration style: `semantic- (defvar semantic-decoration-on-unparsed-include-map (let ((km (make-sparse-keymap))) - (define-key km [ mouse-3 ] 'semantic-decoration-unparsed-include-menu) +; (define-key km [ mouse-3 ] 'semantic-decoration-unparsed-include-menu) + (define-key km [ button3 ] 'semantic-decoration-unparsed-include-menu) km) "Keymap used on unparsed includes.") @@ -268,7 +271,7 @@ This mode provides a nice context menu o (semantic-tag-end tag) face)) ) - (semantic-overlay-put ol 'mouse-face 'region) + (semantic-overlay-put ol 'mouse-face 'highlight) (semantic-overlay-put ol 'keymap map) (semantic-overlay-put ol 'help-echo "Header File : mouse-3 - Context menu") 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.) Patch for illustration: --- semantic/semantic-ia.el 7 Oct 2008 01:50:52 -0000 1.25 +++ semantic/semantic-ia.el 26 Nov 2008 19:14:37 -0000 @@ -269,6 +269,7 @@ This helper manages the mark, buffer swi ;; 1) Push the mark, so you can pop global mark back, or ;; use semantic-mru-bookmark mode to do so. - (push-mark) + (push-tag-mark) ;; 2) Visits the tag. (semantic-go-to-tag dest) ;; 3) go-to-tag doesn't switch the buffer in the current window, 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. Allright, I think that's all for today :) Greets Michael |
From: Eric M. L. <er...@si...> - 2008-11-26 22:43:55
|
>>> Michael Reiher <re...@gm...> 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: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Michael R. <re...@gm...> - 2008-11-27 16:11:27
Attachments:
semantic.diff
|
On Wednesday 26 November 2008 22:38, you wrote: > >>> Michael Reiher <re...@gm...> 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 |
From: Michael R. <re...@gm...> - 2008-11-27 16:12:38
|
On Wednesday 26 November 2008 22:38, Eric M. Ludlam wrote: > >>> Michael Reiher <re...@gm...> 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 |
From: Eric M. L. <er...@si...> - 2008-11-27 18:02:47
|
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 <re...@gm...> seems to think that: >On Wednesday 26 November 2008 22:38, Eric M. Ludlam wrote: >> >>> Michael Reiher <re...@gm...> 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: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Michael R. <re...@gm...> - 2008-11-27 19:57:12
|
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 |
From: Eric M. L. <er...@si...> - 2008-11-28 02:42:31
|
>>> Michael Reiher <re...@gm...> seems to think that: >On Wednesday 26 November 2008 22:38, you wrote: >> >>> Michael Reiher <re...@gm...> 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: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Marcus H. <mar...@gm...> - 2008-11-28 11:57:53
|
Michael Reiher <re...@gm...> 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) |
From: Michael R. <re...@gm...> - 2008-11-28 15:26:53
Attachments:
semantic.diff
|
On Thursday 27 November 2008 17:11, Michael Reiher wrote: > On Wednesday 26 November 2008 22:38, you wrote: > > >>> Michael Reiher <re...@gm...> 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 |
From: Eric M. L. <er...@si...> - 2008-11-28 20:06:53
|
>>> Michael Reiher <re...@gm...> 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 <re...@gm...> 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: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Michael R. <re...@gm...> - 2008-11-29 12:00:37
|
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 |
From: Eric M. L. <er...@si...> - 2008-11-28 20:52:52
|
>>> Marcus Harnisch <mar...@gm...> seems to think that: >Michael Reiher <re...@gm...> 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: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |