Re: [O] Number formatting in tables for LaTeX export
Hello, Michael Gauland mikely...@amuri.net writes: I have a table representing a memory map, something like this: | Start | End | Purpose| |---+--+| | | 1E08 | Bootloader | | 1E09 | 1FFF | Unused (Bootloader expansion) | | 2000 | 3F39 | Application| When I export to LaTeX, '1E08' and '1E09' are interpreted as decimal exponent numbers, and are exported as '1(08)' and '1(09)'. The only way I've found to prevent this is to include the line: #+ATTR_LaTeX: :mode verbatim which produces a rather ugly fixed-font table. Is there an existing solution to this? If not, any ideas for addressing it? You may want to change `org-table-number-regexp' (global) or modify, at least locally, through BIND keyword, `org-latex-table-scientific-notation'. Regards, -- Nicolas Goaziou
Re: [O] how to best make characters invisible in a org-derived mode
Am 27.04.2013 05:29, schrieb Christian Wittern: Hi orgers, In a mode derived from org-mode, I would like to hide some characters with a special function to make the display cleaner. There are two cases: - special characters that should be always invisible - strings matched by a regex that should be invisible I would be glad for any pointers or ideas on how to implement this, either by piggy-packing on org-mode code or by using generic Emacs features. All the best, Christian Hi, maybe have a look how ar-hide-bracketed-in-line-atpt for example is implemented. https://launchpad.net/s-x-emacs-werkstatt/ https://launchpad.net/s-x-emacs-werkstatt/trunk/1.3/+download/S-X-Emacs-Werkstatt-1.3.tar.gz This provides a framework for tasks like this. HTH, Andreas
Re: [O] org-blog 0.9 release
Rafael rvf0...@gmail.com writes: Thanks a lot for your work! I just tried it and it worked for me, to post a basic org-mode file. Thanks for trying it---it's always nice to hear that it works for someone else, too. I'm hopeful that, by having a fairly fleshed-out test suite included, if it doesn't work for someone, the user and I should be able to track down the issue fairly easily. Are you aware of https://github.com/punchagan/org2blog? It also has the purpose to post to wordpress from org, however its author has been busy lately, and apparently major work is going to be needed to make all its features to work with the new exporter. I hope that you could find the time and motivation to make your package deal with: Yep, I'm aware of org2blog---I even used it for a while. There were various things about it for which I did not care, and they seemed fairly fundamental and unlikely to change. I suspect writing a blogging addition for org-mode is today's equivalent of writing your own templating engine for Perl: the bar for entry is low enough that the slightest disagreement with an existing one is cause for writing your own. ;) - inclusion of image files - matematical symbols (that is, wordpress can display LaTeX stuff like $latex a^2+b^2=c^2$ nicely. - syntax code highlighting, native to wordpress. I do want to add more sophisticated content handling capabilities. Image (or other) attachments is an item I want myself. While I support the idea of other, more sophisticated formatting, since I don't have a direct stake in most of them, I'm not sure what the best way to present them is. If org2blog's presentation seems sensible, I will probably follow that just to be compatible. Incidentally, I've tagged 0.10 which has converted to the org-8.0 exporter. In fact, it's probably good that you brought this up now: I do need to implement some additional processing of the exported content (even when you present it with full HTML input, where whitespace shouldn't matter, stupid WordPress inserts line breaks whereever there are newlines). I figure if I design it correctly, the additional processing should be extensible to support the sort of rich content you're talking about as well. Mike.
Re: [O] org-blog 0.9 release
Puneeth Chaganti puncha...@gmail.com writes: Or, if it seems reasonable, we could club the two projects into a single one to give the users something that's better than a sum of the parts! Hi, Puneeth, While I'm not sure the structure of the two tools is really amenable to being joined---the code is very, very different, and I am, of course, biased toward mine ;)---it seems to me *that* a common ox-blog (or whatever) back-end could be a good point of collaboration: it would help jump-start getting org2blog to where it work with 8.0, and it would get org-blog the more sophisticated export capabilities that Rafael seeks. What I'm imagining is an exporter derived from org-html (of which I've already got the basics done) that adds on the additional features you've implemented in org2blog. If you don't mind, I will start looking at the org2blog code and seeing how cleanly I can implement these additional capabilities as handlers or filters for the exporter---and then maybe we could look for that back-end to live in contrib, and both our codebases could take advantage of it? Cheers, Mike.
Re: [O] parameterizing keyword values during a #+call
Gary,
Org-mode macros that got expanded in the middle of babel source block
text would be cool. Just saying.
i agree with Eric's comment. if you think of the issue of trying to
parse an arbitrary (and growing) number of languages, trying to avoid
language-specific constructions in your choice of macro-designator
(things like @@..@@ or {{..}} or $.. or...), etc., you will
probably fairly quickly come to see the benefits of :var as the way of
passing in inputs.
cheers, Greg
Re: [O] org-blog 0.9 release
Mike, On Wed, May 1, 2013 at 4:18 PM, Michael Alan Dorman mdor...@ironicdesign.com wrote: Puneeth Chaganti puncha...@gmail.com writes: Or, if it seems reasonable, we could club the two projects into a single one to give the users something that's better than a sum of the parts! [..] If you don't mind, I will start looking at the org2blog code and seeing how cleanly I can implement these additional capabilities as handlers or filters for the exporter---and then maybe we could look for that back-end to live in contrib, and both our codebases could take advantage of it? That seems like a good plan. I've been meaning to get this going for some time, but have been quite busy off-late. I'll try to make some time for it, soon. Thanks! Puneeth
[O] selecting columns to export
hi. i have an org-mode table with a large number of columns, but would like to export only a small number of them. is there an obvious way of doing this? cheers, Greg
Re: [O] selecting columns to export
Hi Greg, Greg Minshall wrote: hi. i have an org-mode table with a large number of columns, but would like to export only a small number of them. is there an obvious way of doing this? Put a partial echo code block (one where you select in the var header argument which columns interest you), and output the results of that code block? Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] export to various flavors of (X)HTML
On Tue, Apr 30, 2013 at 08:26:52PM -0700, Eric Abrahamsen wrote: Rick Frankel r...@rickster.com writes: Whoops. Wrong key. Patch actually attached to this email... rick Great, I'll consolidate all these -- would it be better to mush them into one big patch, or to keep them separate (I suppose for ease of rollback, if something goes wrong)? Probably squashing them into one patch would be the best. But Carsten or Bastien might disagree :). rick
[O] [PATCH] ox: Cache locations of fuzzy links
* ox.el (org-export-resolve-fuzzy-link): Look for fuzzy link in a cache before trying to resolve it in the parse tree. When a document contains a large number of identical fuzzy links, it doesn't make sense to continually search for them. Instead, as long as we're looking for position independent links, cache the locations and look there first. --- lisp/ox.el | 48 +++- 1 file changed, 35 insertions(+), 13 deletions(-) Achim Gratz wrote: Lawrence Mitchell writes: I did a bit of digging and here are the results. No potential fixes though. I couldn't see how to fix up org-export-data, but here's some band-aid to speed up resolving fuzzy links. It works much better for the fake test case (where there are many identical links) than the real org manual, but I do get a slight improvement (about 6%). As per elp: Before: org-latex-export-to-latex 1 373.02289908 373.02289908 org-export-resolve-fuzzy-link 281 42.108304211 0.1498516164 After: org-latex-export-to-latex 1 349.7238257 349.7238257 org-export-resolve-fuzzy-link 281 19.329938028 0.0687898150 Cheers, Lawrence diff --git a/lisp/ox.el b/lisp/ox.el index 88b4122..bb49512 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -3976,27 +3976,49 @@ significant. ;; Split PATH at white spaces so matches are space ;; insensitive. (path (org-split-string - (if match-title-p (substring raw-path 1) raw-path + (if match-title-p (substring raw-path 1) raw-path))) +(link-cache (plist-get info :fuzzy-link-cache))) +;; Cache for locations of fuzzy links that are not position dependent +(unless link-cache + (setq info (plist-put info :fuzzy-link-cache + (make-hash-table :test 'equal))) + (setq link-cache (plist-get info :fuzzy-link-cache))) (cond ;; First try to find a matching path unless user specified ;; he was looking for a headline (path starts with a * ;; character). ((and (not match-title-p) - (org-element-map (plist-get info :parse-tree) 'target -(lambda (blob) - (and (equal (org-split-string (org-element-property :value blob)) - path) - blob)) -info t))) + (let ((found (gethash (cons 'path path) +link-cache +'fuzzy-link-not-found))) +(or (not (eq found 'fuzzy-link-not-found)) +(puthash (cons 'path path) + (org-element-map (plist-get info :parse-tree) 'target + (lambda (blob) + (and (equal (org-split-string + (org-element-property :value blob)) + path) + blob)) + info t) + link-cache) ;; Then try to find an element with a matching #+NAME: path ;; affiliated keyword. ((and (not match-title-p) - (org-element-map (plist-get info :parse-tree) - org-element-all-elements -(lambda (el) - (let ((name (org-element-property :name el))) -(when (and name (equal (org-split-string name) path)) el))) -info 'first-match))) + (let ((found (gethash (cons 'name path) +link-cache +'fuzzy-link-not-found))) +(or (not (eq found 'fuzzy-link-not-found)) +(puthash (cons 'name path) + (org-element-map (plist-get info :parse-tree) + org-element-all-elements + (lambda (el) + (let ((name (org-element-property :name el))) + (when (and name (equal +(org-split-string name) +path)) + el))) + info 'first-match) + link-cache) ;; Last case: link either points to a headline or to nothingness. ;; Try to find the source, with priority given to headlines with ;; the closest common ancestor. If such candidate is found, -- 1.8.2-rc3
Re: [O] [new exporter] how can I export drawers?
Thomas S. Dye t...@tsdye.com writes: Hi Eric, I haven't been following closely, so I'm just checking that you're aware of a new variable org-export-allow-bind-keywords, which could play a role in the behavior you are seeing. Thanks Tom. I am indeed aware of this variable. And it usually works. For some reason, some times the bindings are ignored but not in any consistent manner. I am going to keep trying to see if I can come up with an example that is reproducible but so far no luck! I should add that, generally, the new exporter is excellent. My problem has been that I have so many documents on the go (from slides to papers, memos, minutes and notes) that the conversion process from old to new exporter is causing me a bit of stress. Typically, when I re-visit a document that was prepared with the old exporter, it's because I need it *now* and I rush into making the changes that are needed for the new exporter... :( Obviously, I need to use org more effectively for my time management ;-) Anyway, I have just submitted a paper for publication, written entirely in org (+babel), including all the data processing, figure generation, etc. Org is a brilliant tool all around! Thanks again, eric -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_8.0.1-60-gcb6284
[O] Rationale for *text* - \alert{text} for Beamer export?
Greetings,
Just wondering about the rationale behind using *bold* markup for
\textbf{} in LaTeX export and to \alert{} in Beamer. Was this a
frequently voiced request? I'm sure I can dig into this somewhere and
change it, but if the majority prefers bold (not saying they do!),
should that be the default?
I'd prefer bold, personally. I don't like red table column titles or in lists.
Thanks,
John
[O] using gnuplot's splot and every commands on org-mode table data
Hello everyone, I'd be grateful if someone would offer me advice on using gnuplot's splot and every commands when plotting data from a table within org-mode. As far as I can tell, these gnuplot commands do not work properly because org-mode exports empty fields in tables as and gnuplot's every and splot commands expect the data file to be formatted as a datablock with blank lines marking the boundaries between datablocks. (For the definition of a datablock, type help glossary at the gnuplot prompt.) I'm using org-mode version 8.0.2 and emacs version 24.2.1 on a Fedora-18 system To illustrate my point, consider a blocked datafile called block.dat containing the following: 1 1 2 1 2 5 1 3 10 2 1 5 2 2 8 2 3 13 3 1 10 3 2 13 3 3 18 For this file the gnuplot command #+begin_src gnuplot :var d=block.dat :results silent plot $d u 2:3 ev :::0::0, u 2:3 ev :::1::1, u 2:3 ev :::2::2 #+end_src shows three separate lines of different colours as gnuplot recognises the datafile as blocked data. Also, the following command produces a surface plot #+begin_src gnuplot :var d=block.dat :results silent splot $d u 1:2:3 #+end_src However, if I put the same data in the table below #+tblname: data | 1 | 1 | 2 | | 1 | 2 | 5 | | 1 | 3 | 10 | | | || | 2 | 1 | 5 | | 2 | 2 | 8 | | 2 | 3 | 13 | | | || | 3 | 1 | 10 | | 3 | 2 | 13 | | 3 | 3 | 18 | and use the following plot command #+begin_src gnuplot :var d=data :results silent plot $d u 2:3 ev :::0::0, u 2:3 ev :::1::1, u 2:3 ev :::2::2 #+end_src the result is a plot of a single line of the same colour as gnuplot joins all of the points in the data file. This seems to be because org-mode exports the table as x y z 1 1 2 1 2 5 1 3 10 2 1 5 2 2 8 2 3 13 3 1 10 3 2 13 3 3 18 and gnuplot does not recognise this as a blocked data file because it contains no blank lines. The same problem occurs for #+begin_src gnuplot :var d=data :results silent splot $d u 1:2:3 #+end_src which does not produce a gridded surface plot. Thanks for your help, Paul
Re: [O] Rationale for *text* - \alert{text} for Beamer export?
Dnia 2013-05-01, o godz. 09:17:23
John Hendy jw.he...@gmail.com napisał(a):
Greetings,
Just wondering about the rationale behind using *bold* markup for
\textbf{} in LaTeX export and to \alert{} in Beamer. Was this a
frequently voiced request? I'm sure I can dig into this somewhere and
change it, but if the majority prefers bold (not saying they do!),
should that be the default?
I'd prefer bold, personally. I don't like red table column titles or
in lists.
Just my 2 cents:
* In general, you shouldn't use boldface in printed documents (unless
you have a good reason. A /very/ good, thought out reason. And
usually you haven't one;).).
* In presentations, things are indeed quite different.
* Keeping that in mind, \alert{...} is /better/ than \textbf{...}, just
like \emph{...} is better than \textit{...}: it is semantic, not
visual markup.
* If you do insist on boldface as alerting, just say
\setbeamerfont{alerted text}{series=\bfseries}
in your preamble. Keep in mind, however, that this will break things
if you use alert...{...}. Take this document, for instance:
\documentclass{beamer}
\begin{document}
\begin{frame}
This is \alert{alerted} text.
And this is \alert2{alerted} only on the second slide.
\end{frame}
\end{document}
In it, text will wobble when changing slides. This is ugly.
* So, what you probably want, is to say
\setbeamercolor{alerted text}{fg=red!50!black}
in your preamble, so \alert{...} means a color in the midpoint (in RGB
linear space) between red and black (you might want to experiment with
percentages other than 50% or wholly different colors, of course).
Thanks,
John
HTH,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
[O] Bug in structmode++?
Hi, Orgstruct minor mode is working with the mail-mode a little strange. If I write a simple list where every item is smaller than a line, I can use M-RET and a new item is inserted as expected. But if the item goes over one line, the second line is not indented and moreover M-RET does not work anymore. org-version: 8.0.2; emacs: 24.3.1 thanks in advance -- :: Igor Sosa Mayor :: joseleopoldo1...@gmail.com :: :: GnuPG: 0x1C1E2890 :: http://www.gnupg.org/ :: :: jabberid: rogorido ::::
[O] flet warning message
Hi, on loading org-mode I get this warning message: , | `flet' is an obsolete macro (as of 24.3); use either `cl-flet' or | `cl-letf' ` Is it important? -- :: Igor Sosa Mayor :: joseleopoldo1...@gmail.com :: :: GnuPG: 0x1C1E2890 :: http://www.gnupg.org/ :: :: jabberid: rogorido ::::
Re: [O] :session question
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: If you mean that there should be new syntax for setting header arguments on a file or sub-tree basis w/o using file local variables, I'd be happy to apply a patch. I'm thinking that something like #+PROPERTY: header-args:R :session *R* :exports none should work. I hate to change syntax, but the syntax you mention above does look both appealing and natural. Even with working file local variables [1]. I've checked that the property interface returns the data as expected, but I haven't implemented anything yet. It does not seem to be an overly difficult endeavour, however. That is very good news. With that portion working I would agree that this should be a fairly straightforward task. But importantly, there should be no way to set a default session name without also specifying the language, regardless of which way one tries to set this up. If you can think of a clean way to implement this then we should go for it. I doubt many existing configurations rely on this behavior. General settings for all languages should be effected by #+PROPERTY: header-args :results value :exports none and there'd be a list of header arguments (or specific values) that are either ignored or warned about when not associated with a particular language. BTW, I think the current property syntax for header arguments should be deprecated since it is the only place where the leading : is missing for those. Comments, thoughts? I think these are great ideas. Personally I'd love to see them implemented. Unfortunately I don't have time to work on an implementation currently. I'm surprised that none of the users who motivated this discussion have chimed in. Their opinions may be more valuable than my own in this regard (as I'm not a heavy #+Property user). Thanks for the clean and initially tested implementation idea! Regards, Achim. Footnotes: [1] Thanks to Bastien my patch allowing variables like `org-babel-default-header-args:R' to be set file-local has been applied to Emacs. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] flet warning message
Hi Igor, a quick grep in a current git-pull reveals a few matches for flet. However, they are all in modules from the contrib-directory and none within the core of org. I do not have much experience with the habits of emacs maintainers, but I think, that they wont drop the onsolete macro flet until Version 25 of emacs (at least). By that time all the modules from contrib will probably long be corrected :-) best regards, Marc Am 01.05.2013 17:04, schrieb Igor Sosa Mayor: Hi, on loading org-mode I get this warning message: , | `flet' is an obsolete macro (as of 24.3); use either `cl-flet' or | `cl-letf' ` Is it important?
Re: [O] [Bug] org-startup-with-inline-images
Rick Frankel r...@rickster.com writes: Hello Rick, `org-startup-with-inline-images' is a customizable variable. The problem is that if an org file is visited in a non-graphics buffer (or batch), `org-display-inline-images' is called an throws an error (Non-X frame used). This problem also occurs when e.g., `org-babel-after-execute-hook' is set to 'org-display-inline-images (which can be mitigated by not setting the hook in a non-x frame). Since the startup variable is a customization, and causes problems if not set programatically, IMHO, the best solution would be to wrap the `org-display-inline-images' function in a test so that is is a no-op on non graphic displays: (defun org-display-inline-images (optional include-linked refresh beg end) ... (interactive P) (when (display-graphic-p) [...]) Thanks for the report, I've attached a patch that fixes this problem (in both `org-display-inline-images' and `org-preview-latex-fragment'). However I don't know if it is the right approach or if I should try to narrow this to lower-level functions. I know that `clear-image-cache' raise this error but I haven't tried to see if it the only one. Should I try to look more at it and add a `org-clear-image-cache' which will check if a graphic display is available or is the current solution fine? Regards, From db2c62c07b9e1a61db4930fc8252b96f3d6bc0b8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com Date: Wed, 1 May 2013 19:19:57 +0200 Subject: [PATCH] lisp/org.el: Do not inline images when no graphic display is available * lisp/org.el (org-preview-latex-fragment) (org-display-inline-images): Detect whether a graphic display is available before inlining images to prevent an error. Thanks to Rick Frankel for the report and the solution. `org-startup-with-inline-images' is a customizable variable. The problem is that if an org file is visited in a non-graphics buffer (or batch), `org-display-inline-images' is called an throws an error (Non-X frame used). This problem also occurs when e.g., `org-babel-after-execute-hook' is set to 'org-display-inline-images (which can be mitigated by not setting the hook in a non-x frame). Since the startup variable is a customization, and causes problems if not set programatically, IMHO, the best solution would be to wrap the `org-display-inline-images' function in a test so that is is a no-op on non graphic displays: --- lisp/org.el | 158 ++- 1 file changed, 80 insertions(+), 78 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index d1c4c9a..ae0110f 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -18195,37 +18195,38 @@ The images can be removed again with \\[org-ctrl-c-ctrl-c]. (interactive P) (unless buffer-file-name (user-error Can't preview LaTeX fragment in a non-file buffer)) - (org-remove-latex-fragment-image-overlays) - (save-excursion -(save-restriction - (let (beg end at msg) - (cond - ((or (equal subtree '(16)) - (not (save-excursion - (re-search-backward org-outline-regexp-bol nil t - (setq beg (point-min) end (point-max) - msg Creating images for buffer...%s)) - ((equal subtree '(4)) - (org-back-to-heading) - (setq beg (point) end (org-end-of-subtree t) - msg Creating images for subtree...%s)) - (t - (if (setq at (org-inside-LaTeX-fragment-p)) - (goto-char (max (point-min) (- (cdr at) 2))) - (org-back-to-heading)) - (setq beg (point) end (progn (outline-next-heading) (point)) - msg (if at Creating image...%s - Creating images for entry...%s - (message msg ) - (narrow-to-region beg end) - (goto-char beg) - (org-format-latex - (concat org-latex-preview-ltxpng-directory (file-name-sans-extension - (file-name-nondirectory - buffer-file-name))) - default-directory 'overlays msg at 'forbuffer - org-latex-create-formula-image-program) - (message msg done. Use `C-c C-c' to remove images.) + (when (display-graphic-p) +(org-remove-latex-fragment-image-overlays) +(save-excursion + (save-restriction + (let (beg end at msg) + (cond + ((or (equal subtree '(16)) + (not (save-excursion + (re-search-backward org-outline-regexp-bol nil t + (setq beg (point-min) end (point-max) + msg Creating images for buffer...%s)) + ((equal subtree '(4)) + (org-back-to-heading) + (setq beg (point) end (org-end-of-subtree t) + msg Creating images for subtree...%s)) + (t + (if (setq at (org-inside-LaTeX-fragment-p)) + (goto-char (max (point-min) (- (cdr at) 2))) + (org-back-to-heading)) + (setq beg (point) end (progn (outline-next-heading) (point)) + msg (if at Creating image...%s + Creating images for entry...%s + (message msg ) + (narrow-to-region beg end) + (goto-char beg) + (org-format-latex + (concat org-latex-preview-ltxpng-directory
[O] [BUG] hline references on left side of table formula
Hi- I don't know if this is a bug or feature :), but if an hline reference (@I, etc) is used on the left side of a calculation, it applies to ALL columns in the row even if the column is specfied. Here are some examples to show the results. I would expect all three versions to generate the same results as the first example. #+BEGIN_ORG * Absolute reference (expected results) | a | b | |---+---| | x | 1 | | y | 2 | |---+---| | | 3 | #+TBLFM: @4$2=vsum(@I..@II) * hline reference | a | b | |---+---| | x | 1 | | y | 2 | |---+---| | x + y | 3 | #+TBLFM: @II$2=vsum(@I..@II) * hline reference with full cell specification in sum | a | b | |---+---| | x | 1 | | y | 2 | |---+---| | 3 | 3 | #+TBLFM: @II$2=vsum(@I$2..@II$2) #+END_ORG FWIW, I believe the problem is that `org-table-recalculate' is matching lhs cell references explicitly against pure numeric references (@[0-9]+$[0-9]+) and therefore expands the lhs via `org-expand-lhs-ranges' instead of expanding it with `org-table-get-descriptor-line' rick
Re: [O] :session question
Eric Schulte writes: #+PROPERTY: header-args:R :session *R* :exports none I hate to change syntax, but the syntax you mention above does look both appealing and natural. Even with working file local variables [1]. OK, so let's settle for this. I've checked that the property interface returns the data as expected, but I haven't implemented anything yet. It does not seem to be an overly difficult endeavour, however. That is very good news. With that portion working I would agree that this should be a fairly straightforward task. […] I think these are great ideas. Personally I'd love to see them implemented. Unfortunately I don't have time to work on an implementation currently. I'll try to get something working. Not immediately, but I'll see when I can shoe it in. I'm surprised that none of the users who motivated this discussion have chimed in. Their opinions may be more valuable than my own in this regard (as I'm not a heavy #+Property user). Well, feedback from users would of course be welcome, but I don't expect anything really until there's some working code to show. Thanks for the clean and initially tested implementation idea! Thanks for your comments. [1] Thanks to Bastien my patch allowing variables like `org-babel-default-header-args:R' to be set file-local has been applied to Emacs. … but it will only be available from 24.4 onward. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] flet warning message
Am Wed, May 01, 2013 at 07:22:27PM +0200, Marc Ihm wrote: [...] I do not have much experience with the habits of emacs maintainers, but I think, that they wont drop the onsolete macro flet until Version 25 of emacs (at least). By that time all the modules from contrib will probably long be corrected :-) thanks for the answer! -- :: Igor Sosa Mayor :: joseleopoldo1...@gmail.com :: :: GnuPG: 0x1C1E2890 :: http://www.gnupg.org/ :: :: jabberid: rogorido ::::
Re: [O] [Bug] org-startup-with-inline-images
On 01.05.2013 13:28, Daimrod wrote: Thanks for the report, I've attached a patch that fixes this problem (in both `org-display-inline-images' and `org-preview-latex-fragment'). However I don't know if it is the right approach or if I should try to narrow this to lower-level functions. I know that `clear-image-cache' raise this error but I haven't tried to see if it the only one. Should I try to look more at it and add a `org-clear-image-cache' which will check if a graphic display is available or is the current solution fine? Looks good. No, I tried narrowing it down myself and it breaks in amy other places in org-display-inline-images if you don't simply cond out the entire function. thanx, rick
Re: [O] worg-new-exporter successful publish locally
Achim Gratz writes: Achim Gratz writes: Something in cc-langs that doe not work correctly in batch mode, it fails to define or select the correct fontification function for gawk. In any case, it doesn't happen when you don't export in batch mode and Emacs 23 does not have that problem, interestingly enough… I've fixed this, not that I would know exactly how… :-) This is now reported as Emacs bug #14325. Apparently the workaround should be good until a better fix is found. If someone understands minor modes and font-lock in particular, then maybe Org could include some fixes for using font-lock in noninteractive application (aka batch mode). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
[O] odd behavior for begin_src org :results
Org-mode version 8.0.1 (release_8.0.1-42-g267cbe @ /Users/minshall/usr/share/emacs/site-lisp/org/) hi. the following produces #+RESULTS: #+begin_src org :results replace hello #+end_src but, repeated evaluations seem to grow the list of results. e.g., after four evaluations: #+RESULTS: hello hello hello hello the following does not produce #+RESULTS at all: #+begin_src org hello #+end_src is this intended behavior? the code thinks so; ob-org.el has: (defvar org-babel-default-header-args:org '((:results . raw silent) (:exports . code)) Default arguments for evaluating a org source block.) otoh, the manual thinks :results replace should be the default: * 'replace' The default value. Any existing results will be removed, and the new results will be inserted into the Org mode buffer in their place. E.g., ':results output replace'. cheers, Greg
Re: [O] odd behavior for begin_src org :results
Greg Minshall minsh...@umich.edu writes: Org-mode version 8.0.1 (release_8.0.1-42-g267cbe @ /Users/minshall/usr/share/emacs/site-lisp/org/) hi. the following produces #+RESULTS: #+begin_src org :results replace hello #+end_src but, repeated evaluations seem to grow the list of results. e.g., after four evaluations: #+RESULTS: hello hello hello hello Yes, this is the behavior of raw results. the following does not produce #+RESULTS at all: #+begin_src org hello #+end_src is this intended behavior? This is the intended behavior for Org-mode blocks, it is not the intended behavior in general. the code thinks so; ob-org.el has: (defvar org-babel-default-header-args:org '((:results . raw silent) (:exports . code)) Default arguments for evaluating a org source block.) otoh, the manual thinks :results replace should be the default: * 'replace' The default value. Any existing results will be removed, and the new results will be inserted into the Org mode buffer in their place. E.g., ':results output replace'. In this case the defaults for org-mode are different from the general cross-language defaults. As I recall, at the time that the defaults were set for Org-mode code blocks, we did not have options like drawers to allow replaceable raw results. Perhaps the default header arguments for Org-mode should be updated. Best, cheers, Greg -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [BUG] New exporter exports TOC twice
Hi Nicolas, On 28.4.2013, at 09:28, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: I am not saying multiple tocs should not be allowed. I am all for that. However, I think that by inserting a #+TOC line, the user indicates desire for local control. Therefore, org-export-with-toc should be ignored, and, by extension, also #+OPTIONS: toc (because this is really a local way to set org-export-with-toc). The problem is that #+TOC cannot be a strict equivalent to `org-export-with-toc', since the former cannot be introduced in the document template. I am not sure I understand. What do you mean? Also, this change would require each user back-end developer to check for the presence of a TOC keyword with headlines value in the parse tree when handling :with-toc property. This is not complicated, but there are already many uncomplicated issues to think about when writing a back-end. An alternative would be that the parser already makes this change. Upon finding #+TOC, it would change the OPTION value in the parse tree. In a nutshell, I don't think we should try to outsmart the user by ignoring his setup here. I suggest to improve the manual, if needed, instead. That is certainly an alternative, once I have understood the issues. Thanks for your patience. - Carsten
Re: [O] Mobileorg- Automatic pushing and pulling
On 28.4.2013, at 21:16, Marvin Doyley m.doy...@rochester.edu wrote: Thanks for the link everybody, here is what I end up doing, i.e., I added these to my .emacs file (which worked like a charm) (add-hook 'after-init-hook 'org-mobile-pull) (add-hook 'kill-emacs-hook 'org-mobile-push) Thanks for the summary and followup - note to everyone - this is always a good idea after a thread with multiple input. It improved the record created in the mailing list archives. Thanks - Carsten
Re: [O] Rationale for *text* - \alert{text} for Beamer export?
On Wed, May 1, 2013 at 10:00 AM, Marcin Borkowski mb...@wmi.amu.edu.pl wrote:
Dnia 2013-05-01, o godz. 09:17:23
John Hendy jw.he...@gmail.com napisał(a):
Greetings,
Just wondering about the rationale behind using *bold* markup for
\textbf{} in LaTeX export and to \alert{} in Beamer. Was this a
frequently voiced request? I'm sure I can dig into this somewhere and
change it, but if the majority prefers bold (not saying they do!),
should that be the default?
I'd prefer bold, personally. I don't like red table column titles or
in lists.
Just my 2 cents:
* In general, you shouldn't use boldface in printed documents (unless
you have a good reason. A /very/ good, thought out reason. And
usually you haven't one;).).
Do you have sources for this? I googled why you shouldn't use bold
and why you shouldn't use bold for papers and some others. I
couldn't find anyone making that case in the first two pages of hits.
I guess I expected that if this was common knowledge it wouldn't be
hard to find.
* In presentations, things are indeed quite different.
* Keeping that in mind, \alert{...} is /better/ than \textbf{...}, just
like \emph{...} is better than \textit{...}: it is semantic, not
visual markup.
Can you explain semantic vs. visual? As in you can more easily
customize the meaning of \alert{} or \emph{} whereas \textbf{} and
\textit{} only has one meaning? Sort of like using a css tag which can
be later customized vs. specifically calling out exactly what you're
thinking you want to do at the moment?
* If you do insist on boldface as alerting, just say
\setbeamerfont{alerted text}{series=\bfseries}
in your preamble. Keep in mind, however, that this will break things
if you use alert...{...}. Take this document, for instance:
\documentclass{beamer}
\begin{document}
\begin{frame}
This is \alert{alerted} text.
And this is \alert2{alerted} only on the second slide.
\end{frame}
\end{document}
In it, text will wobble when changing slides. This is ugly.
Sure, and understood. In general, I'm using *text* simply to call
attention to something important. I work in product development, so
something like:
Customer response to product sampling:
- *US:* blah blah blah
- *China:* blah blah blah
- *India: blah blah blah
Using *text* is simply to call attention to the fact that the *word:*
is an in-line header of sorts for what is to follow. Also, it lets
readers easily compare the bolded text and pick the bucket they care
to explore vs. having it blend in with the prose that follows.
Regardless of the opinions on bold vs. red text, I find bold (or
italics) are more conventional, whereas red conveys problem or
yikes and simply seems more counter-conventional, so I feel it
distracts more than a more typical typeface emphasis method.
In essence, I simply want to call attention to text, but not too much
and red stand out like a sore thumb, in my opinion, far more than bold
or italic. It's so dominant that it over-does it's job of emphasizing.
* So, what you probably want, is to say
\setbeamercolor{alerted text}{fg=red!50!black}
in your preamble, so \alert{...} means a color in the midpoint (in RGB
linear space) between red and black (you might want to experiment with
percentages other than 50% or wholly different colors, of course).
Thanks for letting me know how to tweak and mute down a bit. I can
play with that... though I probably just want *text* to equal bold, or
I'll decide to use /text/ instead.
John
Thanks,
John
HTH,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
Re: [O] Kill all items with specific tag to kill-ring.
On 29.4.2013, at 19:14, Oleksandr Gavenko gaven...@gmail.com wrote: On 2013-04-25, Bernt Hansen wrote: Oleksandr Gavenko gaven...@gmail.com writes: I want this feature in order to simplify precess of moving entries from job org-file to home org-file by marking entries with tag :HOME:... If all you want to do is move items why not use the agenda? Mark your entries with a tag, do an agenda search for that tag, mark all entries with m and move them using bulk refile with B r Great! I don't often use agenda so don't know about this feature. How can I select specific buffer/file (and only this buffer) for displaying/processing in agenda? You call the agenda from that buffer and press 1 or once after `C-c a' and before the agenda command key, for example C-c a m for a match view. - Carsten
Re: [O] [Taskjuggler] Status of exporter
Thank you for your work and this update, Christian! - Carsten On 29.4.2013, at 22:52, Christian Egli christian.e...@sbs.ch wrote: Hi all The Taskjuggler Exporter has seen some major updates. We finally have a nice out-of-the-box experience with tj3, so please give it a spin. What's new? Thanks to Nicolas Goaziou the exporter has been ported to the new export engine. On top of that I added some features that have been requested and there are some pending issues that I'd like to get fixed, see below: Changes ═══ Process and open Previously the exporter just exported a tjp file (at least for tj3). Now there is a new command to process the exported tjp file with tj3 and open the reports in a browser. Dependency resolution against plain IDs ─── There was some discussion on the list about dependency resolution. A good way to express dependencies is to use the org-id module. This is now supported in that it resolves dependencies not only against task_id but also against the ID of a task. Default reports can use document title ── John Hendy proposed to create a possibility to integrate the document title in the default reports. This is now possible by specifying a %title in the default reports. See the doc string of `org-taskjuggler-default-reports'. Use both scheduled and start to determine project start ─── John Hendy again reported an problem that the project start was not using the scheduled info. This is now fixed. Misc bug fixes ── Nicolas Goaziou fixed a number of bugs and typos in the code. Pending ═══ Change mapping of DEADLINE property ─── The DEADLINE property is currently mapped to the end attribute in the tjp export. The end attribute gives tj3 an indication as to when a task should end. Also it has some influence on the scheduling policy (ALAP) which might not be what the user expects. IMHO this is not exactly the semantics of the DEADLINE property. A better fit would be the maxend attribute. For that reason I'd like to propose a backward incompatible change to map the DEADLINE property to the maxend attribute. Patch by Baptiste ─ This patch fixes some problems with milestones. However it depends on above change. Add the text nodes as a note It would make sense to export the text content of a headline as a tj3 note. The new export engine should make this possible. -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
Re: [O] Rationale for *text* - \alert{text} for Beamer export?
Hi John,
Jumping in late here, with apologies if that's left me wide of the mark.
John Hendy jw.he...@gmail.com writes:
On Wed, May 1, 2013 at 10:00 AM, Marcin Borkowski mb...@wmi.amu.edu.pl
wrote:
Can you explain semantic vs. visual? As in you can more easily
customize the meaning of \alert{} or \emph{} whereas \textbf{} and
\textit{} only has one meaning? Sort of like using a css tag which can
be later customized vs. specifically calling out exactly what you're
thinking you want to do at the moment?
IMHO, the best discussion of this difference is the first chapter of
Lamport's LaTeX User's Guide and Manual. Here is the gist as I
understand it:
1) A principle of typesetting is that the layout of a document should
reflect its logical structure.
2) A computer typesetting program can achieve this if it knows what key
parts of the document mean.
3) So, markup should be semantic, rather than visual.
It is possible to achieve identical results using visual markup, of
course, but why not let the computer keep track of things instead?
Sure, and understood. In general, I'm using *text* simply to call
attention to something important. I work in product development, so
something like:
Customer response to product sampling:
- *US:* blah blah blah
- *China:* blah blah blah
- *India: blah blah blah
Here, to achieve semantic markup, you would use description lists
- US :: blah
- China :: blah
- India :: blah
The :: separator lets Org (and ultimately LaTeX) know that the part
before the separator is the term that is being described.
hth,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [PATCH] ox: Cache locations of fuzzy links
Hello, Lawrence Mitchell we...@gmx.li writes: * ox.el (org-export-resolve-fuzzy-link): Look for fuzzy link in a cache before trying to resolve it in the parse tree. Thanks for your patch. A few comments follow. - (if match-title-p (substring raw-path 1) raw-path + (if match-title-p (substring raw-path 1) raw-path))) + (link-cache (plist-get info :fuzzy-link-cache))) +;; Cache for locations of fuzzy links that are not position dependent +(unless link-cache + (setq info (plist-put info :fuzzy-link-cache + (make-hash-table :test 'equal))) + (setq link-cache (plist-get info :fuzzy-link-cache))) Minor nitpick: I'd rather have this included in the (let ...), like: (let (... (link-cache (or (plist-get info :fuzzy-link-cache) (plist-get (setq info (plist-put info :fuzzy-link-cache (make-hash-table :test 'eq))) :fuzzy-link-cache) -(org-element-map (plist-get info :parse-tree) 'target - (lambda (blob) -(and (equal (org-split-string (org-element-property :value blob)) -path) - blob)) - info t))) +(let ((found (gethash (cons 'path path) + link-cache + 'fuzzy-link-not-found))) + (or (not (eq found 'fuzzy-link-not-found)) + (puthash (cons 'path path) + (org-element-map (plist-get info :parse-tree) 'target + (lambda (blob) + (and (equal (org-split-string +(org-element-property :value blob)) + path) +blob)) + info t) + link-cache) I don't get why you need to use such a key. Simply use the link as key and `eq' as the test. Regards, -- Nicolas Goaziou
Re: [O] odd behavior for begin_src org :results
Eric, thanks for the answer. another #+begin_src org question. it appears that only *string* values are allowed for any :var that are defined (i.e., ':var bar=foo', and *not* ':var bar=3'). since i'm not 100% sure of the semantics, maybe this is desired. if one *should* be allowed to pass in, e.g., tables, numbers, etc., then maybe org-babel-expand-body:org in ob-org.el wants to change from the current (defun org-babel-expand-body:org (body params) (dolist (var (mapcar #'cdr (org-babel-get-header params :var))) (setq body (replace-regexp-in-string (regexp-quote (format $%s (car var))) (cdr var) body nil 'literal))) body) to something like this (defun org-babel-expand-body:org (body params) (dolist (var (mapcar #'cdr (org-babel-get-header params :var))) (setq body (replace-regexp-in-string (regexp-quote (format $%s (car var))) (if (stringp (cdr var)) (cdr var) (format %s (prin1 (cdr var body nil 'literal))) body) (as otherwise replace-regexp-in-string notices that (cdr var) is *not* a string, and attempts to execute it.) maybe^2 it would make even more sense to use the #+begin_src emacs-lisp equivalent routine from ob-emacs-lisp.el as a template? (defun org-babel-expand-body:emacs-lisp (body params) Expand BODY according to PARAMS, return the expanded body. (let* ((vars (mapcar #'cdr (org-babel-get-header params :var))) (result-params (cdr (assoc :result-params params))) (print-level nil) (print-length nil) (body (if ( (length vars) 0) (concat (let ( (mapconcat (lambda (var) (format %S (print `(,(car var) ',(cdr var) vars \n ) )\n body \n)) (concat body \n (if (or (member code result-params) (member pp result-params)) (concat (pp body )) body))) (my elisp isn't strong enough to evaluate this.) cheers, Greg
Re: [O] [BUG] New exporter exports TOC twice
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
The problem is that #+TOC cannot be a strict equivalent to
`org-export-with-toc', since the former cannot be introduced in the
document template.
I am not sure I understand. What do you mean?
A TOC keyword belongs to the contents of the document. On the other
hand, :with-toc is handled in a template function, which has access to
both the contents and the meta-data around it. Therefore, :with-toc can
insert a table of contents in more places than TOC.
For example, in latex back-end, TOC cannot insert a \tableofcontents
before \begin{document}, but toc:t can. Of course, this example doesn't
make sense as per LaTeX syntax, but it is possible that some other
back-end wants to allow this.
Also, this change would require each user back-end developer to check
for the presence of a TOC keyword with headlines value in the parse
tree when handling :with-toc property. This is not complicated, but
there are already many uncomplicated issues to think about when writing
a back-end.
An alternative would be that the parser already makes this change. Upon
finding #+TOC, it would change the OPTION value in the parse tree.
The parser doesn't handle the OPTION keyword (it's just another
keyword), and neither should it (export options mustn't influence how
the parsing is done).
It belongs to the export framework to read export options and handle
them. Upon reading the with-toc value, it is indeed possible to check
for the presence of a TOC keyword in the parse tree.
However, in this case, I don't see the need to go out of our way just to
interpret differently what the user specified. Getting two tables of
contents is not surprising when you understand that toc:t and #+TOC:
headlines are independent ways of requesting a table of contents.
Regards,
--
Nicolas Goaziou
Re: [O] Rationale for *text* - \alert{text} for Beamer export?
Dnia 2013-05-01, o godz. 11:41:49
t...@tsdye.com (Thomas S. Dye) napisał(a):
Hi John,
Jumping in late here, with apologies if that's left me wide of the
mark.
John Hendy jw.he...@gmail.com writes:
On Wed, May 1, 2013 at 10:00 AM, Marcin Borkowski
mb...@wmi.amu.edu.pl wrote:
Can you explain semantic vs. visual? As in you can more easily
customize the meaning of \alert{} or \emph{} whereas \textbf{} and
\textit{} only has one meaning? Sort of like using a css tag which
can be later customized vs. specifically calling out exactly what
you're thinking you want to do at the moment?
IMHO, the best discussion of this difference is the first chapter of
Lamport's LaTeX User's Guide and Manual. Here is the gist as I
understand it:
1) A principle of typesetting is that the layout of a document should
reflect its logical structure.
2) A computer typesetting program can achieve this if it knows what
key parts of the document mean.
3) So, markup should be semantic, rather than visual.
It is possible to achieve identical results using visual markup, of
course, but why not let the computer keep track of things instead?
+1
Notice also that even LaTeX breaks the rule of use only semantic
markup in the document (and in fact, there are cases when the rule is
a bit fuzzy anyway). Finding examples of /visual/ markup in LaTeX
(without semantic counterparts) are left as an exercise for the
reader;).
(Hint: rahzrengvbaf fglyrf qrcraq abg ba gur punenpgre bs gur
rahzrengvba, ohg ba vgf qrcgu, naq jvgubhg cnpxntrf yvxr rahzvgrz vg'f
abg rnfl gb qrsvar lbhe bja rahzrengvba fglyrf.)
Sure, and understood. In general, I'm using *text* simply to call
attention to something important. I work in product development, so
something like:
Customer response to product sampling:
- *US:* blah blah blah
- *China:* blah blah blah
- *India: blah blah blah
Here, to achieve semantic markup, you would use description lists
- US :: blah
- China :: blah
- India :: blah
The :: separator lets Org (and ultimately LaTeX) know that the part
before the separator is the term that is being described.
And then use the enumitem package to customize the exact look of the
description environment.
hth,
Tom
Regards,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
[O] Fw: Rationale for *text* - \alert{text} for Beamer export?
I accidentally responded in private, so for completeness I forward this
to the list.
Początek przekazywanej wiadomości:
Data: Thu, 2 May 2013 00:00:05 +0200
Od: Marcin Borkowski mb...@wmi.amu.edu.pl
Do: John Hendy jw.he...@gmail.com
Temat: Re: [O] Rationale for *text* - \alert{text} for Beamer export?
Dnia 2013-05-01, o godz. 15:50:13
John Hendy jw.he...@gmail.com napisał(a):
On Wed, May 1, 2013 at 10:00 AM, Marcin Borkowski
mb...@wmi.amu.edu.pl wrote:
Dnia 2013-05-01, o godz. 09:17:23
John Hendy jw.he...@gmail.com napisał(a):
Greetings,
Just wondering about the rationale behind using *bold* markup for
\textbf{} in LaTeX export and to \alert{} in Beamer. Was this a
frequently voiced request? I'm sure I can dig into this somewhere
and change it, but if the majority prefers bold (not saying they
do!), should that be the default?
I'd prefer bold, personally. I don't like red table column titles
or in lists.
One more thing: /if/ we map *...* to \textbf{...}, then /what/ should
we map to \alert{...}? This seems to me the best answer to your
primary question (about the rationale) - especially given the fact that
boldface should generally be avoided (see below).
Just my 2 cents:
* In general, you shouldn't use boldface in printed documents
(unless you have a good reason. A /very/ good, thought out
reason. And usually you haven't one;).).
Do you have sources for this? I googled why you shouldn't use bold
and why you shouldn't use bold for papers and some others. I
couldn't find anyone making that case in the first two pages of hits.
I guess I expected that if this was common knowledge it wouldn't be
hard to find.
Sorry for a bit fuzzy references - I have only Polish translations of
the following books, so I can't refer by page number nor give exact
quotes. If you don't find them, write me - I'll try to translate the
relevant (short) parts to English;).
* Jost Hochuli, Das Detail in der Typografie (section on emphasis)
* Robert Bringhurst, The Elements of Typographic Style (paragraph
6.5.3)
* Michael Mitchell, Susan Wightman, Book Typography. A Designer's
Manual (chapter III, section on boldface)
* This answer: http://stackoverflow.com/a/1936910/1181665 contains the
crucial distinction: em is for making something stand out
when /reading/, strong is for making something stand out
when /skimming/.
* In presentations, things are indeed quite different.
* Keeping that in mind, \alert{...} is /better/ than \textbf{...},
just like \emph{...} is better than \textit{...}: it is semantic,
not visual markup.
Can you explain semantic vs. visual? As in you can more easily
customize the meaning of \alert{} or \emph{} whereas \textbf{} and
\textit{} only has one meaning? Sort of like using a css tag which can
be later customized vs. specifically calling out exactly what you're
thinking you want to do at the moment?
\textit{} and \textbf{} are visual in the sense that they say this
should look like that. \emph{} and \alert{} are semantic in the sense
that they say this is important, and it is the designer (not the
author) who should decide how to actually render it. Usually, \emph{}
is italics and \alert{} (in beamer, there's no \alert in standard
LaTeX) is red (or other color, depending on the theme). But one might
argue for e.g. another color for \emph{}, or another background (and
not foreground!) for \alert{} etc. Even in standard LaTeX, \emph{}
is /not always/ italics: for instance, you can try \emph{emphasis
\emph{within} emphasized text}! Your comparison to css tags seems to
be very good to me.
Another good example of semantic markup is \email{...} (and not
\texttt{...}) for email addresses: usually, you can just say
\newcommand{\email}[1]{\texttt{#1}}, so they are effectively the same,
but then you have many benefits with semantic markup. One of them
becomes obvious when you realize that you might want to use \texttt for
e.g. both emails and web addresses in a printed document, but when you
later decide to prepare an electronic version, these two groups should
(obviously) behave differently. If you don't markup them using
different macros (or tags in XML/HTML/whateverML parlance), you have
a problem then.
* If you do insist on boldface as alerting, just say
\setbeamerfont{alerted text}{series=\bfseries}
in your preamble. Keep in mind, however, that this will break
things if you use alert...{...}. Take this document, for
instance:
\documentclass{beamer}
\begin{document}
\begin{frame}
This is \alert{alerted} text.
And this is \alert2{alerted} only on the second slide.
\end{frame}
\end{document}
In it, text will wobble when changing slides. This is ugly.
Sure, and understood. In general, I'm using *text* simply to call
attention to something important. I work in product development, so
something like:
Obvious - many things depend on use cases, I use \alert... from time
Re: [O] M-RET slow
Hi Bastien, On 4/27/13, Bastien b...@altern.org wrote: Samuel Wales samolog...@gmail.com writes: If I run it using M-:, it is fast. If I run it using a key binding, it is a bit slow (about 1s). Then this is about `org-meta-return', not `org-insert-heading'. What is the value of `org-catch-invisible-edits' in your config? It's about the same speed with 'smart (what I had) and nil (what I have now). Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
[O] Is it possible to create links to M-x occur results?
Howdy Org-folks, Something that I've found myself wishing for time and time again is to be able to follow the link to a file and immediately pop into a set of M-x occur results given some search term for that file. That way I could link to an overview of a file's class/function definitions, or config stanzas, or other useful things. Given that we can create links to arbitrary elisp, I am sure that this can be done in principle, but if there's a quick recipe that someone has come up with, I'd love to hear about it! --Leo
Re: [O] how to best make characters invisible in a org-derived mode
Hi Andreas, Hi John Thank both of you for trying to get me on track. On 2013-05-01 16:43, Andreas Röhler wrote: maybe have a look how ar-hide-bracketed-in-line-atpt for example is implemented. I can't actually find this function, but I get the general point from the files in Emacs Werkstatt. What tripped me up originally that simply setting a region to 'invisible worked in fundamental mode, but not in org-mode. I found the solution after I finally understood what (info (elisp) Invisible Text) was trying to tell me: - first set the desired region(s) to an arbitrary symbol, like my-symbol: (overlay-put (make-overlay beginning end) 'invisible 'my-symbol) - next add this symbol to 'invisibility' spec : (add-to-invisibility-spec 'my-symbol) After straighting this out I am now a happy camper, enjoying my uncluttered display. All the best, Christian -- Christian Wittern, Kyoto
[O] [html] centering
Has there been a recent change in HTML centering? We get this now: div class=center This does not work in browsers that do not support CSS. Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it.
[O] section subtitle in latex export
Hi all,
I am currently writing a journal thesis in org-mode and exporting it
to a LaTeX file. It worked well until recently I have updated the
org-mode version
to the latest one.
My problem is that the specified class file for the journal fails to
interpret the subtitle
of the sectioning command e.g.) \section[subtitle]{title} . Is it
possible to turn off that subtitle?
I looked into the source code of ox-latex.el but org-latex-section tells
nothing about it.
I have also checked org-latex-classes but curiously
the sectioning format is just \\section{%s} and so on. no subtitle.
org-mode version is the latest devel in the git repository, after 8.0.2,
git commit hash is 00badf1
and the emacs version is 23.3.1
--
Masataro Asai
Department of General Systems Studies
Graduate School of Arts and Sciences, The University of Tokyo
Tel: (81)-44-856-9009
Twitter/github id: guicho271828
Re: [O] Rationale for *text* - \alert{text} for Beamer export?
John Hendy jw.hendy at gmail.com writes:
Just wondering about the rationale behind using *bold* markup for
\textbf{} in LaTeX export and to \alert{} in Beamer. Was this a
frequently voiced request? I'm sure I can dig into this somewhere and
change it, but if the majority prefers bold (not saying they do!),
should that be the default?
I'd prefer bold, personally. I don't like red table column titles or in
lists.
I had asked the same question a while back, and I received some quite
amusing replies about \alert being the Beamer way... which I
promptly ignored and implemented my own hack to customize the LaTeX
command for beamer to use for *bold text* (pasted as a git patch
below).
I'm reading Marcin's recommendations carefully, since now, for the
first time, I need to learn more about tweaking LaTeX's output. I'm
not sure I agree with all of that line of thought, though.
~~
* Keeping that in mind, \alert{...} is /better/ than \textbf{...}, just
like \emph{...} is better than \textit{...}: it is semantic, not
visual markup.
~~
I can understand this rationale if the use case is to export from org
to a LaTeX file, and then continue to work with the LaTeX file. In
that case, you would want the exported LaTeX code to follow best
practices and be maintainable. I'd guess a more common use case for
org export is to work exclusively with the org markup, and allow the
exporter to use LaTeX as an intermediary, on the way to PDF. At least,
this is how *I* use it; it doesn't really bother me if the LaTeX code
produced by org uses semantic or visual markup. Where I need semantic
markup (and I will, in my next article), I'll write the semantic
markup in org.
I guess I look at this in a way that FAUST [1] uses c++ as an
intermediary. You write the signal-processing graph in FAUST's own
purely-functional language, which the FAUST compiler translates into
c++ (with a variety of headers and wrappers for VST, OSX audio units,
SuperCollider plug-ins etc.). The resulting c++ is a mess, from the
standpoint of reading and maintenance, but you're not supposed to
maintain that code by hand. You're supposed to go back to the FAUST
code to make changes.
org -- LaTeX -- PDF
FAUST -- c++ -- DSP plugin
But, going a step further, if semantic markup is what you need,
wouldn't it be better to define a \newcommand wrapper for \textbf, and
then tell org to export *bold* using the wrapper? That would assume
that you can customize the string org uses for *bold*, which you can't
at present... so maybe my hack has some use after all.
hjh
[1] Functional AUdio STream language: http://faust.grame.fr/
From 8ccbc7cad43b520067b8b29d4660fc99587995fd Mon Sep 17 00:00:00 2001
From: James Harkins jamshar...@dewdrop-world.net
Date: Thu, 21 Feb 2013 09:51:02 +0800
Subject: [PATCH] hjh temp: add customize variable for bold/alert style
---
lisp/ox-beamer.el |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index dc427de..44c1c68 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -206,6 +206,12 @@ You might want to put e.g. \allowframebreaks=0.9\
here.
:group 'org-export-beamer
:type '(string :tag Outline frame options))
+(defcustom org-beamer-bold-macro alert
+ LaTeX macro to insert for bold text (delimited by asterisks in the org
source file).
+The default \alert\ renders as red text, normal weight.
+Substitute \textbf\ to obtain boldface.
+ :group 'org-export-beamer
+ :type '(string :tag Bold macro))
;;; Internal Variables
@@ -334,7 +340,8 @@ Return overlay specification, as a string, or nil.
Transcode BLOCK object into Beamer code.
CONTENTS is the text being bold. INFO is a plist used as
a communication channel.
- (format \\alert%s{%s}
+ (format \\%s%s{%s}
+ org-beamer-bold-macro
(or (org-beamer--element-has-overlay-p bold) )
contents))
--
1.7.9.5
Re: [O] [BUG] New exporter exports TOC twice
Hi Nicolas,
On 2.5.2013, at 00:08, Nicolas Goaziou n.goaz...@gmail.com wrote:
Hello,
Carsten Dominik carsten.domi...@gmail.com writes:
The problem is that #+TOC cannot be a strict equivalent to
`org-export-with-toc', since the former cannot be introduced in the
document template.
I am not sure I understand. What do you mean?
A TOC keyword belongs to the contents of the document. On the other
hand, :with-toc is handled in a template function, which has access to
both the contents and the meta-data around it. Therefore, :with-toc can
insert a table of contents in more places than TOC.
For example, in latex back-end, TOC cannot insert a \tableofcontents
before \begin{document}, but toc:t can. Of course, this example doesn't
make sense as per LaTeX syntax, but it is possible that some other
back-end wants to allow this.
OK.
Also, this change would require each user back-end developer to check
for the presence of a TOC keyword with headlines value in the parse
tree when handling :with-toc property. This is not complicated, but
there are already many uncomplicated issues to think about when writing
a back-end.
An alternative would be that the parser already makes this change. Upon
finding #+TOC, it would change the OPTION value in the parse tree.
The parser doesn't handle the OPTION keyword (it's just another
keyword), and neither should it (export options mustn't influence how
the parsing is done).
It belongs to the export framework to read export options and handle
them. Upon reading the with-toc value, it is indeed possible to check
for the presence of a TOC keyword in the parse tree.
However, in this case, I don't see the need to go out of our way just to
interpret differently what the user specified. Getting two tables of
contents is not surprising when you understand that toc:t and #+TOC:
headlines are independent ways of requesting a table of contents.
This is clear enough. I have pushed a fix to the manual which should
make this clearer.
Regards
- Carsten
Re: [O] section subtitle in latex export
Reply to myself:
I edebugged the ox-latex and studied what's happening.
Who wrote this code? you shouldn't do things like this...
The code is overwriting the defcustom'ed sectioning format, no one knows.
the best answer for this problem would be changing the structure of
org-latex-classes but I dont want to do that right now.
so I just gave an option for alternative-heading.
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 2a315ef..95e96f0 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -303,6 +303,12 @@ a format string in which the section title will be
added.
(string :tag Closing (unnumbered)))
(function :tag Hook computing sectioning))
+(defcustom org-latex-alternative-section-title-enabled t
+ Output alternative section title such as
+\\section[short title]{Long long very long title}.
+ :group 'org-export-latex
+ :type 'boolean)
+
(defcustom org-latex-inputenc-alist nil
Alist of inputenc coding system names, and what should really be used.
For example, adding an entry
@@ -1442,7 +1448,7 @@ holding contextual information.
(org-export-data
(org-export-get-alt-title headline info) info)
(and (eq (plist-get info :with-tags) t) tags
- (if (and numberedp opt-title
+ (if (and numberedp opt-title
org-latex-alternative-section-title-enabled
(string-match \\`\\(.*?[^*]\\){ section-fmt))
(format (replace-match \\1[%s] nil nil section-fmt 1)
;; Replace square brackets with parenthesis
On 2013年05月02日 10:49, Masataro Asai wrote:
Hi all,
I am currently writing a journal thesis in org-mode and exporting it
to a LaTeX file. It worked well until recently I have updated the
org-mode version
to the latest one.
My problem is that the specified class file for the journal fails to
interpret the subtitle
of the sectioning command e.g.) \section[subtitle]{title} . Is it
possible to turn off that subtitle?
I looked into the source code of ox-latex.el but org-latex-section tells
nothing about it.
I have also checked org-latex-classes but curiously
the sectioning format is just \\section{%s} and so on. no subtitle.
org-mode version is the latest devel in the git repository, after 8.0.2,
git commit hash is 00badf1
and the emacs version is 23.3.1
--
Masataro Asai
Department of General Systems Studies
Graduate School of Arts and Sciences, The University of Tokyo
Tel: (81)-44-856-9009
Twitter/github id: guicho271828
Re: [O] section subtitle in latex export
Hi Masataro,
I agree that it is weird for org to insert the alternate header when it
is identical to the regular header. I think it is unnecessary
complication to introduce a new option to control this, though – it can
be automatic. Try the patch attached to this email. It simply avoids
inserting the alternate heading whenever it is identical to the standard
one.
(Nicolas, I’m waiting to see if you have any thoughts before pushing
this patch to the org repo.)
2013ko maiatzak 1an, Masataro Asai-ek idatzi zuen:
[...]
@@ -1442,7 +1448,7 @@ holding contextual information.
(org-export-data
(org-export-get-alt-title headline info) info)
(and (eq (plist-get info :with-tags) t) tags
- (if (and numberedp opt-title
+ (if (and numberedp opt-title
org-latex-alternative-section-title-enabled
It looks like your patch got line-wrapped here. Better to send patches
as attachments to avoid this.
From f84800fb82d432112a06918bbe389a00968773bc Mon Sep 17 00:00:00 2001
From: Aaron Ecay aarone...@gmail.com
Date: Thu, 2 May 2013 00:36:44 -0400
Subject: [PATCH] =?UTF-8?q?ox-latex.el=20(org-latex-headline):=20Don?=
=?UTF-8?q?=E2=80=99t=20insert=20alternate=20title=20if=20identical=20to?=
=?UTF-8?q?=20regular=20one?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/ox-latex.el (org-latex-headline): Don’t insert alternate title if
identical to regular one.
---
lisp/ox-latex.el | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 2a315ef..66eefa1 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1435,7 +1435,8 @@ holding contextual information.
(format \nend{%s} (if numberedp 'enumerate 'itemize))
low-level-body)))
;; This is a standard headline. Export it as a section. Add
- ;; an alternative heading when possible.
+ ;; an alternative heading when possible, and when this is not
+ ;; identical to the usual heading.
(let ((opt-title
(funcall org-latex-format-headline-function
todo todo-type priority
@@ -1443,6 +1444,7 @@ holding contextual information.
(org-export-get-alt-title headline info) info)
(and (eq (plist-get info :with-tags) t) tags
(if (and numberedp opt-title
+ (not (equal opt-title full-text))
(string-match \\`\\(.*?[^*]\\){ section-fmt))
(format (replace-match \\1[%s] nil nil section-fmt 1)
;; Replace square brackets with parenthesis
--
1.8.2.2
--
Aaron Ecay
Re: [O] how to best make characters invisible in a org-derived mode
Am 02.05.2013 00:58, schrieb Christian Wittern: Hi Andreas, Hi John Thank both of you for trying to get me on track. On 2013-05-01 16:43, Andreas Röhler wrote: maybe have a look how ar-hide-bracketed-in-line-atpt for example is implemented. I can't actually find this function, but I get the general point from the files in Emacs Werkstatt. What tripped me up originally that simply setting a region to 'invisible worked in fundamental mode, but not in org-mode. I found the solution after I finally understood what (info (elisp) Invisible Text) was trying to tell me: - first set the desired region(s) to an arbitrary symbol, like my-symbol: (overlay-put (make-overlay beginning end) 'invisible 'my-symbol) - next add this symbol to 'invisibility' spec : (add-to-invisibility-spec 'my-symbol) After straighting this out I am now a happy camper, enjoying my uncluttered display. All the best, Christian ar-hide-bracketed-in-line-atpt seems vanished indeed, something got broken. Thanks pointing at. Andreas
