I am using this code for inserting \emph{..} blocks into latex:
(define-skeleton mylatex-emph-skeleton "\emph{_}"
nil "\\emph{" _ "}")
As an undired side effect however, it also inserts a newline at the end of the skeleton. E.g. if I select emphasized in
This is emphasized text.
and press my hotkey, I end up with
This is \emph{emphasized}
text.
instead of
This is \emph{emphasized} text.
Can I prevent this? Note that the newline only gets inserted, there is text after the insertion point, so it is not as easy as deleting the character after the closing }.
Set skeleton-end-newline to nil to change the behavior of all skeletons.
Modify skeleton-end-hook to check which skeleton is being expanded and inserting newline as desired if you want to change the behavior of a specific skeleton.
Related
Problem:
In Emacs configuration modes (e.g. conf-xdefaults-mode or conf-space-mode), some special characters are used in unusual ways, for instance when they define keybindings. This messes up the highlighting for the rest of the buffer.
Example:
The ranger rc.conf file uses conf-space-mode which greatly helps its readability. But lines such as:
map # console shell -p%space
map "<any> tag_toggle tag=%any
mess up the highlighting since # usually defines a comment and is followed by font-lock-comment-face until the end of the line and " defines the beginning of a string and is followed by font-lock-string-face until it encounters a closing quote.
Escaping those characters is not an option because it would prevent them from defining the keybindings.
Possible solution:
The best solution I can think of is to fiddle with font lock settings for those configuration modes to remove the highlighting after those special characters. But I will then loose the proper highlighting after those characters when it is suitable.
A compromise could be to keep highlighting after # since this only messes up one line and there are a lot of comments in those configuration files, while removing the highlighting after single and double quotes since those mess up the entire rest of the buffer and strings are not so common in configuration files.
Question:
What is the proper way to deal with these situations?
Is there a way to reset the highlighting at a point in the buffer? or to insert a character which would affect the highlighting (to fix it) without affecting the code? or is there a way to "escape" some characters for the highlighting only without affecting the code?
The easy way
It's probably easiest to just live with it but keep things constrained. Here, I took ranger's default rc.conf and re-arranged some of the font-lock errors.
Let's ignore the blue "map" for now. We have two visible font-lock errors. The map #... is font-locking as a comment, and the map "... font-locking as a string to the end of the buffer. The first error is self-constrained. Comments end at the end of the line. The second error we constrain by adding a comment. (I don't know if ranger would accept comments in the middle of the line, so I'm only using beginning-of-line comments here.)
The second error is now constrained to one line, but a couple more errors have popped up. Quickly adjusting these we get.
This is something that I could live with, as I'm not in conf files all day long (as opposed to say, source code.) It would be even neater if our new "comments" could be included on the same line.
The hard way
You'll want to use Emacs font-lock-add-keywords. Let's get back to that blue map in the first image. It's rendering blue because conf-space-mode thinks that a string, followed by any amount of whitespace, followed by an opening brace should be rendered in font-lock-type-face (the actually regexp that triggers this is ^[_space__tab_]*\\(.+?\\)[_space__tab_\n]*{[^{}]*?$ where _space_ and _tab_ are actual space and tab characters.)
We can override this in a simple fashion by evaluating
(font-lock-remove-keywords
'conf-space-mode
'(("^\\<\\(map\\)\\>" 1 font-lock-variable-name-face)))
and reloading the buffer with C-x C-v RET. Now, every time that the word "map" appears at the beginning of a line it's rendered as font-lock-variable-name-face (yellow in our example.)
You can make this change permanent by adding a hook to your init file.
(add-hook 'conf-space-mode-hook (lambda ()
(font-lock-remove-keywords
nil
'(("^\\<\\(map\\)\\>" 1 font-lock-variable-name-face)))))
This method doesn't appear to work for your comment (#) and string (' ") delimiters as they're defined in the syntax table. Modifying the syntax table to provide special cases is probably more effort than it's worth.
In emacs org-mode, when I make a new sub-heading,(org-insert-subheading), sometimes it adds a blank line, sometimes it doesn't based on some pattern in text above.
Can I force emacs to never insert a line break?
I.e,
* Heading 1
** Heading 2 #no line breaks.
This is controlled by the variable org-blank-before-new-entry:
Should `org-insert-heading' leave a blank line before new heading/item?
The value is an alist, with `heading' and `plain-list-item' as CAR, and a boolean flag as CDR. The cdr may also be the symbol `auto', in which case Org will look at the surrounding headings/items and try to make an intelligent decision whether to insert a blank line or not.
On my version of emacs, the default for both items is auto. To never insert blank lines, set both to nil:
(setf org-blank-before-new-entry '((heading . nil) (plain-list-item . nil)))
I think this is controlled by the variable org-blank-before-new-entry. As per the Org documentation:
Should org-insert-heading leave a blank line before new heading/item?
The value is an alist, with heading and plain-list-item as CAR,
and a boolean flag as CDR. The cdr may also be the symbol `auto', in
which case Org will look at the surrounding headings/items and try to
make an intelligent decision whether to insert a blank line or not.
For plain lists, if org-list-empty-line-terminates-plain-lists is set,
the setting here is ignored and no empty line is inserted to avoid breaking
the list structure.
The default value is '((heading . auto) (plain-list-item . auto)), so it normally will insert a newline before a heading (the auto part in the heading). You can specify Never when you customize the variable, and it will not insert a newline.
I am currently working on a major mode derived from auto-fill-mode where I need the text to show in a special indented way (it's a derivation of the screenwriter.el project), and I just got stuck with a peculiar behaviour of the auto-fill when there are multi line indentations:
(NOTE: use-hard-newlines is nil, and left-margin is 0):
How I expect it to work:
DUDE <-- here I insert a newline
(sad) <-- here I insert another newline
Hello, look how good <-- here I let the auto-fill-mode fill the text automatically
of a day it is!
But what happens is the following:
DUDE <-- here I insert a newline
(sad) <-- here I insert another newline
Hello, look how good <-- here I let the auto-fill-mode fill the text automatically
of a day it is!
So basically the fill mode acts weirdly when there are multi indented paragraphs, indenting to the second line's left margin. I could not find anywhere how to avoid such a behaviour.
Even stranger, the following works just fine, indenting to the precedent line's margin.
DUDE <-- here I insert a newline
Hello, look how good <-- here I let the auto-fill-mode fill the text automatically
of a day it is!
I wonder if it's just a bug or if there is a way to avoid this since it's quite annoying. Could anyone test if it works differently on other versions of emacs, or at least give me a hint on how to work around this? Thank you very much.
Emacs version: 24.3.1 on Windows
EDIT: I just checked and the same behaviour happens with use-hard-newlines on, so I'm oblivous to how to solve this
You could customize the adaptive-fill-mode variable, which is what causes a prefix to be automatically determined when filling text. Set the variable to nil to disable that behaviour.
For details of how the prefix is worked out, see the fill-context-prefix function.
Is there a quick and easy way to word wrap like "Apply Word Wrap" function of KDE's Kate?
Enter to wrapping mode = M-x auto-fill-mode
Wrap text = select text -> M-q
While the mishadoff's answer is great for default word wrapping, I once had to re-implement it because I wasn't content with the way Emacs did it, so I tried to scratch the bits of it together and here it is: http://pastebin.com/75q65hRf in case you need it.
With that bit of code you can configure what characters to wrap on, what characters terminate words, and also set exception rules for when the characters that would've otherwise break the line won't do it. It may also pad the created column on the right and on the left (I was using this function to format and display documentation text).
Right now I'm using:
(setq show-trailing-whitespace t)
In my .emacs to show trailing whitespace for my CC mode. I can't seem to figure out how to have it not show the whitespace font for whitespace only lines.
Empty lines separating indenting code are sometimes indented at the code level and sometimes not indented at all, and I don't want to draw my attention to a line I don't care to change.
I'd like to stick to built-in emacs modules, but I'm willing to use whitespace.el but it's not clear how to configure it to do this.
Since you want to use built-in modules, I'd advise using the whitespace.el link you specified - as it is shipped with Emacs 23. This answer works when using that whitespace.
As long as you have 'trailing in your 'whitespace-style variable (which it is by default), the following change to the regular expression for what indicates "trailing" whitespace should give you what you want:
(setq whitespace-trailing-regexp
"\\b\\(\\(\t\\| \\|\xA0\\|\x8A0\\|\x920\\|\xE20\\|\xF20\\)+\\)$")
Note: It is just the default value, with the \b prepended, indicating that the whitespace should follow a word.
With
"\\b.*\\(\\(\t\\| \\|\xA0\\|\x8A0\\|\x920\\|\xE20\\|\xF20\\)+\\)$"
the word does not need to be directly in front of the trailing whitespaces but there can be e.g. punctuation characters between them (i.e. this also highlights trailing whitespaces behind non-word characters).
Edit:
Using
"\\b.*?\\(\\(\t\\| \\|\xA0\\|\x8A0\\|\x920\\|\xE20\\|\xF20\\)+\\)$")
highlights all the trailing whitespaces and thus eliminates the drawback mentioned in comment #1.