Given this file:
#+title: test
some words.
/some emphasis/.
/some emphasis/.
/emphasis/.
org-export-as-latex (emacs 23.4.1; Org-mode 6.33x) produces this:
[...]
some words.
\emph{some emphasis\}.
\emph{some emphasis}.
\emph{emphasis}.
[...]
The compilation therefore fails. The same is true if I use *some emphasis* where the markup is more than one word and and starts a new line. Is this a known problem?
Update:
This seems to be a problem with emacs 23.4.1's org-mode (version 6.33x), at least as installed from the repositories for Ubuntu 12.10. With emacs 24.1.1 (and 7.8.11), the problem disappears. ... So this question is closed for me, but maybe there is still a solution for people still using emacs < 24.1.1
Related
I'm using (global-linum-mode t) to present line numbers in Emacs.
This works just fine up-until I use the ctrl + up/down commands (forward-paragraph and backward-paragraph) to navigate a buffer, at which point some line numbers are rendered incorrectly (see attached image).
This occurs only when I use said commands to skip entire segments of code, and the issue immediately disappears (the line numbers are rendered correctly, that is) if I start navigating the buffer by other means.
The issue is present in both C and C++ modes (visualized), and I'm using Emacs 24.3.1 on x86-64 Fedora 19.
While the go-to-line command serves my purposes in terms of navigating compilation errors and warnings, I'd like to keep the line numbers as I find them to be helpful in terms of quickly approximating length of functions.
So far I've found no mention of this problem elsewhere, and I'm unsure of whether or not this is expected behavior of Emacs or if I'm to submit a bug report.
Has anyone encountered the issue or know anything of its origin?
Fix:
The problem may be resolved by invoking (linum-update-current), as portrayed by #lawlist in his answer below. An easy way of repeatedly doing this is to append the command to the execution of forward-paragraph, which may be done using the Emacs Lisp advice feature:
(defadvice forward-paragraph (after forward-paragraph-linum-update)
"Perform (linum-update-current) after jumping forward one
paragraph to ensure line numbers are being rendered
correctly."
(linum-update-current))
(ad-activate 'forward-paragraph)
A few of the lead members on the Emacs development team suggest that linum-mode be avoided for a variety of reasons, and instead they suggest using nlinum-mode: http://elpa.gnu.org/packages/nlinum.html
I personally use a modified version of linum-mode, and I have fixed a few bugs -- if you keep using linum-mode, you will likely need to do the same -- i.e., implement your own bug fixes as you find them. The quickest way to fix the bug you see is to follow your command with:
(linum-update-current)
I am coding in fortran90 on Emacs (no-windows mode) with fortran-mode. I have only used Emacs for Python for which it works without problem but now that I have switched to fortran90 I have many little issues that I don't know how to configure.
The biggest problem I have is with the commenting region command. I usually use M-; to comment regions but I get something like this:
c$$$ if (x1.eq.0) then
I know about the command
C-x r t
which actually does the trick (I can insert a ! at the beginning of each line) but I am so used to the M-; command and I wish I could keep using it. Also, with the latter command I can comment and un-comment the region.
So what I want to do is to replace the symbol for commenting in (and only in) fortran-mode. And such that it works every time I open/close Emacs with fortran-mode.
Thanks!
I haven't coded in Fortran for the last 30 years (!), and I'm not acquainted with Fortran mode in Emacs. But looking at library fortran.el I see that there are some user options for customizing comment behavior. Take a look at them by using M-x customize-group fortran-comment. The doc for each should be self-explanatory. If not, more info is available in the Emacs manual -- see node Fortran and its subnodes, in particular, node Fortran Comments. It specifically talks about M-; in the context of Fortran mode, for instance.
When I have Greek characters in emacs the line spacing before the next line is increased, which is pretty annoying and weird. Strangely any other unicode characters seem to be fine.
What is going on here and how can I make the line spacing consistent with other characters?
The version of emacs is:
GNU Emacs 24.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.12) of 2012-09-22 on batsu, modified by Debian
on linux mint (and using xmonad as a window manager but I doubt that has anything to do with it).
The example above is using "emacs -q" launched from a urxvt terminal with no .Xdefaults file (I then enabled linum-mode so that the line spacings are more visible).
Edit: The same thing happens if using the "-Q" options (I only just found out the difference between -q and -Q).
It seems that the Greek letters are from a completely different font. In addition to stylistic difference, this may cause different line height. So check out whether you can change the font to one that contains all the characters needed.
Really annoying problem in ipython prompt in emacs:
In [128]: if 1==1:
.....: print "yes"
.....: else:
.....: print "no"
.....:
IndentationError: unindent does not match any outer indentation level
It looks perfectly aligned to me, not sure what trigger the error. No such problem when I do this in terminal.
You might try toggling autoindent with
%autoindent
since I think that has caused the problem for me before.
You can change this permanently using ipython's customization. After the proper imports (see the link) the following should work in ipy_user_conf.py:
# Emacs sets the term to dumb so we can distinguish that way
if os.environ['TERM'] == 'dumb':
ip.options.autoindent = 0
Yeah, this is strange. On my end, using the standard python interpreter within an emacs shell works fine when evaluating your code, but using ipython fails. If you're using the python-mode.el package, you probably need to install ipython.el to get proper ipython support. OTOH, if you're using the python.el that normally ships with emacs, you may have to switch to the standard python interpreter (I believe ipython.el is only intended for use with the third-party python-mode.el package, not the python.el that emacs uses by default).
Everytime I insert a snippet (with yasnippet) in a .tex document, I obtain a newline after the snippet. This is quite annoying for small snippets that are typically used in text style. How can I avoid that?
I read a bit about the problem (http://code.google.com/p/yasnippet/issues/detail?id=115 or http://yasnippet.googlecode.com/svn/trunk/doc/faq.html) but couldn't find a solution. Reproduce it as follows (I work with Aquamacs 2.3a on Mac OS X 10.6.8 with yasnippet version 0.6.1c):
Define ~/Library/Preferences/Aquamacs Emacs/Preferences.el to be:
(require 'yasnippet)
(yas/initialize)
(yas/load-directory "~/Library/Preferences/Aquamacs Emacs/plugins/yasnippet-0.6.1c/snippets")
define the following snippet (call it "bm.yasnippet" [bm = boldmath]; the star * symbolizes where the cursor ends -- note that there is no newline after the snippet)
# name: \bm{}{}
# key: bm
# --
\bm{$1}*
restart Aquamacs and open a .tex file and type in bm + Tab [this should insert the snippet]
A newline is added after the snippet. This is quite inconvenient since \bm{foo} is typically used in text style, so for example in "The vector \bm{x} is not the null vector". A typical cause of this is that the snippet ends with a newline which is then inserted, too. However, I specifically obtain this behavior even the snippet does not end with a newline.
I can't repro it with plain Emacs. In fact, I had this exact issue, but my problem is I had require-final-newline set to t. So Emacs was adding a newline at the end of my template.
My setup is a little more complicated but the solution for you is probably to set mode-require-final-newline to nil and restart Emacs.
To verify this is the problem, open up the template and check for the final newline.
Thanks to the answers in Temporarly disable adding of newlines in Emacs, I'm using a function to only temporarily disable the adding of final newlines in the current buffer:
(defun disable-final-newline ()
(interactive)
(set (make-local-variable 'require-final-newline) nil))
the reason why u got a new line is that your snippet has space or tab at the end.
Ctrl+e and Ctrl+k to kill them will make it works, nearly 1 hour to figure it out...
I had a similar issue with a few snippets, one of that was \frac{}{} which I use quite often.
The snippet version of frac that I use is not the one bundled with yasnippets.
The issue was that I edited some of the snippets in VIM and when you save the file, VIM automatically appends a newline to it.
To resolve it I had to remove the newline in a different editor e.g. emacs.