Re: [O] org-babel src block generated graphics included twice if CAPTION is added
Eric Schulte writes: I just pushed up a patch which should allow code blocks to find un-named results even when there are comment lines (such as #+options or #+attr_backend) between the code block and the results. Shouldn't babel use org-element for things like this? Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [O] Syntax of Org Babel :results header argument
t...@tsdye.com (Thomas S. Dye) writes: Eric Schulte schulte.e...@gmail.com writes: Bastien b...@altern.org writes: Hi Sébastien, Sebastien Vauban wxhgmqzgw...@spammotel.com writes: As there was no reaction to this, I'd like to bump it up. At least, to either have a discussion on this, or a clearly stated no go. I tend to agree with Jay here and I prefer the minimalist syntax, although values for the :results parameter are heterogeneous. +1 for maintaining the existing concise syntax. +1 for stable syntax. +1 one more vote Andreas
[O] [PATCH] Enable appending to multivalued-property
Hi List, sometimes it make more sense to append a new value to a multivalued-property than putting it in front of the old values, so here is a patch that enables this: From ca1c5585fd7e57b559d360d3cbcc69b1deb18c98 Mon Sep 17 00:00:00 2001 From: tj t...@data-driven.de Date: Mon, 18 Mar 2013 10:40:54 +0100 Subject: [PATCH 2/2] Org: enable appending to multivalued property * org.el (org-entry-add-to-multivalued-property): Add optional argument APPEND to enable insertion of added value at the end of the multivalued property list. As an example, adding a new year to a property :copyright-years: should result in something like '2012 2013' and not '2013 2012'. --- lisp/org.el | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index a1fa315..33ade96 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15089,13 +15089,17 @@ an empty drawer to delete. ;; Multi-values properties are properties that contain multiple values ;; These values are assumed to be single words, separated by whitespace. -(defun org-entry-add-to-multivalued-property (pom property value) +(defun org-entry-add-to-multivalued-property + (pom property value optional APPEND) Add VALUE to the words in the PROPERTY in entry at point-or-marker POM. (let* ((old (org-entry-get pom property)) (values (and old (org-split-string old [ \t] (setq value (org-entry-protect-space value)) (unless (member value values) - (setq values (cons value values)) + (setq values + (if APPEND + (add-to-list 'values value 'APPEND) + (cons value values))) (org-entry-put pom property (mapconcat 'identity values ) -- 1.8.2 -- cheers, Thorsten
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi Z, can you show an example on how you use it? Maybe we can find a better way. Nicolas is right that portability is compromised by customizable emphasis. - Carsten On 18.3.2013, at 00:02, zeltak zel...@gmail.com wrote: Hi all i just finished a great conversation on #org-mode with some great people. they told me about this thread and the planned changes that may or may not occur to the syntax and id like to just raise the newbee perspective. I find the ability to add custom emphasise with custom faces invaluable. i find it very easy to add and very useful for me since i use ALOT of color highlights in my academic work. i really hope that there is some way to leave the current mphasise with custom faces options as is thx alot guys Z
[O] Bug: The `#+CAPTION' isn't documented well [7.9.3f (release_7.9.3f-17-g7524ef @ /usr/local/share/emacs/24.3.50/lisp/org/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
In [info:org#Images and tables]:
Optionally, the caption can take the form:
#+CAPTION: [Caption for list of figures]{Caption for table (or link).}
The Org manual doesn't explain what this form means clearly. And I also
can't find it in the FAQ and the mailing list archives.
Emacs : GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.6.0)
of 2013-03-17 on Emacs
Package: Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @
/usr/local/share/emacs/24.3.50/lisp/org/)
--
Xue Fuqiao
http://www.gnu.org/software/emacs/
[O] Spreadsheet calculations (24.3/8.0-pre)
Hi, I'm trying to do some simple calculations, but the results are plain wrong. I started the minimal example with `emacs -Q -l minimal.emacs org/minimal.org'. My Emacs is 24.3 with Org-mode version 8.0-pre (release_8.0-pre-116-g65cde8 @ /home/ov/p/org-mode/lisp/): #+TITLE: Nutrition Facts #+CONSTANTS: b=100 j=4.182 #+TBLNAME: nf | Product | kJ | kcal | |---+--+--| | Bread | 1372 | 328 | | Butter| 3054 | 730 | | Marmalade | 926 | 221 | #+TBLFM: $3=$2/$j;%.0f Here are some calculations per portion (plain wrong): | Product |g | kJ | kcal | |---+--+--+--| | Bread | 50.6 | 658 | 157 | | Butter| 11.5 | 150 | 36 | | Marmalade | 19.7 | 256 | 61 | |---+--+--+--| | | | 1064 | 254 | #+TBLFM: $3='(* $2 (/ (org-lookup-first $1 '(remote(nf,@I$1..@II$1)) '(remote(nf,@I$2..@II$2))) 100));N%.0f::$4=$3/$j;%.0f::@$3..$4=vsum(@I..II) Expected: | Product |g | kJ | kcal | |---+--+--+--| | Bread | 50.6 | 694 | 166 | | Butter| 11.5 | 351 | 84 | | Marmalade | 19.7 | 182 | 44 | |---+--+--+--| | | | 1227 | 294 | #+TBLFM: $4=$3/$j;%.0f::@$3..$4=vsum(@I..II) Using the constant b is also totally wrong: | Product |g | kJ | kcal | |---+--++--| | Bread | 50.6 | 0 |0 | | Butter| 11.5 | 0 |0 | | Marmalade | 19.7 | 0 |0 | |---+--++--| | | | 0 |0 | #+TBLFM: $3='(* $2 (/ (org-lookup-first $1 '(remote(nf,@I$1..@II$1)) '(remote(nf,@I$2..@II$2))) $b));N%.0f::$4=$3/$j;%.0f::@$3..$4=vsum(@I..II) These results are achieved using `C-c C-c' on the first column of the format line. If I use `C-u C-c C-c' in the tabel I get different results *every* time. E.g. pressing `C-u C-c C-c' three times on the `B' of `Bread': | Product |g | kJ | kcal | |---+--++---| | Bread | 50.6 | 32606 | 7784 | | Butter| 11.5 | 59888 | 14297 | | Marmalade | 19.7 | 110192 | 26306 | |---+--++---| | | | 202686 | 48387 | #+TBLFM: $3='(* $2 (/ (org-lookup-first $1 '(remote(nf,@I$1..@II$1)) '(remote(nf,@I$2..@II$2))) 100));N%.0f::$4=$3/$j;%.0f::@$3..$4=vsum(@I..II) If I go to the end of the format line and press `C-c C-c' I get totally different results as at the beginning: | Product |g | 1064 | 254 | |---+--+--+--| | Bread | 50.6 | 1064 | 254 | | Butter| 11.5 | 1470 | 351 | | Marmalade | 19.7 | 2790 | 666 | |---+--+--+--| | | | 5324 | 1271 | #+TBLFM: $3='(* $2 (/ (org-lookup-first $1 '(remote(nf,@I$1..@II$1)) '(remote(nf,@I$2..@II$2))) 100));N%.0f::$4=$3/$j;%.0f::@$3..$4=vsum(@I..II) If I use `M-x org-table-recalculate-buffer-tables' even the headlines get screwed up. Am I doing something wrong or are there severe problems in the spreadsheet mode? Thanks in advance! -- Regards, Oliver
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Carsten Dominik carsten.domi...@gmail.com writes: can you show an example on how you use it? Maybe we can find a better way. Nicolas is right that portability is compromised by customizable emphasis. On 18.3.2013, at 00:02, zeltak zel...@gmail.com wrote: I find the ability to add custom emphasise with custom faces invaluable. i find it very easy to add and very useful for me since i use ALOT of color highlights in my academic work. Here is an excerpt from my .emacs, actually stolen from Fabrice Nielson (http://www.mygooglest.com/fni/), that might give some hints how to do interactive color highlighting without any changes to Org-mode: ,-- | ;; *** 14.13 (info (emacs)Highlight Interactively) | | ;; You can use `hi-lock-mode' to highlight words: | ;; `M-x hi-lock-mode RET' | ;; `C-x w h match RET hi-blue RET' | ;; You can also write your settings to the buffer you're using with | ;; `C-x w b', and read them back in again next time with `C-x w i'. | | ;; TODO Have a look at http://www.emacswiki.org/emacs/color-moccur.el for | ;; searching regexp in buffer | | (GNUEmacs | ;; identical token highlighting commands | (when (try-require 'highlight) | | (defface hlt-1 '((t (:background #A0))) nil) | (defface hlt-2 '((t (:background #A0FFA0))) nil) | (defface hlt-3 '((t (:background #A0))) nil) | (defface hlt-4 '((t (:background #FFA0FF))) nil) | (defface hlt-5 '((t (:background #FFA0A0))) nil) | (defface hlt-6 '((t (:background #A0))) nil) | (defface hlt-7 '((t (:background #A0FFA0))) nil) | (defface hlt-8 '((t (:background #A0))) nil) | (defface hlt-9 '((t (:background #FFA0FF))) nil) | (defface hlt-10 '((t (:background #FFA0A0))) nil) | | (global-set-key (kbd C-S-p) 'hlt-previous-highlight) | (global-set-key (kbd C-S-n) 'hlt-next-highlight) | | (defun hlt-highlight-current-word () | (interactive) | (let ((var_name (current-word t))) | (when var_name | (save-excursion | (hlt-highlight-regexp-region | (point-min) | (point-max) | (regexp-quote var_name)) | | ;; emulation of Vim's `*' search | (global-set-key (kbd C-*) 'hlt-highlight-current-word) | )) | | ;; ;; bind the hi-lock commands to more finger-friendly sequences | ;; (define-key hi-lock-map (kbd C-z i) 'hi-lock-find-patterns) | ;; (define-key hi-lock-map (kbd C-z p) 'highlight-phrase) | ;; (define-key hi-lock-map (kbd C-z r) 'unhighlight-regexp) | | ;; (define-key hi-lock-map (kbd C-z h) 'highlight-regexp) | ;; (define-key hi-lock-map (kbd C-z C-h) 'highlight-lines-matching-regexp) | ;; (define-key hi-lock-map (kbd C-z b) 'hi-lock-write-interactive-patterns) | | ;; Highlight based on regexps | (global-set-key [M-f1] 'highlight-regexp) | (global-set-key [M-f2] 'highlight-lines-matching-regexp) | (global-set-key [M-f3] 'hi-lock-mode) | (global-set-key [M-f4] 'hi-lock-write-interactive-patterns) | | ;; highlight current symbol | (when (try-require 'light-symbol) | (light-symbol-mode)) | | ;; highlight current symbol | (setq highlight-symbol-idle-delay 0.5) | (when (try-require 'highlight-symbol) | (highlight-symbol-mode)) `-- -- cheers, Thorsten
Re: [O] org-babel src block generated graphics included twice if CAPTION is added
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: I just pushed up a patch which should allow code blocks to find un-named results even when there are comment lines (such as #+options or #+attr_backend) between the code block and the results. Shouldn't babel use org-element for things like this? Yes, and many many many other things. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Dear Carsten, Thank you for your quick reply. Let me start by first thanking you for your great work on orgmode, I only recently discovered it (someone referred me to your great talk on youtube) and it made me have the courage to start learning emacs and use orgmode. I (actually me and several colleagues here at the school of public health at Harvard) have been using for the past 4 years a note taking app called notecase pro (http://www.notecasepro.com/) which is nice but not FLOSS and lacking in other areas. I am a post doc who takes alot of notes (30-40) daily which include images and color markings. colors are especially important to us since we use them to mark different commands, research areas, paths, comments and warning so that we have a clear easy to remember color visual clue. We use 15-20 color fg/bg commands. An example note could look like this: http://i.imgur.com/Ncq6ozs.png i am a complete new orgmode user but i am so impressed and overblown with the features and definitely want to transition to use it full time and also convince my colleagues to do so as well. with the help of the #irc channel i was able to use the customizing features for the emphasize symbols to achieve color support . the config now looks like this: '(org-emphasis-alist (quote ((@ (:foreground #B4 :background #FF :weight bold) ) ($ (:foreground #FF) ) (* bold b /b) (/ italic i /i) (_ underline span style=\text-decoration:underline;\ /span) (= org-code code /code verbatim) (~ org-verbatim code /code verbatim) (+ (:strike-through t) del /del That would have worked for me but i understood that there are plans to actually disable these customization's in the next version to allow better portability. If its not to hard It would be great to have a method similar to the customizable emphasis that lets a user define custom colors of FG/BG for inline viewing. I am less concerned about exporting since at least for me i plan to do all the editing/viewing inline inside emacs (though it would be nice of course to be able to use it with mobile org and/or other mobile solutions for when we do field work). I will hold on with starting with the mammoth task of converting my Notecase notes into orgmode until the issues is resolved, i assume i should follow the mailing list to check on this? Sorry for the long email and thank you so much again for all your work, its truly fantastic Z. On Mon, Mar 18, 2013 at 2:08 AM, Carsten Dominik carsten.domi...@gmail.comwrote: Hi Z, can you show an example on how you use it? Maybe we can find a better way. Nicolas is right that portability is compromised by customizable emphasis. - Carsten On 18.3.2013, at 00:02, zeltak zel...@gmail.com wrote: Hi all i just finished a great conversation on #org-mode with some great people. they told me about this thread and the planned changes that may or may not occur to the syntax and id like to just raise the newbee perspective. I find the ability to add custom emphasise with custom faces invaluable. i find it very easy to add and very useful for me since i use ALOT of color highlights in my academic work. i really hope that there is some way to leave the current mphasise with custom faces options as is thx alot guys Z
[O] Automatically escaping single spaces
Hi Orgers,
I use double spaces to demarcate end of sentences
(sentence-end-double-space t). Now when I use things like e.g. or
Fig. , Emacs understands it is not the end of sentence and does the
right thing, say for filling. However when I export a phrase like
that from Org, say to LaTeX, I have to be mindful and write something
like this instead: e.g.\space{}[1]. Although this works, it is very
distracting while writing and prone to human error. I would like some
seamless way for Org to respect my sentence-end-double-space setting
while exporting and export single spaces as single spaces.
Can someone suggest someway to get this to work? It would be even more
awesome if this can be included in Org, i.e. respect
sentence-end-double-space in exported text by default.
Thanks for any ideas.
Cheers,
Footnotes:
[1] I have (org-entities-user '((space ~ nil))) in
my Org settings.
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Spreadsheet calculations (24.3/8.0-pre)
I've posted here before about it, but it looks like you're trying to do the same thing as I am; see https://gitorious.org/org-diet Here's an example of an org-diet file entry: | Food / Exercise| Calories | Quantity | Total | |+--+--+---| | thin crispy flatbread| 16 |2 |32 | | tbsp neufchatel cheese spread | 35 |1 |35 | | tbsp apple butter | 30 | .5 |15 | | tbsp jam | 50 | .5 |25 | | Tea w/ agave creamer | 40 |1 |40 | | cedarlane eggplant parmesan| 240 |1 | 240 | | goldfish cracker |2 | 20 |40 | | bequet wrapped caramel | 48 |1 |48 | | Beverage w/ sugar in the raw creamer | 40 |1 |40 | | pecan half | 10 |3 |30 | | orange | 62 |1 |62 | | presliced aged swiss cheese| 70 |1 |70 | | starbucks tall latte low fat milk | 109 |1 | 109 | | 1 pkt sugar in the raw | 20 |1 |20 | | amy's cheese lasagna | 380 |1 | 380 | | baby carrot|4 |3 |12 | | cup low fat cottage cheese | 180 | .5 |90 | | tofutti cutie | 130 |1 | 130 | |+--+--+---| | Total | | | 1418 | #+TBLFM: $4=$2*$3;%.0f::$LR4=vsum(@2$4..@-I$4) That's not answering your question but might be useful given the type of things you appear to be entering :) Oliver Večerník writes: Hi, I'm trying to do some simple calculations, but the results are plain wrong. I started the minimal example with `emacs -Q -l minimal.emacs org/minimal.org'. My Emacs is 24.3 with Org-mode version 8.0-pre (release_8.0-pre-116-g65cde8 @ /home/ov/p/org-mode/lisp/): #+TITLE: Nutrition Facts #+CONSTANTS: b=100 j=4.182 #+TBLNAME: nf | Product | kJ | kcal | |---+--+--| | Bread | 1372 | 328 | | Butter| 3054 | 730 | | Marmalade | 926 | 221 | #+TBLFM: $3=$2/$j;%.0f Here are some calculations per portion (plain wrong): | Product |g | kJ | kcal | |---+--+--+--| | Bread | 50.6 | 658 | 157 | | Butter| 11.5 | 150 | 36 | | Marmalade | 19.7 | 256 | 61 | |---+--+--+--| | | | 1064 | 254 | #+TBLFM: $3='(* $2 (/ (org-lookup-first $1 '(remote(nf,@I$1..@II$1)) '(remote(nf,@I$2..@II$2))) 100));N%.0f::$4=$3/$j;%.0f::@$3..$4=vsum(@I..II) Expected: | Product |g | kJ | kcal | |---+--+--+--| | Bread | 50.6 | 694 | 166 | | Butter| 11.5 | 351 | 84 | | Marmalade | 19.7 | 182 | 44 | |---+--+--+--| | | | 1227 | 294 | #+TBLFM: $4=$3/$j;%.0f::@$3..$4=vsum(@I..II) Using the constant b is also totally wrong: | Product |g | kJ | kcal | |---+--++--| | Bread | 50.6 | 0 |0 | | Butter| 11.5 | 0 |0 | | Marmalade | 19.7 | 0 |0 | |---+--++--| | | | 0 |0 | #+TBLFM: $3='(* $2 (/ (org-lookup-first $1 '(remote(nf,@I$1..@II$1)) '(remote(nf,@I$2..@II$2))) $b));N%.0f::$4=$3/$j;%.0f::@$3..$4=vsum(@I..II) These results are achieved using `C-c C-c' on the first column of the format line. If I use `C-u C-c C-c' in the tabel I get different results *every* time. E.g. pressing `C-u C-c C-c' three times on the `B' of `Bread': | Product |g | kJ | kcal | |---+--++---| | Bread | 50.6 | 32606 | 7784 | | Butter| 11.5 | 59888 | 14297 | | Marmalade | 19.7 | 110192 | 26306 | |---+--++---| | | | 202686 | 48387 | #+TBLFM: $3='(* $2 (/ (org-lookup-first $1 '(remote(nf,@I$1..@II$1)) '(remote(nf,@I$2..@II$2))) 100));N%.0f::$4=$3/$j;%.0f::@$3..$4=vsum(@I..II) If I go to the end of the format line and press `C-c C-c' I get totally different results as at the beginning: | Product |g | 1064 | 254 | |---+--+--+--| | Bread | 50.6 | 1064 | 254 | | Butter| 11.5 | 1470 | 351 | | Marmalade | 19.7 | 2790 | 666 | |---+--+--+--| | | | 5324 | 1271 | #+TBLFM: $3='(* $2 (/ (org-lookup-first $1 '(remote(nf,@I$1..@II$1)) '(remote(nf,@I$2..@II$2))) 100));N%.0f::$4=$3/$j;%.0f::@$3..$4=vsum(@I..II) If I use `M-x org-table-recalculate-buffer-tables' even the headlines get screwed up. Am I doing something wrong or are there severe problems in the
[O] Minibuffer jumping to two lines when agenda displays 3rd level heading
I don't if this is a bug or a feature however to me it's just annoying. I've recently noticed that when moving up and down the agenda some entries will cause the minibuffer to expand to two lines while others make it shrink back to one. From bouncing around a bit, the one thing in common I noticed is that each of the entries that cause the jump to two lines are on a third level heading (***). Is this intentional and is there a way to make it stop? GNU Emacs 24.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.12) of 2012-09-22 on batsu, modified by Debian Org-mode version 8.0-pre (release_8.0-pre-116-g65cde8 @ /home/ewd/.emacs.pkg/org-mode/lisp/) -ED-
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
zeltak zel...@gmail.com writes: Dear Carsten, Thank you for your quick reply. Let me start by first thanking you for your great work on orgmode, I only recently discovered it (someone referred me to your great talk on youtube) and it made me have the courage to start learning emacs and use orgmode. [snip] '(org-emphasis-alist (quote ((@ (:foreground #B4 :background #FF :weight bold) ) ($ (:foreground #FF) ) (* bold b /b) (/ italic i /i) (_ underline span style=\text-decoration:underline;\ /span) (= org-code code /code verbatim) (~ org-verbatim code /code verbatim) (+ (:strike-through t) del /del That would have worked for me but i understood that there are plans to actually disable these customization's in the next version to allow better portability. If its not to hard It would be great to have a method similar to the customizable emphasis that lets a user define custom colors of FG/BG for inline viewing. I am less concerned about exporting since at least for me i plan to do all the editing/viewing inline inside emacs (though it would be nice of course to be able to use it with mobile org and/or other mobile solutions for when we do field work). I will hold on with starting with the mammoth task of converting my Notecase notes into orgmode until the issues is resolved, i assume i should follow the mailing list to check on this? Sorry for the long email and thank you so much again for all your work, its truly fantastic Z. I want to add, as one of the people that helped Z with this on IRC--and as another person that made the leap into Emacs largely because of Org, about five years ago--that I think there are a lot of users like this: people who value Org as a tool that is tightly integrated with the power and flexibility of Emacs and Emacs Lisp, who aren't necessarily closely following Org's upstream development or this list (I didn't follow it closely until recently, either), and who are more concerned with keeping Org flexible and customizable enough to exactly fit their needs within Emacs than they are about making it available as yet another plain-text markup language outside of Emacs. Much as my Gnus is heavily customized to my needs at this point, with Elisp-based features such as adaptive scoring and virtual groups that other news and mail readers simply don't have, I would never really dream of reproducing Org outside of Org. And there are plenty of things that I would never expect to work in an external application or parser that speaks the Org format (dynamic blocks that run Elisp, for example), which everyone nonetheless wants to have. Perhaps a compromise could be reached on variables such as `org-emphasis-alist' and others possibly slated for the defconst treatment: instead of doing that, let's consider keeping them customizable but include the default values in the Org format specification. Org users who are never using Org outside of Emacs will never see a problem using custom emphasis marks inside Emacs, unless Org drops the feature. For those who know that they want to use their Org files with some external parser, we could have an `org-rfc-check' function that warns about non-standard values of things like org-emphasis-alist and offers to revert them to the defaults (which would be the same as the values in the spec). What do you think? Is this a crazy scheme? -- Regards, WGG
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Dnia 2013-03-18, o godz. 15:21:54 wgreenho...@riseup.net (W. Greenhouse) napisał(a): Perhaps a compromise could be reached on variables such as `org-emphasis-alist' and others possibly slated for the defconst treatment: instead of doing that, let's consider keeping them customizable but include the default values in the Org format specification. Org users who are never using Org outside of Emacs will never see a problem using custom emphasis marks inside Emacs, unless Org drops the feature. For those who know that they want to use their Org files with some external parser, we could have an `org-rfc-check' function that warns about non-standard values of things like org-emphasis-alist and offers to revert them to the defaults (which would be the same as the values in the spec). What do you think? Is this a crazy scheme? Just Another N00b's 2cents: what about moving such things from core to contrib? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] Automatically escaping single spaces
Dnia 2013-03-18, o godz. 14:40:24
Suvayu Ali fatkasuvayu+li...@gmail.com napisał(a):
Hi Orgers,
I use double spaces to demarcate end of sentences
(sentence-end-double-space t). Now when I use things like e.g. or
Fig. , Emacs understands it is not the end of sentence and does the
right thing, say for filling. However when I export a phrase like
that from Org, say to LaTeX, I have to be mindful and write something
like this instead: e.g.\space{}[1]. Although this works, it is very
distracting while writing and prone to human error. I would like some
seamless way for Org to respect my sentence-end-double-space setting
while exporting and export single spaces as single spaces.
Can someone suggest someway to get this to work? It would be even
more awesome if this can be included in Org, i.e. respect
sentence-end-double-space in exported text by default.
Hi,
A simple workaround would be to use \frenchspacing in your LaTeX
document (which typographic authorities suggest anyway - at least
Bringhurst). The thing is, the algorithm LaTeX uses to determine
whether a period ends a sentence or not is completely different from
Emacs' one: for the TeX parser, any number of spaces effectively
collapses into one (at least, if no special measures are taken).
Anyway, you may also try e.g.\nbsp{}this to get a nonbreakable
space. I'd also suggest changing your org-entities-user so that \space
maps to either \space or \ in LaTeX - this way you get breakable
spaces, too.
As a feature request: what about including (1) \frenchspacing in the
exported LaTeX file by default and (2) \ mapped to \ in LaTeX
export?
Anyway, for all people interested in the subject (from both
typographical and TeXnical points of view), I'd strongly suggest reading
through e.g. http://tex.stackexchange.com/q/4705/5626 .
Best,
Thanks for any ideas.
Cheers,
Footnotes:
[1] I have (org-entities-user '((space ~ nil))) in
my Org settings.
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
Re: [O] Minibuffer jumping to two lines when agenda displays 3rd level heading
FWIW, the minibuffer behavior does not occur in NTEmacs. GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-08-24 on YAMALOK
Re: [O] A mix of habits and effort estimates?
Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Limitation: the effort is supposed to represent a big total or a daily amount (see property :CLOCK_MODELINE_TOTAL: today). Though, there is no such thing for a weekly limit. If you set CLOCK_MODELINE_TOTAL to repeat you can use any interval you like. Clock in and out of the task repeatedly until you hit your effort limit or are done then mark the task done and the total clocked time resets for the next period. I use this for my habit 'Update org-mode doc' task which repeats .+1w/1m Regards, Bernt
Re: [O] Help request - auto-fill/word wrap with headlines and tags
Not quite - this wraps the headline visually, leaves any tags at the end, and doesn't fold the additional lines, as it technically leaves you with 1 long headline spanning multiple lines, not a 1-line headline with a body of text following it On Fri, Mar 15, 2013 at 2:12 PM, Bastien b...@altern.org wrote: Hi Subhan, Subhan Tindall subhan.tind...@rentrakmail.com writes: I haven't been able to find a combination of options to do this, any ideas? Did you try this? M-x visual-line-mode RET -- Bastien -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi everyone, first a disclaimer: Nicolas has thought about all things parser a lot more than I have, so he might disagree. But here is my take on the issue. First of all, we should not see Org as just another plain text markup language (no offense meant, I am sure, and none taken). Because of its unique treatment of source code inclusion, source code markup, and executability, it is very much unique, I think. Therefore it deserved a clean definition and a well defined parser, with a goal to make files function correctly in different peoples setup. This is what Nicolas is trying to give to us - aside from turning an incredible parser/exporter mess into a sane system. We used to have as many parsers as exporters, all slightly different, bugs having to be fixed in different ways in each parser. That is gone, with a very limited amount of pain, and I am entirely amazed that this was even possible, let alone that someone had the stamina to do it and the patience it takes to put this, with the small limitations it brings, onto the community. Now, I also agree that it is desirable that Org remains to be a hackable system with as much flexibility as we can allow, and we need to carefully consider where the line is. For example, every users setup has some dependency of parser behavior on external variables: todo keywords. The way this is fixed in the sense that we can guarantee a stable parsing of such a system is to tell people that including the TODO keyword definitions with a #+TODO line into the file. So you can have a global setting in a global customization variable to make things easy for yourself and get good behavior in every new file you open, but you can stabilize a file for the parser with in-buffer settings when you need compatibility for other users. There are a few exceptions that Nicolas has pointed out in this thread. The COMMENT keyword is one. We could define an in-buffer setting for it, or we could just fix it, the pain here would be minimal. Another example is the emphasis stuff. There are no in-buffer settings for it, and they would be pretty hard to make. The reason why the emphasis regexp components were made configurable in the first place is because when the feature was introduced, I had no idea what would work, and I redesigned this part several times over. Emphasis is a very heuristic system, the character that are allowed before and after the markers are necessarily a compromise, and we will always find people for who the chosen selection will not work. That is why I would like to argue for keeping this part hackable, even if I agree that the official definition should be fixed. Keeping this variable a customize variable invites changes also by people who do not really know what they are doing. Turning it into a defvar or defconst and somewhere document how to hack around the restriction if you really need to sounds like a good solution for me. Now to the discussion with Z about additional emphasis definitions which he/she uses for custom highlighting of stuff. Right now this relies on modifying the emph-alist variable. However, for the purpose of in-buffer only highlighting, it is not necessary to go through parser-sensitive code. You can do this simply with additions to font-lock, for example using font-lock-add-keywords or something like this, see also Thorsten's post. If someone wants, I can provide an example for Z's case, and we could encapsulate such behavior into a little library in contrib, to make it easy to configure such behavior. Compromising the parser for this application is not necessary. Nicolas, I would assume that your wish to disallow customization is focused on the regexp components, and the marker characters for emphasis, but not on the possibility to change the in-buffer face that is being used to highlight the stuff in the buffer? - Carsten On 18.3.2013, at 16:21, W. Greenhouse wgreenho...@riseup.net wrote: zeltak zel...@gmail.com writes: Dear Carsten, Thank you for your quick reply. Let me start by first thanking you for your great work on orgmode, I only recently discovered it (someone referred me to your great talk on youtube) and it made me have the courage to start learning emacs and use orgmode. [snip] '(org-emphasis-alist (quote ((@ (:foreground #B4 :background #FF :weight bold) ) ($ (:foreground #FF) ) (* bold b /b) (/ italic i /i) (_ underline span style=\text-decoration:underline;\ /span) (= org-code code /code verbatim) (~ org-verbatim code /code verbatim) (+ (:strike-through t) del /del That would have worked for me but i understood that there are plans to actually disable these customization's in the next version to allow better portability. If its not to hard It would be great to have a method similar to the customizable emphasis that lets a user define custom colors of FG/BG for inline viewing. I am less concerned
Re: [O] Help request - auto-fill/word wrap with headlines and tags
Subhan Tindall subhan.tind...@rentrakmail.com writes: Not quite - this wraps the headline visually, leaves any tags at the end, and doesn't fold the additional lines, as it technically leaves you with 1 long headline spanning multiple lines, not a 1-line headline with a body of text following it I misread your request but the answer to it is no, I don't think this is possible. Unless you come up with some dedicated hack for this. HTH, -- Bastien
Re: [O] Syntax of Org Babel :results header argument
Hello all, Andreas Leha wrote: t...@tsdye.com (Thomas S. Dye) writes: Eric Schulte schulte.e...@gmail.com writes: Bastien b...@altern.org writes: Sebastien Vauban writes: As there was no reaction to this, I'd like to bump it up. At least, to either have a discussion on this, or a clearly stated no go. I tend to agree with Jay here and I prefer the minimalist syntax, although values for the :results parameter are heterogeneous. +1 for maintaining the existing concise syntax. +1 for stable syntax. +1 one more vote I've got the authoritative answers I was expecting. It was just a RFI. Case is closed! Best regards, Seb -- Sebastien Vauban
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Carsten Dominik carsten.domi...@gmail.com writes: The reason why the emphasis regexp components were made configurable in the first place is because when the feature was introduced, I had no idea what would work, and I redesigned this part several times over. Emphasis is a very heuristic system, the character that are allowed before and after the markers are necessarily a compromise, and we will always find people for who the chosen selection will not work. That is why I would like to argue for keeping this part hackable, even if I agree that the official definition should be fixed. Keeping this variable a customize variable invites changes also by people who do not really know what they are doing. Turning it into a defvar or defconst and somewhere document how to hack around the restriction if you really need to sounds like a good solution for me. To some extend I disagree, I think. Well, a contrib library is of course OK, but I think it's not the right way to go about it. . . Would it be possible to make it easier to make 'custom' highlights? In a previous thread a [cite:key] syntax was suggested. Perhaps, a better way for custom emphasis would be [type:value] allowing for custom functions for each type. E.g. [TYPE:value] would run function a function org-type-keys-TYPE which returns value formatted with a special face. Perhaps this is more cumbersome and perhaps it is no more 'structured' than using customized emphases. –Rasmus -- El Rey ha muerto. ¡Larga vida al Rey!
Re: [O] edit-src on read-only files
Hi Bastien, thanks again for implementing this! Bastien b...@altern.org writes: Hi Andreas, Andreas Leha andreas.l...@med.uni-goettingen.de writes: thanks for taking this up! But I am not sure, whether I like the current implementation too much. Instead of saving the org-file itself, I'd prefer the org-file to be auto-saved. You can use auto-save-mode then. I changed the `buffer-auto-save-file-name' so that it's unique and shows the date of the auto-save. This is very nice! I've actually meant to have the parent org-buffer auto-saved including the changes in any open source buffer. But this is really good as well. And a much simpler solution. I also deactivated the timer for auto-saving into the buffer where the source code lives, as it is a bit too intrusive IMO. I agree. I've also disabled this and -- given the better auto-saving mechanism (which gets disabled by saving) -- won't use any more. Thanks again, Andreas
[O] scaling the text in the results block of some code chunk when exported using LaTeX
Hello all, Is there a way to scale the text in the latex export of a results block produced by a code chunk? Here is the code chunk i am trying to evaluate and export: #+BEGIN_SRC R :session :exports results :results output org replace :tangle yes print(list.files(recursive = T, pattern = *.xls*)) #+END_SRC This prints a list of filenames that are quite long. I need to preserve them as is. Here is the results block: #+END_SRC #+Results: #+BEGIN_SRC org [1] 20130304 Some Spreadsheet/20130215 XXX_CB edited for sample classification.xls [2] 20130304 Some Spreadsheet/20130215 XXX_CB edited for sample classification.xls [4] 20130304 Some Spreadsheets/20130215 samples results final.xlsx [5] 20130304 Some Spreadsheets/20130215 results final_formatted.xlsx [6] 20130304 Some Spreadsheets/20130304 samples results 121109_Rep Aliqs Highlighted.xlsx #+END_SRC Is there a way for me to define the scaling of the text within the results block when this is exported using latex? Thank you and regards, Shripad Tucson, AZ
Re: [O] scaling the text in the results block of some code chunk when exported using LaTeX
Hello Shripad, On Mon, Mar 18, 2013 at 7:44 PM, shripad sinari shripad.sin...@gmail.com wrote: [snip] Is there a way for me to define the scaling of the text within the results block when this is exported using latex? [snip] I don't know of a way to scale /within/ the code block, but does this work instead? #+NAME: foo #+BEGIN_SRC R :session :exports results :results output org replace :tangle yes print(list.files(recursive = T, pattern = *.xls*)) #+END_SRC \scriptsize #+RESULTS: foo #+BEGIN_SRC org [1] 20130304 Some Spreadsheet/20130215 XXX_CB edited for sample classification.xls [2] 20130304 Some Spreadsheet/20130215 XXX_CB edited for sample classification.xls [4] 20130304 Some Spreadsheets/20130215 samples results final.xlsx [5] 20130304 Some Spreadsheets/20130215 results final_formatted.xlsx [6] 20130304 Some Spreadsheets/20130304 samples results 121109_Rep Aliqs Highlighted.xlsx #+END_SRC \normalsize I learned just yesterday that the 'naming code blocks' trick is very handy for things like this. Here is halfway through the thread where this was discussed: http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01268.html See also John Hendy's comments later in the thread. I hope this helps, -- Jay
Re: [O] scaling the text in the results block of some code chunk when exported using LaTeX
shripad sinari shripad.sin...@gmail.com writes:
Hello all,
Is there a way to scale the text in the latex export of a results
block produced by a code chunk?
Here is the code chunk i am trying to evaluate and export:
#+BEGIN_SRC R :session :exports results :results output org replace :
tangle yes
print(list.files(recursive = T, pattern = *.xls*))
#+END_SRC
This prints a list of filenames that are quite long. I need to
preserve them as is. Here is the results block:
#+END_SRC
#+Results:
#+BEGIN_SRC org
[1] 20130304 Some Spreadsheet/20130215 XXX_CB edited for
sample classification.xls
[2] 20130304 Some Spreadsheet/20130215 XXX_CB edited for
sample classification.xls
[4] 20130304 Some Spreadsheets/20130215 samples
results final.xlsx
[5] 20130304 Some Spreadsheets/20130215 results
final_formatted.xlsx
[6] 20130304 Some Spreadsheets/20130304 samples
results 121109_Rep Aliqs Highlighted.xlsx
#+END_SRC
Is there a way for me to define the scaling of the text within the
results block when this is exported using latex?
Jay mentioned how to repeatably wrap the results in latex markup; I'd
look into the \resizebox in the graphicsx package to make sure the block
of filenames fits the page. Something like:
#+LATEX: \resizebox{\textwidth}{!}{%
#+RESULTS: foo
#+BEGIN_SRC org
etc...
#+END_SRC
#+LATEX: }
Untested, but something like that ought to work...
E
Re: [O] scaling the text in the results block of some code chunk when exported using LaTeX
Jay Kerns gjkerns...@gmail.com writes: I don't know of a way to scale /within/ the code block, but does this work instead? #+NAME: foo #+BEGIN_SRC R :session :exports results :results output org replace :tangle yes cat(\\scriptsize) print(list.files(recursive = T, pattern = *.xls*)) cat(\\normalsize) #+END_SRC hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] scaling the text in the results block of some code chunk when exported using LaTeX
Thanks you all for the suggestions! Let me try out the suggestions and I will report back on what worked. Thanks again! Shripad. Shripad Tucson, AZ On Mon, Mar 18, 2013 at 6:07 PM, Thomas S. Dye t...@tsdye.com wrote: Jay Kerns gjkerns...@gmail.com writes: I don't know of a way to scale /within/ the code block, but does this work instead? #+NAME: foo #+BEGIN_SRC R :session :exports results :results output org replace :tangle yes cat(\\scriptsize) print(list.files(recursive = T, pattern = *.xls*)) cat(\\normalsize) #+END_SRC hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi Carsten, Thank you for your very insightful thoughts. I would like to make one note. 2013ko martxoak 18an, Carsten Dominik-ek idatzi zuen: Now to the discussion with Z about additional emphasis definitions which he/she uses for custom highlighting of stuff. Right now this relies on modifying the emph-alist variable. However, for the purpose of in-buffer only highlighting, it is not necessary to go through parser-sensitive code. You can do this simply with additions to font-lock, for example using font-lock-add-keywords or something like this, see also Thorsten's post. If someone wants, I can provide an example for Z's case, and we could encapsulate such behavior into a little library in contrib, to make it easy to configure such behavior. Compromising the parser for this application is not necessary. I use org to write articles which discuss words in foreign languages. These need to be distinctively typeset (in italics), and sometimes need to be set in a special font with coverage for exotic characters. I would find it very useful to be able to define special emphasis environments for these words. Using macros feels too much like writing LaTeX (which I use org to avoid having to write directly, as much as possible...) I see the goal of the syntactic standardization as making it easier to operate with non-emacs tools; as Nicolas said: My point of view is the following: Org (as a format) definition shouldn't depend on Emacs. It should be totally parseable by any language (which is not the case actually, since syntax relies on variables defined in Emacs). IOW, we should work to make it a real plain-text markup format. Personally, I am OK with articles I have written for export never being able to be read by non-emacs tools (as opposed to other uses of org as a database/schedule/agenda, where the ability to access the information in other programs/programming languages would be useful). I sympathize with the goal of making the format accessible to other tools, but I also think the ability to have within emacs additional flexibility wrt. formatting (for both display and export) is worth preserving. -- Aaron Ecay
Re: [O] Automatically escaping single spaces
Hi Suvayu, I’ve had on my list of rainy day ideas for a while writing a function for org-export-filter-plain-text-functions that would implement something like this. It should be as simple as doing a text replace, either on “. [^ ]” sequences in general or only spaces after a given list of abbreviations. The advantage of the second approach is that it could catch the case where “e.g.” is at the end of a line in the org document. (You’d also have to remove the newline: translate “e.g.\nfoo” into “e.g.\ foo”). Another advantage to pre-specifying is that you might want a non-breaking space in “Fig.~1” but a breakable space in “e.g.\ foo”; so you could keep two lists. -- Aaron Ecay
Re: [O] footnotes export verbatim
On 2/26/13, Nicolas Goaziou n.goaz...@gmail.com wrote: Try the following: I got it to work. Thank you. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is NO hope without action. This means YOU.
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Hi Eric, I’m jointly replying to 2 of your emails. 2013ko martxoak 13an, Eric Schulte-ek idatzi zuen: This is what is already taking place. The :var header arguments are automatically expanded into dependencies between code blocks, and the results of previous code blocks are included in the hash calculation of the current code block. Wow, I did not realize that the :var handling was so sophisticated. Would it be possible to introduce a :depends code-block-name header argument, which recycles the same dependency calculation but does not bind a variable in the code block? Many of the variables that I rely on between blocks are large data frames, and I worry that dumping them into the org buffer and then reloading them into R[fn:1] will result in a slowdown and/or loss of some structure in the data. [fn:1] My understanding of the :var-handling code is that this is how it acquires the values to assign to the variables, as opposed to re-using a variable that is present in a session. But the code is complex, so maybe I’m wrong (again). I also think this would make the feature more discoverable: a :var is just a sub-type of :depends, with extra functionality. Coming from a Sweave/knitr background, I expected something like :depends, and thus didn’t notice :var From re-looking at Achim's previous noweb example, it seems that we currently do *not* include the values of noweb expansions in code block hash calculations, I think this is a bug which should be fixed. +1 To echo Achim's response, you've accidentally uttered Org-mode heresy. Oh no. The good news is that thanks to your and Achim’s explanation, I think I now understand this principle better. Oh yes, there's a whole set of _other_ problems that are waiting to be solved. :-) There always is. :-) I think Org-mode already provides the bulk of what is desired. If we agree to treat :cache yes :results none as obviously taking place for side effects, and then sticking a hash behind the :cache header argument with the code block, then what functionality would be missing? This was more of a joke on my part: life gets boring when you run out of problems to work on. In this specific case, though: 1) a :depends header argument 2) including the session PID in results hashes by default (because it is the only sensible thing to do) 2013ko martxoak 13an, Eric Schulte-ek idatzi zuen: Well, I suppose one man's dirty kludge is another's beautiful hack. The question here is whether the complexity lies in the implementation (and thus the interface) or in the code block itself. While I generally prefer the later, in this case of :results none :cache yes I would be open to placing some custom logic in the backend, which stores the hash value with the code block, possibly changing #+begin_src R :cache yes # code to perform side effect #+end_src to #+begin_src R :cache 9f4e5b4b07e93c680ab37fc4ba1f75e1bfc0ee0a # code to perform side effect #+end_src keeping in mind that the actual hash value should be hidden after the first couple of characters. If you like this solution, may I try once more to convince you of the empty #+RESULTS solution I originally proposed? I looked at the code for inserting/hiding/finding hash values, and it looks like it would be complicated to change. Empty #+RESULTS is easy, although perhaps less conceptually pure. If you want the cache in the header, I think I can try to work on a patch, but it does look tricky. So I am not sure I will have time to work on it until next week. (If anyone else wants to beat me to the punch, please feel free!) One question: should we have the cache in the header only for :results none blocks, or for all blocks? I was actually very proud of this solution. It is what would be done by the framework if we did implement custom support, but by doing it with code blocks the exact mechanics are visible to the user. Agreed. But if it is the only “right” thing to do, or one of a very small set of “right” things, I think it’s a win in terms of conciseness/ease of use to do it automatically. And I think this is the case here: the presence of :session yes is a clear signal that there is out-of-band (from org’s perspective) communication happening between code blocks, and that the invariance of a result can’t be relied on in a different session process. So when the session PID changes, the hash value should change as well, to trigger reevaluation. How should session startup be determined if not through inclusion of the session PID in the code block hash? Perhaps the above could be made more elegant through the addition of an elisp function which returns the pid of the current R session, allowing the above to be truncated to something like the following. #+begin_src R :cache yes :session foo :var pid=(R-pid foo) # code to perform side effect x - 'side effect' 'done' #+end_src
Re: [O] Confusion about attr_latex and new exporter
Hi John, 2013ko martxoak 17an, John Hendy-ek idatzi zuen: #+begin_quote Aaron Ecay Eliminating subtleties is precisely the point of this change. All(-ish)* backends now use :width. * As far as I’ve checked, HTML(+ derived backends) and LaTeX(+derived backends). If there are any that don’t, they should probably be patched to do so as well. #+end_quote I’m sorry, that was a mistake. I sent a patch to the HTML backend to enable this behavior, but forgot all about it. Then when I checked the code, it looked like the functionality was already there! I’ll follow up with Bastien about the patch, and see what its status is... -- Aaron Ecay
Re: [O] org-exp-bibtex missing in git?
Hi Bastien, 2013ko martxoak 9an, Bastien-ek idatzi zuen: This is great -- I'll be offline this week-end, so I won't have time to have a careful look before monday. But I will. I hope this is not bothersome, but have you had a chance to look at these patches? I thought they would solve the problem in the thread at http://thread.gmane.org/gmane.emacs.orgmode/68649 involving HTML image width specifications, but I was mistaken. Nonetheless, I think they are useful for a sort of bare-bones LaTeX bibliographies, as well as solving the problem of not being able to specify different ATTR_HTML lines for 2 links in the same paragraph. Thanks, -- Aaron Ecay
Re: [O] Confusion about attr_latex and new exporter
Hi again, 2013ko martxoak 19an, Aaron Ecay-ek idatzi zuen: I’m sorry, that was a mistake. I sent a patch to the HTML backend to enable this behavior, but forgot all about it. Then when I checked the code, it looked like the functionality was already there! I’ll follow up with Bastien about the patch, and see what its status is... I was very confused when I wrote this. The patches I had in mind were for a different issue. If #+ATTR_HTML: :width 200 ever worked for me, it was only because of me hacking org into a chimeric state. I guess you should continue to use #+ATTR_HTML: width=200 or whatever the working incantation for HTML has traditionally been. Sorry for the noise, -- Aaron Ecay
