Re: [O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes
Rasmus ras...@gmx.us writes: Quick but unrelated question. I'm updating the Worg page and I noticed that the customize-group for ox-koma-letter is org-export-koma-letter. Given that other groups are org-latex and org-html etc., should the group not be called org-koma-letter? Yes, org-koma-letter sounds better. Alan
Re: [O] [PATCH] Add autoload cookie for function org-table-iterate-buffer-tables
Hi Bastien, Bastien wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: In the same vein, I found `org-update-all-dblocks', for which I propose a patch hereafter. Applied against master, thanks. [...] From 3df73c03d9a8c56189cbe91ec752bcc3269536ca Mon Sep 17 00:00:00 2001 From: Sebastien Vauban s...@mygooglest.com Date: Wed, 18 Apr 2012 11:12:00 +0200 Subject: [PATCH 3/3] Add autoload cookie for org-update-all-dblocks * org.el (org-update-all-dblocks): Autoload function. When checking the status of some patches I provided, I just noticed that the function `org-update-all-dblocks' is NOT autoloaded anymore. Can you put the autoload cookie back? Thanks. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add autoload cookie for function org-table-iterate-buffer-tables
Hi Sébastien, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: When checking the status of some patches I provided, I just noticed that the function `org-update-all-dblocks' is NOT autoloaded anymore. Can you put the autoload cookie back? Thanks. Why is it necessary? -- Bastien
Re: [O] Moving by block in the block agenda
Hi Bart, Bart Bunting b...@bunting.net.au writes: I have a block agenda defined which is mostly taken from Bernt Hansen's org-mode.org. Some of the blocks contain many entries. I am trying to find out if there is a simple way to navigate between agenda blocks. The most likely thing I found was org-agenda-goto-block-beginning but it doesn't appear to do that. What am I missing? Nothing -- I just pushed a change in master which remap `backward-paragraph' and `forward-paragraph' to the new commands `org-agenda-backward-block' and `org-agenda-forward-block'. Let me know if it does what you want and thanks for raising this. Thanks, -- Bastien
Re: [O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes
Nicolas Goaziou n.goaz...@gmail.com writes: No. Other groups are `org-export-latex', `org-export-html'... Bastien b...@gnu.org writes: Unless I miss something, other groups are org-export-html org-export-latex etc. so org-export-koma-letter seems right. Right. That's a late night blunder on my part! Thanks for pointing me in the right direction. -- Er du tosset for noge' lårt!
Re: [O] unexpected link behavior in headlines - maybe bug
Hi John John Kitchin jkitc...@andrew.cmu.edu writes: I discovered an unexpected behavior with two links in a headline. The simplest example to reproduce it is here: * file:dft-course-mode.el [[file:my-theme.el][another file]] This is now fixed in maint, thanks for reporting this. -- Bastien
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Nicolas Goaziou n.goaz...@gmail.com writes: Here is the function. If it is good enough, I'll add tests and wrap it up in a patch. I don't think we should prevent users to convert a headline into a fixed-width line. Also, better to use the IGNORE-INVISIBLE arg of org-move-to-column IMO. Otherwise works fine, thanks! -- Bastien
Re: [O] [PATCH] Font-lock: allow hiding of brackets surrounding macros
Hi Florian, Bastien b...@gnu.org writes: Florian Beck f...@miszellen.de writes: I gave it a try. Well, I spend most of my time on formatting this patch. Hope it works. Works well, thanks. Unless someone is against this change, I'll apply it next week. This is now in master -- thanks! -- Bastien
[O] Behavior of M-q on comments in code blocks
Hello, Some time ago, doing a M-q on a comment in a code block did work. For example, the following: #+begin_src emacs-lisp ;; display symbol definitions, as found in the relevant manual (for AWK, C, Emacs Lisp, LaTeX, M4, Makefile, Sh and other languages that have documentation in Info) (global-set-key (kbd C-f1) 'info-lookup-symbol) #+end_src became: #+begin_src emacs-lisp ;; display symbol definitions, as found in the relevant manual (for AWK, C, ;; Emacs Lisp, LaTeX, M4, Makefile, Sh and other languages that have ;; documentation in Info) (global-set-key (kbd C-f1) 'info-lookup-symbol) #+end_src after `M-q' on the comment line (without going to the indirect buffer). This does not work anymore, as you can see on http://screencast.com/t/iauhzbvnmXXn. It even completely breaks the block itself. Though, I can't say whether the fact it does not work anymore is due to changes in Org or in my Emacs configuration. Any hint? Best regards, Seb -- Sebastien Vauban
Re: [O] Simple quote becomes double in LaTeX export
Hello Nicolas, Nicolas Goaziou wrote: Sebastien Vauban writes: With a text in French, and Babel present in my list of LaTeX classes, the following title gets its simple quote converted to a double one: [...] This should be fixed in maint. Thank you for reporting it. In a similar vain, though different, the following: --8---cut here---start-8--- #+LANGUAGE: fr * Note Avant, quand on faisait `M-q' sur un commentaire ... --8---cut here---end---8--- does generate the following when exported (to HTML, in this case): --8---cut here---start-8--- Avant, quand on faisait `M-q » sur un commentaire ... --8---cut here---end---8--- Now, let's be honest, I can completely understand that this wouldn't be a bug, because I used particular syntax (how variables are enclosed in Emacs Lisp documentation), which is not correct. Though, I wanted to report it, as I was surprised to see a single quote converted to a double French quote. Disregard this if needed! Best regards, Seb -- Sebastien Vauban
Re: [O] Quotes for LaTeX export
Hi Rasmus,
On Tue, Feb 4, 2014 at 10:42 PM, Rasmus ras...@gmx.us wrote:
Hi Laurens,
Laurens Van Houtven _...@lvh.io writes:
I'm writing a book using org-mode. On export, org-mode turns double
quotes
like hello into ``hello''. Some modern LaTeXes no longer support that
form, instead preferring semantic markup. (The reasoning being that the
markup implies a particular quote style, whereas quotation style is
language-dependent.)
This is not true. Quotes depend on your LANGUAGE-cookie. See
org-export-smart-quotes-alist.
To more accurately: *my* org-mode is turning double quotes into
``something'' when I export to LaTeX. I do not have an explicit language
cookie set. That is the part you objected to, not the LaTeX part, right?
As a result, I get
The preferred way to do that these days is, in the preamble:
\usepackage{csquotes}
... and then later:
\enquote{something}
But this would require us to load an extra package. Org is quite
capable of handling this on the lisp side (and Org ≠ LaTeX). Clearly,
we could have a org-export-user-smart-quote-alist taking priority over
the predefined one.
A package that, IIUC, is quite commonly available. Plus, the consequence is
that on a bunch of new setups, you get busted quotes, whereas the csquote +
enquote approach AFAIK works on pretty much any reasonable LaTeX
installation.
That said, if org does it, that's fine by me too.
I think it would make sense to support this for org, and perhaps
eventually
make it default behavior. FWIW: I had no idea about this until it bit me
when my LaTeX document suddenly had bogus quotes in it.
This has never happened to me, despite extensive usage of LaTeX for
almost ten years.
This is a fairly new occurrence, and it is not true for all LaTeXes
currently available. The motivation is the one that I have given above:
quotations are language-specific and semantic markup is preferable. I don't
have an exact list of which, but e.g. in ConTeXt MkIV it is now the
default, and it is also the default for me on the current TeX Live when
using lualatex or xelatex. This leads me to believe that perhaps it is not
a *common* issue, but it
Here is an example:
https://f.cloud.github.com/assets/97816/2078835/cac687b6-8dc2-11e3-8b6a-00c1a8175c94.png
If there is no interest to add this to org, how do I hack org so that this
is what it does?
The cleanest way would be a filter, probably
org-export-filter-quote-block-functions and filter-plain-text.
The easiest way would be a macro or simply redefining
org-export-smart-quotes-alist to suit your needs.
thanks!
lvh
Re: [O] Quotes for LaTeX export
On Wed, Feb 5, 2014 at 8:46 AM, Bastien b...@gnu.org wrote:
Nick Dokos ndo...@gmail.com writes:
IIRC, there was support for csquotes in the old exporter[fn:1] but I
guess
it went away when the new exporter came along.
Yes, it'd be good to make it possible again to use
\usepackage{csquotes} and \enquote{something}.
I guess it's obvious, but yes; I agree :)
hth
lvh
Re: [O] Behavior of M-q on comments in code blocks
Sebastien Vauban sva-n...@mygooglest.com writes: Hello, Some time ago, doing a M-q on a comment in a code block did work. For example, the following: I followed up to you post using gnus/message-mode with outorg (i.e. writing the mail in full org-mode), outcommented your first code block and did M-q on the comment line: #+begin_src emacs-lisp ;; display symbol definitions, as found in the relevant manual (for ;; AWK, C, Emacs Lisp, LaTeX, M4, Makefile, Sh and other languages ;; that have documentation in Info) (global-set-key (kbd C-f1) 'info-lookup-symbol) #+end_src the result looks fine, so it might be related to your config. PS #+BEGIN_SRC emacs-lisp (message %s (org-version)) #+END_SRC #+results: : 8.2.5g -- cheers, Thorsten
Re: [O] Behavior of M-q on comments in code blocks
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Though, I can't say whether the fact it does not work anymore is due to changes in Org or in my Emacs configuration. Any hint? Works fine here, surely something in your configuration. -- Bastien
Re: [O] Quotes for LaTeX export
Hi Laurens,
Laurens Van Houtven _...@lvh.io writes:
Hi Rasmus,
On Tue, Feb 4, 2014 at 10:42 PM, Rasmus ras...@gmx.us wrote:
Hi Laurens,
Laurens Van Houtven _...@lvh.io writes:
I'm writing a book using org-mode. On export, org-mode turns double
quotes
like hello into ``hello''. Some modern LaTeXes no longer support that
form, instead preferring semantic markup. (The reasoning being that the
markup implies a particular quote style, whereas quotation style is
language-dependent.)
This is not true. Quotes depend on your LANGUAGE-cookie. See
org-export-smart-quotes-alist.
To more accurately: *my* org-mode is turning double quotes into
``something'' when I export to LaTeX. I do not have an explicit language
cookie set. That is the part you objected to, not the LaTeX part, right?
The language is org-export-default-language if no LANGUAGE is set.
As a result, I get
The preferred way to do that these days is, in the preamble:
\usepackage{csquotes}
... and then later:
\enquote{something}
But this would require us to load an extra package. Org is quite
capable of handling this on the lisp side (and Org ≠ LaTeX). Clearly,
we could have a org-export-user-smart-quote-alist taking priority over
d the predefined one.
A package that, IIUC, is quite commonly available. Plus, the consequence is
that on a bunch of new setups, you get busted quotes, whereas the csquote +
enquote approach AFAIK works on pretty much any reasonable LaTeX
installation.
This is exactly the reasons why I don't want to use csquotes:
\enquote{something}.
But check for instance org-latex-tables-booktabs, which makes optional
support for booktabs. That kind of support for csquote is of course
OK. One reason I'd not use this is that the quotes exported to HTML
and LaTeX are no longer in sync. Which is why I'd rather see
customization through a user smart quote alist.
I think it would make sense to support this for org, and perhaps
eventually
make it default behavior. FWIW: I had no idea about this until it bit me
when my LaTeX document suddenly had bogus quotes in it.
This has never happened to me, despite extensive usage of LaTeX for
almost ten years.
This is a fairly new occurrence, and it is not true for all LaTeXes
currently available. The motivation is the one that I have given above:
See below.
quotations are language-specific and semantic markup is preferable.
Org already has semantic quote characters, namely '' and '.
Compare the output of
#+LANGUAGE: fr
#+OPTIONS: ':t
test
and
#+LANGUAGE: en
#+OPTIONS: ':t
test
I don't have an exact list of which, but e.g. in ConTeXt MkIV it is
now the default, and it is also the default for me on the current
TeX Live when using lualatex or xelatex. This leads me to believe
that perhaps it is not a *common* issue, but it
Here is an example:
https://f.cloud.github.com/assets/97816/2078835/cac687b6-8dc2-11e3-8b6a-00c1a8175c94.png
I'm unable to reproduce with TeXLive up-to-date 2013 with both XeLaTeX
and LuaLaTeX. I don't have context installed. Here's my code where I
tried to disable fancy features of fontspec:
\documentclass{article}
\usepackage{fontspec}
\addfontfeatures{Mapping=}
\addfontfeatures{Ligatures=}
\begin{document}
``test''
\end{document}
Could you share a snip that reproduces your problem?
–Rasmus
--
I hear there's rumors on the, uh, Internets. . .
Re: [O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes
Hello Rasmus, I applied the first patch, with the following small changes. This part would not apply: --8---cut here---start-8--- @@ -252,7 +258,7 @@ This option can also be set with the OPTIONS keyword, e.g.: :group 'org-export-koma-letter) (defcustom org-koma-letter-use-backaddress nil - Non-nil prints return address in small line above to address. + Non-nil prints return address in line above to address. This option can also be set with the OPTIONS keyword, e.g.: \backaddress:t\. :group 'org-export-koma-letter --8---cut here---end---8--- (because the string starts with Print now.) I just removed the small from the sentence, and some spurious white lines. Here is what I got: --8---cut here---start-8--- @@ -230,10 +236,8 @@ English manual of 2012-07-22). (string)) :group 'org-export-koma-letter) - - (defcustom org-koma-letter-use-backaddress nil - Print return address in small line above to address. + Print return address in line above to address. :group 'org-export-koma-letter :type 'boolean) --8---cut here---end---8--- (The line numbers are quite different ... there may be some edits on your side that have not made it to the patch.) I could not apply the second patch because the line numbers are too different. For instance, this chunk is supposed to start on line 266, not 336 here. --8---cut here---start-8--- @@ -336,6 +338,16 @@ This option can also be set with the OPTIONS keyword, e.g.: :group 'org-export-koma-letter :type 'boolean) +(defcustom org-koma-letter-use-title t + Non-nil means use a title in the letter if present. +This option can also be set with the OPTIONS keyword, +e.g. \with-title:nil\. + +See also `org-koma-letter-prefer-subject' for the handling of +title versus subject. + :group 'org-export-koma-letter + :type 'boolean) + (defcustom org-koma-letter-default-class default-koma-letter Default class for `org-koma-letter'. The value must be a member of `org-latex-classes'. --8---cut here---end---8--- Also, what is the text after the @@ in the first line? I can manually apply the patch (it's not that big), or you can regenerate it. Please let me know what you prefer. Best, Alan
Re: [O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes
Alan Schmitt alan.schm...@polytechnique.org writes: Hello Rasmus, I applied the first patch, with the following small changes. Please ignore this email, there was something wrong in my setup (I was in the maint branch ...). Sorry for the noise. Alan
Re: [O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes
Rasmus ras...@gmx.us writes: Alan Schmitt alan.schm...@polytechnique.org writes: Rasmus: do you want to change these, or should I do it and apply the patch? (The former would be simpler, I have to say.) Attached. Sorry about the delay. They should fix Nicholas' 'concerns'. Applied and pushed, thanks. Alan
[O] I erroneously pushed a documentation patch to maint
Hello,
I just did what I hope is a small mistake: I pushed the documentation
patch below (for ox-koma-letter.el) to maint instead of to master.
My first thought was that I could do another commit to remove this, but
then it would pollute the history of this branch. Hence my questions:
- should this commit be removed?
- if so, what the best way to proceed?
I'm very sorry for this blunder,
Alan
--8---cut here---start-8---
240cd3cb40fcc5f958eed7772e9520ef87bf9bd4 HEAD origin/maint maint
Author: Rasmus w...@pank.eu
Date: Sat Jan 25 14:08:15 2014 +0100
Documentation fixes for ox-koma-script.el
* ox-koma-letter.el commentary (org-koma-letter-use-backaddress):
Better documentation.
Signed-off-by: Alan Schmitt alan.schm...@polytechnique.org
1 file changed, 18 insertions(+), 14 deletions(-)
contrib/lisp/ox-koma-letter.el | 32 ++--
Modified contrib/lisp/ox-koma-letter.el
diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 2b7e847..a42a3a5 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -34,14 +34,14 @@
;; On top of buffer keywords supported by `latex' back-end (see
;; `org-latex-options-alist'), this back-end introduces the following
;; keywords:
-;; - CLOSING (see `org-koma-letter-closing'),
-;; - FROM_ADDRESS (see `org-koma-letter-from-address'),
-;; - LCO (see `org-koma-letter-class-option-file'),
-;; - OPENING (see `org-koma-letter-opening'),
-;; - PHONE_NUMBER (see `org-koma-letter-phone-number'),
-;; - SIGNATURE (see `org-koma-letter-signature')
-;; - PLACE (see `org-koma-letter-place')
-;; - and TO_ADDRESS. If unspecified this is set to \mbox{}.
+;; - CLOSING: see `org-koma-letter-closing',
+;; - FROM_ADDRESS: see `org-koma-letter-from-address',
+;; - LCO: see `org-koma-letter-class-option-file',
+;; - OPENING: see `org-koma-letter-opening',
+;; - PHONE_NUMBER: see `org-koma-letter-phone-number',
+;; - SIGNATURE: see `org-koma-letter-signature',
+;; - PLACE: see `org-koma-letter-place',
+;; - TO_ADDRESS: If unspecified this is set to \mbox{}.
;;
;; TO_ADDRESS and FROM_ADDRESS can also be specified using heading
;; with the special tags specified in
@@ -67,8 +67,9 @@
;; (see `org-koma-letter-special-tags-after-letter').
;;
;; The following variables works differently from the main LaTeX class
-;; - AUTHOR: default to user-full-name but may be disabled. (see
org-koma-letter-author),
-;; - EMAIL: same as AUTHOR, (see org-koma-letter-email),
+;; - AUTHOR: Default to user-full-name but may be disabled.
+;; (See also `org-koma-letter-author'),
+;; - EMAIL: Same as AUTHOR. (see also `org-koma-letter-email'),
;;
;; Headlines are in general ignored. However, headlines with special
;; tags can be used for specified contents like postscript (ps),
@@ -111,11 +112,16 @@
;; \[EXTRA]))
;;
;; Then, in your Org document, be sure to require the proper class
-;; with :
+;; with:
;;
;;#+LATEX_CLASS: my-letter
;;
;; Or by setting `org-koma-letter-default-class'.
+;;
+;; You may have to load (LaTeX) Babel as well, e.g., by adding
+;; it to `org-latex-packages-alist',
+;;
+;;(add-to-list 'org-latex-packages-alist '(AUTO babel nil))
;;; Code:
@@ -230,10 +236,8 @@ English manual of 2012-07-22).
(string))
:group 'org-export-koma-letter)
-
-
(defcustom org-koma-letter-use-backaddress nil
- Print return address in small line above to address.
+ Print return address in line above to address.
:group 'org-export-koma-letter
:type 'boolean)
--8---cut here---end---8---
[O] [bug] _ID in CUSTOM_ID being fontified as `org-latex-and-related'
Hello, As you can see on http://screencast.com/t/58dgm0sE1LgX, the _ID part of the string CUSTOM_ID is not fontified correctly: it should be `org-special-keyword' everywhere. Best regards, Seb -- Sebastien Vauban
Re: [O] I erroneously pushed a documentation patch to maint
Hi Alan, don't worry. ox-koma-letter.el is not yet part of Org core, so the fix in maint will not go into Emacs 24.4. And since we are close to merging master into maint (for 8.3), there is no real harm. Best, -- Bastien
Re: [O] [PATCH] Font-lock: allow hiding of brackets surrounding macros
Hello Florian and Bastien,
Bastien wrote:
Bastien b...@gnu.org writes:
Florian Beck f...@miszellen.de writes:
I gave it a try. Well, I spend most of my time on formatting this
patch. Hope it works.
Works well, thanks. Unless someone is against this change, I'll apply
it next week.
This is now in master -- thanks!
I just tested it.
I think that I would have left one pair of {} visible around macro calls
(for making it clear that it's something special, even if we can play
with the face `org-macro'); but, anyway, I find this to be a nice
improvement. Thanks for it!
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [bug] _ID in CUSTOM_ID being fontified as `org-latex-and-related'
Hi Sébastien, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: As you can see on http://screencast.com/t/58dgm0sE1LgX, the _ID part of the string CUSTOM_ID is not fontified correctly: it should be `org-special-keyword' everywhere. I can't reproduce this. What version of Org? Reproducible recipe? Thanks! -- Bastien
Re: [O] [PATCH] Font-lock: allow hiding of brackets surrounding macros
Hi Sébastien,
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:
I think that I would have left one pair of {} visible around macro calls
(for making it clear that it's something special, even if we can play
with the face `org-macro');
Playing with the face is the right thing to do I guess.
--
Bastien
Re: [O] [bug] _ID in CUSTOM_ID being fontified as `org-latex-and-related'
Bastien wrote: Sebastien Vauban writes: As you can see on http://screencast.com/t/58dgm0sE1LgX, the _ID part of the string CUSTOM_ID is not fontified correctly: it should be `org-special-keyword' everywhere. I can't reproduce this. What version of Org? Latest of the day! Reproducible recipe? Org file: --8---cut here---start-8--- * Test :PROPERTIES: :CUSTOM_ID: test :END: This is the 1^st time. --8---cut here---end---8--- Emacs configuration file: --8---cut here---start-8--- (load-theme 'leuven t) ;; highlight LaTeX and related syntax (setq org-highlight-latex-and-related '(latex script entities)) (require 'org) --8---cut here---end---8--- Se http://screencast.com/t/AT6TE0hE0dJ6. Best regards, Seb -- Sebastien Vauban
Re: [O] Quotes for LaTeX export
On Wed, Feb 5, 2014 at 1:12 PM, Rasmus ras...@gmx.us wrote:
This is exactly the reasons why I don't want to use csquotes:
\enquote{something}.
I'm not sure I understand. Are you suggesting the syntax is bad?
But check for instance org-latex-tables-booktabs, which makes optional
support for booktabs. That kind of support for csquote is of course
OK. One reason I'd not use this is that the quotes exported to HTML
and LaTeX are no longer in sync. Which is why I'd rather see
customization through a user smart quote alist.
Okay, that's a fair argument. It would require consistent configuration in
more than one place, unless (I think?) Org's LaTeX export automagically
use/configure Babel.
I think it would make sense to support this for org, and perhaps
eventually
make it default behavior. FWIW: I had no idea about this until it bit
me
when my LaTeX document suddenly had bogus quotes in it.
This has never happened to me, despite extensive usage of LaTeX for
almost ten years.
This is a fairly new occurrence, and it is not true for all LaTeXes
currently available. The motivation is the one that I have given above:
See below.
quotations are language-specific and semantic markup is preferable.
Org already has semantic quote characters, namely '' and '.
Right: I'm talking about TeX and not org-mode there. The semantic way to
say this is quoted is csquotes and \enquote.
Are those code points U+0022 QUOTATION MARK and U+0027 APOSTROPHE? (I am
not an org-mode expert. I'm assuming org-mode does operate on code points,
not bytes?)
\documentclass{article}
\usepackage{fontspec}
\addfontfeatures{Mapping=}
\addfontfeatures{Ligatures=}
\begin{document}
``test''
\end{document}
Could you share a snip that reproduces your problem?
That appears to compile correctly on my machine as well. Perhaps there is a
discrepancy between how I'm building the tex file and how org is building
the intermediary tex file. I will investigate :)
thanks again
lvh
Re: [O] Quotes for LaTeX export
Hello,
Laurens Van Houtven _...@lvh.io writes:
On Wed, Feb 5, 2014 at 8:46 AM, Bastien b...@gnu.org wrote:
Nick Dokos ndo...@gmail.com writes:
IIRC, there was support for csquotes in the old exporter[fn:1] but I
guess
it went away when the new exporter came along.
Yes, it'd be good to make it possible again to use
\usepackage{csquotes} and \enquote{something}.
I guess it's obvious, but yes; I agree :)
I'm still not convinced about the need to support this package out of
the box.
We already have a working solution for many languages, and more general
that this LaTeX-centered command. It has limitations, but csquotes
support would inherit them anyway since it would be built on top of
smart quotes mechanism.
If you want to csquotes, I suggest to:
1. Disable smart quotes.
2. Define a macro like:
#+MACRO: q \enquote{$1}
3. Call the macro when you need it:
{{{q(something)}}}
Regards,
--
Nicolas Goaziou
Re: [O] [bug] _ID in CUSTOM_ID being fontified as `org-latex-and-related'
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: ;; highlight LaTeX and related syntax (setq org-highlight-latex-and-related '(latex script entities)) Thanks. I see the bug (I'd say it's a minor annoyance, though). I don't know if Nicolas will have time to dive into this and fix `org-match-substring-regexp' (if that's the thing to do.) I'd rather not fiddle with this part of the code myself. -- Bastien
Re: [O] Quotes for LaTeX export
Hi Laurens,
Laurens Van Houtven _...@lvh.io writes:
On Wed, Feb 5, 2014 at 1:12 PM, Rasmus ras...@gmx.us wrote:
This is exactly the reasons why I don't want to use csquotes:
\enquote{something}.
I'm not sure I understand. Are you suggesting the syntax is bad?
I'm suggesting it makes adds noise that makes the source even harder
to read than it is. With Emacs you could of course make it look
pretty again. . .
But check for instance org-latex-tables-booktabs, which makes optional
support for booktabs. That kind of support for csquote is of course
OK. One reason I'd not use this is that the quotes exported to HTML
and LaTeX are no longer in sync. Which is why I'd rather see
customization through a user smart quote alist.
Okay, that's a fair argument. It would require consistent configuration in
more than one place, unless (I think?) Org's LaTeX export automagically
use/configure Babel.
To use Babel add (AUTO babel nil) to org-latex-packages-alist or
-default-package-alist. AUTO is replaced with the correct language.
Org already has semantic quote characters, namely '' and '.
Right: I'm talking about TeX and not org-mode there. The semantic way to
say this is quoted is csquotes and \enquote.
But this is the Org-ML. I assume you're interested in using Org for
producing your tex files?
Are those code points U+0022 QUOTATION MARK and U+0027 APOSTROPHE? (I am
not an org-mode expert. I'm assuming org-mode does operate on code points,
not bytes?).
On my computer I produce the quotation with S-2. On most layouts
these are the most straightforward quoting characters. If you use
smartquotes they are exported according to your language.
\documentclass{article}
\usepackage{fontspec}
\addfontfeatures{Mapping=}
\addfontfeatures{Ligatures=}
\begin{document}
``test''
\end{document}
Could you share a snip that reproduces your problem?
That appears to compile correctly on my machine as well. Perhaps there is a
discrepancy between how I'm building the tex file and how org is building
the intermediary tex file. I will investigate :)
I was not able to produce non-working files via Org either. . . But I
didn't test from emacs -q.
–Rasmus
--
C is for Cookie
Re: [O] [bug] _ID in CUSTOM_ID being fontified as `org-latex-and-related'
Hello, Bastien b...@gnu.org writes: I don't know if Nicolas will have time to dive into this and fix `org-match-substring-regexp' (if that's the thing to do.) I'd rather not fiddle with this part of the code myself. The only right way to fix is to use the parser for fontification. This is on my TODO list, but I first need to improve parser cache (hopefully before 8.3). IMO, we can live with this (and some others) fontification artifact until then. Regards, -- Nicolas Goaziou
Re: [O] Quotes for LaTeX export
On Wed, Feb 5, 2014 at 2:37 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: We already have a working solution for many languages, and more general that this LaTeX-centered command. It has limitations, but csquotes support would inherit them anyway since it would be built on top of smart quotes mechanism. This is only for LaTeX-export, so I don't see how LaTeX-centered is relevant. I really don't see how it affects other export langs; plus, it was in the old LaTeX exporter anyway! The reason is that the exporter occasionally produces TeX code that renders poorly on some setups (we're still figuring out which those are exactly). csquotes never does this. lvh
Re: [O] Behavior of M-q on comments in code blocks
Hi Thorsten and Bastien, Bastien wrote: Sebastien Vauban writes: Though, I can't say whether the fact it does not work anymore is due to changes in Org or in my Emacs configuration. Any hint? Works fine here, surely something in your configuration. Here is a reproducible recipe... Can you please try it, and confirm me you see the same things as I do? Org file: --8---cut here---start-8--- * Test The comment in the code block is not correctly refilled (on M-q). #+begin_src sh # display symbol definitions, as found in the relevant manual (for AWK, C, Emacs Lisp, LaTeX, M4, Makefile, Sh and other languages that have documentation in Info) echo Some text #+end_src --8---cut here---end---8--- Minimal Emacs configuration file: --8---cut here---start-8--- ;; Org mode (add-to-list 'load-path ~/Public/Repositories/org-mode/lisp) (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . t) (sh . t))) (find-file ~/test.org) (message Loading Minimal Emacs... Done) --8---cut here---end---8--- See the demo at http://screencast.com/t/fA0hIhnCQgbr. I just type M-q on the comment line and the lines are completely mixed up: --8---cut here---start-8--- #+begin_src sh # display symbol definitions, as found in the relevant manual (for AWK, C, Emacs Lisp, LaTeX, M4, Makefile, Sh and other languages that have documentation in Info) echo Some text #+end_src --8---cut here---end---8--- Best regards, Seb -- Sebastien Vauban
Re: [O] Quotes for LaTeX export
Hi Rasmus,
On Wed, Feb 5, 2014 at 2:44 PM, Rasmus ras...@gmx.us wrote:
Org already has semantic quote characters, namely '' and '.
Right: I'm talking about TeX and not org-mode there. The semantic way to
say this is quoted is csquotes and \enquote.
But this is the Org-ML. I assume you're interested in using Org for
producing your tex files?
Yes, that is the only thing I am doing. I am trying to get org's idea of
semantic quoting to map to LaTeX's idea of semantic quoting. As a result I
also don't understand why anyone cares what the \enquote{whatever} looks
like in the TeX file. Personally I only care what it looks like in Org.
This is also why I think the macro solution is bad. Org has semantic
quotes. It's just not doing a good job of convincing my LaTeX stack that it
has semantic quotes.
I was not able to produce non-working files via Org either. . . But I
didn't test from emacs -q.
The exported TeX source appears to be functionally equivalent to the
snippet you pasted, so the issue is probably in the TeX step.
thanks again,
lvh
Re: [O] Quotes for LaTeX export
Laurens Van Houtven _...@lvh.io writes: On Wed, Feb 5, 2014 at 2:37 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: We already have a working solution for many languages, and more general that this LaTeX-centered command. It has limitations, but csquotes support would inherit them anyway since it would be built on top of smart quotes mechanism. This is only for LaTeX-export, so I don't see how LaTeX-centered is relevant. I really don't see how it affects other export langs; The current quote mechanism is built at the export framework level so that each export back-end doesn't need to bring up its own recipe. I'd rather not add back-end specific code unless it is an improvement. So far, I don't see the improvement. Do you have an example of an Org document that produces a wrong tex file, which would be correct if it used csquotes? plus, it was in the old LaTeX exporter anyway! True. And? I gave you a solution to use csquotes feature in your documents. The reason is that the exporter occasionally produces TeX code that renders poorly on some setups (we're still figuring out which those are exactly). csquotes never does this. I assume it will render poorly in setups that do not use that package. I'm surprised that csquotes is compulsory in some setups. Of course, it would be good to know about them so we can find a workaround. Regards, -- Nicolas Goaziou
[O] [bug?] File contents of SETUPFILE's is read twice
Hello, It seems wrong to me that the SETUPFILE's are accessed twice. Here is the proof... Org file (containing a reference to a non-existing setup file): --8---cut here---start-8--- #+SETUPFILE: ~/missing-file.setup * Test Blah... --8---cut here---end---8--- Minimal Emacs configuration file: --8---cut here---start-8--- ;; Org mode (add-to-list 'load-path ~/Public/Repositories/org-mode/lisp) (find-file ~/test.org) --8---cut here---end---8--- Resulting *Messages* buffer: --8---cut here---start-8--- For information about GNU Emacs and the GNU system, type C-h C-a. Cannot read file d:/Users/fni/missing-file.setup [2 times] --8---cut here---end---8--- WDYT? (this could have a performance impact, even if marginal?) Best regards, Seb -- Sebastien Vauban
Re: [O] Behavior of M-q on comments in code blocks
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: I just type M-q on the comment line and the lines are completely mixed up: Actually M-q in shell-mode on the echo ... line will produce the problem. So I think you should first report this as an Emacs bug. -- Bastien
Re: [O] [bug?] File contents of SETUPFILE's is read twice
Hi Sébastien, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: It seems wrong to me that the SETUPFILE's are accessed twice. That's because setupfile is checked within `org-macro-initialize-templates' and `org-set-regexps-and-options', both called from org-mode. -- Bastien
Re: [O] Behavior of M-q on comments in code blocks
Bastien wrote: Sebastien Vauban writes: I just type M-q on the comment line and the lines are completely mixed up: Actually M-q in shell-mode on the echo ... line will produce the problem. So I think you should first report this as an Emacs bug. True for `M-q' on the second line (echo line) -- did know about that. I'll report it. Though, when doing it on the first line (comment), we don't have the same behavior whether the `M-q' is done on the code block itself (in the Org file) or in the indirect buffer: while the first fails, the latter does work as expected. See http://screencast.com/t/iwE7xbxKj. Best regards, Seb -- Sebastien Vauban
[O] [PATCH] `org-macro--collect-macros' can collect macro definitions from include files
Hello, As the DOCSTRING of the function `org-macro--collect-macros' tells it, it collects macro definitions in current buffer and setup files, not from INCLUDE files. This patch ensures that the above does work. From a8737be0b12ce700cd348c47f91694bfc0fbe7b8 Mon Sep 17 00:00:00 2001 From: Fabrice Niessen fni-n...@pirilampo.org Date: Wed, 5 Feb 2014 16:59:58 +0100 Subject: [PATCH] Collect macro definitions from INCLUDE files as well * org-macro.el (org-macro--collect-macros): INCLUDE files are looked up when searching for macro definitions. --- lisp/org-macro.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/org-macro.el b/lisp/org-macro.el index 50ce438..7f438ed 100644 --- a/lisp/org-macro.el +++ b/lisp/org-macro.el @@ -78,7 +78,7 @@ Return an alist containing all macro templates found. (org-with-wide-buffer (goto-char (point-min)) (while (re-search-forward - ^[ \t]*#\\+\\(MACRO\\|SETUPFILE\\): nil t) + ^[ \t]*#\\+\\(MACRO\\|SETUPFILE\\|INCLUDE\\): nil t) (let ((element (org-element-at-point))) (when (eq (org-element-type element) 'keyword) (let ((val (org-element-property :value element))) -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/
Re: [O] [PATCH] `org-macro--collect-macros' can collect macro definitions from include files
Fabrice Niessen fni-news-TA4HMoP+1wHrZ44/dzw...@public.gmane.org writes: As the DOCSTRING of the function `org-macro--collect-macros' tells it, it collects macro definitions in current buffer and setup files, not from INCLUDE files. Then your patch should change the docstring too. I think we want to collect macros from setupfile only, that's one of the differences between INCLUDE and SETUPFILE. But I'll let Nicolas review and decide. -- Bastien
Re: [O] Behavior of M-q on comments in code blocks
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org writes: Though, when doing it on the first line (comment), we don't have the same behavior whether the `M-q' is done on the code block itself (in the Org file) or in the indirect buffer: while the first fails, the latter does work as expected. See http://screencast.com/t/iwE7xbxKj. I've seen this but I've no time for this right now and the fix in Emacs will also fix this -- feel free to explore, of course! -- Bastien
[O] time tracking math is confusing
I hope there a general rule I'm missing or something I'm doing wrong, because I find the time tracking math in Org confusing. It seems that numbers I enter (ex: 8:00, 5d) are in units of 8-hour days. But math that Org does is in units of 24 hour days. So If I have * Task :PROPERTIES: :ID: test-task :END: ** SubTask 1 :PROPERTIES: :Effort: 5d :END: ** SubTask 2 :PROPERTIES: :Effort: 8:00 :END: Then the total work is 6 days (8 hour units, 48 hours) or 2d (24 hour units, 48 hours). This makes sense to me so far. When I make a time tracking table (i'm not sure of the function name, but C-c C-x i and then enter test-task at the prompt, I see the following table: #+BEGIN: cut-for-brevity | Task | Effort | |--+-+ | * Task | 2d 0:00 | | ** SubTask 1 | 5d | | ** SubTask 2 |8:00 | #+END: This is confusing because the units (24 hour, 8 hour) are mixed. The top row entry, 2d, is 24 hour units, but immedediately below it, the 5d entry is in 8 hour units, as is the 8:00 effort below that. I can work in either unit, but mixing is confusing. It seems human-entered times and estimates are 8 hour, and Org-calculated is 24 hour. Is this always correct? The issue then is that there is no clear indicator of what is human and what is Org on this table. -k.
Re: [O] any way how to look on what was done on particular day?
Thanks to all, yes, 'v L' is the stuff I'm looking for Eric S Fraga e.fr...@ucl.ac.uk writes: Have you tried v l or v L from within the agenda view on the particular day? It should show some of the activities you want. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.1, Org release_8.2.5h-585-g5f0ca0
Re: [O] [PATCH] `org-macro--collect-macros' can collect macro definitions from include files
Hello, Bastien b...@gnu.org writes: Fabrice Niessen fni-news-TA4HMoP+1wHrZ44/dzw...@public.gmane.org writes: As the DOCSTRING of the function `org-macro--collect-macros' tells it, it collects macro definitions in current buffer and setup files, not from INCLUDE files. Then your patch should change the docstring too. I think we want to collect macros from setupfile only, that's one of the differences between INCLUDE and SETUPFILE. I agree. Not all Include files are Org files. Moreover, INCLUDE keywords are expanded before initializing macro templates during export, so MACRO keywords should be read when appropriate. Regards, -- Nicolas Goaziou
[O] Auto-refreshing rendered images from org-babel
I have the org snippet below. What I would like, is to see the rendered image
when I press C-c C-c. I can achieve this with the elisp snippet below. Is there
a proper, or at least a better way of doing this?
Evgeni
#+BEGIN_SRC dot :file files/graphviz/example1.png
digraph test {
size=6,5;
home [label = Home];
prod [label = Products];
news [label = News];
cont [label = Contact];
home - {prod news cont}
}
#+END_SRC
(org-babel-do-load-languages
'org-babel-load-languages
'((dot . t)
))
(defadvice org-babel-execute:dot (after refresh-images activate)
(run-with-timer 1 nil 'org-display-inline-images))
[O] Agenda views skip function hide parent projects
Hello all. I am sure this is documented somewhere, but I cant seem to put together the correct custom agenda view to support my way of project planning I have the following todo keywords defined : TODO NEXT DONE WAIT I like to list everything as a TODO, even if sub items may be a TODO, like this ** TODO Main Test Project *** TODO Main sub project 1 NEXT first task *** TODO Main sub project 2 (stuck) What I would like to see is : on my projects list TODO Main sub project 1 The problem is that my project list looks like this TODO Main Test Project TODO Main sub project 1 I have some projects that are 4 levels deep, so this is quite annoying. How do I get just the deepest level project to show without it's parents ? here is my custom agenda view for projects (p @Projects tags-todo -IGNORE-someday-wait/TODO ( (org-agenda-overriding-header @Projects) (org-agenda-tags-todo-honor-ignore-options t) (org-agenda-skip-function (lambda nil (org-agenda-skip-subtree-if (quote notregexp) \\* NEXT) ) ) Thank you in advance -Tim
Re: [O] Agenda views skip function hide parent projects
Wiskey 5 Alpha wiskey5al...@gmail.com writes: Hello all. I am sure this is documented somewhere, but I cant seem to put together the correct custom agenda view to support my way of project planning I have the following todo keywords defined : TODO NEXT DONE WAIT I like to list everything as a TODO, even if sub items may be a TODO, like this ** TODO Main Test Project *** TODO Main sub project 1 NEXT first task *** TODO Main sub project 2 (stuck) What I would like to see is : on my projects list TODO Main sub project 1 The problem is that my project list looks like this TODO Main Test Project TODO Main sub project 1 I have some projects that are 4 levels deep, so this is quite annoying. How do I get just the deepest level project to show without it's parents ? I highly recommend reading this: http://doc.norang.ca/org-mode.html In particular, if you read this section http://doc.norang.ca/org-mode.html#Projects you will find functions that tell you if something is a project (i.e., is a task with a subtask). I guess one could write something like this: #+begin_src emacs-lisp (defun bh/has-subproject-p () Any task with a todo keyword subtask that is a project (save-restriction (widen) (let ((has-subproject) (subtree-end (save-excursion (org-end-of-subtree t))) (is-a-task (member (nth 2 (org-heading-components)) org-todo-keywords-1))) (save-excursion (forward-line 1) (while (and (not has-subproject) ( (point) subtree-end) (re-search-forward ^\*+ subtree-end t)) (when (bh/is-project-p) (setq has-subproject t (and is-a-task has-subtask #end_src then combine is-project-p and has-subproject-p to decide whether to include something. Alan
Re: [O] Agenda views skip function hide parent projects
it would be interesting to do this with dimming ancestors instead of skipping them. how would you do that? it would also be interesting to dim descendants. there is the blocked task concept, but that is different. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] [PATCH] `org-macro--collect-macros' can collect macro definitions from include files
Hello, Nicolas Goaziou wrote: Bastien b...@gnu.org writes: Fabrice Niessen writes: As the DOCSTRING of the function `org-macro--collect-macros' tells it, it collects macro definitions in current buffer and setup files, not from INCLUDE files. Then your patch should change the docstring too. Right! I think we want to collect macros from setupfile only, that's one of the differences between INCLUDE and SETUPFILE. I agree. Not all Include files are Org files. OK, but that shouldn't be a problem either: if there is no #+MACRO in an Include file, that doesn't matter... Moreover, INCLUDE keywords are expanded before initializing macro templates during export, so MACRO keywords should be read when appropriate. You say that the order of operations, during export, is: - Include files through INCLUDE keywords - Expand macros OK. Still, I don't understand what you mean by so MACRO keywords should be read when appropriate? Anyway, let me explain what I wish such a feature (_or_ the opposite: that Babel blocks are allowed in SETUPFILE)... I'm sharing on GitHub a project [1] where I write Org macros that everybody could once need, and these are easily accessible (once cloned) in every file, after a simple directive such as: #+INCLUDE: /path/to/org-macros.setup As I do have Babel code blocks inside the `org-macros.setup' file, it needs to be loaded via the INCLUDE directive, not via a SETUPFILE. Example of such macro calling a Babel code block: ╭ │ #+name: version-history │ #+begin_src sh :exports none :results silent :colnames '(Version Date Author Comment) │ git log --pretty=format:%h%x09%ad%x09%an%x09%s --date=short | head -n 5 │ #+end_src │ │ #+MACRO: version-history call_version-history[:eval yes]()[:eval yes :results table :colnames '(Version Date Author Comment)] ╰ So, thanks to the INCLUDE directive, I already have a one-liner to include such extended macros. But these aren't collected by `org-macro--collect-macros'... Best regards, Fabrice [1] https://github.com/fniessen/org-macros -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/
[O] org-map-entries moves point
When I call org-map-entries with scope set to 'tree, the current heading gets realigned to the top. Behold: (org-map-entries (lambda () ;; do something or even nothing ) nil 'tree) I think the culprit is the call to `org-agenda-prepare-buffers', or rather commit fe3379bda6ca23474639b114592958bf14431c88, which replaces save-excursion with save-window-excursion. What's interesting: This does NOT restore the window configuration. When I replace save-window-excursion with save-excursion the window configuration is restored again. I'm not sure *why* this happens. -- Florian Beck
[O] Behavior of Org mode Babel code snippets with respect to M-q (fill-paragraph) and C-/ (undo)
Hello, I am using Org-mode version 8.2.5g (8.2.5g-elpa) in GNU Emacs 24.3.1. I have two questions about the behavior of the fantastic Org mode+Babel with respect to code and comments: Here is a minimal example: #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very very very very very long comment line. print *, Hello, World! end program main #+END_SRC Below is the code snippet after M-q (fill-paragraph) on the comment line. The comment line has been refilled (intended behavior) but all lines have been indented. This may also be an intended behavior; but FIRST QUESTION: Is there a way to disable this indentation upon M-Q in Org Babel code snippets? #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very ! very very very very long comment line. print *, Hello, World! end program main #+END_SRC Below is the code snippet after a C-/ (undo). Note that the indentation and the refill which were done by the last command above (M-q) are not being undone. The text in the comment is being removed which I believe means that the previous (self-insert-command)'s that created the text are being undone. This is very undesirable since even a user who is aware of this behavior may by mistake issue the command M-q, have the code snippet formatted in an undesirable way (e.g., sometimes new lines are not respected and code and comments get mixed up), without any immediate way to undo this reformatting. SECOND QUESTION: How can one get the usual (undo) behavior in a Babel code snippet? #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very ! very v comment line. print *, Hello, World! end program main #+END_SRC Please note that these edits are done in the Org mode buffer directly. If I switch to the native language mode using C-c ' things work as expected. Thanks, Omid
Re: [O] Agenda views skip function hide parent projects
On Wed, Feb 5, 2014 at 2:40 PM, Alan Schmitt alan.schm...@polytechnique.org wrote: I highly recommend reading this: http://doc.norang.ca/org-mode.html Alan Thank you for the reply. I was hoping there was a function that did the opposite of '(org-tags-list-sublevels nil)'. But if not, I will have to do something similar to your suggestion. -Tim
Re: [O] [bug?] File contents of SETUPFILE's is read twice
Hi Bastien, Bastien wrote: Sebastien Vauban writes: It seems wrong to me that the SETUPFILE's are accessed twice. That's because setupfile is checked within `org-macro-initialize-templates' and `org-set-regexps-and-options', both called from org-mode. So, you mean that SETUPFILE *must* be read twice, right? I understand the first call. The second one (in `org-set-regexps-and-options') stays a bit cryptic to me, right now. Best regards, Seb -- Sebastien Vauban
Re: [O] org-map-entries moves point
Florian Beck f...@miszellen.de writes: When I call org-map-entries with scope set to 'tree, the current heading gets realigned to the top. Behold: (org-map-entries (lambda () ;; do something or even nothing ) nil 'tree) I think the culprit is the call to `org-agenda-prepare-buffers', or rather commit fe3379bda6ca23474639b114592958bf14431c88, which replaces save-excursion with save-window-excursion. What's interesting: This does NOT restore the window configuration. When I replace save-window-excursion with save-excursion the window configuration is restored again. I'm not sure *why* this happens. John Kitchin reported this last week and Bastien reverted that commit: http://thread.gmane.org/gmane.emacs.orgmode/81587 But it's not clear *why* that commit was done in the first place so if you get some enlightenment from your experiments, please share. Nick
Re: [O] bug: Please save the buffer to a file before refiling when the buffer is already saved
one thing i don't understand is why there need to be 2 olpaths for the identical location. in maint i get both in ido [when it is in same file]. i only need 1 [always]. the bugs aside, there is no reason to /have/ to choose one. right? so why are 2 included? On 1/29/14, Bastien b...@gnu.org wrote: Hi Samuel, Samuel Wales samolog...@gmail.com writes: i have very little capacity to do this properly, doing the best i can so you get timely feedback. perhaps this gives you a little to go on. if not, this will take much longer. Thanks -- I'll explore this using ido, which I do not use ordinarily. If other users want to chim in and test, that'd be great too, especially for the bugfixes I explained in my previous email. -- Bastien -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] Behavior of Org mode Babel code snippets with respect to M-q (fill-paragraph) and C-/ (undo)
Omid omidl...@gmail.com writes: Hello, I am using Org-mode version 8.2.5g (8.2.5g-elpa) in GNU Emacs 24.3.1. I have two questions about the behavior of the fantastic Org mode+Babel with respect to code and comments: Here is a minimal example: #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very very very very very long comment line. print *, Hello, World! end program main #+END_SRC Below is the code snippet after M-q (fill-paragraph) on the comment line. The comment line has been refilled (intended behavior) but all lines have been indented. This may also be an intended behavior; but FIRST QUESTION: Is there a way to disable this indentation upon M-Q in Org Babel code snippets? Try setting org-edit-src-content-indentation to 0. I'm not sure that it is going to work, but (based on rather flimsy numerological evidence, namely that its default value is 2 as is the indent below) it might. #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very ! very very very very long comment line. print *, Hello, World! end program main #+END_SRC BTW, I don't get this behavior but I don't use f90 mode, so I'm not sure whether there is some setup I'm missing. I get (with org-edit-src-content-indentation set to 0): #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very very very very very long comment line. print *, Hello, World! end program main #+END_SRC Nick
Re: [O] org-map-entries moves point
On 05.02.2014 21:59, Nick Dokos wrote: John Kitchin reported this last week and Bastien reverted that commit: http://thread.gmane.org/gmane.emacs.orgmode/81587 Missed that. But this reverts commit 3ec38f5c064c3270f54876ba33c5ca1097b46853 [1] (in org-map-entries) I was talking about fe3379bda6ca23474639b114592958bf14431c88 [2] (which did the same to org-agenda-prepare-buffer) In fact, the revert *caused* my bug. Again, the recipe: The bug doesn't really move the point, rather it recenters the current line. To see it, move into the middle of a document, unfold a second level headline and in the middle of the window execute (org-map-entries (lambda () ;; do something or even nothing ) nil 'tree) This works correctly if either commit [1] is restored or [2] is reverted. But it's not clear *why* that commit was done in the first place so if you get some enlightenment from your experiments, please share. Will do. Nick -- Florian Beck
Re: [O] org-map-entries moves point
Florian Beck f...@miszellen.de writes: On 05.02.2014 21:59, Nick Dokos wrote: John Kitchin reported this last week and Bastien reverted that commit: http://thread.gmane.org/gmane.emacs.orgmode/81587 Missed that. But this reverts commit 3ec38f5c064c3270f54876ba33c5ca1097b46853 [1] (in org-map-entries) I was talking about fe3379bda6ca23474639b114592958bf14431c88 [2] (which did the same to org-agenda-prepare-buffer) In fact, the revert *caused* my bug. Again, the recipe: The bug doesn't really move the point, rather it recenters the current line. To see it, move into the middle of a document, unfold a second level headline and in the middle of the window execute (org-map-entries (lambda () ;; do something or even nothing ) nil 'tree) This works correctly if either commit [1] is restored or [2] is reverted. Does all of [2] have to be reverted? Or can save-window-excursion be changed back to save-excursion? AFAICT, the rest of the fix is independent of that. -- Nick
Re: [O] Behavior of Org mode Babel code snippets with respect to M-q (fill-paragraph) and C-/ (undo)
Hello Nick, Thanks for your quick reply. The variable org-edit-src-content-indentation does indeed have to do with the indentation I was referring to. But it is relative. According to the documentation, it sets the Indentation for the content of a source code block. This should be the number of spaces added to the indentation of the #+begin line in order to compute the indentation of the block content after editing it with M-x org-edit-src-code. Has no effect if `org-src-preserve-indentation' is non-nil. I wonder if one can set it to be zero as an absolute value, meaning that if the a line of code in the source block starts at column n of the buffer, it is left at column n after M-q. Regarding the behavior you observe, as I said I get that too from time to time. In fact, doing M-q on my own example in a fresh Org mode buffer, I now get what you get: #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very very very very very long comment line. print *, Hello, World! end program main #+END_SRC I don't have any special settings for the f90 mode in my .emacs. In fact, I have observed the same behavior for other languages too when edited in an Org source block. The destructive nature of this behavior is very special (C-/ (undo) doesn't work). Many a times, I have tried refilling a line of comments and ended up with a huge mix of code and comment that was impossible to undo (at least to the best of my knowledge) and I had to either revert the change if I had the file under version control, go to an auto backup file, or painfully and manually separate the code and comments to get back the original code block. Omid On 02/05/2014 04:34 PM, Nick Dokos wrote: Omid omidl...@gmail.com writes: Hello, I am using Org-mode version 8.2.5g (8.2.5g-elpa) in GNU Emacs 24.3.1. I have two questions about the behavior of the fantastic Org mode+Babel with respect to code and comments: Here is a minimal example: #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very very very very very long comment line. print *, Hello, World! end program main #+END_SRC Below is the code snippet after M-q (fill-paragraph) on the comment line. The comment line has been refilled (intended behavior) but all lines have been indented. This may also be an intended behavior; but FIRST QUESTION: Is there a way to disable this indentation upon M-Q in Org Babel code snippets? Try setting org-edit-src-content-indentation to 0. I'm not sure that it is going to work, but (based on rather flimsy numerological evidence, namely that its default value is 2 as is the indent below) it might. #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very ! very very very very long comment line. print *, Hello, World! end program main #+END_SRC BTW, I don't get this behavior but I don't use f90 mode, so I'm not sure whether there is some setup I'm missing. I get (with org-edit-src-content-indentation set to 0): #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very very very very very long comment line. print *, Hello, World! end program main #+END_SRC Nick
Re: [O] org-map-entries moves point
Hi Florian, Florian Beck f...@miszellen.de writes: Missed that. But this reverts commit 3ec38f5c064c3270f54876ba33c5ca1097b46853 [1] (in org-map-entries) I was talking about fe3379bda6ca23474639b114592958bf14431c88 [2] (which did the same to org-agenda-prepare-buffer) In fact, the revert *caused* my bug. Again, the recipe: The bug doesn't really move the point, rather it recenters the current line. To see it, move into the middle of a document, unfold a second level headline and in the middle of the window execute (org-map-entries (lambda () ;; do something or even nothing ) nil 'tree) This works correctly if either commit [1] is restored or [2] is reverted. I partially revert [2] (only replacing `save-window-excursion' by `save-excursion') and didn't touch [1] -- if we can produce a bug from there, let's fix it the right way this time. Thanks in advance for digging further, -- Bastien
Re: [O] Auto-refreshing rendered images from org-babel
E Sabof esa...@gmail.com writes: I have the org snippet below. What I would like, is to see the rendered image when I press C-c C-c. I can achieve this with the elisp snippet below. Is there a proper, or at least a better way of doing this? Not tested but should work: (add-hook 'org-babel-after-execute-hook 'org-redisplay-inline-images) HTH, -- Bastien
Re: [O] bug: Please save the buffer to a file before refiling when the buffer is already saved
Samuel Wales samolog...@gmail.com writes: one thing i don't understand is why there need to be 2 olpaths for the identical location. Well, this is the part of the bug that I never managed to reproduce. If you have time for a recipe that produces just this bug, let's go. I wish someone else could report the same bug too -- that'd give us another perspective, and more food for thought. Anyway, I hope we can fix this soon. -- Bastien
Re: [O] Moving by block in the block agenda
Thanks! Works wonderland wonderfully. Kind regards Bart Bastien b...@gnu.org writes: Hi Bart, Bart Bunting b...@bunting.net.au writes: I have a block agenda defined which is mostly taken from Bernt Hansen's org-mode.org. Some of the blocks contain many entries. I am trying to find out if there is a simple way to navigate between agenda blocks. The most likely thing I found was org-agenda-goto-block-beginning but it doesn't appear to do that. What am I missing? Nothing -- I just pushed a change in master which remap `backward-paragraph' and `forward-paragraph' to the new commands `org-agenda-backward-block' and `org-agenda-forward-block'. Let me know if it does what you want and thanks for raising this. Thanks, -- Bastien Bart -- Kind regards Bart
Re: [O] [babel] cannot comment out noweb references
Samuel Wales samolog...@gmail.com writes: hi eric, #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever a #+END_SRC # #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever # b # #+END_SRC #+BEGIN_SRC sh :results output :noweb yes echo whatever #+END_SRC it is a bug that babel tries to use b. babel tries to use COMMENT comments also. samuel When executing the last code block I get the expected output, namely a. #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever a #+END_SRC # #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever # b # #+END_SRC #+BEGIN_SRC sh :results output :noweb yes echo whatever #+END_SRC #+RESULTS: : a Best, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] [babel] shell does not unquote
Use org-babel-expand-block (C-c C-v v) to view the code block with the variable expansion. Best, Samuel Wales samolog...@gmail.com writes: i don't know why the shell does not unquote here: #+BEGIN_SRC sh :results verbatim output :var how=a 'b' \c \d\ e :var dothis=echo \hi\ echo $how $dothis #+END_SRC #+RESULTS: #+begin_example a 'b' c d e hi #+end_example thanks. samuel -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
[O] How to get effort summary in clocktable in agenda?
Hi, i've got an agenda report that includes a clocktable that looks like this: | File | Effort | ALLTAGS | Headline | Time | |--++-+--+| | | ALL| | *Total time* | *8:24* | |--++-+--+| | Work-log.org || | *File time* | *8:24* | | || :514: | PPTDEV-514 Miscellaneous | 1:06 | | || :514: | \__ W06 email, morning | 1:06 | | || :513: | PPTDEV-513 smt 2014 Meetings | 0:17 | | || :513: | \__ Standup | 0:17 | | || | PPTDEV-318 HVE Industry - Feed runner... | 4:47 | | | 0:15 | | \__ SPEC redo spec with RDE | 1:39 | | || | \__ TODO Modify... | 3:08 | | || :389: | JWRK PPTDEV-389 VBA macros | 2:14 | | || :389: | \__ Notes | 2:14 | What I'd really love to have is a column that shows the summarized Effort estimate for the top level headings. IE PPTDEV-318-HVE Industry has a time summary of 4:47 for the day, but only shows the the effort estimate for the individual subtasks that are displayed. If I increase the task level I can see more of the underlying structure, but not a summary. Is there a variable I'm missing here to set up my column as a summary? While I'm at it, is there an easy way to include a calculated column in the clock table (either in the agenda or one generated in my org file) that would show Effort - time for a given headline? Thanks! Subhan -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
[O] semantic-mode is conflict with org-mode
semantic-mode uses `C-c ,' as a prefix for several commands. org-mode uses `C-c ,' for org-priority. I don't use semantic-mode within org-mode. Is there a way to disable semantic-mode just in org-mode buffers in Emacs? If so, can someone include in in [[info:org#Conflicts]]? (I'm using Org 8.2.5c on Emacs 24.3.50.) -- http://www.gnu.org/software/emacs/
[O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi, when using the Shift-enter feature in a table to copy values down, it fails to place the cursor where you expect it to if the previous column has a fixed width and the contents of the cell is truncated. Steps to reproduce: enter the following org table: | | 7 | | |---+-+---| | 4 | podsdfsfsadastatoes | 1 | | 5 | podsdfsfsadastatoes | 2 | | 6 | | | press C-c C-c to ensure the second column is showing abbreviated. place cursor on the number 1, Shift-enter copies values to the next line but leaves the cursor in the wrong position, at the end of the string in the row that starts with 5 if you remove the 7 and repeat the experiment, the cursor moves down the third column as you expect it to. I expect it should work the same whether or not the previous column has truncated contents. Emacs : GNU Emacs 24.3.50.2 (i686-pc-cygwin) of 2014-01-15 on jade Package: Org-mode version 8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/) current state: == (setq org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-latex-format-headline-function 'org-latex-format-headline-default-function org-html-format-inlinetask-function 'ignore outline-minor-mode-hook '(mediawiki-outline-magic-keys) org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-refile-targets '((nil :maxlevel . 9) (org-agenda-files :maxlevel . 9)) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default org-babel-pre-tangle-hook '(save-buffer) org-occur-hook '(org-first-headline-recenter) org-html-format-headline-function 'ignore org-metaup-hook '(org-babel-load-in-session-maybe) org-confirm-elisp-link-function 'yes-or-no-p org-default-notes-file ~/Dropbox/org/todo.org org-latex-format-drawer-function '(lambda (name contents) contents) org-blank-before-new-entry nil org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-mode-hook '(#[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes (lambda nil (flyspell-mode -1))) org-ascii-format-drawer-function '(lambda (name contents width) contents) org-directory ~/Dropbox/org org-from-is-user-regexp \\jason\\ org-html-format-drawer-function '(lambda (name contents) contents) org-metadown-hook '(org-babel-pop-to-session-maybe) org-agenda-files '(~/Dropbox/org/todo.org ~/Dropbox/org ~/Dropbox/org/todo.org) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-after-todo-state-change-hook '(org-clock-out-if-current) org-latex-format-inlinetask-function 'ignore org-M-RET-may-split-line '((default)) org-confirm-shell-link-function 'yes-or-no-p ) signature.asc Description: OpenPGP digital signature
Re: [O] Auto-refreshing rendered images from org-babel
Thanks. I've changed it to the version below, which covers my needs. I think it would make sense as a (default?) feature for ob-dot, ob-ditaa, and any other babel language that renders images. Evgeni ;; Must be defined in a lexical environment (defun es-org-babel-refresh-images-after-execution () (let (refresh-and-remove-self) (setq refresh-and-remove-self (lambda () (org-redisplay-inline-images) (remove-hook 'org-babel-after-execute-hook refresh-and-remove-self))) (add-hook 'org-babel-after-execute-hook refresh-and-remove-self))) (defadvice org-babel-execute:dot (after refresh-images activate) (es-org-babel-refresh-images-after-execution)) Bastien b...@gnu.org writes: E Sabof esa...@gmail.com writes: I have the org snippet below. What I would like, is to see the rendered image when I press C-c C-c. I can achieve this with the elisp snippet below. Is there a proper, or at least a better way of doing this? Not tested but should work: (add-hook 'org-babel-after-execute-hook 'org-redisplay-inline-images) HTH,
[O] Feature request: filling of long captions
Hi all, a currently active thread about filling (http://permalink.gmane.org/gmane.emacs.orgmode/77700) reminded me of a long standing wish of mine: Filling of captions. Would it be possible to have filling of captions? Ideally that would mean at least two things: auto-fill and M-q working on long captions. Example: --8---cut here---start-8--- #+name: test #+begin_src R :results graphics :file tettr.png plot(1:10, 1:10) #+end_src #+results: test [[file:tettr.png]] #+caption: A very long long long long long long long long long long long long long long long long long long long long long long long long long long caption. [[file:tettr.png]] It would be very convenient if that could be automatically broken to #+caption: A very long long long long long long long long long long long long long long #+caption: long long long long long long long long long long long long caption. [[file:tettr.png]] --8---cut here---end---8--- Regards, Andreas
Re: [O] [babel] cannot comment out noweb references
I get this: Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil) org-babel-expand-noweb-references(nil) org-babel-expand-noweb-references((sh echo whatever2 ((:comments . ) (:shebang . ) (:cache . no) (:padline . ) (:noweb . yes) (:tangle . no) (:exports . code) (:results . replace output) (:session . none) (:hlines . no) (:result-type . output) (:result-params output replace) (:rowname-names) (:colname-names)) nil 0 #marker at 2309 in bug.org)) org-babel-execute-src-block(nil) org-babel-execute-src-block-maybe() org-babel-execute-maybe() org-babel-execute-safely-maybe() run-hook-with-args-until-success(org-babel-execute-safely-maybe) org-ctrl-c-ctrl-c(nil) call-interactively(org-ctrl-c-ctrl-c nil nil) On 2/5/14, Eric Schulte schulte.e...@gmail.com wrote: When executing the last code block I get the expected output, namely a. #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever a #+END_SRC # #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever # b # #+END_SRC #+BEGIN_SRC sh :results output :noweb yes echo whatever #+END_SRC #+RESULTS: : a Best, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
