Re: [O] feature suggestion: apply datetime prompt magic to selected region
Hi Brian, suvayu ali fatkasuvayu+li...@gmail.com writes: Ah I see it now, you want the org-timestamp command to work on a region. Maybe you can write your own function with lisp if you are doing this too often. Should be quite simple to try. Please check `org-loop-over-headlines-in-active-region' from latest git repo and see if using `org-schedule' in the region does what you want. We can actually implement this for `org-timestamp' as well, if relevant. Thanks, -- Bastien
Re: [O] BUG: footnote conflicts with code export to pdf
Nick Dokos nicholas.do...@hp.com writes:
zwz zhangwe...@gmail.com wrote:
Steps to reproduce it:
This org file can be exported to pdf correctly.
#+begin_src org
* test
#+BEGIN_SRC c
void main(){
int a;
}
#+END_SRC
#+end
Then you modify it:
#+begin_src org
* test
#+BEGIN_SRC c
void main(){
int a[5];
}
#+END_SRC
#+end
It says org-export-latex-preprocess: Wrong type argument: stringp,
nil
when you try to export the file.
You didn't say what version of org you are using. I cannot reproduce it
in Org-mode version 7.7 (release_7.7.416.g93bd.dirty)
Nick
I am using org-mode 7.7-1 (installed by pacman on Archlinux).
[O] Monthly Agenda View Start Date
I have just started using the month view in Agenda. However, it displays the whole of the current month, starting from the first. What I really want is to display a month's view from today. I relize that I can do this with a custom Agenda command, but is there aready some variable I can set that allows me to do this? My searches of the list archive haven't turned up anything useful so far. Ian.
Re: [O] Monthly Agenda View Start Date
Hi Ian, actually, there was a thread about this yesterday: thread.gmane.org/gmane.emacs.orgmode/48290/focus=48290 On Oct 24, 2011, at 8:34 AM, Ian Barton wrote: I have just started using the month view in Agenda. However, it displays the whole of the current month, starting from the first. What I really want is to display a month's view from today. I relize that I can do this with a custom Agenda command, but is there aready some variable I can set that allows me to do this? My searches of the list archive haven't turned up anything useful so far. Ian. Regards - Carsten
Re: [O] [RFC] Standardized code block keywords
Hi Daniel, Daniel Bausch wrote: named code blocks [1] -- source srcname function calling external functions [2] -- call lob named data [3] -- tblname resname results data what about #+name: for [1] and [3], and #+call: for [2] ? That a table or list contains data is obvious. The only thing, the additional line is for, is to name it. As Eric showed us, this is not always to name it... If the table is the results of an unamed block, you will have #+name: followed by no name! #+name: | line 1 | data1 | | line 2 | data2 | what I also find quite disturbing. Best regards, Seb -- Sebastien Vauban
Re: [O] Can't use char in TODO state
Hi Nicolas, Nicolas Goaziou wrote: Bastien b...@altern.org writes: Michael Brand michael.ch.br...@gmail.com writes: It works with this patch http://patchwork.newartisans.com/patch/964 from Nicolas which I am still using to test it. If so, then Nicolas please apply it. It really simplifies the way headlines are matched in many places in the code. I've applied it. This works as expected from my point of view. Thanks a lot... Best regards, Seb -- Sebastien Vauban
Re: [O] notify, when something to do
Bastien, Bastien wrote: - How to distinguish between SCHEDULED and DEADLINE? I'll investigate... I introduced the ability to use (org-agenda-to-appt nil t :scheduled) if you just want to get scheduled appointments. This might speeds things and make them more flexible. I have the impression we use SCHEDULED here with a wrong semantics. What about the idea (launched by Carsten) of introducing another keyword like APPT or EVENT [1] for such events to be warned of? Best regards, Seb Footnotes: [1] http://www.mail-archive.com/emacs-orgmode@gnu.org/msg45063.html -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Sat, Oct 22, 2011 at 9:58 AM, Christian Moe m...@christianmoe.comwrote: On 10/21/11 8:40 PM, Rainer M Krug wrote: Just to add to it: at the moment I have e.g: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-**revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.**tar.gz which would look horrible in one line and a nightmare to edit. Any suggestions how this cold be changed? Wow. I guess I was wrong to imagine your problem was solved. If your code blocks share the same language, and it supports sessions, I'd bite the bullet and transform them into #+HEADERS lines for the first src block, then reuse them through a session. Does that make sense? If your variables are going to be used by different src blocks in different languages, I don't have any elegant solution. Yep - different languages: R and sh Yours, Christian -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] Recurring events with exceptions
Skip Collins skip.coll...@gmail.com writes: [...] Lemerre's approach only syncs with the Outlook client, not the Exchange server. He suggests using RFC-2446 (iCalendar) as a basis for a more general solution. I think that trying to establish a smoothly syncing connection between org and exchange by using iCalendar is a recipe for frustration. This is mostly because Exchange's implementation of the standard is lacking. It might be more fruitful to pursue an org interface to Exchange Web Services, which is favored and privileged by microsoft. A hypothetical org-ews.el would pass xml messages that look something like: ?xml version=1.0 encoding=utf-8? soap:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; [...] /soap:Envelope For individual one way transfers, this would relatively straightforward, assuming that the relevant xml schema are well defined. As a proof of concept, I use separate one way transfers to sync my org files with google's calendar. Messy and ad hoc but it works; search the mailing list for a description of how I did this -- I'm offline at the moment so cannot search myself. Alternatively, look at [Worg]/org-tutorials/org-google-sync.html for a tutorial written by Arun Persaud that might give you an idea of how this can be done. HTH, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.7 (release_7.7.452.g767f5)
Re: [O] [RFC] Standardized code block keywords
Daniel Bausch danielbau...@gmx.de writes: Hi, named code blocks [1] -- source srcname function calling external functions [2] -- call lob named data [3] -- tblname resname results data what about #+name: for [1] and [3], and #+call: for [2] ? That a table or list contains data is obvious. The only thing, the additional line is for, is to name it. That a source block contains source is also obvious and is already noted by the use of #+begin_src, so why duplicate the src-part? Daniel I don't know if I've left it too late to vote on this but... I would go for name for [1] and [3] and call for [2]. I can, however, see the need for distinguishing between data tables and results so could be convinced that data and results should be used for [3]. In any case, I do know that I dislike srcname and tblname... -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.7 (release_7.7.452.g767f5)
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Sat, Oct 22, 2011 at 5:52 PM, Eric Schulte schulte.e...@gmail.comwrote: Just to add to it: at the moment I have e.g: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.tar.gz which would look horrible in one line and a nightmare to edit. Any suggestions how this cold be changed? Hmm, I don't see any easy solution for the above. I'm sorry to have removed this functionality. I can think of three options for how to handle this situation. 1. If it turns out to be possible/desirable my preferred solution here would be to add general property support for appending values to properties when properties are over specified rather than simply replacing the value. Perhaps this could be done with a variable like org-accumulating-properties which could hold a list of those properties which should accumulate values rather than overwriting them. Should work, but will add an additional level of complexity which I think is avoidable. 2. Adding a #+PROPERTY: line authoring helper similar to the table formula helper making it more natural to edit such long property lines. I think this might be to complicated 3. It may be possible to add syntax for extending #+PROPERTY: specifications across multiple lines, something like #+PROPERTY: var MAINVERSION=0, #+PROPERTY+: SVNVERSION=(vc-working-revision (buffer-file-name)), #+PROPERTY+: SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))), #+PROPERTY+: SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13), #+PROPERTY+: DISP_PACKAGE=seedDisp_0.4-13.tar.gz FWIW I would like to have a similar extender for #+TBLFM: lines. Actually this choice may be my preferred solution. I like that suggestion - This would add an option, if inheritance for subtrees is incorporated for #+PROPERTY to unset all variables - something I was looking for some time ago. So I really like that solution: logical, clear, does not break anything, and easy to read - I would say go for it. What do you think? In addition: I would like to have a warning if #+BABEL is present in the org file, so that one remembers that it has to be changed. #+begin_src emacs-lisp (add-hook 'org-mode-hook (lambda () (save-excursion (goto-char (point-min)) (when (re-search-forward (org-make-options-regexp '(BABEL))) (message This file contains a \#+BABEL:\ line.) #+end_src Could this be included in the next few versions of org, as I can imnagine that especially infrequent org-babel users will be confused. Also: in a year, when I open an old org-file and it des not work, this would warn me about the necessary modifications. Cheers, Rainer Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/ -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] Source blocks for tiny snippets
Hi Eric,
On Sat, Oct 22, 2011 at 18:08, Eric Schulte schulte.e...@gmail.com wrote:
suvayu ali fatkasuvayu+li...@gmail.com writes:
Hi everyone,
I was wondering what people do when they need to put a few (1 or 2)
lines of code snippets in org files? I like the syntax highlighting one
gets in an org buffer and in HTML export with code blocks. Is there some
work around other than have code blocks for every line I want to
include?
As an example consider this paragraph:
Edit job options for number of events and other configurations
: $ $EDITOR $GAUSSOPTS/options_files.py
The number of events in a job can be customised with the option
: LHCbApp().EvtMax = nEvts
To run the generator only, set the property below.
: Gauss().Phases = [Generator]
To turn on full monitoring and dump an ntuple to a root file, include
the opts files as below. It can be customised further to suit the needs.
: importOptions('$GAUSSOPTS/some.opts')
In the above example you have a mix of bash and python snippets.
Currently there is no more concise way to specify code blocks other than
the normal code block format. Although it doesn't currently exist maybe
an option could be added to hide the #+BEGIN/END_SRC lines so that they
don't appear in the buffer. That combined with a helper for specifying
code blocks (I use yasnippets for this) should serve.
Thanks for the confirmation. I can live with example lines for now. :)
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Source blocks for tiny snippets
Hi Eric, Eric Schulte schulte.e...@gmail.com writes: That combined with a helper for specifying code blocks (I use yasnippets for this) should serve. I would like to suggest adding the keybindings and shortcuts for specifying code blocks to chapter 14.11 Key bindings and useful functions in the manual. I'm still looking for a comfortabel way to specify a code-block without typing much. A summary of keybindings, shortcuts and completion methods available for this task in chapter 14 would be helpfull, even if there is some duplication of information given in other chapters. There is, e.g., the shortcut ,--- | s TAB `--- to insert a code-block, but its somehow underdocumented - I don't remember, where I read about it, and don't find it in the manual anymore. cheers -- Thorsten
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On Sat, Oct 22, 2011 at 9:07 PM, Christian Moe m...@christianmoe.comwrote: Hi, Eric Schulte wrote: I can think of three options for how to handle this situation. 1. If it turns out to be possible/desirable my preferred solution here would be to add general property support for appending values to properties when properties are over specified (...) 2. Adding a #+PROPERTY: line authoring helper similar to the table formula helper making it more natural to edit such long property lines. 3. It may be possible to add syntax for extending #+PROPERTY: specifications across multiple lines, something like #+PROPERTY: var MAINVERSION=0, #+PROPERTY+: SVNVERSION=(vc-working-**revision (buffer-file-name)), (...) These are all interesting ideas, as was Darlan's alternative suggestion to Eric's suggestion (1), namely to use a special inherit argument. I'd like to toss out a different idea, which I think is brilliant, but which may go down in flames once we've had a time to think it through. (And sorry if it's been proposed before; I came to Org just as Org-Babel was being stabilized.) In short, let Babel assign to any declared variables of a src block the values of any properties at point with the same name. In other words: - The :var header argument / :var: property could declare variables without assigning values, that is, you could have `:var foo=1, bar, baz=3' to tell Babel that `bar' is a variable too. - When a variable is declared, but no value assigned, Babel would look for a property (e.g. `:bar: 2') at point with the same name as the variable. - If property inheritance is turned on, this means a variable can be specified at any level of the outline. - If no further changes were made (such as the property accumulation Eric suggested), it would still be possible to /declare/ variables only at /one/ level of the outline besides in the code block and calls, since declarations all belong to the same `:var:' property. However, this approach would mean that declarations could be kept short and there would be a great deal of modularity in what values would be assigned. This all sounds very interesting, but I have problems understanding the advantages - possibly because I only had one coffee this morning. In addition see further down: SNIP On 10/22/11 5:52 PM, Eric Schulte wrote: #+BABEL: :var MAINVERSION=0 #+BABEL: :var SVNVERSION=(vc-working-**revision (buffer-file-name)) #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+BABEL: :var DISP_PACKAGE=seedDisp_0.4-13.**tar.gz Have a buffer-level property for all the long lines (sorry if my email client wraps these lines): #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name)) #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+PROPERTY: DISP_PACKAGE seedDisp_0.4-13.tar.gz I think this syntax opens the door for dangerous typos - If you type e.g: #+PROPERTY: vat x=10 what would this be? it should have been #+PROPERTY: var x=10 but now? One could allow this syntax in the case that the variable has been defined before, by using the var syntax: so #+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM, DISP_PACKAGE #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name)) #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+PROPERTY: DISP_PACKAGE seedDisp_0.4-13.tar.gz should be OK, as SVNVERSION is already defined, but #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name)) #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+PROPERTY: DISP_PACKAGE seedDisp_0.4-13.tar.gz #+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM, DISP_PACKAGE not, as the variables are only defined later. But this would not make #+PROPERTY+: redundant, but rather enhance it. Cheers, Rainer Cheers, Rainer SNIP Yours, Christian -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] Links to C/C++ source code lines
Bastien bzg at altern.org writes: Looks nice, thanks. Just wondering: are you aware of the A.3 Adding hyperlink types section in the manual? You core uses advice instead of the `org-add-link-type' function -- is that on purpose? No, I missed that paragraph. That would be a cleaner solution- I'll take a look at it. Thank for the hint! regards, Rafal
Re: [O] No updates on git server?
On Fri, Oct 21, 2011 at 5:39 PM, Bastien b...@altern.org wrote: Rainer M Krug r.m.k...@gmail.com writes: [...] or has org reached a stable state? Is it April fools' day already? :) I had the same idea, when no updates arrived for three days -- Bastien -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax (F): +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
This all sounds very interesting, but I have problems understanding the advantages - possibly because I only had one coffee this morning. It may not be feasible and the disadvantages may outnumber the advantages; we'll see. But having several coffees under my belt already, I'll argue my corner. :-) To recapitulate, I'm proposing that the values of (declared) variables for code blocks could be assigned from properties with the same names, so that: :PROPERTIES: :var: x=1, y=2, z=-3 :END: could also, and interchangeably, be written: :PROPERTIES: :x: 1 :y: 2 :z: -3 :var: x, y, z :END: Here setting the `var' property with variable names, but without assignments, would declare that the variables are to be passed to the src block, and prompt Babel to look for the values in properties with the same names. I think some of the advantages should be clear. First: -- It would easily let code blocks collect data from Org entry properties, without having to use lisp expressions or first collecting the properties in a dynamic block and then referencing the d.b. This would be nice particularly when your data is already in outline/property form. A second advantage: --- It would allow a great deal of flexibility in passing variables according to position in the outline hierarchy. #+BEGIN_EXAMPLE * Some default settings :PROPERTIES: :x: 1 :y: 2 :z: -3 :var: x, y, z :END: ** For all cases where y=5 :PROPERTIES: :y: 5 :END: *** A case where x=1, y=5, z=-3 #+begin_src R (...) #+end_src *** A case where x=1, y=5, z=8: no need to specify y again #+begin_src R :var z=8 (...) #+end_src (z could alternatively have been specified as a property, same as y above) #+END_EXAMPLE This modular re-use of values from higher up in the outline, on any number of levels, should more than compensate for the loss of buffer-wide assignments with the #+BABEL header. With a single :var: property for passing arguments, on the other hand, this is not possible. You have to re-assign values to all three variables on each level. (Note: Eric's idea for accumulative properties, on the other hand, /would/ allow you to do this with a single :var: property.) #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name)) #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-current-export-file))) #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13) #+PROPERTY: DISP_PACKAGE seedDisp_0.4-13.tar.gz I think this syntax opens the door for dangerous typos - If you type e.g: #+PROPERTY: vat x=10 what would this be? it should have been #+PROPERTY: var x=10 but now? Now there would be a :vat: property with the value x=10. It will not be passed to any code block because (as I imagine the scheme) any variables to be passed to a code block still need to be /declared/ with a :var: property or :var header argument, so it will not conflict with any `vat' variable you might have defined in the code. Instead, you will notice the typo when your code block results in an error message that x is missing, same as now. The result of misspelling var under my scheme would be the same as misspelling it now. One could allow this syntax in the case that the variable has been defined before, by using the var syntax: To simplify your example, you think this is permissible: #+PROPERTY: var x, y, z #+PROPERTY: x 1 #+PROPERTY: y (1+ 1) #+PROPERTY: z (- 0 3) but this is not: #+PROPERTY: x 1 #+PROPERTY: y (1+ 1) #+PROPERTY: z (- 0 3) #+PROPERTY: var x, y, z As I imagine the scheme, it wouldn't matter and the two are interchangeable. The `#+PROPERTY: y (1+ 1)' assignment, in and of itself, would only create a property :y: with the string value (1+ 1). When Babel began to execute a code block, it would first look up the value of the property :var: at point to see what variables to pass, and the order of the PROPERTY headers is not important. It would then look for the values of the properties :x:, :y: and :z: at point, and only then, knowing that these are variables for a code block, would it evaluate any lisp expressions in these values. A third advantage: -- It would provide one way to solve your problem -- very long assignment expressions that are difficult to group on a line. It is not necessarily the best way to solve that specific problem, compared with the various options Eric came up with, such as #+PROPERTY+:. But this would not make #+PROPERTY+: redundant, but rather enhance it. Possibly; my solution only applies to the :var passed to a code block; there may be other property assignments that it would be good to be able to split over several lines. Also, I can certainly see the attraction of the analogous #+TBLFM+: -- though I'm fine with the existing `C-c '' solution for that, and
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hi all, Christian Moe wrote: This all sounds very interesting, but I have problems understanding the advantages - possibly because I only had one coffee this morning. I think some of the advantages should be clear. A second advantage: --- It would allow a great deal of flexibility in passing variables according to position in the outline hierarchy. #+BEGIN_EXAMPLE * Some default settings :PROPERTIES: :x: 1 :y: 2 :z: -3 :var: x, y, z :END: ** For all cases where y=5 :PROPERTIES: :y: 5 :END: *** A case where x=1, y=5, z=-3 #+begin_src R (...) #+end_src *** A case where x=1, y=5, z=8: no need to specify y again #+begin_src R :var z=8 (...) #+end_src (z could alternatively have been specified as a property, same as y above) #+END_EXAMPLE This modular re-use of values from higher up in the outline, on any number of levels, should more than compensate for the loss of buffer-wide assignments with the #+BABEL header. With a single :var: property for passing arguments, on the other hand, this is not possible. You have to re-assign values to all three variables on each level. (Note: Eric's idea for accumulative properties, on the other hand, /would/ allow you to do this with a single :var: property.) I think discussing all of this is beneficial and can lead to very interesting solutions. But I just have a comment on your second advantage, something that can render your example inefficient: inheritance is not on by default, and you need to enable if for *specific properties*. Make it on by default would be a very bad idea -- just think at examples of the mails sent through Org-mime: what about setting a Cc or To somewhere and inheriting that in all the file/subtree/etc. May be scary or inefficient performance-wise? Anyway, setting inheritance of properties to on, means you should declare the behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you say that var: x, y, z does that too (then you've two things in one shot -- why not?). Best regards, Seb -- Sebastien Vauban
Re: [O] FYI: Org mode testing framework, Emacs 23 and 22
Hi Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Bastien wrote: Jason, depending on our server resources, would that be feasible to run regular (cron'ed) tests? What is the best frequency? Wouldn't the best frequency be: at every commit? That's not for the minute (maybe even less) it takes to run the 102 tests, I guess... At 8 seconds (on my machine) it shouldn't put too much load on the server to run after every commit, we would just want to be sure that multiple instances of the test suite are not run at once. A check to only run the suite if it is not currently running shouldn't be difficult to run. For my information, why do you need to test that 2 suites don't run at the same time? They only write to temp buffers, no? Can they conflict? Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
On 10/24/11 2:11 PM, Sebastien Vauban wrote: (...) But I just have a comment on your second advantage, something that can render your example inefficient: inheritance is not on by default, and you need to enable if for *specific properties*. You can set `org-use-property-inheritance' to t, to make all properties inheritable, or you can set it to a list to enable specific properties. I suppose you meant that the former would be a bad idea. (And it could be, depending on your working habits, file size, outline nesting depth and the speed of your machine.) But you're right, property inheritance is not on by default and I forgot to mention that this time around. (I think I did mention it in the previous long message where I presented the idea.) Make it on by default would be a very bad idea -- just think at examples of the mails sent through Org-mime: what about setting a Cc or To somewhere and inheriting that in all the file/subtree/etc. May be scary or inefficient performance-wise? Anyway, setting inheritance of properties to on, means you should declare the behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you say that var: x, y, z does that too (then you've two things in one shot -- why not?). Yes, if my suggestion becomes reality, this could be a useful refinement. Yours, Christian
Re: [O] Source blocks for tiny snippets
Thorsten quintf...@googlemail.com wrote: ... There is, e.g., the shortcut ,--- | s TAB `--- to insert a code-block, but its somehow underdocumented - I don't remember, where I read about it, and don't find it in the manual anymore. It is documented in sec. 15.2, Easy Templates, of the org manual (along with how to add your own): (info (org) Easy Templates) Nick
Re: [O] [RFC] Standardized code block keywords
Does org have TAB completion in call lines for names of blocks that can be called? Using srcname for blocks of code could make things easier but if this is not the case then I name is just fine. -- Darlan At Mon, 24 Oct 2011 08:37:13 +0100, Eric S Fraga e.fr...@ucl.ac.uk wrote: Daniel Bausch danielbau...@gmx.de writes: Hi, named code blocks [1] -- source srcname function calling external functions [2] -- call lob named data [3] -- tblname resname results data what about #+name: for [1] and [3], and #+call: for [2] ? That a table or list contains data is obvious. The only thing, the additional line is for, is to name it. That a source block contains source is also obvious and is already noted by the use of #+begin_src, so why duplicate the src-part? Daniel I don't know if I've left it too late to vote on this but... I would go for name for [1] and [3] and call for [2]. I can, however, see the need for distinguishing between data tables and results so could be convinced that data and results should be used for [3]. In any case, I do know that I dislike srcname and tblname... -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.7 (release_7.7.452.g767f5)
Re: [O] OPatches for org-generic-export
On Fri, 21 Oct 2011 19:23:04 +0200, Bastien b...@altern.org said: Glad to see someone tinkering with it! yay! B Could you test Robert's patches against latest Org and report B any problem? As the author of the generic exporter, you might B spot problems more easily... I think they looked fine without intense study, and I trust him to fix bugs that come his way :-) Anyway, I really like the idea of an exporter test regression suite. Now we just need to make that happen! -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/
Re: [O] org-contacts or bbdb?
On Sun, 23 Oct 2011 11:36:21 +0200, pmli...@free.fr (Peter Münster) said: go mess with the database easily. EG, with BBDB if one area gets a new area code you can't go quickly search/replace for all records replacing 111 with 222. With org-contacts it's a simple search/replace edit. PM But you can open the bbdb-file and do the replacement there, can't PM you? As a database, elisp dumps don't seem safe to edit. Yes you can, but the likely hood of running into other conflicts are problematic (IE, matching just the number 111 in just the area-code field when there is no easy near-by matching string to anchor a regexp against). -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/
Re: [O] notify, when something to do
Hey Peter, I also do appointments with orgmode.. I have it hooked up so that it sends me messages via XMPP/Jabber. Possibly useful to you: http://dustycloud.org/blog/2010/11/21/emacs-appointment-notifications-via-xmpp pmli...@free.fr (Peter Münster) writes: Hello, I would like to be notified[1], when a todo item enters the warning period, scheduled time, or deadline. I can imagine writing a function, that executes every 5 minutes, that scans all agenda files calling `org-get-[scheduled,deadline]-time', but I hope, that there is already something, that I can use more easily. TIA for any help, Peter Footnotes: [1] For notifying, I'll use an external program, for example notify-send, because the emacs window is not always visible.
Re: [O] OPatches for org-generic-export
On 10/24/11 Oct 24 -9:44 AM, Wes Hardaker wrote: On Fri, 21 Oct 2011 19:23:04 +0200, Bastien b...@altern.org said: Glad to see someone tinkering with it! yay! B Could you test Robert's patches against latest Org and report B any problem? As the author of the generic exporter, you might B spot problems more easily... I think they looked fine without intense study, and I trust him to fix bugs that come his way :-) Anyway, I really like the idea of an exporter test regression suite. Now we just need to make that happen! The only challenge I see is the matcher. That is, I can create a test document, based on Jambunathan's, but I don't know the best way to write the tests. I suppose some form of regular expression is The Right Thing. There must be a better solution, though --- I figure someone must have a good way to match text files against expectations. I just don't know what that way is. cheers, r
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Hello, Christian Moe m...@christianmoe.com writes: But you're right, property inheritance is not on by default and I forgot to mention that this time around. (I think I did mention it in the previous long message where I presented the idea.) AFAIK, Babel has always searched its properties with inheritance on, independently on user configuration. Thus, it doesn't matter much in that case. Regard, -- Nicolas Goaziou
Re: [O] Source blocks for tiny snippets
Nick Dokos nicholas.do...@hp.com writes: It is documented in sec. 15.2, Easy Templates, of the org manual (along with how to add your own): (info (org) Easy Templates) Thanks, I think I should take the dynamics of org-mode more into account - my not so old hard-copy of the manual is already out of date, apparently, it lacks that section. cheers -- Thorsten
Re: [O] Monthly Agenda View Start Date
On 24/10/11 07:51, Carsten Dominik wrote: Hi Ian, actually, there was a thread about this yesterday: thread.gmane.org/gmane.emacs.orgmode/48290/focus=48290 On Oct 24, 2011, at 8:34 AM, Ian Barton wrote: I have just started using the month view in Agenda. However, it displays the whole of the current month, starting from the first. What I really want is to display a month's view from today. I relize that I can do this with a custom Agenda command, but is there aready some variable I can set that allows me to do this? Thanks Carsten, that's exactly waht I needed. Ian.
Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
I didn't check the list for 3 days and this thread became a little hard to follow. So, forgive me if I'm answering the wrong E-Mail. I liked Christian's idea of using a single var property to tell babel which regular properties it should use as variables (ignoring any variable not defined). This would be enough for my use cases. On the other hand, some way to append values to a property, such as using some special keyword as I have suggested, could be a better solution in order to keep consistence if people want this feature for non-babel related properties. -- Darlan At Sat, 22 Oct 2011 09:53:25 -0600, Eric Schulte wrote: Darlan Cavalcante Moreira darc...@gmail.com writes: It's excellent that now babel understands multiple values in the var property (I was one of the people that wanted this), but There Is One More Thing. Would it be feasible to inherit variables from parent sub-trees? Effectively, I'd like to append new values in lower level sub-trees, but AFAIK setting the var property in a sub-tree will still replace the value set in the parent sub-tree. Currently every new property specification entirely replaced previous specifications with the same name. That is, in the example below the level-2 sub-trees would not have the foo variable passed to babel. * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code only with bar :PROPERTIES: :var: bar=2 :END: src_block ** Code only with baz :PROPERTIES: :var: baz=3 :END: src_block Maybe a special keyword, such as inherit (or append) could be used to incorporate variables defined in the parent sub-tree, such that the example would become * Code with foo :PROPERTIES: :var: foo=1 :END: ** Code with foo and bar :PROPERTIES: :var: bar=2, inherit :END: src_block ** Code with foo and baz :PROPERTIES: :var: baz=3, inherit :END: src_block This should not affect global variables and inherit would inherit variables defined only in the parent sub-tree (unless it also contains the inherit keyword). As a use case scenario, suppose I need to perform simulations for a few different scenarios, each with small variations. This would allow me to define common variables for a scenario in a higher level sub-tree and more specific variables in the lower level sub-trees. This sounds somewhat similar to my suggestion in reply to Rainer's email. Best -- Eric -- Darlan Cavalcante At Fri, 21 Oct 2011 22:24:25 +0200, Christian Moe m...@christianmoe.com wrote: Hi, Yes, that works nicely, and should solve Rainer's problem. I haven't been able to think of anything else that can't be handled by properties. And I do think it's a good idea to winnow down the syntax a bit, even if things break. I just like to grumble. :-) Yours, Christian On 10/21/11 7:37 PM, Eric Schulte wrote: Nice idea. This same issue with var arose when we first started allowing header arguments to be specified inside subtree properties. I've just implemented your suggestion so the following are now possible. #+PROPERTY: var foo=1, bar=2 #+PROPERTY: cache yes #+begin_src emacs-lisp (+ foo bar) #+end_src #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: : 3 and #+begin_src emacs-lisp :var foo=this, bar=that (concat foo bar) #+end_src #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: : this that Thanks for the suggestion and I hope the above is a sufficient replacement for the now-missing #+BABEL: syntax. Cheers -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] BUG: footnote conflicts with code export to pdf
zwz zhangwe...@gmail.com wrote:
Then you modify it:
#+begin_src org
* test
#+BEGIN_SRC c
void main(){
int a[5];
}
#+END_SRC
#+end
It says org-export-latex-preprocess: Wrong type argument: stringp,
nil
when you try to export the file.
You didn't say what version of org you are using. I cannot reproduce it
in Org-mode version 7.7 (release_7.7.416.g93bd.dirty)
Nick
I am using org-mode 7.7-1 (installed by pacman on Archlinux).
Just for future reference: this version does not exist in git, so it
doesn't tell me much. What does M-x org-version say? That's the
important thing (of course, the Archlinux people might have modified it
but it's still the best bet when reporting versions).
Be that as it may, I checked that release_7.7 had the problem, so I tried
a bisection and found that the fix is in the following commit:
,
| commit c3631aae7e68565978433cad8c4a2b286e91dfac
| Author: Nicolas Goaziou n.goaz...@gmail.com
| Date: Sat Jul 30 12:38:06 2011 +0200
|
| org-footnote: prevent LaTeX export from catching footnotes in protect
environment
|
| * lisp/org-footnote.el (org-footnote-in-valid-context-p): check
| `org-protected' property before allowing to match a footnote.
| (org-footnote-at-reference-p): remove an obsolete test. It's now done
| in the previous function.
`
Nick
[O] [PATCH] Agenda: Allow filter list without category in org-agenda-to-appt
Hello, Here the output of git format-patch master. I hope it's correct, it was my first git-commit... --8---cut here---start-8--- From 82da273bb0884347762e883786b334302ad3f0cd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Peter=20M=C3=BCnster?= p...@free.fr Date: Mon, 24 Oct 2011 20:52:45 +0200 Subject: [PATCH] Agenda: Allow filter list without category in org-agenda-to-appt * lisp/org-agenda.el (org-agenda-to-appt): Make sure filter-items are strings before calling `string-match'. Now it's possible to use (org-agenda-to-appt t '((headline string))). TINYCHANGE --- lisp/org-agenda.el | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 24ead18..0b4c07b 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -8489,10 +8489,12 @@ details and examples. (and (stringp filter) (string-match filter evt)) (and (functionp filter) (funcall filter x)) (and (listp filter) - (or (string-match - (cadr (assoc 'category filter)) cat) - (string-match - (cadr (assoc 'headline filter)) evt)) + (let ((cat-filter (cadr (assoc 'category filter))) +(evt-filter (cadr (assoc 'headline filter +(or (and (stringp cat-filter) + (string-match cat-filter cat)) +(and (stringp evt-filter) + (string-match evt-filter evt ;; FIXME: Shall we remove text-properties for the appt text? ;; (setq evt (set-text-properties 0 (length evt) nil evt)) (when (and ok tod) -- 1.7.3.4 --8---cut here---end---8--- -- Peter
[O] How to include comments on export? org-exp-blocks.el?
I'm trying to see if there is a way to include comments on export, to show up as something like the comments boxes you see in MS Word. I see Eric Schulte did some work on this and that somehow it ended up (I think) as part of what you could do using the org-exp-blocks addon. But I'm not sure how you actually use it. Can someone give an example of how org-exp-blocks (or anything else) could be used to export comment blocks as graphic notes in the text? Thanks, Herb
Re: [O] [PATCH] Agenda: Allow filter list without category in org-agenda-to-appt
Hi Peter, pmli...@free.fr (Peter Münster) writes: Here the output of git format-patch master. I hope it's correct, it was my first git-commit... Yes, that's great -- I could save the patch and apply it without problem. http://orgmode.org/w/?p=org-mode.git;a=commit;h=68ffb7a7cc8cd99a49cf69491edba85988f8229c Next time, you can simply attach the patch instead of inserting it in the body of the email. That way it gets caught by the patchwork. Also, you can send it directly to the list, but the way to achieve this depends on your mail client. For example: http://andrewprice.me.uk/weblog/entry/generating-patch-emails-with-git Thanks! HTH, -- Bastien
Re: [O] How to include comments on export? org-exp-blocks.el?
Herbert Sitz hesitz at gmail.com writes: Can someone give an example of how org-exp-blocks (or anything else) could be used to export comment blocks as graphic notes in the text? Just to add a bit. I do have the following line in my .emacs: (require 'org-exp-blocks) and I have a comment like this in my document: --- sample text below -- * Heading one text here #+begin_comment some comment text here #+end_comment * Heading two --- sample text above -- When I export it the headings and text print out but the comment doesn't. I assume I need to do something more than have the 'require' for org-exp-blocks in my .emacs but I can't figure out what it is. -- Herb
Re: [O] How to include comments on export? org-exp-blocks.el?
Herbert Sitz hes...@gmail.com wrote: Herbert Sitz hesitz at gmail.com writes: Can someone give an example of how org-exp-blocks (or anything else) could be used to export comment blocks as graphic notes in the text? Just to add a bit. I do have the following line in my .emacs: (require 'org-exp-blocks) and I have a comment like this in my document: --- sample text below -- * Heading one text here #+begin_comment some comment text here #+end_comment * Heading two --- sample text above -- When I export it the headings and text print out but the comment doesn't. I assume I need to do something more than have the 'require' for org-exp-blocks in my .emacs but I can't figure out what it is. The only documentation there is seems to be in the file itself (and that is not very complete). If you get it working, you might want to submit a patch to improve the documentation. Two hints from org-exp-blocks.el: , | ;; This is a utility for pre-processing blocks in org files before | ;; export using the `org-export-preprocess-hook'. It can be used for ` , | (defun org-export-blocks-preprocess () | Export all blocks according to the `org-export-blocks' block export alist. | Does not export block types specified in specified in BLOCKS | which defaults to the value of `org-export-blocks-witheld'. ` So I tried --8---cut here---start-8--- (add-hook 'org-export-preprocess-hook (function org-export-blocks-preprocess)) --8---cut here---end---8--- and I get the comment in the HTML output. Nick
[O] Fixed!! (was: Re: Problem with org-startup-indented)
On Tue, 18 Oct 2011 17:30:17 +, Andrei Jirnyi wrote: There is a major issue with org-indent-mode under org-mode 7.7 (downloaded today with Emacs PPM, dated 2011-10-18) and Emacs 23.2. It seems that whatever the issue was, it could be fixed by either: - forcing byte-compile on the downloaded package files by smth like M-: (byte-recompile-directory ~/.emacs.d/elpa/org/[whatever] 0 t) - loading the newer (2011-10-24) distribution. Perhaps it was related to the ELPA thing somehow. I wonder if the order of compilation might matter for org-mode? I think in the comments in package.el someone mentions that it currently has issues with tramp because tramp requires a specific order of compilation. --aj
Re: [O] Byte compiler warnings
A few warnings from Emacs 23.2.1 here: Compiling file /home/xx/.emacs.d/elpa/org-20111024/ob-C.el at Mon Oct 24 18:20:36 2011 Entering directory `/home/xx/.emacs.d/elpa/org-20111024/' Compiling file /home/xx/.emacs.d/elpa/org-20111024/ob-calc.el at Mon Oct 24 18:20:36 2011 In end of data: ob-calc.el:105:1:Warning: the following functions are not known to be defined: calc-store-into, calc-recall, math-evaluate-expr Compiling file /home/xx/.emacs.d/elpa/org-20111024/ob-shen.el at Mon Oct 24 18:20:38 2011 In org-babel-execute:shen: ob-shen.el:68:32:Warning: reference to free variable `result-params' ob-shen.el:72:19:Warning: reference to free variable `result' Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-agenda.el at Mon Oct 24 18:20:39 2011 In org-agenda-list: org-agenda.el:3555:26:Warning: `org-agenda-ndays' is an obsolete variable (as of Emacs 24.1); use `org-agenda-span' instead. In org-agenda-get-todos: org-agenda.el:4596:26:Warning: reference to free variable `org-heading-keyword-regexp-format' In org-agenda-goto-today: org-agenda.el:6410:59:Warning: `org-agenda-ndays' is an obsolete variable (as of Emacs 24.1); use `org-agenda-span' instead. In org-agenda-reset-view: org-agenda.el:6495:36:Warning: `org-agenda-ndays' is an obsolete variable (as of Emacs 24.1); use `org-agenda-span' instead. Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-colview.el at Mon Oct 24 18:20:41 2011 In org-columns-capture-view: org-colview.el:1155:32:Warning: reference to free variable `org-heading-keyword-regexp-format' org-colview.el:1160:33:Warning: reference to free variable `org-heading-regexp' Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-compat.el at Mon Oct 24 18:20:41 2011 In org-find-library-name: org-compat.el:341:14:Warning: find-library called with 3 arguments, but accepts only 1 Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-docbook.el at Mon Oct 24 18:20:41 2011 In org-export-as-docbook: org-docbook.el:502:31:Warning: reference to free variable `org-heading-keyword-regexp-format' Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-exp.el at Mon Oct 24 18:20:42 2011 In org-export-protect-quoted-subtrees: org-exp.el:1641:31:Warning: reference to free variable `org-heading-keyword-regexp-format' In org-export-remove-comment-blocks-and-subtrees: org-exp.el:1936:31:Warning: reference to free variable `org-heading-keyword-regexp-format' Compiling file /home/xx/.emacs.d/elpa/org-20111024/org-html.el at Mon Oct 24 18:20:47 2011 In org-export-as-html: org-html.el:1179:31:Warning: reference to free variable `org-heading-keyword-regexp-format'
Re: [O] How to include comments on export? org-exp-blocks.el?
Herbert Sitz hes...@gmail.com writes: I'm trying to see if there is a way to include comments on export, to show up as something like the comments boxes you see in MS Word. What is your target format? Is it org-odt-doc. If yes, then currently there is no support for annotations/comments. It is doable. I did some investigation of it in some other context - inline tasks. You can see some of my notes here: See the Footnotes section of - http://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg00357.html
Re: [O] Org-mode Standardized Code Block Keywords
Chris Malone chris.m.mal...@gmail.com writes: Hi Eric, Here is the CSV output from google moderator - do with it what you wish: Great, I've incorporated this output. Thanks -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [RFC] Standardized code block keywords
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Daniel, Daniel Bausch wrote: named code blocks [1] -- source srcname function calling external functions [2] -- call lob named data [3] -- tblname resname results data what about #+name: for [1] and [3], and #+call: for [2] ? That a table or list contains data is obvious. The only thing, the additional line is for, is to name it. As Eric showed us, this is not always to name it... If the table is the results of an unamed block, you will have #+name: followed by no name! #+name: | line 1 | data1 | | line 2 | data2 | what I also find quite disturbing. I also find this to be disconcerting. -- Eric Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Source blocks for tiny snippets
Nick Dokos nicholas.do...@hp.com writes: Thorsten quintf...@googlemail.com wrote: ... There is, e.g., the shortcut ,--- | s TAB `--- to insert a code-block, but its somehow underdocumented - I don't remember, where I read about it, and don't find it in the manual anymore. It is documented in sec. 15.2, Easy Templates, of the org manual (along with how to add your own): (info (org) Easy Templates) I was not aware this existed. I've just updated the manual to point to this feature when the code block syntax is introduced. Thanks -- Eric Nick -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] How to include comments on export? org-exp-blocks.el?
So I tried (add-hook 'org-export-preprocess-hook (function org-export-blocks-preprocess)) and I get the comment in the HTML output. Is it valid a valid xhtml? M-x nxml-mode C-c C-n (assumming rng validation is on) I find that it suffers from the same problem that cropped up wrt special blocks. See this thread http://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00046.html I think the comment blocks are better handled as special blocks instead of org-exp-blocks. ps: I think number of blocks and hooks in Org reflect number of people that worked on it :-) --
Re: [O] How to include comments on export? org-exp-blocks.el?
Jambunathan K kjambunat...@gmail.com wrote: So I tried (add-hook 'org-export-preprocess-hook (function org-export-blocks-preprocess)) and I get the comment in the HTML output. Is it valid a valid xhtml? I have no idea: I was mainly interested in how to make org-exp-blocks to work (for some value of work) and although I looked at the HTML, I didn't check it. M-x nxml-mode C-c C-n (assumming rng validation is on) I find that it suffers from the same problem that cropped up wrt special blocks. See this thread http://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00046.html I think the comment blocks are better handled as special blocks instead of org-exp-blocks. That may very well be true. ps: I think number of blocks and hooks in Org reflect number of people that worked on it :-) -- Well, I don't mind a plethora of hooks: they enable things that wouldn't be possible otherwise (and they are even documented and easily findable because of uniform naming: either the M-x org--hook trick which works because of the uniform naming [fn:1] or the Worg (?) page that Carsten pointed to some time ago[fn:2]). As for org-exp-blocks, two out of the three areas of its application, as discussed in the commentary, are deprecated: only comment remains. But contrary to your (tongue-in-cheek) remark, Eric Schulte seems to be single-handedly responsible for all of the block stuff :-) Nick Footnotes: [fn:1] Note to future maintainers: don't ever name a hook anything other than org-foo-bar-hook or else :-) [fn:2] I prefer the first to the second because I can do it right in emacs: no need to go look up URLs and use inferior tools.
Re: [O] How to include comments on export? org-exp-blocks.el?
I think the comment blocks are better handled as special blocks instead of org-exp-blocks. That may very well be true. If only - , From org-export-preprocess-string | ;; Call the hook | (run-hooks 'org-export-preprocess-hook) | | ;; Remove comment environment and comment subtrees | (org-export-remove-comment-blocks-and-subtrees) | | ;; Blockquotes, verse, and center | (org-export-mark-blockquote-verse-center) | (run-hooks 'org-export-preprocess-after-blockquote-hook) ` Before it hits the blockquote hook the comment block gets removed. Now there is a reason why the hook is hooking up to org-export-preprocess-hook. While complaining of plethora of hooks, I was mainly complaining from this standpoint. This example also illustrates my frustration as an implementer well. Apart from other things, there is this - Oh! yet another hook that I need to take care of and cater to in org-odt.el. Also software behaviour is counter-intuitive. This prevents one from asserting a mental model with any confidence without diving in to the code. ps: I think number of blocks and hooks in Org reflect number of people that worked on it :-) -- Well, I don't mind a plethora of hooks: they enable things that wouldn't be possible otherwise (and they are even documented and easily findable because of uniform naming: either the M-x org--hook trick which works because of the uniform naming [fn:1] or the Worg (?) page that Carsten pointed to some time ago[fn:2]). org-exp.el is a sequential assembly line. If one rearranges logic in it even a bit - with no regard to the hook boundaries for example - the whole export process goes for a toss. And when you name a hook afterblockquote hook you can't move it before the blockquote can you? As for org-exp-blocks, two out of the three areas of its application, as discussed in the commentary, are deprecated: only comment remains. But contrary to your (tongue-in-cheek) remark, Eric Schulte seems to be single-handedly responsible for all of the block stuff :-) I do see some aspects of current day babel in the deprecated blocks. May be Carsten and various users from the distant past had a hand in various standard but useful hooks like verse, quote, center, comments etc. Nick Footnotes: [fn:1] Note to future maintainers: don't ever name a hook anything other than org-foo-bar-hook or else :-) [fn:2] I prefer the first to the second because I can do it right in emacs: no need to go look up URLs and use inferior tools. --
