Re: [O] bug(?) ox-html always add a timestamp in comment which can't be customized away
Haojun Bao baohao...@gmail.com writes: Just checked, it is the same tag (release_8.0.3), there is no change like in your code. Could you please run git blame on those lines? You need to upgrade to latest. Git blame says: , | $ git blame -L 1509,1511 lisp/ox-html.el | d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1509) (when (plist-get info :time-stamp-file) | d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1510) (format-time-string | d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1511) (concat !-- org-html-metadata-timestamp-format --\n))) ` and the commit shows the change from the code you see to the code I see: , | nick@pierrot:~/src/emacs/org/org-mode$ git show d574bf52 | commit d574bf522d1b2ac74cb4245f8742253bde7861df | Author: Kodi Arfer g...@arfer.net | Date: Thu May 30 15:19:57 2013 -0400 | | ox-html: Fix handling of time-stamp-file | | * lisp/ox-html.el (org-html--build-meta-info): Insert no timestamp | when :time-stamp-file is nil. | | TINYCHANGE | | diff --git a/lisp/ox-html.el b/lisp/ox-html.el | index 297cb55..949c3ba 100644 | --- a/lisp/ox-html.el | +++ b/lisp/ox-html.el | @@ -1506,10 +1506,9 @@ INFO is a plist used as a communication channel. |iso-8859-1))) | (concat | (format title%s/title\n title) | - (format | - (when :time-stamp-file | - (format-time-string | - (concat !-- org-html-metadata-timestamp-format --\n | + (when (plist-get info :time-stamp-file) | + (format-time-string | + (concat !-- org-html-metadata-timestamp-format --\n))) | (format |(if (org-html-html5-p info) | (org-html-close-tag meta charset=\%s\ info) ` Nick On Sat, Jun 8, 2013 at 1:30 PM, Nick Dokos ndo...@gmail.com wrote: Haojun Bao baohao...@gmail.com writes: The culprit code is the following: (when :time-stamp-file (format-time-string (concat !-- org-html-metadata-timestamp-format --\n))) This `when' condition is always true, because :time-stamp-file is a keyword and always eval to itself, never to nil. So I think org-export-time-stamp-file should be used instead of :time-stamp-file. What version are you using? In the version I have, the code looks like this: (when (plist-get info :time-stamp-file) (format-time-string (concat !-- org-html-metadata-timestamp-format --\n))) Org-mode version 8.0.3 (release_8.0.3-197-g221768) [nb: this version includes a few local commits (irrelevant to this subject)] -- Nick -- Nick
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: As I recall I was fully in favor of applying these changes, however I am not qualified to address the changes to property behaviors. Hopefully someone who works more on that side of things can address those aspects. Oh wait, now I understand what you're getting at, let me explain. The first patch that makes Org use the same regex in all places where a property is used does indeed change some behaviour, but not the syntax of the property line: :PROPERTY: VALUE where PROPERTY can contain any non-whitespace character (in correspondence to how the keyword PROPERTY is treated in org.el since it is not explicitly specified in org-element). However, there were other places in Org where a more restricted syntax for properties in property drawers was used, which would have precluded the use of : in property names and made it impossible to overwrite an inherited property from a #+PROPERTY: line that has such a property name. I've taken org-element as the authoritative source for the syntax and eliminated the other interpretations based on the fact that while the behaviour visible in the buffer (highlighting, prompts, etc.) would hint differently, the actual property handling was using the syntax used in org-element already. Hence if documents existed that had mistakenly made use of these differences, they were already broken and would be interpreted via the property API as they are now also shown after this change. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Wrong comment character when adding file local variables?
Rainer M Krug r.m.k...@gmail.com writes: On Friday, June 7, 2013, Vitalie Spinu wrote: All your examples are placed in fundamental mode. The comments are treated by org and thus are correct, local variables are inserted according to the major mode. The question is why - all .R files are automatically in r mode when I open them and all other R files tangle fine. That's because the auto-mode-alist tells emacs that .R files should be in R-mode, so after emacs opens the file, it calls the R-mode function. I don't how this could be easily fixed on org side, but you can solve it straightforwardly with: (add-to-list 'auto-mode-alist (cons NAME\\|DESC 'R-mode)) Ok - I'check it out on Monday. That's one way: it's got its downside in that the names have to match, so you have to remember to modify the auto-mode-alist when you use different names when tangling. Another way is to modify the function below: I use the following in my .emacs file to set the post-tangle-hook to add the local file variables: , | (defvar org-babel-tangled-file nil |If non-nill, current file was tangled with org-babel-tangle) | (put 'org-babel-tangled-file 'safe-local-variable 'booleanp) | | (defun org-babel-mark-file-as-tangled () (R-mode) ; | (add-file-local-variable 'org-babel-tangled-file t) | (add-file-local-variable 'buffer-read-only t) | ;; (add-file-local-variable 'eval: (auto-revert-mode)) | (basic-save-buffer)) | | (add-hook 'org-babel-post-tangle-hook |'org-babel-mark-file-as-tangled) ` to call R-mode explicitly. That's got its own downside: all your tangled files are going to be in R-mode. The point is that you have to tell emacs somehow what you are doing: it can't guess that you are producing R-mode files without some help. -- Nick
[O] Go to heading using LISP
Hi! I want to create special key-bindings that use the org-refile goto interface to jump to specific headings. My initial attempt was: (org-refile 4 gtd.org Projects/Work/Bugs) But it seems specifying RFLOC is not that simple. Someone have any idea how to achieve this or another way to jump to a heading? Best Regards /Alexander
Re: [O] bug(?) ox-html always add a timestamp in comment which can't be customized away
Thanks, sorry for not checking the latest version. On Sat, Jun 8, 2013 at 2:04 PM, Nick Dokos ndo...@gmail.com wrote: Haojun Bao baohao...@gmail.com writes: Just checked, it is the same tag (release_8.0.3), there is no change like in your code. Could you please run git blame on those lines? You need to upgrade to latest. Git blame says: , | $ git blame -L 1509,1511 lisp/ox-html.el | d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1509) (when (plist-get info :time-stamp-file) | d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1510) (format-time-string | d574bf52 (Kodi Arfer 2013-05-30 15:19:57 -0400 1511) (concat !-- org-html-metadata-timestamp-format --\n))) ` and the commit shows the change from the code you see to the code I see: , | nick@pierrot:~/src/emacs/org/org-mode$ git show d574bf52 | commit d574bf522d1b2ac74cb4245f8742253bde7861df | Author: Kodi Arfer g...@arfer.net | Date: Thu May 30 15:19:57 2013 -0400 | | ox-html: Fix handling of time-stamp-file | | * lisp/ox-html.el (org-html--build-meta-info): Insert no timestamp | when :time-stamp-file is nil. | | TINYCHANGE | | diff --git a/lisp/ox-html.el b/lisp/ox-html.el | index 297cb55..949c3ba 100644 | --- a/lisp/ox-html.el | +++ b/lisp/ox-html.el | @@ -1506,10 +1506,9 @@ INFO is a plist used as a communication channel. |iso-8859-1))) | (concat | (format title%s/title\n title) | - (format | - (when :time-stamp-file | - (format-time-string | - (concat !-- org-html-metadata-timestamp-format --\n | + (when (plist-get info :time-stamp-file) | + (format-time-string | + (concat !-- org-html-metadata-timestamp-format --\n))) | (format |(if (org-html-html5-p info) | (org-html-close-tag meta charset=\%s\ info) ` Nick On Sat, Jun 8, 2013 at 1:30 PM, Nick Dokos ndo...@gmail.com wrote: Haojun Bao baohao...@gmail.com writes: The culprit code is the following: (when :time-stamp-file (format-time-string (concat !-- org-html-metadata-timestamp-format --\n))) This `when' condition is always true, because :time-stamp-file is a keyword and always eval to itself, never to nil. So I think org-export-time-stamp-file should be used instead of :time-stamp-file. What version are you using? In the version I have, the code looks like this: (when (plist-get info :time-stamp-file) (format-time-string (concat !-- org-html-metadata-timestamp-format --\n))) Org-mode version 8.0.3 (release_8.0.3-197-g221768) [nb: this version includes a few local commits (irrelevant to this subject)] -- Nick -- Nick
Re: [O] Avoid escaping braces in LaTeX export?
Richard Lawrence richard.lawre...@berkeley.edu writes: [...] Still, this won't work directly for cases where I have loaded a LaTeX package that provides a command which uses curly braces. (I could redefine such commands, as above, but that could get real ugly, real fast...). It seems like this a general problem that the exporter should have a way to handle. Org is not latex, for better or for worse. However, it does allow you to mix the two in various ways. The inline approach is limited to {text} that is on the same line. You could try using visual-line-mode and have all paragraphs be single lines. Alternative, you could try (untested): blah blah blah #+LATEX: \ic{ some text for the inline comment #+LATEX: } more blah HTH, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.3-193-g334581
[O] different font sizes for headings
Hi all! I have installed emacs two days ago and org-mode yesterday. I'm new in it. And currently configuring everything in it. And I just recently found such screenshot: https://raw.github.com/juba/color-theme-tangotango/0a501959707b7637c72aba779651ea94cec96963/screenshots/tangotango_org.png And I'm searching via google how to configure emacs/org-mode so it can display headings (Level 1 Heading, Level 2 Heading) with different font sizes... How such thing could be done? Could you help me please? Thank you in advance! Regards, Andrey.
Re: [O] Avoid escaping braces in LaTeX export?
Eric S Fraga e.fr...@ucl.ac.uk writes: Richard Lawrence richard.lawre...@berkeley.edu writes: Org is not latex, for better or for worse. However, it does allow you to mix the two in various ways. The inline approach is limited to {text} that is on the same line. You could try using visual-line-mode and have all paragraphs be single lines. Alternative, you could try (untested): blah blah blah #+LATEX: \ic{ some text for the inline comment #+LATEX: } more blah Thanks, Eric; that works, too. I think for now the best thing is for me to put longer comments in a custom environment. Then I can use Org's block syntax, and have other export backends do the right thing, if I ever use them instead of LaTeX. I did dig into the exporter code a bit, so in case anyone is bitten by a similar issue that doesn't have a ready workaround, the places to look seem to be: - org-element.el:org-element-latex-or-entity-successor. This is where LaTeX fragments are identified. (As Eric notes, multi-line commands will not have their arguments parsed as part of a latex-fragment; instead, the argument and surrounding braces are parsed as text in the surrounding paragraph.) - ox-latex.el:org-latex-plain-text. This is where special characters that don't get parsed as part of a LaTeX fragment are protected/escaped. I still think it might be nice if each of the protections in org-latex-plain-text could be toggled via an #+OPTIONS keyword, since more often than not, I find that characters are escaped in LaTeX export when I would prefer they weren't. But that might be a peculiar fact about how I use Org. Since for now I don't require this behavior, I'm not going to try to implement it myself, but if anyone else would also find it useful, let me know and I will take a stab at writing a patch. Thanks, all, for the help! -- Best, Richard
[O] add joint work with
Hello emacs-orgmode list! I am trying to prepare a talk using ox-beamer and am missing a function that I am used to. In beamer latex one can for example write \author[speaker]{speaker \\ joint work with second author and third author} Then I get my name and that of my coauthors on the titlepage. My name can then also appear (depending on the beamer theme) in the footnote on each slide. Is it possible to achieve this without exporting to latex and adjusting the corresponding entries there? I didn't find an answer on the list. Also in ox-beamer.el the corresponding section contains only entries with \author{...}, i.e. without square brackets. Would be nice to have an entry #+COAUTHOR: second author and third author that is then put in \author[second author and third author]{...} Or is there already something similar that I didn't find? Best regards, Andrej
Re: [O] link abbreviation with multiple params, e. g. for geo locations
If yes then I understand only now that the functionality of the new variable is of course the same for the changes in both commits and therefore the name has to be the same for the changes in both commits. But for me it would have helped to have some other name, containing neither src-block, which I associate it with #+BEGIN_SRC but not #+CALL line or inline call_name, nor head, which I associate with #+HEADER. I would like to suggest org-babel-exec-marker. What do you and Vitalie (CCed) think? I named it with head because head is the local variable in org-babel-get-src-block-info referring to that position. There are other functions that use -head: org-babel-goto-src-block-head, org-babel-where-is-src-block-head. But, I agree that it might be better called beg, location or position. I think src-block is not misleading, there are plenty of foo-src-block-bar in babel. May be then: org-babel-current-src-block-location? How about the shorter `org-babel-current-src-block'? It is somewhat more ambiguous, but the only reasonable options would be location or name, and not every code block has a name. I think the added brevity is worth the ambiguity, but I'm not strongly committed either way. I'll happily commit whatever is generally appealing. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] link abbreviation with multiple params, e. g. for geo locations
2) Export is not supported (C-c C-c works as expected). I can't reproduce this bug. From your attached org-entry-get-point-example.org I get with some lines omitted \section{example of a geo location, realistic to try out} \item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.56,7.89} \section{another geo location} \item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.44,5.55} but expect \section{example of a geo location, realistic to try out} \item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.56,7.89} \section{another geo location} \item \texttt{geo\_var is 4.44,5.55} \texttt{geo\_var is 4.44,5.55} I've just pushed up a commit which should fix this problem. The org-babel-current-exec-src-block-head variable wasn't bound during export. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] :session question -- and changes to #+Property: syntax
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: As I recall I was fully in favor of applying these changes, however I am not qualified to address the changes to property behaviors. Hopefully someone who works more on that side of things can address those aspects. Oh wait, now I understand what you're getting at, let me explain. The first patch that makes Org use the same regex in all places where a property is used does indeed change some behaviour, but not the syntax of the property line: :PROPERTY: VALUE where PROPERTY can contain any non-whitespace character (in correspondence to how the keyword PROPERTY is treated in org.el since it is not explicitly specified in org-element). However, there were other places in Org where a more restricted syntax for properties in property drawers was used, which would have precluded the use of : in property names and made it impossible to overwrite an inherited property from a #+PROPERTY: line that has such a property name. I've taken org-element as the authoritative source for the syntax and eliminated the other interpretations based on the fact that while the behaviour visible in the buffer (highlighting, prompts, etc.) would hint differently, the actual property handling was using the syntax used in org-element already. Hence if documents existed that had mistakenly made use of these differences, they were already broken and would be interpreted via the property API as they are now also shown after this change. Great. Would you be willing to go ahead and apply these changes (including documentation)? If it upsets anyone we'll sort things out on the mailing list. There are stable releases precisely so that we can experiment interactively on the development head. Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Automatically adding local variables to tangled file
We already set the permission of tangled files to be executable when they include a shebang line. Perhaps we could add an option (or change the default) to set the permissions of tangled files to be read only. Perhaps this could be done using the post-tangle hook with something like the following. ;; -*- emacs-lisp -*- (defun org-babel-mark-tangled-as-read-only () Mark the current file read only. If it is executable keep it executable. (if (= #o755 (file-modes (buffer-file-name))) (set-file-modes (buffer-file-name) #o555) (set-file-modes (buffer-file-name) #o444))) (add-hook 'org-babel-post-tangle-hook 'org-babel-mark-tangled-as-read-only) I think that would be a good idea to add this in a way so that it is controled by a variable I've added a :tangle-mode header argument which may be used to control the permissions of tangled files. See the manual for instructions on it's usage. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] link abbreviation with multiple params, e. g. for geo locations
Eric Schulte schulte.e...@gmail.com on Sat, 08 Jun 2013 12:05:32 -0600 wrote: [...] May be then: org-babel-current-src-block-location? How about the shorter `org-babel-current-src-block'? It is somewhat more ambiguous, but the only reasonable options would be location or name, and not every code block has a name. I think the added brevity is worth the ambiguity, but I'm not strongly committed either way. I personally find it quite confusing. Babel names that contain src-block semantically refer to the whole thing. This one refers to the pointer. If brevity is very important I would rather drop current: `org-babel-src-block-location' or probably even more suggestive: `org-babel-src-block-beginning'. Vitalie
Re: [O] link abbreviation with multiple params, e. g. for geo locations
Vitalie Spinu spinu...@gmail.com writes: Eric Schulte schulte.e...@gmail.com on Sat, 08 Jun 2013 12:05:32 -0600 wrote: [...] May be then: org-babel-current-src-block-location? How about the shorter `org-babel-current-src-block'? It is somewhat more ambiguous, but the only reasonable options would be location or name, and not every code block has a name. I think the added brevity is worth the ambiguity, but I'm not strongly committed either way. I personally find it quite confusing. Babel names that contain src-block semantically refer to the whole thing. This one refers to the pointer. If brevity is very important I would rather drop current: `org-babel-src-block-location' or probably even more suggestive: `org-babel-src-block-beginning'. I like current because it is similar to other variables which are dynamically bound by Org-mode and without it there is no indication that it points to a block which is active *now*. I've changed the variable name to your previous suggestion of `org-babel-current-src-block-location'. If anyone really wants brevity they can add the following to their config. ;; -*- emacs-lisp -*- (defun loc () org-babel-current-src-block-location) Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
[O] 'listings' package used but not required in LaTeX export
Hi List, at the risk that this is caused by some personnal configuration I'm not aware of at the moment, I report it nevertheless: When I export an .org buffer with source code blocks (e.g. R) to LaTeX, functions from the 'listings' package are used in the LaTeX sources, like e.g. ,- | \lstset{language=R,numbers=none} | \begin{lstlisting} `- but there is no ,-- | \usepackage{listings} `-- statement in the preamble. This is about exporting with no further options or properties set, the default case so to say. PS Emacs Version: (24.3.1 24 3 gnu/linux hostname x86_64-unknown-linux-gnu x nil) Org-mode version 8.0.3 (release_8.0.3-165-g60ca9e @ /home/tj/gitclone/org-mode/lisp/) -- cheers, Thorsten
Re: [O] :session question -- and changes to #+Property: syntax
Eric Schulte writes: Great. Would you be willing to go ahead and apply these changes (including documentation)? If it upsets anyone we'll sort things out on the mailing list. All right, then. I've pushed the first part as it is a preparation for the actual change. I can push that second part as well, but I'll need another week or so for properly documenting it in the manual and setting up a test. Unless someone urgently wants to do something with it, I'd rather push these things together. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] Automatically adding local variables to tangled file
Eric Schulte writes: I've added a :tangle-mode header argument which may be used to control the permissions of tangled files. See the manual for instructions on it's usage. The change in org-babel-read now requires that :shebang values are quoted. I've changed the test file accordingly as otherwise the file couldn't be ingested. In general I'd suggest that reading header arguments as eLisp should at be protected against an error propagating out of the reader function. 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] Automatically adding local variables to tangled file
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: I've added a :tangle-mode header argument which may be used to control the permissions of tangled files. See the manual for instructions on it's usage. The change in org-babel-read now requires that :shebang values are quoted. Oh, I should have realized that shebang values weren't normally quoted. I've reverted this portion of my tangle-mode patch, so the reader no longer tries to read #-prefixed strings a elisp. Hopefully this won't affect too many people. I've changed the test file accordingly as otherwise the file couldn't be ingested. In general I'd suggest that reading header arguments as eLisp should at be protected against an error propagating out of the reader function. I think in most cases it would be better to know if an error has occurred than not, and I think any sort of message output would quickly be overwritten by the remainder of the code block execution. Thanks for catching this quickly! Regards, Achim. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] 'listings' package used but not required in LaTeX export
Thorsten Jolitz tjol...@gmail.com writes: but there is no ,-- | \usepackage{listings} `-- This is a feature to my understanding. Several packagess can format, and I for instance prefer pygments if I need code formatting. You could add listings to your packages list, either org-latex-packages-alist or even org-latex-default-packages-alist, if you really want to. You could probably also write a clever filter to load a package if it is missing. –Rasmus -- When in doubt, do it!
Re: [O] 'listings' package used but not required in LaTeX export
Rasmus ras...@gmx.us writes: Thorsten Jolitz tjol...@gmail.com writes: but there is no ,-- | \usepackage{listings} `-- This is a feature to my understanding. mmhh ... I would rather say that the defaults can be as simple as possible (or desired), but should result in reasonable output without any user interaction. But without adding a \usepackage{listings} or modifying the variables you mention the LaTeX output is unusable in this case. Several packagess can format, and I for instance prefer pygments if I need code formatting. Then the default should be loading one of them rather than using package macros in the exported LaTeX sources without loading a package that contains those macros. You could add listings to your packages list, either org-latex-packages-alist or even org-latex-default-packages-alist, if you really want to. You could probably also write a clever filter to load a package if it is missing. I could, and thanks for the tips, but I still think this can be considered a bug (if I'm not the only one having the problem). -- cheers, Thorsten
Re: [O] Go to heading using LISP
Alexander Wingård alexander.wing...@gmail.com writes: Hi! I want to create special key-bindings that use the org-refile goto interface to jump to specific headings. My initial attempt was: (org-refile 4 gtd.org Projects/Work/Bugs) But it seems specifying RFLOC is not that simple. Someone have any idea how to achieve this or another way to jump to a heading? Is the `org-goto' interface close enough? It only does the current buffer, but you can set org-goto-interface to make it behave a fair bit like refile... Yours Eric
[O] org-mouse broken
In recent git master, when org-mouse is loaded, the mouse is not active in the stars of headlines. After reverting the Org buffer, the mouse is active. This is an insufficient bug report, but I cannot do better at this time. I hope that somebody can think of recent activity in the git repo that could have affected this. Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.