Re: [O] Possible bug: List items with * in them when *:nil
Hi Jonathan, Jonathan Leech-Pepin writes: > The following sample org file does not export as possibly expected. > > ,--- > | #+TITLE: Bug? > | #+OPTIONS: *:nil toc:nil author:nil > | > | - hello (*) I would like to have two items > | - may (*) I please? > `--- > > Instead of the two items being listed with (*) as a part of their > items they are placed on a single line as though they were still > being > wrapped in bold tags. I tested this further and it occurs in LaTeX, > HTML and ODT exports. ASCII does the right thing and exports it as > two list items. 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. HTH, PS: FWIW, I also sent this reply to StackOverflow, thanks for forwarding questions from there to here! -- Bastien
Re: [O] Unexpected behaviour while adding checkboxes
Hi François, pin...@iro.umontreal.ca (François Pinard) writes: > Given this Org fragment: > > * Essai > - Le > - petit :: chaperon > - rouge > > with the cursor on the "L", command `C-u C-c C-c' yields: > > * Essai > - [ ] Le > - petit :: chaperon > - [ ] rouge > > while I was expecting: > > * Essai > - [ ] Le > - [ ] petit :: chaperon > - [ ] rouge > > Is there a bug, or do I miss something? If you try C-u C-c C-c on the "- petit :: chaperon" item, you will read this message "Cannot add a checkbox to a description list item" So no, there is no bug here. HTH, Ps: I would advise not mixing list types, e.g. not mixing plain list and descriptive list. -- Bastien
[O] Unexpected behaviour while adding checkboxes
Hi, Org people. Given this Org fragment: --8<---cut here---start->8--- * Essai - Le - petit :: chaperon - rouge --8<---cut here---end--->8--- with the cursor on the "L", command `C-u C-c C-c' yields: --8<---cut here---start->8--- * Essai - [ ] Le - petit :: chaperon - [ ] rouge --8<---cut here---end--->8--- while I was expecting: --8<---cut here---start->8--- * Essai - [ ] Le - [ ] petit :: chaperon - [ ] rouge --8<---cut here---end--->8--- Is there a bug, or do I miss something? François P.S. In case it matters, I'm using a recent pull of Org mode.
[O] italicizing urls
since a url uses the forward slash as do italicized items, i'm having difficulty italicizing urls on the html export. /just [[http://gohere.com][go here]] will you?/ shows up as /just go here will you?/ on the html export (though the go here link is valid) with nothing italicized and the forward slashes visible. i can get around it this way to some extent: /just/ [[http://gohere.com][go here]] /will you?/ but was wondering if there is a better way since the "go here" is still not italicized. -- in friendship, prad
Re: [O] Export without code blocks
Thanks Martyn, that was a big help. aaron. On 27 January 2012 14:04, Martyn Jago wrote: > Martyn Jago writes: > > > Hi Aaron > > > > aaron barclay writes: > > > >> Hi, > >> > >> I am having trouble finding the correct way to export a document without > >> the code blocks included. Should I be using #+EXPORT_EXCLUDE_TAGS? I > can't > >> seem to get it to work, anyone have the correct syntax? > >> > >> cheers, > >> aaron. > > > > #+EXPORT_EXCLUDE_TAGS is for defining tags (such as NO_EXPORT) to > > prevent headings or sub-headings (branches) being exported. As in: > > > > ** don't export me :NO_EXPORT: > > stuff > > > > Possibly what you need is :exports none or :exports results : > > > > begin_src python :exports results > > print "result" > > end_src > > Of course this won't work in python since it will 'print' result, but > not return it. so you also need :results output which makes, the `result' > that which is printed to STDOUT (standard out). > > > What format are you exporting too? > > > > Best, Martyn > > >
Re: [O] org-src-fontify-natively
Hi Dov, Dov Grobgeld wrote: > A solution would be that all org-mode faces would inherit a common > org-mode-face. You could then customize this font to a variable-pitch > without using the ~variable-pitch-mode~ command. Is this feasible? There is `org-default', but I don't know if it solves your problem? For making your blocks _really_ standing out, use as well a config like this: (org-block-begin-line ((t (:underline "#A7A6AA" :foreground "#55" :background "#E2E1D5" (org-block-end-line ((t (:overline "#A7A6AA" :foreground "#55" :background "#E2E1D5" Best regards, Seb -- Sebastien Vauban
[O] New iCalendar import script
Hi all, I've written an iCalendar import script in ruby (I know, not emacs lisp, but at the least I should let you be aware). I think it's an improvement over the awk script, so you may consider mentioning it in the appropriate places. See https://github.com/simonthum/ical2org It has more complete iCalendar support, in particular repeating dates and Todos. Likely it is easier to adapt to individual requirements. Also, it works under windows and linux - my win32 awk was missing key functionality for the script (mktimestamp, IIRC). I'm not particularly attached to CC-BY or github, so if you think a more appropriate long-term place would be orgmode.org then we'll probably find a way. It's in its early stages, for example I'm quite unsure about the timezone support, so feedback is more than welcome! Cheers, Simon
[O] Possible bug: List items with * in them when *:nil
The following question came up on Stack Overflow:
http://stackoverflow.com/questions/9051330/possible-bug-in-org-mode-export-of-item-with
The following sample org file does not export as possibly expected.
,---
| #+TITLE: Bug?
| #+OPTIONS: *:nil toc:nil author:nil
|
| - hello (*) I would like to have two items
| - may (*) I please?
`---
Instead of the two items being listed with (*) as a part of their
items they are placed on a single line as though they were still being
wrapped in bold tags. I tested this further and it occurs in LaTeX,
HTML and ODT exports. ASCII does the right thing and exports it as
two list items.
HTML:
,--
|
| hello (*) I would like to have two items - may (*) I please?
|
|
`--
LaTeX:
,---
| \begin{itemize}
| \item hello (*) I would like to have two items - may (*) I please?
| \end{itemize}
`---
Is this the expected behaviour when *:nil is set on export? I know
you can simply escape the *'s as \* to get the desired result (both
with and without *:nil). However it does seem odd to me that it will
insert the *s as expected in the export, while at the same time keep
the text wrapping that *[...]* creates for bold-face purposes.
Regards,
Jonathan
Re: [O] change call-process also for GNU emacs? (was: Solved)
Uwe Brauer wrote: > >> On Sat, 28 Jan 2012 19:13:57 -0500, Nick Dokos > >> wrote: > >>> > >> ... and bonus points if you also fix the problems described in > > Now I am confused, from the link, you provided, I conclude > you are talking about GNU Emacs, however I only wanted my changes to > work with Xemacs and therefore wrap a > > (if (featurep 'xemacs) > > Around my changes. If you want to have the changes I have in > mind for call-process also for GNU Emacs, I think the > maintainers should have a say. > Actually, it might very well be that they are Xemacs problems as well, but you are right: I meant that since you'd be visiting the area, I might convince you to do some additional work and fix those bugs as well. Nick
[O] change call-process also for GNU emacs? (was: Solved)
>> On Sat, 28 Jan 2012 19:13:57 -0500, Nick Dokos >> wrote: >> > ... and bonus points if you also fix the problems described in Now I am confused, from the link, you provided, I conclude you are talking about GNU Emacs, however I only wanted my changes to work with Xemacs and therefore wrap a (if (featurep 'xemacs) Around my changes. If you want to have the changes I have in mind for call-process also for GNU Emacs, I think the maintainers should have a say. Uwe Brauer
Re: [O] [babel] #+call-line removes hlines and headings ?
Am 29.01.2012 11:42, schrieb Andreas Leha: :colnames yes Hi Andreas, Thanx, that is definitely a solution ! And I agree with you, that its a bit puzzling, that both cases behave differently; the #+call-line should just have the same result as the #+begin_src-line, to which after all it just refers. Beeing able to change the behaviour of the #+call-line with header arguments is of course a good thing, but it should not be necessary here in the first place. However, this would require a patch to the babel-code, which I am currently not able to produce, because I already got lost in debugging this problem :-) And of course I am not sure what would be the side effects of changing this behaviour ... So, thanx again for pointing out this very easy workaround ! with kind regards, Marc-Oliver Ihm
Re: [O] [babel] #+call-line removes hlines and headings ?
Marc-Oliver Ihm writes: > Hello ! > > Generally enjoying babel very much, I have stumbled across a behaviour, that > I do not quite understand: > As it seems, a #+call in babel removes hlines from the results. > > Here is an example: > > #+call: foo() > | 3 | 4 | > #+name: foo > #+begin_src emacs-lisp > '((1 2) hline (3 4)) > #+end_src > > #+results: foo > | 1 | 2 | > |---+---| > | 3 | 4 | > > > The #+begin_src-line does what I would expect; however, when it is called > through a #+call-line the hline > and the heading are removed. > > Is this the intended behaviour, a bug or am I missing something obvious ? > > Thanx a lot for any help ! > > with kind regards, Marc-Oliver Ihm Hi Marc-Oliver, it works with #+call: foo() :colnames yes The more surprising part for me is, that it works on the block itself without. Best, Andreas
Re: [O] Adding the ability to archive into the datetree (updated)
Bastien writes: > thanks for this patch -- it on my radar now, along with these > other changes that I want to incorporate before the new release: > > - Patch by Niels to customize output table in LaTeX, combined > with the patch of Christophe Rhodes. (Carsten, are you still > on it or can I safely digg in there?) > > - Patch by Dave Abrahams for human-readable links. > > - The branch for the Makefile by Achim. Plus, of course, the patch by Litvinov Sergey and/or Bernt Hansen for fixing problem in agenda narrowing, which requires careful testing. -- Bastien
Re: [O] Adding the ability to archive into the datetree (updated)
Hi Andrew, Andrew Hyatt writes: > I've fixed all the reported issues, and am attaching the modified > patch. I'd love for this to get into the next release. If anyone has > a desire to try this out, I'd love to hear if it is clear how to use > it, and if you encounter any issues. thanks for this patch -- it on my radar now, along with these other changes that I want to incorporate before the new release: - Patch by Niels to customize output table in LaTeX, combined with the patch of Christophe Rhodes. (Carsten, are you still on it or can I safely digg in there?) - Patch by Dave Abrahams for human-readable links. - The branch for the Makefile by Achim. There might be other changes, of course. Thanks for your patience, -- Bastien
Re: [O] Possible bug in org-cycle with property drawer
Achim Gratz writes: > Bastien writes: >> This is quite a hypothetical case: the default value for `org-drawers' >> contains drawers that are hardcoded and correspond to key features: I >> cannot figure out a good reason for *not* having these drawers in the >> configuration. > > As a customized variable org-drawers can have any content the user > choses, including none. Before your change, the documentation said that > drawers can be _defined_ (not added) on a per-file-basis. Past your > change, documentation now says that drawers can be _added_ on a per-file > basis (minor nit: org-drawers is no longer the corresponding variable to > a file-local setting, but the basis onto which the file-local-setting is > appended). Yes, you're right, and you put it very well. If there is anything that you can suggest to enhance the documentation here, please do. `org-drawers' contains the default drawers for all files, and #+DRAWERS lets the user add new drawers on top of these default drawers. E.g. if a user have a "HIDE" drawer that he wants to use in any Org buffer, it's a good idea to put it in `org-drawers'. If there is a buffer-local drawer he want just for one file, it's a good idea to add it using #+DRAWERS. > Existing documents will still define _all_ drawers, not just > the additional ones, however it seems you add them without checking if > they are already present (I'd think add-to-list would be better than > append). Fixed, thanks. > Now, there might be a good reason to have system drawers that the user > can't change easily, but then they should not be defined in org-drawers, > perhaps? I suggest this: (defconst org-persistent-drawers '(...)) (defcustom org-custom-drawers '(...)) Then local value of org-drawers would be computed by combining the two (with duplicates deletion.) Would that be consistent to you? -- Bastien
Re: [O] Tweaking the export
Hello, Christian Wittern writes: > Exactly. The reason for wanting to do this is that the above is my > setup for translating, but in some cases the publication will have > only the translation, for such cases, I want to extract just the > translation. This should then produce a new org file, that simple has > either everything before the tab (the original) or everything after > the tab (the translation), while leaving all lines that do not contain > a character as they are. > > I assume this would be an easy task with the new exporter -- but still > a bit at loss on where to start... >From here, I'll assume that: 1. you only split paragraphs (not tables, or lists, and so on); 2. your back-end is called `translator'; 3. you never use tabs in objects (links, latex-fragments). The first step would be to initialize a property that will allow to control the side of the paragraph being exported: #+begin_src emacs-lisp (defconst org-translator-option-alist '((:translator-side nil nil left))) #+end_src Another step will be to create the basis of `translator', that is an Org to Org back-end. 1. For each ELEMENT in `org-element-all-elements', you need to created an appropriate transcoder in the following shape: #+begin_src emacs-lisp (defun org-translator-ELEMENT (element contents info) "Convert ELEMENT from Org to Org syntax." (org-element-ELEMENT-interpreter element contents)) #+end_src This can be done quickly with a macro or some elisp. 2. You should do the same with each OBJECT in `org-element-all-successors': #+begin_src emacs-lisp (defun org-translator-OBJECT (object contents info) "Convert OBJECT from Org to Org syntax." (org-element-OBJECT-interpreter object contents)) #+end_src Though, you will need to duplicate and rename some functions created, as some objects share the same successor. Thus: - `org-translator-sub/superscript' will be split into `org-translator-subscript' and `org-translator-superscript'; - `org-translator-text-markup' will be split into `org-translator-emphasis' and `org-translator-verbatim'; - `org-translator-latex-or-entity' will be split into `org-translator-entity' and `org-translator-latex-fragment'. 3. If all went well, you now have an impressive Org to Org converter. You can even test it with: #+begin_src emacs-lisp (switch-to-buffer (org-export-to-buffer 'translator "*Translation*")) #+end_src Obviously, there is not much to see. Now, we're going to redefine `org-translator-paragraph' to properly ignore one language or the other, depending on `:translator-side' value. #+begin_src emacs-lisp (defun org-translator-paragraph (paragraph contents info) "Convert PARAGRAPH to Org, ignoring one language. Language kept is determined by `:translator-side' value." (let ((leftp (eq (plist-get info :translator-side) 'left))) (replace-regexp-in-string (if leftp "\t+.*$" "^.*\t+") "" contents))) #+end_src Eventually, you need to define two commands to respectively keep left and right parts and save the output in an appropriate file. #+begin_src emacs-lisp (defun org-translator-left (file) "Save buffer in FILE, with only left language in paragraphs." (interactive "FFile (left language): ") (org-export-to-file 'translator file)) (defun org-translator-right (file) "Save buffer in FILE, with only right language in paragraphs." (interactive "FFile (right language): ") (org-export-to-file 'translator file nil nil nil '(:translator-side right))) #+end_src This is completely untested. Regards, -- Nicolas Goaziou
Re: [O] org mode in press
On 2012-01-28 22:59, rick frankel wrote: The dot executable is part of the graphviz package. Installing graphviz should install the dot command line executable alongw w/ neato, circo and and other layout engines. Rick Thanks to all who pointed this out. $sudo port install graphviz did the trick for me, now all dependencies are met. Yeah! Christian -- Christian Wittern, Kyoto
[O] [babel] #+call-line removes hlines and headings ?
Hello ! Generally enjoying babel very much, I have stumbled across a behaviour, that I do not quite understand: As it seems, a #+call in babel removes hlines from the results. Here is an example: #+call: foo() | 3 | 4 | #+name: foo #+begin_src emacs-lisp '((1 2) hline (3 4)) #+end_src #+results: foo | 1 | 2 | |---+---| | 3 | 4 | The #+begin_src-line does what I would expect; however, when it is called through a #+call-line the hline and the heading are removed. Is this the intended behaviour, a bug or am I missing something obvious ? Thanx a lot for any help ! with kind regards, Marc-Oliver Ihm
Re: [O] Possible bug in org-cycle with property drawer
Bastien writes: > This is quite a hypothetical case: the default value for `org-drawers' > contains drawers that are hardcoded and correspond to key features: I > cannot figure out a good reason for *not* having these drawers in the > configuration. As a customized variable org-drawers can have any content the user choses, including none. Before your change, the documentation said that drawers can be _defined_ (not added) on a per-file-basis. Past your change, documentation now says that drawers can be _added_ on a per-file basis (minor nit: org-drawers is no longer the corresponding variable to a file-local setting, but the basis onto which the file-local-setting is appended). Existing documents will still define _all_ drawers, not just the additional ones, however it seems you add them without checking if they are already present (I'd think add-to-list would be better than append). Now, there might be a good reason to have system drawers that the user can't change easily, but then they should not be defined in org-drawers, perhaps? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
