Thread: [CEDET-devel] cpp-root project related fixes
Brought to you by:
zappo
From: Tomasz G. <to...@wp...> - 2012-12-29 22:12:26
|
I've been trying to run 'ede-rescan-toplevel' on a cpp-root project and experienced some errors. I've managed to fix them just to find out that this method is not implemented for this project type. Sadly, even now, I don't know what this method is supposed to do (I thought that this will make ede to scan for files inside cpp root project directory and allow me to use 'ede-find-file' to open them). Anyway I think those fixes (at least first part of them) are ok so I share them with you. Following part changes :file and :class-sym for cpp-root and java-root (not tested but seems to be cloned from cpp-root earlier) to make them consistent with other projects. :file change makes the test: (when (and (featurep (oref this file)) in 'ede-dir-to-projectfile' in lisp/cedet/ede/auto.el pass (I think there is an assumption that project files should 'provide' exactly what is in autoload :file field). :class-sym change fixes test: (and (object-of-class-p ;; Same as class for this dir? ans (oref thisdir :class-sym))) in 'ede-toplevel-project' in lisp/cedet/ede/files.el. === modified file 'lisp/cedet/ede/cpp-root.el' --- lisp/cedet/ede/cpp-root.el 2012-12-10 15:52:10 +0000 +++ lisp/cedet/ede/cpp-root.el 2012-12-29 21:39:35 +0000 @@ -242,11 +242,11 @@ (ede-add-project-autoload (ede-project-autoload "cpp-root" :name "CPP ROOT" - :file 'ede-cpp-root + :file 'ede/cpp-root :proj-file 'ede-cpp-root-project-file-for-dir :proj-root 'ede-cpp-root-project-root :load-type 'ede-cpp-root-load - :class-sym 'ede-cpp-root + :class-sym 'ede-cpp-root-project :new-p nil :safe-p t) ;; When a user creates one of these, it should override any other project @@ -377,7 +377,7 @@ (when (or (not (file-exists-p f)) (file-directory-p f)) (delete-instance this) - (error ":file for ede-cpp-root must be a file")) + (error ":file for ede-cpp-root-project must be a file")) (oset this :file f) (oset this :directory (file-name-directory f)) (ede-project-directory-remove-hash (file-name-directory f)) === modified file 'lisp/cedet/ede/java-root.el' --- lisp/cedet/ede/java-root.el 2012-12-17 12:32:52 +0000 +++ lisp/cedet/ede/java-root.el 2012-12-29 21:39:42 +0000 @@ -199,11 +199,11 @@ (ede-add-project-autoload (ede-project-autoload "java-root" :name "JAVA ROOT" - :file 'ede-java-root + :file 'ede/java-root :proj-file 'ede-java-root-project-file-for-dir :proj-root 'ede-java-root-project-root :load-type 'ede-java-root-load - :class-sym 'ede-java-root + :class-sym 'ede-java-root-project :new-p nil :safe-p t) ;; When a user creates one of these, it should override any other project @@ -296,7 +296,7 @@ (when (or (not (file-exists-p f)) (file-directory-p f)) (delete-instance this) - (error ":file for ede-java-root must be a file")) + (error ":file for ede-java-root-project must be a file")) (oset this :file f) (oset this :directory (file-name-directory f)) (ede-project-directory-remove-hash (file-name-directory f)) I've made another change of which I'm not so confident of. I've changed condition to match more the description and my version worked ok for cpp-root project. I've found out that dirmatch initial value was changed to "" (empty string) in almost the same time as this condition was added and comment by two different persons (IIRC Alex and Eric) and probably this condition assumed that for projects that do not set dirmatch the default value is nil. What I don't understand is the presence of 'root' in condition so I didn't know where to move it. === modified file 'lisp/cedet/ede/auto.el' --- lisp/cedet/ede/auto.el 2012-10-07 12:07:12 +0000 +++ lisp/cedet/ede/auto.el 2012-12-29 20:33:50 +0000 @@ -311,10 +311,10 @@ ;; other EDE projects. This happens if the file is ;; already loaded, or if there is a dirmatch, but ;; root is empty. - (when (and (featurep (oref this file)) - (or (not (stringp dm)) - (not (string= dm ""))) - root) + (when (or (featurep (oref this file)) + (and (or (not (stringp dm)) + (not (string= dm ""))) + root)) (funcall pf (or root d)))))) ) (when (and f (file-exists-p f)) Regards Tomasz Gajewski |
From: Eric M. L. <er...@si...> - 2013-01-01 04:45:12
|
Hi Tomasz, The ede-rescan-toplevel function is for projects that load their configuration out of a file. cpp-root doesn't have a config file, and thus nothing to load. The patch you've made fixing the symbol names is something I'm going to do even though they aren't used. Better to be right. Your second lower patch is more complex. There was a problem where EDE was loading all of it's project types when you load up your first file, so the 'dirmatch' option was added for some projects so that EDE could detect the project without having to load the project type. Anyway, I found that fcn tricky enough that I wouldn't trust my ability to know by inspection if it is good. We'd need to devise a test to poke at the key aspects that matter, and since it is a "when emacs starts up" test, there is no infrastructure for it, and no automated tests yet. Said test would probably be in the tests directory with the other integration tests. Possibly we can augment the existing test to just make sure no other EDE project types pass `featurep'. I'm certain some will fail. Hmmm. That's a good idea. I'll have to add that to my todo list. Eric On 12/29/2012 05:12 PM, Tomasz Gajewski wrote: > > I've been trying to run 'ede-rescan-toplevel' on a cpp-root project and > experienced some errors. I've managed to fix them just to find out that > this method is not implemented for this project type. Sadly, even now, I > don't know what this method is supposed to do (I thought that this will > make ede to scan for files inside cpp root project directory and allow > me to use 'ede-find-file' to open them). > > Anyway I think those fixes (at least first part of them) are ok so I > share them with you. > > Following part changes :file and :class-sym for cpp-root and java-root > (not tested but seems to be cloned from cpp-root earlier) to make them > consistent with other projects. > > :file change makes the test: > > (when (and (featurep (oref this file)) > > in 'ede-dir-to-projectfile' in lisp/cedet/ede/auto.el pass (I think > there is an assumption that project files should 'provide' exactly what > is in autoload :file field). > > :class-sym change fixes test: > > (and (object-of-class-p ;; Same as class for this dir? > ans (oref thisdir :class-sym))) > > in 'ede-toplevel-project' in lisp/cedet/ede/files.el. > > > === modified file 'lisp/cedet/ede/cpp-root.el' > --- lisp/cedet/ede/cpp-root.el 2012-12-10 15:52:10 +0000 > +++ lisp/cedet/ede/cpp-root.el 2012-12-29 21:39:35 +0000 > @@ -242,11 +242,11 @@ > (ede-add-project-autoload > (ede-project-autoload "cpp-root" > :name "CPP ROOT" > - :file 'ede-cpp-root > + :file 'ede/cpp-root > :proj-file 'ede-cpp-root-project-file-for-dir > :proj-root 'ede-cpp-root-project-root > :load-type 'ede-cpp-root-load > - :class-sym 'ede-cpp-root > + :class-sym 'ede-cpp-root-project > :new-p nil > :safe-p t) > ;; When a user creates one of these, it should override any other project > @@ -377,7 +377,7 @@ > (when (or (not (file-exists-p f)) > (file-directory-p f)) > (delete-instance this) > - (error ":file for ede-cpp-root must be a file")) > + (error ":file for ede-cpp-root-project must be a file")) > (oset this :file f) > (oset this :directory (file-name-directory f)) > (ede-project-directory-remove-hash (file-name-directory f)) > > === modified file 'lisp/cedet/ede/java-root.el' > --- lisp/cedet/ede/java-root.el 2012-12-17 12:32:52 +0000 > +++ lisp/cedet/ede/java-root.el 2012-12-29 21:39:42 +0000 > @@ -199,11 +199,11 @@ > (ede-add-project-autoload > (ede-project-autoload "java-root" > :name "JAVA ROOT" > - :file 'ede-java-root > + :file 'ede/java-root > :proj-file 'ede-java-root-project-file-for-dir > :proj-root 'ede-java-root-project-root > :load-type 'ede-java-root-load > - :class-sym 'ede-java-root > + :class-sym 'ede-java-root-project > :new-p nil > :safe-p t) > ;; When a user creates one of these, it should override any other project > @@ -296,7 +296,7 @@ > (when (or (not (file-exists-p f)) > (file-directory-p f)) > (delete-instance this) > - (error ":file for ede-java-root must be a file")) > + (error ":file for ede-java-root-project must be a file")) > (oset this :file f) > (oset this :directory (file-name-directory f)) > (ede-project-directory-remove-hash (file-name-directory f)) > > > > I've made another change of which I'm not so confident of. I've changed > condition to match more the description and my version worked ok for > cpp-root project. I've found out that dirmatch initial value was changed > to "" (empty string) in almost the same time as this condition was added > and comment by two different persons (IIRC Alex and Eric) and probably > this condition assumed that for projects that do not set dirmatch the > default value is nil. What I don't understand is the presence of 'root' > in condition so I didn't know where to move it. > > > === modified file 'lisp/cedet/ede/auto.el' > --- lisp/cedet/ede/auto.el 2012-10-07 12:07:12 +0000 > +++ lisp/cedet/ede/auto.el 2012-12-29 20:33:50 +0000 > @@ -311,10 +311,10 @@ > ;; other EDE projects. This happens if the file is > ;; already loaded, or if there is a dirmatch, but > ;; root is empty. > - (when (and (featurep (oref this file)) > - (or (not (stringp dm)) > - (not (string= dm ""))) > - root) > + (when (or (featurep (oref this file)) > + (and (or (not (stringp dm)) > + (not (string= dm ""))) > + root)) > (funcall pf (or root d)))))) > ) > (when (and f (file-exists-p f)) > > > Regards > Tomasz Gajewski > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122912 > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > |
From: Tomasz G. <to...@wp...> - 2013-01-01 13:04:35
|
"Eric M. Ludlam" <er...@si...> writes: > The ede-rescan-toplevel function is for projects that load their > configuration out of a file. cpp-root doesn't have a config file, and > thus nothing to load. What I really wanted to do is to force reparse of all source files in a project (project big enough to not load all files into emacs at once). I expected that ede project (even cpp-root project) will "know" about all source files. Having all files I would be looking for a way to reparse them. I know about 'semanticdb.sh' script but it doesn't work with cpp root projects well. Definition for projects is in .emacs but it is not loaded. What is worse is that semantic customizations are not read by this script so my setting for 'semanticdb-default-save-directory' was not honoured. And even more surprising misliding docstring for 'semanticdb-default-save-directory' which doesn't mention default value at all (which is ~/.emacs.d/semanticdb or ~/.semanticdb if it exists). Coming back to main topic. How should I reparse files in cpp root project? > The patch you've made fixing the symbol names is something I'm going > to do even though they aren't used. Better to be right. You have commited only cpp-root project changes. Java-root left unchanged. Was it on purpose or you've just overlooked them? > Your second lower patch is more complex. There was a problem where > EDE was loading all of it's project types when you load up your first > file, so the 'dirmatch' option was added for some projects so that EDE > could detect the project without having to load the project type. > > Anyway, I found that fcn tricky enough that I wouldn't trust my > ability to know by inspection if it is good. We'd need to devise a > test to poke at the key aspects that matter, and since it is a "when > emacs starts up" test, there is no infrastructure for it, and no > automated tests yet. Said test would probably be in the tests > directory with the other integration tests. Possibly we can augment > the existing test to just make sure no other EDE project types pass > featurep'. I'm certain some will fail. > > Hmmm. That's a good idea. I'll have to add that to my todo list. As you mention your todo list is there any public place for storing cedet related bugs and wishlist items? Bugzilla, trac, launchpad, etc.? I've seen discussion on emacs-devel about tags for cedet bugs on debbugs and even checked list of bugs but I don't think it contains any todos. If it is supposed to be a forum for discussing cedet related issues IMHO cedet should become a project on debbugs becase user tags are not intuitive and AFAIK there is no web interface for them. I'm still looking around the code and only trying to understand general ideas but during that I find some things which are missing or not working and would like to have a place where such issues could be entered, listed, monitored, discussed. And it would be good if it is linked from cedet web pages somewhere (I hope it is not there now and I it's not me who just missed it :-) ). Regards Tomasz Gajewski > On 12/29/2012 05:12 PM, Tomasz Gajewski wrote: >> >> I've been trying to run 'ede-rescan-toplevel' on a cpp-root project >> and experienced some errors. I've managed to fix them just to find >> out that this method is not implemented for this project type. Sadly, >> even now, I don't know what this method is supposed to do (I thought >> that this will make ede to scan for files inside cpp root project >> directory and allow me to use 'ede-find-file' to open them). >> >> Anyway I think those fixes (at least first part of them) are ok so I >> share them with you. >> >> Following part changes :file and :class-sym for cpp-root and >> java-root (not tested but seems to be cloned from cpp-root earlier) >> to make them consistent with other projects. >> >> :file change makes the test: >> >> (when (and (featurep (oref this file)) >> >> in 'ede-dir-to-projectfile' in lisp/cedet/ede/auto.el pass (I think >> there is an assumption that project files should 'provide' exactly >> what is in autoload :file field). >> >> :class-sym change fixes test: >> >> (and (object-of-class-p ;; Same as class for this dir? >> ans (oref thisdir :class-sym))) >> >> in 'ede-toplevel-project' in lisp/cedet/ede/files.el. >> >> >> === modified file 'lisp/cedet/ede/cpp-root.el' >> --- lisp/cedet/ede/cpp-root.el 2012-12-10 15:52:10 +0000 >> +++ lisp/cedet/ede/cpp-root.el 2012-12-29 21:39:35 +0000 >> @@ -242,11 +242,11 @@ >> (ede-add-project-autoload >> (ede-project-autoload "cpp-root" >> :name "CPP ROOT" >> - :file 'ede-cpp-root >> + :file 'ede/cpp-root >> :proj-file 'ede-cpp-root-project-file-for-dir >> :proj-root 'ede-cpp-root-project-root >> :load-type 'ede-cpp-root-load >> - :class-sym 'ede-cpp-root >> + :class-sym 'ede-cpp-root-project >> :new-p nil >> :safe-p t) >> ;; When a user creates one of these, it should override any other project >> @@ -377,7 +377,7 @@ >> (when (or (not (file-exists-p f)) >> (file-directory-p f)) >> (delete-instance this) >> - (error ":file for ede-cpp-root must be a file")) >> + (error ":file for ede-cpp-root-project must be a file")) >> (oset this :file f) >> (oset this :directory (file-name-directory f)) >> (ede-project-directory-remove-hash (file-name-directory f)) >> >> === modified file 'lisp/cedet/ede/java-root.el' >> --- lisp/cedet/ede/java-root.el 2012-12-17 12:32:52 +0000 >> +++ lisp/cedet/ede/java-root.el 2012-12-29 21:39:42 +0000 >> @@ -199,11 +199,11 @@ >> (ede-add-project-autoload >> (ede-project-autoload "java-root" >> :name "JAVA ROOT" >> - :file 'ede-java-root >> + :file 'ede/java-root >> :proj-file 'ede-java-root-project-file-for-dir >> :proj-root 'ede-java-root-project-root >> :load-type 'ede-java-root-load >> - :class-sym 'ede-java-root >> + :class-sym 'ede-java-root-project >> :new-p nil >> :safe-p t) >> ;; When a user creates one of these, it should override any other project >> @@ -296,7 +296,7 @@ >> (when (or (not (file-exists-p f)) >> (file-directory-p f)) >> (delete-instance this) >> - (error ":file for ede-java-root must be a file")) >> + (error ":file for ede-java-root-project must be a file")) >> (oset this :file f) >> (oset this :directory (file-name-directory f)) >> (ede-project-directory-remove-hash (file-name-directory f)) >> >> >> >> I've made another change of which I'm not so confident of. I've changed >> condition to match more the description and my version worked ok for >> cpp-root project. I've found out that dirmatch initial value was changed >> to "" (empty string) in almost the same time as this condition was added >> and comment by two different persons (IIRC Alex and Eric) and probably >> this condition assumed that for projects that do not set dirmatch the >> default value is nil. What I don't understand is the presence of 'root' >> in condition so I didn't know where to move it. >> >> >> === modified file 'lisp/cedet/ede/auto.el' >> --- lisp/cedet/ede/auto.el 2012-10-07 12:07:12 +0000 >> +++ lisp/cedet/ede/auto.el 2012-12-29 20:33:50 +0000 >> @@ -311,10 +311,10 @@ >> ;; other EDE projects. This happens if the file is >> ;; already loaded, or if there is a dirmatch, but >> ;; root is empty. >> - (when (and (featurep (oref this file)) >> - (or (not (stringp dm)) >> - (not (string= dm ""))) >> - root) >> + (when (or (featurep (oref this file)) >> + (and (or (not (stringp dm)) >> + (not (string= dm ""))) >> + root)) >> (funcall pf (or root d)))))) >> ) >> (when (and f (file-exists-p f)) >> >> >> Regards >> Tomasz Gajewski >> >> ------------------------------------------------------------------------------ >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. SALE $99.99 this month only -- learn more at: >> http://p.sf.net/sfu/learnmore_122912 >> _______________________________________________ >> Cedet-devel mailing list >> Ced...@li... >> https://lists.sourceforge.net/lists/listinfo/cedet-devel >> > > -- Tomasz Gajewski |
From: Eric M. L. <er...@si...> - 2013-01-01 16:52:18
|
On 01/01/2013 08:04 AM, Tomasz Gajewski wrote: > "Eric M. Ludlam"<er...@si...> writes: > >> The ede-rescan-toplevel function is for projects that load their >> configuration out of a file. cpp-root doesn't have a config file, and >> thus nothing to load. > > What I really wanted to do is to force reparse of all source files in a > project (project big enough to not load all files into emacs at once). I > expected that ede project (even cpp-root project) will "know" about all > source files. Having all files I would be looking for a way to reparse > them. > > I know about 'semanticdb.sh' script but it doesn't work with cpp root > projects well. Definition for projects is in .emacs but it is not > loaded. What is worse is that semantic customizations are not read by > this script so my setting for 'semanticdb-default-save-directory' was > not honoured. Hmm. That is a problem I hadn't considered. > And even more surprising misliding docstring for > 'semanticdb-default-save-directory' which doesn't mention default value > at all (which is ~/.emacs.d/semanticdb or ~/.semanticdb if it exists). I'll fix that. > Coming back to main topic. How should I reparse files in cpp root > project? There are 2 reasons to have tag data for an entire project. One is to just jump to some definition somewhere. If you would like to do that, I recommend installing and using GNU Global, and using the EDE and Semantic GNU Global configuration steps in the cedet manual. If you create a GTAGS table at the top of your project, it will be used for these basic steps. The second reason to parse files is for smart completion, tag help in the mini buffer, and stuff like that. That is best served by Semantic's automatic parsing system. This mechanism only parses the files you actually need, and minimizes (to some extend) how much memory is used. I don't recommend using Semantic to parse all the files in a project for very large projects. >> The patch you've made fixing the symbol names is something I'm going >> to do even though they aren't used. Better to be right. > > You have commited only cpp-root project changes. Java-root left > unchanged. Was it on purpose or you've just overlooked them? Alex Ott has been making changes in that area lately, and I don't have any tests for it, so I hesitated. >> Your second lower patch is more complex. There was a problem where >> EDE was loading all of it's project types when you load up your first >> file, so the 'dirmatch' option was added for some projects so that EDE >> could detect the project without having to load the project type. >> >> Anyway, I found that fcn tricky enough that I wouldn't trust my >> ability to know by inspection if it is good. We'd need to devise a >> test to poke at the key aspects that matter, and since it is a "when >> emacs starts up" test, there is no infrastructure for it, and no >> automated tests yet. Said test would probably be in the tests >> directory with the other integration tests. Possibly we can augment >> the existing test to just make sure no other EDE project types pass >> featurep'. I'm certain some will fail. >> >> Hmmm. That's a good idea. I'll have to add that to my todo list. > > As you mention your todo list is there any public place for storing > cedet related bugs and wishlist items? Bugzilla, trac, launchpad, etc.? > I've seen discussion on emacs-devel about tags for cedet bugs on debbugs > and even checked list of bugs but I don't think it contains any todos. > If it is supposed to be a forum for discussing cedet related issues IMHO > cedet should become a project on debbugs becase user tags are not > intuitive and AFAIK there is no web interface for them. > > I'm still looking around the code and only trying to understand general > ideas but during that I find some things which are missing or not > working and would like to have a place where such issues could be > entered, listed, monitored, discussed. And it would be good if it is > linked from cedet web pages somewhere (I hope it is not there now and I > it's not me who just missed it :-) ). The sourceforge bug trackers are sometimes used, but I don't do a good job keeping track or assigning bugs. I find it slow to use and interacting with bug creators a challenge. I'm open to any ideas people have for improving things. Eric |
From: Tomasz G. <to...@wp...> - 2013-01-01 20:57:44
|
"Eric M. Ludlam" <er...@si...> writes: >> Coming back to main topic. How should I reparse files in cpp root >> project? > > There are 2 reasons to have tag data for an entire project. One is to > just jump to some definition somewhere. If you would like to do that, > I recommend installing and using GNU Global, and using the EDE and > Semantic GNU Global configuration steps in the cedet manual. If you > create a GTAGS table at the top of your project, it will be used for > these basic steps. > > The second reason to parse files is for smart completion, tag help in > the mini buffer, and stuff like that. That is best served by > Semantic's automatic parsing system. This mechanism only parses the > files you actually need, and minimizes (to some extend) how much > memory is used. As I'm currently using more Eclipse than Emacs for coding in my job I think a little differently. In Eclipse I can use completion for example for a class that is not available from currently included headers but is in the project and ask Eclipse to add an include for me to this class declaration. I thought that something like this would be possible here and that is why I wanted to parse all files from the project. Did you consider such usecase? > I don't recommend using Semantic to parse all the files in a project > for very large projects. I would like to try to do this. I'd like to see if it works. Do I correctly assume that you think it will be slow or maybe you expect some other problems? > The sourceforge bug trackers are sometimes used, but I don't do a good > job keeping track or assigning bugs. I find it slow to use and > interacting with bug creators a challenge. I'm open to any ideas > people have for improving things. I've just tried to see what bugs/features/patches are available on sf and I agree with you: it is slow :-). As David said that debbugs is the right place I think it just should be stated clearly on cedet webpages. I wouldn't know about it if I wasn't reading emacs-devel. Regards Tomasz Gajewski |
From: Eric M. L. <er...@si...> - 2013-01-04 03:32:07
|
On 01/01/2013 03:56 PM, Tomasz Gajewski wrote: > "Eric M. Ludlam"<er...@si...> writes: > >>> Coming back to main topic. How should I reparse files in cpp root >>> project? >> >> There are 2 reasons to have tag data for an entire project. One is to >> just jump to some definition somewhere. If you would like to do that, >> I recommend installing and using GNU Global, and using the EDE and >> Semantic GNU Global configuration steps in the cedet manual. If you >> create a GTAGS table at the top of your project, it will be used for >> these basic steps. >> >> The second reason to parse files is for smart completion, tag help in >> the mini buffer, and stuff like that. That is best served by >> Semantic's automatic parsing system. This mechanism only parses the >> files you actually need, and minimizes (to some extend) how much >> memory is used. > > As I'm currently using more Eclipse than Emacs for coding in my job I > think a little differently. In Eclipse I can use completion for example > for a class that is not available from currently included headers but is > in the project and ask Eclipse to add an include for me to this class > declaration. I thought that something like this would be possible here > and that is why I wanted to parse all files from the project. Did you > consider such usecase? There are two kinds of completion in semantic. The 'smart' version, and a 'brute' version that will complete across the "whole project", where "whole" just means the stuff currently in Emacs. It is a bit limited, so not widely used. >> I don't recommend using Semantic to parse all the files in a project >> for very large projects. > > I would like to try to do this. I'd like to see if it works. Do I > correctly assume that you think it will be slow or maybe you expect some > other problems? One way is in a running Emacs, visit 1 file in each directory. For each file, use semantic-debug-idle-work-function. That will parse all the files in that directory. Normally that happens automatically in idle-time, but this lets you force it. It happens to be a debug function. The internal fcn is (semantic-idle-scheduler-work-parse-neighboring-files) Presumably it would be easy to write an Emacs loop to call the internal fcn. You could probably just copy the internal fcn, and have it scan whatever files you want. It isn't very big. Eric |
From: Tomasz G. <to...@wp...> - 2013-01-05 19:29:20
|
"Eric M. Ludlam" <er...@si...> writes: > There are two kinds of completion in semantic. The 'smart' version, > and a 'brute' version that will complete across the "whole project", > where "whole" just means the stuff currently in Emacs. It is a bit > limited, so not widely used. > >>> I don't recommend using Semantic to parse all the files in a project >>> for very large projects. >> >> I would like to try to do this. I'd like to see if it works. Do I >> correctly assume that you think it will be slow or maybe you expect >> some other problems? > > One way is in a running Emacs, visit 1 file in each directory. For > each file, use semantic-debug-idle-work-function. That will parse all > the files in that directory. Normally that happens automatically in > idle-time, but this lets you force it. It happens to be a debug > function. The internal fcn is > (semantic-idle-scheduler-work-parse-neighboring-files) I don't understand why this function iterates over automode alist but this causes it to not work for me. I have an entry in automode alist based on directory in which files exist. It is not a pattern on file names which is needed for directory-files used in this function. The solution I see is to retrieve all files from directory and later filter them out (I think it is simple enough I can handle writing a patch for this :-) ) but maybe there is some better solution for this as this can be expensive for 'large' directrories. Regards Tomasz Gajewski |
From: Eric M. L. <er...@si...> - 2013-01-15 01:42:16
|
On 01/05/2013 02:29 PM, Tomasz Gajewski wrote: > "Eric M. Ludlam"<er...@si...> writes: > >> There are two kinds of completion in semantic. The 'smart' version, >> and a 'brute' version that will complete across the "whole project", >> where "whole" just means the stuff currently in Emacs. It is a bit >> limited, so not widely used. >> >>>> I don't recommend using Semantic to parse all the files in a project >>>> for very large projects. >>> >>> I would like to try to do this. I'd like to see if it works. Do I >>> correctly assume that you think it will be slow or maybe you expect >>> some other problems? >> >> One way is in a running Emacs, visit 1 file in each directory. For >> each file, use semantic-debug-idle-work-function. That will parse all >> the files in that directory. Normally that happens automatically in >> idle-time, but this lets you force it. It happens to be a debug >> function. The internal fcn is >> (semantic-idle-scheduler-work-parse-neighboring-files) > > I don't understand why this function iterates over automode alist but > this causes it to not work for me. I have an entry in automode alist > based on directory in which files exist. It is not a pattern on file > names which is needed for directory-files used in this function. The > solution I see is to retrieve all files from directory and later filter > them out (I think it is simple enough I can handle writing a patch for > this :-) ) but maybe there is some better solution for this as this can > be expensive for 'large' directrories. It loops over the automode alist to identify files of the same major mode of the current file. The assumption is that if you're in some C code, you will want tags from other C files, and not Makefiles, or .txt files, or python, or whatever else might be nearby. The entry that causes this fcn to not work; what does it look like? Can we just make this loop ignore bad file matches? Eric |
From: Tomasz G. <to...@wp...> - 2013-02-21 21:04:08
|
> On 01/05/2013 02:29 PM, Tomasz Gajewski wrote: >> "Eric M. Ludlam"<er...@si...> writes: >> >>> One way is in a running Emacs, visit 1 file in each directory. For >>> each file, use semantic-debug-idle-work-function. That will parse >>> all the files in that directory. Normally that happens >>> automatically in idle-time, but this lets you force it. It happens >>> to be a debug function. The internal fcn is >>> (semantic-idle-scheduler-work-parse-neighboring-files) >> >> I don't understand why this function iterates over automode alist but >> this causes it to not work for me. I have an entry in automode alist >> based on directory in which files exist. It is not a pattern on file >> names which is needed for directory-files used in this function. The >> solution I see is to retrieve all files from directory and later >> filter them out (I think it is simple enough I can handle writing a >> patch for this :-) ) but maybe there is some better solution for this >> as this can be expensive for 'large' directrories. > > It loops over the automode alist to identify files of the same major > mode of the current file. > > The assumption is that if you're in some C code, you will want tags > from other C files, and not Makefiles, or .txt files, or python, or > whatever else might be nearby. > > The entry that causes this fcn to not work; what does it look like? > Can we just make this loop ignore bad file matches? I've finally found time to get back to this. The entry that causes problem is e.g.: ("/usr/local/Qt-4.8.0/include" . c++-mode) Following patch seems to make it work for me. It iterates first over all files from directory and then over auto mode alist entries and matches full file path against them. Additionally I've added a check to avoid parsing same file more than once if it matches more than one entry in auto-mode-alist. Regards Tomasz Gajewski === modified file 'lisp/cedet/semantic/idle.el' --- lisp/cedet/semantic/idle.el 2013-01-31 20:50:32 +0000 +++ lisp/cedet/semantic/idle.el 2013-02-21 21:03:13 +0000 @@ -436,14 +436,16 @@ "Parse all the files in similar directories to buffers being edited." ;; Let's check to see if EDE matters. (let ((ede-auto-add-method 'never)) - (dolist (a auto-mode-alist) - (when (eq (cdr a) major-mode) - (dolist (file (directory-files default-directory t (car a) t)) - (semantic-throw-on-input 'parsing-mode-buffers) - (save-excursion - (semanticdb-file-table-object file) - )))) - )) + (dolist (file (directory-files default-directory t ".*" t)) + (when (file-regular-p file) + (catch 'file-parsed-break + (dolist (a auto-mode-alist) + (when (and (eq (cdr a) major-mode) + (string-match (car a) file)) + (semantic-throw-on-input 'parsing-mode-buffers) + (save-excursion + (semanticdb-file-table-object file)) + (throw 'file-parsed-break t)))))))) ;;; REPARSING |
From: Tomasz G. <to...@wp...> - 2013-02-21 21:30:45
|
Tomasz Gajewski <to...@wp...> writes: >> On 01/05/2013 02:29 PM, Tomasz Gajewski wrote: >>> "Eric M. Ludlam"<er...@si...> writes: >>> >>>> One way is in a running Emacs, visit 1 file in each directory. For >>>> each file, use semantic-debug-idle-work-function. That will parse >>>> all the files in that directory. Normally that happens >>>> automatically in idle-time, but this lets you force it. It happens >>>> to be a debug function. The internal fcn is >>>> (semantic-idle-scheduler-work-parse-neighboring-files) >>> >>> I don't understand why this function iterates over automode alist but >>> this causes it to not work for me. I have an entry in automode alist >>> based on directory in which files exist. It is not a pattern on file >>> names which is needed for directory-files used in this function. The >>> solution I see is to retrieve all files from directory and later >>> filter them out (I think it is simple enough I can handle writing a >>> patch for this :-) ) but maybe there is some better solution for this >>> as this can be expensive for 'large' directrories. >> >> It loops over the automode alist to identify files of the same major >> mode of the current file. >> >> The assumption is that if you're in some C code, you will want tags >> from other C files, and not Makefiles, or .txt files, or python, or >> whatever else might be nearby. >> >> The entry that causes this fcn to not work; what does it look like? >> Can we just make this loop ignore bad file matches? > > I've finally found time to get back to this. > > The entry that causes problem is e.g.: > > ("/usr/local/Qt-4.8.0/include" . c++-mode) > > Following patch seems to make it work for me. It iterates first over all > files from directory and then over auto mode alist entries and matches > full file path against them. Additionally I've added a check to avoid > parsing same file more than once if it matches more than one entry in > auto-mode-alist. One note on my patch is that I noticed that it doesn't break on a keypress what I would expect. I've tested this patch only by calling (semantic-idle-scheduler-work-parse-neighboring-files) by hand. Maybe it should work only in idle mode but maybe I've broken this somehow. Regards Tomasz Gajewski > > === modified file 'lisp/cedet/semantic/idle.el' > --- lisp/cedet/semantic/idle.el 2013-01-31 20:50:32 +0000 > +++ lisp/cedet/semantic/idle.el 2013-02-21 21:03:13 +0000 > @@ -436,14 +436,16 @@ > "Parse all the files in similar directories to buffers being edited." > ;; Let's check to see if EDE matters. > (let ((ede-auto-add-method 'never)) > - (dolist (a auto-mode-alist) > - (when (eq (cdr a) major-mode) > - (dolist (file (directory-files default-directory t (car a) t)) > - (semantic-throw-on-input 'parsing-mode-buffers) > - (save-excursion > - (semanticdb-file-table-object file) > - )))) > - )) > + (dolist (file (directory-files default-directory t ".*" t)) > + (when (file-regular-p file) > + (catch 'file-parsed-break > + (dolist (a auto-mode-alist) > + (when (and (eq (cdr a) major-mode) > + (string-match (car a) file)) > + (semantic-throw-on-input 'parsing-mode-buffers) > + (save-excursion > + (semanticdb-file-table-object file)) > + (throw 'file-parsed-break t)))))))) > > > ;;; REPARSING > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > -- Tomasz Gajewski |
From: Eric M. L. <er...@si...> - 2013-02-26 03:28:22
Attachments:
db.el.patch
|
On 02/21/2013 04:30 PM, Tomasz Gajewski wrote: > Tomasz Gajewski<to...@wp...> writes: > >>> On 01/05/2013 02:29 PM, Tomasz Gajewski wrote: >>>> "Eric M. Ludlam"<er...@si...> writes: >>>> >>>>> One way is in a running Emacs, visit 1 file in each directory. For >>>>> each file, use semantic-debug-idle-work-function. That will parse >>>>> all the files in that directory. Normally that happens >>>>> automatically in idle-time, but this lets you force it. It happens >>>>> to be a debug function. The internal fcn is >>>>> (semantic-idle-scheduler-work-parse-neighboring-files) >>>> >>>> I don't understand why this function iterates over automode alist but >>>> this causes it to not work for me. I have an entry in automode alist >>>> based on directory in which files exist. It is not a pattern on file >>>> names which is needed for directory-files used in this function. The >>>> solution I see is to retrieve all files from directory and later >>>> filter them out (I think it is simple enough I can handle writing a >>>> patch for this :-) ) but maybe there is some better solution for this >>>> as this can be expensive for 'large' directrories. >>> >>> It loops over the automode alist to identify files of the same major >>> mode of the current file. >>> >>> The assumption is that if you're in some C code, you will want tags >>> from other C files, and not Makefiles, or .txt files, or python, or >>> whatever else might be nearby. >>> >>> The entry that causes this fcn to not work; what does it look like? >>> Can we just make this loop ignore bad file matches? >> >> I've finally found time to get back to this. >> >> The entry that causes problem is e.g.: >> >> ("/usr/local/Qt-4.8.0/include" . c++-mode) >> >> Following patch seems to make it work for me. It iterates first over all >> files from directory and then over auto mode alist entries and matches >> full file path against them. Additionally I've added a check to avoid >> parsing same file more than once if it matches more than one entry in >> auto-mode-alist. > > One note on my patch is that I noticed that it doesn't break on a > keypress what I would expect. I've tested this patch only by calling > (semantic-idle-scheduler-work-parse-neighboring-files) by hand. Maybe it > should work only in idle mode but maybe I've broken this somehow. > [ ...] >> + (dolist (file (directory-files default-directory t ".*" t)) >> + (when (file-regular-p file) >> + (catch 'file-parsed-break >> + (dolist (a auto-mode-alist) >> + (when (and (eq (cdr a) major-mode) >> + (string-match (car a) file)) >> + (semantic-throw-on-input 'parsing-mode-buffers) >> + (save-excursion >> + (semanticdb-file-table-object file)) >> + (throw 'file-parsed-break t)))))))) Thanks for looking into this. If the key to your patch is about ignoring non-regular files, then perhaps my patch will also work for you. This will prevent other programs that attempt similar things from failing too by checking at a lower level. It continues to pass the current test suite. If this fixes your problem, I'll commit it. Eric |
From: Tomasz G. <to...@wp...> - 2013-02-26 06:55:04
|
"Eric M. Ludlam" <er...@si...> writes: > On 02/21/2013 04:30 PM, Tomasz Gajewski wrote: >> Tomasz Gajewski<to...@wp...> writes: >> >>>> On 01/05/2013 02:29 PM, Tomasz Gajewski wrote: >>>>> "Eric M. Ludlam"<er...@si...> writes: >>>>> >>>>>> One way is in a running Emacs, visit 1 file in each directory. >>>>>> For each file, use semantic-debug-idle-work-function. That will >>>>>> parse all the files in that directory. Normally that happens >>>>>> automatically in idle-time, but this lets you force it. It >>>>>> happens to be a debug function. The internal fcn is >>>>>> (semantic-idle-scheduler-work-parse-neighboring-files) >>>>> >>>>> I don't understand why this function iterates over automode alist >>>>> but this causes it to not work for me. I have an entry in automode >>>>> alist based on directory in which files exist. It is not a pattern >>>>> on file names which is needed for directory-files used in this >>>>> function. The solution I see is to retrieve all files from >>>>> directory and later filter them out (I think it is simple enough I >>>>> can handle writing a patch for this :-) ) but maybe there is some >>>>> better solution for this as this can be expensive for 'large' >>>>> directrories. >>>> >>>> It loops over the automode alist to identify files of the same >>>> major mode of the current file. >>>> >>>> The assumption is that if you're in some C code, you will want tags >>>> from other C files, and not Makefiles, or .txt files, or python, or >>>> whatever else might be nearby. >>>> >>>> The entry that causes this fcn to not work; what does it look like? >>>> Can we just make this loop ignore bad file matches? >>> >>> I've finally found time to get back to this. >>> >>> The entry that causes problem is e.g.: >>> >>> ("/usr/local/Qt-4.8.0/include" . c++-mode) >>> >>> Following patch seems to make it work for me. It iterates first over >>> all files from directory and then over auto mode alist entries and >>> matches full file path against them. Additionally I've added a check >>> to avoid parsing same file more than once if it matches more than >>> one entry in auto-mode-alist. >> >> One note on my patch is that I noticed that it doesn't break on a >> keypress what I would expect. I've tested this patch only by calling >> (semantic-idle-scheduler-work-parse-neighboring-files) by hand. Maybe >> it should work only in idle mode but maybe I've broken this somehow. >> > > [ ...] > >>> + (dolist (file (directory-files default-directory t ".*" t)) >>> + (when (file-regular-p file) >>> + (catch 'file-parsed-break >>> + (dolist (a auto-mode-alist) >>> + (when (and (eq (cdr a) major-mode) >>> + (string-match (car a) file)) >>> + (semantic-throw-on-input 'parsing-mode-buffers) >>> + (save-excursion >>> + (semanticdb-file-table-object file)) >>> + (throw 'file-parsed-break t)))))))) > > Thanks for looking into this. > > If the key to your patch is about ignoring non-regular files, then > perhaps my patch will also work for you. This will prevent other > programs that attempt similar things from failing too by checking at a > lower level. The problem I was trying to solve was that 'directory-files' cannot be called directly with patterns from 'auto-mode-alist' because entries in this list have more general meaning. The contain regular expressions for FULL path of the file but pattern passed to 'directory-files' can contain only regular expression to be pattern for JUST file names. That is why I'm retrieving full list of files from directory and later check in auto-mode-alist to find out mode for this file. I thought I've explained it in detail but it seems I missed the most important part. I hope it is clear now what was my intention. The second problem solved is that there can be more than one entry in 'auto-mode-alist' that matches a given file (those are just regular expressions and first matching wins). That is why I've added this catch-throw to leave internal loop after finding first matching entry from 'auto-mode-alist'. > === modified file 'lisp/cedet/semantic/db.el' > *** lisp/cedet/semantic/db.el 2013-01-31 20:50:32 +0000 > --- lisp/cedet/semantic/db.el 2013-02-26 02:12:37 +0000 > *************** > *** 899,905 **** > then load the tags for FILE, and create a new table object for it. > DONTLOAD does not affect the creation of new database objects." > ;; (message "Object Translate: %s" file) > ! (when (and file (file-exists-p file)) > (let* ((default-directory (file-name-directory file)) > (tab (semanticdb-file-table-object-from-hash file)) > (fullfile nil)) > --- 899,905 ---- > then load the tags for FILE, and create a new table object for it. > DONTLOAD does not affect the creation of new database objects." > ;; (message "Object Translate: %s" file) > ! (when (and file (file-exists-p file) (file-regular-p file)) > (let* ((default-directory (file-name-directory file)) > (tab (semanticdb-file-table-object-from-hash file)) > (fullfile nil)) > As about your patch I think it doesn't affect me in any way although I'm not sure - I haven't tested it. Regards Tomasz Gajewski |
From: Eric M. L. <er...@si...> - 2013-03-03 02:29:12
Attachments:
idle.el.patch
|
On 02/26/2013 01:54 AM, Tomasz Gajewski wrote: > "Eric M. Ludlam"<er...@si...> writes: > >> >>>> + (dolist (file (directory-files default-directory t ".*" t)) >>>> + (when (file-regular-p file) >>>> + (catch 'file-parsed-break >>>> + (dolist (a auto-mode-alist) >>>> + (when (and (eq (cdr a) major-mode) >>>> + (string-match (car a) file)) >>>> + (semantic-throw-on-input 'parsing-mode-buffers) >>>> + (save-excursion >>>> + (semanticdb-file-table-object file)) >>>> + (throw 'file-parsed-break t)))))))) >> >> Thanks for looking into this. >> >> If the key to your patch is about ignoring non-regular files, then >> perhaps my patch will also work for you. This will prevent other >> programs that attempt similar things from failing too by checking at a >> lower level. > > The problem I was trying to solve was that 'directory-files' cannot be > called directly with patterns from 'auto-mode-alist' because entries in > this list have more general meaning. The contain regular expressions for > FULL path of the file but pattern passed to 'directory-files' can > contain only regular expression to be pattern for JUST file names. > > That is why I'm retrieving full list of files from directory and later > check in auto-mode-alist to find out mode for this file. > > I thought I've explained it in detail but it seems I missed the most > important part. I hope it is clear now what was my intention. > > The second problem solved is that there can be more than one entry in > 'auto-mode-alist' that matches a given file (those are just regular > expressions and first matching wins). That is why I've added this > catch-throw to leave internal loop after finding first matching entry > from 'auto-mode-alist'. Thanks for clarifying. I think the data was in your previous email. I tend to field CEDET email late at night these days and I'm not always on top of my game. ;) Now that i understand the issue better, I'll lay out how I understand things. 1) semantic-idle-scheduler-work-parse-neighboring-files is trying to parse files next to the current buffer. Thus, directory matches shouldn't generally affect it much. 2) You are just trying to overcome the problem of directory-files throwing an error. For these two cases, I suspect a simple condition-case around directory files should be sufficient. The third issue, overcoming the fact that a given mode exists in auto-mode-alist multiple times shouldn't be a problem with the simplified patch below. It may hit the same file twice, but fortunately semanticdb-file-table-object is pretty speedy the second time around since there is a hash tracking known files. In addition, the directory-files call is only done when something from auto-mode-alist matches the same major mode as the mode started in. (The buffer with the neighbors.) Will this patch as explained match your need? Thanks Eric |
From: Tomasz G. <to...@wp...> - 2013-03-03 10:06:41
|
"Eric M. Ludlam" <er...@si...> writes: > On 02/26/2013 01:54 AM, Tomasz Gajewski wrote: >> "Eric M. Ludlam"<er...@si...> writes: >> >>> >>>>> + (dolist (file (directory-files default-directory t ".*" t)) >>>>> + (when (file-regular-p file) >>>>> + (catch 'file-parsed-break >>>>> + (dolist (a auto-mode-alist) >>>>> + (when (and (eq (cdr a) major-mode) >>>>> + (string-match (car a) file)) >>>>> + (semantic-throw-on-input 'parsing-mode-buffers) >>>>> + (save-excursion >>>>> + (semanticdb-file-table-object file)) >>>>> + (throw 'file-parsed-break t)))))))) >>> >>> Thanks for looking into this. >>> >>> If the key to your patch is about ignoring non-regular files, then >>> perhaps my patch will also work for you. This will prevent other >>> programs that attempt similar things from failing too by checking at >>> a lower level. >> >> The problem I was trying to solve was that 'directory-files' cannot >> be called directly with patterns from 'auto-mode-alist' because >> entries in this list have more general meaning. The contain regular >> expressions for FULL path of the file but pattern passed to >> 'directory-files' can contain only regular expression to be pattern >> for JUST file names. >> >> That is why I'm retrieving full list of files from directory and >> later check in auto-mode-alist to find out mode for this file. >> >> I thought I've explained it in detail but it seems I missed the most >> important part. I hope it is clear now what was my intention. >> >> The second problem solved is that there can be more than one entry in >> 'auto-mode-alist' that matches a given file (those are just regular >> expressions and first matching wins). That is why I've added this >> catch-throw to leave internal loop after finding first matching entry >> from 'auto-mode-alist'. > > Thanks for clarifying. I think the data was in your previous email. > I tend to field CEDET email late at night these days and I'm not > always on top of my game. ;) > > Now that i understand the issue better, I'll lay out how I understand > things. > > 1) semantic-idle-scheduler-work-parse-neighboring-files is trying to > parse files next to the current buffer. Thus, directory matches > shouldn't generally affect it much. > 2) You are just trying to overcome the problem of directory-files > throwing an error. I think I was not clear enough again :-). No. directory-files doesn't throw error. Files just do not match my regular expression becuase only filename is matched and my entry from directory-files contains pattern on directories. In consequence your patch doesn't change anything. The only solution that I see is to retrieve all files and match them against auto-mode-alist entries just like I did in my patch. > For these two cases, I suspect a simple condition-case around > directory files should be sufficient. > > The third issue, overcoming the fact that a given mode exists in > auto-mode-alist multiple times shouldn't be a problem with the > simplified patch below. It may hit the same file twice, but > fortunately semanticdb-file-table-object is pretty speedy the second > time around since there is a hash tracking known files. If you think multiple matches is not a problem then here is a simplified version of my patch: === modified file 'lisp/cedet/semantic/idle.el' *** lisp/cedet/semantic/idle.el 2013-01-31 20:50:32 +0000 --- lisp/cedet/semantic/idle.el 2013-03-03 09:29:57 +0000 *************** *** 436,449 **** "Parse all the files in similar directories to buffers being edited." ;; Let's check to see if EDE matters. (let ((ede-auto-add-method 'never)) ! (dolist (a auto-mode-alist) ! (when (eq (cdr a) major-mode) ! (dolist (file (directory-files default-directory t (car a) t)) ! (semantic-throw-on-input 'parsing-mode-buffers) ! (save-excursion ! (semanticdb-file-table-object file) ! )))) ! )) ;;; REPARSING --- 436,449 ---- "Parse all the files in similar directories to buffers being edited." ;; Let's check to see if EDE matters. (let ((ede-auto-add-method 'never)) ! (dolist (file (directory-files default-directory t ".*" t)) ! (when (file-regular-p file) ! (dolist (a auto-mode-alist) ! (when (and (eq (cdr a) major-mode) ! (string-match (car a) file)) ! (semantic-throw-on-input 'parsing-mode-buffers) ! (save-excursion ! (semanticdb-file-table-object file)))))))) ;;; REPARSING > In addition, the directory-files call is only done when something from > auto-mode-alist matches the same major mode as the mode started > in. (The buffer with the neighbors.) I have left this check but done individually for each file. As I think about it more a slightly more efficient algoright (though not for the most pessimistic case) would be to filter auto-mode-alist with this check, retrieve full directory listing and check files against this filtered list. Something like this implements patch below. Regards Tomasz Gajewski === modified file 'lisp/cedet/semantic/idle.el' *** lisp/cedet/semantic/idle.el 2013-01-31 20:50:32 +0000 --- lisp/cedet/semantic/idle.el 2013-03-03 10:01:48 +0000 *************** *** 435,449 **** (defun semantic-idle-scheduler-work-parse-neighboring-files () "Parse all the files in similar directories to buffers being edited." ;; Let's check to see if EDE matters. ! (let ((ede-auto-add-method 'never)) (dolist (a auto-mode-alist) (when (eq (cdr a) major-mode) ! (dolist (file (directory-files default-directory t (car a) t)) ! (semantic-throw-on-input 'parsing-mode-buffers) ! (save-excursion ! (semanticdb-file-table-object file) ! )))) ! )) ;;; REPARSING --- 435,452 ---- (defun semantic-idle-scheduler-work-parse-neighboring-files () "Parse all the files in similar directories to buffers being edited." ;; Let's check to see if EDE matters. ! (let ((ede-auto-add-method 'never) ! (matching-auto-mode-paterns nil)) (dolist (a auto-mode-alist) (when (eq (cdr a) major-mode) ! (add-to-list 'matching-auto-mode-paterns (car a)))) ! (dolist (file (directory-files default-directory t ".*" t)) ! (when (file-regular-p file) ! (dolist (a matching-auto-mode-paterns) ! (when (string-match a file) ! (semantic-throw-on-input 'parsing-mode-buffers) ! (save-excursion ! (semanticdb-file-table-object file)))))))) ;;; REPARSING |
From: Eric M. L. <er...@si...> - 2013-03-05 01:45:57
|
On 03/03/2013 05:06 AM, Tomasz Gajewski wrote: [ snip ] >> Now that i understand the issue better, I'll lay out how I understand >> > things. >> > >> > 1) semantic-idle-scheduler-work-parse-neighboring-files is trying to >> > parse files next to the current buffer. Thus, directory matches >> > shouldn't generally affect it much. >> > 2) You are just trying to overcome the problem of directory-files >> > throwing an error. > I think I was not clear enough again :-). > > No. directory-files doesn't throw error. Files just do not match my > regular expression becuase only filename is matched and my entry from > directory-files contains pattern on directories. > > In consequence your patch doesn't change anything. The only solution > that I see is to retrieve all files and match them against > auto-mode-alist entries just like I did in my patch. [snip] > I have left this check but done individually for each file. As I think > about it more a slightly more efficient algoright (though not for the > most pessimistic case) would be to filter auto-mode-alist with this > check, retrieve full directory listing and check files against this > filtered list. Something like this implements patch below. > > > Regards > Tomasz Gajewski > > > === modified file 'lisp/cedet/semantic/idle.el' > *** lisp/cedet/semantic/idle.el 2013-01-31 20:50:32 +0000 > --- lisp/cedet/semantic/idle.el 2013-03-03 10:01:48 +0000 > *************** > *** 435,449 **** > (defun semantic-idle-scheduler-work-parse-neighboring-files () > "Parse all the files in similar directories to buffers being edited." > ;; Let's check to see if EDE matters. > ! (let ((ede-auto-add-method 'never)) > (dolist (a auto-mode-alist) > (when (eq (cdr a) major-mode) > ! (dolist (file (directory-files default-directory t (car a) t)) > ! (semantic-throw-on-input 'parsing-mode-buffers) > ! (save-excursion > ! (semanticdb-file-table-object file) > ! )))) > ! )) > > > ;;; REPARSING > --- 435,452 ---- > (defun semantic-idle-scheduler-work-parse-neighboring-files () > "Parse all the files in similar directories to buffers being edited." > ;; Let's check to see if EDE matters. > ! (let ((ede-auto-add-method 'never) > ! (matching-auto-mode-paterns nil)) > (dolist (a auto-mode-alist) > (when (eq (cdr a) major-mode) > ! (add-to-list 'matching-auto-mode-paterns (car a)))) > ! (dolist (file (directory-files default-directory t ".*" t)) > ! (when (file-regular-p file) > ! (dolist (a matching-auto-mode-paterns) > ! (when (string-match a file) > ! (semantic-throw-on-input 'parsing-mode-buffers) > ! (save-excursion > ! (semanticdb-file-table-object file)))))))) Thanks for your patience in explaining. This final patch is something I understand with the needed backstory. I was hesitant to do full directory lookups in this function. The ".*" is always scary. I suppose it is no worse that several shorter lookups. Perhaps this will be faster in the end. Your patch is currently passing tests, but I don't think we have any tests that explicitly try this out idle routine out. Instead, I'm going to run with this for a little bit and see how it goes. Fortunately, this patch is smaller than 10 lines of new code, so I don't need any special papers to accept contributions such as this. Thanks Eric |
From: Eric M. L. <er...@si...> - 2013-03-21 02:53:33
|
On 03/04/2013 08:45 PM, Eric M. Ludlam wrote: > > Thanks for your patience in explaining. > > This final patch is something I understand with the needed backstory. I > was hesitant to do full directory lookups in this function. The ".*" is > always scary. I suppose it is no worse that several shorter lookups. > Perhaps this will be faster in the end. > > Your patch is currently passing tests, but I don't think we have any > tests that explicitly try this out idle routine out. > > Instead, I'm going to run with this for a little bit and see how it goes. > > Fortunately, this patch is smaller than 10 lines of new code, so I don't > need any special papers to accept contributions such as this. Hi Tomasz, Your patch was too close to the edge of being "small", so I re-wrote it to avoid copyright issues, and checked in the change. Hopefully this version satisfies your particular use case. I found that when I was running, the defaults had changed to not parse neighboring files by default, so all that intermediate time was wasted. Bummer. I tested by hand instead to make sure the logic was ok. Thanks Eric |
From: David E. <de...@ra...> - 2013-01-01 16:56:52
|
Tomasz Gajewski writes: > As you mention your todo list is there any public place for storing > cedet related bugs and wishlist items? Bugzilla, trac, launchpad, etc.? > I've seen discussion on emacs-devel about tags for cedet bugs on debbugs > and even checked list of bugs but I don't think it contains any todos. > If it is supposed to be a forum for discussing cedet related issues IMHO > cedet should become a project on debbugs becase user tags are not > intuitive and AFAIK there is no web interface for them. Using the Emacs bugtracker is the best choice. While usertags are surely not perfect, I prefer them over making CEDET a separate package. (Since you already read that thread on emacs-devel, I won't repeat the reasons here). You can get a list of bugs with usertag 'cedet' through http://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs;tag=cedet And since you're already using Gnus, the 'debbugs' package from ELPA should be right up your alley. -David |
From: Tomasz G. <to...@wp...> - 2013-01-01 20:31:33
|
David Engster <de...@ra...> writes: > Tomasz Gajewski writes: >> As you mention your todo list is there any public place for storing >> cedet related bugs and wishlist items? Bugzilla, trac, launchpad, >> etc.? I've seen discussion on emacs-devel about tags for cedet bugs >> on debbugs and even checked list of bugs but I don't think it >> contains any todos. If it is supposed to be a forum for discussing >> cedet related issues IMHO cedet should become a project on debbugs >> becase user tags are not intuitive and AFAIK there is no web >> interface for them. > > Using the Emacs bugtracker is the best choice. While usertags are > surely not perfect, I prefer them over making CEDET a separate > package. (Since you already read that thread on emacs-devel, I won't > repeat the reasons here). You can get a list of bugs with usertag > 'cedet' through As I understand if someone wants to enter a cedet but enters it for emacs and later someone else (you?) assign a tag for it. This part I think stands for "usertags are surely not perfect" :-) > http://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs;tag=cedet It would be good, I think, to have a link from cedet pages to this query. I couldn't find a way to make a query from advanced search that produced this url. tag=cedet yes, but users=emacs no. Is it possible? Anyway it is nice to know it. > And since you're already using Gnus, the 'debbugs' package from ELPA > should be right up your alley. I've checked this and I think I might like this interface. Regards Tomasz Gajewski |
From: David E. <de...@ra...> - 2013-01-01 21:54:49
|
Tomasz Gajewski writes: > David Engster <de...@ra...> writes: > >> Tomasz Gajewski writes: >>> As you mention your todo list is there any public place for storing >>> cedet related bugs and wishlist items? Bugzilla, trac, launchpad, >>> etc.? I've seen discussion on emacs-devel about tags for cedet bugs >>> on debbugs and even checked list of bugs but I don't think it >>> contains any todos. If it is supposed to be a forum for discussing >>> cedet related issues IMHO cedet should become a project on debbugs >>> becase user tags are not intuitive and AFAIK there is no web >>> interface for them. >> >> Using the Emacs bugtracker is the best choice. While usertags are >> surely not perfect, I prefer them over making CEDET a separate >> package. (Since you already read that thread on emacs-devel, I won't >> repeat the reasons here). You can get a list of bugs with usertag >> 'cedet' through > > As I understand if someone wants to enter a cedet but enters it for > emacs and later someone else (you?) assign a tag for it. This part I > think stands for "usertags are surely not perfect" :-) Anyone can set usertags, also directly when filing the bug. See admin/notes/bugtracker in Emacs trunk. But I don't think that users should have to care; if they haven't installed CEDET from bzr, then CEDET is just a part of Emacs, so they file an Emacs bug report, and "someone" (usually Glen or me) will set the tag afterwards. If people use the bzr version, they should just report bugs here. If bugs don't get fixed, or features don't get implemented, this is due to lack of manpower, not because we don't have a proper bug tracker. > I couldn't find a way to make a query from advanced search that produced > this url. tag=cedet yes, but users=emacs no. Is it possible? I'm afraid you just have to know it. -David |