I try to install/run emacs on a Win7 64-bit machine after using it for years on a WinXP 32-bit machine and run into a problem I do not find any help for in the documentation or on the web.
Symptom:
when starting runemacs.exe for the first time it creates the file
*C:\Users\USER\My Documents.emacs.d*
as one would expect (for my administrator as well as for my user account)
and comes up operational
from the second start of runemacs.exe it breaks in the startup phase,
displaying the scratch buffer, ringing the warning bell and displaying in
bottom line the error:
File exists: c:/Users/USER/My Documents/.emacs.d/
buffer messages specifies:
make-directory: File exists: c:/Users/USER/My Documents/.emacs.d/
if runemacs was called with a file to open, i.e. because the file type was
associated with it and the file was opened to edit, the file is not open
and ready to be edited, but a file can be opened via the menu File->Open File...
but my configurations in the file
C:\Users\USER\My Documents.emacs
are not loaded
My goal:
I want to regain the way I used emacs on the old WinXP 32-bit system:
click a file associated with emacs, get it opened and ready for editing, get my configurations in .emacs loaded automatically, i.e. work with emacs seamlessly.
Checks done and failed attempts to fix this:
I tried the following newly downloded versions of emacs
emacs-23.4-bin-i386.zip
emacs-23.2-bin-i386.zip (the one I used on the WinXP)
I had the emacs directory containing the directory stucture (bin, etc, ...)
located at:
C:\Program Files (x86)\emacs-23.4\ (my preferred location)
C:\Emacs\emacs-23.4\
in the download directory, where I originally extracted it
My HOME variable points to:
C:\Users\USER\My Documents (default)
C:\Users\USER\My Documents\ (tried)
My PATH variable contains:
C:\Program Files (x86)\emacs-23.4\bin (default)
or the corresponding other locations which I tried
The ownership and permissions of my C:\Users\USER\My Documents.emacs.d
look OK:
owner is the USER (administrator or standard_user)
permissions grant Full Control
Having originally installed emacs to *C:\Program Files (x86)\emacs-23.4*
using the administrator account, I also tried to use user account installation
instead (to check for some non- obvious parameter/access permission not set
right if the admin account is uses for setup)
For the runemacs.exe executable I manually set the compatibility settings to
Windows XP (Service Pack 3)
default setting after unpacking: no compatibility setting enabled
I removed the private configuration file C:\Users\USER\My Documents.emacs
(inherited from my XP installation) to check whether it produces a screw-up
All that did not change a bit of the described symptom, i.e. either I screwed up
in testing the above and missed a particular setting which should work, or I am looking into the wrong direction...
It is still unclear to me whether this has anything to do with:
W7 64-bit vs. XP 32-bit
environmental parameter screw-up
emacs configuration (.emacs, .emacs.d) screw-up
general stupidity (of me ;-)
... and why is it has emacs a problem with it in the first place, that the .emacs.d directory already exists... That should be the standard case...
Any help and wisdom much appreciated.
First of all, nice question. The details and listing of what you've already tried is helpful.
Some points:
Don't have spaces in key paths (Emacs, and %HOME%). Generally, things work
fine. But when things break it's often hard to debug and trace back to the
fact that some package author didn't take spaces properly into account.
Set a HOME environment variable to your %USER_PROFILE%. Make it
%USER_PROFILE%/home if you must, but I use the former.
Start by running emacs without any customization.
runemacs -Q
When that works, add your customizations one at a time.
n.b. This answer is not relevant to the original question (which was about Windows), but may be useful to Unix users searching for this error message
You will get this error also if emacs does not have the correct permissions on the .emacs.d directory.
Check it
ls -ld $HOME/.emacs.d
And make sure the user you are running under has rwx permissions!
I got similar problems when I installed the new version of emacs on a new installation of the ubuntu 12.10. I get the problem fixed by chmod 777 .emacs.d, that is, as the previous post pointed out, the emacs does not have the access right to .emacs.d directory. Hope this help.
Related
I am trying to use models from Hugging Face, but VS code always downloads them into my very limited C: drive; C:\Users\<user>\.cache.
How can I force it to cache to a different drive?
Things I've tried:
Googling: only seen threads for Linux, whose commands do not transfer over. Could not find clear equivalent commands for Windows.
Running a new instance from terminal code --user-data-dir E:/.cache
Fully un-installing VS Code, downloading a portable version, and making a data folder (following these instructions)
All of them still result in caching to C:\Users\<user>\.cache.
From some further research, it appears this is currently not possible.
However, I've found that symlinks is a great temporary workaround. In short,
Create a folder on a drive/partition with an abundance of space, i.e. E:\TempCache
Close any instances of VS Code, if any.
Navigate to C:\Users\<username>\.cache. If there's anything in it, cut them over to E:\TempCache, and delete the whole .cache folder.
Open cmd with admin rights, and enter mklink /J "C:\Users\<name>\.cache" "E:\TempCache". This will re-create an empty .cache folder.
Next time VS Code is ran, it will automatically detect and use the .cache folder on the C drive like nothing changed.
I have the following instruction in I need to perform to run a web app I that have received:
"Go to the directory where the app is unpacked and type 'gradle jettyRun'."
Sounds simple enough, if you know the commands for finding out your current directory and changing it. The problem is, searching for these basic things only nets a huge amounts of irrelevant answers to much more advanced questions where the same terms are used with a slightly different meaning. So what do they exactly mean by what they say and how do I achieve that? It sound's so simple I'm almost embarrased to have to ask it, yet I'm still dumbfounded by the MySQL command line enough to have to.
This has nothing to do with the MySQL command line (>>>), or MySQL itself. This is simply saying:
Open your terminal or shell. In Windows, this is called Command Prompt.
Change the directory to where the files are located, you do this with the cd (change directory) command.
Next you simply type gradle jettyRun.
I am trying to edit my MATLAB path. I have permission, it does not give me an error when I try to edit via the GUI, but when I close and reopen matlab, the changes are gone.
I have edited ~/matlab/startup.m to include the paths I need the most, and this works, but why can't I edit the path via the GUI?
I assume it is saving my path (because there is no permission warning/error), but it may be that something is destroying those changes, or reverting upon each startup, I guess I'm just not entirely sure where to look.
EDIT: I should mention that I did not set this machine up, and it's a UNIX box that may have other configuration scripts that are messing with the path. (I checked bashrc but there's nothing there that would interfere)
Found a script that the previous admin put into the machine's global profile that automatically sets the path to include various toolboxes.
I can't run my ipython notebook with the --read-only option.
It says :
[NotebookApp] CRITICAL | Unrecognized flag: '--read-only'
It's weird because I've seen several blog mentionning it.
I'm running with the 1.1 version of ipython.
Do you know if this option was removed or moved elsewhere?
There is a super easy way to do what you're trying to do I think though--simply use OS security.
Do this:
When you're ready to deploy to read only, make a special folder
for your read-only work, and copy your *.ipynb files into that.
Make the *.ipynb files read-only at the Linux level: chmod 444
*.ipynb.
Run iPython Notebook from that directory. Use a different port
so that it won't conflict.
Send the URL to everyone using the URL that has the read-only
port.
They can then read it all, even run code, but they will not be
able to save changes.
They cannot navigate anywhere outside that directory. E.g. the
little home icon only brings them to the folder with your read-only
content.
Thus they have full access to the page and its functionality, but
cannot mess it up on anyone else. And all you need is a cp and a
chmod. Profit!
At least this solved my need. I have my regular port with write authority for all my development, then I copy it over, chmod it, and let people at it. Works just fine for me.
Hope this helps others!
Yes the option was removed, it might be re-introduced in another form later when nbconvert/nbviewer is refined, but you better run your own local instance of nbviewer to this effect.
Is there a good technical or other reason why the MS hard-coded the Documents folder as the default location for WindowsPowerShell? MS has been criticized for too much configuration over convention in the past (WCF?), but a case can be made for more configuration in PowerShell. I, and I presume most developers, like to keep their development work centralized in a separate folder or volume away from personal and system files.
For instance, if you install PoshGit, it will install itself in C:\Users\Your Name\WindowsPowerShell\Modules. I don't want it to install itself there but in my own development partition d:\Dev\PowerShellScripts. There's no environment variable that controls this location.
Is there a reason for this or I just don't get it?
Can you explain yourself a bit more.
According to my understanding PowerShell.exe interpreter base directory is the one defined by $env:HOMEDRIVE, $env:HOMEPATH, that can be change using the user profile.
As shown in the screen shots here under :
Edited :
Ok, the screenshot comes from the user property in Active Directory MMC, you've got a simplest one in your windows seven user properties. But this has nothing to do with your problem.
Your problem is around the module installation. The think that you have to know is that Modules can be installed quite everywhere (even on a shared directory with some tricks). By default the environnement variable $env:PSModulePath points to the paths where Get-Module -ListAvailable look for them. So you can add d:\Dev\PowerShellScripts\Modules in this path and then copy the subfolder of C:\Users\Your Name\WindowsPowerShell\Modules created by PoshGit inside your Modules directory and it should work. Modules as opposite to Snapins don't need to be registered.
Now the reason why PoshGit choose to put module in user profile, raser than let you choose the place is PoshGit installer problem.
For more explanations read about Modules and about_environment_variables.