Re: [O] Number formatting in tables for LaTeX export

2013-05-01 Thread Nicolas Goaziou
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

2013-05-01 Thread Andreas Röhler

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

2013-05-01 Thread Michael Alan Dorman
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

2013-05-01 Thread Michael Alan Dorman
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

2013-05-01 Thread Greg Minshall
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

2013-05-01 Thread Puneeth Chaganti
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

2013-05-01 Thread Greg Minshall
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

2013-05-01 Thread Sebastien Vauban
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

2013-05-01 Thread Rick Frankel
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

2013-05-01 Thread Lawrence Mitchell
* 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?

2013-05-01 Thread Eric S Fraga
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?

2013-05-01 Thread John Hendy
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

2013-05-01 Thread Paul Stansell
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?

2013-05-01 Thread Marcin Borkowski
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++?

2013-05-01 Thread Igor Sosa Mayor
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

2013-05-01 Thread 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?


-- 
:: Igor Sosa Mayor :: joseleopoldo1...@gmail.com ::
:: GnuPG: 0x1C1E2890   :: http://www.gnupg.org/  ::
:: jabberid: rogorido  ::::



Re: [O] :session question

2013-05-01 Thread Eric Schulte
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

2013-05-01 Thread Marc Ihm

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

2013-05-01 Thread Daimrod
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

2013-05-01 Thread Rick Frankel

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

2013-05-01 Thread Achim Gratz
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

2013-05-01 Thread Igor Sosa Mayor
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

2013-05-01 Thread Rick Frankel

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

2013-05-01 Thread Achim Gratz
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

2013-05-01 Thread Greg Minshall
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

2013-05-01 Thread Eric Schulte
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

2013-05-01 Thread Carsten Dominik
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

2013-05-01 Thread Carsten Dominik

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?

2013-05-01 Thread John Hendy
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.

2013-05-01 Thread Carsten Dominik

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

2013-05-01 Thread Carsten Dominik
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?

2013-05-01 Thread Thomas S. Dye
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

2013-05-01 Thread Nicolas Goaziou
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

2013-05-01 Thread Greg Minshall
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

2013-05-01 Thread Nicolas Goaziou
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?

2013-05-01 Thread Marcin Borkowski
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?

2013-05-01 Thread Marcin Borkowski
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

2013-05-01 Thread Samuel Wales
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?

2013-05-01 Thread Leo Alekseyev
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

2013-05-01 Thread 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



--
Christian Wittern, Kyoto




[O] [html] centering

2013-05-01 Thread Samuel Wales
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

2013-05-01 Thread Masataro Asai
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?

2013-05-01 Thread James Harkins
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

2013-05-01 Thread Carsten Dominik
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

2013-05-01 Thread Masataro Asai
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

2013-05-01 Thread Aaron Ecay
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

2013-05-01 Thread Andreas Röhler

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