Re: [O] Error with :wrap org in babel and 8.0-pre
Hello, Eric Schulte wrote: - Can we prune some options/syntax that's no longer necessary? For example, what does =:wrap= (no argument provided) do? Wrap has been deprecated for some time. No, it hasn't been deprecated. :results wrap has; not :wrap... Perhaps it has been long enough that we can go ahead and remove it entirely from the code and documentation at this point. Or =:wrap src org= / =:results output org=? It seems that these once served a purpose but no longer accomplish anything useful. I would be happy to remove support for =:results org=. It has been supplanted by =:results drawer=, and I don't believe there is any other use for it. Unless someone complains, I'd be happy to remove both. :results org and :results drawer are not the same regarding Org results: the first does comma-escape the result lines, not the second. Best regards, Seb -- Sebastien Vauban
Re: [O] why is 'no' the default value of :tangle
Christian Moe wrote: Guido Van Hoecke writes: I am wondering why the default value of header argument :tangle is 'no' rather than 'yes'. FWIW, the default makes sense to me. A document might contain lots of little code blocks for one purpose or another (testing, little utilities, version archive, etc.) that you don't want included in the tangled product. Back to google-calendar.org as an example. Is it normal that whomever wants to use the embedded elisp file needs to edit the source and e.g. insert a '#+PROPERTY: tangle yes'? It is clear that this file will need to be tangled by every single person that wants to use the embedded code, so should the default not allow for tangling without having the edit the input file? Well, if you're distributing code for others to use in the form of source blocks in Org documents, it may be a courtesy to set `:tangle yes'. But that doesn't necessarily give users the tangled result where they want it on their system, with the filename they want, so they will often have to edit it anyway. And you can change the default for your Org installation, by changing the default of the tangle header argument in your .emacs file: #+begin_src emacs-lisp ;; add default arguments (add-to-list 'org-babel-default-header-args '(:tangle . yes)) #+end_src Best regards, Seb -- Sebastien Vauban
Re: [O] Colour themes suggestions?
Rainer M. Krug wrote: rai...@krugs.de (Rainer M. Krug) writes: Vikas Rawal vikasli...@agrarianresearch.org writes: I am looking for suggestions for color themes which are on a light background (reflections are less) and has nice and effective syntax highlighting. http://orgmode.org/worg/org-color-themes.html You may like Leuven. Indeed - Leuven looks very nice - I like the different background colors for the code blocks - very useful. One question though - can I use it under emacs 24, as it states Obsolete since Emacs 24 on git? There are 2 different packages, one using `color-theme-6.6.0' (which does not work anymore on Emacs 24, IIRC), and another using the new custom theme feature of Emacs. So, it does well work under Emacs 24. Best regards, Seb -- Sebastien Vauban
Re: [O] Invalid syntax in INCLUDE keyword
OSiUX, OSiUX wrote: After upgrading, when publish a project I get the error: org-export-expand-include-keyword: Invalid syntax in INCLUDE keyword I try delete all lines with: #+INCLUDE: header.org New syntax: quote the file name... #+INCLUDE: header.org But the error persists. Anyone know how to fix it? org-version: 8.0-pre (release_8.0-pre-410-g87e84c) Emacs 23.4.1 thanks! Best regards, Seb -- Sebastien Vauban
Re: [O] Exploring org-element.el with navi-mode
Hello Thorsten, Thorsten Jolitz wrote: its now possible to use the new libraries for 'Org-mode outside Org-mode' (outshine, outorg, pop-org, navi-mode) on Emacs Lisp files that use the official header conventions (;;;+ ). Where are these official header conventions described? Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Process hlines in imported tables
Hi Eric, Sebastien Vauban wrote: Eric Schulte wrote: I would agree that this (meaning raw implies scalar) should either occur for all languages or for none. I think this is something interesting, but I wonder now if we wouldn't loose more than we would win. I mean: how would one be able to output a real raw result, then, that is one where pipes are not interpreted as table field separator which have to be aligned in some specific way. Do we need another argument for that? I mean: at the end, raw should really be raw (no interpretation). If we want some cycling for table alignment purpose (BTW, do you have lots of such code blocks?), maybe it'd be better to introduce a `cycle' argument or so? I think that this portion of my post has been ignored in your answers -- which I still have to carefully look at. Though, I don't think the above question should stay unanswered: if you now cycle on all raw results, how do we insert real raw results for which we don't want any interpretation (not even cycling tables, or what you be confounded as tables)? Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Eric, Eric Schulte wrote: Let me explain. AFAICT, there were 5 possibles values of the :colnames header argument: - no header argument :: (default for all languages but Emacs Lisp) - :colnames no :: (default for Emacs Lisp code blocks) - :colnames yes :: Tells Org Babel that your first row contains column names. - :colnames LIST :: Specifies to use LIST as column names. - :colnames nil :: Same as :colnames yes. Right? Almost, values 1 (none) and 5 (nil) are the same. I don't share your view about this last statement. As I believe I mentioned nil on a header argument is not interpreted as the lisp literal `nil'. To pass an empty argument to a code block you should do :colnames '(), an obscure syntax for an obscure thing. I do now share your view with your precision on using - :colnames '() or - :colnames () to pass an empty argument. Are both version above really equivalent (they _do_ behave the same in my tests, but I'm wondering for the future)? Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Eric, Eric Schulte wrote: ** Using =:colnames no= header argument (case 2) #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Here, I still don't understand why I do see the table header line: I did change the default =:colnames yes= specification to =:colnames no= on the code block. I did override the default value. Why is the =no= argument not respected? Because 'hlines is set to yes by default in `org-babel-default-header-args:emacs-lisp'. I missed the cumulative effect of hlines on the behavior of colnames. Yes, setting hlines to no does solve the problem for Emacs Lisp code blocks. Thanks a lot. Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Eric, Eric Schulte wrote: What is still unclear to me as well, is why =()= and =nil= aren't the same from Babel's point of view? However, I think I understood this one: it is because nil is interpreted as a string, not as the empty list; right? That's because strings aren't quoted, right? Yes. Apart from the automatic (and, maybe, sometimes unwished) coercion of a symbol into a string (case of `nil'), are you aware of other tricky stuff? For my own understanding, why didn't we force the user to quote all strings, and avoid the above problem? Best regards, Seb -- Sebastien Vauban
Re: [O] org-babel-tangle
Guido Van Hoecke wrote: When editing https://github.com/bateast/google-calendar/blob/master/google-calendar.org I assume from the documentation that hitting C-c C-v C-t or M-x org-babel-tangle would produce the pure source (in casu elisp) file, but it says 'Tangled 0 code blocks from google-calendar.org' I am pretty sure that it should be possible to produce the source file without any modification of the input file, but appearently I am approaching it the wrong way. Any help and suggestions would be most welcome, Put, at least, `#+PROPERTY: tangle yes' in the first lines of the Org file -- or put a target filename. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Process hlines in imported tables
Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Sebastien Vauban wrote: Eric Schulte wrote: I would agree that this (meaning raw implies scalar) should either occur for all languages or for none. I think this is something interesting, but I wonder now if we wouldn't loose more than we would win. I mean: how would one be able to output a real raw result, then, that is one where pipes are not interpreted as table field separator which have to be aligned in some specific way. Do we need another argument for that? I mean: at the end, raw should really be raw (no interpretation). If we want some cycling for table alignment purpose (BTW, do you have lots of such code blocks?), maybe it'd be better to introduce a `cycle' argument or so? I think that this portion of my post has been ignored in your answers -- which I still have to carefully look at. Though, I don't think the above question should stay unanswered: if you now cycle on all raw results, how do we insert real raw results for which we don't want any interpretation (not even cycling tables, or what you be confounded as tables)? Is this a hypothetical problem or do you have a use case which requires non-cycling? At this stage, completely hypothetical. It's just that we remove some possibility which existed: from now on, we can't insert some types of data anymore. And I feel that the name raw does not conform anymore to the reality. But, as said, I don't have a real problem at hand. Best regards, Seb -- Sebastien Vauban
Re: [O] Error with :wrap org in babel and 8.0-pre
Dear Eric, Eric Schulte wrote: John Hendy jw.he...@gmail.com writes: On Fri, Apr 12, 2013 at 5:24 PM, Eric Schulte schulte.e...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: Use :wrap org if your code block produces raw org. E.g., #+begin_src sh :results output :wrap org cat EOF | a | b | |---+---| | 1 | 2 | EOF #+end_src #+RESULTS: #+BEGIN_org | a | b | |---+---| | 1 | 2 | #+END_org Playing a bit with the above code, removing `:results output' to see what would happen, I'm amazed by the results: #+begin_src sh :wrap org cat EOF | a | b | |---+---| | 1 | 2 | EOF #+end_src #+results: #+BEGIN_org | | | a | | | b | | | | ---+--- | | | | | | | | | 1 | | | 2 | | #+END_org Is it expected? Best regards, Seb -- Sebastien Vauban
Re: [O] Error with :wrap org in babel and 8.0-pre
Hello Nicolas, Nicolas Goaziou wrote: John Hendy jw.he...@gmail.com writes: #+RESULTS: #+BEGIN_org With the assumption of 100 lbs. of input material 1 and 200 lbs. of material 2, we can produce the following number of widgets based on injection mold wall thicknesses. | wall | vals | widgets | |---+--+--| | 5 mil | 0.01 | 4.00 | | 6 mil | 0.01 | 3.00 | | 8 mil | 0.01 | 25000.00 | #+END_org This is wrong. We discussed it months ago on this ML and, IIRC, Babel should produce #+begin_src org blocks, not #+begin_org. Org documentation specifies it too. Here, I think we confound two different syntaxes: - :results org, which produces #+BEGIN_SRC org..#+END_SRC - :wrap org, which produces #+BEGIN_org..END_org I didn't read the thread carefully, but you may want to use drawer output instead. My mind isn't clear yet about those use cases. Best regards, Seb -- Sebastien Vauban
Re: [O] Error with :wrap org in babel and 8.0-pre
Eric Schulte wrote: Nicolas Goaziou n.goaz...@gmail.com writes: John Hendy jw.he...@gmail.com writes: On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: John Hendy jw.he...@gmail.com writes: #+RESULTS: #+BEGIN_org ... #+END_org This is wrong. We discussed it months ago on this ML and, IIRC, Babel should produce #+begin_src org blocks, not #+begin_org. Org documentation specifies it too. Wrong, as in =:wrap org= behavior is currently a bug? Or wrong in that for my given use case, I shouldn't be using =:wrap org=? Wrong as is the current behaviour is a bug. It is expected to produce #+begin_src org blocks. Its use case is to generate dead data: I disagree, the current behavior is *not* a bug. From the manual. , | 14.8.2.23 ':wrap' | . | | The ':wrap' header argument is used to mark the results of source block | evaluation. The header argument can be passed a string that will be | appended to '#+BEGIN_' and '#+END_', which will then be used to wrap the | results. If not string is specified then the results will be wrapped in | a '#+BEGIN/END_RESULTS' block. ` I think you're confusing :results org with :wrap org. And it's even possible to use :wrap SRC org to get the same as :results org... That said, I don't think there is ever a case when you would want to use :wrap org. The solution to the original question is to use :results drawer. Best regards, Seb -- Sebastien Vauban
Re: [O] Error with :wrap org in babel and 8.0-pre
John, John Hendy wrote: Here's my summary of possible options from this thread and others in which I've tried to do similar things (=:exports results= used in all cases): 1) =:results output wrap=. - Documentation: none seems to suggest that this combination is even possible. - Behavior: Suggested in mailing list thread with Eric Schulte and works properly for me. Just to be complete, :results wrap has been deprecated since Org 7.9.2, and replaced by :results drawer. Best regards, Seb -- Sebastien Vauban
Re: [O] Error with :wrap org in babel and 8.0-pre
John,
John Hendy wrote:
I think you're confusing :results org with :wrap org.
And it's even possible to use :wrap SRC org to get the same as :results
org...
True, however I don't get the same output as I used to with this and
think it's essentially useless now. =#+begin_src org/end_src= used to
give me the equivalent of essentially a block of Org-mode syntax that
would be interpreted and parsed just as if it had no #+begin/end
around it. Now, it's output to LaTeX in \begin{verbatim} /
\end{verbatim}. It's treated like source code, not Org-mode text to be
exported.
=#+begin_src org= seems to be no different than =#+begin_example=
Yes, but for the syntax highlighting.
or =#+begin_src lang :exports code :eval no=
Yes, except that lang must be the same in the source and results block: so a
SQL code block producing SQL code, or R producing R, etc.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] New exporter and dates in tables
Hello, Nicolas Goaziou wrote: Bastien b...@gnu.org writes: I would find it both cleaner and more useful for users to extend `org-export-with-timestamps' with three choices: 'inactive-not-standalone 'active-not-standalone 'not-standalone This is a different idea. The change would happen at the exporter level, not at parser's. When set to 'not-standalone, it means export time-stamps except standone time-stamps, i.e. those who are alone on a line. Well, parsing is not line based, and a timestamp alone on a line doesn't mean much. Though, a timestamp alone in a paragraph is much easier to translate. IOW: 2013-04-13 Sat is not a standalone timestamp (use M-q). but, 2013-04-13 Sat is a standalone timestamp. Wouldn't it be a good moment to introduce APPT: 2013-04-13 Sat or maybe better named EVENT: 2013-04-13 Sat for things that only apply for today? Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Hi Eric, Sebastien Vauban wrote: Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric Schulte wrote: Emacs Lisp is an exception in terms of colname processing, it has default header arguments set to pass column names through to the code block, where the processing may be done trivially in Emacs Lisp. OK, but I don't understand the precedence of header arguments. I thought that a header argument given on the code block preempted all the other values (system-wide default for all languages, language defaults, file-wide arguments, and subtree arguments). Why isn't this true here as well? That is what is happening here, although combinations of :hlines and :colnames can be tricky. Especially weird, is that if you want to *unset* a header argument which is set at a higher level, you need to set it to '(), as in :colnames '(). #+name: unset-colnames-example-input | a | b | |---+---| | 1 | 2 | | 3 | 4 | ** Having no =:colnames= header argument (case 1) I understand that the following example does have =:colnames= set to =yes=: it is neither unset nor changed on the code block specification. #+begin_src emacs-lisp :var data=unset-colnames-example-input data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Hence, this result is what is expected. ** Using =:colnames no= header argument (case 2) #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Here, I still don't understand why I do see the table header line: I did change the default =:colnames yes= specification to =:colnames no= on the code block. I did override the default value. Why is the =no= argument not respected? This still escapes me. ** Using =:colnames ()= header argument (case 6) As you told me, to unset the =:colnames yes= header argument, we must use: #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames () data #+end_src #+results: | 1 | 2 | | 3 | 4 | That does work. What is still unclear to me as well, is why =()= and =nil= aren't the same from Babel's point of view? However, I think I understood this one: it is because nil is interpreted as a string, not as the empty list; right? That's because strings aren't quoted, right? Best regards, Seb -- Sebastien Vauban
Re: [O] Using a table value within the text (dynamic variable)?
'Mash Thomas Herbert wrote: I was wondering if it was possible at all to use like a variable within a document that would reference a table cell, and could then be dynamically updated when the table cell was? The reason I ask is that I would like to have have tabular data held in another document and then write my document referencing and including the data within the text, so I only have to change the external data and the document would be updated automatically. Example... #+TBLNAME: example |-+-| | Foo | Bar | |-+-| | 22 | 43 | | 44 | 54 | |-+-| Lorem ipsum dolor sit amet, @remote(example,B2) consectetur adipiscing elit. Nullam vehicula lobortis sem, ut viverra lorem elementum quis. Etiam ac lacus eu ante molestie vehicula. Maecenas sed viverra sem. Proin mattis fermentum orci, sed tempus nibh feugiat eget. Would become... Lorem ipsum dolor sit amet, 43 consectetur adipiscing elit. Nullam vehicula lobortis sem, ut viverra lorem elementum quis. Etiam ac lacus eu ante molestie vehicula. Maecenas sed viverra sem. Proin mattis fermentum orci, sed tempus nibh feugiat eget. Thoughts? Use an Org Babel (inline) code block which extracts part of the table. See indexing variables. Best regards, Seb -- Sebastien Vauban
Re: [O] Enriched/Org is a colorful Org
Carsten Dominik wrote: On 10 apr. 2013, at 12:48, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: On Wed, Apr 10, 2013 at 12:16:28PM +0200, Carsten Dominik wrote: On 10 apr. 2013, at 11:54, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: On Wed, Apr 10, 2013 at 09:32:44AM +0530, Jambunathan K wrote: See Side note towards the end of this message http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14157#8 This request is common enough; every time it comes up overlays are proposed as a solution. It would be good if this is available even as a library outside of Org. Yes, overlays are better. However, maybe I am just no getting it, but what is even the purpose of facemenu? AFAICS, the faces are non-permanent, so when I save the file and reopen it, all the faces are gone. I really cannot see a useful application for this. AFAIR, the use cases presented so far involved adding highlighting-like information in Org files. If the overlays are generated consistently based on the user's setup, it doesn't matter if they are non-permanent (as in not part of the Org file, but dependent on the Emacs setup instead). Of course this means the highlighting information will not be portable; but I don't think people mind that. I personally do not find any use for the feature as such; although it might be interesting to be able to insert plain text cookies in Org files and have them highlighted in some fashion. I could then use a list of ideas like this: Some topic ... 1. Idea 1 2. Idea 2 (?) where I'm doubtful about idea (2); having (?) highlighted would remind me of that. Just an idea. Yes, this would make sense if the highlighting would be reestablished automatically next time you visit the file. If not, it would be pretty useless in my eyes. IIUC, I do use something similar: automatic highlighting of some words, hooked on the mode (so, permanent... for me). --8---cut here---start-8--- (defface lvn/highlight-face '((t (:weight normal :slant normal :box '(:line-width 1 :color #CC) :foreground #CC :background #88))) Face for making FIXME and other warnings stand out.) (defvar lvn/highlight-org-regexps \\(FIXME\\|BUG\\|XXX\\|[Ee]rror\\|[Ww]arning\\|WARNING\\) Patterns to highlight (for Org mode only).) ;; set up highlighting of special patterns for Org mode only (dolist (mode '(org-mode)) (font-lock-add-keywords mode `((,lvn/highlight-org-regexps 1 'lvn/highlight-face prepend --8---cut here---end---8--- Best regards, Seb -- Sebastien Vauban
Re: [O] Using a table value within the text (dynamic variable)?
'Mash Thomas Herbert wrote:
OK thanks, I have never used Babel at all, but I believe I have found
the inline use.
src_lang[args]{code}
So I thought...
src_emacs-lisp[var: data=example-table[2:1]]{data}
But this does not work.
src_emacs-lisp[:var data=example-table[2,1]]{data} should work (untested)
^^
Two questions...
Am I right in saying even if I do get this to work, it would only
replace the inline code blocks (variables) on an export?
AFAIK, yes -- I've never really used inline code blocks.
But I think you could intermix real code blocks within paragraphs, if you
don't insert any blank line (= paragraph separator).
Or have a real block doing the work, exposing the answer in your Org buffer,
and have an inline code block to echo the answer.
It wouldn't work like a hyperlink and translate and hide the code block
underneath the value?
From what I understand from your question, no.
Best regards,
Seb
--
Sebastien Vauban
[O] test-org-babel/inline-src-blocks FAILED
-babel/inline-src-blocks ni (unwind-protect (ert-run-test test) (setf (aref (ert--stats-test-end (let ((ert--current-run-stats stats) (pos (ert--stats-test-pos stats ert-run-or-rerun-test([cl-struct-ert--stats \\(org\\|ob\\) [[cl-st (while (consp --cl-var--) (setq test (car --cl-var--)) (ert-run-or-r (let* ((--cl-var-- tests) (test nil)) (while (consp --cl-var--) (set (catch (quote --cl-block-nil--) (let* ((--cl-var-- tests) (test nil) (cl-block-wrapper (catch (quote --cl-block-nil--) (let* ((--cl-var-- (block nil (let* ((--cl-var-- tests) (test nil)) (while (consp --cl- (loop for test in tests do (ert-run-or-rerun-test stats test listene (progn (loop for test in tests do (ert-run-or-rerun-test stats test (unwind-protect (progn (loop for test in tests do (ert-run-or-rerun- (let ((ert--current-run-stats stats)) (force-mode-line-update) (unwi (unwind-protect (let ((ert--current-run-stats stats)) (force-mode-li (let ((abortedp t)) (unwind-protect (let ((ert--current-run-stats st (let* ((tests (ert-select-tests selector t)) (stats (ert--make-stats ert-run-tests(\\(org\\|ob\\) (lambda (event-type rest event-args) ert-run-tests-batch(\\(org\\|ob\\)) (let ((stats (ert-run-tests-batch selector))) (kill-emacs (if (zerop (unwind-protect (let ((stats (ert-run-tests-batch selector))) (kill- ert-run-tests-batch-and-exit(\\(org\\|ob\\)) (let ((org-id-track-globally t) (org-id-locations-file (convert-stan org-test-run-batch-tests() call-interactively(org-test-run-batch-tests nil nil) command-execute(org-test-run-batch-tests) command-line-1((-l ert.el -l ert-x.el -L /cygdrive/d/User command-line() normal-top-level() Test test-org-babel/inline-src-blocks condition: (ert-test-failed ((should (equal 2 (org-babel-execute-src-block))) :form (equal 2 3) :value nil :explanation (different-atoms (2 #x2 ?) (3 #x3 ? FAILED 73/372 test-org-babel/inline-src-blocks --8---cut here---end---8--- Best regards, Seb -- Sebastien Vauban
Re: [O] Enriched/Org is a colorful Org
Hi Carsten, Carsten Dominik wrote: On 10.4.2013, at 18:21, Eli Zaretskii e...@gnu.org wrote: From: Carsten Dominik carsten.domi...@gmail.com On 10 apr. 2013, at 11:54, Suvayu Ali fatkasuvayu+li...@gmail.com wrote: This request is common enough; every time it comes up overlays are proposed as a solution. It would be good if this is available even as a library outside of Org. Yes, overlays are better. I beg the Org developers to please be very careful when introducing expensive display features such as overlays into Org. Org already puts the Emacs display engine to its limits in many of its popular features; this is interesting input, I was not aware of this. Has this been discussed before, can you point me to relevant threads, and what are the symptoms of the display engine being at its limits? adding overlays to this mess might be too much. I guess Eli simply means, in a general way, that overlays do negatively impact display performance, as you said as well a couple of times: ╭ │ From: Carsten Dominik carsten.domi...@gmail.com │ Subject: Re: performance problems with drawers │ Newsgroups: gmane.emacs.orgmode │ To: Al gman...@wilec.net │ Cc: emacs-orgmode@gnu.org │ Date: Wed, 8 Jul 2009 07:05:53 +0200 (3 years, 39 weeks, 3 days ago) │ │ Hi Al, │ │ first of all, I cannot reproduce the fact that drawers have such │ a major influence on time, wit a test file that I created to │ be similar to what you describe. │ │ There is a way to speed up drawer handling, by using text properties │ instead of overlays. How have some vague plans to do this, but nothing │ concrete or soon. │ │ - Carsten ╰ and ╭ │ From: Carsten Dominik carsten.domi...@gmail.com │ Subject: Re: fontification and icon issues │ Newsgroups: gmane.emacs.orgmode │ To: David O'Toole dto1...@gmail.com │ Cc: emacs-orgmode@gnu.org │ Date: Thu, 24 Sep 2009 10:46:24 +0100 (3 years, 28 weeks, 2 days ago) │ │ On Sep 22, 2009, at 4:11 PM, David O'Toole wrote: │ [...] │ │ 2. using add-text-properties to specify a display property (or even just │ a face) for any part of an org headline text kills the fontification of │ the rest of the text (TODO keyword and leading stars unaffected.) I'm │ trying to use font-lock-add-keywords to display the images. │ │ Can you make an example file, and maybe a small function that does set these │ properties, so that I can see what you mean? │ │ - Carsten │ │ Maybe I should use overlays instead? │ │ This can be done, but if every line in a very large file gets │ an overlay, performance is severely degraded. │ │ - Carsten ╰ I don't know enough about Org to understand why overlays are being considered instead of text properties, but feel free to describe the issues (preferably on emacs-devel) and start a discussion about the possible alternatives. Best regards, Seb -- Sebastien Vauban
Re: [O] org-babel header documentation
Eric Schulte wrote: Eric Abrahamsen e...@ericabrahamsen.net writes: Eric Schulte schulte.e...@gmail.com writes: Exists on Worg? Sorry for my obtuseness, but I'm not finding it. http://orgmode.org/worg/org-contrib/babel/header-args.html Great! I just saw mention of the wrap header argument in another thread but that doesn't appear on this page, could we trouble you to add it? It would be *great* to have one canonical spot listing all the possibilities... I think this page is more for ancillary notes and tricks, the canonical spot is the manual, and it does mention the wrap header argument (apparently the preferred name is drawer). See the following. http://orgmode.org/manual/results.html To add a note: ╭ │ `:results wrap' is deprecated but still supported. ╰ since Org 7.9.2. Best regards, Seb -- Sebastien Vauban
Re: [O] test-org-babel/inline-src-blocks FAILED
Hello Achim, Achim Gratz wrote: Sebastien Vauban writes: I'm just trying to reuse ERT and run the tests on my (new, Bastien ;-)) machine. Results: Ran 372 tests, 371 results as expected, 1 unexpected (2013-04-10 22:04:05+0200) 10 expected failures 1 unexpected results: FAILED test-org-babel/inline-src-blocks More information: Yes, but not the interesting ones, like which Emacs you use. Anyway, this is a known problem with some Emacs versions on Windows and it only happens in batch mode so it can't be debugged. GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-12 on VBOX on Windows, yes. Best regards, Seb -- Sebastien Vauban
[O] [babel] Drop `:results code'?
Hello, Shouldn't we, for the sake of simplifying the multiple options, drop the support for `:results code'? It is completely redundant (though, less powerful) with `:wrap'. Best regards, Seb -- Sebastien Vauban
Re: [O] [BUG] org-clock-in menu scrolls off the top of the window
Hi Bernt Hansen, Bernt Hansen wrote: Sebastien Vauban writes: Bernt Hansen wrote: Another change I've noticed in master is the display of the clocking task menu when doing C-u M-x org-clock-in I've reduced my clocking menu items a bit due to screen size changes and not being able to see the items that scroll off the top of the screen (normally the most recent items are the ones I'm looking for but on small screens the menu scrolls up and I can't see the recent items). My current setting is (setq org-clock-history-length 23) My menu for clock-in tasks currently runs 1-9,A-N and starts with the Current Clocking Task on line 1. I have a widescreen monitor in windows and the bottom half of the menu is blank when the screen splits horizontally to display the clock in menu -- it seems to be centered near the last item in the list but this scrolls the default and interrupted clocking task entries off the top of the screen. There is no way to scroll this menu that I am aware of. The buffer *Clock Task Select* has , | Default Task | [d] OrganizeOrganization | The task interrupted by starting the last one | [i] OrganizeOrganization | Current Clocking Task | [c] SomeProject TODO SomeTask | Recent Tasks | [1] SomeProject TODO SomeTask | [2] OrganizeOrganization | [3] refile TODO foo | ... | [N] refile SomeOtherRefileTask ` but it scrolls with C-u M-x org-clock-in so it looks like this , | Current Clocking Task | [c] SomeProject TODO SomeTask | Recent Tasks | [1] SomeProject TODO SomeTask | [2] OrganizeOrganization | [3] refile TODO foo | ... | [N] refile SomeOtherRefileTask | ... lots of blank lines ` As your data is not that true, I can't tell from what you show, but another thing that I've seen (in my config) is that many tasks are duplicated, hence the list is much longer that needed. Do you see that as well in your case? For example, it seems to me that (in the second screen) item 1 is redundant with item c. In the first screen, items d, i and 2 seem redundant, while items c and 1 seem also redundant. The data has been modified but the duplication isn't new. The only tasks I renamed were 'SomeTask' and 'SomeOtherRefileTask'. I used capture to create foo as a temporary task (which I subsequently deleted). The actual task list came from projects at my work. Duplicated tasks in my displayed menu are really duplicated and as far as I know that behaviour hasn't changed. If there is a default, and current task (all the same) then [d], [c], and [1] will all be identical. The default task is only displayed when a default clocking task is identified (which is always for me). [c] may not be that useful to display since we can just quit and leave the clock alone. Personally I like the duplication in the history list (it's a true view of what was clocked in recently) Personally, I would find it clearer to see every task at most once, be it as default, interrupted or in the list. So, the interrupted task wouldn't be duplicated in the list. But I can understand that this is a question of taste. Something which is not a question of taste, IMHO, is that items are sometimes duplicated within the 1..N list: I have, for example, --8---cut here---start-8--- Recent Tasks [1] Read emails [2] Organize work [3] Organize work [4] Prepare meeting --8---cut here---end---8--- Items 2 and 3 are the same one -- I don't have Organize work duplicated within my agenda files. I don't understand why it's duped in there. Ever observed this as well? The main thing I'm reporting is all the whitespace now at the bottom of the screen since the list is artificially scrolled up. I used to be able to determine exactly what fit in the list so I set my history length appropriately. I know that item duplication is a side-question, but it does consume real screen estate... Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Hi Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric Schulte wrote: Emacs Lisp is an exception in terms of colname processing, it has default header arguments set to pass column names through to the code block, where the processing may be done trivially in Emacs Lisp. OK, but I don't understand the precedence of header arguments. I thought that a header argument given on the code block preempted all the other values (system-wide default for all languages, language defaults, file-wide arguments, and subtree arguments). Why isn't this true here as well? That is what is happening here, although combinations of :hlines and :colnames can be tricky. Especially weird, is that if you want to *unset* a header argument which is set at a higher level, you need to set it to '(), as in :colnames '(). Much clearer, but not yet crystal-clear for me... Let me explain. AFAICT, there were 5 possibles values of the :colnames header argument: - no header argument :: (default for all languages but Emacs Lisp) - :colnames no :: (default for Emacs Lisp code blocks) - :colnames yes :: Tells Org Babel that your first row contains column names. - :colnames LIST :: Specifies to use LIST as column names. - :colnames nil :: Same as :colnames yes. Right? Almost, values 1 (none) and 5 (nil) are the same. I don't share your view about this last statement. ** Input table #+name: unset-colnames-example-input | a | b | |---+---| | 1 | 2 | | 3 | 4 | ** Having no =:colnames= header argument (case 1) Same results for R and sh code blocks (first good news ;-)) -- I'm avoiding, on purpose, testing with Emacs Lisp... #+begin_src R :var data=unset-colnames-example-input data #+end_src #+results: | 1 | 2 | | 3 | 4 | #+begin_src sh :var data=unset-colnames-example-input echo $data #+end_src #+results: | 1 | 2 | | 3 | 4 | ** Using =:colnames nil= header argument (case 5) Once again, R and sh blocks do produce the same results... #+begin_src R :var data=unset-colnames-example-input :colnames nil data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | #+begin_src sh :var data=unset-colnames-example-input :colnames nil echo $data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | ... but they are _not_ equivalent to the no header argument (case 1). ** Using =:colnames yes= header argument (case 3) On the contrary, case 5 is equivalent to the case 3: same results as :colnames yes. #+begin_src R :var data=unset-colnames-example-input :colnames yes data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | #+begin_src sh :var data=unset-colnames-example-input :colnames yes echo $data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Now, indeed, your trick with :colnames '() (or even :colnames ()...) does work well for Emacs-Lisp... Though, I thought that () was equivalent to nil, but it seems not to be the case, then. Is it because of some sort of type coercion, that would convert nil as a string or something along such lines? See Emacs Lisp evaluation of variables in (info (org)var). Not sure to find what you want me to read in that page... We could add nil as a special exception, but that might be surprising to some people. As far as the Lisp interpreter is concerned, () and nil are the same, right? Then, why do you talk of adding a special exception? Maybe, I don't understand your point because I'm missing the context info you wanted me to read just above? Extra question: when do we have to use such a trick? When the value can be a list of things? If yes, why are you talking of :hlines -- there is no list argument there? Whenever you want to unset a header argument, which has a value set at some higher level. ** unset the colnames header argument #+name: unset-colnames-example-input | a | b | |---+---| | 1 | 2 | | 3 | 4 | Unlike most code blocks, Emacs Lisp has colnames set to yes in its default header arguments. [...] If we wanted to unset this value, we could do the following. #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames () data #+end_src #+RESULTS: | 1 | 2 | | 3 | 4 | This is clear -- thanks! -- but it does not unset the header argument as long as case 1 and 5 are not the same in the above given example (for R and sh blocks). Best regards, Seb -- Sebastien Vauban
Re: [O] converting people to Emacs and org-mode
Hi Christopher, Christopher Allan Webber wrote: Eric Abrahamsen writes: Russell Adams rlad...@adamsinfoserv.com writes: My experience has been that after watching me manage a project in Org for a few weeks, I have customers beg me to help them install it on their PC. I've had quite a few converts through working together and by example. Perhaps the web incarnations of org could help here too. Say the manager of a small group project were able to create a web-version of an agenda, and project members could filter that by clicking on javascript-enabled versions of tags corresponding to their TODOs, and even click the TODOs to change state, that could be a nice introduction to project management in Org. It might require too much org functionality to be re-written in javascript though? Dunno. I think a web application that allowed for orgmode-as-a-group-todo-management-system thing would be huge. It would require a lot of thinking of how to approach it in a way that would be nice and make sense. I'm not really sure what it would look like. But hook that up to git and you'd have a really interesting bug tracking system. I guess it should be in the spirit of configurable organizers like the TiddlyWiki based GTD systems (see http://www.tiddlywiki.com/): - MPTW (MonkeyPirateTiddlyWiki) :: http://mptw.tiddlyspot.com/ - mGSD :: http://mgsd.tiddlyspot.com/demo3.html and http://thinkcreatesolve.biz/mGSDEnhancements.html - D-cubed - tbGTD :: http://tbgtd.tiddlyspot.com/ That is the killer brother application for Org, for sure. There was that relevant GSoC project, but I'd be interested in this happening in python or similar. Now that we have the standard for orgmode as a file format... Best regards, Seb -- Sebastien Vauban
Re: [O] Google calendar sync - what is recommended?
Hi Rainer, Rainer M. Krug wrote: PS: org-unrelated gnus questions: 1) how can I insert these [1] footnotes in message-mode? See org-footnote. 2) how can I quote or enclose a block with these brackets in acsii code? --8---cut here---start-8--- In Gnus, C-c M-m (that is, the command message-mark-inserted-region). --8---cut here---end---8--- Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Hi Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric Schulte wrote: Emacs Lisp is an exception in terms of colname processing, it has default header arguments set to pass column names through to the code block, where the processing may be done trivially in Emacs Lisp. OK, but I don't understand the precedence of header arguments. I thought that a header argument given on the code block preempted all the other values (system-wide default for all languages, language defaults, file-wide arguments, and subtree arguments). Why isn't this true here as well? That is what is happening here, although combinations of :hlines and :colnames can be tricky. Especially weird, is that if you want to *unset* a header argument which is set at a higher level, you need to set it to '(), as in :colnames '(). #+name: unset-colnames-example-input | a | b | |---+---| | 1 | 2 | | 3 | 4 | ** Having no =:colnames= header argument (case 1) I understand that the following example does have =:colnames= set to =yes=: it is neither unset nor changed on the code block specification. #+begin_src emacs-lisp :var data=unset-colnames-example-input data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Hence, this result is what is expected. ** Using =:colnames no= header argument (case 2) #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Here, I still don't understand why I do see the table header line: I did change the default =:colnames yes= specification to =:colnames no= on the code block. I did override the default value. Why is the =no= argument not respected? ** Using =:colnames yes= header argument (case 3) #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames yes data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Here, the =:colnames yes= specification is simply redundant to what's specified for the emacs-lisp language. In all cases, the results is what is should be. ** Using =:colnames nil= header argument (case 5) #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames nil data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | As written in my previous post, =:colnames nil= is equivalent to =:colnames yes= in Emacs Lisp, R and sh code blocks -- at least. (Still) not clear to me -- sorry to be stubborn. ** Using =:colnames ()= header argument (case 6) As you told me, to unset the =:colnames yes= header argument, we must use: #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames () data #+end_src #+results: | 1 | 2 | | 3 | 4 | That does work. ** Using =:colnames ()= header argument (case 7) So does the quoted empty list version... #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames '() data #+end_src #+results: | 1 | 2 | | 3 | 4 | What is still unclear to me as well, is why =()= and =nil= aren't the same from Babel's point of view? Best regards, Seb -- Sebastien Vauban
[O] [babel] Specified colnames
Hi Eric, I'm trying to specify the column names of the table. #+name: input | title | baz | |---+-| | obs1 | foo | | obs2 | bar | But both versions (with symbols or strings) just do return the plain input table. #+name: R-echo-colnames-list #+begin_src R :var data=input :exports results :colnames '(Rev Author) data #+end_src #+name: R-echo-colnames-qlist #+begin_src R :var data=input :exports results :colnames '(Rev Author) data #+end_src Am I doing something wrong? Best regards, Seb -- Sebastien Vauban
Re: [O] [BUG] org-clock-in menu scrolls off the top of the window
Hi Bernt, Bastien, Bernt Hansen wrote: Another change I've noticed in master is the display of the clocking task menu when doing C-u M-x org-clock-in I've reduced my clocking menu items a bit due to screen size changes and not being able to see the items that scroll off the top of the screen (normally the most recent items are the ones I'm looking for but on small screens the menu scrolls up and I can't see the recent items). My current setting is (setq org-clock-history-length 23) My menu for clock-in tasks currently runs 1-9,A-N and starts with the Current Clocking Task on line 1. I have a widescreen monitor in windows and the bottom half of the menu is blank when the screen splits horizontally to display the clock in menu -- it seems to be centered near the last item in the list but this scrolls the default and interrupted clocking task entries off the top of the screen. There is no way to scroll this menu that I am aware of. The buffer *Clock Task Select* has , | Default Task | [d] OrganizeOrganization | The task interrupted by starting the last one | [i] OrganizeOrganization | Current Clocking Task | [c] SomeProject TODO SomeTask | Recent Tasks | [1] SomeProject TODO SomeTask | [2] OrganizeOrganization | [3] refile TODO foo | ... | [N] refile SomeOtherRefileTask ` but it scrolls with C-u M-x org-clock-in so it looks like this , | Current Clocking Task | [c] SomeProject TODO SomeTask | Recent Tasks | [1] SomeProject TODO SomeTask | [2] OrganizeOrganization | [3] refile TODO foo | ... | [N] refile SomeOtherRefileTask | ... lots of blank lines ` As your data is not that true, I can't tell from what you show, but another thing that I've seen (in my config) is that many tasks are duplicated, hence the list is much longer that needed. Do you see that as well in your case? For example, it seems to me that (in the second screen) item 1 is redundant with item c. In the first screen, items d, i and 2 seem redundant, while items c and 1 seem also redundant. Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Specified colnames
Hi Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: I'm trying to specify the column names of the table. #+name: input | title | baz | |---+-| | obs1 | foo | | obs2 | bar | But both versions (with symbols or strings) just do return the plain input table. #+name: R-echo-colnames-list #+begin_src R :var data=input :exports results :colnames '(Rev Author) data #+end_src #+name: R-echo-colnames-qlist #+begin_src R :var data=input :exports results :colnames '(Rev Author) data #+end_src Am I doing something wrong? It looks like ob-R implements its own result table reconstruction instead of using the general support. This is because R actually has a notion of column names and row names internally. The implementation in ob-R does not correctly handle specified colnmaes as your example shows. The attached patch brings ob-R closer to the using the unified general table reconstructed used in most other languages, and fixes your problem mentioned above. I haven't applied it however, as it may introduce other bugs related to specifying column names from within R. For example, I'm not sure that it will now correctly apply column names from a table built entirely from within R. Thanks for your help. Extra question: tested with a sh block, both of the above do work, that is with strings or symbols. Which one is supposed to be better (that is, will be more portable with time), if there is one? Additional testing by someone more familiar with R than myself would be greatly appreciated. Can't yet be that person, sadly. But time will come that... Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Hi Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric Schulte wrote: Emacs Lisp is an exception in terms of colname processing, it has default header arguments set to pass column names through to the code block, where the processing may be done trivially in Emacs Lisp. OK, but I don't understand the precedence of header arguments. I thought that a header argument given on the code block preempted all the other values (system-wide default for all languages, language defaults, file-wide arguments, and subtree arguments). Why isn't this true here as well? That is what is happening here, although combinations of :hlines and :colnames can be tricky. Especially weird, is that if you want to *unset* a header argument which is set at a higher level, you need to set it to '(), as in :colnames '(). Much clearer, but not yet crystal-clear for me... Let me explain. AFAICT, there were 5 possibles values of the :colnames header argument: - no header argument :: (default for all languages but Emacs Lisp) - :colnames no :: (default for Emacs Lisp code blocks) - :colnames yes :: Tells Org Babel that your first row contains column names. - :colnames LIST :: Specifies to use LIST as column names. - :colnames nil :: Same as :colnames yes. Right? Now, indeed, your trick with :colnames '() (or even :colnames ()...) does work well for Emacs-Lisp... Though, I thought that () was equivalent to nil, but it seems not to be the case, then. Is it because of some sort of type coercion, that would convert nil as a string or something along such lines? Extra question: when do we have to use such a trick? When the value can be a list of things? If yes, why are you talking of :hlines -- there is no list argument there? Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Specified colnames
Eric, Eric Schulte wrote: Extra question: tested with a sh block, both of the above do work, that is with strings or symbols. Which one is supposed to be better (that is, will be more portable with time), if there is one? Both will be maintained. The contribution of a test exercising both options could provide an extra guarantee of perseverance. This is also a good first step towards editing the code. :) Here's my trial to do so. --8---cut here---start-8--- (ert-deftest test-ob/specific-column-names-symbols () Test passing specific column names as a list of symbols. (should (equal #+name: input-table | id | var1 | |+--| | 1 | bar | | 2 | baz | #+begin_src sh :var data=input-table :exports results :colnames '(Rev Author) echo \$data\ #+end_src #+results: | Rev | Author | |-+| | 1 | bar| | 2 | baz| (org-test-with-temp-text #+name: input-table | id | var1 | |+--| | 1 | bar | | 2 | baz | #+begin_src sh :var data=input-table :exports results :colnames '(Rev Author) echo \$data\ #+end_src (org-babel-execute-src-block) (buffer-string) --8---cut here---end---8--- Does this correspond to what you're asking for? However, running it did not succeed. I must do something wrong, or NOT do something good... ╭ │ Selector: t │ Passed: 0 │ Failed: 0 │ Total: 0/1 │ │ Started at: 2013-04-08 22:45:19+0200 │ Aborted. │ Aborted at: 2013-04-08 22:45:19+0200 │ │ A │ │ A test-ob/specific-column-names-symbols │ Test passing specific column names as a list of symbols. │ aborted ╰ The worse is that I don't get a backtrace, even after: - setting debug-on-error to t, or - M-x'ing toggle-debug-on-error. Weird, but not the first time -- seems related to Emacs 24.2 or so (+ my config?). Best regards, Seb -- Sebastien Vauban
Re: [O] CSS link in html export for v. 7.9.3e woes
Hi François, Bastien, Bastien wrote: François Pinard pin...@iro.umontreal.ca writes: There does not seem to be any reference to HTML_STYLE in the Org manual. (Org version 7.9.3e (7.9.3e-1751-g8c47da) — taken this morning). I guess Sébastien meant #+HTML_HEAD -- #+HTML_STYLE does not exist anymore. Yes HTML_STYLE has been changed in between, to a better keyword, btw. Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Hi Eric, Eric Schulte wrote: Emacs Lisp is an exception in terms of colname processing, it has default header arguments set to pass column names through to the code block, where the processing may be done trivially in Emacs Lisp. OK, but I don't understand the precedence of header arguments. I thought that a header argument given on the code block preempted all the other values (system-wide default for all languages, language defaults, file-wide arguments, and subtree arguments). Why isn't this true here as well? * Call at export time #+call: ELisp-echo-1(data=input) I get: | id | var1 | | id | var1 | | obs1 | foo | | obs2 | bar | Not at all what I was expecting... Agreed, I've just pushed up a fix, so the following now works. #+name: input | id | var1 | |--+--| | obs1 | foo | | obs2 | bar | #+name: ELisp-echo-1 #+begin_src emacs-lisp :var data=input :exports results data #+end_src #+call: ELisp-echo-1(data=input) #+RESULTS: ELisp-echo-1(data=input) | id | var1 | |--+--| | obs1 | foo | | obs2 | bar | Thanks for pointing this out. Here, I understand that the #+call line uses the default header argument set on the language. So, that seems right to me as well... Thanks. Best regards, Seb -- Sebastien Vauban
[O] [babel] Bugs for Emacs Lisp code blocks
Hello, Here are some tests with the colnames parameter *and* the Emacs Lisp language for the echo code block. They're giving results I don't understand... Note that functionally the same echo code block in other languages (I tested R and sh) does return the expected results. * Input table Consider this input table, with 2 rows, and a header row. #+name: input | id | var1 | |--+--| | obs1 | foo | | obs2 | bar | * Interactive calls Let's try different calls, changing the =:colnames= parameter. 1. Using =:colnames yes= #+name: ELisp-echo-1 #+begin_src emacs-lisp :var data=input :colnames yes :exports results data #+end_src #+results: ELisp-echo-1 | id | var1 | |--+--| | obs1 | foo | | obs2 | bar | OK; the result is what I expected. 2. Using =:colnames no= #+name: ELisp-echo-2 #+begin_src emacs-lisp :var data=input :colnames no :exports results data #+end_src #+results: ELisp-echo-2 | id | var1 | |--+--| | obs1 | foo | | obs2 | bar | Here, I was expecting: | id | var1 | | obs1 | foo | | obs2 | bar | 3. Using no =:colnames= header argument #+name: ELisp-echo-3 #+begin_src emacs-lisp :var data=input :exports results data #+end_src #+results: ELisp-echo-3 | id | var1 | |--+--| | obs1 | foo | | obs2 | bar | Here, I was expecting: | obs1 | foo | | obs2 | bar | * Call at export time #+call: ELisp-echo-1(data=input) I get: | id | var1 | | id | var1 | | obs1 | foo | | obs2 | bar | Not at all what I was expecting... Best regards, Seb -- Sebastien Vauban
Re: [O] avoid subscripting text
Hello, Mike McLean wrote: On Apr 3, 2013, at 9:30 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: I use LaTeX export all the time, but almost always with words with underscores in them (data from external tables, variable names and so on). So I never want _ to turn into a subscript. Just one data point, but that's how I use it. I have to echo this use case. I have variable names and what not with underscores in the name about 100 times as much as I have a need for a subscript. Do you mean that the option ^:nil is not working for you, or not enough? Best regards, Seb -- Sebastien Vauban
Re: [O] Org-mode as a metalanguage: calling SQL functions
Hello Eric, Eric Schulte wrote: At this point I'm not sure if the documentation or the code should be amended. I've personally never liked the args-in-block-name syntax, but I don't recall if we formally decided to abandon it, or if it has simply been broken in a recent commit. I am not sure if I have any say here, but I agree that the args in name notation looks not as good and might be considered for abolishment. Great, I agree wholeheartedly and I'll update the documentation accordingly (and take a look at lob-ingest to ensure it no longer uses this var-in-name style). I confirm that, following a discussion we had, you had decided to drop the alternate syntax, a couple of months ago (more than 2 ;-)). Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Process hlines in imported tables
Hi Achim, Achim Gratz wrote: Rick Frankel writes: Missed verbatim. Thanks for the pointer, it works, but i think that perl is double-processing returned values. If we do the same things in elisp i get (my) expected results: #+begin_src elisp :results raw |c1|c2| |- |a|1| |b|2|; #+end_src Elisp is different from all other languages: it doesn't do any processing of strings to begin with for value returns. The reason that Perl processes raw results is that org-babel-result-cond does not switch to the scalar path for this condition, which is why you need the extra verbatim. It probably should, though, so if Eric agrees then I will push a change that does this. IIUC, wouldn't that be changing the default answer to how to interpret the results just for Perl? While the default answer for all languages seems to be table? Best regards, Seb -- Sebastien Vauban
Re: [O] Org-mode as a metalanguage: calling SQL functions
Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric Schulte wrote: At this point I'm not sure if the documentation or the code should be amended. I've personally never liked the args-in-block-name syntax, but I don't recall if we formally decided to abandon it, or if it has simply been broken in a recent commit. I am not sure if I have any say here, but I agree that the args in name notation looks not as good and might be considered for abolishment. Great, I agree wholeheartedly and I'll update the documentation accordingly (and take a look at lob-ingest to ensure it no longer uses this var-in-name style). I confirm that, following a discussion we had, you had decided to drop the alternate syntax, a couple of months ago (more than 2 ;-)). Great, so I'm not imagining things. Thanks Seb. For the sake of clarity, it all began (in September 2011) with the fact it was more difficult to trap errors such as missing default value, in the functional-syntax style. See http://article.gmane.org/gmane.emacs.orgmode/46888. This also lead, a couple of weeks later (October 2011), to questionning the multiple keywords used for code blocks, such as #+source: and #+srcname:. See http://article.gmane.org/gmane.emacs.orgmode/48399. Best regards, Seb -- Sebastien Vauban
Re: [O] Help with beamer
Hi Erich, Neuwirth Erich wrote: I am preparing a presentation with or-mode and beamer. I am using :PROPERTIES: :BEAMER_envargs: [+-] :END: to make list elements appear one by one. When creating handouts, I want to supress the build effect (it works by creatin many slides unnecessary in printout) Is there a way of using a global variable to enable or disable all these blocks controlling the build effects so I can avoid changing them all one by one? #+LaTeX_CLASS_OPTIONS: [presentation] should do it. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Process hlines in imported tables
Rick, Achim, Eric, Rick Frankel wrote: I agree. raw results should probably be treated as scalar (with cycling of the output to reformat an table :). I think (!) I fully agree with that as well. Just that I wouldn't like more exceptions in the supported languages. So, if it's kindof the new default, great. BTW, I am having problems wrapping my head around verbatim. From testing, it seems that verbatim acts the same as scalar. 100% true; they're just synonyms [1]. FYI, so are `table' and `vector'... Best regards, Seb [1] I hate synonyms. I'd be in favor of just keeping one syntax... -- Sebastien Vauban
Re: [O] [PATCH] Process hlines in imported tables
Eric, Eric Schulte wrote: I would agree that this (meaning raw implies scalar) should either occur for all languages or for none. I think this is something interesting, but I wonder now if we wouldn't loose more than we would win. I mean: how would one be able to output a real raw result, then, that is one where pipes are not interpreted as table field separator which have to be aligned in some specific way. Do we need another argument for that? I mean: at the end, raw should really be raw (no interpretation). If we want some cycling for table alignment purpose (BTW, do you have lots of such code blocks?), maybe it'd be better to introduce a `cycle' argument or so? If we do have such header argument implications, then we'd want to put them into the weakest portion of the default header argument hierarchy. Currently this hierarchy looks something like 1. default header arguments shipped with Org-mode 2. user-set default header arguments 3. default languages-specific header arguments shipped with Org-mode 4. user-set default language-specific header arguments 5. buffer or file level header arguments 6. subtree header arguments 7. code block header arguments I think this raw implies verbatim action should probably take place somewhere between 3 and 4, but there could be arguments for other positions. Also, without looking at the code, I'm not sure how difficult adding such implications would be. Maybe I don't understand the problem correctly, but I'd think this raw implies verbatim would have to take place after _each_ above step. If between 3 and 4, then a raw specified on the block level (step 7) wouldn't imply verbatim? Does that make sense? I think every raw (be it default, language, buffer, subtree or block-local) would have to imply the same reasoning. Are there other header argument implication rules which would make code blocks do what I mean more naturally in more situations? Best regards, Seb -- Sebastien Vauban
Re: [O] Incompatible agenda commands
Bastien, Bastien wrote: Sebastien Vauban writes: While a custom agenda command such as the following used to work some time ago, it does not anymore. (add-to-list 'org-agenda-custom-commands '(D Stuck + agenda ((stuck ) (agenda ((org-agenda-span 'week) t) Now, it seems that the stuck block view inhibits any extra view to be displayed afterward. do I understand correctly that you only get the stuck view and not the agenda view? Yes, you do understand what I meant. If so, I cannot reproduce it. I hate those! I'll try to provide you with a reproducible recipe, then. Thanks for looking at it. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Process hlines in imported tables
Hi Rick, Rick Frankel wrote: IIUC, wouldn't that be changing the default answer to how to interpret the results just for Perl? While the default answer for all languages seems to be table? It's not. only shell (which doesn't have _value_ results), Is this statement really true, btw? Wouldn't the value result of a sh code block be the return code? and sql, force the results to be interpreted as a table. Because table is the default option... elisp, ruby and python seem to treat raw results as scalars. For ELisp, Eric told that it was an exception. For Ruby and Python, I dunno, as I don't know the languages and have no environment ready to test them (under Windows). Best regards, Seb -- Sebastien Vauban
Re: [O] org-check.org confusion
Hi David, Loyall, David wrote: But how do I, also an Emacs newbie, know that? Well, lock files aren't peculiar to Emacs. Have a look: http://en.wikipedia.org/wiki/File_locking#Lock_files :) How do you remove the lock? Well, first close all your Emacs buffers (on any machine, anywhere) that are pointed at the org-check.org file. Then see if the lock file is still there. If it's there, and you're not editing the file in an Emacs buffer, than the lock is stale. Manually delete it. (Alternatively, Emacs has some user interface for doing this. It is described in that info page ^^^.) When you open f.org, if there is an #f.org# file, Emacs will let you know: You should recover this file is displayed in the echo area. Then, simply type M-x recover-this-file, and answer: - yes, to overwrite f.org with that auto-saved version - no, to simply delete #f.org# FYI, I've customized the color `recover-this-file' with an orange background in order to clearly see that Emacs has something to tell me, even if I overlooked the msg in the echo area: ... (recover-this-file ((,class (:background white :background #FF3F3F Best regards, Seb -- Sebastien Vauban
Re: [O] org-capture equivalent of org-remember's % ?
Hi Adam, Adam Spiers wrote: I'm finally switching from org-remember to org-capture. M-x org-capture-import-remember-templates works fine except that it doesn't know how to translate %, which causes a jump to the target location immediately after storing the note. Is there an org-capture equivalent of org-remember's % ? I don't know specifically about that one -- which seems to have disappeared -- but there is an alternative, anyway: ╭ │ When called interactively with a C-u prefix argument GOTO, don't capture │ anything, just go to the file/headline where the selected template stores its │ notes. With a double prefix argument C-u C-u, go to the last note stored. ╰ So, finish your capture by `C-u C-u C-c C-c'... Best regards, Seb -- Sebastien Vauban
Re: [O] #+call split into multiple lines?
Hi Thomas, Thomas S. Dye wrote: In this situation I often put the arguments in a named Org table and then write the Babel source code block to take a single argument--the table name--and parse the information passed in that way. #+name: card-table | cname | gname | photo | etc.| | Dr. Stefan Vollmar | Stefan | stefan-vollmar.jpg| ... | | Dr. Stefan Vollmar, Jr. | Stefan Jr. | stefan-vollmar-jr.jpg | ... | #+call: mhead-hcard(card=card-table[0,]) for Stefan #+call: mhead-hcard(card=card-table[1,]) for Stefan Jr. If you don't mind writing some extra code for the Babel function, then #+call: mhead-hcard(card=card-table,gname=Stefan) etc. And do you eventually have a way to write a for-loop for all the lines of the tables, not being forced to write as many calls as the number of lines you do have? I don't see (immediately) how to do such, but that would really allow to promote such a use case! Best regards, Seb -- Sebastien Vauban
Re: [O] :session question - header argument setting
Hi Rainer, Rainer M Krug wrote: #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . org-R))) #+end_src OK - that I see how this works. Although I would very much like to have a syntax to define this default language header as #+PROPERTY as it would be more consistent. But I remember there was a way of executing this code when opening but I can't find it anymore. File local variable? Best regards, Seb -- Sebastien Vauban
[O] Incompatible agenda commands
Hello, While a custom agenda command such as the following used to work some time ago, it does not anymore. --8---cut here---start-8--- (add-to-list 'org-agenda-custom-commands '(D Stuck + agenda ((stuck ) (agenda ((org-agenda-span 'week) t) --8---cut here---end---8--- Now, it seems that the stuck block view inhibits any extra view to be displayed afterward. Best regards, Seb -- Sebastien Vauban
Re: [O] Minibuffer jumping to two lines when agenda displays 4th level heading
Hello Edward, Edward DeMeulle wrote: Just realized that I was incorrect about the level. It is actually when moving the cursor in the agenda to a 4th level heading that the minibuffer expands in size to two lines and then back to one line when moving to another entry that isn't 4th level. This happens under Linux but not Windows. Am I the only one experiencing this? Try: --8---cut here---start-8--- ;; minibuffer window expands vertically as necessary to hold the text ;; that you put in the minibuffer (setq resize-mini-windows t) --8---cut here---end---8--- (instead of the 'grow-only default) Best regards, Seb -- Sebastien Vauban
Re: [O] Html-Exporter Hanling images / links
Hi Robert, Robert Eckl wrote: with Org-mode version 8.0-pre (release_8.0-pre-193-gaa7b1e i got some issues handling images and links: A Link [[http://www.mypage.de][description]] results in idesription/i without any link. FWIW, I confirm this bug. Best regards, Seb -- Sebastien Vauban
Re: [O] Org-mode as a replacement for Google Reader
Hi Nick, Nick Dokos wrote: - I wish Emacs to be able to actually render HTML in a buffer (w3m not a valid option under Windows at least) Under Linux, w3m is usable (just barely) but like all text browsers, it works better with text-heavy pages without too many bells and whistles: certainly not a substitute for a full-blown browser. Re: Windows - the web page says it's available on Windows (with Cygwin): is that not true? It is available from Cygwin, and it does work well for the HTML mails I receive in Gnus. Of course, it's limited (no JavaScript, a.o.), but that's no different from under Linux. Best regards, Seb -- Sebastien Vauban
Re: [O] Org spreadsheet formula range destination and per-cell placement for Lisp
Paul, Paul Michael Reilly wrote: I am in the throes of setting up an Org mode spreadsheet for an invoicing/status/planning tool and came across this fabulous thread: *[O] org table calc and lisp for hh:mm timetablehttp://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00972.html *at http://lists.gnu.org/archive/html/emacs-orgmode/2011-03/msg00972.htmlwhich provided me much of what I need. So thanks to all involved for that excellent piece of work. The one problem I am having trouble grasping is in how to use Emacs Lisp to generate a range of values automagically. I have no trouble with a single cell using Lisp and passing in a rectangular region to process or in setting up a region using the Org table/spreadsheet/calc support described in the various Google accessible documentation. What I am trying to do at a high level is setup a table with rows of actions spanning a start and stop time. Each action row has a bill-to category column. In the table, as part of a Lisp based formula, I want to process these action rows and build a list of bill-to : total time summary values and then place these summaries in a range in the table, so a fragment of the table might look like: ... | Client1 | Client2 | Commute | ... ... | 12.50 | 22.00 | 10.5| ... where the numbers (hours) have been summed by filtering the task rows by clients. Hope that's clear. So there are essentially two issues for me: the first is understanding how to associate a range destination for a Lisp based formula result, which I think can be done, I just do not understand how to do it yet, and second, probably an enhancement request, is to figure out how to pass a list of cell addresses to a List form (along with other data) and have the form compute and store values to those cells. The latter would a sort of holy grail, at least for me. I won't answer your post, but will present you what I'm doing, as I'm using Org for billing my clients. How I do is: - Clock my time in the client file - Generate a dynamic block for each client file Quite easy. So, this is just to show you an alternative, in case you did overlook that. Best regards, Seb -- Sebastien Vauban
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hi Bastien, Bastien wrote: Sebastien Vauban writes: Nick Dokos wrote: Can we please make it an invariable practice to run `make test' before every push? Isn't it possible to put such in some sort of Git pre-commit hook (or pre-push hook), so that it gets automatically enforced? If anyone knows how to setup an automated tests framework for Org, feel free to go ahead, we will use it and monitor broken tests to see what's wrong in the code or in the tests or in the environment running the tests. Testing is a nice habit to have, but let's not make it a coercive pre-requisit before pushing patches. My whole thinking here is well captured by Rich Hickey: http://codequarterly.com/2011/rich-hickey/ Fogus: You have been known to speak out against test-driven development. Do you mind elaborating on your position? Hickey: I never spoke out ‘against’ TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design. The text you mention refers about time to write extra test suites. I was referring to simply have make test _run_ before being able to push commits. Best regards, Seb -- Sebastien Vauban
Re: [O] Macro expansion to control beamer template
Hello Florian,
Florian Adamsky wrote:
at the moment I revise my course lectures and of course I use org-mode
for that. I was searching for an easy way to create fullframe. After
searching a bit in the mailing list, I found out that the 8.0-pre with
its new beamer exporter already has this functionality. Therefore I
switch to the current git-version. Wonderful work by the way!
I created a beamer template file that I control with macros. My
org-mode config file has the following snippet:
(add-to-list 'org-latex-classes
(list beamer
(file-string (concat custom-basedir templates/beamer.tex))
'(\\section{%s} .\\section*{%s})
'(\\subsection{%s} . \\subsection*{%s})
'(\\subsubsection{%s} . \\subsubsection*{%s})))
The beamer.tex file contains snippets like that:
\documentclass[xetex,aspectratio={{{BEAMERRATIO}}}]{beamer}
[...]
\newcommand{\myEmail}{\urlEMAIL}
\newcommand{\myUrl}{\urlURL}
\newcommand{\myShortConf}SHORTCONF
\newcommand{\myLongConf}LONGCONF
This does not work anymore. After searching a bit in the ml archive I
have read that the macro is not as powerful as before. The macro works
only in the org file and not in my template file. What is the best way
to work around this problem?
Would an INCLUDE in the Org file do the work for you?
Would you agree with such a solution (having to explicitly put one extra line
in all your Org Beamer files)?
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [BUG] ob-sql.el: probably an extra paren
Hi Nick, Nick Dokos wrote: Can we please make it an invariable practice to run `make test' before every push? Isn't it possible to put such in some sort of Git pre-commit hook (or pre-push hook), so that it gets automatically enforced? Best regards, Seb -- Sebastien Vauban
Re: [O] Possible to collapse State List by default?
Hi Bastien, Bastien wrote: Martin Butz m...@mkblog.org writes: I wonder if it is possible to collapse the list of state changes below SCHEDULED by default; as I have lots of tasks which I'll be working on several days and use to clock in to track the time I have also lots of entries like the following example. (setq org-log-into-drawer t) I definitely think that this should be made the default. or (setq org-log-into-drawer LOGBOOK) Both are equivalent. You can also use this startup option in an Org file: #+STARTUP: logdrawer This is a FAQ, perhaps LOGBOOK is a better default value for `org-log-into-drawer'. What do you all think? You mean: #+STARTUP: logbook ? Best regards, Seb -- Sebastien Vauban
Re: [O] problems with org-protocol + capture templates
Hi Alvar, Alvar Maciel wrote: Hi to all, I'm using org-mode as personal day planner with almost all the configuration of http://doc.norang.ca/org-mode.html I try to use org-protocol to send links to emacs using the config of worg. But when emacs open i can not select the template of the capture mode (it's weird months ago was working) and i don't know were is my mistake. this is my keybindidng var orgProtoString = 'org-protocol://capture://'+ encodeURIComponent(gBrowser.currentURI.spec) + '/' + encodeURIComponent(gBrowser.contentWindow.document.title) + '/' + encodeURIComponent(content.window.getSelection()); gBrowser.loadURI(orgProtoString); my capture template (setq org-capture-templates (quote ((t todo entry (file ~/en uso/2013/org/refile.org) * TODO %?\n%U\n%a\n :clock-in t :clock-resume t) (r respond entry (file ~/en uso/2013/org/refile.org) * NEXT Respond to %:from on %:subject\nSCHEDULED: %t\n%U\n%a\n :clock-in t :clock-resume t :immediate-finish t) (n note entry (file ~/en uso/2013/org/refile.org) * %? :NOTE:\n%U\n%a\n :clock-in t :clock-resume t) (j Journal entry (file+datetree ~/Dropbox/en uso/2013/org/diary.org) * %?\n%U\n :clock-in t :clock-resume t) (w org-protocol entry (file ~/en uso/2013/org/refile.org) * TODO Review %c\n%U\n :immediate-finish t) (p Phone call entry (file ~/en uso/2013/org/refile.org) * PHONE %? :PHONE:\n%U :clock-in t :clock-resume t) (h Habit entry (file ~/en uso/2013/org/refile.org) * NEXT %?\n%U\n%a\nSCHEDULED: %(format-time-string \%Y-%m-%d %a .+1d/3d\)\n:PROPERTIES:\n:STYLE: habit\n:REPEAT_TO_STATE: NEXT\n:END:\n AFAIK, no, you can't dynamically select your template. The default template for org-protocol is bound to `w'. Though, you can change that for your Emacs sessions. Best regards, Seb -- Sebastien Vauban
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] [RFC] Org version of the Org manual
Hi Carsten,
Carsten Dominik wrote:
On 17.3.2013, at 02:19, Thomas S. Dye t...@tsdye.com wrote:
Hi Achim,
Achim Gratz strom...@nexgo.de writes:
Hi Tom,
I'm playing around with the current version, here is what I have so far:
The arguments to #+attr_texinfo need to lose the double quotes
Index entries in description lists must be separated from their entry by
at least one blank line like in the example below, otherwise the second
such entry gets indented in the exported .texi file and that somehow
confuses texinfo for some of them.
- {{{kbd(v d)}}} or short {{{kbd(d)}}}, ~org-agenda-day-view~ ::
{{{kindex(v d)}}}
{{{kindex(d)}}}
{{{vindex(org-agenda-span)}}}
With these hanges I get the manual exported correctly to all formats.
Done. Thanks.
I brought the manual up-to-date and used @@info:@@ for the problem macro
characters, so it should be completely converted to Org now.
I tried the file on github, and export to texinfo fails with the attached
backtrace (exports to other backends as well).
I love this idea, so I really want to try. Any ideas what might be wrong on
my side?
- Carsten
Debugger entered--Lisp error: (error Unknown marker at 281861)
Could you try M-x goto-char 281861?
I have such a msg in old files where I had my own @ markes.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [RFC] Org syntax (draft)
Hi Achim,
Achim Gratz wrote:
Nicolas Goaziou writes:
As discussed a few days ago, here is a document describing the complete
Org syntax as read by the parser. I also added some comments. I am going
to put the Org file on Worg, so anyone can update it and fix mistakes.
after some playing with the Org manual in Org that Tom has been working
on I am starting to think that there should be a way to define the same
macro differently for different export backends. That would be mainly
so that you could have a macro expansion use export snippets tailored to
that backend where (after stripping the export snippets) the expansion
makes little or no sense in other backends. What do you think?
This is already possible, as once explained by Nicolas on this ML:
╭
│ You can also have macros generating raw code geared towards LaTeX or HTML
│ back-ends (through export-snippets). For example:
│
│ #+MACRO: my-mod @@e-latex:\something{$1}e-html:div
class=something$1/div@@
│
│ This is an example: {{{my-mod(text)}}}.
╰
Best regards,
Seb
--
Sebastien Vauban
Re: [O] A mix of habits and effort estimates?
Hi Marcin, Marcin Borkowski wrote: Dnia 2013-03-16, o godz. 22:59:18 Sebastien Vauban wxhgmqzgw...@spammotel.com napisał(a): Marcin Borkowski wrote: Bastien b...@altern.org napisał(a):' Marcin Borkowski mb...@wmi.amu.edu.pl writes: Is such a thing possible in Org-mode? Did you check (info (Org)Tracking your habits) ? As I mentioned (though only in the subject), yes. This is close, but my point is not I want to do this at least once each three days or something like this, but rather I want to spend at least 180 minutes every week on this - regardless of days. Of course, I could do it with the habits module (and if there's no other solution, I will do it like this), but what I'd like to have is actually a mixture of habits and effort estimates/clocking. No problem for that. - For the sake of facility, give a unique tag to your educational task - Clock to your task each time you work on it - Whenever you want to check whether you did work enough or not, launch the agenda view for the current week (`v w' in case you say the current day by default) - Ask for the display of the clock report (`C-u R') - Filter on your educational task Thanks, that is brilliant! It is /almost/ what I was looking for. (One thing that is missing might be fancy coloring, say red for things I devoted too little time to etc. I guess this might be actually implemented using properties and some hooks - I'll try to look into it some day.) Now I only need to automate it (which should be easy with custom agenda views, I guess.) Thanks! Automate it: yes, go for custom agenda view. Re: colors, one way is to put an effort on the task, and you'll see your consumption regarding that cut-off value; whenever you're above it, your clocked time becomes red. 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. Best regards, Seb -- Sebastien Vauban
Re: [O] A mix of habits and effort estimates?
Hi Marcin, Marcin Borkowski wrote: Bastien b...@altern.org napisał(a): Marcin Borkowski mb...@wmi.amu.edu.pl writes: Is such a thing possible in Org-mode? Did you check (info (Org)Tracking your habits) ? As I mentioned (though only in the subject), yes. This is close, but my point is not I want to do this at least once each three days or something like this, but rather I want to spend at least 180 minutes every week on this - regardless of days. Of course, I could do it with the habits module (and if there's no other solution, I will do it like this), but what I'd like to have is actually a mixture of habits and effort estimates/clocking. No problem for that. - For the sake of facility, give a unique tag to your educational task - Clock to your task each time you work on it - Whenever you want to check whether you did work enough or not, launch the agenda view for the current week (`v w' in case you say the current day by default) - Ask for the display of the clock report (`C-u R') - Filter on your educational task Have fun! Best regards, Seb -- Sebastien Vauban
Re: [O] org-caldav will cease to work with Google Calendar
Hi Julien, Julien Cubizolles wrote: Thanks for this info but according to the documentation MobileOrg can synchronize your TODO items that have a DEADLINE or SCHEDULE. It seems not very practical in the case of an appointment where you don't necessarily have something TODO except be there. Also how would you you specify the start and end time of a meeting with a DEADLINE timestamp ? DEADLINE are not made therefore (repeated X days before the D day), nor SCHEDULED entries (repeated after, until DONE). Do you mean that MobileOrg doesn't support plain (active) timestamps? Best regards, Seb -- Sebastien Vauban
Re: [O] Syntax of Org Babel :results header argument
Hello, 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. Best regards, Seb Sebastien Vauban wrote: Before Org 8 is out, I'm willing to put light on some last syntax which I find counter-intuitive and not along the lines of the rest: it concerns the `results' parameter. Let's sum up first the list of all parameters: 1. Collection - :results value - :results output 2. Type of results (when :results is set to `value'): - Result types + :results vector + :results scalar + :results list + :results file - Result wrappers + :results raw + :results drawer + :results org (removed, right?) + :results html + :results code + :results latex + :results pp 3. Handling - :results replace - :results silent - :results none - :results append - :results prepend As you see (by the shown structure), the different values answer different questions: - How the results should be collected from the source code block? - How they will be inserted into the Org mode buffer? - How to interpret/wrap the results? - How the results should be handled? And answering many of these questions at the same time means giving a *multi-value* to the parameter, such as: :results list append Wouldn't it make more sense (and be more easily parsed by the machine and be cleaner and less error-prone for us, poor humans) if `results' would be split in different parameters for the different questions they answer, each of those parameters getting at most one value? Something along the lines of: :results_type file :results_insertion append (those names may be ugly, it just for the purpose of explaining my idea). I know that it's the ultimate moment to discuss such a change, would there be consensus, before Org 8 is out. -- Sebastien Vauban
[O] Background color reset for links and DONE headlines
Hello, As you can see on http://screencast.com/t/xdVGDQrbB, faces for DONE headlines or hyperlinks seem to reset the background color of the elements they're applied onto, even if they don't have any background color specified: --8---cut here---start-8--- `(org-link ((,class (:underline t :foreground #006DAF `(org-headline-done ((,class (:height 1.0 :weight bold :strike-through #BEBEBE :foreground #C5C5C5 --8---cut here---end---8--- I see that the font is set in defun `org-set-font-lock-defaults' (L6039--6045 of `org.el'), but it seems to me we can only give one face through that mechanism. Am I right? Is this a limitation we can work around? Best regards, Seb -- Sebastien Vauban
Re: [O] org-mode's HEAD org-remember bug?
Hello Marcelo, Marcelo de Moraes Serpa wrote: I just updated org to HEAD, and I'm getting the following error when trying to run the org-remember function (bound to C-c r): Debugger entered--Lisp error: (wrong-type-argument stringp nil) string-match(\\[\\[\\([^][]+\\)\\]\\(\\[\\([^][]+\\)\\]\\)?\\] nil) (cond ((equal desc NONE) (setq desc nil)) ((string-match org-bracket-link-regexp desc) (setq desc ...))) (let (link cpltxt desc description search txt custom-id agenda-link sfuns sfunsn) (cond (...) (... ...) (... ...) (... ...) (... ... ...) (... ... ...) (... ... ...) (... ... ...) (... ...) (... ... ...) (... ... ... ...) (... ...) (t ...)) (if (consp link) (setq cpltxt ... link ...)) (setq link (or link cpltxt) desc (or desc cpltxt)) (cond (... ...) (... ...)) (if (and ... link) (progn ... ... ...) (or agenda-link ...))) (let* ((org-called-with-limited-levels t) (org-outline-regexp ...) (outline-regexp org-outline-regexp) (org-outline-regexp-bol ...)) (let (link cpltxt desc description search txt custom-id agenda-link sfuns sfunsn) (cond ... ... ... ... ... ... ... ... ... ... ... ... ...) (if ... ...) (setq link ... desc ...) (cond ... ...) (if ... ... ...))) (org-with-limited-levels (let (link cpltxt desc description search txt custom-id agenda-link sfuns sfunsn) (cond ... ... ... ... ... ... ... ... ... ... ... ... ...) (if ... ...) (setq link ... desc ...) (cond ... ...) (if ... ... ...))) org-store-link(nil) org-remember-annotation() run-hook-with-args-until-success(org-remember-annotation) remember(nil) org-do-remember() org-remember(nil) call-interactively(org-remember nil nil) Any hints? On HEAD, it's org-capture... Your key binding is obsolete... Best regards, Seb -- Sebastien Vauban
[O] Alignment in `org-list-dt'
Hello, I'm surprised by the way the alignment occurs for DT lists in Org buffers. Here is an ECM: --8---cut here---start-8--- - Alt text :: Text description of a graphic that appears before the graphic is loaded into the browser. After an image has been downloaded on the browser, the alt text may briefly appear over the graphic as you rollover the mouse over the graphic. - Anchor a :: The anchor tag is used to define a hypertext link.The anchor tag is used to define a hypertext link. - Angle brackets :: less than () and greater than () symbols used to surround an element to create a tag. --8---cut here---end---8--- After Angle brackets, I added a newline and TAB'bed. What special is that the cursor is positioned 1 char too much to the left IMO. On an esthaetic POV, I don't find the above paragraphs (obtained thru `M-q', bound to the command `fill-paragraph') as nice to read as they could or should. Once you have a longer term, the definition must stay within a very narrow column... I prefer what the standard TAB'ing or M-q'ing does (_I don't understand_ why it's that different) on the following ECM: --8---cut here---start-8--- - =:results replace= :: (default option) Insert results after the source block, replacing any previously inserted results. - =:results silent= :: (default for Org results) Just send the commands, still echo the results in the minibuffer (to see code block output) and go. This option was originally added in the case where one *does not want to change the Org-mode buffer* (*no results are inserted* into the Org mode buffer -- even during export). - =:results none= :: silent even for the minibuffer. Such a code block is run for its side effects (by definition). --8---cut here---end---8--- Only that last list item is not indented as nicely as the others (2 chars to the right). Dunno why? For info, if the for (first word on the second line) is not directly under the silent (first word on the first line), that's not the case in my Org file, because I use to hide the markup characters. Best regards, Seb -- Sebastien Vauban
Re: [O] Alignment in `org-list-dt'
Hi Bastien, Bastien wrote: Sebastien Vauban writes: - Angle brackets :: less than () and greater than () symbols used to surround an element to create a tag. Try (setq org-description-max-indent 5) That was it. Thanks a lot! Best regards, Seb -- Sebastien Vauban
[O] Syntax of Org Babel results
Hello, Before Org 8 is out, I'm willing to put light on some last syntax which I find counter-intuitive and not along the lines of the rest: it concerns the `results' parameter. Let's sum up first the list of all parameters: 1. Collection - :results value - :results output 2. Type of results (when :results is set to `value'): - Result types + :results vector + :results scalar + :results list + :results file - Result wrappers + :results raw + :results drawer + :results org (removed, right?) + :results html + :results code + :results latex + :results pp 3. Handling - :results replace - :results silent - :results none - :results append - :results prepend As you see (by the shown structure), the different values answer different questions: - How the results should be collected from the source code block? - How they will be inserted into the Org mode buffer? - How to interpret/wrap the results? - How the results should be handled? And answering many of these questions at the same time means giving a *multi-value* to the parameter, such as: :results list append Wouldn't it make more sense (and be more easily parsed by the machine and be cleaner and less error-prone for us, poor humans) if `results' would be split in different parameters for the different questions they answer, each of those parameters getting at most one value? Something along the lines of: :results_type file :results_insertion append (those names may be ugly, it just for the purpose of explaining my idea). I know that it's the ultimate moment to discuss such a change, would there be consensus, before Org 8 is out. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Achim, Eric, Achim Gratz wrote: Eric Schulte writes: A hash marks a *result* with an indication of what was used to generate it (code block parameters). The point of a hash is to allow the result to be returned without having to re-execute. For this reason, I think that the hash should live with the result. Here Babel is assuming a very specific execution model, namely a functional one (a function with the same parameters always delivers the same results, so if you see the same function invoked with the same parameters you can just substitute the result from an earlier invocation). Babel isn't a functional language however, so it is both possible and done in practice to use it for side-effects or even side-effects only. But back to my earlier remark about the hash value actually being a signature of the source block and not the result. If I use noweb references, the reference text is cached, not its expansion. Well seen... I wouldn't have thought of that... A more general question: shouldn't cache be unusable (generate an error) when there is a session? In the presence of a session, I've the impression that caching results is always wrong. Who knows its contents before executing the code, in the next Emacs session? Best regards, Seb -- Sebastien Vauban
Re: [O] [new exporter] Captions for tables made by source blocks
Hello Achim, Achim Gratz wrote: Nicolas Goaziou writes: It's very easy to have a caption on the generated output: name the code. Hence, the following code block: #+NAME: calculation #+BEGIN_SRC emacs-lisp (+ 1 1) #+END_SRC will produce: #+RESULTS: calculation 2 If you add a caption to the results, like: #+CAPTION: Basic arithmetic #+RESULTS: calculation 2 you can update the source block without ever needing to remove the caption. Great. I could swear the last time I was trying this it would add a new result block on top of the old one, but I may have changed the name inbetween. The thing is: - you try with an unnamed block - you get an unnamed result block inserted - you name the block - you get a named result block inserted - you have to manually remove the unnamed result block It would still be nice (I think) if an unnamed source block would simply replace the next unnamed result block if there is one. I think this is a great proposition, which would make a lot of sense. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Improve presentation of entry text lines
Hi Bastien, Bastien wrote: Sebastien Vauban writes: FYI, there's a bug (not related to this change): if you filter out some events (for example, a work meeting today, with an active timestamp) by tag (show only home related things), you don't see the event headline, but well the 5 first entry text lines... This is a limitation: you cannot show entries in filtered agenda views. It you can come up with a patch that allows this, thanks in advance. A pitty. But more coherent than before... So, a good trade-off, before better. Best regards, Seb -- Sebastien Vauban
Re: [O] [bug] Inline tasks are exported, even with noexport tag
Bastien wrote: Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Then should it also support `org-export-with-tasks' variable? Yes. E.g. if `org-export-with-tasks' is set 'todo, only inline tasks with a TODO keyword should be exported. Done. Thanks! Thanks! Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] Merge of new export framework on Wednesday
Hi Bastien, Bastien wrote: Sean O'Halpin sean.ohal...@gmail.com writes: One small point: as we're going to have to change the meta directive #+STYLE to #+HTML_STYLE, can we change the name to reflect what it really does in the HTML backend, i.e. insert text verbatim into the head element? I suggest we rename it to #+HTML_HEAD. Done. You can now use HTML_HEAD instead of HTML_STYLE. Some variables were also renamed, check the details here: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2752ef Isn't it peculiar to rename STYLE into HEAD, in all affected vars but one? - html-STYLE-include-default - html-STYLE-include-default (unchanged) - html-STYLE-include-scripts - html-HEAD-include-scripts - org-html-STYLE-include-default - org-html-HEAD-include-default-STYLE - org-html-STYLE-include-scripts - org-html-HEAD-include-scripts Best regards, Seb -- Sebastien Vauban
[O] [PATCH] Improve presentation of entry text lines
Hello, The following patch improves the entry-mode presentation (`E' in the agenda) by adding a better leader on the side and one for a bottom corner. The style is a bit like boxquote. Best regards, Seb From 606a57768d853cba427abd982e133f6b9bc20c94 Mon Sep 17 00:00:00 2001 From: Sebastien Vauban wxhgmqzgw...@spammotel.com Date: Fri, 1 Mar 2013 17:12:58 +0100 Subject: [PATCH] Improve presentation of entry text lines 2013-03-01 Sebastien Vauban wxhgmqzgw...@spammotel.com * org-agenda.el (org-agenda-entry-text-show-here): Improve presentation of entry text lines (in entry-mode) by adding two customizable vars (for side, and for bottom corner). --- lisp/org-agenda.el | 14 +- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 3b6a005..242bb73 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -180,6 +180,16 @@ and `org-agenda-entry-text-maxlines'. :group 'org-agenda :type 'integer) +(defcustom org-agenda-entry-text-side-leaders | + Text preceding the side of entry text lines in the agenda view. + :group 'org-agenda + :type 'string) + +(defcustom org-agenda-entry-text-bottom-corner-leaders `-- + Text preceding the bottom corner of entry text lines in the agenda view. + :group 'org-agenda + :type 'string) + (defcustom org-agenda-add-entry-text-descriptive-links t Non-nil means export org-links as descriptive links in agenda added text. This variable applies to the text added to the agenda when @@ -3853,7 +3863,9 @@ This check for agenda markers in all agenda buffers currently active. (error No marker points to an entry here)) (setq txt (concat \n (org-no-properties (org-agenda-get-some-entry-text -m org-agenda-entry-text-maxlines +m org-agenda-entry-text-maxlines +org-agenda-entry-text-side-leaders)) + \n org-agenda-entry-text-bottom-corner-leaders)) (when (string-match \\S- txt) (setq o (make-overlay (point-at-bol) (point-at-eol))) (overlay-put o 'evaporate t) -- 1.7.9 -- Sebastien Vauban
Re: [O] [bug] changing TODO status with org-after-todo-state-change-hook defined fails
Hi Bastien, Bastien wrote: Eric S Fraga e.fr...@ucl.ac.uk writes: You need to use (org-schedule '(4)) here, this is part of a change in master that allows to use C-u C-u C-c C-s to add a delay (and same for C-u C-u C-c C-d which adds a warning delay.) I find the use of C-u C-u C-c C-d full of promise, but not yet there: I do C-c C-d and set a deadline on Fri 8 of March. I do C-u C-u C-d C-d and S-Left twice: in the agenda, I see the date moving to the 27 of Feb, 2 days before today; but the warning will be applied starting 2 days (the count is right) before the 8 of March. I think we should see the 8 of March as reference date for fixing the start date (or length, depending on how we see it) of the warning delay. It's even more weird if we S-Right from the current date: it seems that the difference in days is taken in absolute value, but I'm not even sure of that. Is it possible to put the reference date correctly when we call C-u C-u C-c C-d? Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Improve presentation of entry text lines
Bastien, Bastien wrote: Sebastien Vauban writes: The following patch improves the entry-mode presentation (`E' in the agenda) by adding a better leader on the side and one for a bottom corner. Mhh.. two options is way two much for this, let's have just one. Also, the output with your patch is wrong when the entry has no text. I pushed a slightly soberer change, thanks for the idea! OK. FYI, there's a bug (not related to this change): if you filter out some events (for example, a work meeting today, with an active timestamp) by tag (show only home related things), you don't see the event headline, but well the 5 first entry text lines... Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Hi Bastien, Bastien wrote: Hi Sébastien, Bastien b...@altern.org writes: Here's a patch to allow for a different prefix for deadline entries which are in the past: for example, 3 d ago instead of In -3 d... Please make sure the change is backward compatible so that users don't have to change the value of their `org-agenda-deadline-leaders' (i.e. simply fall back on (nth 1 ...) when (nth 2 ...) returns nil. I finally added this, with a slightly different patch: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=c8c991e Nice... Though, one question: why did you change the spacing (and, in fact, the width) of the leaders? --8---cut here---start-8--- -(defcustom org-agenda-scheduled-leaders '(Scheduled: Sched.%2dx: ) +(defcustom org-agenda-scheduled-leaders '( Scheduled: Sched.%3dx: ) Text preceding scheduled items in the agenda view. (...) -(defcustom org-agenda-deadline-leaders '(Deadline: In %3d d.: ) +(defcustom org-agenda-deadline-leaders '( Deadline: In %3d d.: %3d d. ago: ) --8---cut here---end---8--- Thanks for the suggestion, Thanks as well ;-) Best regards, Seb PS- Another question: some time ago, there was a ML with all the commits done on Org. This seems to have disappeared (at least from Gmane). A reason for that, or an alternative? -- Sebastien Vauban
Re: [O] 5f095f5 is the first bad commit (for my use case)
Hi Aaron, Aaron Ecay wrote: 2013ko otsailak 27an, Sebastien Vauban-ek idatzi zuen: Do you know if there was a way out -- other than killing Emacs -- in such a case where `C-g' is not working? If you are on Linux (or OS X, I suppose), you can sometimes break an infloop by sending emacs the SIGUSR2 signal (in the shell, “kill -USR2 `pidof emacs`”). This also generates a backtrace in the lisp debugger, which is useful for debugging. See C-h v debug-on-event . Thanks for the info! Best regards, Seb -- Sebastien Vauban
Re: [O] Org-Mode Reference Card bug
Hello Frank and Nick, Nick Dokos wrote: Frank Mueller fm.em...@web.de wrote: Just a remark to the Org-Mode Reference Card (http://orgmode.org/orgcard.pdf). There is a little bug in the spreadsheet description. wrong: sum from 2nd to 3rd hline |:=vsum(@II..@III)| correct: sum from 2nd to 3rd hline |:=vsum(@II..III)| The second at symbol must be deleted for correct working. Why do you think so? I second Nick: your proposition is wrong; it can't work like that. Now, maybe you're hit by a feature here: when setting `org-hide-emphasis-markers' to t, some `@' disappear from the formula (as you see them, while they're there: enable visible-mode and check it!). Is this what happens to you? That's a feature... Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Bastien, Bastien wrote: Sebastien Vauban writes: Though, one question: why did you change the spacing (and, in fact, the width) of the leaders? -(defcustom org-agenda-scheduled-leaders '(Scheduled: Sched.%2dx: ) +(defcustom org-agenda-scheduled-leaders '( Scheduled: Sched.%3dx: ) Text preceding scheduled items in the agenda view. (...) -(defcustom org-agenda-deadline-leaders '(Deadline: In %3d d.: ) +(defcustom org-agenda-deadline-leaders '( Deadline: In %3d d.: %3d d. ago: ) For the change in Scheduled: and Deadline: it's because I think it's cleaner to align them on the right, like the Sched. and In %3d.: strings. I don't mind, I customize them anyway ;-) For the change in the width (from 11 to 12), it's because I wanted to correctly display %3d d. ago: , not %2d d. ago: , so that now any string with a warning delay more than 100 will be correctly displayed. Before, we allowed 100+ days for the future deadlines, but not for past scheduled items (i.e. they were not aligned properly.) I feel the change is not too intrusive. I think the change of width can impact people who customize a bit the look of their agenda, and rely upong *all* the leaders to be of width 11. That was the motivation for my other patch, about clocking info (to make it go into a 11-char slot). Let's see how people react to that -- or if some are impacted. Best regards, Seb -- Sebastien Vauban
Re: [O] Org-Mode Reference Card bug
Bastien, Bastien wrote: Sebastien Vauban writes: Now, maybe you're hit by a feature here: when setting `org-hide-emphasis-markers' to t, some `@' disappear from the formula (as you see them, while they're there: enable visible-mode and check it!). Why would @ disappear with `org-hide-emphasis-markers' set to t? They should not visually disappear, but they do. Consider the following formula line: |---+---| | | | |---+---| #+TBLFM: @1$1=vsum(@-I..@-II) It becomes this: #+TBLFM: 1$1=vsum(-I..@-II) ^^ when `org-hide-emphasis-markers' is turned on. Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Commenting out src blocks for tangling
Bastien, Bastien wrote: Rainer M Krug r.m.k...@gmail.com writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Does it work as well for the `:noexport:' tag? Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Bastien, Bastien wrote: Sebastien Vauban writes: PS- Another question: some time ago, there was a ML with all the commits done on Org. This seems to have disappeared (at least from Gmane). A reason for that, or an alternative? I can't remember of such a mailing list. You can subscribe to the RSS feed from http://orgmode.org/cgit.cgi/org-mode.git/ And to the dedicated newsgroup on gwene.org: gwene.org.org-mode.git That must be it: `org-mode.git', which I accessed from Gmane. Thanks. It seems there are now 2 redundants such groups: - nntp+gmane:gwene.cz.or.repo.w.org-mode.git - nntp+gmane:gwene.org.org-mode.git Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Commenting out src blocks for tangling
Hi Rainer, Rainer M Krug wrote: On 28/02/13 10:30, Sebastien Vauban wrote: Bastien wrote: Rainer M Krug r.m.k...@gmail.com writes: I agree - COMMENTing a subtree should automatically disable tangling of code blocks in the subtree. Would this something which could be introduced easily, as it seems there are quite a few who assumed that it would be doing it? This is now the case in master: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=8e0b45 Does it work as well for the `:noexport:' tag? I don't think it should. Tangling is something different to export, so there should not be ay interactions between the two in this respect. On the other hand, COMMENT is generic - it is a COMMENT and does not concern anything. So it is applicable for tangling as well. I would actually say it would be counterintuitive if :noexport: would influence tangling as it is governed by a completely different approach in org as well as in what I am doing with the org file. I've always used :noexport: instead of COMMENT (as I hate the visual clutter of that wide keyword). So, for me, they were equivalent. You must be right, though, that they aren't: COMMENT seems more generic than just export. So, dismiss my request. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add a different prefix for past deadlines in the agenda view
Andreas, Andreas Leha wrote: Bastien b...@altern.org writes: You can subscribe to the RSS feed from http://orgmode.org/cgit.cgi/org-mode.git/ Sorry for hijacking this thread, and sorry for my ignorance. But where can I find this RSS feed? You can find the group on Gmane (available, then, by NNTP at least). Best regards, Seb -- Sebastien Vauban
Re: [O] Org-Mode Reference Card bug
Bastien,
Bastien wrote:
Sebastien Vauban writes:
They should not visually disappear, but they do.
No... chances are that it comes from your configuration. Please always
assume it does first, then provide a recipe if it's with emacs -Q. Thanks!
Yes, it does. I still had the following code, from when `@' was unofficially
supported in Beamer to render alert calls:
--8---cut here---start-8---
(defface my/org-alert-face
'((t (:weight bold :foreground black :foreground #FF)))
Face used to display alert'ed items.)
(add-to-list 'org-emphasis-alist
'(@ my/org-alert-face span class=\alert\ /span))
(add-to-list 'org-export-latex-emphasis-alist
'(@ \\alert{%s} nil))
--8---cut here---end---8---
Without that, the problem disappears.
Sorry for the noise.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] 5f095f5 is the first bad commit (for my use case)
Hello Nicolas,
Nicolas Goaziou wrote:
Sebastien Vauban writes:
Since updating to latest Org this morning, I couldn't open anymore my file
~/org/work.org.
Symptom? Org-mode gets loaded, but buffer remains blank, and Emacs is
(apparently) inflooping, with letting me stop it (with C-g).
Solution? Kill Emacs through the task manager, and bisect:
╭
│ 5f095f59099e77eda5cf7cae64119f9f246c4c70 is the first bad commit
│ commit 5f095f59099e77eda5cf7cae64119f9f246c4c70
│ Author: Nicolas Goaziou
n.goaziou-re5jqeeqqe8avxtiumw...@public.gmane.org
│ Date: Sun Feb 10 00:07:48 2013 +0100
│
│ Fontify latex, entities and sub/superscript again
╰
Now, having my Git tip on commit 3f95d81, everything's OK. I can work again,
but the most difficult problem is that I don't see how to debug further the
above problem.
Any idea why this fails?
Probably an infloop, as you suggest. It would be great if you could
provide an ECM (even not M) for that problem. You can send it through
private mail if you want.
Also, what's your value for `org-highlight-latex-and-related'?
You've directly put me on the right track: some (untested) code I added just
before leaving on vacation...
--8---cut here---start-8---
;; highlight LaTeX and related syntax
(setq org-highlight-latex-and-related
'('latex
'script
'entities))
--8---cut here---end---8---
This is obviously wrong (shame on me!), but has the interesting effect of
causing an infloop on opening Org files...
Thanks!
Best regards,
Seb
--
Sebastien Vauban
[O] Inserting a comma as prefix of headlines (in Org code blocks)
Hello, Consider this Org block: #+begin_src org * Headline inside an Org block Text of that entry. #+end_src I don't remember exactly why (I think, sometimes, TAB'ing did not work properly to prefix the dangerous lines with a `,'), I had to do it manually: go and prefix every headline of the Org code block. #+begin_src org ,* Headline inside an Org block Text of that entry. #+end_src That worked for long, but not anymore since a couple of weeks (could be something like 2 months or so): currently, if you go in column 0 of the headline, and insert `,', you get asked: Priority A-C, SPC to remove: IMHO, such a question should not be asked, and the `,' should be inserted literally, as we're in the context of a code block. Best regards, Seb -- Sebastien Vauban
Re: [O] logdone enhancement
Hi Bastien, Bastien wrote: Arun Persaud apers...@lbl.gov writes: * project ** TODO headline :repeat: a longer description of what the todo item is about SCHEDULED: 2013-06-18 Tue +1m The SCHEDULED line should be right after the headline, see the manual. It can sometimes work when it is on another line, but this is accidental, you should put the line right after the headline. Now that this syntax order is enforced, will we get commit 6b04bef back in Org 8? That'd be great... Best regards, Seb PS- See discussion on http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg01248.html and https://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00219.html -- Sebastien Vauban
Re: [O] logdone enhancement
Bastien, Bastien wrote: Hi Sébastien, Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Now that this syntax order is enforced, will we get commit 6b04bef back in Org 8? That'd be great... Why not. Can you heavily test commit 6b04bef and see if anything goes wrong? I can try, though it already had been heavily tested back in that time. But first, For me, the question comes down to: do we agree that John (in this case) won't be allowed anymore to write such an entry? --8---cut here---start-8--- *** NOTE Assets:Receivable:CEG #+begin_src sh :results value :exports results ledger reg --inject=Expected '^income:ceg' ledger reg --sort date -b 2007 receivable:CEG #+end_src :PROPERTIES: :ID: 8BEF6C42-8B23-495B-9421-3810B58907A1 :VISIBILITY: folded :CREATED: [2010-06-18 Fri 07:37] :END: --8---cut here---end---8--- Best regards, Seb -- Sebastien Vauban
Re: [O] 5f095f5 is the first bad commit (for my use case)
Nicolas,
Nicolas Goaziou wrote:
Sebastien Vauban writes:
You've directly put me on the right track: some (untested) code I added
just before leaving on vacation...
;; highlight LaTeX and related syntax
(setq org-highlight-latex-and-related
'('latex
'script
'entities))
This is obviously wrong (shame on me!), but has the interesting effect of
causing an infloop on opening Org files...
I fixed the infloop. Thank you.
Thanks!
Do you know if there was a way out -- other than killing Emacs -- in such a
case where `C-g' is not working?
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [patch] ox-koma-letter
Hi, Rasmus wrote: Maybe we should write a user guide *before* further implementation steps. I agree. A question zero is whether we eventually want to have an org-letter which could, in principle, output to something different than scrlttr2. That could be isodoc for which I have a bit of experience with. I'd enjoy to try and plug it in the current org-letter implementation. Best regards, Seb -- Sebastien Vauban
[O] [bug] Inline tasks are exported, even with noexport tag
Hello,
The following ECM fails on 2 fronts:
- the `noexport' tag on the inline task is not respected;
- the exported contents (because of the previous item) is not compilable in
LaTeX (maybe the default in `org-latex-inlinetask' is not generic enough for
handling such a content, or there are restrictions on the contents of inline
tasks which I did not respect?)
Best regards,
Seb
--8---cut here---start-8---
#+TITLE: ECM Noexport not respected, and failure to export
#+AUTHOR:Seb Vauban
#+Time-stamp: 2013-02-27 Wed 15:07
#+LANGUAGE: en
#+OPTIONS: H:3 num:t toc:t ^:{}
* Private headline :noexport:
You don't see this. Good!
* Public headline
Normal body text...
*** This error report should be private :noexport:
When pushing Submit, I got the error:
#+begin_example
[ServletException in:/WEB-INF/sharedfiles/pdef/split/action_n235.jsp] No
getter method available for property submitinfo.xor_n249_n250 for bean under
name ViewCaseForm'
#+end_example
Maybe due to UTF-8 in the file =C:\WebClient\src\SubmitInfo.java=.
See as well
[[file:WebClient/src/tools/pdef/makefile][file:WebClient/src/tools/pdef/makefile]].
*** END
Follow-up to normal body text...
--8---cut here---end---8---
--
Sebastien Vauban
Re: [O] [bug] Inline tasks are exported, even with noexport tag
Hello Nicolas, Nicolas Goaziou wrote: Sebastien Vauban writes: The following ECM fails on 2 fronts: - the `noexport' tag on the inline task is not respected; Should it? Well, it previously did. And that's pretty interesting: you can put private inline blocks, and have them exported or not, depending of the target of your document. Inlinetasks are not headlines, even though they use a somewhat similar syntax. :noexport: tag applies to trees. Inlinetasks do not define a tree. For me, inline tasks were (up to now) exactly like trees but with an end, and their contents was inline in the current entry, without disrupting the outline structure. We could use them to mirror note or warning blocks or paragraphs we find in all books, and that in a portable manner (regarding the multi-backends). As (I understood that) they were like headlines, we could anything like for real headlines: - adding tags - adding TODO keywords - adding drawers - adding clocking information - etc. Is this not right anymore? More generally, `org-export-with-tasks', `org-export-select-tags' and `org-export-exclude-tags' only apply on headlines. I understand there is a yes for all / no for all switch, but the ability to mark some of the inline blocks NOT for export is a functionality which, IMHO, we should avoid to drop. On the other hand, `org-export-with-inlinetasks' allows you to ignore inlinetasks completely during export. For conditional export, you may also want to look at drawers, which can be included/excluded by their name. If inline tasks can or should be replaced by drawers, what is their use, then? What remains as their fundamental reason of living? I'd like that to be clarified for my own understanding. - the exported contents (because of the previous item) is not compilable in LaTeX (maybe the default in `org-latex-inlinetask' is not generic enough for handling such a content, or there are restrictions on the contents of inline tasks which I did not respect?) From the Org POV, you can put anything in an inlinetask excepted another inlinetask and a headline. `latex' backend puts contents within \fbox and a \minipage environments. It's possible that verbatim is not allowed within one of them, I didn't check. It's quite difficult to come up with something visually different and yet general enough. You can also use `org-latex-format-inlinetask-function'. I'll give a look, thanks. Best regards, Seb -- Sebastien Vauban
