[O] PATCH: Document how to scroll calendar by one year at date prompt. (was: Re: Bug: Missing command description in org-mode manual)

[Gregor Zattler]

Hi Jens, org-mode developers,
* Haustedt, Jens  [19. Mar. 2015]:
> in the description of the date/time prompt, a section describes the
> control of the calendar from the minibuffer.
> 
> There, a description of scrolling the calendar by 1 year is missing. The
> keyboard shortcut is M-S-/ and works perfectly.

The following patch adds this info to the manual.  It also
justifies the lines to look prettier in info.

Gregor


---
 doc/org.texi | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 6d25df1..49bc562 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -6136,13 +6136,14 @@ from the minibuffer:
 @kindex M-S-@key{left}
 @kindex @key{RET}
 @example
-@key{RET}   @r{Choose date at cursor in calendar.}
-mouse-1@r{Select date by clicking on it.}
-S-@key{right}/@key{left} @r{One day forward/backward.}
-S-@key{down}/@key{up} @r{One week forward/backward.}
-M-S-@key{right}/@key{left}   @r{One month forward/backward.}
-> / <  @r{Scroll calendar forward/backward by one month.}
-M-v / C-v  @r{Scroll calendar forward/backward by 3 months.}
+@key{RET}  @r{Choose date at cursor in calendar.}
+mouse-1@r{Select date by clicking on it.}
+S-@key{right}/@key{left}   @r{One day forward/backward.}
+S-@key{down}/@key{up}  @r{One week forward/backward.}
+M-S-@key{right}/@key{left} @r{One month forward/backward.}
+> / <  @r{Scroll calendar forward/backward by one month.}
+M-v / C-v  @r{Scroll calendar forward/backward by 3 months.}
+M-S-@key{down}/@key{up}@r{Scroll calendar forward/backward by one year.}
 @end example
 
 @vindex org-read-date-display-live
-- 
2.1.4


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

[O] comment section with latex_header

[Andreas Leha]

Hi all,

