When you use babel with French (set by, \usepackage[francais]{babel} emacs replaces automatically quotations marks (") by \og and \fg (you need only to restart emacs after adding babel).
It could be quite cool. But I'm using csquotes package which allows to have the good quotation marks by simply writing ".
\usepackage[babel]{csquotes}
\MakeOuterQuote{"}
So this amazing feature of emacs (the automatic replacement of " by \og or \fg) is useless for me and even painful.
How do I remove it?
It seems it is the font-latex-quotes variable which manage this. But options are only French (<< >>) or German (>> <<). I would like to redefine this variable to consider "test" as quote with test in color.
Assuming you are using auctex. you need to customize the value of variable TeX-quote-language to 'override.
This special value makes that language-related styles inhibit to modify its value, so quoting magic is deactivated.
I fixed this issue by modifying the variables LaTeX-csquotes-open-quote and LaTeX-csquotes-close-quote.
I define the first variable as \enquote{ and the second as }.
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 org-mode, I want to give inline code with equals signs and quotation marks:
<div class="foo">
The way I would normally do this in org-mode is
=<div class="foo">=
When I export this to HTML, it gets rendered like this:
<div class"foo">=
What is the right way to do this inline (rather than just creating a source block)?
You could use verbatim markers, ~, instead:
~<div class="foo">~
The problem is that the equals sign after 'class' is interpreted as the closing code section delimiter. You can prevent this by inserting a space before the equals sign, like this:
=<div class = "foo">=
I wanted org-mode's source code to appear correctly in Github's parser. But, just as =:echo "hello"= would not appear correctly in Emacs, it also did not appear correctly in Github. However, I tried other characters with C-x 8 RET, and the LEFT DOUBLE QUOTATION MARK and RIGHT DOUBLE QUOTATION MARK work. That is,
=:echo “hello“=
appear successfully as
:echo “hello“
Unfortunately, I don't think they will actually work if copy-and-pasted into all environments. Vim gives E15: Invalid expression: “hello“. But then, how often do we paste commands into Vim's command line. Well, okay, there is :#".
After almost a decade, here's the correct answer:
Org's escape character is zero width space. When this character is inserted, Emacs will not interpret = as the end of the verbatim. Emacs can correctly interpret =<div class="foo">=. Note that this string has an invisible zero width space character.
However, I think due to a bug, exports from org to other formats, will have this character and need to be removed manually. For example, the export of the string above to markdown will be `<div class="foo">` which is what we want, except that it has an additional zero width space character.
It is not very hard to fix this. Removing all these additional characters can be easily done with replace-string command.
Tip: You can use C-x 8 RET (or insert-char command) and choose 200B to insert zero width space character inside Emacs.
Say I want to escape characters in org-mode, e.g. _ so that org-mode renders the following:
* _TARGET_
In my set up (which I think is the default one) org-mode underlines the word as opposed to rendering _TARGET_
More generally, where can I find information about how to escape characters in Emacs org-mode?
The code and verbatim markup will render the text inside as-is, without interpretation. Therefore, =_TARGET_= will probably work as you intend (you'll also get a different monospace typeface for that word).
With a current Emacs and org-mode you might try
* \under{}TARGET\under{}
If that is not automagically displayed as * _TARGET_ just try C-c C-x \, that should toggle the display of those codings between coding characters and coded character.
(In principle the same as I explained here.)
If you want to break org to interpret some syntax you are using, you will have to ways to do that.
Using escape char. _ is \under and * is \ast, so you can write like this \ast \under{}TARGET\under;
Another way is to use zero width space, its code is 200B, so you can use C-x 8 RET 200b RET to insert a zero width space to break the interpreting.
They work on the latest org on the responding time (latest 9.2).
Alternatively, use the normal shell backslash to escape the characters you want to avoid Org-mode interpreting as markup:
* \_TARGET\_
The backslash characters are visible in your Emacs buffer, but are hidden when exporting - e.g. to HTML or PDF-via-LaTeX.
This escaping works in many other situations, e.g. SR\_1234 to render as SR_1234 during export rather than as a subscript.
I'm relatively new to Emacs, but have been experimenting with it to see if it would be worth switching. I write in Markdown and use pandoc to convert to whatever I need. In case it matters, I'm running Emacs 23.3.1 on Ubuntu 12.04.
I'm a graduate student in the humanities, so my writing is heavy on the footnotes. Footnotes, in pandoc, are formatted within square brackets. The problem I'm having is that auto-fill mode seems to ignore text within brackets, so my footnotes end up snaking their way across the page--and the only fix I've been able to find is to manually break the lines myself, every time I edit the paragraph. That's obviously less than ideal. (I could also give up on inline footnotes, and leave them all separate references, but I'd prefer not to, and it doesn't seem like that should be necessary.)
So my question is, is there a way to make auto-fill mode operate on text within brackets, too? Is there a reason it doesn't by default?
Many thanks,
-- Brian
It turns out that markdown-mode, as of v. 1.7, deliberately avoids breaking lines in square brackets in order to avoid breaking links--which is the most common use of brackets for Markdown. See http://jblevins.org/projects/markdown-mode/rev-1-7.
Brian,
Add the following to your init file† to allow auto-fill in markdown-mode to break lines inside square brackets:
(require 'markdown-mode)
(defun markdown-nobreak-p () nil)
What we did is redefine the function "markdown-nobreak-p" (originally defined here: http://jblevins.org/git/markdown-mode.git/commit/?id=66566a55 ) to always return "nil" which means "yes you are allowed to break at this point". The original version of this function would return non-nil for points inside square brackets.
† http://www.gnu.org/software/emacs/manual/html_node/emacs/Find-Init.html
Auto-fill by itself does not prevent filling inside brackets. It can be told to do so by the major-mode, tho, so I guess the problem depends on your major mode. If you're using mardown-mode, then please report this problem to its maintainer. In any case, you may want to try and use M-q to explicitly fill the paragraph, since it does not always follow the same conventions as auto-filling: it's more explicit than auto-fill, but still more automatic than placing the newlines by hand.
When I export to PDF via org-mode (C-c C-e d), any words with underscores end up being partially converted to subscript. How can I prevent this from happening?
I found this article on the subject:
Disabling Underscore subscript in Emacs Tex Mode
However, I either wasn't able to figure out the correct elisp or it simply didn't work. Note, I don't want to change any global font options. I only want this fix to apply to tex/latex/org-mode.
I also found this post, though it didn't work either:
disable subscript superscript raise/lower?
You can disable super/subscripting within an org file by adding the following line:
#+OPTIONS: ^:nil
Check the org manual for more options.
The following command inserts a template containing all the options:
C-c C-e #
I was able to solve the issue by setting the following variable:
(setq org-export-with-sub-superscripts nil)
I think this would be easier: http://orgmode.org/manual/Subscripts-and-superscripts.html
Escape the underscore with a backslash:
Now, escape the _:
You can see this in action here: http://www.railsonmaui.com/blog/2013/04/27/octopress-setup-with-github-and-org-mode/
Use \under (Documentation on The Org Manual: Special symbols)
For example:
text\under{}text
Do you want to prevent subscripts in the onscreen display of the source file or in the text of the output PDF? If the latter, then you want
\usepackage{underscore}
It won't break the use of underscores in maths mode, either.
For individual cases, insert a literal underscore this way:
text text one\textunderscore{}two text
In my case any word that contains an underscore is likely to be a variable name or something similar. I just surround it with = or ~ so that it's treated as such. Then it will be exported accordingly.