[O] comment section with latex_header
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] PATCH: Document how to scroll calendar by one year at date prompt.
Hello, Gregor Zattler telegr...@gmx.net writes: Hi Jens, org-mode developers, * Haustedt, Jens j.haust...@euroimmun.de [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-up/down 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-ascii, bug?] different spacing between title author
Hello, Rasmus ras...@gmx.us 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
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Abrahamsen e...@ericabrahamsen.net 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
Hello, Rasmus ras...@gmx.us 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] [ox, patch] Add #+SUBTITLE
Rasmus ras...@gmx.us 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 hgroup if :html5-fancy is t. Or maybe that's going too far! Either way, I like this.
Re: [O] [PATCH] Re: autoloads not working correctly for org-table.el?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Eric Abrahamsen e...@ericabrahamsen.net 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 e...@ericabrahamsen.net 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 carsten at orgmode dot org +;; 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 http://www.gnu.org/licenses/. + +;;; 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 +;;
Re: [O] replace letf with cl-letf in org-mime
Hello, Eric Abrahamsen e...@ericabrahamsen.net 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] comment section with latex_header
Andreas Leha andreas.l...@med.uni-goettingen.de 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] [ox] possible to modify org-export-document-properties OTG
Rasmus ras...@gmx.us writes: Nicolas Goaziou m...@nicolasgoaziou.fr 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,
[O] PATCH: Document how to scroll calendar by one year at date prompt. (was: Re: Bug: Missing command description in org-mode manual)
Hi Jens, org-mode developers,
* Haustedt, Jens j.haust...@euroimmun.de [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-up/down 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
--
-... --- .-. . -.. ..--.. ...-.-
Re: [O] [ox, patch] Add #+SUBTITLE
Eric Abrahamsen e...@ericabrahamsen.net writes: Rasmus ras...@gmx.us writes: In ox-html, You might consider wrapping the title and subtitle in an hgroup 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] [ox, patch] Add #+SUBTITLE
Hi Nicolas,
I'm a bit confused by your message.
Nicolas Goaziou m...@nicolasgoaziou.fr 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] 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] [ox, patch] Add #+SUBTITLE
On 2015-03-22, at 16:29, Rasmus ras...@gmx.us 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
Re: [O] [ox, patch] Add #+SUBTITLE
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 mb...@wmi.amu.edu.pl writes:
On 2015-03-22, at 16:29, Rasmus ras...@gmx.us 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
[O] [OT] A short (less than a minute), informal survey about LaTeX
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
Marcin Borkowski mb...@wmi.amu.edu.pl writes:
On 2015-03-22, at 16:29, Rasmus ras...@gmx.us 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
[O] bug#18870: bug#18870: \emsp and alignment in org clock report
Nicolas Goaziou m...@nicolasgoaziou.fr 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] [OT] A short (less than a minute), informal survey about LaTeX
Marcin Borkowski mb...@wmi.amu.edu.pl 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] PATCH: Document how to scroll calendar by one year at date prompt.
Hi Nicolas,
* Nicolas Goaziou m...@nicolasgoaziou.fr [22. Mar. 2015]:
Gregor Zattler telegr...@gmx.net writes:
* Haustedt, Jens j.haust...@euroimmun.de [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-up/down 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] [ox, patch] Add #+SUBTITLE
Marcin Borkowski mb...@wmi.amu.edu.pl 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] fontenc makes pdf non-searchable
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.
Gregor Zattler telegr...@gmx.net 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,
Re: [O] [ox, patch] Add #+SUBTITLE
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 mb...@wmi.amu.edu.pl 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
Rasmus ras...@gmx.us writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Rasmus ras...@gmx.us writes: In ox-html, You might consider wrapping the title and subtitle in an hgroup 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] bug#18870: \emsp and alignment in org clock report
Hello, Ben Finney ben+em...@benfinney.id.au 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
[O] agenda timeline sorting and item insertion
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
[O] bug#18870: \emsp and alignment in org clock report
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 b...@benfinney.id.au signature.asc Description: Digital signature
Re: [O] [OT] A short (less than a minute), informal survey about LaTeX
Marcin Borkowski mb...@wmi.amu.edu.pl 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
Re: [O] [ox, patch] Add #+SUBTITLE
On 2015-03-22, at 23:43, Rasmus ras...@gmx.us wrote:
Marcin Borkowski mb...@wmi.amu.edu.pl 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