If there are `#+latex_header:' entries in a section and that section is
`COMMENT'ed out, I'd expect the #+latex_header entries to be
uneffective.  As they are when I comment them out one by one as in
`# #+latex_header:'.

Is this a bug? (I'd say, yes)

Regards,
Andreas


PS:

ECM

--8<---cut here---start->8---
* Test
test
* COMMENT LaTeX setup
#+latex_header: \usepackage{foo}
--8<---cut here---end--->8---



LaTeX export:

--8<---cut here---start->8---
% Created 2015-03-22 Sun 10:56
\documentclass[11pt]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
% ... 
\usepackage{foo}
% ...
\begin{document}

\tableofcontents

\section{Test}
\label{sec-1}
test
% Emacs 24.4.50.1 (Org mode 8.3beta)
\end{document}
--8<---cut here---end--->8---

Re: [O] comment section with latex_header

[Rasmus]

Andreas Leha  writes:

> Hi all,
>
> If there are `#+latex_header:' entries in a section and that section is
> `COMMENT'ed out, I'd expect the #+latex_header entries to be
> uneffective.  As they are when I comment them out one by one as in
> `# #+latex_header:'.
>
> Is this a bug? (I'd say, yes)

Why?  I guess you can still archive 
-- 
To err is human. To screw up 10⁶ times per second, you need a computer

Re: [O] [PATCH] Re: autoloads not working correctly for org-table.el?

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Eric Abrahamsen  writes:
>
>> If we really want to get all the message-specific stuff refactored into
>> orgstruct++ mode, I guess we could (in the `orgstruct++-mode' function)
>> bind `normal-auto-fill-function' and `adaptive-fill-function' to new
>> functions, which first check for message-mode specific stuff (and any
>> other modes that need to be handled),then delegate to
>> `org-auto-fill-function' and `org-adaptive-fill-function'.
>
> Indeed. There's also `org-fill-paragraph' to purge from Message mode
> stuff.
>
> Ultimately, Orgstruct minor mode could be moved into its own library,
> e.g., "org-struct.el".
>
>> Actually, all `org-auto-fill-function' does is conditionally call
>> `org-adaptive-fill-function', so maybe we could just have one new
>> function, `orgstruct++-auto-fill-function', that does everything.
>
> Probably, yes.
>
>> How does that sound?
>
> It sounds good.

Okay, here's my first attempt at this.

So far as I can tell, it works. By which I mean "it works, but I don't
understand why". I don't have any experience twiddling with the filling
mechanism, and I found it very baffling, but in all my tests so far this
patch does what it is supposed to.

Likely areas of ugliness:

1. I haven't succeeded in merging `orgstruct-auto-fill-function' with
   `orgstruct-adaptive-fill-function', mostly because I don't really
   understand what "adaptive fill" actually means.
2. I have overridden the `org-element-paragraph-separate' altogether,
   rather than adding message-mode stuff to it. And yet, it works okay,
   to wit: the plain list I'm currently typing.
   3. There's almost certainly refactoring that could be done.

Oops, it doesn't work okay after all -- when I hit RET at the end of the
third list item, it indented itself.

So obviously this isn't quite there yet. I'll keep working at it, which
means actually learning how filling works. In the meantime, any code
comments would be appreciated.

Eric

>From c93dc652d998978a070d7ea39bbd5ee14041f531 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Wed, 11 Mar 2015 18:48:52 +0800
Subject: [PATCH] First stab at independent orgstruct mode

---
 lisp/org-element.el |   2 +
 lisp/org-struct.el  | 364 ++
 lisp/org.el | 632 ++--
 3 files changed, 531 insertions(+), 467 deletions(-)
 create mode 100644 lisp/org-struct.el

diff --git a/lisp/org-element.el b/lisp/org-element.el
index b0e4e5c..8c95bcc 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4856,6 +4856,8 @@ This function assumes `org-element--cache' is a valid AVL tree."
 
  Tools
 
+(defvar orgstruct-mode nil)
+
 (defsubst org-element--cache-active-p ()
   "Non-nil when cache is active in current buffer."
   (and org-element-use-cache
diff --git a/lisp/org-struct.el b/lisp/org-struct.el
new file mode 100644
index 000..3acfbc0
--- /dev/null
+++ b/lisp/org-struct.el
@@ -0,0 +1,364 @@
+;;; org-struct.el --- Org-style editing in non-Org buffers  -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2015 Free Software Foundation, Inc.
+
+;; Author: Carsten Dominik 
+;; Keywords: outlines
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see .
+
+;;; Commentary:
+
+;; This file provides two minor modes for using Org-style editing
+;; commands in buffers that aren't in Org mode. The first mode,
+;; orgstruct-mode, defines key-bindings for structural editing
+;; commands like inserting headings and manipulating list items. The
+;; second minor mode, orgstruct++-mode, builds on the first, adding
+;; functions to handle filling and indentation.
+
+;; The basic orgstruct-mode is a bit of a hack: it hijacks all the
+;; keys it needs for structure editing, and wraps them in a function
+;; (`orgstruct-make-binding') that checks the context around point.
+;; If the text around point looks like Org text, the relevant Org
+;; command is run.  If it doesn't, the function checks to see if the
+;; currently-active major or minor modes have commands bound to those
+;; keys, and, if so, calls those commands.
+
+;; The second minor mode, orgstruct++, special-cases various major
+;; modes, such as message-mode, to make sure that Org text structures
+;; are filled and indented properly.
+
+;; in orgstruct++ mode, we need to set custom values for
+;; indent-line-function, adaptive-fill-function,
+;; 

[O] replace letf with cl-letf in org-mime

[Eric Abrahamsen]

It's amazing what an effect barky compiler errors can have.

E

>From 0bba16a7419d32ecc25ccdf422c9d0e129d0b547 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Sun, 22 Mar 2015 21:39:57 +0800
Subject: [PATCH] Use `cl-flet' rather than plain `flet'

* contrib/lisp/org-mime.el (org-mime-send-subtree, org-mime-compose):
  The compiler complains otherwise.
---
 contrib/lisp/org-mime.el | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/contrib/lisp/org-mime.el b/contrib/lisp/org-mime.el
index f341474..9f18dc6 100644
--- a/contrib/lisp/org-mime.el
+++ b/contrib/lisp/org-mime.el
@@ -252,7 +252,7 @@ export that region, otherwise export the entire body."
   (save-restriction
 (org-narrow-to-subtree)
 (run-hooks 'org-mime-send-subtree-hook)
-(flet ((mp (p) (org-entry-get nil p org-mime-use-property-inheritance)))
+(cl-flet ((mp (p) (org-entry-get nil p org-mime-use-property-inheritance)))
   (let* ((file (buffer-file-name (current-buffer)))
 	 (subject (or (mp "MAIL_SUBJECT") (nth 4 (org-heading-components
 	 (to (mp "MAIL_TO"))
@@ -287,17 +287,17 @@ export that region, otherwise export the entire body."
   (require 'message)
   (message-mail to subject headers nil)
   (message-goto-body)
-  (flet ((bhook (body fmt)
-		(let ((hook (intern (concat "org-mime-pre-"
-	(symbol-name fmt)
-	"-hook"
-		  (if (> (eval `(length ,hook)) 0)
-		  (with-temp-buffer
-			(insert body)
-			(goto-char (point-min))
-			(eval `(run-hooks ',hook))
-			(buffer-string))
-		body
+  (cl-flet ((bhook (body fmt)
+		   (let ((hook (intern (concat "org-mime-pre-"
+	   (symbol-name fmt)
+	   "-hook"
+		 (if (> (eval `(length ,hook)) 0)
+			 (with-temp-buffer
+			   (insert body)
+			   (goto-char (point-min))
+			   (eval `(run-hooks ',hook))
+			   (buffer-string))
+		   body
 (let ((fmt (if (symbolp fmt) fmt (intern fmt
   (cond
((eq fmt 'org)
-- 
2.3.3

Re: [O] [ox, patch] Add #+SUBTITLE

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> This patch adds #+SUBTITLE to a couple of backends.  This property is
> already supported in ox-texinfo and e.g. beamer.cls has a subtitles macro,
> but ox-beamer.el has no #+SUBTITLE.  I have used subtitles in
> e.g. applications for research funds.
>
> The value-added is twofold:
>
> - It adds a consistent way to have subtitle across backends.  I'm
>   explicitly assuming this is nice, but perhaps this is false.
> - Currently, it is, I believe, impossible to hack-up a subtitle in at
>   least ox-odt.el.
>
> It's not documented yet as I want make sure that it's not an undesirable
> feature before progressing further.
>
> WDTY?

Adding #+SUBTITLE to Beamer is a fine idea, since there's already
a dedicated macro for it. Thank you for taking care of it.

However, I think porting this feature to back-ends that do not support
it out of the box is pushing too hard. 

Back-ends developers should try hard to support features defined in
"ox.el" (in particular in `org-export-options-alist'). However, all
back-ends are free to implement their specific keywords without adding
burden on other libraries. "ox-texinfo" supports #+SUBAUTHOR, should we
add it everywhere? I don't think so.

This is why I suggested to move KEYWORD and DESCRIPTION outside of
"ox.el", as they cannot be ported to all back-ends without relying on
dubious markup.

Now, if SUBTITLE is a feature desperately needed everywhere, which can
be discussed, it should be moved to "ox.el" and probably
`org-element-document-keywords'. IMO, this is not necessary. SUBTITLE
should be kept for back-ends that can handle it.

As a side note, "ox-texinfo" doesn't parse SUBTITLE. You might want to
change it and update manual accordingly.

Regards,

-- 
Nicolas Goaziou

Re: [O] PATCH: Document how to scroll calendar by one year at date prompt.

[Nicolas Goaziou]

Hello,

Gregor Zattler  writes:

> Hi Jens, org-mode developers,
> * Haustedt, Jens  [19. Mar. 2015]:
>> in the description of the date/time prompt, a section describes the
>> control of the calendar from the minibuffer.
>> 
>> There, a description of scrolling the calendar by 1 year is missing. The
>> keyboard shortcut is M-S-/ and works perfectly.
>
> The following patch adds this info to the manual.  It also
> justifies the lines to look prettier in info.

Thank you. 

Could you send it again using "git format-patch" and add an appropriate
commit message?

Regards,

-- 
Nicolas Goaziou

Re: [O] [ox] possible to modify org-export-document-properties OTG

[Nicolas Goaziou]

Rasmus  writes:

> Nicolas Goaziou  writes:
>>
>>(:subject "SUBJECT" nil nil parsed)
>>
>> `parsed' behavior implies `space' anyway, since we're talking about
>> secondary strings.
>
> Is that always the case?  I guess..

There are only two ways to look at it: either it can only contain
objects, or it can contain paragraphs. The latter might make sense for,
e.g., DESCRIPTION.

In this case, we need 2 symbols for that, e.g., `parse-objects' and
`parse-elements'.

>> `org-element-map' can find objects in captions, with an optional
>> argument.
>
> If turns out to be important, perhaps it would also be possible to map
> keyword objects with an non-default argument.

This is different. Captions are already in the parse tree. Keyword
objects are added mid-way. I'd rather keep keywords as is. If you want
to map over objects in, e.g., SUBJECT, you need to explicitly call
`org-element-map' on (plist-get info :subject).

Regards,

Re: [O] replace letf with cl-letf in org-mime

[Nicolas Goaziou]

Hello,

Eric Abrahamsen  writes:

> It's amazing what an effect barky compiler errors can have.

Thanks. However, `cl-flet' is not supported in Emacs 23 so it's not an
option for Org 8.3.

OTOH, most uses of `flet' can be replaced with a plain `lambda' and
funcalls.

> -(flet ((mp (p) (org-entry-get nil p org-mime-use-property-inheritance)))
> +(cl-flet ((mp (p) (org-entry-get nil p 
> org-mime-use-property-inheritance)))
>(let* ((file (buffer-file-name (current-buffer)))
>(subject (or (mp "MAIL_SUBJECT") (nth 4 (org-heading-components
>(to (mp "MAIL_TO"))

  (let* ((mp (lambda (p) (org-entry-get nil p 
org-mime-use-property-inheritance
 (file (buffer-file-name (current-buffer)))
 (subject (or (funcall mp "MAIL_SUBJECT") (nth 4 
(org-heading-components
 (to (funcall mp "MAIL_TO"))
 ...)


Regards,

-- 
Nicolas Goaziou

Re: [O] [ox-ascii, bug?] different spacing between title & author

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> Newlines behave differently when using utf8 and other encodings,
> e.g. between the top line and the title (which is fine), but also between
> title and author, which I dislike a lot.  I don't know if this is a
> features.
>
> Example:
> #+title: title
> #+author: author 
>
> utf8 output with 2 newlines between title and author and no line between
> top line and title.
>
>   
>TITLE
>
>
>author
>   
>
>
> Ascii output with a single newline between title and author.  Much nicer.
>
>   
>
>TITLE
>
>author
>   

Fixed in 51b206bcd2676a3f46cbb89e6ac35d3a04ea70b5. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] replace letf with cl-letf in org-mime

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> It's amazing what an effect barky compiler errors can have.
>
> Thanks. However, `cl-flet' is not supported in Emacs 23 so it's not an
> option for Org 8.3.

Oh, okay -- I guess I'd never really been aware of what Emacs version we
were maintaining compatibility with. That's good to know. I'll do
another version of this in the morning.

> OTOH, most uses of `flet' can be replaced with a plain `lambda' and
> funcalls.
>
>> -(flet ((mp (p) (org-entry-get nil p org-mime-use-property-inheritance)))
>> +(cl-flet ((mp (p) (org-entry-get nil p 
>> org-mime-use-property-inheritance)))
>>(let* ((file (buffer-file-name (current-buffer)))
>>   (subject (or (mp "MAIL_SUBJECT") (nth 4 (org-heading-components
>>   (to (mp "MAIL_TO"))
>
>   (let* ((mp (lambda (p) (org-entry-get nil p 
> org-mime-use-property-inheritance
>  (file (buffer-file-name (current-buffer)))
>  (subject (or (funcall mp "MAIL_SUBJECT") (nth 4 
> (org-heading-components
>  (to (funcall mp "MAIL_TO"))
>  ...)
>
>
> Regards,

Re: [O] [ox, patch] Add #+SUBTITLE

[Eric Abrahamsen]

Rasmus  writes:

> Hi,
>
> This patch adds #+SUBTITLE to a couple of backends.  This property is
> already supported in ox-texinfo and e.g. beamer.cls has a subtitles macro,
> but ox-beamer.el has no #+SUBTITLE.  I have used subtitles in
> e.g. applications for research funds.
>
> The value-added is twofold:
>
> - It adds a consistent way to have subtitle across backends.  I'm
>   explicitly assuming this is nice, but perhaps this is false.
> - Currently, it is, I believe, impossible to hack-up a subtitle in at
>   least ox-odt.el.
>
> It's not documented yet as I want make sure that it's not an undesirable
> feature before progressing further.
>
> WDTY?

In ox-html, You might consider wrapping the title and subtitle in an
 if :html5-fancy is t. Or maybe that's going too far! Either
way, I like this.

Re: [O] [ox, patch] Add #+SUBTITLE

[Rasmus]

Hi Nicolas,

I'm a bit confused by your message.

Nicolas Goaziou  writes:

> However, I think porting this feature to back-ends that do not support
> it out of the box is pushing too hard. 

In the patch there's ox-latex where e.g. KOMA-Script has as
subtitle-macro.  ox-html, ox-ascii, ox-odt all are pretty liberate formats
in terms of what elements are supported.

> Back-ends developers should try hard to support features defined in
> "ox.el" (in particular in `org-export-options-alist'). However, all
> back-ends are free to implement their specific keywords without adding
> burden on other libraries. "ox-texinfo" supports #+SUBAUTHOR, should we
> add it everywhere? I don't think so.

OK.  ox and org-element shouldn't be touched by the patch.

> This is why I suggested to move KEYWORD and DESCRIPTION outside of
> "ox.el", as they cannot be ported to all back-ends without relying on
> dubious markup.

Yeah, I still have a patch for that...  I still have to do the
documentation changes.

> Now, if SUBTITLE is a feature desperately needed everywhere, which can
> be discussed, it should be moved to "ox.el" and probably
> `org-element-document-keywords'. IMO, this is not necessary. SUBTITLE
> should be kept for back-ends that can handle it.

IMO it is.  The only place where there's a "hack" is in ox-latex and
that's cause article is the default class.  If you prefer, it can just
output to the \subtitle{·} by default and say it's KOMA-script only.  That
seems harsh, though.

> As a side note, "ox-texinfo" doesn't parse SUBTITLE. You might want to
> change it and update manual accordingly.

The patch doesn't touch ox-texinfo.  I don't mind fixing that bug, though.

—Rasmus

-- 
Hvor meget poesi tror De kommer ud af et glas isvand?

Re: [O] [ox, patch] Add #+SUBTITLE

[Rasmus]

Eric Abrahamsen  writes:

> Rasmus  writes:
>
> In ox-html, You might consider wrapping the title and subtitle in an
>  if :html5-fancy is t. Or maybe that's going too far! Either
> way, I like this.

First result on my search engine says¹ :

Update 16th April, 2013. hgroup has now been removed from the HTML5
specification. We are working on an article to help guide authors on
which markup patterns they should use instead.

Update 4th April, 2013. Please note that following this decision,
hgroup will be removed from the HTML5 specification. As such, we don’t
endorse using it on production sites.

I don't know anything about html, though.  Is there another element you
had in mind?  Or is the html5doctor just wrong?

Thanks,
Rasmus


Footnotes: 
¹   http://html5doctor.com/the-hgroup-element/

-- 
Hvor meget poesi tror De kommer ud af et glas isvand?

Re: [O] fontenc makes pdf non-searchable

[William Denton]

On 21 March 2015, Martin Leduc wrote:


You can find a minimal example here [1], with the org file, and the tex and pdf 
files generated from it. Firts try to search within the pdf. It does not work 
(at least on my side) To solve the problem, remove the line with
\usepackage[T1]{fontenc}

in the tex file, and compile it. It should now search normally.


"It works for me" is all I can say, which isn't too helpful.  Everything happens 
as it should, and I can search the PDF (in evince).  Maybe it's something with 
your LaTeX setup?  Sorry I can't suggest anything more.


Bill

[1] https://www.dropbox.com/sh/7s6di4en5ljbkcq/AAAzyQeg6VkMHnC1X9dQTg6ua?dl=0

--
William Denton ↔  Toronto, Canada ↔  https://www.miskatonic.org/

Re: [O] [ox, patch] Add #+SUBTITLE

[Marcin Borkowski]

On 2015-03-22, at 16:29, Rasmus  wrote:

> IMO it is.  The only place where there's a "hack" is in ox-latex and
> that's cause article is the default class.  If you prefer, it can just
> output to the \subtitle{·} by default and say it's KOMA-script only.  That
> seems harsh, though.

Hi there,

being like a Pavlov's dog trained to dribble on seeing the word
LaTeX;-), let me add my 2 cents here.

[TL;DR: imho, the right way to do LaTeX export is to prepare a dedicated
package for Org-mode generated files (easy/medium), arrange for it to be
included in all major TeX distros (easy) and simplify the LaTeX exporter
to comply with it (easy).  This could greatly enhance the quality of
PDFs produced by Org-mode and make modifying their look easier on the
Org side.  I could do the LaTeX side of the work.  Now the question is:
does the community /want/ it.]

The (default) LaTeX markup sucks.  (It’s not about Org-mode-produced
LaTeX files, it’s about LaTeX itself.)  And I'm telling that as
a long-time TeX and LaTeX user and fan.  I would strongly suggest not
caring too much about “what does LaTeX support out-of-the-box” – in
fact, it supports almost nothing without a heap of packages.

What I really think Org-mode community should do is the following.

We (if I may use that pronoun here) should prepare a dedicated Org LaTeX
package, properly supporting all Org’s fancy stuff like tags,
timestamps, todo keywords etc., and allowing for parametrizing their
look-and-feel through a reasonable LaTeX interface.  I think it should
/not/ be a class, since then people would be free to use it with
article/amsart/koma-script/memoir/whatever.  This is not very difficult
nor time-consuming, and in fact I might be tempted to do it (more on
that below).  This would require (simple) changes in the LaTeX exporter
(generally, simplifying it); this I cannot do, since I don’t have the
FSF papers signed (and I don’t want to sign them).  OTOH, the package
does not have this problem, since LaTeX licensing is much more sane than
Emacs’; this package should be imho part of every TeX distro (which is
important, and in fact easy to arrange), so that we could send an
Org-generated LaTeX file to any TeX user.

The biggest advantage would be the possibility of exporting e.g. TODO
lists or agendas to LaTeX, and have them formatted as TODO lists and
agendas and not as “articles”.  Currently, LaTeX export is more or less
limited to scientific articles (unless you want to tweak it /a lot/ so
that it looks even remotely reasonable), where you don’t really care
about layout and design, since they are going to be changed by the
journal anyway.

Just think about the possibilities.  We could make a TODO list in Org,
and send it (as a pdf file) for non-Org-users to print, and it could
look like a TODO-list.  (I guess there are still lots of people who
depend on paper todo lists; I do, for sure, though I make them
manually.)  We could have an option (on Org side, which would translate
to a LaTeX one) to have more Word-like layout.  (You can say what you
want about Word – my personal opinion is that it is unsuitable for
documents larger/more complex than a piece of paper with an arrow
showing the direction to the restroom – but sometimes, especially for
short memos/notes, LaTeX’s extremely generic spacing can be annoying.
Of course, you could just load the savetrees package – but let me make
a short, informal and unscientific survey here: how many of you would
find it useful, but never thought that something like that exists?  If,
OTOH, there would be such option for the LaTeX exporter, it would be
right there, in Org-mode manual.  In fact, since not everyone might
follow this thread, let me start another one, with this very question in
a minute;-).)

The added benefit would be much cleaner structure of Org-generated LaTeX
files.  Currently, they have a huge preamble and a few hard-wired
things.

Summing up: as we know, there are many ways people use Org-mode, but the
current PDF exporter (through LaTeX’s article class, heavily biased
toward scientific material) is suboptimal for all but one of these ways.

As I said, if there is some consensus on whether something like that is
needed, I can start working on it.  (In fact, it might be a fun
side-project.)  I would estimate that I’d need a week or two to come up
with a proof-of-concept, sort-of-working thing, and something like two
months with a first production version.  (Though I don’t have time for
a project like this now, realistically I could start in August.)  (Let
me thank here for Org-mode clocking feature – the above estimate is due
to the fact that I did some work on coding a dedicated, quite complex
LaTeX class for a journal, and I know that it has taken me about 32
hours as of now.  Assuming an average pace of 2-4 hours a week, and
assuming about 16 hours for a first version of this one – it would be
a much simpler project – gives 1-2 months or so.  NB. Fun fact: the work
on the class for the jour

[O] [OT] A short (less than a minute), informal survey about LaTeX

[Marcin Borkowski]

Hi there,

two questions for people using LaTeX (possibly only as Org-mode
backend).

1. Did you know about the savetrees package by Scott Pakin
(http://www.ctan.org/pkg/savetrees)?  From the description:

,
| The goal of the savetrees package is to pack as much text as
| possible onto each page of a LaTeX document. Admittedly, this
| makes the document far less attractive. Nevertheless,
| savetrees is a simple way to save paper when printing draft copies
| of a document.
`

2. Would you find it useful when producing PDF files other that
scientific articles (using Org-mode or not)?

(Note: I explained the rationale behind this survey in another post
I sent to the list a few minutes ago in the thread about the #+SUBTITLE
keyword.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] [ox, patch] Add #+SUBTITLE

[Thomas S. Dye]

Marcin Borkowski  writes:

> On 2015-03-22, at 16:29, Rasmus  wrote:
>
>> IMO it is.  The only place where there's a "hack" is in ox-latex and
>> that's cause article is the default class.  If you prefer, it can just
>> output to the \subtitle{·} by default and say it's KOMA-script only.  That
>> seems harsh, though.
>
> Hi there,
>
> being like a Pavlov's dog trained to dribble on seeing the word
> LaTeX;-), let me add my 2 cents here.
>
> [TL;DR: imho, the right way to do LaTeX export is to prepare a dedicated
> package for Org-mode generated files (easy/medium), arrange for it to be
> included in all major TeX distros (easy) and simplify the LaTeX exporter
> to comply with it (easy).  This could greatly enhance the quality of
> PDFs produced by Org-mode and make modifying their look easier on the
> Org side.  I could do the LaTeX side of the work.  Now the question is:
> does the community /want/ it.]
>
> The (default) LaTeX markup sucks.  (It’s not about Org-mode-produced
> LaTeX files, it’s about LaTeX itself.)  And I'm telling that as
> a long-time TeX and LaTeX user and fan.  I would strongly suggest not
> caring too much about “what does LaTeX support out-of-the-box” – in
> fact, it supports almost nothing without a heap of packages.
>
> What I really think Org-mode community should do is the following.
>
> We (if I may use that pronoun here) should prepare a dedicated Org LaTeX
> package, properly supporting all Org’s fancy stuff like tags,
> timestamps, todo keywords etc., and allowing for parametrizing their
> look-and-feel through a reasonable LaTeX interface.  I think it should
> /not/ be a class, since then people would be free to use it with
> article/amsart/koma-script/memoir/whatever.  This is not very difficult
> nor time-consuming, and in fact I might be tempted to do it (more on
> that below).  This would require (simple) changes in the LaTeX exporter
> (generally, simplifying it); this I cannot do, since I don’t have the
> FSF papers signed (and I don’t want to sign them).  OTOH, the package
> does not have this problem, since LaTeX licensing is much more sane than
> Emacs’; this package should be imho part of every TeX distro (which is
> important, and in fact easy to arrange), so that we could send an
> Org-generated LaTeX file to any TeX user.
>
> The biggest advantage would be the possibility of exporting e.g. TODO
> lists or agendas to LaTeX, and have them formatted as TODO lists and
> agendas and not as “articles”.  Currently, LaTeX export is more or less
> limited to scientific articles (unless you want to tweak it /a lot/ so
> that it looks even remotely reasonable), where you don’t really care
> about layout and design, since they are going to be changed by the
> journal anyway.
>
> Just think about the possibilities.  We could make a TODO list in Org,
> and send it (as a pdf file) for non-Org-users to print, and it could
> look like a TODO-list.  (I guess there are still lots of people who
> depend on paper todo lists; I do, for sure, though I make them
> manually.)  We could have an option (on Org side, which would translate
> to a LaTeX one) to have more Word-like layout.  (You can say what you
> want about Word – my personal opinion is that it is unsuitable for
> documents larger/more complex than a piece of paper with an arrow
> showing the direction to the restroom – but sometimes, especially for
> short memos/notes, LaTeX’s extremely generic spacing can be annoying.
> Of course, you could just load the savetrees package – but let me make
> a short, informal and unscientific survey here: how many of you would
> find it useful, but never thought that something like that exists?  If,
> OTOH, there would be such option for the LaTeX exporter, it would be
> right there, in Org-mode manual.  In fact, since not everyone might
> follow this thread, let me start another one, with this very question in
> a minute;-).)
>
> The added benefit would be much cleaner structure of Org-generated LaTeX
> files.  Currently, they have a huge preamble and a few hard-wired
> things.
>
> Summing up: as we know, there are many ways people use Org-mode, but the
> current PDF exporter (through LaTeX’s article class, heavily biased
> toward scientific material) is suboptimal for all but one of these ways.
>
> As I said, if there is some consensus on whether something like that is
> needed, I can start working on it.  (In fact, it might be a fun
> side-project.)  I would estimate that I’d need a week or two to come up
> with a proof-of-concept, sort-of-working thing, and something like two
> months with a first production version.  (Though I don’t have time for
> a project like this now, realistically I could start in August.)  (Let
> me thank here for Org-mode clocking feature – the above estimate is due
> to the fact that I did some work on coding a dedicated, quite complex
> LaTeX class for a journal, and I know that it has taken me about 32
> hours as of now.  Assuming an average pace of 2-4 ho

Re: [O] [ox, patch] Add #+SUBTITLE

[John Williams]

I, for one, find your ideas exciting, Marcin.  If you're simply looking
for votes in order to start work on this: +1.

Thanks!

> Marcin Borkowski  writes:

> On 2015-03-22, at 16:29, Rasmus  wrote:

>> IMO it is.  The only place where there's a "hack" is in ox-latex
>> and that's cause article is the default class.  If you prefer, it
>> can just output to the \subtitle{·} by default and say it's
>> KOMA-script only.  That seems harsh, though.

> Hi there,

> being like a Pavlov's dog trained to dribble on seeing the word
> LaTeX;-), let me add my 2 cents here.

> [TL;DR: imho, the right way to do LaTeX export is to prepare a
> dedicated package for Org-mode generated files (easy/medium),
> arrange for it to be included in all major TeX distros (easy) and
> simplify the LaTeX exporter to comply with it (easy).  This could
> greatly enhance the quality of PDFs produced by Org-mode and make
> modifying their look easier on the Org side.  I could do the LaTeX
> side of the work.  Now the question is: does the community /want/
> it.]

> The (default) LaTeX markup sucks.  (It’s not about
> Org-mode-produced LaTeX files, it’s about LaTeX itself.)  And I'm
> telling that as a long-time TeX and LaTeX user and fan.  I would
> strongly suggest not caring too much about “what does LaTeX
> support out-of-the-box” – in fact, it supports almost nothing
> without a heap of packages.

> What I really think Org-mode community should do is the following.

> We (if I may use that pronoun here) should prepare a dedicated Org
> LaTeX package, properly supporting all Org’s fancy stuff like
> tags, timestamps, todo keywords etc., and allowing for
> parametrizing their look-and-feel through a reasonable LaTeX
> interface.  I think it should /not/ be a class, since then people
> would be free to use it with
> article/amsart/koma-script/memoir/whatever.  This is not very
> difficult nor time-consuming, and in fact I might be tempted to do
> it (more on that below).  This would require (simple) changes in
> the LaTeX exporter (generally, simplifying it); this I cannot do,
> since I don’t have the FSF papers signed (and I don’t want to sign
> them).  OTOH, the package does not have this problem, since LaTeX
> licensing is much more sane than Emacs’; this package should be
> imho part of every TeX distro (which is important, and in fact
> easy to arrange), so that we could send an Org-generated LaTeX
> file to any TeX user.

> The biggest advantage would be the possibility of exporting
> e.g. TODO lists or agendas to LaTeX, and have them formatted as
> TODO lists and agendas and not as “articles”.  Currently, LaTeX
> export is more or less limited to scientific articles (unless you
> want to tweak it /a lot/ so that it looks even remotely
> reasonable), where you don’t really care about layout and design,
> since they are going to be changed by the journal anyway.

> Just think about the possibilities.  We could make a TODO list in
> Org, and send it (as a pdf file) for non-Org-users to print, and
> it could look like a TODO-list.  (I guess there are still lots of
> people who depend on paper todo lists; I do, for sure, though I
> make them manually.)  We could have an option (on Org side, which
> would translate to a LaTeX one) to have more Word-like layout.
> (You can say what you want about Word – my personal opinion is
> that it is unsuitable for documents larger/more complex than a
> piece of paper with an arrow showing the direction to the restroom
> – but sometimes, especially for short memos/notes, LaTeX’s
> extremely generic spacing can be annoying.  Of course, you could
> just load the savetrees package – but let me make a short,
> informal and unscientific survey here: how many of you would find
> it useful, but never thought that something like that exists?  If,
> OTOH, there would be such option for the LaTeX exporter, it would
> be right there, in Org-mode manual.  In fact, since not everyone
> might follow this thread, let me start another one, with this very
> question in a minute;-).)

> The added benefit would be much cleaner structure of Org-generated
> LaTeX files.  Currently, they have a huge preamble and a few
> hard-wired things.

> Summing up: as we know, there are many ways people use Org-mode,
> but the current PDF exporter (through LaTeX’s article class,
> heavily biased toward scientific material) is suboptimal for all
> but one of these ways.

> As I said, if there is some consensus on whether something like
> that is needed, I can start working on it.  (In fact, it might be
> a fun side-project.)  I would estimate that I’d need a week or two
> to come up with a proof-of-concept, sort-of-working thing, and
 

[O] bug#18870: bug#18870: \emsp and alignment in org clock report

[Nicolas Goaziou]

Nicolas Goaziou  writes:

> The trick could be to use an Org entity which is as large as its
> overlay. Even better if that entity is readable without that overlay.
> I'll look into it soon.

This should now be fixed. The markup used is more readable and doesn't
alter table alignment.

Re: [O] PATCH: Document how to scroll calendar by one year at date prompt.

[Gregor Zattler]

Hi Nicolas,
* Nicolas Goaziou  [22. Mar. 2015]:
> Gregor Zattler  writes:
>> * Haustedt, Jens  [19. Mar. 2015]:
>>> in the description of the date/time prompt, a section describes the
>>> control of the calendar from the minibuffer.
>>> 
>>> There, a description of scrolling the calendar by 1 year is missing. The
>>> keyboard shortcut is M-S-/ and works perfectly.
>>
>> The following patch adds this info to the manual.  It also
>> justifies the lines to look prettier in info.
> 
> Thank you. 
> 
> Could you send it again using "git format-patch" and add an appropriate
> commit message?

Sure.  In this iteration I also added the respective keys to the
Key index.

Ciao, Gregor
-- >8 --
Subject: [PATCH 1/1] How to scroll calendar by one year at date prompt.

Add respective keys to the Key index.  Also justify the lines in this
block to look prettier in info.
---
 doc/org.texi | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 
6d25df177d93847dba0f310e6506e5c3c8d2aa40..6b56c4aac6bb802c36a3b076f2ef4bb97019b788
 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -6135,14 +6135,18 @@ from the minibuffer:
 @kindex M-S-@key{right}
 @kindex M-S-@key{left}
 @kindex @key{RET}
-@example
-@key{RET}   @r{Choose date at cursor in calendar.}
-mouse-1@r{Select date by clicking on it.}
-S-@key{right}/@key{left} @r{One day forward/backward.}
-S-@key{down}/@key{up} @r{One week forward/backward.}
-M-S-@key{right}/@key{left}   @r{One month forward/backward.}
-> / <  @r{Scroll calendar forward/backward by one month.}
-M-v / C-v  @r{Scroll calendar forward/backward by 3 months.}
+@kindex M-S-@key{down}
+@kindex M-S-@key{up}
+
+@example
+@key{RET}  @r{Choose date at cursor in calendar.}
+mouse-1@r{Select date by clicking on it.}
+S-@key{right}/@key{left}   @r{One day forward/backward.}
+S-@key{down}/@key{up}  @r{One week forward/backward.}
+M-S-@key{right}/@key{left} @r{One month forward/backward.}
+> / <  @r{Scroll calendar forward/backward by one month.}
+M-v / C-v  @r{Scroll calendar forward/backward by 3 months.}
+M-S-@key{down}/@key{up}@r{Scroll calendar forward/backward by one year.}
 @end example
 
 @vindex org-read-date-display-live
-- 
2.1.4

Re: [O] [OT] A short (less than a minute), informal survey about LaTeX

[Rasmus]

Marcin Borkowski  writes:

> two questions for people using LaTeX (possibly only as Org-mode
> backend).
>
> 1. Did you know about the savetrees package by Scott Pakin
> (http://www.ctan.org/pkg/savetrees)?  From the description:

Yes.

> ,
> | The goal of the savetrees package is to pack as much text as
> | possible onto each page of a LaTeX document. Admittedly, this
> | makes the document far less attractive. Nevertheless,
> | savetrees is a simple way to save paper when printing draft copies
> | of a document.
> `
>
> 2. Would you find it useful when producing PDF files other that
> scientific articles (using Org-mode or not)?

No.  I find the output too ugly.

Regards,
Rasmus "the tree-cutter"

-- 
To err is human. To screw up 10⁶ times per second, you need a computer

Re: [O] [ox, patch] Add #+SUBTITLE

[Rasmus]

Marcin Borkowski  writes:

> [TL;DR: imho, the right way to do LaTeX export is to prepare a dedicated
> package for Org-mode generated files (easy/medium), arrange for it to be
> included in all major TeX distros (easy) and simplify the LaTeX exporter
> to comply with it (easy).  This could greatly enhance the quality of
> PDFs produced by Org-mode and make modifying their look easier on the
> Org side.  I could do the LaTeX side of the work.  Now the question is:
> does the community /want/ it.]

I have a couple of initial concerns that you could address if your
spin-off thread if you like.

- Sat you can envision better code for a particular piece of org syntax.
  Why is a better to have it in an external latex-package than directly in
  the org files?  If it lives somewhere else, I have to bug you when I
  want to change something.  What if you get bored of this?

- What happens when you cannot maintain it any longer?  Note also that the
  scope is somewhat different as a typical latex package solves a problem
  like "provide good tables" or "enhance itemize 2e" (ei2e).  Such
  packages are fairly easy to replace (e.g. sugfigure → subcaption).

- I don't want latex code generated by org to a "special flavor" like with
  LyX.

- Why can the issues you have in mind not be solved by a specialized
  derived backend?  Such as ox-beamer or ox-koma-letter.

Thanks,
Rasmus

-- 
Enough with the bla bla!

Re: [O] [OT] A short (less than a minute), informal survey about LaTeX

[John Williams]

> Marcin Borkowski  writes:

> Hi there, two questions for people using LaTeX (possibly only as
> Org-mode backend).

> 1. Did you know about the savetrees package by Scott Pakin
> (http://www.ctan.org/pkg/savetrees)?  From the description:
Yes.
> , | The goal of the savetrees package is to pack as much text
> as | possible onto each page of a LaTeX document. Admittedly, this
> | makes the document far less attractive. Nevertheless, |
> savetrees is a simple way to save paper when printing draft copies
> | of a document.  `

> 2. Would you find it useful when producing PDF files other that
> scientific articles (using Org-mode or not)?
Yes
> (Note: I explained the rationale behind this survey in another
> post I sent to the list a few minutes ago in the thread about the
> #+SUBTITLE keyword.)

> Best,

> -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Faculty of Mathematics and Computer Science Adam Mickiewicz
> University

[O] bug#18870: \emsp and alignment in org clock report

[Ben Finney]

On 17-Mar-2015, Nicolas Goaziou wrote:

> Also, the bug is about table alignment when `org-pretty-entities' is
> used.

Okay. So if I'm reporting a regression in the text (non-GUI) Emacs
behaviour of Org mode, I should make a separate report?

> > So the U+2003 EM SPACE character should be translated *during
> > export*, and not be literally in the displayed text.
> 
> No, because it means this character should be treated specially by
> Org (e.g., LaTeX just ignores it so it needs to be turned into a
> space there).

That conflicts with what you're saying later:

> > But not for display, which is the bug to be fixed here.
> 
> Actually, it works more or less correctly for display on GUI with a
> non-nil `org-pretty-entities', or calling
> `org-toggle-pretty-entities'.

So the behaviour is masked by special behaviour of “entities”. Why is
that special behaviour acceptable, but allowing export of U+2003 is not?

On 22-Mar-2015, Nicolas Goaziou wrote:

> This should now be fixed. The markup used is more readable and
> doesn't alter table alignment.

Is that true for text-only terminals too?

-- 
 \   “See, in my line of work you gotta keep repeating things over |
  `\   and over and over again, for the truth to sink in; to kinda |
_o__)   catapult the propaganda.” —George W. Bush, 2005-05 |
Ben Finney 


signature.asc
Description: Digital signature

Re: [O] [ox, patch] Add #+SUBTITLE

[Marcin Borkowski]

On 2015-03-22, at 23:43, Rasmus  wrote:

> Marcin Borkowski  writes:
>
>> [TL;DR: imho, the right way to do LaTeX export is to prepare a dedicated
>> package for Org-mode generated files (easy/medium), arrange for it to be
>> included in all major TeX distros (easy) and simplify the LaTeX exporter
>> to comply with it (easy).  This could greatly enhance the quality of
>> PDFs produced by Org-mode and make modifying their look easier on the
>> Org side.  I could do the LaTeX side of the work.  Now the question is:
>> does the community /want/ it.]
>
> I have a couple of initial concerns that you could address if your
> spin-off thread if you like.

Good questions!

> - Sat you can envision better code for a particular piece of org syntax.
>   Why is a better to have it in an external latex-package than directly in
>   the org files?  If it lives somewhere else, I have to bug you when I
>   want to change something.  What if you get bored of this?

The point would be to provide user-level ways to change the look.
Currently e.g. tags are hardcoded into the section titles, which is ugly
both in the LaTeX source and in the LaTeX output.  (Also, see below.)

> - What happens when you cannot maintain it any longer?  Note also that the

Either the project dies, or someone takes it over.  The latter seems to
be quite common in the LaTeX community, so I wouldn't be very worried.

>   scope is somewhat different as a typical latex package solves a problem
>   like "provide good tables" or "enhance itemize 2e" (ei2e).  Such
>   packages are fairly easy to replace (e.g. sugfigure → subcaption).

Fair enough.  Not a problem imho, though.  A “package” has a very wide
definition in the LaTeX world, and I explained why a package would be
better than a class (even though doing it as a package would be a bit
more work with ensuring that it works with wide range of classes).

> - I don't want latex code generated by org to a "special flavor" like with
>   LyX.

But the whole point is to have LaTeX code which is human-readable (and
human-modifiable).  Also, currently you have "special flavor" anyway -
just look at the preamble of Org-generated LaTeX files.  In my vision,
the huge preamble is replaced by \usepackage{orglatex} or something like
this, and instead of, say,

: \section{{\bfseries\sffamily TODO} hello\hfill{}\textsc{world}}

(how is that not a “special flavor”?) you would have

: \section{\orgtodo{TODO}hello\orgtags{world}}

or, if we decide to do a major surgery on LaTeX’s sectioning mechanism
(which is debatable), even

: \section[orgtodo=TODO,orgtags=world]{hello}

or something like this.  Note that I assume that the package would be
included in all major TeX distros, so the average LaTeX user wouldn't
even notice any change, apart from better markup.

> - Why can the issues you have in mind not be solved by a specialized
>   derived backend?  Such as ox-beamer or ox-koma-letter.

This seems to bug you enough that you basically asked twice;-).

As I said, people use Org-mode in various ways.  For some people, the
LaTeX export is something they use to produce a PDF.  For other people,
Org may be a quick authoring tool (faster and more comfortable than
AUCTeX, possibly), but after e.g. making a draft in Org they continue
their work in LaTeX (because LaTeX is just more powerful than Org when
it comes to typesetting proper).  For them, human-readable (and
editable) LaTeX code is a nice thing.

Also, adding some options in a LaTeX package seems to have less friction
than in Org.  In the former, you just code it and make a pull request to
the package maintainer (or send a patch, or even just file a feature
request).  In the latter, you bug Nicolas, and he has to think about the
impact of your feature request for other backends (because Org is not
LaTeX-centric!).

Probably most importantly, Org-mode is much more about the content, and
delegates the presentation issues to backends.  In case of HTML, you
have CSS, and it seems that everyone agrees that generating a suitable
CSS is outside Org-mode’s scope.  What I’m proposing here is very much
analogous to the HTML/CSS division: let Org produce a somewhat generic
LaTeX markup (like HTML), and let a LaTeX package (like CSS) decide what
to do with that visually.  Currently, due to hard-coding of things like
in the above example, it is plainly impossible.  And while HTML has ways
of “extending itself” built-in (thanks to element classes and divs and
spans), LaTeX does not have anything like that.  What I’m proposing is
(more or less) filling this gap.

Also, due to (sorry to repeat that) insane licensing requirements of
Org, making changes is much more frictionless on the LaTeX side of
things.

>
> Thanks,
> Rasmus


-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: [O] fontenc makes pdf non-searchable

[Martin Leduc]

Hey  finally your response helped me a lot, that is the problem was probably on 
my side.

I solved it by installing the package cm-super, as suggested here. I still 
can't search in the pdf I gave you (and still wondering why YOU can), but 
re-exporting the org file makes a pdf that now works correctly.

Thanks again !
Martin






> Date: Sun, 22 Mar 2015 13:56:45 -0400
> From: w...@pobox.com
> To: mart...@hotmail.com
> CC: emacs-orgmode@gnu.org
> Subject: Re: [O] fontenc makes pdf non-searchable
> 
> On 21 March 2015, Martin Leduc wrote:
> 
> > You can find a minimal example here [1], with the org file, and the tex and 
> > pdf files generated from it. Firts try to search within the pdf. It does 
> > not work (at least on my side) To solve the problem, remove the line with
> > \usepackage[T1]{fontenc}
> >
> > in the tex file, and compile it. It should now search normally.
> 
> "It works for me" is all I can say, which isn't too helpful.  Everything 
> happens 
> as it should, and I can search the PDF (in evince).  Maybe it's something 
> with 
> your LaTeX setup?  Sorry I can't suggest anything more.
> 
> Bill
> 
> [1] https://www.dropbox.com/sh/7s6di4en5ljbkcq/AAAzyQeg6VkMHnC1X9dQTg6ua?dl=0
> 
> -- 
> William Denton ↔  Toronto, Canada ↔  https://www.miskatonic.org/
  

Re: [O] PATCH: Document how to scroll calendar by one year at date prompt.

[Nicolas Goaziou]

Gregor Zattler  writes:

> Sure.  In this iteration I also added the respective keys to the
> Key index.

Applied. Thank you.

I added TINYCHANGE at the end of the commit message, since you don't
seem to have signed FSF papers. Please correct me if I'm wrong.

Regards,

[O] bug#18870: \emsp and alignment in org clock report

[Nicolas Goaziou]

Hello,

Ben Finney  writes:

> Okay. So if I'm reporting a regression in the text (non-GUI) Emacs
> behaviour of Org mode, I should make a separate report?

First, please update Org and test the new behaviour if you can.

> So the behaviour is masked by special behaviour of “entities”. Why is
> that special behaviour acceptable, but allowing export of U+2003 is
> not?

Because entities syntax is well defined, and uses easy-to-reach
characters. Asking users to insert EM SPACE as special markup doesn't
seem right for Org.

> On 22-Mar-2015, Nicolas Goaziou wrote:
>
>> This should now be fixed. The markup used is more readable and
>> doesn't alter table alignment.
>
> Is that true for text-only terminals too?

Yes, it is.


Regards,

-- 
Nicolas Goaziou

Re: [O] [ox, patch] Add #+SUBTITLE

[Rasmus]

Hi,

First: Please don't take me being critical as meaning I'm necessarily
negative about.  I'm just minimizing risk over the expectation.

Marcin Borkowski  writes:

>> - What happens when you cannot maintain it any longer?  Note also that the
>
> Either the project dies, or someone takes it over.  The latter seems to
> be quite common in the LaTeX community, so I wouldn't be very worried.

That does not seem like something you'd want to base Org on...

>>   scope is somewhat different as a typical latex package solves a problem
>>   like "provide good tables" or "enhance itemize 2e" (ei2e).  Such
>>   packages are fairly easy to replace (e.g. sugfigure → subcaption).
>
> Fair enough.  Not a problem imho, though.  A “package” has a very wide
> definition in the LaTeX world, and I explained why a package would be
> better than a class (even though doing it as a package would be a bit
> more work with ensuring that it works with wide range of classes).

I am talking about latex packages and the example mentions real latex
packages.  A class would be a sure route to failure.  A packages is fine.
But it's beside the point.  You argue, if I understand correctly, for
amending ox-latex to rely on a very specialized package, which we may or
may not easily be able to replace should it come to that.

>> - I don't want latex code generated by org to a "special flavor" like with
>>   LyX.

> In my vision, the huge preamble is replaced by \usepackage{orglatex} or
> something like this, and instead of, say,

OK.

> : \section{{\bfseries\sffamily TODO} hello\hfill{}\textsc{world}}
>
> (how is that not a “special flavor”?) you would have
>
> : \section{\orgtodo{TODO}hello\orgtags{world}}
>
> or, if we decide to do a major surgery on LaTeX’s sectioning mechanism
> (which is debatable), even
>
> : \section[orgtodo=TODO,orgtags=world]{hello}

Both are appealing.

>> - Why can the issues you have in mind not be solved by a specialized
>>   derived backend?  Such as ox-beamer or ox-koma-letter.
>
> This seems to bug you enough that you basically asked twice;-).

No.  Here is ask why you can't settle for another Org-mode backend, rather
than a new latex package.  This can even live in contrib without signing
the copyright agreement with FSF.

E.g. you could get a very similar result to what you are talking about by
defining the macros at export-level (e.g. write-out
\providecommand\orgtodo...)  and allowed writing a preamble or similar (if
you really mind long preambles).  That way anybody would also be able to
customize on the latex end, if they so desire.

> As I said, people use Org-mode in various ways. [...].  For other
> people, [they make] a draft in Org they continue their work in LaTeX
> (...).  For them, human-readable (and editable) LaTeX code is a nice
> thing.

Good point.

> Also, adding some options in a LaTeX package seems to have less friction
> than in Org.  In the former, you just code it and make a pull request to
> the package maintainer (or send a patch, or even just file a feature
> request).  In the latter, you bug Nicolas, and he has to think about the
> impact of your feature request for other backends (because Org is not
> LaTeX-centric!).

I don't see the difference.

—Rasmus

-- 
You people at the NSA are becoming my new best friends!

Re: [O] [ox, patch] Add #+SUBTITLE

[Eric Abrahamsen]

Rasmus  writes:

> Eric Abrahamsen  writes:
>
>> Rasmus  writes:
>>
>> In ox-html, You might consider wrapping the title and subtitle in an
>>  if :html5-fancy is t. Or maybe that's going too far! Either
>> way, I like this.
>
> First result on my search engine says¹ :
>
> Update 16th April, 2013. hgroup has now been removed from the HTML5
> specification. We are working on an article to help guide authors on
> which markup patterns they should use instead.
>
> Update 4th April, 2013. Please note that following this decision,
> hgroup will be removed from the HTML5 specification. As such, we don’t
> endorse using it on production sites.
>
> I don't know anything about html, though.  Is there another element you
> had in mind?  Or is the html5doctor just wrong?

Between me and html5doctor, I'd believe html5doctor. That's a shame
though! hgroup always made a lot of sense to me.

[O] agenda timeline sorting and item insertion

[Claudius Mueller]

Hello,

I have an issue with the timeline in the agenda view. It sorts backward
(see black line in attached figure) and timed items are not inserted into
the timeline (see black arrow). Any idea what I am doing wrong? I am
generating the default agenda (C-c a a) and am using a stripped down
version of my org-mode init file that contains nothing but the basics:

(require 'org-install)

(add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))
(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-cc" 'org-capture)
(global-set-key "\C-ca" 'org-agenda)
(global-set-key "\C-cb" 'org-iswitchb)

(custom-set-variables
 '(org-tags-column -90)
 '(org-log-done 'time)
 '(org-blank-before-new-entry nil)
 '(org-agenda-files (list "/data/private/org/tasks.org")))


My setup:
openSUSE 13.2
Emacs 24.4.1


Thank you!

Claudius