Thread: [CEDET-devel] RE: ECB question....
Brought to you by:
zappo
From: Berndl, K. <kla...@sd...> - 2004-05-06 08:45:14
|
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 mode exists. In fact: semantic adds always in its elisp-code a setup-function to the hook XXX-mode-hook when a parser exists for the major-mode XXX-mode. There is no other way to avoid this besides modifying the related semantic file and removing the add-hook statement - at least AFAIK...but maybe the cedet- maintainer can help you better?! > > I would like to find a way to disable semantic parsing(or at least > stop the annoying red underlines all over the buffer), maintain the > association between the pseudo-c file and c-mode, and NOT deactivate > ecb. Can this be done? Can I have my cake and eat it too? :-) 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?? In the meanwhile you can disable the ummatched syntax-mode via adding to the c-mode-hook something like: (add-hook 'c-mode-hook (lambda () (if (string-match "<regexp which matches these special files" (buffer-file-name (current-buffer))) (semantic-show-unmatched-syntax-mode -1)))) This disables this unmatch-syntax-mode for your special files. > > Thanks for your time and help, Klaus. I'm totally loving this > package. You must have spent hundreds if not thousands of hours on > this. Thansk for your prasing ;-) > > > ------------- > Javier > > -----Original Message----- > From: Berndl, Klaus [mailto:kla...@sd...] > Sent: Thursday, April 29, 2004 11:52 AM > To: 'Oviedo, Javier' > Subject: RE: ECB question.... > > > Hi Javier > > Hi Klaus. Thanks for the quick response. > > This quite a package you have written here. You should be proud of > it. To be honest, I have avoided using it until recently because it > seemed a little intimidating...it looks so complex and I didn't > really have the time to sit and learn it. > > I can understand this but i have really spend a lot of work to make > ECB at easiest to install as possible and as easiest to start as > possible...because IMO one of the biggest disadvantages of Emasc is > that is often really quite complicated to install add-ons - > especially compared with Windows - where mostly running a setup.exe > is sufficient. XEmacs and its packaging-system is a lot of better > than GNU Emacs but still not good enough. > > With ECB you can even upgrade to newer versions by calling > `ecb-upgrade-ecb' - if you are connected to the internet this will > auto. check if there are new versiosn available and then download and > install the newest one. All what you have to do is to add the new > ECB-dir to the load-path and restart Emacs. ECB will autom. check if > your customized ECB-options are still compatible with the new version > and if not auto. upgrade your settings to the new-option-types or > names - if you are interested in the full story of this topic read > the detailed comment at beginning of ecb-upgrade.el! > > IMHO if Emacs wants to survive or wants to get more users coming from > a window-world it must be get more user-friendly - ECB is my try to > accomplish this...at least it is a try ;-) > > But finally yesterday I "broke down" and decided that I must face my > fears. :-) You are really brave :-) I'm quite glad that I did. I am > really, really enjoying the features you provide. I am reading the > help/manual cover to cover and over the next few days I will begin to > really customize it for my needs. > > Fine - i give you an extra coin because you are one of the very few > people who do with manual for what it was written ;-) > > I have already started by creating my own layout. > > Cool :-) > > ...but I digress. :-) > > no problem, such a digress i really can accept ;-) > > I think wb-line-number is posted on the lisp list, but to be honest I > can't remember where I got it from. Please find the file attached. > > I will investigate next week.... > > Another quick question if you don't mind: Should I copy all > ecb/semantic/eieio/etc .el files to one common directory and then > byte-compile them of should I include each individual path in my > load-path(and then byte compile). I'd like to find the easiest way > for me to take future updates but still have an easy way to > byte-compile and track down source files.. > > I strongly recommend not to do this, ie. do NOT copy all el files of > these differebnt packages in one big directory!!! In general it is > wise to preserve the subdir-sturcture of a package!! > > I recommend you to download the latest cedet-suite (cedet1.0beta2b > IIRC) which contains much better semantic, eieio etc.) and install it > in a separate dir. Then just read the INSTALL-file in the topdir of > this suite which will take about 2 minutes. Then just call "make" and > bob will be your uncle! > > same for ECB: Install it in a separate dir and read the File README > for installation instructions - but obviously you have already done > this ;-) Both cedet-suite and ECB are byte-compileable by a simple > "make" and nothing more. Even more easier you can byte-compile ECB > from within Emacs with an own command. Just install ECB, add the > ECB-install-dir to your load-path, restart Emacs and call > `ecb-byte-compile' - Voilà - thats all! > > Does this help you? > Klaus > > Thanks again! I'll be checking gnu.emacs.sources for ecb updates from > now on. Take care. > > ------------- > Javier > > -----Original Message----- > From: Berndl, Klaus [mailto:kla...@sd...] > Sent: Thursday, April 29, 2004 11:22 AM > To: 'Oviedo, Javier' > Subject: RE: ECB question.... > > > Hi Javier, > Hello Klaus, > It seems that I have found the source of my issue...or at least I > believe I have. I was loading a package called wb-line-number. This > package has a series of defadvices that I believe may be conflicting > with ECB. If I no longer "require" this package, I stop seeing the > strange behavior (at least so far). I will tell over time if this > really fixes what I saw. If so then I will simply no longer use that > package...though it would be nice if I could, but I like ECB too much > to give it up. :-) > wb-line-number has defadvice for the following functions: > other-window > delete-other-windows > delete-window > delete-windows-on > execute-kbd-macro > call-last-kbd-macro > switch-to-buffer > delete-frame > one-window-p > pop-to-buffer > I wish all ECB-users would write such bug-reports like you ;-) This > is a wunderful and great track-down of the problem - Without knowing > this wb-line-number.el package i can say with about 99,99% sureness > that this is the reason, because ECB also advices a lot of this > functions. Es suppose that especially the advice of switch-to-buffer, > one-window-p and pop-to-buffer of this library are responsible for > the strange behavior you saw. > > Ok, where can i get this library (or can you send me a version?) so i > can try to make ECB compatible with this lib (but IMHO ECB does > nothing which should break other packages so maybe this lib should be > enhanced to be more compatible - but we will see......) > > Thanks for the report and your efforts! > Klaus > > > Thanks. > ------------- > Javier Hi! |
From: Oviedo, J. <jo...@te...> - 2004-05-06 13:28:58
|
> IMHO semantic should offer a mechanism to exclude major-modes and/or fi= les (e.g. on a regexp-basis) from being > setup for semantic-parsing - even i= f there is a parser available. Eric, David, what do you say?? I agree. It would be quite useful. Thanks. ------------- Javier =20 -----Original Message----- From: Berndl, Klaus [mailto:kla...@sd...]=20 Sent: Thursday, May 06, 2004 4:45 AM To: 'Oviedo, Javier'; ecb...@li...; ced...@li... Subject: RE: ECB question.... Hi Javier, Eric, david: Oviedo, Javier wrote: > Hello Klaus. I've run come across an interesting scenario that I=20 > thought you could help me with. >=20 > We have an internal programming language that is a pseudo C type of=20 > language. Very similar but not the same. In any case, since they are=20 > so similar, I have the associated file type set to open the buffer in=20 > c-mode. Now the problem...since file is not really in true C syntax,=20 > semantic displays most of the file in the=20 > semantic-unmatched-syntax-face. This is very annoying to look at. :-) Yes, i can imagine ;-) >=20 > I've gone through the manual looking for a way to disable this on a=20 > file by file basis. So far I've only found a way to disable the=20 > semantic parsing on a mode basis using ecb-non-semantic-exclude-modes.=20 > I tried using a defalias of c-mode and adding that defalias to the=20 > excluded modes, but that didn't > work...given that defalias will return c-mode. =20 `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 n= o way in ECB to exclude modes from being parsed by semantic if for such a m= ode 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 mode exists. In fact: semantic adds always in its elisp-code a setup-function = to the hook XXX-mode-hook when a parser exists for the major-mode XXX-mode. There is no other way to avoid this besides modifying the related semanti= c file and removing the=20 add-hook statement - at least AFAIK...but maybe the cedet- maintainer can help you better?! >=20 > I would like to find a way to disable semantic parsing(or at least=20 > stop the annoying red underlines all over the buffer), maintain the=20 > association between the pseudo-c file and c-mode, and NOT deactivate > ecb. Can this be done? Can I have my cake and eat it too? :-) =20 IMHO semantic should offer a mechanism to exclude major-modes and/or file= s (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?? In the meanwhile you can disable the ummatched syntax-mode via adding to = the c-mode-hook something like: (add-hook 'c-mode-hook (lambda () (if (string-match "<regexp which matches these special files= " (buffer-file-name (current-buffer))) (semantic-show-unmatched-syntax-mode -1)))) This disables this unmatch-syntax-mode for your special files. >=20 > Thanks for your time and help, Klaus. I'm totally loving this package.=20 > You must have spent hundreds if not thousands of hours on this. Thansk for your prasing ;-) >=20 >=20 > ------------- > Javier >=20 > -----Original Message----- > From: Berndl, Klaus [mailto:kla...@sd...] > Sent: Thursday, April 29, 2004 11:52 AM > To: 'Oviedo, Javier' > Subject: RE: ECB question.... >=20 >=20 > Hi Javier >=20 > Hi Klaus. Thanks for the quick response. >=20 > This quite a package you have written here. You should be proud of it.=20 > To be honest, I have avoided using it until recently because it seemed=20 > a little intimidating...it looks so complex and I didn't > really have the time to sit and learn it. =20 >=20 > I can understand this but i have really spend a lot of work to make=20 > ECB at easiest to install as possible and as easiest to start as=20 > possible...because IMO one of the biggest disadvantages of Emasc is=20 > that is often really quite complicated to install add-ons - especially=20 > compared with Windows - where mostly running a setup.exe is=20 > sufficient. XEmacs and its packaging-system is a lot of better > than GNU Emacs but still not good enough. =20 >=20 > With ECB you can even upgrade to newer versions by calling=20 > `ecb-upgrade-ecb' - if you are connected to the internet this will=20 > auto. check if there are new versiosn available and then download and=20 > install the newest one. All what you have to do is to add the new=20 > ECB-dir to the load-path and restart Emacs. ECB will autom. check if=20 > your customized ECB-options are still compatible with the new version=20 > and if not auto. upgrade your settings to the new-option-types or=20 > names - if you are interested in the full story of this topic read > the detailed comment at beginning of ecb-upgrade.el! =20 >=20 > IMHO if Emacs wants to survive or wants to get more users coming from=20 > a window-world it must be get more user-friendly - ECB is my try to=20 > accomplish this...at least it is a try ;-) >=20 > But finally yesterday I "broke down" and decided that I must face my=20 > fears. :-) You are really brave :-) I'm quite glad that I did. I am=20 > really, really enjoying the features you provide. I am reading the=20 > help/manual cover to cover and over the next few days I will begin to > really customize it for my needs. =20 >=20 > Fine - i give you an extra coin because you are one of the very few=20 > people who do with manual for what it was written ;-) >=20 > I have already started by creating my own layout. >=20 > Cool :-) >=20 > ...but I digress. :-) >=20 > no problem, such a digress i really can accept ;-) >=20 > I think wb-line-number is posted on the lisp list, but to be honest I=20 > can't remember where I got it from. Please find the file attached. >=20 > I will investigate next week.... >=20 > Another quick question if you don't mind: Should I copy all=20 > ecb/semantic/eieio/etc .el files to one common directory and then=20 > byte-compile them of should I include each individual path in my=20 > load-path(and then byte compile). I'd like to find the easiest way for=20 > me to take future updates but still have an easy way to > byte-compile and track down source files.. =20 >=20 > I strongly recommend not to do this, ie. do NOT copy all el files of=20 > these differebnt packages in one big directory!!! In general it is=20 > wise to preserve the subdir-sturcture of a package!! >=20 > I recommend you to download the latest cedet-suite (cedet1.0beta2b > IIRC) which contains much better semantic, eieio etc.) and install it=20 > in a separate dir. Then just read the INSTALL-file in the topdir of=20 > this suite which will take about 2 minutes. Then just call "make" and > bob will be your uncle! =20 >=20 > same for ECB: Install it in a separate dir and read the File README=20 > for installation instructions - but obviously you have already done=20 > this ;-) Both cedet-suite and ECB are byte-compileable by a simple=20 > "make" and nothing more. Even more easier you can byte-compile ECB=20 > from within Emacs with an own command. Just install ECB, add the=20 > ECB-install-dir to your load-path, restart Emacs and call > `ecb-byte-compile' - Voil=E0 - thats all! =20 >=20 > Does this help you? > Klaus >=20 > Thanks again! I'll be checking gnu.emacs.sources for ecb updates from=20 > now on. Take care. >=20 > ------------- > Javier >=20 > -----Original Message----- > From: Berndl, Klaus [mailto:kla...@sd...] > Sent: Thursday, April 29, 2004 11:22 AM > To: 'Oviedo, Javier' > Subject: RE: ECB question.... >=20 >=20 > Hi Javier, > Hello Klaus, > It seems that I have found the source of my issue...or at least I=20 > believe I have. I was loading a package called wb-line-number. This=20 > package has a series of defadvices that I believe may be conflicting=20 > with ECB. If I no longer "require" this package, I stop seeing the=20 > strange behavior (at least so far). I will tell over time if this=20 > really fixes what I saw. If so then I will simply no longer use that=20 > package...though it would be nice if I could, but I like ECB too much > to give it up. :-) =20 > wb-line-number has defadvice for the following functions: other-window > delete-other-windows > delete-window > delete-windows-on > execute-kbd-macro > call-last-kbd-macro > switch-to-buffer > delete-frame > one-window-p > pop-to-buffer > I wish all ECB-users would write such bug-reports like you ;-) This > is a wunderful and great track-down of the problem - Without knowing > this wb-line-number.el package i can say with about 99,99% sureness > that this is the reason, because ECB also advices a lot of this > functions. Es suppose that especially the advice of switch-to-buffer, > one-window-p and pop-to-buffer of this library are responsible for > the strange behavior you saw. =20 >=20 > Ok, where can i get this library (or can you send me a version?) so i=20 > can try to make ECB compatible with this lib (but IMHO ECB does=20 > nothing which should break other packages so maybe this lib should be > enhanced to be more compatible - but we will see......) =20 >=20 > Thanks for the report and your efforts! > Klaus >=20 >=20 > Thanks. > ------------- > Javier Hi! |
From: Eric M. L. <er...@si...> - 2004-05-06 16:08:12
|
>>> "Oviedo, Javier" <jo...@te...> 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: za...@gn..., er...@si... Home: http://www.ludlam.net Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: David P. <dav...@wa...> - 2004-05-07 19:32:26
|
Hi Eric, >>>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. What do you think of the following? It is simple and permits to use any kind of heuristics to inhibit Semantic (buffer name, major mode, buffer size, etc.). David (defcustom semantic-inhibit-functions nil "List of functions to call with no arguments before to setup Semantic. If any of these functions returns non-nil, the current buffer is not setup to use Semantic." :group 'semantic :type 'hook) (defun semantic-new-buffer-fcn () "Setup the current buffer to use Semantic. If the major mode is ready for Semantic, and no `semantic-inhibit-functions' disabled it, the current buffer is setup to use Semantic, and `semantic-init-hook' is run." ;; Do stuff if semantic was activated by a mode hook in this buffer, ;; and not afterwards disabled. (when (and semantic--parse-table (not (run-hook-with-args-until-success 'semantic-inhibit-functions))) ;; Force this buffer to have its cache refreshed. (semantic-clear-toplevel-cache) ;; Here are some buffer local variables we can initialize ourselves ;; of a mode does not choose to do so. (semantic-lex-init) ;; Setup for a needed reparse. (semantic-parse-tree-set-needs-rebuild) ;; Specify that this function has done it's work. (setq semantic-new-buffer-fcn-was-run t) ;; Call DB hooks before regular init hooks (run-hooks 'semantic-init-db-hooks) ;; Lastly, set up semantic modes (run-hooks 'semantic-init-hooks) )) ;;; Example that inhibits semantic in buffers whose name contains "test" ;; (add-hook 'semantic-inhibit-functions '(lambda () (or (string-match "test" (buffer-name))))) |
From: Eric M. L. <er...@si...> - 2004-05-08 01:11:40
|
David, This is a grand solution for this aspect of the problem. Bravo! Please check it in. Eric >>> David Ponce <dav...@wa...> seems to think that: >Hi Eric, > > >>>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. > >What do you think of the following? It is simple and permits to use >any kind of heuristics to inhibit Semantic (buffer name, major mode, >buffer size, etc.). > >David > >(defcustom semantic-inhibit-functions nil > "List of functions to call with no arguments before to setup Semantic. >If any of these functions returns non-nil, the current buffer is not >setup to use Semantic." > :group 'semantic > :type 'hook) > >(defun semantic-new-buffer-fcn () > "Setup the current buffer to use Semantic. >If the major mode is ready for Semantic, and no >`semantic-inhibit-functions' disabled it, the current buffer is setup >to use Semantic, and `semantic-init-hook' is run." > ;; Do stuff if semantic was activated by a mode hook in this buffer, > ;; and not afterwards disabled. > (when (and semantic--parse-table > (not (run-hook-with-args-until-success > 'semantic-inhibit-functions))) > ;; Force this buffer to have its cache refreshed. > (semantic-clear-toplevel-cache) > ;; Here are some buffer local variables we can initialize ourselves > ;; of a mode does not choose to do so. > (semantic-lex-init) > ;; Setup for a needed reparse. > (semantic-parse-tree-set-needs-rebuild) > ;; Specify that this function has done it's work. > (setq semantic-new-buffer-fcn-was-run t) > ;; Call DB hooks before regular init hooks > (run-hooks 'semantic-init-db-hooks) > ;; Lastly, set up semantic modes > (run-hooks 'semantic-init-hooks) > )) > >;;; Example that inhibits semantic in buffers whose name contains "test" >;; >(add-hook 'semantic-inhibit-functions > '(lambda () > (or (string-match "test" (buffer-name))))) > |
From: David P. <dav...@wa...> - 2004-05-08 07:52:58
|
Hi Eric, > This is a grand solution for this aspect of the problem. Bravo! Thanks! > Please check it in. Done. David |