I've just upgraded OS from Ubuntu 16.04 to 18.04 and for some reason emacs disappeared.
On reinstalling I've just noticed that running M-x shell then hg diff produces an error message:
WARNING: terminal is not fully functional
- (press RETURN)
I think I may have fixed this by running:
export TERM=xterm
After which I got a very colourful shell experience and no warning on running hg diff
However, its only displaying one page of the hg diff output then pausing with a : at a time now, previously it printed the lot without stopping.
I think this may be acceptable, if I could figure out what key allows me to print the next page of hg diff output, and ideally, what key would allow printing all remaining hg diff output and return me to the shell prompt.
If I hit return I get an additional line at a time, but this is a bit slow and not really ideal.
I think this is maybe a question about xterm shortcut keys? Possibly not emacs specific, but I'm not sure..
shell-mode is line-buffered, meaning the input won't be sent to the underlying process until you enter RET. In this case, the output should be running through a program like less where RET would give you another page instead of a single line.
So, in shell-mode you can use SPC followed by a RET. In term-mode where the default is not line-buffered (to resemble the underlying shell as transparently as possible) a single RET should suffice to give you a new page.
Related
Whenever I enter a terminal command in vim (e.g., !echo hello), I am momentarily kicked out to view the result of that terminal command and then prompted with Press ENTER or type command to continue. This is a bit jarring. I would like to stay within vim and with the command output printed out at the bottom.
I know vim :read will take the terminal output and actually put it into my buffer, but that is not what I am looking to do. Here is some reading if you are interested in a tangent.
It looks like when I run vim in Screen I get what I am looking for, but I am trying to get this to work with tmux and the stock Mac terminal.
After a ton of research, probably too much, I got it! It looks like vim will send commands to the terminal, which in turn defines the behavior of how the terminal commands are processed from vim. Put this into your .vimrc file:
set t_ti= t_te= " show results from terminal commands within vim!
From what I understand, this just makes sure to send nothing to the terminal, which yields my desired results!
Side note: the above addition to your .vimrc file will also prevent the vim buffer from clearing when exiting vim (e.g., :wq). I am okay with this! It is kind of nice sometimes to see what you were just working on :).
I always use Emacs's shell. I create 2 buffers (C-x 2) and use one of them as a terminal (M-x shell).
Sometimes I use a command a lot of times (e. g. python3 test.py). I use shortcut <C-up> to repeat the last command. And it's very inconvenient that Emacs saves duplicates of commands. I have to press <C-up> many times so that I can run any other command.
The problems is only in Emacs's shell. I have setting HISTCONTROL=ignoreboth in .bashrc and in usual terminal it works very well.
Is it possible to configure Emacs so that it ignores duplicates?
It's customizable
(setq comint-input-ignoredups t)
Setting 'comint-input-ignoredups' as suggested by Jürgen Hötzel will of course solve the immediate, but here are some alternatives.
You could choose to use the command 'ansi-term' instead of 'shell', this will run a bash (or whatever you choose) so you get the same control as in (say) an xterm. As an added bonus, you also get a rather capable terminal so applications that depend on this will work.
Another possibility, if you have something you want to repeatedly run, is to use the 'compile' command. This can run any shell command, it does not have to be a compiler. The advantage here is that you keep the running of the test out of your shell command history (no matter how you run your shell) and you get the output in a separate buffer. If the output is suitably organised and/or the compilation buffer is suitably configured, you could also use the 'next-error' command to jump back to the appropriate part of the source.
Finally, I would like to mention that the 'shell' command supports searching the command history. It is by default bound to M-r (comint-history-isearch-backward-regexp).
I'm somewhat new to gnu emacs, and so perhaps this is a noob question, but I have a few batch files I use a lot when coding in emacs to compile/build/execute/debug/etc. I am wondering how I could A) run these batch files from emacs without having to keep opening a cmd prompt window or going to windows explorer and B) bind this to a key shortcut (perhaps I could specify the file?) I have seen several things online about running emacs in batch-mode, but I don't believe this is what I'm looking for. And I know it is possible because I have seen others run batch from emacs (output and everything would appear in a new buffer adjacent to the current as if you did C-x 3)
Thanks in advance!
To run an arbitrary shell command in Emacs, you call shell-command which is bound to M-!
See C-hf shell-command (or C-hkM-!) for details.
I believe in the Windows-native Emacs, the default shell is cmd (or some alias thereof), so I'm reasonably confident that this is what you're thinking of.
I'm not sure whether all of the following work in Windows, but related commands are:
M-& - async-shell-command
M-| - shell-command-on-region
And with a prefix argument (e.g. C-uM-!) any of those commands will insert the shell command's output into the current buffer. (In the case of shell-command-on-region, that replaces the region.)
Problem:
git add -p seems unusable in either emacs shell or eshell
magit (a frequently suggested alternative to using git from the shell in emacs) sucks balls on Windows (it's horrendously slow.)
Keeping a cygwin window open and using that for git add -p and then going back and forth between that and emacs is doable, but more than a little annoying.
Is there any way that under Microsoft Windows I can get either git add -p to work well in shell or eshell or alternatively get magit to be somewhat usable?
If magit is slow, that probably indicates problems with your windows git client?
I would look into that first and foremost (because git add -p really doesn't hold a candle to magit's interface, IMO).
What are the exact tools (and versions thereof) which you are using?
You should definitely check the magit issue tracker to see if there are known reasons why magit might be slow.
Have you tried:
% EDITOR=emacsclient git add -e <files>
and then using the diff-mode commands in your running emacs to interactively edit the hunks of the patch?
Then you will be able to split hunks within the patch at any particular line with diff-split-hunk and remove hunks entirely with diff-hunk-kill (and of course these commands are bound to shorter key sequences for quick interactive use). When you are done editting the patch, use C-x # to save it and quit the emacsclient session (so that you can go back to your shell).
(emacsclient, if you are not familiar with it, is a program that will let you open files in an already-running emacs, as long as the latter has started up a server for emacsclient to connect to; see the M-x describe-function server-start)
Note that you will probably want to customize how emacsclient interacts with git a little bit; for example, see these answers: Using ediff as git mergetool and How to set the exit status for emacsclient.
I am using a bash script to run a number of application (some repeatedly) on a Windows machine through cygwin. The script contains commands to launch those applications, line by line. Most of these applications run for many minutes and many times I have observed that the i+1 th application is not being started even after i th application is completed. In such cases, if I press enter in the cygwin console on which the bash script is running, the next application starts running. Is it because of any issue with bash on cygwin? Or is it an issue with the Windows OS itself? Have any of you observed such an issue with bash + cygwin + Windows?
Thanks.
I think I have seen this before.
Instead of
somecommand
try
somecommand </dev/null
If that doesn't work, try
cmd /c somecommand
Or experiment with other redirections, e.g.
somecommand >/dev/null
Sounds like you may have a problem with your shell script encoding; DOS (and Windows) uses CR+LF line endings, whereas Linux uses LF endings. Try saving the file as LF.
What might also be going on:
When I was running Cygwin on a school laptop, I encountered a dramatic slowing of shell scripts vs. when they were running in a native Linux environment. This was especially apparent when running a configure script from GNU Autotools.
Check your path for slow drives. (From the Cygwin FAQ):
Why is Cygwin suddenly so slow?
If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.
You might also want to check whether you have an antivirus program running. Antivirus programs tend to scan every single executable file as it is executed; this can cause problems for even simple shell scripts that run hundreds or even thousands of individual programs before they run their course.
This mailing list post outlines what is needed to pseudo-mount the main /usr/bin directory as cygexec. I'm not sure what that does, but I found it helped.
If you're running a configure script, try the -C option.
Hope this helps!
Occasionally, I'll get this behaviour because I have accidentally deleted the 'she-bang' at the top of the script, that is, deleted the #!/bin/bash on the first line of the script.
It's even more likely for this to happen when a parent shell script calls a child script that has the she-bang missing!
Hope this helps.
A bit of a long shot, but I have seen some similar behaviour previously.
In Windows 2000, if any program running in a command prompt window had some of it's text highlighted by the cursor, it would pause the command running, and you had to press enter or clear the highlighting to get the command prompt to continue executing.
As I said, bit of a long shot, but accidental mouse clicks could be your issue...
Install cygwin with unix style line breaks and forget weird problems like that.
Try saving your script as "the-properly-line-broken-style" for your cygwin. That is, use the style you specified under installation.
Here is some relevant information:
https://stackoverflow.com/a/7048200/657703