[O] org-fill-paragraph breaks timestamps
Hi list, In plain lists, I sometimes insert timestamps in running text (for an item to appear in the agenda), then fill it with org-fill-paragraph. Sometimes, the timestamp is splitted (at any of both spaces), breaking the desired agenda behavior. Is there something I can do for this not to happen ? I guess the filling function should recognize the timestamp not to split it, but my lisp knowledge makes it more of a feature request than anything else. -- William (Like so : 2013-02-09 Sat 14:46)
[O] OT, but not really: todays XKCD
Hi everyone. I am sorry for the spam, but todays XKCD http://xkcd.com/1172/ is just too good to not share here, together with this piece of data: $ grep defcustom lisp/*el contrib/lisp/*el |wc -l 1213 Hurray for Nicolas and Bastien to be brave and switch to the new exporter framework which is a thing of beauty. Lets help them to fix the bugs as quickly as possible and then make those small adaptations in our workflow - it will be worth it. - Carsten
Re: [O] OT, but not really: todays XKCD
Dominik, Carsten c.domi...@uva.nl writes: Hurray for Nicolas and Bastien to be brave and switch to the new exporter framework which is a thing of beauty. It is an umbrella statement and doesn't mean much in and of itself. Let me clarify, Bastien has very miniscule (~ZERO) contribution to the new framework or the exporters. I was forced to respond because your mail will be read by many. People tend to impose their own meanings in to statements. IMNSHO, clubbing Nicolas work with Bastien, is doing Nicolas a big dis-service and giving Bastien an association that he doesn't deserve. I will also encourage people who donate to Orgmode - particularly those who will be donating for impending Org-8.0 release - to make targeted donations to Nicolas Goaziou (exclusively) or take his advise on how the funds should be routed (if he is averse to taking donations). A targeted donation (for individual work or hosting the servers) is much better than an umbrella donation to Orgmode or Bastien. Let's share good will and credit where it is due and NOT give credit when nothing is due. This is important when one is respected, trusted and is in position of some influence. I am particularly worried to see recent call for donations on Google+ which raised to the pitch to that of religious fundraising. ps-1: I have openly stated that I have no interest in partaking of or seeking donations for Emacs/Orgmode related work. I consider my existing work as a donation themselves. --
Re: [O] latex code block evaluation
Hi Sebastien,
Sebastien Vauban
wxhgmqzgw...@spammotel.com writes:
Hi Henry,
henry atting wrote:
I have this latex code block:
#+begin_src latex :file foo.pdf
\documentclass{article}
\begin{document}
...some text...
\end{document}
#+end_src
After evaluation the resulting file looks like this:
article ...some text...
I do not understand this. As far as I know it is possible to define the
latex documentclass within a code block.
Could you be more explicit? Do you want to use that to pass parameters to the
LaTeX backend? If yes, why not using the #+LaTeX: directive (not sure
they're still supported with the exact same syntax as before -- I've not yet
merged my documents). And that brings us to the most important question: old
or new exporter?
Eventually, can you send a real ECM, or your real use case?
Ah, I see, I was unclear.
In this case I simply want to evalutate this code block with `C-c C-c'.
I do not use the orgmode LaTeX exporter, only the HTML exporter.
Finally I will create org files with LaTeX code blocks which I will export to
HTML. And that's all. HTML export works fine with the old or the new
exporter.
Though in this case it is not really indispensable I only was wondering why
code block evalution does not work as expected. Why is
`\documentclass{article}' not recognized properly?
Best regards,
Seb
Greetings,
henry
Re: [O] Fwd: Re: Bug? in texinfo exporter
On Feb 11, 2013 1:59 AM, Nicolas Goaziou n.goaz...@gmail.com wrote:
t...@tsdye.com (Thomas S. Dye) writes:
Aloha Jon,
[...]
Yes, I believe you are right. The commas are not the culprits.
Apologies for the red herring.
Perhaps Nicolas should revert the commit? Could you check if this is
the right thing to do?
My fix isn't about the comma. Didn't it work?
Your fix seems to have worked from what I can see (it was what I was
thinking of fixing at least). The comma was Tom's initial guess.
I *have* found a bug/limitation of the texinfo exporter. If a link is
split between two lines the exporter doesn't handle it correctly. A
split link is exported like @ref{A-split-link}, when it should be @ref{A
split link}, I think.
If this is a limitation, please let me know so I can put all the links
on one line.
There's no such limitation. Could you provide an ECM for that?
I think Tom might be referring to when a line is hard wrapped with M-q. It
seems to affect the description of the org link to escape the spaces. I'm
not sure what effect this has on export. From what Tom is saying it isn't
unescaping the text.
Regards,
Jon
Regards,
--
Nicolas Goaziou
[O] New exporter macro question
Hi,
I am porting my websites to the new exporter, finally. Much is very smooth. I
do have a problem with macros:
* Macro definition
#+MACRO: thumbright #+ATTR_HTML: style=float:right;width:$1;margin:0px 20px
0px 20px; \n [[./Content/$2/thumb.jpg]]
* Macro call
{{{thumbright(300px,Wiskunde)}}}
* This used to expand to
img src=./Content/Wiskunde/thumb.jpg
style=float:right;width:300px;margin:0px 20px 0px 20px;
alt=./Content/Wiskunde/thumb.jpg /
* But now it expands to nothing
I am sure I am missing something basic. Thanks!
- Carsten
[O] Exporter question
Hi, In a file with some time stamps in headlines, is it still possible to get rid of them only for the Table of Contents, but to leave them in the headlines themselves? Thanks - Carsten
Re: [O] New exporter macro question
On 11 feb. 2013, at 13:48, Carsten Dominik carsten.domi...@gmail.com wrote:
Hi,
I am porting my websites to the new exporter, finally. Much is very smooth.
I do have a problem with macros:
* Macro definition
#+MACRO: thumbright #+ATTR_HTML: style=float:right;width:$1;margin:0px
20px 0px 20px; \n [[./Content/$2/thumb.jpg]]
* Macro call
{{{thumbright(300px,Wiskunde)}}}
* This used to expand to
img src=./Content/Wiskunde/thumb.jpg
style=float:right;width:300px;margin:0px 20px 0px 20px;
alt=./Content/Wiskunde/thumb.jpg /
* But now it expands to nothing
I am sure I am missing something basic. Thanks!
OK, I see, this seems to be because the \n is no longer interpreted as a
newline character upon macro expansion, so the entire text ends up in the
ATTR_HTML line and is treated as a comment.
Is there a way to get what I meant?
Thanks
- Carsten
Re: [O] OT, but not really: todays XKCD
Hi Jambunathan, thanks for pointing out again that the new exporter is 99% Nicolas achievement. It's so obvious to me that I may be fooled in thinking that it's obvious to everyone. As for the donations, I also wish Nicolas can receive donations. If Nicolas makes this move, I'd be happy to have more donate buttons on the website to allow targeted donations. For the ones I received, I don't think I'm actually pretending to do more than what I do. Your choice of not asking for donation is yours, I respect that. I'm not a very talented programmer, I just happen to know enough of Emacs Lisp to help with a project like Org. I do this mainly for the thrill of learning new things and the pleasure of meeting nice and smart people online. There is one thing that I hope I'm good at: being polite and patient with people. Trying to help, even when I'm not the best one around here to give an answer. I don't know if you are a maintainer for a project of a comparable size than Org, but if you do, you know that being nice and willing to help is a big part of the job. It's important for two reasons: to keep a nice atmosphere on the list, so that people feel comfortable asking stupid questions; and to let other developers focus on their work (while you try to help newbies with their problems). It would have been difficult for you to focus on the ODT exporter or to Nicolas to focus on the new export engine if I didn't put enough energy to maintain the whole beast. At least I believe so. But I get the core of your message and I fully agree: kudos go to Nicolas for his work! I just hope I helped him somehow. Best, PS: I think I said it already but I'm not a benevolent dictator for life -- the ones I think would be good maintainers declined the offer so far. Just be patient :) -- Bastien
Re: [O] New exporter macro question
Carsten Dominik carsten.domi...@gmail.com wrote:
On 11 feb. 2013, at 13:48, Carsten Dominik carsten.domi...@gmail.com wrote:
Hi,
I am porting my websites to the new exporter, finally. Much is very
smooth. I do have a problem with macros:
* Macro definition
#+MACRO: thumbright #+ATTR_HTML: style=float:right;width:$1;margin:0px
20px 0px 20px; \n [[./Content/$2/thumb.jpg]]
* Macro call
{{{thumbright(300px,Wiskunde)}}}
* This used to expand to
img src=./Content/Wiskunde/thumb.jpg
style=float:right;width:300px;margin:0px 20px 0px 20px;
alt=./Content/Wiskunde/thumb.jpg /
* But now it expands to nothing
I am sure I am missing something basic. Thanks!
OK, I see, this seems to be because the \n is no longer interpreted as a
newline character upon macro expansion, so the entire text ends up in the
ATTR_HTML line and is treated as a comment.
Is there a way to get what I meant?
It seems to be coming from deep with emacs: if I create a buffer
with
x y z \ x y z
and evaluate (with point somewhere on that line)
(buffer-substring-no-properties (point-at-bol) (point-at-eol))
I get x y z \\ x y z, so the backslash is escaped willy-nilly.
This happens in org-element-keyword-parser. I don't know if the
macro expansion would replace \n with a newline absent the extra
backslash, but I'm sure that its presence does not help any.
Nick
Re: [O] Feature: Group and limit items in agenda
Hi Muchenxuan, Muchenxuan Tong demon...@gmail.com writes: My intention is to limit the number of tasks in each category. Did you check (info (org)Block Agenda) ? That's the way I would suggest: define a block agenda listing the various categories, then use `org-agenda-max-todos' in each of them to limit the number of TODOs. For the new proposed 'org-agenda-max-todos', I can only limit the number of TODOs in the whole TODO lists. Maybe for what I want, it's desirable to add a auto-split or auto-group features, where a list of TODOs, can be split further into multiple lists of TODOs, by a certain criteria (tags, category). What do you think about it? I understand defining block agendas is not as straightforward than the solution you envision, but my feeling is that allowing grouping+limits will have too much overlap with the block agenda functionality. Let me know if you find the path to happiness with a combinaison of block agendas and the new variables. Thanks, -- Bastien
Re: [O] Calling 'org-babel-mark-block' with 'M-x cmd' and 'M-: (cmd)'
Hi Thorsten, Thorsten Jolitz tjol...@googlemail.com writes: Interesting, I have to check what happens when I use this function in a program. Kind of strange, though, is that a bug in 'org-babel-mark-block' - or in Emacs itself? I think it may have been a temporary bug in Emacs. Can you reproduce it with a recent Emacs? Also, M-h is bound to `org-mark-element', which will mark a block (the whole block, not just its content). You might find it useful too! Best, -- Bastien
Re: [O] Bug in org-src.el?
Hi Thorsten, Thorsten Jolitz tjol...@googlemail.com writes: when I export a (bit complicated) PicoLisp source block with ':results html', I get an error: , | error: Invalid search bound (wrong side of point) ` Yes, I've seen this error too sometimes and it was not easy to fix when I tried to. Can you share the minimal code block to reproduce? Thanks, -- Bastien
Re: [O] Scheduling makes link disappear
Hi Thomas, Thomas Morgan t...@ziiuu.com writes: Thanks! That fixes it and doesn't break any of the agenda views that I use. Thanks for confirming, I've applied the patch now. All best, -- Bastien
Re: [O] freeplane exporter too?
scraw...@gmail.com writes: would the new freemind exporter be able to handle files created with freeplane, or would there have to be a freeplane exporter too? Freeplane files and Freemind files are similar, but not the same. Just something to consider... Here is a wiki page describing the freeplan format, if anyone needs to implement this new export backend: http://freeplane.sourceforge.net/wiki/index.php/Current_Freeplane_File_Format -- Bastien
[O] bug#13668: 24.2.93; strike-through in org mode
Roland Winkler wink...@gnu.org writes: On Sun Feb 10 2013 Bastien wrote: Please provide a patch. I'd much appreciate if the org developers could do that. I have enough such things on my own emacs agenda, Done in Org's git repository, thanks. -- Bastien
Re: [O] org-fill-paragraph breaks timestamps
Hi William, William william.leche...@ens-lyon.org writes: In plain lists, I sometimes insert timestamps in running text (for an item to appear in the agenda), then fill it with org-fill-paragraph. Sometimes, the timestamp is splitted (at any of both spaces), breaking the desired agenda behavior. Fixed. Is there something I can do for this not to happen ? Update (either the maint or the master branch) :-) Thanks! -- Bastien
Re: [O] [PATCH] Fix a number of potential infinite loops due to unsgined underflow.
Hi Tom, Tom Prince tom.pri...@ualberta.net writes: I discovered this, when trying to merge a file, with a tag that overhangs the right margin. Trying to merge the following line with itself (with --rmargin less than 10) the causes the driver to output spaces forever: Good to know people are using Andrew's work! Andrew, are you still maintainer this git merge driver? Thanks, -- Bastien
Re: [O] Problem with org-html-format-latex
Vincent Beffara vbeffara...@gmail.com writes: so simply testing on the value of processing-type would work better, maybe? Yes, should be okay now, let me know! -- Bastien
Re: [O] suggestion: M-m should move point to first word on line
Hi Meng Weng, Meng Weng Wong mengw...@gmail.com writes: Ordinarily, M-m is bound to (back-to-indentation) – move point to the first non-whitespace character on the line. It differs from C-a. Might it make sense for org-mode to override M-m? Not to override `M-m' but perhaps to define * as a syntactic whitespace character. Patch attached -- use with caution. I tested it a bit and it seems to work, but not all tests pass and there may be side-effects that I could not observe. In the meantime, I guess org-special-ctrl-a org-special-ctrl-a/e are useful enough, as already pointed. diff --git a/lisp/org.el b/lisp/org.el index 4555ed1..d6ae281 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5177,6 +5177,7 @@ The following commands are available: (org-set-tag-faces 'org-tag-faces org-tag-faces)) ;; Calc embedded (org-set-local 'calc-embedded-open-mode # ) + (modify-syntax-entry ?* ) (modify-syntax-entry ?@ w) (modify-syntax-entry ?\ \) (if org-startup-truncated (setq truncate-lines t)) -- Bastien
Re: [O] edit-src on read-only files
Hi Greg, Greg Minshall minsh...@umich.edu writes: hi. i use RCS on my .org files. it's happened to me more than once (1 == shame on me) that i've entered C-c ' on a read-only .org file, spent some time editing the source code fragment, then done C-c ', only to lose my edits, as the original buffer was read-only. it seems like org-mode should prevent that. Yes, this is now the case in master. Thanks! -- Bastien
Re: [O] orgstruct-mode with custom headline prefix
Christopher Schmidt christop...@ch.ristopher.com writes: Christopher Schmidt christop...@ch.ristopher.com writes: Here is the patch. Now one just needs ;; Local Variables: ;; eval: (orgstruct-mode 1) ;; orgstruct-heading-prefix-regexp: ;;; ;; End: This is in master now. The commit is a3f6570. Thanks a lot! -- Bastien
Re: [O] OT, but not really: todays XKCD
[RESENT to the list only now] Dear Jambunathan, I respect your contributions to Org/Emacs/FreeSoftware a lot. But I am disappointed to see that you discourage/attack current Org's maintainer directly. I think this won't help anyone in anyway. Thanks., -- ఎందరో మహానుభావులు అందరికి వందనములు. YYR
Re: [O] [Bug] Yasnippet/Org: properties messed up when expanding $1
Hi Karl, Karl Voit devn...@karl-voit.at writes: I do face strange behavior when using yasnippet with Org-mode: So there does not seem to be anybody who is able to fix this issue. Is there at least somebody who can confirm this weird bug? I've installed Yasnippet (from GNU ELPA) but I think I need more help on how to test it... expanding with TAB in text-mode and in yas-minor-mode doesn't produce anything useful. Can you make a recipe for yas-n00bs? Thanks! -- Bastien
Re: [O] latex code block evaluation -- Eric?
Hi Henry,
henry atting wrote:
Sebastien Vauban writes:
henry atting wrote:
I have this latex code block:
#+begin_src latex :file foo.pdf
\documentclass{article}
\begin{document}
...some text...
\end{document}
#+end_src
After evaluation the resulting file looks like this:
article ...some text...
I do not understand this. As far as I know it is possible to define the
latex documentclass within a code block.
Could you be more explicit? Do you want to use that to pass parameters to
the
LaTeX backend? If yes, why not using the #+LaTeX: directive (not sure
they're still supported with the exact same syntax as before -- I've not yet
merged my documents). And that brings us to the most important question: old
or new exporter?
Eventually, can you send a real ECM, or your real use case?
Ah, I see, I was unclear.
In this case I simply want to evalutate this code block with `C-c C-c'.
I do not use the orgmode LaTeX exporter, only the HTML exporter.
Finally I will create org files with LaTeX code blocks which I will export to
HTML. And that's all. HTML export works fine with the old or the new
exporter.
Though in this case it is not really indispensable I only was wondering why
code block evalution does not work as expected. Why is
`\documentclass{article}' not recognized properly?
To be sure to understand, what are you expecting when you're evaluating the
LaTeX code block? Its content to be automagically converted to a PDF file
thru the LaTeX chain?
AFAIK, this does not work. I'd like it to be the case, but Eric Schulte once
explained it was (too?) difficult. Dunno if it's still on his task list.
The workaround was to tangle to a TeX file, and from there to compile to a PDF
via AUCTeX. Yes, not sexy, I know.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] block quotes in prose?
Hi Peter, Peter Salazar cycleofs...@gmail.com writes: Now the question is: How do I make org-mode recognize the prefix as a demarcator of a code block, so that my document remains readable as Markdown? You can't -- using : as the prefix for fixed-width regions is hardcoded. If we allow to customize this, it will lower the exchangeability of .org files between users (this exchangeability is already quite low due to the many options user have.) Best, -- Bastien
Re: [O] block quotes in prose?
Hi Bastien and Peter, Bastien wrote: Peter Salazar cycleofs...@gmail.com writes: Now the question is: How do I make org-mode recognize the prefix as a demarcator of a code block, so that my document remains readable as Markdown? You can't -- using : as the prefix for fixed-width regions is hardcoded. If we allow to customize this, it will lower the exchangeability of .org files between users (this exchangeability is already quite low due to the many options user have.) That 'd have been excellent: copies of (replies to) emails wouldn't have needed to be protected anyhow. But, yes, I can understand it's too late... Best regards, Seb -- Sebastien Vauban
Re: [O] latex code block evaluation
henry atting s...@online.de writes:
I have this latex code block:
#+begin_src latex :file foo.pdf
\documentclass{article}
\begin{document}
...some text...
\end{document}
#+end_src
After evaluation the resulting file looks like this:
article ...some text...
I do not understand this. As far as I know it is possible to define the
latex documentclass within a code block.
Currently the machinery used to generate images of inline latex
equations is used to evaluate latex code blocks. So e.g., the following
works as expected.
#+begin_src latex :file write-fisher.pdf :results raw
\begin{equation*}
P_{i} = \frac{(2N)!}{i! (2N-i)!} p^{i}q^{2N-i}
\end{equation*}
#+end_src
#+RESULTS:
[[file:write-fisher.pdf]]
In this case it is all a matter of balancing what the majority of users
think is expected. If specifying a particular document class is
important, than I am sure that it shouldn't be hard to update the
org-babel-execute:latex function to check for the presence of
\begin{document} and handle those cases differently (in a similar way to
how org-babel-execute:C checks for a main function).
If specifying the document class is not required your example could be
converted to the (arguably preferable) example below.
#+begin_src latex :file foo.pdf :results raw
...some text...
#+end_src
#+RESULTS:
[[file:foo.pdf]]
Cheers,
--
Eric Schulte
http://cs.unm.edu/~eschulte
[O] A short introduction to YASnippet (was: [Bug] Yasnippet/Org: properties messed up when expanding $1)
* Bastien b...@altern.org wrote:
Hi Karl,
Hi!
I've installed Yasnippet (from GNU ELPA) but I think I need more
help on how to test it... expanding with TAB in text-mode and in
yas-minor-mode doesn't produce anything useful.
Does it produce something at all?
Can you make a recipe for yas-n00bs?
Sure.
If yasnippet is installed and loaded, you should get an additional
menu entry called «YASnippet». You find out, where your snippet
folder is located. Mine is «~/.emacs.d/snippets». yasnippet is
pretty straight forward: every text file within the snippet folder
is a defined snippet. If not stated otherwise in the header of the
file, the name of the snippet file is the command which is used to
expand.
You can define snippets that are only available in certain modes:
snippets within «$SNIPPETDIR/text-mode/org-mode» are only available
in Org-mode. Following snippet is only available in Org-mode and is
expanded by entering «test» followed by TAB:
,[ Snippet «~/.emacs.d/snippets/text-mode/org-mode/test» ]
| # name : Testing yasnippet/org issue
| # --
|
| ** Test ${1:test}
| :PROPERTIES:
| :ID: $1
| :END:
`
AFAIR the header is optional. Within the header, you can define
additional description, alternative name, author, and so forth.
If you add new snippets, you can choose «YASnippet/Reload
everything» from the Emacs menu. I guess this is «yas/reload-all».
Within a snippet, the first «$1» results in putting the cursor at
this point and «asking» the user to enter a string. You can define a
default string with «${1:test}» where «test» is the default string
for «$1».
All other occurrences of «$1» will be replaced by the very same user
string which is quite handy: you have to enter it only once and it
gets replaced multiple times.
The snippet above with «$1» as «foo bar» should result in:
,[ expanded snippet «test» with «foo bar» ]
| ** Test foo bar
| :PROPERTIES:
| :ID: foo bar
| :END:
`
For further documentation, please refer to [1].
At my side, any «$x» within the PROPERTIES drawer messes up the
line.
YASnippets are very easy to set up, very handy to use. IMHO,
everybody should use something like yasnippet in his/her daily
workflow.
1. http://capitaomorte.github.com/yasnippet/#how-to-use-yasnippet
--
Karl Voit
Re: [O] New exporter macro question
Nick Dokos nicholas.do...@hp.com wrote: Carsten Dominik carsten.domi...@gmail.com wrote: OK, I see, this seems to be because the \n is no longer interpreted as a newline character upon macro expansion, so the entire text ends up in the ATTR_HTML line and is treated as a comment. It seems to be coming from deep with emacs: if I create a buffer with x y z \ x y z and evaluate (with point somewhere on that line) (buffer-substring-no-properties (point-at-bol) (point-at-eol)) I get x y z \\ x y z, so the backslash is escaped willy-nilly. This happens in org-element-keyword-parser. I don't know if the macro expansion would replace \n with a newline absent the extra backslash, but I'm sure that its presence does not help any. Even if I delete the extra backslash from the value of the macro in org-macro-initialize-templates, the regexp fails to properly match: , | ;; Install buffer-local macros. | (org-with-wide-buffer | (goto-char (point-min)) | (while (re-search-forward ^[ \t]*#\\+MACRO: nil t) |(let ((element (org-element-at-point))) |(when (eq (org-element-type element) 'keyword) | (let ((value (org-element-property :value element))) |(when (string-match ^\\(.*?\\)\\(?:\\s-+\\(.*\\)\\)?\\s-*$ value) | (funcall set-template | (cons (match-string 1 value) | (or (match-string 2 value) ) ` OTOH, if I modify the cell argument inside set-template[fn:1] to get rid of the extra backslash, the macro expansion happened as expected. Nick Footnotes: [fn:1] This is obviously a gross hack, only meant as a debugging aid. In fact, I didn't even code it up: I just stepped through the thing with edebug and slammed the modified value into the cell argument.
Re: [O] Bug in org-insert-heading-after-current?
Hi Thorsten, Thorsten Jolitz tjol...@googlemail.com writes: having added a property drawer with two entries: ,- | * Definitions | :PROPERTIES: | :exports: both | :results: replace | :END: `- I evaluate: ,--- | (outline-previous-heading) | (org-insert-heading-after-current) `--- and get: , | * Definitions | :PROPERTIES: | :exports: both | :results: replace | * | [2013-01-28 Mo 17:48] | :END: ` while the new heading should be below the :END: I cannot reproduce this with the current HEAD of the git repository and a bare emacs -Q. Is there other info I need to reproduce this? Thanks! -- Bastien
[O] make test failure
Just pulled and ran make test. I get one failure with the appended backtrace: Nick Test test-org/backward-element backtrace: (if (unwind-protect (setq value-4576 (apply fn-4574 args-4575)) (set (let (form-description-4578) (if (unwind-protect (setq value-4576 (a (let ((value-4576 (quote ert-form-evaluation-aborted-4577))) (let (f (let ((fn-4574 (function looking-at)) (args-4575 (list (regexp-quote (progn (org-mode) (progn (insert \n* Head 1\n** Head 1.1\n*** Head (unwind-protect (progn (org-mode) (progn (insert \n* Head 1\n** Hea (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn (let ((temp-buffer (generate-new-buffer *temp*))) (save-current-b (lambda nil (let ((temp-buffer (generate-new-buffer *temp*))) (sa #[0 \306\307!r\211q\210\310\311\312\313\314\315!\316\\317\320%DC funcall(#[0 \306\307!r\211q\210\310\311\312\313\314\315!\316\\31 ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc #[0 r\304\305!q\210\306 d\307\223)\310\311\312\313\314\315!\316\ funcall(#[0 r\304\305!q\210\306 d\307\223)\310\311\312\313\314\315 ert-run-test([cl-struct-ert-test test-org/backward-element Test `or ert-run-or-rerun-test([cl-struct-ert--stats \\(org\\|ob\\) [[cl-st ert-run-tests(\\(org\\|ob\\) #[385 \306\307\\203D
Re: [O] Bug: org-insert-heading-respect-content inserts at the wrong level if target heading is invisible [7.9.2 (release_7.9.2-883-g6fb36e.dirty @ /home/dlm/share/org-mode.git/lisp/)]
Hi James, James Harkins jamshar...@gmail.com writes: I'm resending the issue that I reported the other day, now with a MCE. Sorry for the delay on this -- and thanks for the detailed reports. I tried not to get lost in the details actually... so I ended up using the attached fix. It works here, i.e. C-u C-RET inserts a new heading at the right place, but I'm not using org-mobile.el so I'm not 100% sure if it works for you. Can you test and confirm? Thanks! From 808779ada5a35b69aca12e35723b22725aebf0f3 Mon Sep 17 00:00:00 2001 From: Bastien Guerry b...@altern.org Date: Mon, 11 Feb 2013 18:27:21 +0100 Subject: [PATCH] Fix `org-insert-heading-respect-content' * org-mobile.el (org-mobile-edit): DTRT when insert a heading in an invisible region. * org.el (org-insert-heading-respect-content): New `invisible-ok' parameter. Add docstring. (org-insert-todo-heading-respect-content): Add docstring. Thanks to James Harkins for the extra detailed reports and the proposed solutions, both for org.el and org-mobile.el. --- lisp/org-mobile.el | 2 +- lisp/org.el| 8 +--- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/lisp/org-mobile.el b/lisp/org-mobile.el index a410de0..293d2a0 100644 --- a/lisp/org-mobile.el +++ b/lisp/org-mobile.el @@ -1064,7 +1064,7 @@ be returned that indicates what went wrong. (if (org-on-heading-p) ; if false we are in top-level of file (progn (end-of-line 1) - (org-insert-heading-respect-content) + (org-insert-heading-respect-content t) (org-demote)) (beginning-of-line) (insert * )) diff --git a/lisp/org.el b/lisp/org.el index 623c374..10168a5 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7231,12 +7231,14 @@ This is a list with the following elements: (org-move-subtree-down) (end-of-line 1)) -(defun org-insert-heading-respect-content () - (interactive) +(defun org-insert-heading-respect-content (invisible-ok) + Insert heading with `org-insert-heading-respect-content' set to t. + (interactive P) (let ((org-insert-heading-respect-content t)) -(org-insert-heading t))) +(org-insert-heading t invisible-ok))) (defun org-insert-todo-heading-respect-content (optional force-state) + Insert TODO heading with `org-insert-heading-respect-content' set to t. (interactive P) (let ((org-insert-heading-respect-content t)) (org-insert-todo-heading force-state t))) -- 1.8.1.2 -- Bastien
Re: [O] org-bullets extension
E Sabof esa...@gmail.com writes: What is the current status of the package? Was it accepted? Was it superseded? org-bullets.el is in the contrib/ directory. If it wasn't superseded, I might spend some time re-implementing it. I think it would be nice to adapt Jambunathan's solution for Org's core: something like a `org-replace-leading-stars' that, when non-nil, would be used as the char/string for compose-region. Then users could turn this on/off using #+STARTUP. What do you think? -- Bastien
Re: [O] make test failure
Hi Nick, Nick Dokos nicholas.do...@hp.com writes: Just pulled and ran make test. I get one failure with the appended backtrace: I submitted this patch to Nicolas so that he can approve/apply it. I think the test is wrong, not the code. diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index dac5fd2..561ac98 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -677,10 +677,7 @@ Outside. ;; headline at the same level. (goto-line 3) (org-backward-element) -(should (looking-at (regexp-quote * Head 1))) -;; 4.3. At the first top-level headline: should error. -(goto-line 2) -(should-error (org-backward-element))) +(should (looking-at (regexp-quote ** Head 1.1 ;; 5. At beginning of first element inside a greater element: ;;expected to move to greater element's beginning. (org-test-with-temp-text Before.\n#+BEGIN_CENTER\nInside.\n#+END_CENTER -- Bastien
Re: [O] navigating between non-code blocks?
Hi Sébastien and François, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Indeed... Fixed. And, don't know why, but the speed key `F' is not working for me, on a freshly pulled Org: Also fixed, thanks. -- Bastien
Re: [O] [PATCH] Protect org-agenda-prepare-buffers with org-unmodified
Hi Francesco, Francesco Pizzolante fpz-djc/ipccudyqhejpep6iedvlejwur...@public.gmane.org writes: This patch protects changes done in org-agenda-prepare-buffers with org-unmodified instead of saving/restoring buffer-modified-p. This avoids modification hooks to run. Applied, thanks! -- Bastien
[O] Invalid read syntax (#) in org-element parse tree
Hi List, here is an excerpt of a parse tree produced with 'org-element-parse-buffer': ,- | (section (:begin 1 :end 624 :contents-begin | 1 :contents-end 623 :post-blank 1 :parent #0) (keyword (:key | TITLE :value Program Blues for Icke :begin 1 :end | 39 :post-blank 0 :post-affiliated 1 :parent #1))) `- When I evaluate a function with this list as data, I get an error: , | Debugger entered--Lisp error: (invalid-read-syntax #) | read(#buffer *scratch*) | preceding-sexp() | eval-last-sexp-1(t) | eval-last-sexp(t) | eval-print-last-sexp() | call-interactively(eval-print-last-sexp nil nil) ` from the doc in 'org-element.el' I learn that: , | ;; Notwithstanding affiliated keywords, each greater element, element | ;; and object has a fixed set of properties attached to it. [...] | | ;; `:parent' which refers to the element or object containing it. [...] | | ;; Lisp-wise, an element or an object can be represented as a list. | ;; It follows the pattern (TYPE PROPERTIES CONTENTS), where: | ;; TYPE is a symbol describing the Org element or object. | ;; PROPERTIES is the property list attached to it. See docstring of | ;; appropriate parsing function to get an exhaustive | ;; list. | ;; CONTENTS is a list of elements, objects or raw strings contained | ;;in the current element or object, when applicable. | ;; | ;; An Org buffer is a nested list of such elements and objects, whose | ;; type is `org-data' and properties is nil. ` There are a lot of usages of '#' in Emacs Lisp, but I couldn't figure out how (and why) it is used in ':parent #1'. Nic Ferrier wrote an exhaustive library with routines for working with key/value data structures like hash-tables and alists and plists (https://github.com/nicferrier/emacs-kv/blob/master/kv.el), but I cannot apply any of the functions due to the read error. Do I really have to treat the parse tree as text first and eliminate the '#' before I can use it as list in Emacs Lisp, or did I simply manage to get the wrong represantation of the parse tree somehow? Thanks for any advice. -- cheers, Thorsten
Re: [O] Fwd: Re: Bug? in texinfo exporter
Aloha Nicolas and Jon,
Nicolas Goaziou n.goaz...@gmail.com writes:
t...@tsdye.com (Thomas S. Dye) writes:
Aloha Jon,
[...]
Yes, I believe you are right. The commas are not the culprits.
Apologies for the red herring.
Perhaps Nicolas should revert the commit? Could you check if this is
the right thing to do?
My fix isn't about the comma. Didn't it work?
The particular link I used in the example now works. Thanks. I wasn't
sure what was done and worried that my red herring had made it into the
code. Glad to know that it didn't.
I *have* found a bug/limitation of the texinfo exporter. If a link is
split between two lines the exporter doesn't handle it correctly. A
split link is exported like @ref{A-split-link}, when it should be @ref{A
split link}, I think.
There's no such limitation. Could you provide an ECM for that?
Yes, here is an ECM.
- Begin ECM --
* A long headline that typically breaks across lines with M-q
Blah.
* Concise headline
The problem comes with links that are split across lines, e.g. [[A
long headline that typically breaks across lines with M-q]]. They work
in the Org mode buffer, but not when exported to texinfo.
* Editing setup
#+name: setup-editing
#+header: :results silent
#+header: :eval no-export
#+begin_src emacs-lisp
(require 'ox-texinfo)
(define-key org-mode-map (kbd C-c e) 'org-export-dispatch)
(setq org-pretty-entities nil)
(setq org-src-preserve-indentation t)
(setq org-confirm-babel-evaluate nil)
(org-babel-do-load-languages
'org-babel-load-languages
'((emacs-lisp . t)
(sh . t)))
(add-to-list 'org-export-snippet-translation-alist
'(info . e-texinfo))
#+end_src
-- End ECM ---
Here is the makeinfo output:
poto:orgmanual dk$ makeinfo --force org-texi-link.texi
/Users/dk/org/orgmanual//org-texi-link.texi:55: Cross reference to nonexistent
node `A-long-headline-that-typically-breaks-across-lines-with-M-q' (perhaps
incorrect sectioning?).
Note the hyphens between the words of the headline/link.
All the best,
Tom
--
T.S. Dye Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
Re: [O] org-element-paragraph-parser fails
Hello, Charles Berry ccbe...@ucsd.edu writes: Remove the spaces before #+name OR take out the '- item' and org-export-dispatch succeeds. As is, it fails with org-element-paragraph-parser: Invalid search bound (wrong side of point) , | * export dispatcher | | - item | | #+name: xyz | #+BEGIN_SRC emacs-lisp | (pwd) | #+END_SRC ` This should be fixed. Thank you for reporting this. Note that it won't give you the result you're probably expecting. The NAME keyword belongs to the list whereas the src-block doesn't. The are unrelated. So the affiliated keyword will be parsed as a regular keyword and the block will have no name. Regards, -- Nicolas Goaziou
Re: [O] compilation issues of new export framework
Achim Gratz strom...@nexgo.de writes: Nicolas Goaziou n.goaziou at gmail.com writes: On the other hand, `org-element-type' and al. from org.el are called less often. So, it is not a problem if they are compiled as function calls. They are normally not compiled as function calls, only in single mode. Regarding commit 6b7101b91, did you intend to demote org-element-nested-p to a defun or was this just a leftover from the earlier experiment? I found that inlining it was an overkill. So the change is intentional. Regards, -- Nicolas Goaziou
Re: [O] compilation issues of new export framework
Nicolas Goaziou writes: I found that inlining it was an overkill. So the change is intentional. Thanks for the confirmation. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] OT, but not really: todays XKCD
Yagnesh Raghava Yakkala h...@yagnesh.org writes: But I am disappointed to see that you discourage/attack current Org's maintainer directly. I think this won't help anyone in anyway. If I say Yagnesh has made zero contributions to Tamil Poetry does it amount to attacking you. Think about it. --
Re: [O] ocaml babel no longer works?
Hello, Eric Schulte writes: Thanks for looking into this. I've applied a patch to ob-ocaml.el which should handle the two different tuareg execution functions. Thanks a lot. About the thing getting stuck, I made some progress. My error was that I did not add ;; at the end of my ocaml phrase, which resulted in an error in the toplevel: #+begin_quote Objective Caml version 3.12.1 # let x = 2 in x org-babel-ocaml-eoe;; Characters 13-14: let x = 2 in x ^ Error: This expression is not a function; it cannot be applied #+end_quote As you see, it's trying to apply the 'x' to the oeo thing. My guess is that babel waits until seeing this special string before sending the result back. By the way, this allows for some fun things, like this: #+BEGIN_SRC ocaml let f x = () in f #+END_SRC make babel stuck because the interpreter is in this state: #+begin_quote # let f x = () in f org-babel-ocaml-eoe;; - : unit = () #+end_quote So I have a suggestion and two feature requests. The suggestion: instead of appending 'org-babel-ocaml-eoe;;' to the code, how simply put ';;' (which will make sure everything is flushed) then detect the toplevel is done by seeing the string '# ' at the beginning of the line? Would there be an issue with the fact that this line does not have a newline? If so, an alternative suggestion would be to use the longer ';; org-babel-ocaml-eoe;;' which makes sure the phrase in the input won't interact with the marker. The first feature requests: if there is an error, could it be parsed? (It probably always start with 'Error: '). Then the error could be put in the result block, instead of waiting for the marker that will never appear. The second feature request: I want to use this for my ocaml lab classes (I'm thinking of giving them an org file they have to complete by writing the caml code). Could it be possible to have an option for the full output of the compiler (and not just the result) to be printed? I see it does it when it does not recognize the type of the output. So I guess such an option would be applied to either org-babel-ocaml-parse-output or the place where it's called. Thanks a lot for any suggestion as how to implement this. I think I see how to do the second one (except I don't know how to add a configuration variable to toggle it). I have no idea about the first one, though. Alan
Re: [O] new exporter fails to output footnotes?
Samuel Wales samolog...@gmail.com writes: Surely this is pilot error someplace. (org-export-to-buffer 'html (get-buffer-create test) t nil t) *** test asasdf[fn::test] *** output p asasdfsupa id=fnr.1 name=fnr.1 class=footref href=#fn.11/a/sup/p It should be fixed in master. Could you confirm it? Thank you for reporting the bug. Regards, -- Nicolas Goaziou
Re: [O] New exporter macro question
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
I am porting my websites to the new exporter, finally. Much is very smooth.
I do have a problem with macros:
* Macro definition
#+MACRO: thumbright #+ATTR_HTML: style=float:right;width:$1;margin:0px
20px 0px 20px; \n [[./Content/$2/thumb.jpg]]
* Macro call
{{{thumbright(300px,Wiskunde)}}}
* This used to expand to
img src=./Content/Wiskunde/thumb.jpg
style=float:right;width:300px;margin:0px 20px 0px 20px;
alt=./Content/Wiskunde/thumb.jpg /
* But now it expands to nothing
I am sure I am missing something basic. Thanks!
Macros have been downgraded a bit, as there was some overlapping with
Babel functionalities. In particular, they are meant to replace objects,
not elements, which means they cannot contain newline characters
anymore.
You can use a Babel block to generate the Org code you want. You can
also try the following macro, which will generate the HTML code you
want:
#+MACRO: thumbright @@html:img src=./Content/$2/thumb.jpg
style=float:right;width:$1;margin:0px 20px 0px 20px;
alt=./Content/$2/thumb.jpg /@@
Regards,
--
Nicolas Goaziou
Re: [O] Problem with org-html-format-latex
so simply testing on the value of processing-type would work better, maybe? Yes, should be okay now, let me know! Nope, exactly the same. cache-relpath and cache-dir are not allowed to be nil. Meaning that if processing-type is 'mathjax they should be set to _some_ string anyway (the contents will be ignored eventually, but far down the line unfortunately ...) Something like instead of your 'let' line works: (let ((cache-relpath ) (cache-dir ) bfn) /v
[O] Installation problem? (new exporter)
Hi, gang. I've difficulty to get the new exporter into movement. After trying for some time, I'm giving into this mailing list for help or advice. First, C-c C-e yields Cannot open load file: org-export. I guess that some old autoload is hiding somewhere, but I just do not find it. Command C-h k C-c C-e tersely says: org-export-dispatch is an interactive autoloaded Lisp function. [Arg list not available until function definition is loaded.] Not documented. Debugging on error is terse as well: Debugger entered--Lisp error: (file-error Cannot open load file org-export) On this Ubuntu 12.10, I moved /usr/share/emacs/23.4/lisp/org/ and /share/emacs23/site-lisp/org-mode/ elsewhere, just in case. I had no problems before using a recent Org, letting these older directories there, but this does not mean there were no problem, of course. To install Org, I merely git clone or git pull it, and then use make. In the Make output, I see that autoloads are regenerated. Second, the following Makefile entry (reduced) does not work anymore for me: all: emacs -Q --batch --load publish.el --funcall org-publish-all Here is file publish.el (reduced): (defvar api-org-distribution ~/emacs/_/org-mode) (add-to-list 'load-path (concat api-org-distribution /lisp)) (require 'org) (message (org-version)) (setq org-publish-project-alist `((api :base-directory ~/control3/api/ :publishing-directory ~/control3/api-html ))) The ~/control3/api/ directory is already populated with many Org files by another program. Running make yields: 7.9.3e No publishing function chosen and no output is produced. Sigh! :-) François
Re: [O] Invalid read syntax (#) in org-element parse tree
Hello, Thorsten Jolitz tjol...@gmail.com writes: here is an excerpt of a parse tree produced with 'org-element-parse-buffer': ,- | (section (:begin 1 :end 624 :contents-begin | 1 :contents-end 623 :post-blank 1 :parent #0) (keyword (:key | TITLE :value Program Blues for Icke :begin 1 :end | 39 :post-blank 0 :post-affiliated 1 :parent #1))) `- When I evaluate a function with this list as data, I get an error: , | Debugger entered--Lisp error: (invalid-read-syntax #) | read(#buffer *scratch*) | preceding-sexp() | eval-last-sexp-1(t) | eval-last-sexp(t) | eval-print-last-sexp() | call-interactively(eval-print-last-sexp nil nil) ` [...] There are a lot of usages of '#' in Emacs Lisp, but I couldn't figure out how (and why) it is used in ':parent #1'. See (info (elisp) Read Syntax for Circular Objects) Nic Ferrier wrote an exhaustive library with routines for working with key/value data structures like hash-tables and alists and plists (https://github.com/nicferrier/emacs-kv/blob/master/kv.el), but I cannot apply any of the functions due to the read error. Do I really have to treat the parse tree as text first and eliminate the '#' before I can use it as list in Emacs Lisp, or did I simply manage to get the wrong represantation of the parse tree somehow? I'm not sure about what you want to do with the parse tree. The usual function to work with it is `org-element-map'. You may want to have a look at its docstring, as it contains examples. Regards, -- Nicolas Goaziou
Re: [O] How to pass a block of text to a code block as data?
Sean, that helps too, thank you. Now that you and Sebastien have gone to
all this trouble I found the part of the manual that sort of describes
this, but I clearly didn't understand it before. Possible needs a more
worked-out example for the slow among us, like self.
I've noticed one curious thing in trying a perl example. See first:
-8--
#+name: wake
#+BEGIN_EXAMPLE
riverrun, past Eve and Adam's, from swerve of shore to bend
of bay, brings us by a commodius vicus of recirculation back to
Howth Castle and Environs.
Sir Tristram, violer d'amores, fr'over the short sea, had passen-
core rearrived from North Armorica on this side the scraggy
isthmus of Europe Minor to wielderfight his penisolate war: nor
had topsawyer's rocks by the stream Oconee exaggerated themselse
to Laurens County's gorgios while they went doublin their mumper
all the time: nor avoice from afire bellowsed mishe mishe to
#+END_EXAMPLE
#+begin_src perl :var inlines=wake :results output
foreach $aln (split(/$/,$inlines)) {
print $aln;
}
#+end_src
#+results:
: riverrun, past Eve and Adam's, from swerve of shore to bend
: of bay, brings us by a commodius vicus of recirculation back to
: Howth Castle and Environs.
: Sir Tristram, violer d'amores, fr'over the short sea, had passen-
: core rearrived from North Armorica on this side the scraggy
: isthmus of Europe Minor to wielderfight his penisolate war: nor
: had topsawyer's rocks by the stream Oconee exaggerated themselse
: to Laurens County's gorgios while they went doublin their mumper
: all the time: nor avoice from afire bellowsed mishe mishe to
-8--
and then a more complicated block that's closer to my real task:
-8--
#+NAME: job2
#+BEGIN_EXAMPLE
!START
!ID:7655
!DATE:02/10/2013
!CLOSE:03/15/2013
!UNTILFILLED:
!POSITION:Science Editor
!COMPANY:East Newark Times Herald News and World Defender
!BEGIN-DESCRIPTION
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy
nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut
wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit
lobortis nisl ut aliquip ex ea commodo consequat.
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse
molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero
eros et accumsan et iusto odio dignissim qui blandit praesent luptatum
zzril delenit augue duis dolore te feugait nulla facilisi.
!END-DESCRIPTION
!BEGIN-SPECIAL
Duis eget lorem ac odio lobortis suscipit nec et neque. Sed at quam ut
mauris scelerisque congue id eget dui. Quisque tellus lectus, tristique eu
posuere in, faucibus vitae urna. Duis vitae orci purus, quis euismod augue.
!END-SPECIAL
!SALARY:16.67 per hour
!BEGIN-CONTACT
Please submit online at http://enthnawd.org/jobs
!END-CONTACT
!END
#+END_EXAMPLE
#+begin_src perl :var inlines=job2 :results output
foreach $aln (split(/$/,$inlines)) {
print $aln;
}
#+end_src
#+results:
#+begin_example
!START
!ID:7655
!DATE:02/10/2013
!CLOSE:03/15/2013
!UNTILFILLED:
!POSITION:Science Editor
!COMPANY:East Newark Times Herald News and World Defender
!BEGIN-DESCRIPTION
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy
nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut
wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit
lobortis nisl ut aliquip ex ea commodo consequat.
Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse
molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero
eros et accumsan et iusto odio dignissim qui blandit praesent luptatum
zzril delenit augue duis dolore te feugait nulla facilisi.
!END-DESCRIPTION
!BEGIN-SPECIAL
Duis eget lorem ac odio lobortis suscipit nec et neque. Sed at quam ut
mauris scelerisque congue id eget dui. Quisque tellus lectus, tristique eu
posuere in, faucibus vitae urna. Duis vitae orci purus, quis euismod augue.
!END-SPECIAL
!SALARY:16.67 per hour
!BEGIN-CONTACT
Please submit online at http://enthnawd.org/jobs
!END-CONTACT
!END
#+end_example
-8--
NOTICE THAT while both return the result as Example text, the first simple
prepends each line with a colon, simple Example form, and the second wraps
the result in an Example block without altering the lines.
Not sure why? Is this just a function of the number of lines of the text?
Michael
--
Michael Baum maab...@gmail.com
You should never have your best trousers on when you go out
to fight for freedom and truth. - Ibsen
Re: [O] How to pass a block of text to a code block as data?
Michael Baum maab...@gmail.com writes: Sean, that helps too, thank you. Now that you and Sebastien have gone to all this trouble I found the part of the manual that sort of describes this, but I clearly didn't understand it before. Possible needs a more worked-out example for the slow among us, like self. Patches are welcome, especially documentation patches. [...] NOTICE THAT while both return the result as Example text, the first simple prepends each line with a colon, simple Example form, and the second wraps the result in an Example block without altering the lines. Not sure why? Is this just a function of the number of lines of the text? Yes, this is a function of the number of lines in the output text. You can control where this switch is made by changing the value of org-babel-min-lines-for-block-output. Best, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] LaTeX export: Theorem with an author
Hi, #+begin_theorem :options [Him] slkdfj #+end_theorem This isn't future-proof. If, for example, we need to add options for the HTML back-end, there will be a syntax conflict. The rule is the following: - If the toggle are global, allow them on the block opening string (i.e. src-block and code toggles) - For back-end specific value, use attributes. Fair enough. Although as Andreas said, something backend-agnostic to specify meta-data could still make sense at some point, which each backend could choose to implement as reasonable or ignore. You're right that setting LaTeX to add [Author] is probably not one of those cases. Cheers, /v Regards, -- Nicolas Goaziou
Re: [O] Invalid read syntax (#) in org-element parse tree
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, I'm not sure about what you want to do with the parse tree. The usual function to work with it is `org-element-map'. You may want to have a look at its docstring, as it contains examples. I want to write an 'unusual' backend that does not need anything else from the exporting framework but the parse-tree as a list. So all I need would be a workaround for this read-error issue, i.e. a tip how to get a version of the parse tree that can be used as list in a Lisp program. I could not find any explanation for the '#1' and '#2' syntax I encountered, so I don't really know what its all about. -- cheers, Thorsten
Re: [O] edit-src on read-only files
it seems like org-mode should prevent that. Yes, this is now the case in master. Thanks! great -- thank you!!
Re: [O] OT, but not really: todays XKCD
Dominik, Carsten c.domi...@uva.nl writes: is just too good to not share here, together with this piece of data: $ grep defcustom lisp/*el contrib/lisp/*el |wc -l 1213 Scary! But indicative of the power of org I guess. Hurray for Nicolas and Bastien to be brave and switch to the new exporter framework which is a thing of beauty. Lets help them to fix the bugs as quickly as possible and then make those small adaptations in our workflow - it will be worth it. +1 I think it's worth making clear that my concerns last week, with respect to moving to the new exporter, were with the move taking place without a clear idea of what workflow changes were required, whether small or not. The subsequent emails to this list, by Nicolas but also by many others, has made a significant difference. I have moved over to the new exporter exclusively, with actually little change to my workflow incredibly! Things are going well but I do seem to be encountering some very obscure bugs, mostly to do with columns in beamer export. I've not been able to come up with a suitable minimal example yet unfortunately: when I take a slide which has problems out of the whole presentation and put it into a single slide document, it works... :( Anyway, work in progress. In any case, thanks are due, of course, to Nicolas and Bastien but I would also like to express my thanks to all other contributors to org, be they contributors to actual code or because of their engagement on this list! All are required for org to continue being the indispensable part of my life and all are appreciated greatly. thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-975-g1eccd2
Re: [O] [ANN] outorg.el -- reverse Org-Babel
Thorsten Jolitz tjol...@gmail.com writes: With 'outorg', you can stay in you favorite language's major-mode while programming, but with a real Org-mode 'look-and-feel', and rapidly switch to a temporary buffer in Org-mode for some comment editing. Exiting the temporary buffer then stores the edited comment text back to the original source-code buffer (out-commented with the language's 'comment-start' character). Hi, Thorsten. Just from reading your description, outorg seems strangely similar to poporg (https://github.com/pinard/poporg), which I announced on this list maybe two weeks ago. I would presume you missed it? :-) I'll save myself a pointer to outorg, for later perusing and study. François
Re: [O] OT, but not really: todays XKCD
Jambunathan K kjambunat...@gmail.com writes: Dominik, Carsten c.domi...@uva.nl writes: Hurray for Nicolas and Bastien to be brave and switch to the new exporter framework which is a thing of beauty. It is an umbrella statement and doesn't mean much in and of itself. Let me clarify, Bastien has very miniscule (~ZERO) contribution to the new framework or the exporters. Jambunathan, please do not make the mistake of underestimating the effort required to manage a project like org. It is an often thankless job (thanks Bastien!) and much of what is done is behind the scenes and probably very often akin to herding cats. Nicolas has not worked in isolation, which is not intended to diminish his contributions of course. The fact that much of the continual evolution of org is so painless and yet so effective is a real indicator of how well Bastien is managing the whole process. 'nuff said. On to other things now... like actually using org to get work done! -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-975-g1eccd2
Re: [O] [ANN] outorg.el -- reverse Org-Babel
François Pinard pin...@iro.umontreal.ca writes: Hi, Francois, Just from reading your description, outorg seems strangely similar to poporg (https://github.com/pinard/poporg), which I announced on this list maybe two weeks ago. I would presume you missed it? :-) I missed that completely, you can check the code - there should be no similarities whatsoever. I was entirely inspired by my recent discovery of the possibilities of outline-minor-mode and Org-Babel. What a bad luck ... ;( But anyway, probably the best we can do is to bring both version to a usable state and then let the users decide if they want to use it - and which one. At first glance, the projects seem so different that a merge appears impossible or just to much work - and not worth the pain. I'll save myself a pointer to outorg, for later perusing and study. I'll do the same thing with 'poporg' ;) -- cheers, Thorsten
Re: [O] OT, but not really: todays XKCD
Why are you fudging with Mail Followup headers? Please don't underestimate the confusion it creates for others. --
Re: [O] Bug: org-insert-heading-respect-content inserts at the wrong level if target heading is invisible [7.9.2 (release_7.9.2-883-g6fb36e.dirty @ /home/dlm/share/org-mode.git/lisp/)]
On Feb 12, 2013 1:31 AM, Bastien b...@altern.org wrote: Hi James, James Harkins jamshar...@gmail.com writes: I'm resending the issue that I reported the other day, now with a MCE. Sorry for the delay on this -- and thanks for the detailed reports. I tried not to get lost in the details actually... so I ended up using the attached fix. It works here, i.e. C-u C-RET inserts a new heading at the right place, but I'm not using org-mobile.el so I'm not 100% sure if it works for you. Can you test and confirm? I can, in about a week. I'm traveling, without my laptop (first time in years I've left it at home - phone and tablet only for this trip). I'm creating new entries in MobileOrg on the road. When I get home, I'll apply the patch and see what happens. One concern: When you tested with C-u C-RET, was the point on a hidden headline? The problem only occurs if the current heading is folded up underneath a parent heading. AFAIK cursor movement in org-mode ensures that the point is never on invisible text, which is why I wrote a short lisp function to demonstrate. It seems to me the issue reproduces only when calling org-insert-heading non-interactively, then, so I wanted to check if your test reproduces the problem without the patch. hjh
Re: [O] org-bullets extension
François Pinard pin...@iro.umontreal.ca writes: Bastien b...@altern.org writes: org-bullets.el is in the contrib/ directory. Let me try to describe the problem. [...] Hmph! My description was not accurate, as I can now observe. Here is a correction. Instead of: The header gets opened, with all items visible, including the one just inserted. However, for that last item, this one that just got inserted, the bullet of the following header and header text is visually concatenated at the end of that item. Typing C-l (recenter-top-bottom) repairs the display: the bullet and its text visually jump on the next line, where they belong. I should have written: The header gets opened, with all items visible, *except* the one just inserted. For the *previous to last* item, that is, *the last item which is visible*, the bullet of the following header and header text is visually concatenated at the end of that item. Typing C-l (recenter-top-bottom) repairs the display: the *last inserted item reappears*, and the bullet and its text visually jump on the next line, where they belong. Sorry for my prior lack of precision. François
Re: [O] org-bullets extension
François Pinard pin...@iro.umontreal.ca writes: François Pinard pin...@iro.umontreal.ca writes: Bastien b...@altern.org writes: org-bullets.el is in the contrib/ directory. Let me try to describe the problem. [...] Hmph! My description was not accurate, as I can now observe. Here is a correction. Instead of: The header gets opened, with all items visible, including the one just inserted. However, for that last item, this one that just got inserted, the bullet of the following header and header text is visually concatenated at the end of that item. Typing C-l (recenter-top-bottom) repairs the display: the bullet and its text visually jump on the next line, where they belong. I should have written: The header gets opened, with all items visible, *except* the one just inserted. For the *previous to last* item, that is, *the last item which is visible*, the bullet of the following header and header text is visually concatenated at the end of that item. Typing C-l (recenter-top-bottom) repairs the display: the *last inserted item reappears*, and the bullet and its text visually jump on the next line, where they belong. A screenshot is worth a 1000 words. Remember to CC the author. The author is keen to hear feedbacks and will act on it promptly. Sorry for my prior lack of precision. François --
Re: [O] [ANN] outorg.el -- reverse Org-Babel
Thorsten Jolitz tjol...@gmail.com writes: [about the nearly coincident publication of *outorg* and *poporg*] What a bad luck ... ;( Oh, I'm not much into authorship wars, you know, as long as the need gets covered. Free time being a scarce resource (for me at least!), I prefer when we can all make the best use of it. Keep happy! François
Re: [O] format of the ID property in the new HTML exporter
Daniel Clemente n142...@gmail.com writes: Hi, in ox-html.el there's a line with an assert (the only one): (assert (org-uuidgen-p path)) 1. I have some IDs like o5y98600aze0 which don't conform to that uuidgen format; they were created by early versions of org. Should only UUIDs be accepted as ID? 2. I think the ID should be editable by hand to what you like, as long as they are unique. If you don't need to export it you don't need a CUSTOM_ID, and having both ID and CUSTOM_ID is not the simplest way. So I think that assert is too strict. My short IDs seem as good as the long UUIDs. There is ID and then there is CUSTOM_ID. IIUC/IIRC, ID is a uuid and CUSTOM_ID can be whatever. Any reason why you cannot use CUSTOM_IDs here? --
Re: [O] OT, but not really: todays XKCD
Jambunathan K kjambunat...@gmail.com writes: Why are you fudging with Mail Followup headers? Please don't underestimate the confusion it creates for others. I believe that most people expect responses to a mailing list email to be directed to that list. I am sorry you have found this confusing. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-975-g1eccd2
Re: [O] New exporter macro question
Hello Nicolas,
thanks for your reply. I now remember this point of downgrading the macros and
replacing complex macro calls with babel code. Thanks also for the easy
work-around.
- Carsten
On 11.2.2013, at 22:37, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
I am porting my websites to the new exporter, finally. Much is very smooth.
I do have a problem with macros:
* Macro definition
#+MACRO: thumbright #+ATTR_HTML: style=float:right;width:$1;margin:0px
20px 0px 20px; \n [[./Content/$2/thumb.jpg]]
* Macro call
{{{thumbright(300px,Wiskunde)}}}
* This used to expand to
img src=./Content/Wiskunde/thumb.jpg
style=float:right;width:300px;margin:0px 20px 0px 20px;
alt=./Content/Wiskunde/thumb.jpg /
* But now it expands to nothing
I am sure I am missing something basic. Thanks!
Macros have been downgraded a bit, as there was some overlapping with
Babel functionalities. In particular, they are meant to replace objects,
not elements, which means they cannot contain newline characters
anymore.
You can use a Babel block to generate the Org code you want. You can
also try the following macro, which will generate the HTML code you
want:
#+MACRO: thumbright @@html:img src=./Content/$2/thumb.jpg
style=float:right;width:$1;margin:0px 20px 0px 20px;
alt=./Content/$2/thumb.jpg /@@
Regards,
--
Nicolas Goaziou
Re: [O] OT, but not really: todays XKCD
Eric S Fraga e.fr...@ucl.ac.uk writes: Jambunathan K kjambunat...@gmail.com writes: Why are you fudging with Mail Followup headers? Please don't underestimate the confusion it creates for others. I believe that most people expect responses to a mailing list email to be directed to that list. Pray explain why Carsten appears in the followup post and you yourself don't figure in it. When I send a wide reply - S W in (gnus) - my response would have been sent To to Carsten. Precisely this is what I see in my Gnus buffer. , Reply buffer | To: Dominik, Carsten c.domi...@uva.nl | Cc: emacs-orgmode@gnu.org List emacs-orgmode@gnu.org | Subject: Re: OT, but not really: todays XKCD | Gcc: nnfolder+archive:sent.2013-02 | From: Jambunathan K kjambunat...@gmail.com ` , Article buffer | Mail-Followup-To: Jambunathan K kjambunat...@gmail.com, Dominik, Carsten | c.domi...@uva.nl, emacs-orgmode@gnu.org List | emacs-orgmode@gnu.org ` I am sorry you have found this confusing. I will continue to be confused, unless an explanation is in order. I have noticed this consistently with your mails in the past. --
Re: [O] suggestion: M-m should move point to first word on line
Bastien b...@altern.org writes: [...] Not to override `M-m' but perhaps to define * as a syntactic whitespace character. Patch attached -- use with caution. I tested it a bit and it seems to work, but not all tests pass and there may be side-effects that I could not observe. Bastien, this seems to cause a problem with org-ctrl-c-minus when trying to cycle a bullet point past +. That is, it works if the bullet is - so you can cycle to the next which is + but you cannot cycle past that. I've tried this batch with org up to date a few minutes ago (ignore my signature info below as this emacs is running a slightly older org). Emacs was started with -Q. Debug trace: , | Debugger entered--Lisp error: (args-out-of-range 85 88) | replace-match( nil nil * 1) | org-cycle-list-bullet(nil) | call-interactively(org-cycle-list-bullet) | org-ctrl-c-minus() | call-interactively(org-ctrl-c-minus nil nil) ` Point was at column 0 of the first item in the attached minimal org file. I hope that's enough info... Thanks, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-975-g1eccd2 #+TITLE: examplebug.org #+AUTHOR:Eric S Fraga * cycling list bullet points + the first item + the second item + and the third and last item
Re: [O] OT, but not really: todays XKCD
Jambunathan K kjambunat...@gmail.com writes: A targeted donation (for individual work or hosting the servers) is much better than an umbrella donation to Orgmode or Bastien. FWIW I agree. Any effective proposal against the website is welcome: ~$ git clone git://orgmode.org/orgweb.git Thanks, -- Bastien
Re: [O] Problem with org-html-format-latex
Vincent Beffara vbeffara...@gmail.com writes: so simply testing on the value of processing-type would work better, maybe? Yes, should be okay now, let me know! Nope, exactly the same. cache-relpath and cache-dir are not allowed to be nil. Meaning that if processing-type is 'mathjax they should be set to _some_ string anyway (the contents will be ignored eventually, but far down the line unfortunately ...) Something like instead of your 'let' line works: (let ((cache-relpath ) (cache-dir ) bfn) Mhh... okay. Now should be good. Thanks for your patience. -- Bastien
Re: [O] suggestion: M-m should move point to first word on line
Hi Eric, thanks for testing. Eric S Fraga e.fr...@ucl.ac.uk writes: this seems to cause a problem with org-ctrl-c-minus when trying to cycle a bullet point past +. That is, it works if the bullet is - so you can cycle to the next which is + but you cannot cycle past that. Attached patch (against master) fixes this problem. I'm not sure I'm in favor of this change, though, I expect it to cause other problems and the benefit looks small for now. Do you see other reasons than M-m where stars as whitespace chars are useful? What about *markup*? Thanks, From a41bc3569e6812ce0c35e50abfc91590a47919c6 Mon Sep 17 00:00:00 2001 From: Bastien Guerry b...@altern.org Date: Tue, 12 Feb 2013 08:30:14 +0100 Subject: [PATCH] org.el (org-mode): Set ?* to be syntactically a whitespace character * org-list.el (org-list-bullet-string): Don't skip all whitespace characters, skip whitespace and tab explicitely. * org.el (org-mode): Set ?* to be syntactically a whitespace character. --- lisp/org-list.el | 4 ++-- lisp/org.el | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org-list.el b/lisp/org-list.el index d86746f..e4d6d6d 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -1081,8 +1081,8 @@ It determines the number of whitespaces to append by looking at org-list-two-spaces-after-bullet-regexp bullet)) ))) - (string-match \\S-+\\([ \t]*\\) bullet) - (replace-match spaces nil nil bullet 1 + (if (string-match [^ \t]+\\([ \t]*\\) bullet) + (replace-match spaces nil nil bullet 1) (defun org-list-swap-items (beg-A beg-B struct) Swap item starting at BEG-A with item starting at BEG-B in STRUCT. diff --git a/lisp/org.el b/lisp/org.el index 461cdf0..a58c10b 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5173,6 +5173,7 @@ The following commands are available: (org-set-tag-faces 'org-tag-faces org-tag-faces)) ;; Calc embedded (org-set-local 'calc-embedded-open-mode # ) + (modify-syntax-entry ?* ) (modify-syntax-entry ?@ w) (modify-syntax-entry ?\ \) (if org-startup-truncated (setq truncate-lines t)) -- 1.8.1.2 -- Bastien
