I recently, for work reasons, had to switch back from using Linux to using Windows on my laptop. I have not changed my emacs configuration in any way, but now when I start up emacs, twice I get a "Windows Security" network login prompt for a server I previously had mapped a shared folder to. Ever since I deleted that shared folder, emacs now prompts me twice during the startup sequence to log into the server. Nothing in my config files points to this server, and I don't have this problem on any other machine where I use the same configuration.
Any idea why this might be happening and how to make it stop?
EDIT:
I've identified one line of the config file that triggers it. It's
(setq org-completion-use-ido t)
(setq ido-everywhere t)
(setq ido-max-directory-size 100000)
(ido-mode (quote both)) ;; Evaluating this line pulls it up.
Based on the original poster having narrowed down the issue to ido-mode, the likely suspect is the file where the variable ido-save-directory-list-file points to.
The printout for describe-variable of the aforementioned variable is as follows:
ido-save-directory-list-file is a variable defined in `ido.el'.
Its value is "~/.emacs.d/ido.last"
Documentation:
File in which the Ido state is saved between invocations.
Variables stored are: `ido-last-directory-list', `ido-work-directory-list',
`ido-work-file-list', and `ido-dir-file-cache'.
Must be set before enabling Ido mode.
You can customize this variable.
This variable was introduced, or its default value was changed, in
version 24.4 of Emacs.
Related
When I change any environment variable in Windows using GUI (System Properties/Environment Variables/System Variables) changes are reflected immediately in cmd terminal, but PowerShell shows an old value.
Here cmd recognized that I changed JAVA_HOME value from C:\Users\nikif\.jdks\openjdk-19.0.1 to C:\Users\nikif\.jdks\corretto-16.0.2
PowerShell still shows the previous value - C:\Users\nikif\.jdks\openjdk-19.0.1
Is there any command that will make PowerShell recognize the environment variable change made in GUI?
Or maybe there is a better way to change the environment variable from PowerShell?
Thank you.
This all should really be a comment (I tried above), but attempting to explain why the question, as it stands, is too vage requires just more explaination.
Processes get their environment when started by the OS. They basically get a copy the environment as it was at that point in time. When you start a process you can (using the respective APIs) pass additional or altered environment variables.
During the existance (runtime) of a process you cannot change the environment.
Shells are a common exception, as they provide specific syntax that does that (set NAME=VALUE in CMD.EXE and $env:NAME="VALUE" in PowerShell, for example). An application itself could also do such stuff from its code using respective APIs. But in general, there is no way to change variables from the outside.
One process will never see the changes done to the environment in a different process. For example, if you have to separate CMD.EXE sessions running and change a variable in one of them, the other will not know. The environment is private to each process.
A potential exception is the (global/system) environment variables you can set using the Computer/Properties/Environment setting (applet). The system will send a WM_SETTINGCHANGE window message indicating the that environment has changed. Applications can register to this message and act accordingly.
However, neither PowerShell nor CMD.EXE do seem to listen to this message (it would require a (hidden) Window anyway and both are console applications). And frankly, it would be not good if they did. Consider CMD.EXE just execuing a batch file and a variable (say PATH) changes underneath - security issues and general havoc all over.
I try to open a file using emacs c-x c-f /Users/fred/Dropbox/foo/bar/bam/baz.txt.
In the mini buffer it says...
"File exists, but cannot be read".
...Next I do m-x revert buffer. Now in the mini buffer it says....
"Opening input file: Input/output error, /Users/fred/Dropbox/foo/bar/bam/baz.txt"
...I do m-x revert buffer again and this time the file reads in fine.
The problem is that a file should open on the first try, no questions asked!
This is more or less a repeatable problem (specifically I have gotten "File exists, but cannot be read" several times in the last 2 weeks. I try various work arounds to open the file (e.g. hit m-x revert buffer twice as described above). I usually (always?) am able to open the file. And once I finally DO open one of those obstinate files, it easily opens using emacs in other contexts (e.g. new windows, or re-opens when I have closed the buffer).
<<< UPDATE ~2 DAYS AFTER ORIGINAL POST -- START OF SECTION >>
I seem to be able to reproduce a very similar behavior when I start emacs using an init file that starts an emacs with about 30 different text files open. (I.e. part of the init is to open these files in emacs). When I change the emacs buffer (c-x b) to point to some files, call them GoodFile1, GoodFile2, there text is visible, i.e. all is well. For other files, call them BadFile1, BadFile2, BadFile3, when I switch to them the screen is blank and I know they have LOTs of text in them. I haven't seem any error messages akin to "File exists, but cannot be read", but still this is bad behavior and it seems related to the original problem. Next, similar to the originally reported case, I hit m-x revert buffer between 1 and 4(?) times and, poof!, the text appears and I am begrundgingly happy again. Now, here's the interesting bit: when I start a new terminal window and fire up an emacs loading the same init file then the formerly bad files (e.g. BadFile1, BadFile2, BadFile3) are now visible right from the start -- as they should be on a normally functioning computer. It is as if a formerly blank seeming file changes some sort of state so that when a fresh emacs tries to open it the file shows up as it should. What kind of state change is involved? I think it has to do with smart sync. So the question is, assuming it is smart sync, how to avoid this annoying required behavior of hitting revert buffer a buncha times? Does it last between boots? I am pretty sure unix touch did not help. Maybe there is some other operation to perform?
Note: On this machine I always start emacs with 'emacs -nw -l my_special_emacs_init.el' (GUI's are for wimps (-;)
<<< UPDATE ~2 DAYS AFTER ORIGINAL POST -- END OF SECTION >>
All annoying bad behavior happens on my new set up.
On my old setup, I have never gotten any thing like this behavior over years, possibly decades. (and, on my old setup, I tried the specific file mentioned above and it opened fine)
So, what, you may ask, is different between my new setup and my old setup?
OS / Hardware:
New Setup: Catalina 10.15.6 on a brand new Mac Book Pro.
Old Setup: Mohave 10.14.6 on a Mac Book Pro "early 2015" (and has never had this issue in prior OS's either)
Dropbox:
New Setup: Smart Sync On. I am using Dropbox with Smart Sync Turned on such that files are by default "online only". "online only" is a misnomer. Some files end up locally on my hard drive. Smart sync seems to figure out what files to store locally on the mac. I suspect that knowing how it does this will fix my problem.
Old Setup: Smart Sync Off. I have been using Dropbox for years but have stayed far away from Smart Sync and have never had a problem opening a file.
Emacs Version:
New Setup: GNU Emacs 27.1
Old Setup: GNU Emacs 22.1.1.
Clearly it can't be a permissions issue bc I've never had this problem on my old setup.
Any clues?
Does anyone know of any diagnostics I can do to "dig under the hood" when I find another case of this "File exists, but cannot be read".
Any thoughts on whether it is OS difference? Hardware difference? Dropbox Smart Sync Yes vs Smart Sync No difference? Emacs version difference?
<<< UPDATE ~2 DAYS AFTER ORIGINAL POST -- START OF SECTION >>
My current hunch is the the 'state change' mentioned in the update above is related to smart sync somehow figuring out that the user wants a given file cached locally. The bad behaving files are non-local so poor emacs can't open them. Whacking them with 1 to 4 revert buffers tells smart sync to make the given file local. Alas, smart sync is not smart enough to figure out what emacs users want right off the bat! Perhaps emacs can be changed in such a way as to tickle smart sync into realize that the given file should be made local local Or we can petition Dropbox to respect emacs. Or I am not using smart sync correctly. Thoughts?
<<< UPDATE ~2 DAYS AFTER ORIGINAL POST -- END OF SECTION >>
I had the same problem. This is the root cause, and solution:
https://emacs.stackexchange.com/questions/53026/how-to-restore-file-system-access-in-macos-catalina
In short, give /usr/bin/ruby full filesystem access in General Settings -> Security & Privacy -> Privacy
I had this problem on Big Sur; giving Full Disk Access to /usr/bin/ruby solved the problem.
Note it is not so trivial to do this, you have to press cmd-shift-dot in the system preferences file chooser to enable the usr directory to be visible at the Macintosh HD level.
First off, I'd like to apologise if this has already been covered. It's difficult to filter through all the existing issues similar to this one.
So in Windows there is two (as far as I'm aware) ways to set environment variables. First one is through the Command Prompt and the second is through System Properties in the Control Panel.
The former would be more desirable for me however I have an issue where the variable only lasts and exists in that session. This gets considerably annoying when I have to re-set my Java path every time.
The latter is what I have to resort to, it takes time and once in a blue moon I'll forget where to locate the menu.
Is there something I have to do in the Command Prompt to get it set permanently? Possibly a flag or switch to append to the command?
The SETX command can modify environment variables persistently:
Setx provides the only command-line or programmatic way to directly
and permanently set system environment values.
It's quite a powerful tool but read the notes carefully on that page though because there are a few little catches to using it.
This question already has answers here:
How can I have a portable Emacs?
(5 answers)
Closed 9 years ago.
In few weeks I'll be on a competition for website development.
I can use Emacs from a usb stick. I can't write to system drives anything so all Emacs configs and plugins are needed to be loaded from the usb stick. These are rules so I would rather not break them.
So I think this can be done with setting load-path or recompiling emacs to look config files from the usb but I no idea how this would be done in practice.
GNU provides compiled binary releases of Emacs for Windows. They require no installation or compilation.
Download the version you want (the latest at the time of writing is emacs-24.3-bin-i386.zip).
Optionally, verify its signature with GnuPG.
Extract it to your flash drive.
If a %HOME% environment variable exists, Emacs will use this as your home directory. Setting %HOME% to D:\ will cause Emacs to read its configuration from D:\.emacs or D:\.emacs.d\init.el. It will also cause package.el to install packages to D:\.emacs.d\elpa\.
If you are permitted to modify environment variables for your user, go to Computer ⟶ Properties ⟶ Advanced system settings, click the Environment Variables button, and add or modify HOME, setting it whatever drive letter your flash drive gets assigned. You will need to reboot (or at least log out and back in) before this variable takes effect.
If you are not allowed to modify this variable, you can use set HOME=D:\ in cmd.exe, then execute Emacs from that shell. You may want to write a short batch script to do this and add it to your flash drive.
To run Emacs, use bin\runemacs.exe.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 4 years ago.
Improve this question
See Update Below
Let me explain the situation:
In the System Control Panel, I setup JAVA_HOME as C:\Java\JDK1.6. However, when I went into a terminal window to see what's going on, I got this:
echo %JAVA_HOME%
D:\Program Files\Java\jre6
Where in the hell is this getting set, and why isn't it picking up the value I set it in the control panel? Other environment variables I put in are set, but it looks like something is overriding it.
Word of Warning:
Although I'm an Administrator on the system, they've put all sorts of goofy restrictive policies on it. For example, I can't set my Recycle Bin not to warn me when I delete something. The Property setting isn't there when you right click on the Recycling Bin. I also can't do regedit. To set the environmental properties, I setup a MCC Console, and pull up the System Control Panel thorough there.
Update
Yes, I know the environment variables don't get reset until I open a new command line prompt. However, this is something I set a couple weeks ago, and the machine had been booted a few times since.
I have it set in the System Variables (the lower box). If I put it in the User Variables (the upper box), it does get set correctly, but my PATH is set incorrectly if I put %JAVA_HOME% in the path.
Going back through my questions and tying up all the loose ends...
Turned out that the administrators disabled the ability to set PATH on the system. the admins had a policy that if they didn't understand something, they locked it down. And, since they didn't understand much, they locked everything down.
This was a government office, and the admins locked down anything that didn't involve writing bureaucratic regulations or memos in Microsoft Office that no one bothers to read.
Unfortunately, I was a developer there, so I kept running into these walls. My supervisor quit, and took me to his new site. I'm glad I'm out of there.
When you change the environment variable via the control panel, it only changes the environment in the process that it is running.
When a process starts it will "inherit" the environment of the parent at the time it was launched. Changes afterwards are not propagated to child processes.
You may have to relaunch your terminal, or to be sure, log off then back on.
You have to open a new command prompt to actually "see" the new variable (or call the set command in the cmd window for temporary changes or setx for permanent changes).
Environment variables are inherited from the parent process when a process is started. When you change or add a variable in the Control Panel, your shell (i.e. the main explorer.exe process) gets to see the change immediately, but not any other already running process. When you start a new process with explorer.exe as the parent process, e.g. by double-clicking a file or chosing Start+Run, the newly created process will also see the updated environment variable(s).
A nice tool for analyzing such kind of things is Process Explorer. It shows you the relationship between parent and child processes and double-clicking a running process shows you a detailed dialog with a tab listing all environment variables of the current process.
The problems is, all executables are in bin folder so you should set %JAVA_HOME%\bin inside your PATH variable.
You were almost there my friend, it usually happens.
Marce