Re: [Orgmode] Error when running org-babel-execute-buffer -- Wrong type argument: consp, nil
Thanks for the suggestion Nick, I've moved the macro definition up towards the top of ob.el, and for good measure I am now autoloading it. After this change I am able to call both ob-execute-subtree and ob-execute-buffer without error on the following simple Org-mode file * top ** first #+begin_src emacs-lisp (+ 1 1 1 1 1) #+end_src ** second #+begin_src emacs-lisp (message even more) #+end_src Could you and/or Konrad let me know if this now works on your systems, and if not could you send me an example file that exercises the error? Thanks -- Eric Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: Thanks for doing most of the debugging on this. After much banging of my head, I stumbled onto this very nice page of common problems with compiled Macros in Emacs Lisp [1], it looks like this sort of thing has happened before. :) I realized I was guilty of one of the macro sins specified above, and after rectifying that design flaw I believe (at least for my simple test case) this error should be fixed. Please let me know if you continue to run into this problem with the byte-compiled version of this macro. ... Footnotes: [1] http://www.gnu.org/s/emacs/manual/html_node/elisp/Problems-with-Macros.html After Konrad reported that this doesn't fix it, I tried it too with his simple org file and got the same error [fn:1]. So after trying the usual debugging tricks and coming up empty, I took a look at the ob.elc file and the problem was obvious: the macro was not expanded during compilation. I'm not sure how exactly we get to the ``consp nil'' error that way, but I'm pretty sure that the solution is to change the order of the macro and the function that uses it in ob.el, so the definition precedes the use. Cheers, Nick PS. I can now go to bed in peace... Footnotes: [fn:1] OT to the above: I had to name the session , otherwise python would report , | Traceback (most recent call last): | File stdin, line 5, in module | File stdin, line 3, in main | NameError: global name 'days' is not defined ` Here for reference is my modification to Konrad's original example: * Vacation days #+begin_src python :session foo :results silent days = 32+2+9 #+end_src ** Vacation 2010-10-28 Thu-2010-10-29 Fri #+begin_src python :session foo :results silent days -= 2 #+end_src ** Remaining days #+begin_src python :session foo :results value days #+end_src #+results: : 41 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Error when running org-babel-execute-buffer -- Wrong type argument: consp, nil
On 19 Nov 2010, at 09:19, Eric Schulte wrote: Could you and/or Konrad let me know if this now works on your systems, and if not could you send me an example file that exercises the error? It works fine now! Thanks, Konrad. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] Change C-' behaviour on #+TBLFM: line
Hi, Short description: I recently started to use tables in org-mode. Having the pointer inside the the table and pressing C-c' I can enter the formula buffer. However, placing the pointer on the #+TBLFM: line C-c' results in Find file or URL:. If even more people believe this is confusing, I would suggest to switch the behaviour. C-c' on a #+TBLFM: line should open up the formular buffer. Longer Explanation: For small changes of the formula I often edit the #+TBLFM: line directly. If things went more complex or get messed, I press C-c' to enter the formula buffer. However, at this time my pointer is located at the #+TBLFM: line. The associated call function for C-c' is: org-edit-special This function calls org-table-edit-formulas in case the point is located inside the table and ffap aka find-file-at-point in all other cases (omitting the cases for source code and include lines here for simplicity) Thus pressing C-c' at #+TBLFM ends up with the request for a file or a URL. In my opinion org-edit-special needs another case to look out for #+TBLFM or resp. combine this with the case to call `org-table-edit-formulas'. Please find below a patch for that. ---patchbegin diff --git a/lisp/org.el b/lisp/org.el index 023e019..a7e4d33 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -17259,7 +17259,9 @@ When in an #+include line, visit the include file. Otherwise call ((org-edit-fixed-width-region)) ((org-at-table.el-p) (org-edit-src-code)) - ((org-at-table-p) + ((or (org-at-table-p) (save-excursion + (beginning-of-line 1) + (looking-at [ \t]*#\\+TBLFM))) (call-interactively 'org-table-edit-formulas)) (t (call-interactively 'ffap ---patchend- This is my very first public org-mode patch and my very first hack in vital org-mode elisp code. Thus, don't laugh or blame to much :) Best regards Torsten ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: org-indent, org-inlinetask: patches on github
Hi Nicolas, Nicolas Goaziou wrote: Sébastien Vauban writes: I tested the look and feel of the export to HTML and PDF. Works fine. Works even better (IMHO) with the suggested template. The advantage is to get a real different look for the inlined task, so that it gets your attention as it deserves it. Ok, I do not mind, as I do not use inline tasks. I trust you here. I have applied it on github (and corrected the misplaced b). Thanks -- as well for the misplaced b (it was working fine, but not semantically in the correct spot, right). If it is a sane default template for HTML, perhaps someone could tell me what its equivalent is for DocBook? Can't be of any help for that. - Regarding LaTeX, my suggestion requires the =todonotes= LaTeX package to be loaded in the header. For that one I'm not sure adding one more package to those already inserted by default is a good idea. Is =todonotes= standard in every LaTeX distribution? I think so, but what really is standard? With TeXLive, almost all existing packages are installed nowadays (you can't not choose anymore for base or medium installation packages). So, yes, it's directly available. With MikTeX, I have no idea. But MiKTeX pops up the user for missing packages, allowing its installation in a couple of seconds. If not by default, shouldn't be a problem either. I think default templates should be clean and very low on requirements. This is not too hard for an user of this (undocumented) feature of Org to configure it to its needs after all. I share your view on keeping trying to be as basic as possible in requirements. Though, I must admit that, at the time when I only used pure LaTeX for editing my stuff, the todonotes package appeared as the only valuable one. And, as its name says, it really is targetting TODO notes! What do users (and maintainers) think about it? I'm interested as well by comments... When do you think this could be merged in the master branch? Best regards, Seb -- Sébastien Vauban ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] Quarters added to clocktables
Hi,
I'm proud to present my first patch to orgmode.
With this patch quarters are added to clocktables. It is now possible to
show data for a quarter via the following syntax:
:block thisq[-n] or
:block lastq
:block 2010-Q2
Other places where quarters might be handy (for instance repeating
events quarterly) are still todo.
I've patched two files, the main file lisp/org-clock.el and the
documentation in doc/org.texti
Regards,
Erwin Vrolijk
http://snow.nl
diff --git a/doc/org.texi b/doc/org.texi
index 06583d7..5f07dbd 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -5820,6 +5820,7 @@ be selected:
2007-12-31@r{New year eve 2007}
2007-12 @r{December 2007}
2007-W50 @r{ISO-week 50 in 2007}
+ 2007-Q2 @r{2nd quarter in 2007}
2007 @r{the year 2007}
today, yesterday, tod...@var{n} @r{a relative day}
thisweek, lastweek, thiswe...@var{n} @r{a relative week}
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 3146926..1301fb8 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -1653,6 +1653,64 @@ buffer and update it.
(re-search-forward ^[ \t]+#\\+END:.* nil t)
(= (match-end 0) pos)
start
+(defun org-day-of-week (day month year)
+ Returns the day of the week as an integer.
+ (nth 6
+ (decode-time
+ (date-to-time
+(format %d-%02d-%02dT00:00:00 year month day)
+
+(defun org-quarter-to-date (quarter year)
+ Get the date (week day year) of the first day of a given quarter.
+ (cond
+ ((= quarter 1)
+(setq startday (org-day-of-week 1 1 year))
+(cond
+ ((= startday 0)
+ (list 52 7 (- year 1)))
+ ((= startday 6)
+ (list 52 6 (- year 1)))
+ ((= startday 4)
+ (list 1 startday year))
+ (( startday 4)
+ (list 53 startday (- year 1)))
+ )
+)
+ ((= quarter 2)
+(setq startday (org-day-of-week 1 4 year))
+(cond
+ ((= startday 0)
+ (list 13 startday year))
+ (( startday 4)
+ (list 14 startday year))
+ ((= startday 4)
+ (list 13 startday year))
+ )
+)
+ ((= quarter 3)
+(setq startday (org-day-of-week 1 7 year))
+(cond
+ ((= startday 0)
+ (list 26 startday year))
+ (( startday 4)
+ (list 27 startday year))
+ ((= startday 4)
+ (list 26 startday year))
+ )
+)
+ ((= quarter 4)
+(setq startday (org-day-of-week 1 10 year))
+(cond
+ ((= startday 0)
+ (list 39 startday year))
+ ((= startday 4)
+ (list 40 startday year))
+ (( startday 4)
+ (list 39 startday year))
+ )
+)
+ )
+ )
(defun org-clock-special-range (key optional time as-strings)
Return two times bordering a special time range.
@@ -1670,6 +1728,10 @@ the returned times will be formatted strings.
(dow (nth 6 tm))
(skey (symbol-name key))
(shift 0)
+(q (cond ((= (nth 4 tm) 10) 4)
+ ((= (nth 4 tm) 7) 3)
+ ((= (nth 4 tm) 4) 2)
+ ((= (nth 4 tm) 1) 1)))
s1 m1 h1 d1 month1 y1 diff ts te fm txt w date)
(cond
((string-match ^[0-9]+$ skey)
@@ -1687,19 +1749,35 @@ the returned times will be formatted strings.
(setq d (nth 1 date) month (car date) y (nth 2 date)
dow 1
key 'week))
+ ((string-match ^\\([0-9]+\\)-[qQ]\\([1-4]\\)$ skey)
+ (require 'cal-iso)
+ (setq y (string-to-number (match-string 1 skey)))
+ (setq q (string-to-number (match-string 2 skey)))
+ (setq date (calendar-gregorian-from-absolute
+ (calendar-absolute-from-iso (org-quarter-to-date q y
+ (setq d (nth 1 date) month (car date) y (nth 2 date)
+ dow 1
+ key 'quarter))
((string-match
^\\([0-9]+\\)-\\([0-9]\\{1,2\\}\\)-\\([0-9]\\{1,2\\}\\)$ skey)
(setq y (string-to-number (match-string 1 skey))
month (string-to-number (match-string 2 skey))
d (string-to-number (match-string 3 skey))
key 'day))
+ ; looking forward with quarters is not implemented yet.
+; ((string-match \\(\\(?:[-]\\|\\(?:!q\\)[+]\\)[0-9]+\\)$ skey)
((string-match \\([-+][0-9]+\\)$ skey)
(setq shift (string-to-number (match-string 1 skey))
- key (intern (substring skey 0 (match-beginning 1))
+ key (intern (substring skey 0 (match-beginning 1
+ (if(and (memq key '(quarter thisq)) ( shift 0))
+(error Looking forward with quarters isn't implemented.)
+ (
+
(when (= shift 0)
- (cond ((eq key 'yesterday) (setq key 'today shift -1))
- ((eq key 'lastweek) (setq key 'week shift -1))
- ((eq key 'lastmonth) (setq key 'month shift -1))
- ((eq key 'lastyear) (setq key 'year shift -1
+ (cond ((eq key 'yesterday) (setq key 'today shift -1))
+ ((eq key 'lastweek) (setq key 'weekshift -1))
+
Re: [Orgmode] including images for tex export, how?
Stinky Wizzleteet wizzlet...@hotmail.com writes: Hi, I've tried adding a link to a picture so it would show up in the tex export. It doesn't get exported as an \includegraphics sort of deal, but as a hyperlink. Where, how can I fix this ? make sure the link starts with file:. I had this problem earlier this morning as I had put only the file name. i.e. you want something like this: some text ... [[file:figures/mygraph.jpg]] or similar. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 23.2.1 : using Org-mode version 7.3 (release_7.3.93.g451ac) ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [Babel] Need for an extra literal block construct
Hi all,
Sébastien Vauban wrote:
Rainer M Krug wrote:
On 24/09/10 11:28, Sébastien Vauban wrote:
Eric Schulte wrote:
Sébastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org
writes:
Eric Schulte wrote:
Would you mind creating an LaTeX environment around the =results=
block, so that we could have the code colorized (via listings or
Minted), and clearly distinguish the results, if we want so.
Having an environment would allow one to use non-proportional font for
the results, or a shadowed background, or...
Would such an environment be in addition too or in place of wrapping
results in the example environment?
I would think of something like this:
\begin{orgresults}
... results block ...
\end{orgresults}
so that one can customize the =orgresults= environment in LaTeX to get a
colored background, another font, etc.
One very nice property of the current setup is that it relies solely on
vanilla Org-mode for export features. If the example export of Org-mode
allowed some form of customization through a customizable div class or
latex environment would that be sufficient?
The name of the environment could be in a variable, yes.
But please note the above request can come out of a misunderstanding or
poor knowledge of already existing parametrization of Org-Babel. Put me
back on tracks if needed...
I think you've made a good point for adding this functionality.
Thanks ;-)
I'll put this on the Babel TODO stack, and reply to this email when we get
something implemented.
FYI, I think it such a thing should be on by default, but with a
possibility to disable it, block per block (or subtree, or file, ...).
Something like a =:nowrapper= header argument?
Probably even one step further: being able to specify the environment to be
used in a header argument, so we would have three possible scenarios:
1) default (equals to :wrapper orgresults) : using \begin{orgresults}
... \end{orgresult}
2) :nowrapper : using no wrapper around the results block
3) :wrapper myEnvironment : using \begin{myEnvironment} ...
\end{myEnvironment}
Sure! This would make *a lot of sense*, IMHO.
Along this (still open -- at least, I hope so) discussion, I have a request
for a new literal block.
Currently, when looking at http://orgmode.org/manual/Literal-examples.html, we
see we only have two environments that keep line breaks as they are in the
Org buffer, that is SRC and EXAMPLE, both mapped in HTML to PRE.
- SRC is used for source code blocks
- EXAMPLE, with a too general name (IMO), is used for results of the block
code execution
But we have nothing else for blocks we would want to present differently.
Since a couple of months, I'm beginning to capture tasks received by emails,
or replies from this list, but they often contain structured replies (lines
prefixed by ) that are unreadable if not presented like they are in Gnus.
Therefore, could we imagine introducting a new block type for emails (for
example)?
Or, if the above gets done, we could have orgresults (for example) used for
the results of SRC blocks, and then keep EXAMPLE for the mails?
What do you think?
Best regards,
Seb
--
Sébastien Vauban
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Clock report (R from the agenda)
Hi Carsten,
Carsten Dominik wrote:
On Nov 4, 2010, at 11:39 AM, Sébastien Vauban wrote:
Carsten Dominik wrote:
you should now be able to use `C-u R' to achieve this.
OK.
The lighter in the mode line will then switch from Clock to Clock{},
A detail: I'd eventually would have written Clock/ to remind the / used
for applying the filters.
I did use {} because the current filter is actually listed in the mode line,
surrounded by {}.
Another: could we append, in the modeline, the tags (or their abbrev, such
as w for work) used in the filtered view?
The filter *is* shown in the mode line. Just not as part of the Clock
lighter.
I wanted to (re-)test these, but now, when doing R, nothing is appended into
my buffer with logged times. Did I do something wrong?
Same with C-u R.
and the current tags filtering should apply to the clock table in the
agenda.
Please test this and report back.
Only minor thing: while the logged lines are correctly shown or made
invisible in the grid time, you need to refresh the table with g for it
to display the correct values.
Until that, what's above is not in sync' with what's in the table. Isn't
there a way to make this refresh happen automatically?
That would be possible. However, the whole idea of filtering is to be *very*
fast, it works by hiding lines that are already in the buffer. Doing a
refresh for each change in filter would be time consuming. So I'd say having
to refresh by hand if the clock is showing filtered stuff is the smaller
evil.
I would privilege coherency of sums above small delay in table appearance. You
know, when we look at tables for chasing time, we really need trustable
figures.
In fact, I don't really understand your argument: if I want quick reports, I
would just choose for the unfiltered view. If I need detailed sums of clocked
times, I would go for the filtrable view (by C-u R) and would accept a
little delay.
If you really don't share this vision, could you at least make this
customizable? TIA.
: | File | L | Headline | Time| |
: |--+---+--+-+--|
: | | | *Total time* | *10:15* | |
: |--+---+--+-+--|
: | Clock-Report.org | | *File time* | *10:15* | |
: | Clock-Report.org | 1 | Work | 8:09| |
: | Clock-Report.org | 2 | Client A | | 3:23 |
: | Clock-Report.org | 2 | Client B | | 4:46 |
: | Clock-Report.org | 1 | Personal | 2:06| |
: | Clock-Report.org | 2 | DONE Lunch with Mary | | 2:06 |
Nice new layout. Much clearer for the levels...
Yes, I think so to. Try :compact t, that is also nice, I think.
I'll have a look -- when reports will come back to life.
| File | Headline | Time| |
|--+--+-+--|
| | ALL *Total time* | *10:15* | |
|--+--+-+--|
| Clock-Report.org | *File time* | *10:15* | |
| | Work | 8:09| |
| | \__ Client A | | 3:23 |
| | \__ Client B | | 4:46 |
| | Personal | 2:06| |
| | \__ DONE Lunch with Mary | | 2:06 |
A couple of days ago, when it still worked, I've just seen something really
painful: all the Org buffers were referenced in that table, even those which
should not participate -- because I did not clock any time in them (for that
or those days).
Plus, having many Org files, in fact, I did not see anymore the lines with the
real time, as there were many lines with 0:00 time before them...
Best regards,
Seb
--
Sébastien Vauban
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [BUG] [Orgmode] link to a file in a footnote ?
Sébastien Mengin sebastien-lis...@edilibre.net writes: Consider the following minimal example: Text[fn:1] * Footnotes [fn:1] Note with a [[file:abecedaire.jpg][link]]. [...] doing C-c C-o on the link moves the cursor on [fn:1] and says in the minibuffer: Position saved mark to ring, go back with C-c , instead of opening the linked file. Is this a bug? Here, Org-mode version 7.3 commit-451acd11cef9db348aa26aa1bbc2a300c75cbe88 GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600) of 2010-05-08 on G41R2F1 confirmed. Yes, this is a bug. More info: If the pointer of the mouse is put on the word link the yellow window that appears says:LINK: file:namefile. so the LINK is somehow recognised as a link to the file namefile. However clicking on it makes the cursor jump to the link of the footnote. But if the link is in a new line, e.g.: * Footnotes [fn:1] Note with a [[file:abecedaire.jpg][link]]. Org-mode opens the link of the file. Then a *qualitative* bug analysis. Seems that Org-mode considers the [[file:abecedaire.jpg][link]] link, when it is the same line of the footnote link, as part of the footnote link itself. My skills end here, I can't help more. Carsten, hth, have a nice squashing ;-) cheers, Giovanni ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] org-reverse-note-order
Hi there, (setq org-reverse-note-order t) does not seem to work properly with org-capture-templates It seems to append my TODO or notes at the end rather at the beginning. Does anybody know what I am doing wrong ? thanks M ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [Babel] Need for an extra literal block construct
Along this (still open -- at least, I hope so) discussion, I have a request for a new literal block. Currently, when looking at http://orgmode.org/manual/Literal-examples.html, we see we only have two environments that keep line breaks as they are in the Org buffer, that is SRC and EXAMPLE, both mapped in HTML to PRE. There's VERSE, too. Yours, Christian ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Mobile.org UTF-8
Hi Henri-Paul I ran into a similar problem when I moved from using MobileMe to Dropbox. What I did that seemed to fix the problem for me was to delete the folder MobileOrg from my Dropbox folder. Then I reset the stuff in Mobileorg on my iPhone, re-sync'ed the iPhone to create a new MobileOrg folder in your Dropbox folder and then it worked. It seems to work fine now. -Neil On Thu, 2010-11-18 at 22:02 -0800, Henri-Paul Indiogine wrote: I am running the latest git org-mode on Emacs 24 in Ubuntu. I also have an iPod with the latest version of MobileOrg, 1.5.1. I also use Dropbox. Just today I reinstalled everything on my iPod because I had problems synchronizing. For some reason Dropbox stopped the synchronization. I unlinked and then linked again to make it all work. Now I obtain the error: Unable to detect file encoding, please re-save this file using UTF-8. I did some Googling and it appears that the problem was solved in the latest version of MobileOrg. I have not changed anything in my .emacs file and have never specified any encoding and before this evening I did not have any problems with MobileOrg. Thanks, Henri-Paul ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] org-article #+INCLUDE LaTex support
Tom,
I have been trying to use the org-article LaTEX setup to get consistent look
and feel across my documents.
I found out that if you insert the following lines directly in a file
(test.org), the desired output is produced. However if you insert the lines in
an #+INCLUDE file, then the outcome is different. The settings of org-article
are ignored.
Test case 1:
File: test.org
#+OPTIONS: H:3
#+LaTeX_CLASS: org-article
#+LaTeX_CLASS_OPTIONS:
[koma,letterpaper,captions=tableheading,utopia,11pt,listings-
sv,microtype,paralist,colorlinks=true,urlcolor=blue,secnums]
#+LATEX_HEADER: \usepackage[AUTO]{inputenc}
* Sample Heading1
** Sample Heading2
*** Sample Heading3
Content goes here
Test case 2:
File: test.org
#+include: boiler.org
#+OPTIONS: H:3
* Sample Heading1
** Sample Heading2
*** Sample Heading3
Content goes here
File: boiler.org
#+OPTIONS: H:2
#+LaTeX_CLASS: org-article
#+LaTeX_CLASS_OPTIONS:
[koma,letterpaper,captions=tableheading,utopia,11pt,listings-
sv,microtype,paralist,colorlinks=true,urlcolor=blue,secnums]
#+LATEX_HEADER: \usepackage[AUTO]{inputenc}
It seems that when files are included, the contents of the included file are
not evaluated consistently. This seems like it is more of an issue with org-
mode and interpreting include file contents.
- Srinivas
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Clock report (R from the agenda)
I don't know what this thread is about, but it seems related.
Aapologies if I'm
hijacking it, but as of my latest pull just this morning,
my agenda has no clocktable in it, where as it previously
did. I have not changed anything as far as I know.
Thanks!
--Erik
Sébastien Vauban wrote:
Hi Carsten,
Carsten Dominik wrote:
On Nov 4, 2010, at 11:39 AM, Sébastien Vauban wrote:
Carsten Dominik wrote:
you should now be able to use `C-u R' to achieve this.
OK.
The lighter in the mode line will then switch from Clock to Clock{},
A detail: I'd eventually would have written Clock/ to remind the / used
for applying the filters.
I did use {} because the current filter is actually listed in the mode line,
surrounded by {}.
Another: could we append, in the modeline, the tags (or their abbrev, such
as w for work) used in the filtered view?
The filter *is* shown in the mode line. Just not as part of the Clock
lighter.
I wanted to (re-)test these, but now, when doing R, nothing is appended into
my buffer with logged times. Did I do something wrong?
Same with C-u R.
and the current tags filtering should apply to the clock table in the
agenda.
Please test this and report back.
Only minor thing: while the logged lines are correctly shown or made
invisible in the grid time, you need to refresh the table with g for it
to display the correct values.
Until that, what's above is not in sync' with what's in the table. Isn't
there a way to make this refresh happen automatically?
That would be possible. However, the whole idea of filtering is to be *very*
fast, it works by hiding lines that are already in the buffer. Doing a
refresh for each change in filter would be time consuming. So I'd say having
to refresh by hand if the clock is showing filtered stuff is the smaller
evil.
I would privilege coherency of sums above small delay in table appearance. You
know, when we look at tables for chasing time, we really need trustable
figures.
In fact, I don't really understand your argument: if I want quick reports, I
would just choose for the unfiltered view. If I need detailed sums of clocked
times, I would go for the filtrable view (by C-u R) and would accept a
little delay.
If you really don't share this vision, could you at least make this
customizable? TIA.
: | File | L | Headline | Time| |
: |--+---+--+-+--|
: | | | *Total time* | *10:15* | |
: |--+---+--+-+--|
: | Clock-Report.org | | *File time* | *10:15* | |
: | Clock-Report.org | 1 | Work | 8:09| |
: | Clock-Report.org | 2 | Client A | | 3:23 |
: | Clock-Report.org | 2 | Client B | | 4:46 |
: | Clock-Report.org | 1 | Personal | 2:06| |
: | Clock-Report.org | 2 | DONE Lunch with Mary | | 2:06 |
Nice new layout. Much clearer for the levels...
Yes, I think so to. Try :compact t, that is also nice, I think.
I'll have a look -- when reports will come back to life.
| File | Headline | Time| |
|--+--+-+--|
| | ALL *Total time* | *10:15* | |
|--+--+-+--|
| Clock-Report.org | *File time* | *10:15* | |
| | Work | 8:09| |
| | \__ Client A | | 3:23 |
| | \__ Client B | | 4:46 |
| | Personal | 2:06| |
| | \__ DONE Lunch with Mary | | 2:06 |
A couple of days ago, when it still worked, I've just seen something really
painful: all the Org buffers were referenced in that table, even those which
should not participate -- because I did not clock any time in them (for that
or those days).
Plus, having many Org files, in fact, I did not see anymore the lines with the
real time, as there were many lines with 0:00 time before them...
Best regards,
Seb
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] org-article #+INCLUDE LaTex support
Aloha Srinivas,
On Nov 19, 2010, at 8:08 AM, Srinivas Pavani wrote:
Tom,
I have been trying to use the org-article LaTEX setup to get
consistent look
and feel across my documents.
I found out that if you insert the following lines directly in a file
(test.org), the desired output is produced. However if you insert
the lines in
an #+INCLUDE file, then the outcome is different. The settings of
org-article
are ignored.
Test case 1:
File: test.org
#+OPTIONS: H:3
#+LaTeX_CLASS: org-article
#+LaTeX_CLASS_OPTIONS:
[koma,letterpaper,captions=tableheading,utopia,11pt,listings-
sv,microtype,paralist,colorlinks=true,urlcolor=blue,secnums]
#+LATEX_HEADER: \usepackage[AUTO]{inputenc}
* Sample Heading1
** Sample Heading2
*** Sample Heading3
Content goes here
Test case 2:
File: test.org
#+include: boiler.org
#+OPTIONS: H:3
* Sample Heading1
** Sample Heading2
*** Sample Heading3
Content goes here
File: boiler.org
#+OPTIONS: H:2
#+LaTeX_CLASS: org-article
#+LaTeX_CLASS_OPTIONS:
[koma,letterpaper,captions=tableheading,utopia,11pt,listings-
sv,microtype,paralist,colorlinks=true,urlcolor=blue,secnums]
#+LATEX_HEADER: \usepackage[AUTO]{inputenc}
It seems that when files are included, the contents of the included
file are
not evaluated consistently. This seems like it is more of an issue
with org-
mode and interpreting include file contents.
- Srinivas
Thanks for reporting this. I'm glad you're able to get the desired
output with org-article.
Org-article doesn't know anything about include files (perhaps it
should?), so I'm guessing along with you that this is an org-mode issue.
If I'm not mistaken, Eric Fraga reported this behavior as a bug
earlier today (http://lists.gnu.org/archive/html/emacs-orgmode/2010-11/msg00860.html
). I'll be interested in the discussion of this issue and any changes
that might be required for org-article to process include files
correctly.
All the best,
Tom___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [bug] Update clocktable (C-cxr with point within clocktable) doesn't detect, inserts new clocktable at point
With Org Mode git, when I use C-c C-x C-r inside an existing clocktable, Org inserts a new clocktable at point. The previous behavior was to detect and update the existing clocktable, which I presume is still the intended behavior. Jeff ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Need for an extra literal block construct
Hi Christian, Christian Moe wrote: Along this (still open -- at least, I hope so) discussion, I have a request for a new literal block. Currently, when looking at http://orgmode.org/manual/Literal-examples.html, we see we only have two environments that keep line breaks as they are in the Org buffer, that is SRC and EXAMPLE, both mapped in HTML to PRE. There's VERSE, too. #+TITLE: Is VERSE a real PRE environment? #+DATE: 2010-11-19 #+LANGUAGE: en_US If VERSE was really handled verbatim (for lists, etc.), then, yes, definitively, I don't need a new environment for emails. Was forgetting about that one, thanks for the reminder! Though, if the following is not a bug, but a deliberative choice, then no, it's not what I'm looking for... * Source block ** Source #+begin_src emacs-lisp (update this-var) (echo OK) #+end_src ** Results #+begin_example pre class=src src-emacs-lisp(update this-var) (echo span class=org-stringOK/span) /pre #+end_example * Example ** Source #+begin_example Does it work? Yes, if you: - update =this-var= - restart OK. Confirmed, but you need to: 1. delete the =cache=. 2. redo it. Thanks to: - you - me #+end_example ** Results #+begin_example pre class=examplegt;gt; Does it work? gt; gt; Yes, if you: gt; - update =this-var= gt; - restart OK. Confirmed, but you need to: 1. delete the =cache=. 2. redo it. Thanks to: - you - me /pre #+end_example * Verse ** Source #+begin_verse Does it work? Yes, if you: - update =this-var= - restart OK. Confirmed, but you need to: 1. delete the =cache=. 2. redo it. Thanks to: - you - me #+end_verse ** Results #+begin_example p class=verse gt;gt; Does it work?br/ gt;br/ gt; Yes, if you:br/ gt; - update codethis-var/codebr/ gt; - restartbr/ br/ OK. Confirmed, but you need to:br/ /pol li delete the codecache/code.br/ /li li redo it.br/ br/ Thanks to:br/ /li li youbr/ /li li mebr/ /p #+end_example ** Right thing or wrong thing? The verse mail is badly translated into HTML: 1. lists are not copied verbatim in the PRE 2. they're even wrong: mix of OL and UL, because there is no ending /OL... While the second is clearly a bug, what about the first point? Best regards, Seb -- Sébastien Vauban ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [Bug] New Org lists
Hi Nicolas, This is a normal list (example): - lists are not copied verbatim in the PRE - they're even wrong: mix of OL and UL, because there is no ending /OL... Place the *cursor at the end* of the first (or second) itemized line (that is, after PRE), and S-arrow right to cycle through the different markers for the lists (-, +, *, 1. and 1)). You'll see that these 2 lines become real headings! In other words, I have finally managed to reproduce a bug I was talking about a couple of weeks ago... Good to know... Best regards, Seb -- Sébastien Vauban ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Need for an extra literal block construct
Hi all,
Sébastien Vauban wrote:
Christian Moe wrote:
Along this (still open -- at least, I hope so) discussion, I have a request
for a new literal block.
Currently, when looking at http://orgmode.org/manual/Literal-examples.html,
we
see we only have two environments that keep line breaks as they are in the
Org buffer, that is SRC and EXAMPLE, both mapped in HTML to PRE.
There's VERSE, too.
#+TITLE: Is VERSE a real PRE environment?
#+begin_verse
Does it work?
Yes, if you:
- update =this-var=
- restart
OK. Confirmed, but you need to:
1. delete the =cache=.
2. redo it.
Thanks to:
- you
- me
#+end_verse
is translated into
#+begin_example
p class=verse
gt;gt; Does it work?br/
gt;br/
gt; Yes, if you:br/
gt; - update codethis-var/codebr/
gt; - restartbr/
br/
OK. Confirmed, but you need to:br/
/pol
li
delete the codecache/code.br/
/li
li
redo it.br/
br/
Thanks to:br/
/li
li
youbr/
/li
li
mebr/
/p
#+end_example
** Right thing or wrong thing?
The verse mail is badly translated into HTML: lists are not copied
verbatim in the PRE
*Same for PDF*: the lists in the VERSE environment are interpreted:
--8---cut here---start-8---
\begin{verse}
Does it work?\\
\\
Yes, if you:\\
- update \url{this-var}\\
- restart\\
\vspace*{1em}
OK. Confirmed, but you need to:\\
\begin{enumerate}
\item delete the \url{cache}.\\
\item redo it.\\
\end{enumerate}
\vspace*{1em}
Thanks to:\\
\begin{itemize}
\item you\\
\item me\\
\end{itemize}
\end{verse}
--8---cut here---end---8---
So are the CODE inlined words (delimited by =equal= signs).
- Bug, or
- on purpose?
Best regards,
Seb
--
Sébastien Vauban
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [Babel] Need for an extra literal block construct
Aloha Sébastien,
Just a side comment on the LaTeX output of your example: it is usually
not a good idea to put markup like \vspace in the .tex file. Commands
like \vspace work there, but they defeat the document design of the
style or class file. In the ideal case, commands like \vspace are
confined to style and class files and do not appear in tex files.
Perhaps the \vspace could be eliminated on the way to squashing your
bug?
All the best,
Tom
On Nov 19, 2010, at 10:26 AM, Sébastien Vauban wrote:
Hi all,
Sébastien Vauban wrote:
Christian Moe wrote:
Along this (still open -- at least, I hope so) discussion, I have
a request
for a new literal block.
Currently, when looking at http://orgmode.org/manual/Literal-examples.html
, we
see we only have two environments that keep line breaks as they
are in the
Org buffer, that is SRC and EXAMPLE, both mapped in HTML to PRE.
There's VERSE, too.
#+TITLE: Is VERSE a real PRE environment?
#+begin_verse
Does it work?
Yes, if you:
- update =this-var=
- restart
OK. Confirmed, but you need to:
1. delete the =cache=.
2. redo it.
Thanks to:
- you
- me
#+end_verse
is translated into
#+begin_example
p class=verse
gt;gt; Does it work?br/
gt;br/
gt; Yes, if you:br/
gt; - update codethis-var/codebr/
gt; - restartbr/
br/
OK. Confirmed, but you need to:br/
/pol
li
delete the codecache/code.br/
/li
li
redo it.br/
br/
Thanks to:br/
/li
li
youbr/
/li
li
mebr/
/p
#+end_example
** Right thing or wrong thing?
The verse mail is badly translated into HTML: lists are not copied
verbatim in the PRE
*Same for PDF*: the lists in the VERSE environment are interpreted:
--8---cut here---start-8---
\begin{verse}
Does it work?\\
\\
Yes, if you:\\
- update \url{this-var}\\
- restart\\
\vspace*{1em}
OK. Confirmed, but you need to:\\
\begin{enumerate}
\item delete the \url{cache}.\\
\item redo it.\\
\end{enumerate}
\vspace*{1em}
Thanks to:\\
\begin{itemize}
\item you\\
\item me\\
\end{itemize}
\end{verse}
--8---cut here---end---8---
So are the CODE inlined words (delimited by =equal= signs).
- Bug, or
- on purpose?
Best regards,
Seb
--
Sébastien Vauban
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Mobile.org UTF-8
Hi Neil! Neil Hepburn nhepb...@ualberta.ca writes: I ran into a similar problem when I moved from using MobileMe to Dropbox. What I did that seemed to fix the problem for me was to delete the folder MobileOrg from my Dropbox folder. Then I reset the stuff in Mobileorg on my iPhone, re-sync'ed the iPhone to create a new MobileOrg folder in your Dropbox folder and then it worked. It seems to work fine now. OK, I can delete the Dropbox folder. However, what do you mean with reset the stuff in MobileOrg on my iPhone? Do you delete the app and then install a fresh one? And then sync with org-mode? Thanks, Henri-Paul -- Henri-Paul Indiogine Email: hindiog...@gmail.com Skype: hindiogine Website: http://people.cehd.tamu.edu/~sindiogine ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Inserting text into the head part of an HTML document?
Thanks Nick and Erik! I just tried #+STYLE: meta name=robots content=noindex, nofollow / which does what I was after. I think this should be documented - so I'll draft a patch. Stephen ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Inserting text into the head part of an HTML document?
which does what I was after. I think this should be documented - so I'll draft a patch. no need - I see its already there, I just missed it before. (section 12.5.7 CSS support) Stephen ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Need for an extra literal block construct
Hi Thomas,
Thomas S. Dye wrote:
On Nov 19, 2010, at 10:26 AM, Sébastien Vauban wrote:
*Same for PDF*: the lists in the VERSE environment are interpreted:
--8---cut here---start-8---
\begin{verse}
Does it work?\\
\\
Yes, if you:\\
- update \url{this-var}\\
- restart\\
\vspace*{1em}
OK. Confirmed, but you need to:\\
\begin{enumerate}
\item delete the \url{cache}.\\
\item redo it.\\
\end{enumerate}
\vspace*{1em}
Thanks to:\\
\begin{itemize}
\item you\\
\item me\\
\end{itemize}
\end{verse}
--8---cut here---end---8---
Just a side comment on the LaTeX output of your example: it is usually not a
good idea to put markup like \vspace in the .tex file. Commands like \vspace
work there, but they defeat the document design of the style or class file.
In the ideal case, commands like \vspace are confined to style and class
files and do not appear in tex files.
Perhaps the \vspace could be eliminated on the way to squashing your bug?
Just to be sure we talk of the same thing, the \vspace is not introduced by
me. It's something automatically inserted in the TeX during the VERSE
conversion.
I think it's clear to you, but let's state it clearly...
Best regards,
Seb
--
Sébastien Vauban
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [Babel] Need for an extra literal block construct
Aloha Séb,
On Nov 19, 2010, at 12:02 PM, Sébastien Vauban wrote:
Hi Thomas,
Thomas S. Dye wrote:
On Nov 19, 2010, at 10:26 AM, Sébastien Vauban wrote:
*Same for PDF*: the lists in the VERSE environment are interpreted:
--8---cut here---start-8---
\begin{verse}
Does it work?\\
\\
Yes, if you:\\
- update \url{this-var}\\
- restart\\
\vspace*{1em}
OK. Confirmed, but you need to:\\
\begin{enumerate}
\item delete the \url{cache}.\\
\item redo it.\\
\end{enumerate}
\vspace*{1em}
Thanks to:\\
\begin{itemize}
\item you\\
\item me\\
\end{itemize}
\end{verse}
--8---cut here---end---8---
Just a side comment on the LaTeX output of your example: it is
usually not a
good idea to put markup like \vspace in the .tex file. Commands
like \vspace
work there, but they defeat the document design of the style or
class file.
In the ideal case, commands like \vspace are confined to style and
class
files and do not appear in tex files.
Perhaps the \vspace could be eliminated on the way to squashing
your bug?
Just to be sure we talk of the same thing, the \vspace is not
introduced by
me. It's something automatically inserted in the TeX during the VERSE
conversion.
I think it's clear to you, but let's state it clearly...
Best regards,
Seb
--
Sébastien Vauban
Yes, that's what I meant. Apologies for any ambiguity.
Tom
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [Babel] Need for an extra literal block construct
Hi Seb, Sébastien Vauban wxhgmqzgw...@spammotel.com writes: *Same for PDF*: the lists in the VERSE environment are interpreted: ... So are the CODE inlined words (delimited by =equal= signs). - Bug, or - on purpose? I believe that this is on purpose, otherwise I don't see why verse would be any different from example. I think of verse as a quote where newlines are enforced (making it good for mail because you don't end up with s stacked in the middle of your paragraphs) I think you may want to look at org-exp-blocks.el, it allows extensible block syntax so that a user can define his/her own types and how they will be exported. This would be useful for custom export of the proposed future babel results block (which I promise I'll implement soon). Best -- Eric Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Mobile.org UTF-8
Hi Neil! 2010/11/19 Neil Hepburn nhepb...@ualberta.ca: I ran into a similar problem when I moved from using MobileMe to Dropbox. What I did that seemed to fix the problem for me was to delete the folder MobileOrg from my Dropbox folder. Then I reset the stuff in Mobileorg on my iPhone, re-sync'ed the iPhone to create a new MobileOrg folder in your Dropbox folder and then it worked. It seems to work fine now. It worked, thanks. HP -- Henri-Paul Indiogine Curriculum Instruction Texas AM University Email: hindiog...@gmail.com Skype: hindiogine Website: http://people.cehd.tamu.edu/~sindiogine Rien ne va de soi. Rien n'est donné. Tous est construit. Gaston Bachelard, 1934 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [Bug] New Org lists
Hello, Sébastien Vauban writes: This is a normal list (example): - lists are not copied verbatim in the PRE - they're even wrong: mix of OL and UL, because... Place the *cursor at the end* of the first (or second) itemized line (that is, after PRE), and S-arrow right to cycle through the different markers for the lists (-, +, *, 1. and 1)). You'll see that these 2 lines become real headings! In other words, I have finally managed to reproduce a bug I was talking about a couple of weeks ago... Good to know... I've pushed a fix on master. Thanks for not giving up with this bug. Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [Babel] Need for an extra literal block construct
Eric Schulte schulte.e...@gmail.com writes:
This would be useful for custom export of the proposed future babel
results block (which I promise I'll implement soon).
An experimental patch implementing wrapping of results using a new
wrap :results header argument is attached. Here is an example of its
usage.
** introducing =wrap= header argument
#+begin_src emacs-lisp :results wrap
(mapcar (lambda (el) (list el (+ 1 (* el el (number-sequence 0 10))
#+end_src
#+results:
#+BEGIN_RESULT
| 0 | 1 |
| 1 | 2 |
| 2 | 5 |
| 3 | 10 |
| 4 | 17 |
| 5 | 26 |
| 6 | 37 |
| 7 | 50 |
| 8 | 65 |
| 9 | 82 |
| 10 | 101 |
#+END_RESULT
now indented
- first
- second
#+begin_src emacs-lisp :results wrap
something else
#+end_src
#+results:
#+BEGIN_RESULT
: something else
#+END_RESULT
I haven't applied it directly to the repository because I fear it could
have negative effects on the wrapping of results in HTML and LaTeX
blocks, so if any brave souls could try this out over the next day or
two and let me know how it works I'd then feel much more comfortable
about dropping it into the core.
Best -- Eric
From e2589d43280164dbcb2e1d3b18ef6bf23ac99b6b Mon Sep 17 00:00:00 2001
From: Eric Schulte schulte.e...@gmail.com
Date: Fri, 19 Nov 2010 16:04:59 -0700
Subject: [PATCH] wrap :results header argument wraps code block results
* lisp/ob.el (org-babel-insert-result): Responds to new wrap header
argument.
(org-babel-merge-params): Includes new wrap header argument in
one of the results header argument exclusive groups.
---
lisp/ob.el | 72 +--
1 files changed, 35 insertions(+), 37 deletions(-)
diff --git a/lisp/ob.el b/lisp/ob.el
index 3689619..9feb0a6 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -1433,11 +1433,11 @@ code the results are extracted in the syntax of the source
(delete-region (point) (org-babel-result-end)))
((member append result-params)
(goto-char (org-babel-result-end)) (setq beg (point)))
- ((member prepend result-params) ;; already there
- )))
+ ((member prepend result-params ; already there
(setq results-switches
(if results-switches (concat results-switches) ))
- (cond
+ ;; insert results based on type
+ (cond
;; do nothing for an empty result
((= (length result) 0))
;; insert a list if preferred
@@ -1449,6 +1449,7 @@ code the results are extracted in the syntax of the source
'(:splicep nil :istart - :iend \n)
;; assume the result is a table if it's not a string
((not (stringp result))
+ (goto-char beg)
(insert (concat (orgtbl-to-orgtbl
(if (or (eq 'hline (car result))
(and (listp (car result))
@@ -1458,24 +1459,30 @@ code the results are extracted in the syntax of the source
(goto-char beg) (when (org-at-table-p) (org-table-align)))
((member file result-params)
(insert result))
- ((member html result-params)
- (insert (format #+BEGIN_HTML%s\n%s#+END_HTML\n
- results-switches result)))
- ((member latex result-params)
- (insert (format #+BEGIN_LaTeX%s\n%s#+END_LaTeX\n
- results-switches result)))
- ((member code result-params)
- (insert (format #+BEGIN_SRC %s%s\n%s#+END_SRC\n
- (or lang none) results-switches result)))
- ((member org result-params)
- (insert (format #+BEGIN_SRC org\n%s#+END_SRC\n result)))
- ((member raw result-params)
- (save-excursion (insert result)) (if (org-at-table-p) (org-cycle)))
- (t
- (org-babel-examplize-region
- (point) (progn (insert result) (point)) results-switches)))
- ;; possibly indent the results to match the #+results line
+ (t (goto-char beg)
+ (org-babel-examplize-region
+ (point) (progn (insert result) (point)) results-switches)))
(setq end (if (listp result) (org-table-end) (point)))
+ ;; possibly wrap result
+ (flet ((wrap (start finish)
+ (goto-char beg) (insert start)
+ (goto-char (+ (if (listp result) 0 (length start)) end))
+ (insert finish) (setq end (point
+ (cond
+ ((member html result-params)
+ (wrap #+BEGIN_HTML\n #+END_HTML))
+ ((member latex result-params)
+ (wrap #+BEGIN_LaTe\n #+END_LaTeX))
+ ((member code result-params)
+ (wrap (format #+BEGIN_SRC %s%s\n (or lang none) results-switches)
+ #+END_SRC))
+ ((member org result-params)
+ (wrap #+BEGIN_ORG\n #+END_ORG))
+ ((member raw result-params)
+ (goto-char beg) (if (org-at-table-p) (org-cycle)))
+ ((member wrap result-params)
+ (wrap #+BEGIN_RESULT\n #+END_RESULT
+ ;; possibly indent the results to match the #+results line
(when (and indent ( indent 0)
;; in this case `table-align' does the work for us
(not (and (listp result)
@@ -1503,22 +1510,13 @@ code the results are extracted in the syntax of the source
((org-at-table-p) (progn (goto-char (org-table-end)) (point)))
((org-in-item-p) (- (org-list-bottom-point) 1))
(t
-
Re: [Orgmode] Re: [Babel] Need for an extra literal block construct
Hi, Perhaps I misunderstood what you're after. As I now understand it, you want line breaks preserved and you don't want anything interpreted, you want verbatim text. Why doesn't EXAMPLE meet your needs? Yours, Christian On 11/19/10 9:12 PM, Sébastien Vauban wrote: Hi Christian, Christian Moe wrote: Along this (still open -- at least, I hope so) discussion, I have a request for a new literal block. Currently, when looking at http://orgmode.org/manual/Literal-examples.html, we see we only have two environments that keep line breaks as they are in the Org buffer, that is SRC and EXAMPLE, both mapped in HTML to PRE. There's VERSE, too. #+TITLE: Is VERSE a real PRE environment? #+DATE: 2010-11-19 #+LANGUAGE: en_US If VERSE was really handled verbatim (for lists, etc.), then, yes, definitively, I don't need a new environment for emails. Was forgetting about that one, thanks for the reminder! Though, if the following is not a bug, but a deliberative choice, then no, it's not what I'm looking for... * Source block ** Source #+begin_src emacs-lisp (update this-var) (echo OK) #+end_src ** Results #+begin_example pre class=src src-emacs-lisp(update this-var) (echospan class=org-stringOK/span) /pre #+end_example * Example ** Source #+begin_example Does it work? Yes, if you: - update =this-var= - restart OK. Confirmed, but you need to: 1. delete the =cache=. 2. redo it. Thanks to: - you - me #+end_example ** Results #+begin_example pre class=examplegt;gt; Does it work? gt; gt; Yes, if you: gt; - update =this-var= gt; - restart OK. Confirmed, but you need to: 1. delete the =cache=. 2. redo it. Thanks to: - you - me /pre #+end_example * Verse ** Source #+begin_verse Does it work? Yes, if you: - update =this-var= - restart OK. Confirmed, but you need to: 1. delete the =cache=. 2. redo it. Thanks to: - you - me #+end_verse ** Results #+begin_example p class=verse gt;gt; Does it work?br/ gt;br/ gt; Yes, if you:br/ gt; - updatecodethis-var/codebr/ gt; - restartbr/ br/ OK. Confirmed, but you need to:br/ /pol li delete thecodecache/code.br/ /li li redo it.br/ br/ Thanks to:br/ /li li youbr/ /li li mebr/ /p #+end_example ** Right thing or wrong thing? The verse mail is badly translated into HTML: 1. lists are not copied verbatim in the PRE 2. they're even wrong: mix of OL and UL, because there is no ending /OL... While the second is clearly a bug, what about the first point? Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Need for an extra literal block construct
Hi Eric, Eric Schulte wrote: Sébastien Vauban wxhgmqzgw...@spammotel.com writes: *Same for PDF*: the lists in the VERSE environment are interpreted. So are the CODE inlined words (delimited by =equal= signs). - Bug, or - on purpose? I believe that this is on purpose, I'd like to have an official answer on this, because I really would have thought the contrary. otherwise I don't see why verse would be any different from example. Of course, that's kinda true but... I think of verse as a quote where newlines are enforced (making it good for mail because you don't end up with s stacked in the middle of your paragraphs) if the above behavior is wanted, then I cannot use VERSE for mails. Because it will corrupt the email layout in both HTML and PDF (for example, in passages of the email that would not be prefixed by ). I think you may want to look at org-exp-blocks.el, it allows extensible block syntax so that a user can define his/her own types and how they will be exported. Rigth point. I did not think anymore of that one. Though, I would like all my documents (even with cited emails) to be compilable by anybody, in both HTML and PDF, without requiring a special customization in the .emacs file, in the CSS or in the LaTeX classes). Hence, I really would like avoiding to introduce my own tags. This would be useful for custom export of the proposed future babel results block (which I promise I'll implement soon). I don't wanna hurry you on this. If I plugged this post to that old thread, it's because they really are (more than) related to each other. Of course, I'll be excited to try and use what you will produce in that direction, but you can spend time first on more important things (if any!? ;-)). BTW, once you will have implemented that, I will be able to use QUOTE for email passages, and your new environment will be compilable without requiring any custom add-on. So, that should answer fully this. Thanks a lot! Best regards, Seb -- Sébastien Vauban ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Need for an extra literal block construct
Hi Christian, Christian Moe wrote: Perhaps I misunderstood what you're after. As I now understand it, you want line breaks preserved and you don't want anything interpreted, you want verbatim text. Why doesn't EXAMPLE meet your needs? Because there are clearly 3 key concepts to be able to distinguish in nice HTML/PDF output: - Code fragments :: text files that use the specific numbers of spaces and characters to line things up. - Sample output :: Output from programs, scripts or commands. - Text giving instructions :: Typically used for quoting passages of an email message. The first one is covered in HTML by the src class and in PDF by listings. The last two are currently handled the same way (ie, not distinguishable). In HTML, both are mapped onto EXAMPLE. Best regards, Seb -- Sébastien Vauban ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL] Two minor issues
Hi Jambunathan, Sorry to be so slow to get to these, Jambunathan K kjambunat...@gmail.com writes: 1. Improper fontification of Babel blocks With babel native fontification on, I see that the commented elisp code down below is not fontified. The problem persists if I kill the buffer and find it again. #+begin_src emacs-lisp ;; (message Hello World) #+end_src err, and I haven't had the energy to investigate this one yet! (While we're at it, here's another org-src fontification minibug that I expect others have noticed: the closing parenthesis here comes up fontified with what looks like the string face #+begin_src emacs-lisp (defvar x nil string) #+end_src ) 2. C-c C-v C-M-h and C-c C-v C-x interaction In the block below do 1. C-c C-v C-M-h, C-c C-v C-x C-M-\ 2. Mark (just) the code-block with C-SPC etc etc. C-c C-v C-x C-M-\ See the difference in behaviour. OK, but I've just fixed that one. Dan #+begin_src xml text:p text:style-name=StandardThis is a xref to text:bookmark-ref text:reference-format=text text:ref-name=__RefHeading__1669_1684552201Heading8 /text:bookmark-ref./text:p #+end_src I have transient mark mode on. Jambunathan K. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Okular Metadata to Org
Hi All,
My first post to the list. I've been working on this python script to
extract Okular metadata and insert it into an org-mode file. I like
using Okular to read and take notes, but accessing those notes is a
total pain. This script takes care of that problem.
You can get the code here:
git clone git://lair.fifthhorseman.net/~rossg/okutorg.git
What the script does is read the xml and creates a .org file with this
structure:
* [[/home/USER/articles/feminism/aronson-Feminism_or_Post-feminism.pdf]]
** [[bibnotes:1
/home/USER/articles/feminism/aronson-Feminism_or_Post-feminism.pdf][Young women
no longer]]
Young women no longer concern themselves with discrimination.
By adding the following lisp to my .emacs files, each 'bibnotes' link
type will open the file to the page on which the note was taken.
Unfortunately, Okular has no switch for opening on a specified
annotation, but the page is not a bad result.
{{{
;; Open okular from org bibnotes to correct page.
(org-add-link-type bibnotes 'org-follow-bibnotes-link)
(defun org-follow-bibnotes-link (link)
Follow links of the type 'pagenumber path/to/file
(when (string-match \\([0-9]+\\)\\([[:blank:]]+\\)\\(\/.*\.pdf\\) link)
(start-process okular nil okular -p
(match-string 1 link)
(match-string 3 link
}}}
The overall code is not great, as I am not a great coder by any
stretch. Nor is the script feature rich, currently it just does a
recursive dump of all the okular metadata files that have
annotations. It does check the .org file for duplicate entries, but in
a rudamentary fashion.
I wanted to integrate this with pymacs or do the import with
lisp, but both of those things are beyond me at the moment.
Any thoughts are welcome. You're welcome to flame me about feminism,
but please not about the code (I know it's weak). This is the first
thing I've ever made public. Help don't hate ;) .
Hopefully someone else will find this useful,
Ross
--
Sent from an Emacs buffer.
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BABEL] Two minor issues
Hi Dan, Dan Davison wrote: #+begin_src emacs-lisp ;; (message Hello World) #+end_src err, and I haven't had the energy to investigate this one yet! Another minibug, when natively fontifying, is that the line #+begin_src is no more fontified up to the end of the screen (well to the end of the line): choose a font with a background color, and you will notice the difference immediately. The line #+end_src is well correctly fontified from begin of a line to end of screen. By end of screen, I mean the whole line, even after the last character of that line... Am I clear? Thanks. Best regards, Seb -- Sébastien Vauban ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Babel] Need for an extra literal block construct
Hi Eric, Eric Schulte wrote: Eric Schulte schulte.e...@gmail.com writes: This would be useful for custom export of the proposed future babel results block (which I promise I'll implement soon). An experimental patch implementing wrapping of results using a new wrap :results header argument is attached. Here is an example of its usage. ** introducing =wrap= header argument #+begin_src emacs-lisp :results wrap (mapcar (lambda (el) (list el (+ 1 (* el el (number-sequence 0 10)) #+end_src #+results: #+BEGIN_RESULT | 0 | 1 | | 1 | 2 | | 2 | 5 | | 3 | 10 | | 4 | 17 | | 5 | 26 | | 6 | 37 | | 7 | 50 | | 8 | 65 | | 9 | 82 | | 10 | 101 | #+END_RESULT now indented - first - second #+begin_src emacs-lisp :results wrap something else #+end_src #+results: #+BEGIN_RESULT : something else #+END_RESULT I haven't applied it directly to the repository because I fear it could have negative effects on the wrapping of results in HTML and LaTeX blocks, so if any brave souls could try this out over the next day or two and let me know how it works I'd then feel much more comfortable about dropping it into the core. Waoouwww, that was quick! I'll patch my system and test it this evening. Thank you *very much*... Best regards, Seb -- Sébastien Vauban ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
