I'm using org mode to make a list that I would like exported to PDF. some items in the list have the combination (*) and this seems to throw org mode off.
This MWE
#+TITLE: Bug?
#+OPTIONS: *:nil toc:nil author:nil
- hello (*) I would like to have two items
- may (*) I please?
results in
even though the #+OPTIONS: *:nil part was obviously read and understood (the part between the stars is not bold as it would be had that line been missing.
Is this is bug? Am I doing something wrong? Is there a workaround?
The *:nil option is not the problem here.
The problem comes from the fact that the * in (*) actually do emphasize the text (it is in bold font in the buffer). Given that, the exporter does its best, which is not very good.
The bug here is to allow multiline fontification over distinct list items -- we'll try to fix it, but that's a rather complex issue.
On top of the workaround above, have a look at `org-emphasis-regexp-components', thru which you can prevent parentheses as post/pre-characters in a fontified string.
I found a work-around for this behavior (bug?): add an empty line between the two offending lines:
#+TITLE: Workaround!
#+OPTIONS: toc:nil author:nil
- hello (*) I would like to have two items
- may (*) I please?
gives:
Thus allowing the string (*) to exist in an item (or rather in two consecutive items)
I'm not certain if this is a bug or not. I was able to reproduce it, however if I escaped the * the export occurred as expected.
#+TITLE: Bug?
#+OPTIONS: toc:nil author:nil
- hello (\*) I would like to have two items
- may (\*) I please?
Latex created:
\begin{itemize}
\item hello (\*) I would like to have two items
\item may (\*) I please?
\end{itemize}
I will however post the question to the mailing to confirm whether this is the expected behaviour or not in this situation. The thread for this question is HERE.
EDIT I edited to correct the LaTeX that was exported (needed to add this as 1 char is not enough, feel free to remove this line.)
Related
I love Emacs and Org-Mode. But I can only stand to use Org Mode in the clean view (or whatever it's called - with org-indent-mode on).
My problem is that I often want to use headers that don't have a bullet in front of them. I want one asterisk to be the start of the list, not the header.
Example:
List 1
List 2
Header 1
List 3
List 4
But when I try to do this, Header 1 gets indented to the level of List 2.
I know just turning off org-indent-mode and getting used to that is one solution. But is there a way to reset the indentation for Header 1?
The things you are talking about changing are pretty fundamental to org-mode; basically you are trying to change the org-mode syntax. The reason why Header 1 in your example is not being dedented, is that org-mode does not see it as a headline, because headlines by definition start with leading stars. Also, while it is technically supported to use * to identify a plain list item, this is not recommended, and can cause some unexpected behavior (see footnote 1 here).
That being said, you can have some control over the appearance of headlines. For example, you can use the org-bullets package. You can then define the bullets to use in place of * like this:
(setq org-bullets-bullet-list
'("◉" "◎" "⚫" "○" "►" "◇"))
which will define the bullets used for the first six levels of headlines. You can replace the bullets in that list with other utf-8 symbols, and you can even use " " as one of the symbols, so that your Headlines will be preceded by a single space. However, note that this only affects the way headlines are displayed; they will still be preceded by * in the actual file.
I know it is not very helpful, but my overall suggestion would be to stick with the org-mode syntax if you want to use org-mode, i.e., use a structure like this:
- List one
- List two
* Header 1
- List three
- List four
with * starting a headline, and - starting a plain list. Since org-mode files are just plain text, the magic of that mode depends heavily on those files having a set structure. In my own experience, if you try to change that structure (another example is changing timestamp formats), it will cause more headaches than it relieves, and cause a lot of the functionality that makes org-mode so great to break.
Just as a side note: I prefer a cleaner view as well, and one option I like to enable in addition to org-indent-mode is (setq org-hide-leading-stars t), which will display only a single star/bullet per headline (although the leading stars will still be present in the actual text file).
I want to use the capture module of org-mode to create a data base of new words that I want to learn, and then use the drill module to learn them (flash cards style).
In my org-capture-templates I added the following:
("v" "Vocabulary" entry
(file+headline (concat org-directory "/vocab.org")
"Vocabulary")
"* Word :drill:\n%^ \n** Answer \n%^")
This is a rather naive template which I borrowed from here. It works fine but it is too limited. Unfortunately I'm rather new to elisp and I don't know how to improve it.
I think the above template has to be improved in the following there aspects:
Headline Currently the first input string is the (new) word and the headline is fixed. How can the headline be the same (input) word? I think that the following result is desirable:
* Vocabulary
** Foo :drill:
Foo
*** Answer
What is foo
Actually an even better way would be to have 3 input strings.
The new word (for example foo) which will be the headline.
If the second is empty, then it gets the same string as (1). Otherwise, concatenates the string to the one from (1). E.g. having as second input bar would yield foo bar. This will be the content of the entry.
The word's definition which should come in the answer sub-headline.
Duplications (see again this) If at some later point I try to capture foo again, I would like to know it, and be directed to edit the already existing entry - skipping all the inputs.
Sorting After capturing I think it would be nice to sort the list of words. This should not be too hard given that the headline of each entry is the word itself. In this case one can probably use the org-sort-entries function.
I know this is a rather big questions but I also think that if it can be solved here it will be of great use to many users.
Edits:
Using #juan_g suggestions, I improved my template and now it is:
("v" "Vocabulary" entry
(file+headline (concat org-directory "/vocab.org")
"Vocabulary")
"* %^{The word} :drill:\n %t\n %^{Extended word (may be empty)} \n** Answer \n%^{The definition}")
I didn't manage to set the default value of the second input to be the 1st one. I tried something like %^{Extended word (may be empty)|%\1} but it returns ^A which is not helpful.
In any case, this improved version seems to be already usable.
About the input question, in Org Mode Manual: 9.1.3.2 Template expansion, there is the %\1 special escape code:
%\n Insert the text entered at the nth %^{prompt}, where n a number, starting from 1.
The duplications question probably would need some Emacs Lisp coding.
For sorting, see C-c ^ (org-sort).
BTW, org-drill seems indeed a really interesting package, based on SuperMemo's spaced repetition algorithms.
You need an extra "\", therefore %\\1 works as expected.
I am following this tutorial, and I am getting this error, when I try to export the presentation to latex:
No definition for class `beamer' in `org-export-latex-classes'
Note:
I installed emacs from the repository in Ubuntu. And following are the related packages that are available in my system:
emacs-snapshot
emacs-snapshot-bin-common
emacs-snapshot-common
emacsen-common
latex-beamer
latex-xcolor
preview-latex-style
texlive-latex-base
texlive-latex-extra
texlive-latex-recommended
Am I missing anything? Do I have to configure other things?
I found I had to run M-x org-beamer-export-to-pdf to get it to work.
Yes., you should define beamer class in org-latex-export-classes. an example how to define is in this blog post
Edit: updating for 2022 and to make reproducibility more straightforward
The original answer is below, untouched since ~2011. I still think the top upvoted answer and accepted answer aren't necessary in 2022, and org-mode is notoriously hard to troubleshoot without walking through fundamentals:
.emacs and other config files
the exact .org file used
In trying to recreate the worg tutorial cited, I think it no longer works as-is. Note that the manual cites a different example now.
In any case, here is a github repo I created with the following to help any others who find this:
a min-config (with no custom org-latex-classes definition for beamer as the accepted answer suggests
a modified beamer_test.org that exports for me using the min-config; some minor tweaks were necessary
the pdf and org file with _ref in the name; when users export, they can compare their generated pdf and tex files (the ones in the downloaded repo will be overwritten) to these references to study differences and better identify issues
Hopefully this better removes confusion for any stumbling on this question.
Final note: I believe my answer below was potentially wrong always, or became wrong at some point in the past 10yrs, as it should be C-c C-e l and P for the final option (beamer pdf), not p (regular latex pdf). I don't remember org-mode that far back to know if p ever worked given the #+latex_class: beamer setting or not.
Edit 2 as ceochronos points out in the comments, my answer was probably always wrong anyway, as I left out the lower case L in the export options C-c C-e p vs. C-c C-e l p. Then again, C-c C-e is an interactive menu with no p option, so hopefully it didn't mess with the minds of too many folks over the years!
The accepted answer shouldn't be necessary anymore. There is a built in function for Beamer export. See this tutorial for details. In essence, just put the following at the top of an org file (before any headlines):
#+startup: beamer
#+LaTeX_CLASS: beamer
#+BEAMER_FRAME_LEVEL: 2
First option brings in some beamer specific options, second makes sure export to LaTeX uses the beamer class, third option means top level headlines are sections, second levels are slides. Change value to 1 for just every top headline being a slide.
Then export with C-c C-e p.
Only exporting to PDF worked after I've exported to a TeX file first with org-beamer-export-to-latex
I know different methods of introducing multi-line comments in Perl. But I want to know why it doesn't have something simpler multi-line comment feature such /* comment */, which would make it much easier.
I currently follow http://www.perlmonks.org/?node_id=560985 to achieve multi-line comments. Are there any plans to include this feature in Perl anytime soon?
C-style comments come with a variety of difficult problems, including the inability to comment-out comments. Additionally, convenient syntax for one-line encourages concise writing, which makes your code easier to read. The absence of 10-line "Author: ... Input: ... Output: ... Favorite Color: ..." blocks that you see from time to time in C and C++ is another benefit.
Multi-line comments encourage long writing that is better expressed more concisely or as documentation, so this is what Perl encourages with its # and =pod operators (respectively).
Finally, if you are having trouble with Perl's style of commenting, you should configure your editor to edit programs, not text. In Emacs, if you start writing something like # this is a comment that is getting longer and longer and longer and oh my goodness we are out of space on this line what to do now and type M-q, Emacs will automatically insert the # at the beginning of each line that it creates.
If you just want to comment-out a block of code, then you need look no further than M-x comment-region and M-x uncomment-region, which will comment out the region in pretty-much any language; including Perl.
Don't stress about the syntax of comments; that's the computer's job!
There was a discussion regarding this on the perl6-language#perl.org mailing list. Although in the end the discussion was inconclusive, the summary posted here makes for interesting reading.
As with any multiline comment structure, there will be a "open" and a "close" comment condition, and that leads to problems with nested comments.
for example, C uses /* as the open and */ as the close. How does a multiline comment system handle comments within comments? C will fail if you try to comment a block that is already commented.
Note that line-based comments (e.g. c++ // comments) do not suffer this problem.
Simplicity is in the eye of the beholder. That said, there are already a number of ways to do multi-line comments. First, void string literals:
q{This text won't do anything.
Neither will this.};
This has the unfortunate side effect of triggering a warning:
Useless use of a constant in void context at - line 4.
Another option is using a heredoc in void context - for some reason this doesn't cause a warning:
<<ENDCOMMENT;
Foo comment bar.
ENDCOMMENT
As you can see, the problem isn't the lack of syntax as such (python doc comments look vaugely similar to the q{} method in fact) - it's more just that the community of perl programmers has settled on line comments using # and POD. Using a different method at this point will just confuse people who have to read your code later.
I want to fully-justify latex code on EMACS so that my latex code will look better. For example, I remember my advisor sending me latex in fully justified way like this:
In ~\cite{Hummel2004}, authors described an approach for harvesting
software components from the Web. The basic idea is to use the Web as
the underlying repository, and to utilize standard search engines,
such as Google, as the means of discovering appropriate software
assets. Other researchers have crawled through Internet publicly
available CVS repositories to build their own source code search
engines (e.g., SPARS-J)~\cite{Matsushita2005}.
I suppose that his column-width is set to 70 columns.
Could someone give me a hint?
The standard fill.el package includes the command justify-current-line which is part of what you need. From the function help:
Do some kind of justification on this line.
Normally does full justification: adds spaces to the line to make it end at
the column given by `current-fill-column'.
Optional first argument how specifies alternate type of justification:
it can be `left', `right', `full', `center', or `none'.
If how is t, will justify however the `current-justification' function says to
And other posters have already given you the magicall invokation:
M-x set-justification
As a philosophical side note, the point of fixed-wdith text justification is to fake real typography on a inflexible output device. So applying it to LaTeX source seems a little odd to me. Moreover, I have been using the "one sentence to a line" approach to LaTeX documents for some months now, and find that it really does improves both the editability and the source-control behavior of LaTeX, so I would recommend against doing this.
If you select the region, and then press Ctrl-u M-x fill-region you get "full justification".
M-x set-justification-full
Use Refill mode afterwards to not have to run the command again after typing.
To get line wrap in the file itself (as opposed to something like longlines-mode that does not alter the structure of the file), I use auto-fill-mode, which automatically applies M-q (fill-paragraph) to each paragraph. For example, I use auto-fill-mode in mail-mode. You could do something similar with your LaTeX mode with a hook like this:
(add-hook 'TeX-mode-hook 'turn-on-auto-fill)
Assuming your TeX mode's hook is TeX-mode-hook.