Re: Fwd: I released the refactoring tool
Eric Ludlam <[email protected]> Fri, 27 Feb 2015 21:09:36 -0500
| Newsgroups | gmane.emacs.cedet |
|---|---|
| Message-ID | <[email protected]> |
On 02/24/2015 09:35 AM, Lluís wrote: > Eric Ludlam writes: > >> On 02/19/2015 10:45 AM, Lluís wrote: >>> I could then change the linux project to set them "properly" by default. Even >>> more, if we ever have a way to store a per-project properties file (like: edit >>> project, change settings, save to project's root), having these as project >>> properties would be a win. > >> All EDE projects support a concept of project-local variables. You can do: > >> M-x customize-project RET > > Right, but are "semanticdb-new-database-class" and > "semanticdb-find-default-throttle" (or some equivalent) project-local variables? Project local variables are just a way to set buffer local variables via EDE. So yes, they are. >> and go to the settings tab and find project local variables >> there. Unfortunately, ede-linux, and the other specific/automatic projects won't >> save your changes. The Generic project type will save, and the cpp-root and >> java equivalents also can just have them set. > > I think we discussed this before. In my opinion it would be nice to refactor > projects into a common generic base project that handles loading and storing > project-local variables in the disk (I think David did something on these lines, > but using a separate project type). We're getting closer to that with the code > you added to detect the root of a project by looking for the root of a > repository. Yes, I agree, that would be nice. Also need to make sure users don't have to save some .ede file into their project directories. >> I'm open to any suggestions/help for making the -linux and -emacs project types >> work better, as I don't use them directly myself. > > Well, making the variables above as project-local and setting them to a less > "heavy-weight" value will make the linux project more responsive by default. But > of course this is should only be used in the meantime until CEDET is able to > handle these on large projects (I'm assuming that will be possible in the > future). There are several ideas for making things more responsive. The one that affect me was having all those symbols in Emacs memory. Being able to offload those into a file, and query as needed would save a lot. If you have a zillion includes in each file however, not much to do about that. >> Another option for setting these variables is the directory-local stuff. > > Yeah, I was struggling to think whether it makes more sense to have a special > project file, or instead use directory-local variables to establish the project > configuration. I like the refactor idea floated above, but in the meantime, there are several other options. ;) Eric ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Cedet-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cedet-devel