Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am having difficulties with emacs server closing unexpectedly. I am connecting over SSH with PuTTY from a Windows 7 machine to an ubuntu machine, using xming to handle x11 windows. It seems to be something to do with the way putty closes connections.
I start an emacs server using emacs --daemon. I then connect to it using emacsclient -c. When I close the resulting window, the emacs server stays running, as it should, and I can reconnect using emacsclient -c again. I can then close the putty session, reopen it, and reconnect again. This is all as I expected.
The trouble comes when I close the SSH session without first closing the emacs window. When reconnecting, the emacs server is no longer running. This only happens when the x11 version of emacs is running. If I start emacs in the terminal with emacsclient -c -nw, the emacs server stays running even if I don't exit emacs before closing PuTTY.
I'm not sure what could be causing this, or where to look to trouble-shoot this more.
There is apparently a bug in the Gtk libraries used by the default emacs binary in Ubuntu.
If you use the lucid variant (eg emacs23-lucid) then things do indeed work swimmingly. I connect, drop, reconnect, ... hundreds of times between reboots.
I re-connect either in text mode, or x11 mode, and set up simple aliases for this:
alias emt='TERM=vt100 emacsclient -nw'
alias emx='emacsclient -c'
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I am using the Fish shell (version 3.3.1) on MacOS. Every time I run a command it shows this error multiple times:
error: Unable to open universal variable file '/': Permission denied
The commands still run perfectly, but it's very annoying to see these errors. They are still on the screen even after a clear command.
Fish has a feature where it'll store so called "universal" variables to a file on disk, so they can easily be persisted and shared among open fishes.
This error:
error: Unable to open universal variable file '/': Permission denied
Shows that fish is trying to open the file at "/", the root of the filesystem. This points to a misconfiguration, because "/" isn't a file, by definition. It's a directory.
The file is supposed to be in the config directory, which is at:
$XDG_CONFIG_HOME/fish, if that variable is set
$HOME/.config/fish, if it isn't
I can't find the specific sequence to reproduce this, but it appears that $XDG_CONFIG_HOME or $HOME are set when fish is started (by its parent process, probably the terminal), and to non-functional values.
Was having this same issue after installing using brew install fish.
What finally worked was uninstalling fish.
brew uninstall fish
Then removing fish from my .config folder.
cd ~
rm -rf .config/fish
Then I just installed fish using the fish GUI installer.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
The community reviewed whether to reopen this question 23 days ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am using XMing to run Emacs from WSL, which is working quite well. My issue is when trying to share folders between Windows and WSL. I have tried the following:
Project located in the Windows file system, accessed via /mnt/ in WSL
Symlink (created in WSL bash) of project located in the Windows file system
Copy the project to the WSL file system
Out of the 3 listed options, only the last works with projectile (and likely other Emacs packages). But I need to be able to access/modify the files from Windows as well, so that is not a viable option.
Has anyone found a good solution for this?
I do it so (also to sync between Windows_laptop & Ubuntu_pc):
I have folder "workspace"
and symlinks to it: windows symlink under win and linux symlink under linux.
%USERPROFILE%\Cloud\workspace
for Win usage:
made windows symlink: %USERPROFILE%\workspace -> %USERPROFILE%\Cloud\workspace
for Ubuntu usage (WSL):
made linux symlink: ~/workspace -> /mnt/C/Users/USER/Cloud/workspace
May this help?
One of the advantages of WSL (windows subsystem for Linux) is that you can share files easily with your windows.
I have used the below codes with WSL Ubuntu (but this should work with other versions of Linux as well). Using /mnt will do all the magic.
Syntax:- cd /mnt/drive/Folder/Subfolder
Sample code:- cd /mnt/c/Users/Saswat
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm trying to disable the 'r' and 'o' commands in vim so people who use it can't open other files from within vim.
I tried to use the cmap r <Nop> and cmap o <Nop>, which work but have an undesirable side-effect... those 2 letters can never be used in vim command line nor when searching for something...
If you try to search for the word, "word" the search line displays: /wd.
So is there another way to disable opening files from with vimrc ?
If you really want to secure Vim (and not just provide a superficial appearance of certain disallowed features), you have to remove those features from the source code and compile (and test!) a limited version of Vim. (Or maybe you can use a operating-system wrapper that sandboxes the Vim process and filters certain system calls, but I don't know any such thing.)
Any Vimscript obstruction can be circumvented: Your remappings can be undone via :cunmap, any more elaborate protection in Vimscript can be stopped by pressing <C-c> at the right time.
You can launch Vim with a flag:
$ vim -R (readonly)
$ vim -Z (restricted)
$ vim -m (no writing)
$ vim -M (no text modification)
But none of those will block :e or :r or any of the myriad of similar commands. And… the ~/.vimrc could probably be edited with nano or whatever to remove any eventual command anyway.
What about completely sandboxing Vim or its user?
What about explaining why you would want that?
If you want to allow editing of a specific file with root permissions, without allowing commands or editing of other files (as you've now indicated in a separate comment), why don't you do this as outlined in man 8 sudoedit:
Temporary copies are made of the files to be edited
with the owner set to the invoking user.
The editor specified by the policy is run to edit the
temporary files. The sudoers policy uses the
SUDO_EDITOR, VISUAL and EDITOR environment variables
(in that order). If none of SUDO_EDITOR, VISUAL or
EDITOR are set, the first program listed in the editor
sudoers(5) option is used.
If they have been modified, the temporary files are
copied back to their original location and the
temporary versions are removed.
It is much safer to launch the editor in the user's context, not root context. (Plus, the user get's his Vim settings, not the unmaintained ones from the root account!) Just the sync back of the edited temp file must be done with root priviledges; with the help of sudo, all of this can be implemented in a few lines of shell script.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
When you double click on a file opens a new window emacs. Tell me how to do to open in the same
I beg your pardon, Linux OS
I installed emacs23
Then i run the command:
emacs --daemon &&
emacsclien -c &&
emacsclien -c
And i have opened 2 windows instead of one
You don't provide enough information, such as what OS/windowing system you're using, but the answer involves using emacsclient. The wiki page has all the details of using emacsclient, though not how to set up your OS/windowing system to associate the file types with emacsclient (instead of emacs).
You have a single Emacs instance with two windows. You have two windows because you explicitly asked for them by passing the -c option to emacsclient.
I use Emacs remotely using X-Server in a Windows client and Linux server. I noticed that I can halt it using ctrl-z and then type fg 1 to get it working again. Is there some way that I could get it to halt on the machine that I am on, and then log into a different machine and start where I left off? When I start a new ssh session, the emacs job isn't associated to my terminal. There must be someway to "steal" it.
Also, maybe there's an Emacs feature that will do basically the same thing. However, I think closing and re-opening all my files and buffers would take quite a while.
Expanding on the idea of using emacsclient, you can look at what what someone did to solve the problem of editing a file from a different machine than where (s)he started running Emacs.
As of Emacs 23, you can run emacsclient in terminal windows using the -nw option.
Other solutions you might want to try are to use:
gnu screen
vnc
For years I used screen to "attach" and "detach" from a virtual terminal that sounds like your usage model. If you have the ability to use graphics... vnc is really great, just do your work in a vnc session and connect to it any machine.
And your last idea is already implemented by the package desktop (which is bundled with Emacs). Take a look at the wiki page for session management, which includes other alternatives to desktop, as well as add-ons for desktop to lazily load files.
You can run emacs as a server, and use emacsclient to connect to it. You can open multiple connections to the same emacs server, via ttys or X11.
When doing this, C-X C-C will close your connection, and leave the server running.
A simple way to do this by invoking emacs as follows. This will connect to the server if one is running, or create one.
emacsclient --alternate-editor="" -c
Sometimes I will be at work and have to run out the door leaving my Emacs session as it was. Later, I will open an Emacs instance to the same machine (usually using remote SSH) and find that I have files open in Emacs. Now the good news. Emacs allows you to "steal" those files using M-x recover-this-file. I recommend one of Trey's solutions if you can plan ahead. If not, you can use this recover file technique to keep progress moving.