I'm trying to move most of my editing and shell activities into emacs, so that I can easily continue my workflow from different computers. I also have different emacs instances for my different projects. E.g., I start up:
emacs --daemon=project1
emacs --daemon=project2
Then whenever I want to start a frame to work on project1, I do:
emacsclient -s project1 -c
Mostly it works great, but I have trouble with executing tools from my emacs shells that are trying to fire up an editor using $EDITOR. Of course, what I would want in this case is that a new buffer opens in my current emacs instance, exactly what emacsclient is designed for. So if in a shell buffer in project1's emacs I say:
export EDITOR='emacsclient -s project1'
then in that particular shell everything works perfectly.
My question is, how could I automatically set the EDITOR variable in a way that it points to the emacs instance the current shell is running in?
Here is one way to do it:
(add-hook 'shell-mode-hook
(lambda ()
(comint-send-string
(get-buffer-process (current-buffer))
(concat "export EDITOR='emacsclient -s "
(daemonp)
" -c'\n"))))
Related
So in my rifle.conf I have
ext org, has emacs, terminal, flag f = emacs "$#"
However it opens the file with the GUI version of emacs?
How do I open it with 'emacs -nw filename'?
I tried what Tom had said but I found that there were too many steps to open my org file. I wanted to be able to just press enter on an orgfile within ranger and have it open emacs -nw file.org, within the tmux pane running ranger.
The following solved my dilemma:
!mime ^text, label editor, ext org = emacs -nw -- "$#"
Edit: Interesting dig - after a look at OPs solution above: It turns out ranger does indeed open a terminal program 'on top of itself', so to speak.
The culprit in OPs first attempt is the flag f, in fact the minimal
ext org = emacs -nw "$#"
works like a charm.
Old attempts:
As far as I read the docs, you cannot open a file with a program running in the same terminal as ranger itself is running
in (I may be wrong, though).
Following the documentation I exported TERMCMD, since I'm using tmux with TERM=screen-256color, ranger cannot infer the terminal to use from that:
# just a test, I don't use xterm
export TERMCMD=xterm
And simply added the t flag and -nw to the command in rifle.conf:
❯ cat ~/.config/ranger/rifle.conf
ext org, has emacs, terminal, flag tf = emacs -nw "$#"
Hitting r in ranger
0 | emacs -nw "$#"
:open_with 0
This opens a new xterm, starting a new emacs editing the file in question. You can simply press the Return key while on the file in question with this setup; using r would show all available options.
If you are living in the terminal and don't want to start another graphical terminal, I suggest using something like tmux - you can use tmux commands to open files, in this case like so
ext org, has emacs, terminal, flag f = tmux splitw -h emacs -nw "$#"
splitting the current pane (with ranger running), launching a new pane to the right of the current one and starting emacs there. The pane will be closed when you quit emacs. I'd probably start an emacsserver and use emacsclient -nw in this scenario.
I'm running ubuntu 1804 on windows using the WSL. Everything is set up fine and works correctly. I've also installed ZSH and oh-my-zsh, again this is all good and everything looks like its working fine. Everything except the arrow keys whilst using vim or man pages or some other command line tools.
The up and down keys work on the command line when scrolling through history and also for select commands like nano. Also if I boot into bash rather than zsh the arrow keys do work in vim and man pages, in fact they work everywhere.
If i boot into bash, then switch to zsh on the command line manually the arrow keys then work everywhere.
So my cmder config for zsh
c:/_distros/ubuntu1804/ubuntu1804.exe -c zsh -cur_console:pm
and for bash
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pm:/mnt
The one for bash uses the conemu-cyg-64.exe program that comes from conemu which is a symbiont of POSIX enabled pty and WinAPI full-featured terminal.
Apparently you can use this tool with zsh but i cant manage to make it work i get the error
{PID:10592} failed to run shell (2): No such file or directory
{PID:10592} shell: `/usr/bin/zsh` `-l` `-i`
{PID:10592} dir: `/cygdrive/c/Program Files/cmder`
ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console...
and this is the task in cmder
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe /usr/bin/zsh -l -i -cur_console:pm:/mnt
So I think that if i can boot into zsh using conemu-cyg-64 that the cursor keys will probably work in commands like vim and the man pages. Any help or advice getting that working would be brilliant.
EDIT:
On my ubuntu install zsh is installed at /usr/bin/zsh, but there is no file or folder /cygdrive/c/Program Files/cmder
Many thanks to #Maximus for pointing me in the right direction. The answer was right under my nose at the bash on windows page of conemu. A small change to the command i was using before. the zsh needs to go on the end rather than before the --wsl.
The correct task to ensure that cursor keys work on all apps in the terminal is:
set "PATH=%ConEmuBaseDirShort%\wsl;%PATH%" & %ConEmuBaseDirShort%\conemu-cyg-64.exe --wsl -cur_console:pnm:/mnt -t zsh -l
I'm trying to wrap my head around this: on Windows, I use cmder (a wrapper around ConEmu) which improves on the bare cmd.exe experience (a lot) but can also host other shells like PowerShell or Git Bash. I'd like to go more "unix-y" but still well integrated with my Windows tools. Git Bash strikes the right balance for me: I can do things like rm -rf node_modules but still run my Windows commands fine.
It's easy to get Git Bash going inside cmder, however, I'd like to replace the shell with zhs, mainly to get the super-useful "up arrow respects the current prefix" feature (I write git, press the up arrow and only get suggestions on the recent Git commands).
The question is, who will handle the up arrow? Will it be ConEmu and do Windows-y stuff (cycling through all the commands) or will it fall down to zsh and the cycling will be implemented by it? How does this work?
Related: ConEmu: possible to change the up arrow behavior?
ConEmu's disclaimer states
ConEmu is not a shell, so it does not provide "shell features" like remote access, tab-completion, command history and others.
Only the shell itself knows when user types a command and only the shell may store executed commands history. Of course, only the shell may process Up/Down/Tab keys to "browse" stored history of commands.
cmder is a bundle of tools including clink, which integrates into cmd.exe and process cmd's prompt internally. So, in cmder by default Up/Down/Tab arrows are processed by clink.
More info is here: http://conemu.github.io/en/TabCompletion.html
Let's say you run a command like grunt serve on a tmux pane,
and you kill the pane on which the command is running. I found that
the process is not killed:
ps aux | grep grunt
still shows that grunt is running even though the pane is gone.
How do you kill a tmux pane along with the process(es)?
To stop the program running you can close the pane by entering <C-B> x and then entering y.
Just do: <CTRL-B>:kill-pane
Use Ctrl + b¹, > to get a menu with this and other useful commands:
This is what uses the Spotify plugin.
¹ Or the chosen tmux escape sequence.
Other notes and sources
tmux list-keys | grep display-menu #
curl cht.sh/tmux # Online cheatsheet
https://wiki.archlinux.org/title/tmux
You may find the tmux-safekill plugin useful.
I wanted it to kill Ruby processes, so I had to fork the repo to add that functionality in, so I'm sure you could do the same for grunt processes if you don't get all the functionality you need from the repo directly.
My Mac OS command line application is making Unix calls such as:
system("rm -rf /Users/stu/Developer/file);
perfectly successfully.
So why is the following not changing the current directory?
system("cd /Users/me/whatever");
system("pwd"); //cd has not changed
Because
system() executes a command specified in command by calling /bin/sh -c command, and returns after the command has been completed.
So each command is executed independently, each in a new instance of the shell.
So your first call spawns a new sh (with your current working directory), changes directories, and then exits. Then the second call spawns a new sh (again in your CWD).
See the man page for system().
The better solution is to not use system. It has some inherent flaws that can leave you open to security vulnerabilities. Instead of executing system() commands, you should use the equivalent POSIX C functions. Everything that you can do from the command-line, you can do with C functions (how do you think those utilities work?)
Instead of system("rm -rf ...") use this.
Instead of system("cd ...") use chdir().
Instead of system("pwd ...") use getcwd().
There are some differences, of course, but these are the fundamental equivalents of what you're trying to do.