In vim, one can set the variable formatprg to have vim use an external program to format lines via the gq command.
Is there an analogous setting for Emacs evil mode? If not, is there another way to achieve a similar functionality?
Related
Each time when I edit bash script I type a command M-x shell-script-mode. And then I get nice shell code higlighting. How to get it automatically each time I start emacs so I do not have to type the command. When I added (shell-script-mode) to init.el it did not help.
You can set the default major mode to be whatever you want by adding
(setq-default major-mode 'shell-script-mode)
to your init file. That will ensure that any newly created buffer will be in shell-script-mode unless its mode is specified otherwise (e.g. through auto-mode-alist). Whether it's a good idea or not, I don't know: I probably would not want that to be my default setting - but to each her/his own.
One of the simplest ways to have Emacs set the desired mode for a buffer editing a file is to include a special comment in the first line of that file, e.g. for a shell script your first line might be:
# -*-sh-*-
For scripts it is also common, or and often even required, to have an interpreter file comment on the very first line of the file, which of course would preclude having an Emacs mode comment, so Emacs also looks for interpreter file comments and associates those with a major mode, so the first line of your shell script might be:
#!/bin/sh
There are a number of other ways to tell Emacs how to set the buffer mode when visiting a file. See, for example, Emacs Manual: Choosing File Modes
In Haskell-mode, the shortcut C-c C-= is defined to do something.
Trying this shortcut, I realized that emacs do not recognize the shortcut C-c C-=.
Indeed, when I try the shortcut on emacs, the buffer write C-c = is not defined although I pressed C- C-=. I have the same problem with some other symbols like '.' or 'ยง'. But shortcuts like C-c C-l or C-c C-c work.
I try to remove my .emacs but I have the same problem.
a friend have the same problem as me.
Both we are on ArchLinux (64 bits) and we use emacs in console. The keyboard is an azerty.
The problem come from emacs ? Arch Linux ?
Your terminal can't send Emacs C-= so you can't use that key sequence. (Emacs would recognise it if it received it, but that won't happen.)
Your options are:
Run GUI Emacs.
Use M-x name-of-command RET (for whatever command is bound to the key sequence you're not able to use). Use C-hm to see the major mode's bindings, or C-hb to see all current bindings, in order to learn what those command names are.
Create new custom keybindings for the commands in question (i.e. bindings which your terminal can send to Emacs).
Find a different terminal emulator with enhanced key sequence abilities. The vast majority of them will be no better than what you have, because they're all adhering to the limitations of the terminals they're emulating. The most capable one I know of is http://invisible-island.net/xterm/xterm.html but you may need to compile it yourself, and then expect to spend lots of time configuring it. (It's not a trivial solution, though, and xterm requires a GUI environment, so running GUI Emacs is much simpler.)
Use C-x#c<key> instead of C-<key>.
With that last option, you can use a sequence your terminal can send to fake a sequence that it can't send.
C-cC-= would become C-cC-x#c=
If you really wanted to use that last option, you can set a custom binding to simplify the sequence (may be necessary in some instances to avoid conflicting with existing sequences). See the end of https://stackoverflow.com/a/24804434/324105 for more information.
To add to phils' post - another option is an Emacs package (which I wrote), which can teach Emacs and terminals how to properly recognize all PC keyboard keys and modifier key combinations:
https://github.com/CyberShadow/term-keys
The default configuration already includes encoding key combinations like Ctrl=, as well as similar variations.
After every Emacs startup in python-mode I need to open the interpreter in a different buffer and
change the size of the new buffer that it fits emacs-code-browser's history. I want to automate
this activity.
How can I automate that an interactive python shell always appears (after Emacs startup) in an extra buffer like in the screenshot?
UPDATE: See below: workgroups.el and emacs-code-browser seem to collide. See screenshot
Before Editing
After Editing
I use Emacs23, emacs-code-browser and python-mode.el.
UPDATE: I tried to use workgroups.el. I defined a new python workgroup and added the following line to my .emacs: (wg-load "~/.emacs.d/workgroups/python_workgroup.wg"). The windows are, however, messed up. You can see it on the screenshot below:
It think that emacs-code-browser and the settings of my workgroup collide. Is there a way
to avoid this behavior?
also you may try desktop-save-mode:
desktop-save-mode is an interactive autoloaded Lisp
function.
(desktop-save-mode &optional ARG)
Toggle desktop saving (Desktop Save mode).
With a prefix argument ARG, enable Desktop Save mode if ARG is
positive, and disable it otherwise. If called from Lisp, enable
the mode if ARG is omitted or nil.
If Desktop Save mode is enabled, the state of Emacs is saved from
one session to another. See variable desktop-save' and function
desktop-read' for details.
How about using workgroups.el ?
It is used for saving your window configuration which is exactly what you need.
This way you can create a workgroup called for example Python, adjust buffers (including one containing interactive python shell) and everything and save the group, and next time you just open workgroup Python and all buffers open as they were before. If you want it to open automatically when emacs is started, just set your saved Python workgroup as a default workgroup.
I've found that terminal emacs does not render the correct colors unless I explicitly set TERM=xterm-256color. I use gnome-terminal, and from what I understand, TERM should be set to gnome-256color. Similarly, I tend to use tmux a lot, which advises against any TERM setting other than screen-256color. Unfortunately, both of those settings (within their respective context - gnome-terminal or tmux) result in emacs having wrong colors, whereas vim displays colors correctly. However, if I export TERM=xterm-256color, the colors work just fine in emacs.
Can anyone explain what's going on, or offer a solution?
Update
Here's what I'm dealing with:
I can get the colors to look correct in the terminal by adding the following to my init.el:
(defun terminal-init-gnome ()
"Terminal initialization function for gnome-terminal."
;; This is a dirty hack that I accidentally stumbled across:
;; initializing "rxvt" first and _then_ "xterm" seems
;; to make the colors work... although I have no idea why.
(tty-run-terminal-initialization (selected-frame) "rxvt")
(tty-run-terminal-initialization (selected-frame) "xterm"))
This feels really, really wrong though. There has to be a logical explanation for this...
P.S.
I have very little knowledge of terminfo and the precise role that $TERM plays in the process of color terminal behavior. If it's safe to always use xterm-256color (even when $TERM "should" be gnome-256color or screen-256color), I'll go with that.
Maybe I'm not understanding something, buy why don't you run emacs like this:
TERM=xterm-256color emacs -nw
This way Emacs has its own TERM setting that you know works. You can also make an alias or wrap this in shell-script.
Terminals are a special type of device. When a process sends special byte sequences (called control sequences) to the terminal, it performs some action (like cursor positioning, change colors, etc).
You can read the ANSI terminal codes to find more detail about control sequences.
But terminals come from 70s, when hardware was limited in its capabilities, and a terminal cannot provide info about its capabilities (ie. which sequences it supports).
$TERM was used to resolve this issue - it allows programs to know what to send to the terminal to get the job done. termcap and terminfo are databases that store info about terminal capabilities for many $TERM names. If your $TERM is not in the db, you must ask an administrator to add it.
All terminal emulators inherit these limitations from old hardware terminals. So they need a properly set $TERM, and the terminfo/termcap DB MUST have data for this terminal. When a virtual terminal starts it sets the $TERM variable for you (and inside programs like bash). If $TERM is not in the terminfo/termcap you can quickly define an alias from $TERM to xterm-256color (you can find examples in the termcap file on how to do that).
This behavior has to do with the logic EMACS uses to determine whether the terminal background is dark or light. Run M-x list-colors-display with TERM set to either xterm-256color or screen-256color and you'll see that the exact same colors are listed. As you pointed out in the comments, the difference in color schemes that you've observed is due to the frame background mode. To see this, with your TERM set to screen-256color, compare the colors in
emacs -Q -nw --eval "(setq frame-background-mode 'light)"
and
emacs -Q -nw --eval "(setq frame-background-mode 'dark)"
The function frame-set-background-mode (in frame.el) checks to see whether the terminal type matches "^\\(xterm\\|\\rxvt\\|dtterm\\|eterm\\)" if it can't deduce the background color otherwise.
Within a running session, you can change the color scheme to 'light by evaluating
(let ((frame-background-mode 'light)) (frame-set-background-mode nil))
I am not that familiar with how emacs handles different terminals exactly. But looking at lisp/term directory in emacs sources, I found out that the existence of a function terminal-init-xxx allows you to add support for different terminals. For example, I've got:
(defun terminal-init-screen ()
"Terminal initialization function for screen."
;; Use the xterm color initialization code.
(xterm-register-default-colors)
(tty-set-up-initial-frame-faces))
in my .emacs, which adds support for screen-256color. You may try defining a similar function for gnome by renaming the above function to terminal-init-gnome.
NOTE: If you are interested, you can try to track down the calls from tty-run-terminal-initialization code. It first gets the terminal type using tty-type function, then looks at certain locations to load a relevant terminal file, then tries to locate the matching terminal-init-xxx function, and finally calls it. It may help you figure out the correct name for gnome-terminal.
It looks like unless your TERM indicates that your terminal has 256 colors, emacs will only use 8. Changing TERM to gnome-256color allowed the color registration functions to work.
There is a way to cheat, after all. When I run gnome-terminal, my terminal is set to xterm by default. Instead of changing TERM variable, it is possible to redirect xterm to another terminal, say, gnome-256color. Simply create the directory $(HOME)/.terminfo/x, then run ln -s /usr/share/terminfo/g/gnome-256color ~/.terminfo/x/xterm. I think this is better than setting TERM manually in .bashrc, because it only redirects a particular terminal to something else. A console login would still leave TERM as linux, and not xterm-256color.
Add this to your ~/.emacs:
(add-to-list 'term-file-aliases
'("st-256color" . "xterm-256color"))
It tells emacs that if it sees TERM=st-256color then it should initialize the terminal as if it had seen TERM=xterm-256color.
Longer answer:
Emacs is showing strange colors because it thinks your terminal can only support 8 colors. In Emacs, run M-x list-colors-display to see the colors it thinks are available. The correct number of colors is detected during terminal-specific initialization. It says, in part:
Each terminal type can have its own Lisp library that Emacs loads when run on that type of terminal.
On my machine, the terminal-specific initialization files are in /usr/local/share/emacs/25.*/lisp/term. It has files for xterm, rxvt, screen, etc. but nothing for st. We need to help Emacs find the right initialization file. The documentation further says:
If there is an entry matching TERM in the term-file-aliases association list, Emacs uses the associated value in place of TERM
So that association list is a recommended way to handle unknown terminals. It works without you having to manually override the TERM environment variable.
On ubuntu 10.04 I too had noticed that running emacs -nw inside byobu/tmux/screen was using different colours from emacs -nw in the regular gnome-terminal.
I found that this is because byobu was setting TERM to screen-bce. Then setting TERM to xterm (for me, in the normal gnome-terminal TERM=xterm) gave me the same syntax highlighting when not running through byobu/screen.
So still not sure what the proper solution is.
See also this post:
Emacs Python-mode syntax highlighting
in gedit it's possible to define so-called "snippets" for simpler input.
For example, there is a snippet while. This means: If you type while -> (-> stands for tab key). And gedit automatically converts it to the following (including correct indentation):
while (condition){
}
In vim (in conjunction with latex-suite) I saw the following: If you type (, vim inserts just a (. If you type ( a second time, vim automatically converts it to \left( \right).
I found abbrev-mode but this mode doesn't place the cursor properly (i.e. between parentheses or inside the while loop).
I managed to create custom emacs keybindings/macros that do just the same (without having to press the tab key), so I know it's possible.
However, is there already and package where you can define such "snippets" without much effort? Or are there even any serious reasons not to use such things?
See yasnippet. It provides snippets for most major languages, and it is easy to add new ones or modify the old ones.
Yes, yasnippet is probably the way to go. But make sure you learn the major mode you're using for your editing - when writing in LaTeX, learn auctex. Major modes can contain functionality that makes some snippets pointless, and do the same thing even better. So instead of using a begin/end-snippet in a LaTeX buffer, try C-c C-e in auctex. Etc :)
Don't forget abbrev-mode.