Emacs 24 in Ubuntu 14.
I have file opened only in emacs, and it gives me this constantly, after each saving. that is annoying.
This is strange, because earlier everything worked fine. I can hardly guess what could I break during this time. I'am total newbie in Ubuntu, using it according to instructions found in internet.
Now I'm using emacs 23, everything is fine. I guess, I need auto-syncronization of opened buffer with saved file right after saving. Anyway, how can I fix it?
It sounds like some other program on your computer is reading the file when it changes, and possibly even introducing changes (perhaps just to the modification time, rather than to the contents). It's hard to say off-hand just what that would be.
A workaround try M-x global-auto-revert-mode. It will only auto-revert if you have no local modification since the last saving. This is generally a nice mode to turn on if you use multiple editors, and I keep it enabled all the time.
Other ideas:
Check if any other process currently has the file open using fuser /path/to/filename.txt (note: it only shows open file descriptors, not processes that hold the file content in memory and write it later)
Do you use any non-standard filesystem? (check with df -h /path/to/filename.txt and mount)
Is your system time stable? (Manually check date, scan the output of dmesg for obvious errors concerning timekeeping, and look for errors related to NTP in the logfiles in /var/log/.
Related
I use many VS Code workspaces throughout the day. Most of them are backed by directories on NFS-mounted drives, which are only mounted while I'm VPN'd in to my employer's network. Opening VS Code while not VPN'd in will cause all of my windows to close, leaving me with blank/empty workspaces, and then I have to set them all back up again in the morning. It only takes a few minutes to do, but I'm lazy and it's not neat; I like things neat. I know that I can start VS Code without any workspaces using the -n option, which is great, but then the next time I start up the editor for real (i.e. for work purposes), all of my workspaces need to be reopened again (see previous statement re: I'm lazy and I like things neat).
Is there a way to indicate that I want to start VS Code without any project just this one time, and then the next time I start I want all of my old workspaces to reopen as normal? Alternately, does anyone know where the state information is stored and how to edit it? I have no qualms about saving it off and then restoring it after I'm done.
Absent any miracle solution, I've at least found the correct file to manipulate: the storage.json file, which on MacOS is found at:
~/Library/Application Support/Code/storage.json
I wrote a Perl script to do the manipulation. When I want to go "offline" it reads in the JSON file, loops through the opened windows, identifies the ones I don't want, and removes them using jq, then launches VS Code. When I'm ready to go back "online", I read a backup of the original file looking for the windows I previously removed, adds them back in (also using jq), and then launches VS Code.
The Perl script is a bit rough around the edges to be posted publicly, but people might find the jq helpful. To delete, you want to identify the windows to be removed as (zero-based) indexes in the array, and then delete them with the following:
jq '. | del(.windowsState.openedWindows[1,2,5])' '/Users/me/backups/online-storage.json' >'/Users/me/Library/Application Support/Code/storage.json'
If you want to add them back in at some point, you extract the full JSON bits from the backup file, and then use the following command to append them to the back of the array:
jq '.windowsState.openedWindows += [{"backupPath":"...",...,"workspaceIdentifier": {...}}, {"backupPath":"...",...,"workspaceIdentifier": {...}}, {"backupPath":"...",...,"workspaceIdentifier": {...}}]' '/Users/me/backups/offline-storage.json' >'/Users/me/Library/Application Support/Code/storage.json'
The inserted JSON is elided for clarity; you'll want to include the full JSON strings, of course. I don't know what significance the ordering has, so pulling them out of the middle of the array and appending them to the end of the array will likely have some consequence; it's not significant for my purposes, but YMMV.
I uploaded Fabian Vogt's micropython port to my TI Nspire CX CAS, together with a couple of *.py.tns files to try. I can't find a way to load/launch those files.
As micropython does not include the os module, I can't use os.chdir to change the current directory and load the *.py files from the python shell. I tried from python shell: open("documents/mydirectory/myfile")
with different extensions .py or .py.tns, without success.
I don't think the Nspire has anything like the terminal commmand line either.
Thanks for your help,
There are 2 ways that you could do this, one easy way and one tedious way.
1. Map .py to micropython in your ndless.cfg
(ndless.cfg should be at /documents/ndless/ndless.cfg)
Like so:
ext.xxx=program-name
ext.xxx=program-name
ext.txt=nTxt
ext.py=micropython
ext.xxx=program-name
ext.xxx=program-name
You can edit this file either by copying it back and forth from your computer using TiLP or the official software, or you can edit it on-calc using nTxt. (This requires a bit of fiddling with making a copy of ndless.cfg so that the mappings still exist to open the copied file ndless.txt).
Ndless should come with a standard ndless.cfg containing basic bindings for nTxt and a few popular emulators. If you don't have one, get the standard one here. It will scan all directories (at least /documents/*, AFAIK) for programs. I've found that removing lines related to programs not on your Nspire will decrease load time.
2. Proper way to run a file in Python
To run a file in Python, you should do something like this:
with open("/documents/helloworld.py.tns","r") as file:
exec(file.read())
This will properly close the file after executing, which I've noticed is quite important on the Nspire, as leaving files open has given me trouble before. Of course, if you'd like, you can do exec(open("...","r").read()) and then handle closing the file yourself, but be warned: bad things can happen if you forget.
Also, you must remember to add the leading / and the .tns extension, or else strange things will happen, especially with writing to files.
That's about it! Feel free to ask more questions if needed, I'll be watching the ti-nspire tag.
(Just realized this question is quite old, but I guess it still might be helpful for others who end up on empty questions months later while trying to figure something out :P)
Specs: SAS 9.3, GNU emacs 23.4.1 (2012-06-05), and what I think is kind of an old version of ESS (sometime in 2001 maybe?). Unix -- I think SunOS 5.10.
I'm a fairly new emacs user and a very new user of ESS[SAS]. I have noticed that code which works when submitted as an entire file will not work when I submit it region by region. Here is an example:
libname mylib "/.";
data temp; set mylib.temp; run;
Assume that I have a directory as specified in libname and there is a SAS dataset called temp in it -- my code works properly when I submit the whole thing, but if I run just the first line and then the second, it tells me that "mylib" is not defined.
Based on the behavior of the log files -- the second submission creates a log file that overwrites the first -- I think what is going on is that it's starting a new SAS session with each submission. Why might it be doing this? (ESS does not do that with R code -- I can run a snippet to define a variable and then that variable stays defined.) I find I make fewer programming errors if I test things incrementally rather than running all my code in batch mode, and the GUI for SAS in unix leaves something to be desired, so I would really like to find a fix to this.
The only other clue I have is a pair of warnings I get on every submission:
NOTE: Unable to open SASUSER.REGSTRY. WORK.REGSTRY will be opened
instead.
NOTE: All registry changes will be lost at the end of the session.
WARNING: Unable to copy SASUSER registry to WORK registry. Because of
this,you will not see registry customizations during this session.
NOTE: Unable to open SASUSER.PROFILE. WORK.PROFILE will be opened
instead.
NOTE: All profile changes will be lost at the end of the session.
I googled those warnings separately and found they're commonly associated with a corrupt profile, but unfortunately the recommended fix did not fix anything (after deleting the iffy profile, it just restored itself and the error persisted). I am not sure whether this is related or not.
I realize this question might be out of scope for stackoverflow; if it is, a redirect to a more appropriate forum would be much appreciated.
I have noticed that MATLAB (R2011b on Windows 7, 64 bit) tends to slow down if I am in debugging mode for a long period of time (e.g. 3 hours). I don't recall this happening on previous versions of MATLAB.
The slow down is small, but significant enough to have an impact on my productivity (sometimes MATLAB needs to wait for up to 1 sec before I can type on the command line or on the editor).
I usually spend hours on debugging mode (e.g. after stopping at a keyboard statement) coding full projects in this mode. I find working on debugging mode convenient to organically grow my code while inspecting my code anytime in execution time.
The odd thing is my machine has 16 GB of RAM and the total size of all workspaces while in debugging mode is usually less than 4 GB. I don't have any other large process running in the background, and my system reports ~8GB of free RAM.
Also, unfortunately MATLAB does not let me call pack from debugging mode; it complains with :
Warning: PACK can only be used from the MATLAB command line.
I have reproduced this behavior after restarting MATLAB, rebooting my system, and on different days. With this, my question/s are:
Has anybody else noticed this? Is there anything I could do to prevent this slowdown without exiting debugging mode?
Are there any technical notes or statements from Mathworks addressing this issue?
In case it matters, my code is on a network drive, so I added the following on my startup.m file, which should alleviate any impact on performance resulting from it:
system_dependent('RemoteCWDPolicy', 'None');
system_dependent('RemotePathPolicy', 'None');
system_dependent('DirChangeHandleWarn','Never');
I have experienced some similar issues. The problem ended up being that Mathworks changed how Matlab caches files. For some users, it is now storing data in the TMP folder as defined by the environment variables. This folder was being scanned by anti virus and causing a lot of performance problem. Of course, IT wouldn't let us exclude the TMP folder from scans. So we added a line to our start up script that changes the environment variable of TMP to some other location within an excluded folder.
You don't have to worry about changing the variable back or messing up other programs. When applications launch, they copy the environment variables into their own local instance of them. Any changes made to them only change the local copy of those variables, not the system copy.
Here is the function you will need.
setenv('TEMP', 'C:\TEMP');
I'm not sure if it was TMP or TEMP. Check your environment variables to be sure.
I am using MATLAB R2011 on linux 10, windows 7 (32 bit).
I experienced MATLAB slowing down while printing simple variables in command window.
It turned that there was one .m file loaded in my Editor.
It was a big file with 10000 lines. These lines were simple data that should have been saved as mat file. When i closed this file, the editor was back to its normal speed.
I have Emacs open but accidentally I've deleted the .emacs file it read when it started. This represents about 15 years of tweaking. (I know, I know, backups.)
Is there a way to get Emacs to write out the .emacs file I've deleted?
I wouldn't normally ask such a lame question on SO but I know I only have a day or so before this Emacs session ends.
As ayckoster suggests, you might try a file recovery or forensics tool like The Sleuth Kit. Or, and this may seem crazy, if you're on a Unix-like system, you could search through the raw disk device (on the Mac I'm currently on, that would be /dev/rdisk1). Seriously, several times I've been too lazy to break out a full-blown recovery tool but instead used something like sudo less -f /dev/rdisk1, searched for a string I knew was in the file (global-set-key, anyone?), and succeeded in recovering the file's original content.
If you have Emacs' backup feature turned on, you should have a copy of your next-to-last .emacs file in ~/.emacs~. If so, just rename that one to ".emacs" and you will have the .emacs file with all but your latest changes. Even if you don't currently have backups enabled, you might still have a substantial chunk of your .emacs file in the last backup on file. You should also look at the value of the variable "backup-directory-alist" - it specifies location(s) for backup files to be stored if the default (same directory as modified file) isn't used.
Otherwise, how good is your memory... ;-)
EDIT: Since you don't have a backup of your .emacs file but you have a running Emacs instance that was started with that .emacs file, another thing you can do is to save all the custom settings that would have been defined in your .emacs file. To do this, do something like:
(setq custom-file "/my/home/directory/.emacs-custom.el")
(custom-save-all)
Then, you could create a new .emacs file and add the following lines to it:
(setq custom-file "/my/home/directory/.emacs-custom.el")
(load custom-file)
That will at least restore some of the custom variable settings that were in your .emacs file.
Emacs evaluates your .emacs file and afterwards it is closed. So basically you cannot get your .emacs back.
A solution might be to use a file recovery application. The odds of your .emacs being on your hard drive are quite good.
As most such programs cannot deduce the file name or directory name of the deleted file you have to know the content of your .emacs.
Then you can restore all currently deleted files in some folder and recursively search for the contents of your .emacs.
This process might take very long. You have to decide if its worth your effort.
I don't know of any way to get Emacs to provide the original .emacs file, but you can certainly interrogate the loaded function and variable symbols, and obtain their values.
This would be rather a lot of work, but I think in theory you should be able to obtain a good chunk of this data in some form or other, if you succeeded in filtering it all down to what you knew was yours.
For evaluated functions, (symbol-function 'SYMBOL) will return a (less-readable) definition of the supplied function. You could then use (fset 'SYMBOL VALUE), where VALUE is the result of the call to symbol-function, to define that function in a new .emacs file. That would give you an approach for recovering your defined functions.
http://www.gnu.org/s/emacs/manual/html_node/elisp/Function-Cells.html
http://www.gnu.org/s/emacs/manual/html_node/elisp/Symbol-Components.html
You might also look at:
How to print all the defined variables in emacs?
This is a very incomplete starter, but given time constraints I'm posting and marking it community wiki, if anyone wants to run with it.
A how-to for dumping the state of the application in a reliably restorable fashion would be a great start, if the current session is definitely going to be killed (or even if it's not, actually, to guard against crashing or other mishap).
You could potentially re-tag this with some more general data-recovery type tags, to expand the audience.