I'm trying to implement a copy participant and things work quite well when I copy a resource to another location. However, things does not work if I do a copy+paste into the same directory. Eclipse will happily suggest a new name for the file, but it seems that I cannot get a pointer to the new name in my implementation of the CopyParticipant.
What I see is, that org.eclipse.jdt.internal.corext.refactoring.changes.CopyResourceChange.getNewResourceName() asks for the new name but the participant appears to be already done with its job at that point in time. Did I miss something?
Related
I am aware that I am asking for an implementation detail but I want to hack something for my use case and hence the question.
My use case: I use an on-demand instance where source code is hosted at work. This means I get a new machine (let's say every day) where I open the same source folder (but hosted on that remote machine). Because of this, the context of opened files in editor gets lost between sessions.
I am curious where does VSCode save the information about open files in a workspace. If I know that, I am hoping I can copy that file at the end of day before I give up an on-demand instance AND when I get the next instance (which may have a different remote url but same file paths), I can somehow hack this file to open all the editors from previous session in the new on-demand. Does my question make sense? Let me know if something is not clear.
On Windows the workspace state is stored here:
%APPDATA%\Code\User\workspaceStorage
And on Linux:
~/.config/Code/User/workspaceStorage
Every workspace has a subfolder here with a hashed name. To find out which one belongs to your workspace, open the contained workspace.json, which looks like this:
{
"folder": "file:///c%3A/some/path"
}
Choose the one that matches your workspace folder and copy the complete folder.
However, I am not sure how VS Code calculates the hashes for the folder names, so maybe it won't use the same hash again in your new instance. But this definitely is the place where the information is stored, so it's worth a try.
I'm writing an Eclipse plugin and I need to save some properties files and binary files as metadata of the plugin. The idea is that when the user starts Eclipse next day he/she won't need to configure/type all again from scratch.
I'm good about writing and reading the files, but I'm not sure about the best location for them. It seems like the perfect location would be something like:
<WORKSPACE_HOME>/.metadata/.plugins/org.myplugin.name
But how do I get or assemble this path? So far I've got to assemble this path as shown below:
<WORKSPACE_HOME>: I could use ResourcesPlugin.getWorkspace().getRoot().getLocation().
.metadata/.plugins: Should I hard code this section? Could it change in the future?
org.myplugin.name: This is the easy one since it's my plugin name.
Is it possible to get that path without hard coding values?
Do I need to create the last directory (my plugin name)? (I guess I need to)
Ask org.eclipse.core.runtime.Platform for your Bundle's "private" state location. If you have a plug-in activator, you can get the Bundle from there. Otherwise, there's a different method on Platform to get the right instance based on the ID.
https://help.eclipse.org/oxygen/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/runtime/Platform.html#getStateLocation-org.osgi.framework.Bundle-
I'm trying to change some folder names in a Joomla (1.5.23) website to better define what they contain. Everything I find refers to changing template names but in the admin panel I don't see anything named "templates".
So far I've been able to make all my changes by directly editing the files in the database but I can't find how to change a folder name. I tried changing it in the category manager and published it but still uses the old folder names.
Any direction would help at this point.
From the Admin, under Extensions, you'll see Template Manager. It displays your available templates based on folders in the \templates folder, and uses the templateDetails.xml within that folder for the admnin form.
Your best bet is to simply copy one of those folders, makes changes in the templateDetails.xml files (so you that you'll see a different name in the admin), and further investigate how it works from the copied version.
In one of the previous versions of one of my file in a Netbeans project I wrote code that I later removed, and now I want to retrieve it. However now I can't find it when I manually go to previous versions, as I have many versions in the local history of this file, and I don;t remember when exactly I wrote this code.
Is there a way to run a search on the local history of this file?
I saw in this answer that the local history is kept in this path
<HOME>/.netbeans/<NB_VERSION>/var/filehistory where HOME is my user home and NB_VERSION is the version of NetBeans (e.g. 7.0).
I tried running AgentRansack on that directory, but to no avail.
I recently had to solve this problem and figured it out. Netbeans stores local history files in your user directory as mentioned above. Inside that folder are numbered directories. It's pretty easy to guess which one you need based on the modification date of the folder (if you know when you last looked at it, so that doesn't help you much). In side the numbered folders is another folder with a hashed name, and inside of that folder is a set of files: a data file, and numbered files. The data file can be read with a binary file reader, and if viewed in ascii mode will show the filename that this history belongs to. The numbered files are actually zip files and they have full versions of the file in them. Just unzip those and open with a text editor if they are plain text files.
Hope this helps you out, but I realize its probably too late now. I had to figure this out because I had opened a remote file with netbeans (a file that was not associated with a project), and couldn't get back into the Local History because the file didn't have a project. However I could see it in the Local history by reading the data file, and I just guessed that the other files were zipped by the fact that they started with "PK" in the binary viewer. Once I put it all together I was home free.
I am developing for the iPhone and the prevailing advice on auto-generating files from entities, when using Core Data, is to select the *.xcdatamodel file and the create the new file(s) etc. This creates the *.m and *.h files in the Resources directory. These are then moved to the Classes directory or a subdirectory of Classes.
However, when viewing my github repository I notice that all of the model files which have been auto-generated in the above mentioned way are present on the root of the project folder (as if they were a resource).
The underlying file structure may or may not matter (I'm unsure on this point) but I would like to make my repository less disorganised. I can see entropy taking over as the project gets much bigger and there are more files to contend with.
My question is therefore: is there a way to organise the underlying file structure without messing up the project settings or the way github sees the project?
I hope the above isn't unclear and I look forward to your replies.
Yes, this is possible. The Xcode groups (the yellow "folders," like your Resources) are completely independent of the file system - they don't directly represent directories. If you select a group and go to File -> Get Info, you can select the base path for that group of files. You can create and select a new folder through the file chooser there.
Once you do this, all the files in that group will go red - Xcode can no longer find them through the new path. Use the Finder (or Git) to move them into your new directory, and all should be well.
Xcode defaults to placing new Managed Object classes in the folder that the model is in, so new resources will get placed there automatically.
As a sidenote, I highly recommend Rentzsch's Mogenerator to handle Managed Object class creation. It divorces Xcode's auto-generated code from your custom code, and then automagically regenerates the template code every time your model changes (without losing your own code).