I'm searching for a way to parse the whole directory with source code with semantic. Is this possible to do without explicitly opening each file in emacs?
Yes,
There's a thing called an EDE project in CEDET - where you can specify the list of files in a project file. Semantic then does analysis of all of the files listed in the .ede project, and stored that in the database.
At that point, completion and intellisense works on all of those files.
I use projman mode on top of EDE. It aids in the creation of projects and provides convenient functions to find all source files and generate a global TAGS file. I had tried CEDET on and off for the past couple years and had always come away disappointed until I discovered projman.
Related
Where does VSCode store its Most Recently Used (MRU) list of .NET projects and solutions on Windows?
And also is there some open source code to fetch VSCode's MRUs?
I scanned all files in this dir (recursive) C:\Users\pat\AppData\Roaming\Code with no luck
For you it should be in C:\Users\pat\AppData\Roaming\Code\User\globalStorage\state.vscdb; this file is an SQLite database and you can look around for tools that open this kind of file (because it won't be readable as plain text) to see what's inside and decide whether you can sync it across machines (if that's what you're after).
Also reference this answer, there's very useful stuff over there.
Edit: Thanks this is indeed the file I was looking for.
It can be read with the tool SQLitebrowser.
I didn't easily found a .NET library to read the state.vscdb file + we are very reluctant in embedding a whole library in our product for a small feature.
Hopefully state.vscdb contains the MRU file list in clear textual JSON.
So what I did is just open this file as text, and locate the JSON and read it. Clearly it is ugly but JSON shouldn't be crypted anytime soon in such file and if it fails one day, this feature is not critical for us, just a convenient helper for the user.
The JSON to locate looks like:
{"entries":[
{"fileUri":"file:///c%3A/Dir/treeItem.ts"},
{"fileUri":"file:///c%3A/Dir/YourSolution.sln"},
...
I'm using Practically Macros, but maybe there is some better Eclipse macro player for this task?
I run some commands on huge amount of files.
How do you open all files from a folder - one at a time - recursive, then do some commands on them?
Also is there some better fix for using the save command if there were no changes made? Like only save if changes where made. Now it generates an error so I write an character and then remove it to always be able to save.
I know how to do the file editing, but I first must open the files manually and it takes alot of time because if I select multiple I can't use the open with (Progress OpenEdge AppBuilder (OpenEdge UI Designer) is default and I don't want that but thats not the point here).
Practically Macro example:
*file editing, many commands*
Insert string: -
Delete previous character
Save
Close
Play last macro
This edit all the currently opened files like I want them (beautify).
This generates an error when there is no more files to close. How to fix?
So my macro/progress questions where:
Is there a better macro player for eclipse than Practically Macro?
Is there a way to use the save command only when needed?
Is there a way to not get errors when all files are closed? Or a way to detect when the recursive loop should end.
Is there a way to open multiple files with in Progress Developer Studio in text mode?
Is there a way to recursive open all the files in a folder (one at a time and open with OpenEdge ABL Editor) with macro?
This version of Practically Macro had semi-usable Eclipse macro support for my current version of Eclipse (Mars). Another option that seems to take a more official approach, but hasn't seemed to get much traction yet, is EASE.
If you do these kinds of tasks regularly, you could script things externally, in perl or Node.js or any other of the dozens of high-quality scripting languages out there.
WARNING: there appear to be two older versions of Practically Macro you might stumble upon. One is also on the Eclipse Marketplace but not marked with the trailing "-0". There is also another older one on SourceForge.
This thread is very useful for finding out which files in Netbeans should go into source countrol, but it doesn't cover all files.
In particular I'm wondering whether the following files should go into source control. Here are my assumptions/guesses:
nb-configuration.xml - easiest - the file itself in the comment says it should go into source control.
nbactions.xml - from what I see this file stores information typical to running the application. I.e. JVM arguments etc. So I suppose it is a question of taste - if you want other developers to have a "suggested" Run configuration - include it. Otherwise - don't. Correct?
catalog.xml - not sure what this does (I GUESS it's used by the editor to find out xml schemas and such to enable syntax coloring, but it's just a guess). Anyway - I see that this file has system-specific information (path) - so it shouldn't go into source control.
Can anyone confirm the above?
Thanks,
Piotr
I never put my IDE configuration files in the repository, for several reasons:
other colleagues may want to use theirs;
other colleagues may want to use other IDEs (such as Eclipse) and seeing those files (or even have to exclude them from the checkout) could be annoying for them;
some of these files are generally not related to a single project, others automatically generated, so no need to store them in the source code of every project.
In order to exclude them, our first solution was the .svnignore, but it was still logically wrong to modify some shared content for the specific needs of a single user, so we decided to be more strict:
in my ~/.subversion/config I have:
[miscellany]
global-ignores = nbactions.xml nbproject
Hope this helps,
Marcello
In my Maven based projects I put nbactions.xml into source control. Just make sure to change absolute paths to relative ones.
I put nbactions.xml into source control BUT there is a caveat: it's internal format can change so if your developers, for any reason, use different versions of NetBeans you could have to remove it because sharing it becomes nasty.
Recently I upgraded from NetBeans 7.3.1 to 7.4 and the "Run" action was giving a strange error message. I solved the problem by deleting and regenerating nbactions.xml: the old one had a custom Maven goal for the "Run" and "Debug" actions; it was org.codehaus.mevenide:netbeans-deploy-plugin:1.2.4:deploy it was not visible in the IDE v7.3.1 (perhaps it has been generated by an even older version for internal usage) and was generating a class not found for org.openide.util.Lookup in v7.4. I'm documenting the problem here because I found the solution by myself after an unsuccessful search on the Net. I hope this can help someone else.
I created a project "Sample Code"... here I just paste sample code... much of it is snippets that won't compile.
Is there some project-specific setting I can make so that Eclipse doesn't try to compile it?
I would prefer not to have the source code littered with red error markers.
Put your code in a non-java project, ie a general project.
Downside: you will have to create package directory structure (unless you can copy and paste from somewhere else).
Upside: it won't try to compile.
MY SOLUTION
ok, this is not an exact solution to my problem... but it is another way to do it and I kinda like it now...
I simply forget about using Eclipse to store the sample java files!
I found a good program CodeBox for Mac to store code snippets and I'm sure there exist such things for Windows, Linux too...
there interesting thing is that when I choose from this program to open the java snippet file (.java) in an external editor (Eclipse), it will open in Eclipse without any Syntax checking... wohoo! no squiggly lines
Because of this, it is not full blown code highlighting... classes and variables same color... but that's ok.. still quite readable. Much more than if it was in Eclipse with syntax highlighting running on it...
So basically, if you want to get rid of these red squiggles... one way to do it is don't keep sample .java (or other language) files in a project in Eclipse... simply keep them in the filesystem or code storage app and open them with Eclipse when you want to view them.
Depending on how you prefer to structure your project:
you could put your java files into a separate folder that is not configured as a source folder. There is an entry in the eclipse help on how to configure your build path.
or you can set exclusion-patterns in the build configuration, so that specific packages or files that follow a pattern you define don't get compiled.
Yet another way to handle your snippets could be to use a Scrapbook page.
Eclipse won't highlight anything in a scrapbook page but you can select code parts inside the page and execute them isolated. That's nice if you're experimenting and don't want to set up a whole class with imports and methods just to see if a specific snippet works as expected.
From what I can tell from the docs, semantic works by slowly building up an idea of what's in your project by analysing each file (and possibly its neighbours) as you visit them. This is too slow. I'd like to just have it visit all the files in my project. Is there an easy way to do this? Having to visit hundreds of files before I can get decent autocomplete working seems crazy.
I've also got a etags file generated. Can I leverage that somehow?
Relevant info: Emacs on Windows, version 23.2.1
CEDET will automatically parse all files references via #include statements, thus providing pretty good completion. If you are looking to jump around in your files, you can setup CEDET to use GNU Global, CScope, to provide the database needed to move around a project by tag name.
In addition, CEDET will parse your headers and nearby files in idle time, so eventually you will have a complete database of all your local files in about 10 minutes after using the tools the first time. You can speed it up by opening a file, and calling
M-x semantic-debug-idle-work-function
which will go off and do that stuff without waiting.
In the end, I've found that the best solution is to brute-force the parsing of the files manually using a bit of elisp. The best answer I've found to this is here.