Re: [Orgmode] Re: timestamp with repeater interval
On Oct 25, 2010, at 7:30 PM, Matt Lundin wrote: Eric S Fraga writes: On Sun, 24 Oct 2010 17:11:34 +0200, Rainer Thiel jena.de> wrote: http://orgmode.org/worg/org-faq.php#org-diary-class This would be exactly what I need -- if it really worked. It does not for me, probably because I haven't really understood how it is supposed to work. I should have expected that an entry like this: * TODO Class 10:00am-12:00am <%%(org-diary-class 10 18 2010 2 12 2011 3)> in one of my agenda files would make show up an agenda entry every Wednesday between Oct 18th, 2010 and Feb 12, 2011 in my agenda. But this is not the case, nothing shows up. What am I doing wrong? What is wrong (if you can call it that) is that the actual argument list to the org-diary-class function depends on the settings of a couple of variables: calendar-date-style and/or european-calendar-style. I have been wondering for many years: What was Edward M. Reingold thinking when he made this horrible decision. I mean, local dependencies when parsing plain text dates - I guess there is no way around it. But in a function call? Sequence of arguments? What? Cheers - Carsten As I have the former set to 'iso, in my case I need to specify dates in the Y M D order: * TODO Class 10:00am-12:00am <%%(org-diary-class 2010 10 18 2011 2 12 3)> You may need to do the same. I've cc-ed the org-mode list for others to be aware of this as well. Thanks for this clarification Eric. I updated the FAQ accordingly. Best, Matt ___ 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] Re: Aligning Columns in HTML Export Tables
OK, I think this change is now done. Thank you all for sharing your
expertise!
- Carsten
On Oct 25, 2010, at 11:39 PM, Sebastian Rose wrote:
Christian Moe writes:
Maybe someone with a browser where colgroups actually do work
(Opera!) can check
1. if they only work with the align attribute, and not with CSS, and
2. whether they still work (take precedence) now that the
individual cells are
aligned with CSS for their class.
They _never_ took precedence, as soon as I used a style like this:
/* My default for all td elements */
td { text-align:left; }
The `td' style will alway be a "better" CSS-match than the col's style
or class attribute, even then the col's align attribute. It's even
the
expected behaviour according to CSS standards since that what's the
`C'
in CSS means. I have to remove my favourite default style for td
elements from my stylesheet to make that work in Opera, too. In
current
FF it does not work at all.
Here's another test:
CSS:
--8<---cut here---start->8---
col.right { text-align:right;vertical-align:top;background-
color:red; }
col.left { text-align:left;vertical-align:top;background-
color:green; }
col.center { text-align:center;vertical-align:top;background-
color:blue; }
--8<---cut here---end--->8---
A table:
--8<---cut here---start->8---
class="right" />
ABC
1bartext
12test300
9foo4
--8<---cut here---end--->8---
The only `style' that works that way is the `background-color'. In
Opera and FF at least.
Means, the `class' attribute in elements doesn't work very well
(but '' might make sense with
alternating colors)..
Both, 'align' and the 'style' attribute will be overwritten by a
default
style for a element in the users stylesheet (some prefere center,
some left alignment as the default).
It's common practice to have `style' or `class' attribute in td
elements. That's what classes are for in the end. Make HTML elements
members of a group with certain properties.
Why not jut go with it?
Look at `magento's code, Drupal, whatever. They even use more those
usefull classes, e.g. `first' and `last' for the first and last
elements
of lists. HTML elements without classes are hard to find. The reason
is, that HTML is just a document structure. Classes (and IDs) make
those elements live.
"first" "last" "right" "left" "content" "footnote" "menu" "comment"
"big" "small" "light" "dark" "pro" "contra" - classes make the
difference.
Plus 'class="right"' is easy to change in central place left
entrirely to the user: the stylesheet.
XML is not meant to avoid clutter. And if it was, something went
terribly wrong, I guess :)
Sebastian
___
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: [PATCH] sexp may retrurn a list
Applied, thanks.
- Carsten
On Oct 24, 2010, at 10:01 PM, Łukasz Stelmach wrote:
Łukasz Stelmach writes:
I've disovered, that %%(org-bbdb-anniversaries) returns (as every
other
sexp) a string. Which is OK if there is only one.
Anniversaries: John Doe's 10th wedding anniversary
Unfortunately the agenda view becomes awful if we have noted Jane's
weeding date too
Anniversaries: John Doe's 10th wedding anniversary; Jane Doe's
10th wedding anniversary
And what if we know 3 Eves and 5 Adams and it's Christmas Eve? (Hint:
their name day)
[...]
As Thomas Bauman pointed out, there are functions that can be used in
sexps which return cons cells like this
(nil . "Full Moon 3:35am (CEST)")
(this one is diary-lunar-phases), these aren't properly supported by
the
previous version of my patch. This one can distinguish between such a
cons cell and a "real" list.
("John Doe's 10th wedding anniversary"
"Jane Doe's 10th wedding anniversary")
This is because
(consp (cdr '(a . b))) ; => nil
so org-diary-sexp-entry can be made return (cdr result) only in case
of
the former cons cell. The third condition in the `cond' block is IMHO
enough as it is now, but if you think adding
(listp (cdr result))
may help then be it.
--8<---cut here---start->8---
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index ede62e8..8544a62 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4499,17 +4499,20 @@ the documentation of `org-diary'."
category (org-get-category beg)
todo-state (org-get-todo-state))
- (if (string-match "\\S-" result)
- (setq txt result)
- (setq txt "SEXP entry returned empty string"))
-
- (setq txt (org-format-agenda-item
- "" txt category tags 'time))
- (org-add-props txt props 'org-marker marker)
- (org-add-props txt nil
- 'org-category category 'date date 'todo-state todo-state
- 'type "sexp")
- (push txt ee
+ (dolist (r (if (stringp result)
+(list result)
+ result)) ;; we expect a list here
+ (if (string-match "\\S-" r)
+ (setq txt r)
+ (setq txt "SEXP entry returned empty string"))
+
+ (setq txt (org-format-agenda-item
+ "" txt category tags 'time))
+ (org-add-props txt props 'org-marker marker)
+ (org-add-props txt nil
+ 'org-category category 'date date 'todo-state todo-state
+ 'type "sexp")
+ (push txt ee)
(nreverse ee)))
(defun org-diary-class (m1 d1 y1 m2 d2 y2 dayname &rest skip-weeks)
diff --git a/lisp/org-bbdb.el b/lisp/org-bbdb.el
index 53514f7..0d3134d 100644
--- a/lisp/org-bbdb.el
+++ b/lisp/org-bbdb.el
@@ -338,8 +338,7 @@ This is used by Org to re-create the anniversary
hash table."
(setq text (append text (list tmp)))
(setq text (list tmp)
))
-(when text
- (mapconcat 'identity text "; "
+text))
(defun org-bbdb-complete-link ()
"Read a bbdb link with name completion."
diff --git a/lisp/org.el b/lisp/org.el
index b482b8e..c1d4e7d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15024,7 +15024,10 @@ D may be an absolute day number, or a
calendar-type list (month day year)."
(sleep-for 2))
(cond ((stringp result) result)
((and (consp result)
+ (not (consp (cdr result)))
(stringp (cdr result))) (cdr result))
+ ((and (consp result)
+ (stringp (car result))) result)
(result entry)
(t nil
--8<---cut here---end--->8---
--
Miłego dnia,
Łukasz Stelmach
___
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] Re: 7.01 & Xemacs 21.4.22: decompose-region is not known
On Oct 25, 2010, at 7:48 PM, Jambunathan K wrote: For people who cannot use git, the snapshot release files, corresponding to the latest git version, are provided http://repo.or.cz/w/org-mode.git";>in the git repository. Choose which snapshot you want, presumably the first line in the "shortlog" section and click the tar.gz or zip link at the right end. Looks like the below URL (with no modification whatsoever) always downloads the current tip of the tree. - http://repo.or.cz/w/org-mode.git/snapshot This is cool! Can you please document this in an appropriate spot on Worg? - Carsten ___ 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: Aligning Columns in HTML Export Tables
On Oct 25, 2010, at 11:52 PM, Baoqiu Cui wrote: Sebastian Rose writes: Carsten Dominik writes: OK, I will use class. I could make a special case for the docbook exporter.. +1 +1 for making a "special case for the docbook exporter". :-) (DocBook documents can be rendered in different formats, some of which (like PDF) may know nothing about CSS.) BTW: Org mode's exports to XHTML, not HTML 4.01 or HTML 5 (which is a proposal, not a "standard" or recommendation yet). Still, '' is valid XHTML, too. Maybe we should add a parameter to function org-format-org-table- html to indicate whether we want to format pure standard XHTML tables that do not use "class" or CSS related stuff. This is exactly how I have done it now. - Carsten Thanks, -- Baoqiu ___ 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-capture adds newline(s) when it should not
On Tue, Oct 26, 2010 at 10:34 AM, Noorul Islam wrote:
> On Tue, Oct 26, 2010 at 10:05 AM, Carsten Dominik
> wrote:
>>
>> On Oct 26, 2010, at 6:29 AM, Noorul Islam wrote:
>>
>>> On Mon, Oct 25, 2010 at 5:46 PM, Carsten Dominik
>>> wrote:
On Oct 25, 2010, at 1:58 PM, Noorul Islam wrote:
> On Mon, Oct 25, 2010 at 4:48 PM, Noorul Islam wrote:
>>
>> On Mon, Oct 25, 2010 at 4:21 PM, Marcel van der Boom
>> wrote:
>>>
>>> Hi all,
>>>
>>> I'm in the process of migrating from org-remember to org-capture.
>>> Pretty easy going so far, but it seems org-capture adds newlines,
>>> which
>>> I think it should not do.
>>>
>>> My (test) capture-template is:
>>>
>>> (("t" "Todo" entry
>>> (file "~/.outlet/GTD.org")
>>> "* TODO %?" :prepend t :empty-lines 0)
>>>
>>> with the intention of inserting the captured task on the
>>> first line of the file ~/.outlet/GTD.org. What happens when I capture
>>> an task is this:
>>>
>>>
>>>
>>> * TODO Captured task
>>>
>>>
>>>
>>>
>>> Both before and after the task is a newline. Also, when capturing and
>>> cancelling the capture with C-c C-k the newlines remain whereas the
>>> task is removed.
>>>
>>> I'm using the latest git version with emacs 24.0.50.1 on Ubuntu 10.10
>>>
>>> Am I doing something wrong or is this a bug?
>>>
>>
>> I do not have Emacs 24 as of now.
>>
>> With the same template I am not able to re-create this on
>>
>> Org-mode version 7.01trans (release_7.01h.832.gf7094)
>> GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
>> of 2010-01-30 on noorul
>>
>
> On emacs 24 I am able to re-create the problem Marcel reported.
I find that puzzling. What might have changed in Emacs 24 to cause such
differences? I do not use Emacs 24 on a day-to-day basis yet.
>>>
>>> On emacs 24 (newline 0) inserts a new line which I think is incorrect.
>>
>> Sounds like a but to me too.
>> For now I am working around this in the latest git version.
>>
>> Marcel, this should be fixed. Could you please submit a bug report
>> to Emacs 24, stating that (newline 0) does insert a newline?
>>
>
> I filed a bug report.
>
Here is the link
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7281
- Noorul
___
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] %20 in file://... URL
>Which Org mode version are you using? > >M-x org-version RET > >And can you give an example of a link that does not work as expected? > >Best, > -- David > Hello, Thanks for the feedback. Here is an example of failing link: [[file://localhost/c%3A/msys/1.0/temp/foo.html][link]] the file exists on my PC as c:\msys\1.0\temp\foo.html I am under MSWindows XP. M-x org-version => Org-mode version 7.01 This is more or less the latest version on emacs trunk. BR, Vincent. ___ 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-capture adds newline(s) when it should not
On Tue, Oct 26, 2010 at 10:05 AM, Carsten Dominik
wrote:
>
> On Oct 26, 2010, at 6:29 AM, Noorul Islam wrote:
>
>> On Mon, Oct 25, 2010 at 5:46 PM, Carsten Dominik
>> wrote:
>>>
>>> On Oct 25, 2010, at 1:58 PM, Noorul Islam wrote:
>>>
On Mon, Oct 25, 2010 at 4:48 PM, Noorul Islam wrote:
>
> On Mon, Oct 25, 2010 at 4:21 PM, Marcel van der Boom
> wrote:
>>
>> Hi all,
>>
>> I'm in the process of migrating from org-remember to org-capture.
>> Pretty easy going so far, but it seems org-capture adds newlines,
>> which
>> I think it should not do.
>>
>> My (test) capture-template is:
>>
>> (("t" "Todo" entry
>> (file "~/.outlet/GTD.org")
>> "* TODO %?" :prepend t :empty-lines 0)
>>
>> with the intention of inserting the captured task on the
>> first line of the file ~/.outlet/GTD.org. What happens when I capture
>> an task is this:
>>
>>
>>
>> * TODO Captured task
>>
>>
>>
>>
>> Both before and after the task is a newline. Also, when capturing and
>> cancelling the capture with C-c C-k the newlines remain whereas the
>> task is removed.
>>
>> I'm using the latest git version with emacs 24.0.50.1 on Ubuntu 10.10
>>
>> Am I doing something wrong or is this a bug?
>>
>
> I do not have Emacs 24 as of now.
>
> With the same template I am not able to re-create this on
>
> Org-mode version 7.01trans (release_7.01h.832.gf7094)
> GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
> of 2010-01-30 on noorul
>
On emacs 24 I am able to re-create the problem Marcel reported.
>>>
>>> I find that puzzling. What might have changed in Emacs 24 to cause such
>>> differences? I do not use Emacs 24 on a day-to-day basis yet.
>>>
>>
>> On emacs 24 (newline 0) inserts a new line which I think is incorrect.
>
> Sounds like a but to me too.
> For now I am working around this in the latest git version.
>
> Marcel, this should be fixed. Could you please submit a bug report
> to Emacs 24, stating that (newline 0) does insert a newline?
>
I filed a bug report.
Thank you!
Noorul
___
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-capture adds newline(s) when it should not
On Oct 26, 2010, at 6:29 AM, Noorul Islam wrote:
On Mon, Oct 25, 2010 at 5:46 PM, Carsten Dominik
wrote:
On Oct 25, 2010, at 1:58 PM, Noorul Islam wrote:
On Mon, Oct 25, 2010 at 4:48 PM, Noorul Islam
wrote:
On Mon, Oct 25, 2010 at 4:21 PM, Marcel van der Boom >
wrote:
Hi all,
I'm in the process of migrating from org-remember to org-capture.
Pretty easy going so far, but it seems org-capture adds
newlines, which
I think it should not do.
My (test) capture-template is:
(("t" "Todo" entry
(file "~/.outlet/GTD.org")
"* TODO %?" :prepend t :empty-lines 0)
with the intention of inserting the captured task on the
first line of the file ~/.outlet/GTD.org. What happens when I
capture
an task is this:
* TODO Captured task
Both before and after the task is a newline. Also, when
capturing and
cancelling the capture with C-c C-k the newlines remain whereas
the
task is removed.
I'm using the latest git version with emacs 24.0.50.1 on Ubuntu
10.10
Am I doing something wrong or is this a bug?
I do not have Emacs 24 as of now.
With the same template I am not able to re-create this on
Org-mode version 7.01trans (release_7.01h.832.gf7094)
GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
of 2010-01-30 on noorul
On emacs 24 I am able to re-create the problem Marcel reported.
I find that puzzling. What might have changed in Emacs 24 to cause
such
differences? I do not use Emacs 24 on a day-to-day basis yet.
On emacs 24 (newline 0) inserts a new line which I think is incorrect.
Sounds like a but to me too.
For now I am working around this in the latest git version.
Marcel, this should be fixed. Could you please submit a bug report
to Emacs 24, stating that (newline 0) does insert a newline?
Thanks!
- Carsten
Thanks and Regards
Noorul
___
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-capture adds newline(s) when it should not
On Mon, Oct 25, 2010 at 5:46 PM, Carsten Dominik
wrote:
>
> On Oct 25, 2010, at 1:58 PM, Noorul Islam wrote:
>
>> On Mon, Oct 25, 2010 at 4:48 PM, Noorul Islam wrote:
>>>
>>> On Mon, Oct 25, 2010 at 4:21 PM, Marcel van der Boom
>>> wrote:
Hi all,
I'm in the process of migrating from org-remember to org-capture.
Pretty easy going so far, but it seems org-capture adds newlines, which
I think it should not do.
My (test) capture-template is:
(("t" "Todo" entry
(file "~/.outlet/GTD.org")
"* TODO %?" :prepend t :empty-lines 0)
with the intention of inserting the captured task on the
first line of the file ~/.outlet/GTD.org. What happens when I capture
an task is this:
* TODO Captured task
Both before and after the task is a newline. Also, when capturing and
cancelling the capture with C-c C-k the newlines remain whereas the
task is removed.
I'm using the latest git version with emacs 24.0.50.1 on Ubuntu 10.10
Am I doing something wrong or is this a bug?
>>>
>>> I do not have Emacs 24 as of now.
>>>
>>> With the same template I am not able to re-create this on
>>>
>>> Org-mode version 7.01trans (release_7.01h.832.gf7094)
>>> GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
>>> of 2010-01-30 on noorul
>>>
>>
>> On emacs 24 I am able to re-create the problem Marcel reported.
>
> I find that puzzling. What might have changed in Emacs 24 to cause such
> differences? I do not use Emacs 24 on a day-to-day basis yet.
>
On emacs 24 (newline 0) inserts a new line which I think is incorrect.
Thanks and Regards
Noorul
___
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? - can't set effort from agenda
On 25 Oct 2010 at 17:45, Carsten Dominik wrote: > > > However, what we still need is this: > > Make your file as small as possible so that it still repeats the bug. > > > > Then: how do you construct the agenda view? Is it the daily agenda, > or a TODO list. What does it look like? In which line is the cursor > when you press "e"? Is that line linking to the first task in your > org file, or the last? OK, here is master.org and recurring.org.: master.org --- #+STARTUP: odd #+STARTUP: hidestars #+STARTUP: logdone #+SEQ_TODO: TODO NEXT PENDING | DONE(d!) CANCELLED(c@) #+TAGS: Rock(r) Frog(f) Schedule(s) Important(i) Urgent(u) Week(w) Soon(o) * Org mode for emacs :PROPERTIES: :CATEGORY: Org mode :Effort: 1:30 :END: *** TODO [#E] reproduce org mode effort bug SCHEDULED: <2010-10-25 Mon> :PROPERTIES: :Effort: 0:10 :END: [2010-10-25 Mon] *** TODO how to get list of all tags? SCHEDULED: <2010-10-25 Mon> :PROPERTIES: :Effort: 0:10 :END: *** TODO mark a task done-yesterday SCHEDULED: <2010-10-25 Mon> :PROPERTIES: :Effort: 0:10 :END: -- recurring.org -- #+STARTUP: odd #+STARTUP: hidestars #+SEQ_TODO: TODO NEXT PENDING | DONE(d!) CANCELLED(c@) #+TAGS: Rock(r) Frog(f) * TODO Recurring :PROPERTIES: :CATEGORY: Recurring :END: *** TODO krebs security blog SCHEDULED: <2010-10-25 Mon +1d> :PROPERTIES: :Effort: 0:10 :END: *** TODO read local paper SCHEDULED: <2010-10-25 Mon ++1d> :PROPERTIES: :Effort: 0:10 :END: *** TODO booktv check SCHEDULED: <2010-10-25 Mon +1w> :PROPERTIES: :Effort: 1:30 :END: --- Construct the agenda view by typing C-c a a while in buffer master.org. Then in the agenda, type d for daily. In the agenda, use the up/down arrow keys to move the highlight to the task of interest, and press e, then use a digit to select the effort. This example has made one thing clear to me - when I thought that setting the effort was not working, it was actually CHANGING THE EFFORT FOR A DIFFERENT TASK. The problem is usually observable when setting the effort in the last three tasks in the agenda, the ones from the recurring.org file, though sometimes (I think) those have worked correctly. The effort change for these last three tasks, when wrong, will always be to one of the other tasks in recurring.org. I hope this is sufficient. An oddity in this example is that typing e also opens a second window in the frame (like when spacebar is typed). Don't recall having seen this happen before. The priority setting problem is also observable, but one time only! On my first priority setting attempt with these files, I typed the comma while the first item in recurring was highlighted and got the: org-agenda-priority: Wrong type argument: integer-or-marker-p, nil All further attempts worked properly. Strange. ___ 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: Aligning Columns in HTML Export Tables
Sebastian Rose writes: > Carsten Dominik writes: >> OK, I will use class. I could make a special case for the docbook >> exporter.. > > +1 +1 for making a "special case for the docbook exporter". :-) (DocBook documents can be rendered in different formats, some of which (like PDF) may know nothing about CSS.) > BTW: Org mode's exports to XHTML, not HTML 4.01 or HTML 5 (which is a > proposal, not a "standard" or recommendation yet). Still, > '' is valid XHTML, too. Maybe we should add a parameter to function org-format-org-table-html to indicate whether we want to format pure standard XHTML tables that do not use "class" or CSS related stuff. Thanks, -- Baoqiu ___ 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: Aligning Columns in HTML Export Tables
Christian Moe writes:
> Maybe someone with a browser where colgroups actually do work (Opera!) can
> check
>
> 1. if they only work with the align attribute, and not with CSS, and
>
> 2. whether they still work (take precedence) now that the individual cells are
> aligned with CSS for their class.
They _never_ took precedence, as soon as I used a style like this:
/* My default for all td elements */
td { text-align:left; }
The `td' style will alway be a "better" CSS-match than the col's style
or class attribute, even then the col's align attribute. It's even the
expected behaviour according to CSS standards since that what's the `C'
in CSS means. I have to remove my favourite default style for td
elements from my stylesheet to make that work in Opera, too. In current
FF it does not work at all.
Here's another test:
CSS:
--8<---cut here---start->8---
col.right { text-align:right;vertical-align:top;background-color:red; }
col.left { text-align:left;vertical-align:top;background-color:green; }
col.center { text-align:center;vertical-align:top;background-color:blue; }
--8<---cut here---end--->8---
A table:
--8<---cut here---start->8---
ABC
1bartext
12test300
9foo4
--8<---cut here---end--->8---
The only `style' that works that way is the `background-color'. In
Opera and FF at least.
Means, the `class' attribute in elements doesn't work very well
(but '' might make sense with
alternating colors)..
Both, 'align' and the 'style' attribute will be overwritten by a default
style for a element in the users stylesheet (some prefere center,
some left alignment as the default).
It's common practice to have `style' or `class' attribute in td
elements. That's what classes are for in the end. Make HTML elements
members of a group with certain properties.
Why not jut go with it?
Look at `magento's code, Drupal, whatever. They even use more those
usefull classes, e.g. `first' and `last' for the first and last elements
of lists. HTML elements without classes are hard to find. The reason
is, that HTML is just a document structure. Classes (and IDs) make
those elements live.
"first" "last" "right" "left" "content" "footnote" "menu" "comment"
"big" "small" "light" "dark" "pro" "contra" - classes make the
difference.
Plus 'class="right"' is easy to change in central place left
entrirely to the user: the stylesheet.
XML is not meant to avoid clutter. And if it was, something went
terribly wrong, I guess :)
Sebastian
___
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] Omit top level heading in latex export?
Hi all, Even though this problem has been solved by exporting a region consisting of a single subtree ... I've always thought that it would be nice to be able to get the same behavior using org-publish, so that it can be used more easily in scripts. To be concrete: if I have this structure: * Essays:export: ** Essay One ** Essay Two I'd like to be able to use a publishing option to export "Essays" and get output like Section 1 Essay One Section 2 Essay Two (which is what we get when we select the subtree "Essays" as the active region before exporting) instead of Section 1 Essays Section 1.1 Essay One Section 1.2 Essay Two -- Best, Hsiu-Khuern. On Sun, Oct 3, 2010 at 8:27 AM, suvayu ali wrote: > On 3 October 2010 06:31, Indraneel Majumdar wrote: >> Hi, >> >> I'm running into a problem with latex export. I have several essays under a >> top level heading "Essays". How can I export say only one essay without the >> top level heading "Essays" also showing up in the output as a "Section"? I >> want the heading of my essay to be displayed as a latex section. Is this >> possible in any simple way? The manual describes some option to define my >> own class in the .emacs file, but I couldn't understand that very well. >> eg. >> >> * Essays >> ** Essay One >> ** Essay Two >> >> I want to export only "Essay Two" (eg with a :export: tag) and don't want >> "Essays" to show up. >> > > What about just exporting the subtree you want? I believe the way to > do that is to go to the subtree and while exporting limit the export > with `1'. Hope this helps. > >> >> Thanks in advance, >> Indraneel >> > > -- > Suvayu > > Open source is the future. It sets us free. > > ___ > 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] Re: Aligning Columns in HTML Export Tables
[Veering off-topic, just to round off a discussion]
On 10/25/10 4:55 PM, Sebastian Rose wrote:
How refer to all right-aligned `td' elements in a certain tables without
some special attribute anyway.
Fair point. (In an ideal world, as long as the whole column is
right-aligned it should be enough to refer to all right-aligned `col'
elements, but this clearly is not the case today.)
`class' preferred since this is CSS2 and
will work in commen browsers. I'm not sure how which browsers will
understand the selector `table#special td[align="right"] {...}'.
Firefox, Safari, ... The attribute selector is CSS2, too. But I agree
`class' is preferred.
BTW: Org mode's exports to XHTML, not HTML 4.01 or HTML 5 (which is a
proposal, not a "standard" or recommendation yet). Still,
'' is valid XHTML, too.
Absolutely, I didn't mean to imply otherwise. But I think in this
regard, at least, the thinking behind the HTML 5 proposal makes sense.
(As for the relationship between HTML 5 and XHTML, let's not go there...)
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
[Orgmode] org-crypt fails to encrypt region
Hello,
I am just learning how to use GPG, org-crypt, and epa. I am using:
- org version 7.01h
- emacs version GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version
2.20.1) of 2010-08-14 on barber, modified by Debian.
In my .emacs I have the following variables set:
(require 'epa)
(require 'org-crypt)
(org-crypt-use-before-save-magic)
(setq org-tags-exclude-from-inheritance (quote ("crypt")))
; GPG key to use for encryption
(setq org-crypt-key "Stuart McLean")
I generated a keypair using KGPG, and tried to encrypt a region like the
following with `M-x org-encrypt-entry'.
*** secret data :crypt:
my secret data
I also tried:
*** crypt setup :crypt:
:PROPERTIES:
:CRYPTKEY: Stuart McLean
:END:
my secret data
I get the following in the echo area:
epg-encrypt-string: Encrypt failed: ((exit) (invalid-recipient (reason . 0)
(requested-recipient . "7488B7E9D0613F5E")))
I get the same error with `epa-encrypt-region'.
Again, I am new to this, is there possibly an error with my GPG setup?
Thank you,
Stuart
___
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: Aligning Columns in HTML Export Tables
Actually, I have one more question: The exporter does now (in addition to setting classes for individual fields) Should this be classes instead of align attributes as well? Thanks! - Carsten Maybe someone with a browser where colgroups actually do work (Opera!) can check 1. if they only work with the align attribute, and not with CSS, and 2. whether they still work (take precedence) now that the individual cells are aligned with CSS for their class. Unless the answer to both is "yes", I'd say classes there too, to be consistent with what you're doing on cells (and where HTML5 seems to be heading). 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
[Orgmode] [Babel] Proposed addition to the Library of Babel: Merge two or more (possibly incomplete) tables by first column. And a question.
Hello ! Well, here is an example: > #+tblname: lower > | 2 | b | > | 4 | d | > | 5 | e | > | 6 | h | > > #+tblname: upper > | 1 | A | > | 3 | C | > | 4 | D | > | 10 | J | > | 2 | B | > > #+begin_src emacs-lisp :var t1=lower :var t2=upper > (merge-tables-by-first-column t1 t2) > #+end_src > > #+results: > | 1 | | A | > | 2 | b | B | > | 3 | | C | > | 4 | d | D | > | 5 | e | | > | 6 | h | | > | 10 | | J | > This example uses two tables as input; both of which associate numbers (first column, simply the position within the alphabet) with letters (second column). There is one table for lower- and one table for upper-case letters. Both tables are processed with babel and the function merge-tables-by-first-column. The third table is the result, which merges the two input tables: It contains all lines and all columns from both tables. Note, that not every number needs to appear in both input-tables; e.g. "1" does not appear in the table "lower" and therefore the corresponding cell (first line, second column) within the result table is empty; this is probably different from existing ways of merging tables. This function might be useful for consolidating results from different data sources. Please find the elisp-code for merge-tables-by-first-column below. Having explained so far, I have a question: Currently I have defined the function merge-tables-by-first-column within my emacs startup file. However, I think, that this defun should be placed within the library of babel (if acceptable); and for efficency reasons maybe even in a way, that it will only be compiled at emacs startup (and not at every invocation). Is that possible ? In the meantime, however this code works well, if placed within your .emacs-file. I hope this code might proof useful and would like to thank for any answers to my question ! With kind regards, Marc-Oliver Ihm (defun merge-tables-by-first-column (&rest tables) "Merge any number of tables by treating their first column as a key; sort the result" (interactive) (let (is-all-numbers less-than-function equal-function conversion-function format-specifier rests-of-tables rest-of-rests-of-tables rest-of-table widths-of-tables current-key result-table result-line i) ;; Find out, if all keys in all tables are numbers or if there are strings among them (setq is-all-numbers (catch 'not-a-number (dolist (table tables) (dolist (line table) (unless (numberp (car line)) (throw 'not-a-number 'nil 't)) ;; prepare functions to treat table contents in a unified way (setq format-specifier (if is-all-numbers "%g" "%s")) (setq conversion-function (if is-all-numbers (lambda (x) x) (lambda (x) (if (numberp x) (number-to-string x) x)) )) (setq less-than-function (lambda (x y) (if is-all-numbers (< x y) (string< (funcall conversion-function x) (funcall conversion-function y) (setq equal-function (lambda (x y) (if is-all-numbers (= x y) (string= (funcall conversion-function x) (funcall conversion-function y) ;; sort tables (setq tables (mapcar (lambda (table) (sort table (lambda (x y) (funcall less-than-function (car x) (car y) tables)) ;; compute and remember table widths (setq widths-of-tables (mapcar (lambda (x) (length (car x))) tables)) (setq rests-of-tables (copy-list tables)) ;; loop as long as the rest of table still contains lines (while (progn ;; find lowest key among all tables, which is the key for the next line of the result (setq current-key nil) (dolist (rest-of-table rests-of-tables) (when (and rest-of-table (or (null current-key) (funcall less-than-function (caar rest-of-table) current-key))) (setq current-key (caar rest-of-table current-key) (progn (setq result-line (list current-key)) ;; go through all tables and collect one line for the result table ... (setq i 0) ; table-count ;; cannot use dolist like above, because we need to modify the cons-cells (setq rest-of-rests-of-tables rests-of-tables) (while (progn (setq rest-of-table (car rest-of-rests-of-tables)) (setq i (1+ i)) ;; if table contains current key (if (and rest-of-table (funcall equal-function current-key (caar rest-of-table))) ;; then copy rest of line (progn (nconc result-line (cdar rest-of-table)) ;; and shorten rest (setcar rest-of-rests-of-tables (cdar rest-of-rests-of-
[Orgmode] face org-table should inherit from fixed-pitch
I like to view text (and org) files in variable-pitch-mode, but tables should remain fixed-pitch or they look like garbage. Solution: make the org-table face inherit from fixed-pitch. I easily customized it, but it would be nice if switching to fixed-pitch-mode was turnkey for everyone. ___ 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] TikZ to separate file (babel?) possible?
Hi John,
In the case you describe I would export the *code* of the tikz latex
block rather than the file resulting from evaluating the block.
This is possible by adding the following header argument to the code
block which will evaluate the latex block when the export target is not
latex and will just export the code when the target is latex.
:exports (if latexp "code" "results")
Best -- Eric
John Hendy writes:
> Followup question. I have an existing diagram I had already exported to PDF
> via LaTeX, taken a screenshot of, and used in a presentation. I tried the
> same diagram with the new method and am having issues with the font. The
> original org file is like this:
>
> *---( File_1.org -> embedded LaTeX )---*
> #+latex_header: \usepackage{tikz} \usetikzlibrary{shapes,positioning,arrows}
> #+latex_header: \usepackage[hmargin=2.5cm,vmargin=2.5cm]{geometry}
> #+latex_header: \usepackage{lmodern}
> #+latex_header: \renewcommand{\rmdefault}{cmss}
>
> * Section
>
> #+begin_latex
>
> +++ TikZ code is here +++
>
> #+end_latex
>
> *---( End File_1.org )---*
>
>
> My file using this new method is like this:
>
> *---( File_2.org -> exports TikZ to separate PDF via babel/LaTeX )---*
> #+latex_header: \usepackage{tikz} \usetikzlibrary{shapes,positioning,arrows}
> #+latex_header: \usepackage[hmargin=2.5cm,vmargin=2.5cm]{geometry}
> #+latex_header: \usepackage{lmodern}
> #+latex_header: \renewcommand{\rmdefault}{cmss}
>
> * Section
>
> #+begin_src latex :file flow-chart.pdf :packages '(("" "tikz")) :border 1em
>
> +++ TikZ code is here +++
>
> #+end_src
>
> *---( End File_2.org )---*
>
>
> In my first file, the entire font is latin modern (sans-serif). Header,
> title, author, *and* all TikZ diagram text.
>
> In the second, only the header is (if I export the whole thing), but not the
> text in my TikZ nodes. Why is the babel block ignoring the document font
> setting?
>
>
> Thanks,
> John
>
>
> On Sat, Oct 23, 2010 at 12:58 PM, John Hendy wrote:
>
>> Thanks, Eric F. Got the preview package going and this is *exactly* what I
>> would have been looking for.
>>
>> Eric S: yes, ImageMagick will take care of the rest :)
>>
>>
>> Thanks all!
>> John
>>
>> On Fri, Oct 22, 2010 at 6:11 PM, Eric S Fraga wrote:
>>
>>> On Fri, 22 Oct 2010 16:36:10 -0500, John Hendy
>>> wrote:
>>>
>>> > This is fantastic. Honestly, I had no idea that one could use LaTeX with
>>> > babel! This is just perfect. I was googling around for "export tikz pgf
>>> jpg"
>>> > and things like that with no luck. This will do perfectly.
>>>
>>> For completeness (and the mailing list archive), if you need to do
>>> this directly in latex, you will want to use the minimal document
>>> class and the preview package. Check out examples on the tikz
>>> examples web site [1]. The preview package is what babel uses.
>>>
>>> Footnotes:
>>> [1] http://www.texample.net/tikz/examples/
>>>
>>>
>>> --
>>> Eric S Fraga
>>> GnuPG: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D
>>>
>>>
>>
___
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] TikZ to separate file (babel?) possible?
On Mon, Oct 25, 2010 at 1:53 PM, Eric Schulte wrote:
> Hi John,
>
> In the case you describe I would export the *code* of the tikz latex
> block rather than the file resulting from evaluating the block.
>
>
Code = raw LaTeX/TikZ code? If so, I don't really care about that. i just
want the graphic.
> This is possible by adding the following header argument to the code
> block which will evaluate the latex block when the export target is not
> latex and will just export the code when the target is latex.
>
> :exports (if latexp "code" "results")
>
When trying C-c C-c after adding this, I get "Symbol's value as variable is
void: latexp" in the minibuffer.
Also, does this assist with my font issue? My main question is how to get
the document font to apply to my babel block. At present, the code shown
above for file_2.org is *perfect* in its behavior (I get a perfectly cropped
PDF of my diagram) except for it not being the right font. I just need to
know to set the font for the TikZ babel output.
Thanks for the assistance,
John
>
> Best -- Eric
>
> John Hendy writes:
>
> > Followup question. I have an existing diagram I had already exported to
> PDF
> > via LaTeX, taken a screenshot of, and used in a presentation. I tried the
> > same diagram with the new method and am having issues with the font. The
> > original org file is like this:
> >
> > *---( File_1.org -> embedded LaTeX )---*
> > #+latex_header: \usepackage{tikz}
> \usetikzlibrary{shapes,positioning,arrows}
> > #+latex_header: \usepackage[hmargin=2.5cm,vmargin=2.5cm]{geometry}
> > #+latex_header: \usepackage{lmodern}
> > #+latex_header: \renewcommand{\rmdefault}{cmss}
> >
> > * Section
> >
> > #+begin_latex
> >
> > +++ TikZ code is here +++
> >
> > #+end_latex
> >
> > *---( End File_1.org )---*
> >
> >
> > My file using this new method is like this:
> >
> > *---( File_2.org -> exports TikZ to separate PDF via babel/LaTeX )---*
> > #+latex_header: \usepackage{tikz}
> \usetikzlibrary{shapes,positioning,arrows}
> > #+latex_header: \usepackage[hmargin=2.5cm,vmargin=2.5cm]{geometry}
> > #+latex_header: \usepackage{lmodern}
> > #+latex_header: \renewcommand{\rmdefault}{cmss}
> >
> > * Section
> >
> > #+begin_src latex :file flow-chart.pdf :packages '(("" "tikz")) :border
> 1em
> >
> > +++ TikZ code is here +++
> >
> > #+end_src
> >
> > *---( End File_2.org )---*
> >
> >
> > In my first file, the entire font is latin modern (sans-serif). Header,
> > title, author, *and* all TikZ diagram text.
> >
> > In the second, only the header is (if I export the whole thing), but not
> the
> > text in my TikZ nodes. Why is the babel block ignoring the document font
> > setting?
> >
> >
> > Thanks,
> > John
> >
> >
> > On Sat, Oct 23, 2010 at 12:58 PM, John Hendy wrote:
> >
> >> Thanks, Eric F. Got the preview package going and this is *exactly* what
> I
> >> would have been looking for.
> >>
> >> Eric S: yes, ImageMagick will take care of the rest :)
> >>
> >>
> >> Thanks all!
> >> John
> >>
> >> On Fri, Oct 22, 2010 at 6:11 PM, Eric S Fraga
> wrote:
> >>
> >>> On Fri, 22 Oct 2010 16:36:10 -0500, John Hendy
> >>> wrote:
> >>>
> >>> > This is fantastic. Honestly, I had no idea that one could use LaTeX
> with
> >>> > babel! This is just perfect. I was googling around for "export tikz
> pgf
> >>> jpg"
> >>> > and things like that with no luck. This will do perfectly.
> >>>
> >>> For completeness (and the mailing list archive), if you need to do
> >>> this directly in latex, you will want to use the minimal document
> >>> class and the preview package. Check out examples on the tikz
> >>> examples web site [1]. The preview package is what babel uses.
> >>>
> >>> Footnotes:
> >>> [1] http://www.texample.net/tikz/examples/
> >>>
> >>>
> >>> --
> >>> Eric S Fraga
> >>> GnuPG: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D
> >>>
> >>>
> >>
>
___
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] TikZ to separate file (babel?) possible?
Followup question. I have an existing diagram I had already exported to PDF
via LaTeX, taken a screenshot of, and used in a presentation. I tried the
same diagram with the new method and am having issues with the font. The
original org file is like this:
*---( File_1.org -> embedded LaTeX )---*
#+latex_header: \usepackage{tikz} \usetikzlibrary{shapes,positioning,arrows}
#+latex_header: \usepackage[hmargin=2.5cm,vmargin=2.5cm]{geometry}
#+latex_header: \usepackage{lmodern}
#+latex_header: \renewcommand{\rmdefault}{cmss}
* Section
#+begin_latex
+++ TikZ code is here +++
#+end_latex
*---( End File_1.org )---*
My file using this new method is like this:
*---( File_2.org -> exports TikZ to separate PDF via babel/LaTeX )---*
#+latex_header: \usepackage{tikz} \usetikzlibrary{shapes,positioning,arrows}
#+latex_header: \usepackage[hmargin=2.5cm,vmargin=2.5cm]{geometry}
#+latex_header: \usepackage{lmodern}
#+latex_header: \renewcommand{\rmdefault}{cmss}
* Section
#+begin_src latex :file flow-chart.pdf :packages '(("" "tikz")) :border 1em
+++ TikZ code is here +++
#+end_src
*---( End File_2.org )---*
In my first file, the entire font is latin modern (sans-serif). Header,
title, author, *and* all TikZ diagram text.
In the second, only the header is (if I export the whole thing), but not the
text in my TikZ nodes. Why is the babel block ignoring the document font
setting?
Thanks,
John
On Sat, Oct 23, 2010 at 12:58 PM, John Hendy wrote:
> Thanks, Eric F. Got the preview package going and this is *exactly* what I
> would have been looking for.
>
> Eric S: yes, ImageMagick will take care of the rest :)
>
>
> Thanks all!
> John
>
> On Fri, Oct 22, 2010 at 6:11 PM, Eric S Fraga wrote:
>
>> On Fri, 22 Oct 2010 16:36:10 -0500, John Hendy
>> wrote:
>>
>> > This is fantastic. Honestly, I had no idea that one could use LaTeX with
>> > babel! This is just perfect. I was googling around for "export tikz pgf
>> jpg"
>> > and things like that with no luck. This will do perfectly.
>>
>> For completeness (and the mailing list archive), if you need to do
>> this directly in latex, you will want to use the minimal document
>> class and the preview package. Check out examples on the tikz
>> examples web site [1]. The preview package is what babel uses.
>>
>> Footnotes:
>> [1] http://www.texample.net/tikz/examples/
>>
>>
>> --
>> Eric S Fraga
>> GnuPG: 8F5C 279D 3907 E14A 5C29 570D C891 93D8 FFFC F67D
>>
>>
>
___
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: 7.01 & Xemacs 21.4.22: decompose-region is not known
> For people who cannot use git, the > snapshot release files, > corresponding to the latest git version, > are provided http://repo.or.cz/w/org-mode.git";>in the git > repository. Choose which snapshot you want, presumably > the first line in the "shortlog" section and click the > tar.gz or zip link at the right end. Looks like the below URL (with no modification whatsoever) always downloads the current tip of the tree. - http://repo.or.cz/w/org-mode.git/snapshot 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
[Orgmode] Re: timestamp with repeater interval
Eric S Fraga writes: > On Sun, 24 Oct 2010 17:11:34 +0200, Rainer Thiel wrote: >> >> http://orgmode.org/worg/org-faq.php#org-diary-class >> >> This would be exactly what I need -- if it really worked. It does not >> for me, probably because I haven't really understood how it is >> supposed to work. I should have expected that an entry like this: >> >> * TODO Class 10:00am-12:00am >> <%%(org-diary-class 10 18 2010 2 12 2011 3)> >> >> in one of my agenda files would make show up an agenda entry every >> Wednesday between Oct 18th, 2010 and Feb 12, 2011 in my agenda. But >> this is not the case, nothing shows up. What am I doing wrong? > > What is wrong (if you can call it that) is that the actual argument > list to the org-diary-class function depends on the settings of a > couple of variables: calendar-date-style and/or > european-calendar-style. As I have the former set to 'iso, in my case > I need to specify dates in the Y M D order: > > * TODO Class 10:00am-12:00am > <%%(org-diary-class 2010 10 18 2011 2 12 3)> > > You may need to do the same. > > I've cc-ed the org-mode list for others to be aware of this as well. Thanks for this clarification Eric. I updated the FAQ accordingly. Best, Matt ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
Hi,
here is the crontab line that Bastien uses to create the *latest.tar.gz.
0 0 * * * /home/cdominik/bin/tarzip-latest-org.sh >> /dev/null 2>&1
So in principle these should be produced daily.
So I I say I just made a fix, you cannot expect the change to be in
there
before tomorrow. And the crontab process may get hung up for a while,
and then
these files will be out of date.
Clearly, the superior way to get bleeding edge is git. No other process
we provide will ever be as reliable.
- Carsten
On Oct 25, 2010, at 6:48 PM, Nick Dokos wrote:
Giovanni Ridolfi wrote:
AFAIK, that's the latest *released* version:
releases. If you don't want to use git to get the latest
development
version, you can get a tarball of it (or any version really) from
Ok I was told differently on this list but ok.
Not only on this list, but also in the home-page !
I may be mistaken:
Yes, you are ;). Or, at least, you /should/ be wrong ;-)
But there are occasional hiccups and sometimes the tarballs
get out of sync, e.g. most recently at the end of September - see
http://thread.gmane.org/gmane.emacs.orgmode/31131
Yes :-(
Currently I see both org-latest.zip and org-latest.tar.gz dated
2010-10-16 01:00
That's strange. I downloaded org-latest.zip on the 20th October
and the commit was:
Org-mode version 7.01trans
commit-4cd56cfa7b93902544acb32848e36ee4004239a3
And it seemed to me that was the latest.
I don't know: I still see Oct 16 dates, but I don't have time to
investigate
carefully.
- and, btw, the top-level directory in both archives is
org-mode-web, which, according to Bastien in the above thread, is
wrong
and should be fixed.
Yes, I did some black magic to have a working org-latest.zip(org-
mode/blah-blah)
http://repo.or.cz/w/org-mode.git
Choose which snapshot you want and click the tar.gz or zip link at
the right end of the corresponding line
Uhhh nice! Thanks, Nick, I've learned something new today.
Thanks are due Jambunathan K. (iirc): he pointed that out a couple
of days ago. I'm just a conduit :-)
Bastien, would it be possible that the link in the homepage:
For people who cannot use git we provide zip
or tar.gz snapshot release
files updated each day
and corresponding to the latest git version.
will point to such page?
E.g.
For people who cannot use git, the
snapshot release files,
corresponding to the latest git version,
are provided http://repo.or.cz/w/org-mode.git";>in the git
repository. Choose which snapshot you want, presumably
the first line in the "shortlog" section and click the
tar.gz or zip link at the right end.
Pros: we will not have the problems of syncing
Cons: we will not have the file http://orgmode.org/org-latest.tar.gz
one can download directly, in a script...
but they have to use the browser.
Maybe keep org-latest.{tgz,zip} on orgmode.org, but add a mention
of the other method just in case there are syncing problems with the
tarballs.
Nick
___
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: 7.01 & Xemacs 21.4.22: decompose-region is not known
Giovanni Ridolfi wrote:
> >> > AFAIK, that's the latest *released* version:
> >> > releases. If you don't want to use git to get the latest development
> >> > version, you can get a tarball of it (or any version really) from
> >>
> >> Ok I was told differently on this list but ok.
>
> Not only on this list, but also in the home-page !
> >
> > I may be mistaken:
>
> Yes, you are ;). Or, at least, you /should/ be wrong ;-)
>
> > But there are occasional hiccups and sometimes the tarballs
> > get out of sync, e.g. most recently at the end of September - see
> >
> > http://thread.gmane.org/gmane.emacs.orgmode/31131
>
> Yes :-(
>
> >
> > Currently I see both org-latest.zip and org-latest.tar.gz dated
> > 2010-10-16 01:00
>
> That's strange. I downloaded org-latest.zip on the 20th October
> and the commit was:
> Org-mode version 7.01trans commit-4cd56cfa7b93902544acb32848e36ee4004239a3
> And it seemed to me that was the latest.
>
I don't know: I still see Oct 16 dates, but I don't have time to investigate
carefully.
> > - and, btw, the top-level directory in both archives is
> > org-mode-web, which, according to Bastien in the above thread, is wrong
> > and should be fixed.
>
> Yes, I did some black magic to have a working
> org-latest.zip(org-mode/blah-blah)
>
> >
> >>> http://repo.or.cz/w/org-mode.git
> >>> Choose which snapshot you want and click the tar.gz or zip link at
> >>> the right end of the corresponding line
>
> Uhhh nice! Thanks, Nick, I've learned something new today.
>
Thanks are due Jambunathan K. (iirc): he pointed that out a couple
of days ago. I'm just a conduit :-)
> Bastien, would it be possible that the link in the homepage:
>
> For people who cannot use git we provide zip
> or tar.gz snapshot release
> files updated each day
> and corresponding to the latest git version.
>
> will point to such page?
>
> E.g.
>
> For people who cannot use git, the
> snapshot release files,
> corresponding to the latest git version,
> are provided http://repo.or.cz/w/org-mode.git";>in the git
> repository. Choose which snapshot you want, presumably
> the first line in the "shortlog" section and click the
> tar.gz or zip link at the right end.
>
> Pros: we will not have the problems of syncing
>
> Cons: we will not have the file http://orgmode.org/org-latest.tar.gz
> one can download directly, in a script...
> but they have to use the browser.
>
Maybe keep org-latest.{tgz,zip} on orgmode.org, but add a mention
of the other method just in case there are syncing problems with the
tarballs.
Nick
___
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] struggling with simple indentation
Hello, > Rainer Stengele writes: > Dear all, > I am struggling with a simple indentation problem. > Having this: (1) > > * test > - indented > line > ^ > point at "^" and pressing TAB results in: > * test > - indented > line > > Having this: (2) > * test > - indented > - indented > line > ^ > point at "^" and pressing TAB results in: > * test > - indented > - indented > line > I cannot reproduce this. I always get case (1). Are you using development version ? 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] bug? - can't set effort from agenda
On Oct 25, 2010, at 4:29 PM, George Pearson wrote: On 25 Oct 2010 at 8:12, Carsten Dominik wrote: Hi George, why do you keep us guessing about your setup and file. Post your setup and an example file (as minimal as possible). You really do not give us *anything* to hook on to. I was really too harsh here, my apologies. However, what we still need is this: Make your file as small as possible so that it still repeats the bug. So like #+STARTUP: odd #+STARTUP: hidestars #+STARTUP: logdone #+SEQ_TODO: TODO NEXT PENDING | DONE(d!) CANCELLED(c@) #+TAGS: [redacted] * TODO some task * something with a date <2010-10-10 Thu> etc etc. Then: how do you construct the agenda view? Is it the daily agenda, or a TODO list. What does it look like? In which line is the cursor when you press "e"? Is that line linking to the first task in your org file, or the last? If I can reproduce a bug, I can fix it (well almost always...). - Carsten What else is needed? My second post contained the output of org-submit-bug-report and, in the section you quoted below, are the first lines of master.org (the file referred to in the error) up until the first headline. On Oct 24, 2010, at 11:27 PM, George Pearson wrote: On 24 Oct 2010 at 15:45, George Pearson wrote: The problem has now changed though, since I added this line to my two org files: #+PRIORITIES: A Z Z Now when I type "e" on a task in the agenda, and hit a number key to set the effort, I get the following: byte-code: Before first headline at position 223 in buffer master.org. Position 223 is the 1st character of the line following the priorities line. I have also seen position 203, which is the first character of the "priorities" line itself. Unfortunately, it would be a bit time- consuming for me to remove the "priorities" line, as I now have a number of tasks outside of the usual A-C range that would need to be adjusted first. Can do it if necessary though. I have removed the "#+PRIORITIES" line and replaced it with customized settings (i.e. in .emacs). Same problem setting effort in the agenda though: byte-code: Before first headline at position 203 in buffer master.org Position 203 is now the beginning of the blank line after my other #+ lines and before the first headline. Here are the lines preceding position 203: #+STARTUP: odd #+STARTUP: hidestars #+STARTUP: logdone #+SEQ_TODO: TODO NEXT PENDING | DONE(d!) CANCELLED(c@) #+TAGS: [redacted] Ideas? ___ 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 ___ 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-bbdb: anniversaries with unknown years
I will look into that. Thomas ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
Nick Dokos writes: > Uwe Brauer wrote: >> Nick Dokos writes: >> [ org-latest.zip ] >> > AFAIK, that's the latest *released* version: >> > releases. If you don't want to use git to get the latest development >> > version, you can get a tarball of it (or any version really) from >> >> Ok I was told differently on this list but ok. Not only on this list, but also in the home-page ! > > I may be mistaken: Yes, you are ;). Or, at least, you /should/ be wrong ;-) > But there are occasional hiccups and sometimes the tarballs > get out of sync, e.g. most recently at the end of September - see > > http://thread.gmane.org/gmane.emacs.orgmode/31131 Yes :-( > > Currently I see both org-latest.zip and org-latest.tar.gz dated > 2010-10-16 01:00 That's strange. I downloaded org-latest.zip on the 20th October and the commit was: Org-mode version 7.01trans commit-4cd56cfa7b93902544acb32848e36ee4004239a3 And it seemed to me that was the latest. > - and, btw, the top-level directory in both archives is > org-mode-web, which, according to Bastien in the above thread, is wrong > and should be fixed. Yes, I did some black magic to have a working org-latest.zip(org-mode/blah-blah) > >>> http://repo.or.cz/w/org-mode.git >>> Choose which snapshot you want and click the tar.gz or zip link at >>> the right end of the corresponding line Uhhh nice! Thanks, Nick, I've learned something new today. Bastien, would it be possible that the link in the homepage: For people who cannot use git we provide zip or tar.gz snapshot release files updated each day and corresponding to the latest git version. will point to such page? E.g. For people who cannot use git, the snapshot release files, corresponding to the latest git version, are provided http://repo.or.cz/w/org-mode.git";>in the git repository. Choose which snapshot you want, presumably the first line in the "shortlog" section and click the tar.gz or zip link at the right end. Pros: we will not have the problems of syncing Cons: we will not have the file http://orgmode.org/org-latest.tar.gz one can download directly, in a script... but they have to use the browser. 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
Re: [Orgmode] bug? - can't set effort from agenda
Another wrinkle on this, related to the priority change (A-Z). If I try to set the priority in the agenda by typing a comma, and then entering the (capital) priority letter at the prompt Priority A-Z, SPC to remove: then I get: org-agenda-priority: Wrong type argument: integer-or-marker-p, nil HOWEVER, repeating the comma entry and priority entry again is successful. ___ 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] Preserve math environments in title when exporting to LaTeX
Hi all,
This patch fixes the issue I originally described here:
http://article.gmane.org/gmane.emacs.orgmode/32281
It preserves math-mode delimiters (e.g. "$" and "\(") in the document
title when exporting to LaTeX. (That is, it prevents them from being
escaped, by running the title through org-export-preprocess-string,
which marks them with the org-protected property.) It should work
regardless of whether the title is pulled from a headline, from the text
before the first headline, or from an explicit #+TITLE declaration.
(This is my first time contributing a patch to a Free Software project
-- so please, let me know what you think!)
Best,
Richard
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 4fcbbb7..f97436c 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -727,13 +727,33 @@ when PUB-DIR is set, use this as the publishing directory."
(org-current-export-file buffer-file-name)
(title (or (and subtree-p (org-export-get-title-from-subtree))
(plist-get opt-plist :title)
- (and (not
- (plist-get opt-plist :skip-before-1st-heading))
- (org-export-grab-title-from-buffer))
+ (unless (plist-get opt-plist :skip-before-1st-heading)
+ (let ((pt (org-export-grab-title-from-buffer)))
+ (remove-text-properties 0 (length pt)
+ '(:org-license-to-kill t) pt)
+ pt))
(and buffer-file-name
(file-name-sans-extension
(file-name-nondirectory buffer-file-name)))
"No Title"))
+ ; Preprocessing preserves math environments in title
+ (title
+ (and title (string-match "\\S-" title)
+ (org-export-preprocess-string
+ title
+ :emph-multiline t
+ :for-LaTeX t
+ :comments nil
+ :tags (plist-get opt-plist :tags)
+ :priority (plist-get opt-plist :priority)
+ :footnotes (plist-get opt-plist :footnotes)
+ :drawers (plist-get opt-plist :drawers)
+ :timestamps (plist-get opt-plist :timestamps)
+ :todo-keywords (plist-get opt-plist :todo-keywords)
+ :add-text nil
+ :select-tags nil
+ :exclude-tags nil
+ :LaTeX-fragments nil)))
(filename
(and (not to-buffer)
(concat
___
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] Multi-line headline
All, Is it possible to have multi-line headlines? If so, how do I set it up? Thanks for the help! Bill -- Bill Zingler Zingler & Associates, Inc. (443) 822-4857 ___ 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: Aligning Columns in HTML Export Tables
Carsten Dominik writes:
> OK, I will use class. I could make a special case for the docbook
> exporter..
+1
>> Having to set /anything/ on each cell just to align a column is not optimal
>> either, but since some browsers don't honor colgroups, it's the most robust
>> way.
How refer to all right-aligned `td' elements in a certain tables without
some special attribute anyway. `class' preferred since this is CSS2 and
will work in commen browsers. I'm not sure how which browsers will
understand the selector `table#special td[align="right"] {...}'.
BTW: Org mode's exports to XHTML, not HTML 4.01 or HTML 5 (which is a
proposal, not a "standard" or recommendation yet). Still,
'' is valid XHTML, too.
___
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] quotes inside code markup: bug?
I'm finding that, when I export as Latex or html, quoted strings don't get translated properly. I.e., a bit of text like ="foo"= will be translated literally, instead of turning into a code marked-up string. I am attaching a simple document of this type, and the results of export to latex. Export to HTML seems to give the same behavior. This seems like something that would happen to many people, so I wonder if it's a bug or if I'm failing to understand something. * Here's a headline with a quote in monospace ** A ="string"= in code sample-quote-bug.tex Description: TeX document ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
Nick Dokos wrote: > > Overall, I think getting snapshot tarballs like this is more reliable; > but using git is much more efficient, both in terms of server resources > and in terms of efficient use of your time: if you are uploading a I meant: downloading > tarball more often than every month, you owe it to yourself to use git. Why is it so difficult to say what I mean? Nick ___ 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? - can't set effort from agenda
Here's a new copy from org-submit-bug-report. It is slightly different
from before, as I changed to customizied low and default priority
settings since the earlier post.
Emacs : GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600)
of 2010-05-08 on G41R2F1
Package: Org-mode version 7.01h
current state:
==
(setq
org-empty-line-terminates-plain-lists t
org-remember-interactive-interface 'outline
org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-
vars)
org-default-priority 90
org-agenda-custom-commands '(("i" "Do promptly" tags-todo
"Week|Schedule|Important"
((org-agenda-skip-function
(quote
(org-agenda-skip-entry-if (quote scheduled)
(quote deadline))
)
)
)
)
("c" "Weekly schedule"
((agenda "" ((org-agenda-ndays 1)))
(agenda ""
((org-agenda-ndays 7)
(org-agenda-repeating-timestamp-show-all t)
(org-agenda-skip-function
(quote
(org-agenda-skip-entry-if (quote deadline)
(quote scheduled))
)
)
)
)
)
((org-agenda-compact-blocks t)))
)
org-agenda-files '("~/orgfiles/master.org" "~/orgfiles/recurring.org")
org-agenda-window-setup 'other-frame
org-metaup-hook '(org-babel-load-in-session-maybe)
org-capture-templates '(("t" "Todo" entry
(file+headline "/home/george/orgfiles/master.org" "")
"* TODO %?\n %u\n" :prepend t)
)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-agenda-todo-ignore-scheduled t
org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup)
org-export-latex-format-toc-function 'org-export-latex-format-toc-
default
org-agenda-skip-scheduled-if-done t
org-log-redeadline 'time
org-export-preprocess-hook '(org-export-blocks-preprocess)
org-tab-first-hook '(org-hide-block-toggle-maybe
org-babel-hide-result-toggle-maybe)
org-src-mode-hook '(org-src-mode-configure-edit-buffer)
org-confirm-shell-link-function 'yes-or-no-p
org-export-first-hook '(org-beamer-initialize-open-trackers)
org-use-tag-inheritance nil
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-default-notes-file "/home/george/orgfiles/master.org"
org-directory "/home/george/orgfiles/"
org-log-reschedule 'time
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-
drawers
org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
org-export-preprocess-before-normalizing-links-hook '(org-remove-file-
link-modifiers)
org-mode-hook '(#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook org-show-block-all
append local]
5]
#[nil "\300\301\302\303\304$\207"
[org-add-hook change-major-mode-hook
org-babel-show-result-all append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
turn-on-font-lock)
org-agenda-ndays 1
org-global-properties '(("Effort_ALL" .
"0 0:05 0:10 0:15 0:20 0:30 0:45 1:00 1:30 2:00")
)
org-ctrl-c-ctrl-c-hook '(org-babel-lob-execute-maybe org-babel-hash-at-
point
org-babel-execute-src-block-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-mode-hook '((lambda nil (hl-line-mode 1)))
org-agenda-start-on-weekday nil
org-export-interblocks '((lob org-babel-exp-lob-one-liners)
(src org-babel-exp-inline-src-blocks))
org-reverse-note-order t
org-occur-hook '(org-first-headline-recenter)
org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-
select-beamer-code)
org-agenda-todo-ignore-deadlines t
org-columns-default-format "%CATEGORY %35ITEM %Effort{:} %PRIORITY
%ALLTAGS"
org-remember-templates '(("Todo" 116 "* TODO %?\n %u\n" nil nil nil))
org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-
toc
org-beamer-auto-fragile-frames
org-beamer-place-default-actions-for-lists)
org-lowest-priority 90
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-export-blocks '((src org
[Orgmode] Re: Can I customize the faces in the agenda deoendant on the priority of the entries? RESOLVED
Am 25.10.2010 15:10, schrieb Rainer Stengele: > Hi all, > > Can I customize the faces in the agenda dependant on the priority of the > entries? > > - Rainer > > > ___ > 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 > Sorry for the noise, I found it: "Org Priority Faces" under "Groups: Org TODO Org Faces" - Rainer ___ 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? - can't set effort from agenda
On 25 Oct 2010 at 8:12, Carsten Dominik wrote: > Hi George, > > why do you keep us guessing about your setup and file. Post > your setup and an example file (as minimal as possible). > You really do not give us *anything* to hook on to. What else is needed? My second post contained the output of org-submit-bug-report and, in the section you quoted below, are the first lines of master.org (the file referred to in the error) up until the first headline. > On Oct 24, 2010, at 11:27 PM, George Pearson wrote: > > > On 24 Oct 2010 at 15:45, George Pearson wrote: > > > >> The problem has now changed though, since I added this line to my two > >> org files: > >> > >> #+PRIORITIES: A Z Z > >> > >> Now when I type "e" on a task in the agenda, and hit a number key to > >> set the effort, I get the following: > >> > >> byte-code: Before first headline at position 223 in buffer > >> master.org. > >> > >> Position 223 is the 1st character of the line following the > >> priorities > >> line. I have also seen position 203, which is the first character of > >> the "priorities" line itself. Unfortunately, it would be a bit time- > >> consuming for me to remove the "priorities" line, as I now have a > >> number of tasks outside of the usual A-C range that would need to be > >> adjusted first. Can do it if necessary though. > > > > I have removed the "#+PRIORITIES" line and replaced it with customized > > settings (i.e. in .emacs). Same problem setting effort in the agenda > > though: > > > > byte-code: Before first headline at position 203 in buffer master.org > > > > Position 203 is now the beginning of the blank line after my other #+ > > lines and before the first headline. Here are the lines preceding > > position 203: > > > > #+STARTUP: odd > > #+STARTUP: hidestars > > #+STARTUP: logdone > > #+SEQ_TODO: TODO NEXT PENDING | DONE(d!) CANCELLED(c@) > > #+TAGS: [redacted] > > > > > > Ideas? > > > > ___ > > 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] [org-babel] Using the power of ESS inside an R source code block
Hi Bernd, It seems that you have already found the best solution in the indirect edit buffers (by calling C-c ' from inside of a code block). I would only add that in the email you mentioned below, I was specifically talking about syntax highlighting of R code in Org-mode buffers, which at the time I believed was not possible. It would seem I was wrong, as such syntax highlighting is now implemented in recent versions of Org-mode through setting the `org-src-fontify-natively' variable. Hope you enjoy using Org-mode with Ess. Best -- Eric Bernd Weiss writes: > Am 24.10.2010 05:44, schrieb Bernd Weiss: >> Dear all, >> >> Yesterday, I spent some time (re-)discovering the power of org-babel >> and R. Everything works well but there is one issue that I find >> somewhat annoying (I apologise if this word is too rude). As a >> long-time ESS user I wish that I could use things like ESS syntax >> highlighting, indentation or some keybindings (e.g. for "<-") inside >> an R source code block. However, with respect to an e-mail from Eric >> Schulte >> >> http://www.mail-archive.com/emacs-orgmode@gnu.org/msg22301.html >> >> (or this one: >> https://stat.ethz.ch/pipermail/ess-help/2009-September/005544.html ) >> >> this seems to be a feature wich is hard to realise inside org-babel. >> Is this (still) correct? Or is it a problem with my >> installation/initialisation of org-mode/org-babel?[1] > > > Ok, one workaround are indirect buffers, right? This blog post is > really helpful (see "A note about syntax highlighting in Emacs") > > http://blogisticreflections.wordpress.com/2010/05/23/introduction-to-using-r-with-org-babel-part-1/ > > Bernd > > ___ > 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] Re: 7.01 & Xemacs 21.4.22: decompose-region is not known
Uwe Brauer wrote: > >> Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose-region is not > >> known; Nick Dokos adds: > >> Uwe Brauer wrote: >>> And in this package I can't see your change, >>> org-freemind is the same as in the package of yesterday >>> > >> AFAIK, that's the latest *released* version: it's only updated for >> releases. If you don't want to use git to get the latest development >> version, you can get a tarball of it (or any version really) from > > Ok I was told differently on this list but ok. I may be mistaken: I use git to update so I don't keep track of the tarballs. But there are occasional hiccups and sometimes the tarballs get out of sync, e.g. most recently at the end of September - see http://thread.gmane.org/gmane.emacs.orgmode/31131 Currently I see both org-latest.zip and org-latest.tar.gz dated 2010-10-16 01:00 - and, btw, the top-level directory in both archives is org-mode-web, which, according to Bastien in the above thread, is wrong and should be fixed. >> http://repo.or.cz/w/org-mode.git > >> Choose which snapshot you want and click the tar.gz or zip link at >> the right end of the corresponding line (although I just pulled and Overall, I think getting snapshot tarballs like this is more reliable; but using git is much more efficient, both in terms of server resources and in terms of efficient use of your time: if you are uploading a tarball more often than every month, you owe it to yourself to use git. Nick ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
>> Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose-region is not >> known; Carsten Dominik adds: > Testing under both Emacs and XEmacs would be highly appreciated. Ok I downloaded it, - compilation now is fine! (Xemacs 21.4.22 Mule with the newest xemacs-base pkg). Maybe that should be added in the documentation! - org also seems to work as far as I can tell. thanks Uwe ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
>> Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose-region is not >> known; Nick Dokos adds: > Uwe Brauer wrote: >> And in this package I can't see your change, >> org-freemind is the same as in the package of yesterday >> > AFAIK, that's the latest *released* version: it's only updated for > releases. If you don't want to use git to get the latest development > version, you can get a tarball of it (or any version really) from Ok I was told differently on this list but ok. > http://repo.or.cz/w/org-mode.git > Choose which snapshot you want and click the tar.gz or zip link at > the right end of the corresponding line (although I just pulled and cool, that works. Uwe ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
Uwe Brauer wrote: > Well I just downloaded > http://orgmode.org/org-latest.tar.gz > > > And in this package I can't see your change, > org-freemind is the same as in the package of yesterday > AFAIK, that's the latest *released* version: it's only updated for releases. If you don't want to use git to get the latest development version, you can get a tarball of it (or any version really) from http://repo.or.cz/w/org-mode.git Choose which snapshot you want and click the tar.gz or zip link at the right end of the corresponding line (although I just pulled and I don't see any updates to org-freemind.el - in particular, it still requires rx - maybe Carsten forgot to push?) Nick ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
I pushed now, sorry about that. - Carsten On Oct 25, 2010, at 3:21 PM, Nick Dokos wrote: Uwe Brauer wrote: Well I just downloaded http://orgmode.org/org-latest.tar.gz And in this package I can't see your change, org-freemind is the same as in the package of yesterday AFAIK, that's the latest *released* version: it's only updated for releases. If you don't want to use git to get the latest development version, you can get a tarball of it (or any version really) from http://repo.or.cz/w/org-mode.git Choose which snapshot you want and click the tar.gz or zip link at the right end of the corresponding line (although I just pulled and I don't see any updates to org-freemind.el - in particular, it still requires rx - maybe Carsten forgot to push?) Nick - Carsten ___ 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: Aligning Columns in HTML Export Tables
On Oct 25, 2010, at 3:13 PM, Christian Moe wrote:
On 10/25/10 11:08 AM, Carsten Dominik wrote:
On Oct 25, 2010, at 10:51 AM, Christian Moe wrote:
On 10/25/10 6:36 AM, Baoqiu Cui wrote:
I am wondering if there
is any special reason to use "class" instead of "align". If not,
can we
change the elisp code to use "align"?
I believe the "align" attribute is slated for obsoletion in HTML5,
on the grounds that it's better handled by CSS.
http://www.w3.org/TR/html5/obsolete.html
It's a reason to go with "class" instead. Not a compelling one,
perhaps.
My only strong opinion on this is that I absolutely agree with the
choice not to set the "style" attribute locally on each table cell.
Hmm, butwe do now set the class in each cell. Is that any better?
- Carsten
It's a subtle difference, and every way works, so I don't want to
waste more of your time.
#+begin_rant
But yes, I think it /is/ better, for the same reason Sebastian
requested it: Setting class is the preferred way to make all cells
of that class custom-styleable by changing a single line in the
stylesheet.
As I pointed out below, though, it's not the only way. CSS lets you
do the same, nearly as easily, if "align" is used instead of "class"
as Baoqiu Cui suggested; "class" is more future-proof (HTML5),
"align" more compact (the default is already defined).
(Heck, come to think of it, Sebastian could have monospaced the left-
aligned column in his example even when Org set "style" on each
cell, using a selector like:
: td[style="text-align: left;"] { font-family: monospace; }
-- but that, I think, would be perverse.)
Over-use of the style attribute to set styles locally works against
the purpose of CSS. The local style attribute should be used for
exceptions; general rules should be handled at a higher level of the
cascade.
Having to set /anything/ on each cell just to align a column is not
optimal either, but since some browsers don't honor colgroups, it's
the most robust way.
#+end_rant
Christian
But Sebastian Rose's request that prompted it, /could/ equally well
be addressed with the "align" attribute:
How about this (line-wrapped for readability):
1
bar
text
instead of
1
bar
text
??
Combined with the ways to add IDs and classes to tables, we could
then style the
columns better.
I would like to set this for right aligned tags as default:
td.right { font-family:monospace;text-align:right; }
Using the "align" attribute as follows,
1
bar
text
Sebastian could achieve the same with CSS like
td[align="right"] { font-family: monospace;}
In the same way one could even use CSS to override the alignment
specified by the "align" attribute, if for whatever reason this
seemed like a good idea...
One slight advantage of the "align" attribute over "class" is that
it doesn't require the default style to contain the extra verbiage
Carsten mentioned:
I have now in the default style:
td, th { vertical-align: top; }
th.right { text-align:right; }
th.left { text-align:left; }
th.center { text-align:center; }
td.right { text-align:right; }
td.left { text-align:left; }
td.center { text-align:center; }
Is there a way to write this more compactly?
Yours,
Christian
- Carsten
Actually, I have one more question:
The exporter does now (in addition to setting classes for individual
fields)
align="center" />
Should this be classes instead of align attributes as well?
Thanks!
- Carsten
- Carsten
___
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: Aligning Columns in HTML Export Tables
On Oct 25, 2010, at 3:13 PM, Christian Moe wrote:
On 10/25/10 11:08 AM, Carsten Dominik wrote:
On Oct 25, 2010, at 10:51 AM, Christian Moe wrote:
On 10/25/10 6:36 AM, Baoqiu Cui wrote:
I am wondering if there
is any special reason to use "class" instead of "align". If not,
can we
change the elisp code to use "align"?
I believe the "align" attribute is slated for obsoletion in HTML5,
on the grounds that it's better handled by CSS.
http://www.w3.org/TR/html5/obsolete.html
It's a reason to go with "class" instead. Not a compelling one,
perhaps.
My only strong opinion on this is that I absolutely agree with the
choice not to set the "style" attribute locally on each table cell.
Hmm, butwe do now set the class in each cell. Is that any better?
- Carsten
It's a subtle difference, and every way works, so I don't want to
waste more of your time.
#+begin_rant
But yes, I think it /is/ better, for the same reason Sebastian
requested it: Setting class is the preferred way to make all cells
of that class custom-styleable by changing a single line in the
stylesheet.
As I pointed out below, though, it's not the only way. CSS lets you
do the same, nearly as easily, if "align" is used instead of "class"
as Baoqiu Cui suggested; "class" is more future-proof (HTML5),
"align" more compact (the default is already defined).
(Heck, come to think of it, Sebastian could have monospaced the left-
aligned column in his example even when Org set "style" on each
cell, using a selector like:
: td[style="text-align: left;"] { font-family: monospace; }
-- but that, I think, would be perverse.)
Over-use of the style attribute to set styles locally works against
the purpose of CSS. The local style attribute should be used for
exceptions; general rules should be handled at a higher level of the
cascade.
I agree. But in the context of text alignment in tables, not all
browsers support
styles specified for entire columns. I think it is ridiculous to have
to specify the alignment (or a class) for each field, but the browser
realities force me.
OK, I will use class. I could make a special case for the docbook
exporter..
Having to set /anything/ on each cell just to align a column is not
optimal either, but since some browsers don't honor colgroups, it's
the most robust way.
:-) Just what I think. OK, a class it is.
- Carsten
td.right { font-family:monospace;text-align:right; }
Using the "align" attribute as follows,
1
bar
text
Sebastian could achieve the same with CSS like
td[align="right"] { font-family: monospace;}
In the same way one could even use CSS to override the alignment
specified by the "align" attribute, if for whatever reason this
seemed like a good idea...
One slight advantage of the "align" attribute over "class" is that
it doesn't require the default style to contain the extra verbiage
Carsten mentioned:
I have now in the default style:
td, th { vertical-align: top; }
th.right { text-align:right; }
th.left { text-align:left; }
th.center { text-align:center; }
td.right { text-align:right; }
td.left { text-align:left; }
td.center { text-align:center; }
Is there a way to write this more compactly?
Yours,
Christian
- Carsten
- Carsten
___
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: Aligning Columns in HTML Export Tables
On 10/25/10 11:08 AM, Carsten Dominik wrote:
On Oct 25, 2010, at 10:51 AM, Christian Moe wrote:
On 10/25/10 6:36 AM, Baoqiu Cui wrote:
I am wondering if there
is any special reason to use "class" instead of "align". If not,
can we
change the elisp code to use "align"?
I believe the "align" attribute is slated for obsoletion in HTML5,
on the grounds that it's better handled by CSS.
http://www.w3.org/TR/html5/obsolete.html
It's a reason to go with "class" instead. Not a compelling one,
perhaps.
My only strong opinion on this is that I absolutely agree with the
choice not to set the "style" attribute locally on each table cell.
Hmm, butwe do now set the class in each cell. Is that any better?
- Carsten
It's a subtle difference, and every way works, so I don't want to
waste more of your time.
#+begin_rant
But yes, I think it /is/ better, for the same reason Sebastian
requested it: Setting class is the preferred way to make all cells of
that class custom-styleable by changing a single line in the stylesheet.
As I pointed out below, though, it's not the only way. CSS lets you do
the same, nearly as easily, if "align" is used instead of "class" as
Baoqiu Cui suggested; "class" is more future-proof (HTML5), "align"
more compact (the default is already defined).
(Heck, come to think of it, Sebastian could have monospaced the
left-aligned column in his example even when Org set "style" on each
cell, using a selector like:
: td[style="text-align: left;"] { font-family: monospace; }
-- but that, I think, would be perverse.)
Over-use of the style attribute to set styles locally works against
the purpose of CSS. The local style attribute should be used for
exceptions; general rules should be handled at a higher level of the
cascade.
Having to set /anything/ on each cell just to align a column is not
optimal either, but since some browsers don't honor colgroups, it's
the most robust way.
#+end_rant
Christian
But Sebastian Rose's request that prompted it, /could/ equally well
be addressed with the "align" attribute:
How about this (line-wrapped for readability):
1
bar
text
instead of
1
bar
text
??
Combined with the ways to add IDs and classes to tables, we could
then style the
columns better.
I would like to set this for right aligned tags as default:
td.right { font-family:monospace;text-align:right; }
Using the "align" attribute as follows,
1
bar
text
Sebastian could achieve the same with CSS like
td[align="right"] { font-family: monospace;}
In the same way one could even use CSS to override the alignment
specified by the "align" attribute, if for whatever reason this
seemed like a good idea...
One slight advantage of the "align" attribute over "class" is that
it doesn't require the default style to contain the extra verbiage
Carsten mentioned:
I have now in the default style:
td, th { vertical-align: top; }
th.right { text-align:right; }
th.left { text-align:left; }
th.center { text-align:center; }
td.right { text-align:right; }
td.left { text-align:left; }
td.center { text-align:center; }
Is there a way to write this more compactly?
Yours,
Christian
- Carsten
___
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] Can I customize the faces in the agenda deoendant on the priority of the entries?
Hi all, Can I customize the faces in the agenda dependant on the priority of the entries? - Rainer ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
>> Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose-region is not
>> known; Carsten Dominik adds:
> On Oct 25, 2010, at 12:48 PM, Uwe Brauer wrote:
Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose-
>>
>> But couldn't you just add
>>
>> (if (featurep 'emacs)
>> (require 'rx))
>>
>> For the time being so that org could be used under Xemacs
>> (and you would not receive the corresponding complains :-D )
> I have just updated org-freemind in the repository in a
> way that will hopefully be compatible with Emacs and
> XEmacs. In particular, I got rid of the rx dependency.
Well I just downloaded
http://orgmode.org/org-latest.tar.gz
And in this package I can't see your change,
org-freemind is the same as in the package of yesterday
Uwe
___
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] struggling with simple indentation
Dear all, I am struggling with a simple indentation problem. Having this: (1) * test - indented line ^ point at "^" and pressing TAB results in: * test - indented line ^ Having this: (2) * test - indented - indented line ^ point at "^" and pressing TAB results in: * test - indented - indented line ^ I want to consistently indent lines like in case (1). Why does org not indent in case (2) How can I change this behavior? Is it a config issue? I could not find a variable where I could adapt the indentation behavior. Best Rainer ___ 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-capture adds newline(s) when it should not
On Oct 25, 2010, at 1:58 PM, Noorul Islam wrote:
On Mon, Oct 25, 2010 at 4:48 PM, Noorul Islam
wrote:
On Mon, Oct 25, 2010 at 4:21 PM, Marcel van der Boom > wrote:
Hi all,
I'm in the process of migrating from org-remember to org-capture.
Pretty easy going so far, but it seems org-capture adds newlines,
which
I think it should not do.
My (test) capture-template is:
(("t" "Todo" entry
(file "~/.outlet/GTD.org")
"* TODO %?" :prepend t :empty-lines 0)
with the intention of inserting the captured task on the
first line of the file ~/.outlet/GTD.org. What happens when I
capture
an task is this:
* TODO Captured task
Both before and after the task is a newline. Also, when capturing
and
cancelling the capture with C-c C-k the newlines remain whereas the
task is removed.
I'm using the latest git version with emacs 24.0.50.1 on Ubuntu
10.10
Am I doing something wrong or is this a bug?
I do not have Emacs 24 as of now.
With the same template I am not able to re-create this on
Org-mode version 7.01trans (release_7.01h.832.gf7094)
GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
of 2010-01-30 on noorul
On emacs 24 I am able to re-create the problem Marcel reported.
I find that puzzling. What might have changed in Emacs 24 to cause
such differences? I do not use Emacs 24 on a day-to-day basis yet.
- Carsten
Thanks and Regards
Noorul
___
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
- Carsten
___
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: [PATCH] quote the real csv separator
Carsten Dominik writes: > On Oct 25, 2010, at 10:45 AM, Łukasz Stelmach wrote: >> OR, if you think that CSV should stay as it is then I >> suggest such a rewrite: >> >> (defun orgtbl-to-csv (table params) >> (orgtbl-to-generic table (org-combine-plists >>params >> '(:sep "," :fmt org-quote-csv-field >> >> to make CSV :sep and and :fmt mandatory (that's how this all have >> starded). > > I don't understand, here is the current definition of orgtbl-to-csv: > > (defun orgtbl-to-csv (table params) > "Convert the orgtbl-mode table to CSV material. > This does take care of the proper quoting of fields with comma or > quotes." > (orgtbl-to-generic table (org-combine-plists > '(:sep "," :fmt org-quote-csv-field) > params))) > > so these are mandatory. I guess I do not understand what you are > saying. OK, try to eval these: (let ((params '(:sep "|"))) (org-combine-plists '(:sep "," :fmt org-quote-csv-field) params)) (let ((params '(:sep "|"))) (org-combine-plists params '(:sep "," :fmt org-quote-csv-field))) The latter prevents :sep from being overriden. -- Miłego dnia, Łukasz Stelmach ___ 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-capture adds newline(s) when it should not
On Mon, Oct 25, 2010 at 4:48 PM, Noorul Islam wrote:
> On Mon, Oct 25, 2010 at 4:21 PM, Marcel van der Boom wrote:
>> Hi all,
>>
>> I'm in the process of migrating from org-remember to org-capture.
>> Pretty easy going so far, but it seems org-capture adds newlines, which
>> I think it should not do.
>>
>> My (test) capture-template is:
>>
>> (("t" "Todo" entry
>> (file "~/.outlet/GTD.org")
>> "* TODO %?" :prepend t :empty-lines 0)
>>
>> with the intention of inserting the captured task on the
>> first line of the file ~/.outlet/GTD.org. What happens when I capture
>> an task is this:
>>
>>
>>
>> * TODO Captured task
>>
>>
>>
>>
>> Both before and after the task is a newline. Also, when capturing and
>> cancelling the capture with C-c C-k the newlines remain whereas the
>> task is removed.
>>
>> I'm using the latest git version with emacs 24.0.50.1 on Ubuntu 10.10
>>
>> Am I doing something wrong or is this a bug?
>>
>
> I do not have Emacs 24 as of now.
>
> With the same template I am not able to re-create this on
>
> Org-mode version 7.01trans (release_7.01h.832.gf7094)
> GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
> of 2010-01-30 on noorul
>
On emacs 24 I am able to re-create the problem Marcel reported.
Thanks and Regards
Noorul
___
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] Sitemap publish with chronological ordering
Here's a patch that add an option to sort files in the sitemap chronologically. A "#+DATE" driven sorting is still missing IMO. --8<---cut here---start->8--- diff --git a/lisp/org-publish.el b/lisp/org-publish.el index c66cd29..74afa87 100644 --- a/lisp/org-publish.el +++ b/lisp/org-publish.el @@ -186,8 +186,9 @@ sitemap of files or summary page for a given project. Set this to `first' (default) or `last' to display folders first or last, respectively. Any other value will mix files and folders. - :sitemap-alphabetically The site map is normally sorted alphabetically. - Set this explicitly to nil to turn off sorting. + :sitemap-sort-files The site map is normally sorted alphabetically. + You can change this behaviour setting this to + `chronologically', `anti-chronologically' or nil. :sitemap-ignore-case Should sorting be case-sensitive? Default nil. The following properties control the creation of a concept index. @@ -233,13 +234,18 @@ Any changes made by this hook will be saved." :group 'org-publish :type 'hook) -(defcustom org-publish-sitemap-sort-alphabetically t - "Should sitemaps be sorted alphabetically by default? +(defcustom org-publish-sitemap-sort-files 'alphabetically + "How sitemaps files should be sorted by default? +Possible values are `alphabetically', `chronologically', `anti-chronologically' and nil. +If `alphabetically', files will be sorted alphabetically. +If `chronologically', files will be sorted with older modification time first. +If `anti-chronologically', files will be sorted with newer modification time first. +nil won't sort files. You can overwrite this default per project in your -`org-publish-project-alist', using `:sitemap-alphabetically'." +`org-publish-project-alist', using `:sitemap-sort-files'." :group 'org-publish - :type 'boolean) + :type 'symbol) (defcustom org-publish-sitemap-sort-folders 'first "A symbol, denoting if folders are sorted first in sitemaps. @@ -360,30 +366,37 @@ This splices all the components into the list." (nreverse (org-publish-delete-dups (delq nil rtn) -(defvar sitemap-alphabetically) +(defvar sitemap-sort-files) (defvar sitemap-sort-folders) (defvar sitemap-ignore-case) (defvar sitemap-requested) (defun org-publish-compare-directory-files (a b) - "Predicate for `sort', that sorts folders-first/last and alphabetically." + "Predicate for `sort', that sorts folders and files for sitemap." (let ((retval t)) -(when (or sitemap-alphabetically sitemap-sort-folders) - ;; First we sort alphabetically: - (when sitemap-alphabetically -(let* ((adir (file-directory-p a)) - (aorg (and (string-match "\\.org$" a) (not adir))) - (bdir (file-directory-p b)) - (borg (and (string-match "\\.org$" b) (not bdir))) - (A (if aorg - (concat (file-name-directory a) - (org-publish-find-title a)) a)) - (B (if borg - (concat (file-name-directory b) - (org-publish-find-title b)) b))) - (setq retval (if sitemap-ignore-case - (not (string-lessp (upcase B) (upcase A))) -(not (string-lessp B A)) - +(when (or sitemap-sort-files sitemap-sort-folders) + ;; First we sort files: + (when sitemap-sort-files + (cond ((equal sitemap-sort-files 'alphabetically) + (let* ((adir (file-directory-p a)) + (aorg (and (string-match "\\.org$" a) (not adir))) + (bdir (file-directory-p b)) + (borg (and (string-match "\\.org$" b) (not bdir))) + (A (if aorg +(concat (file-name-directory a) +(org-publish-find-title a)) a)) + (B (if borg +(concat (file-name-directory b) +(org-publish-find-title b)) b))) +(setq retval (if sitemap-ignore-case + (not (string-lessp (upcase B) (upcase A))) + (not (string-lessp B A)) + ((or (equal sitemap-sort-files 'chronologically) +(equal sitemap-sort-files 'anti-chronologically)) +(let ((A (org-publish-find-date a)) + (B (org-publish-find-date b))) + (setq retval (if (equal sitemap-sort-files 'chronologically) + (<= A B) + (>= A B))) ;; Directory-wise wins: (when sitemap-sort-folders ;; a is directory, b not: @@ -438,10 +451,10 @@ matching filenam
Re: [Orgmode] Re: Orgmode meetup at FOSDEM, February 2011. Who would come?
Richard Moreland writes: Hi, > On Oct 24, 2010, at 12:53 AM, Puneeth wrote: > >> The FOSDEM site says, >> 2010-10-23: Acceptance notification of devrooms >> >> Wondering if you have any news on this. > > Nothing yet, unfortunately. I'll keep the list posted as soon as I hear > anything. >From fosdem's website: On Mon, 10/25/2010 - 00:24 Devroom assignment still in the make This is just a short notice that we are still working on the devroom assignment for FOSDEM 2011. We received 36 valid proposals, but have only 24 'devroom days' to distribute over the weekend (not counting the distribution miniconf). Many proposals are also true collaborative proposals, making the decision even harder. Please bare with us for one or two more days, while we finalize the devroom allocation. -- so let's wait utill wednesday 27 ;-) 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
Re: [Orgmode] capture initial "level" and refile of capture buffer
Hi Noorul, could you please make a more detailed test case of this but, with an example files (capture target and refile target files) and step by step instructions. I am not sure I understand what exactly you are doing. Thanks. - Carsten On Oct 23, 2010, at 10:42 AM, Noorul Islam wrote: On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley wrote: What determines the level of a new capture element? e.g I just created one and it started at "". feature request : when I added some sub elements to a capture buffer e.g * my new capture ** sub point *** sub sub point 1 *** sub sub point 2 and hit C-c C-w to refile, it only refiled the sub element (where cursor was) and then lost the rest. I would like to suggest that refile from the capture buffer should refile the entire buffer and not only the "current nested org item". Or am I missing something in my setup? On my box I have this observation. If I have something like this in my capture buffer * TODO Test * my new capture ** sub point *** sub sub point 1 *** sub sub point 2 and if I press C-c C-w at the last line (*** sub sub point 2) and refile it to refile.org then what I get in refile.org is this * TODO Test * my new capture ** sub point *** sub sub point 1 * sub sub point 2 The last one's level got changed. I have latest pull from git repo. Org-mode version 7.01trans (release_7.01h.833.g21ad0) GNU Emacs 23.2.2 (i686-pc-linux-gnu) of 2010-06-08 on sajida Thanks and Regards Noorul ___ 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 - Carsten ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
On Oct 25, 2010, at 12:48 PM, Uwe Brauer wrote: Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose- region is not known; Carsten Dominik adds: (if (featurep 'emacs) (require 'rx)) To org-freemind otherwise it *does not* compile Yes. I still need to et to fixing org-freemind.el. Unfortunately, the day has not enough hours. By fixing you mean that it could compile under Xemacs? But couldn't you just add (if (featurep 'emacs) (require 'rx)) For the time being so that org could be used under Xemacs (and you would not receive the corresponding complains :-D ) I have just updated org-freemind in the repository in a way that will hopefully be compatible with Emacs and XEmacs. In particular, I got rid of the rx dependency. Testing under both Emacs and XEmacs would be highly appreciated. - Carsten ___ 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-capture adds newline(s) when it should not
On Mon, Oct 25, 2010 at 4:21 PM, Marcel van der Boom wrote:
> Hi all,
>
> I'm in the process of migrating from org-remember to org-capture.
> Pretty easy going so far, but it seems org-capture adds newlines, which
> I think it should not do.
>
> My (test) capture-template is:
>
> (("t" "Todo" entry
> (file "~/.outlet/GTD.org")
> "* TODO %?" :prepend t :empty-lines 0)
>
> with the intention of inserting the captured task on the
> first line of the file ~/.outlet/GTD.org. What happens when I capture
> an task is this:
>
>
>
> * TODO Captured task
>
>
>
>
> Both before and after the task is a newline. Also, when capturing and
> cancelling the capture with C-c C-k the newlines remain whereas the
> task is removed.
>
> I'm using the latest git version with emacs 24.0.50.1 on Ubuntu 10.10
>
> Am I doing something wrong or is this a bug?
>
I do not have Emacs 24 as of now.
With the same template I am not able to re-create this on
Org-mode version 7.01trans (release_7.01h.832.gf7094)
GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
of 2010-01-30 on noorul
Thanks and Regards
Noorul
___
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: Adding tags, grouping tags
On 10/25/2010 02:18 AM, Carsten Dominik wrote: > Hi, > > I have the feeling that there are really two strands of > discussion going on here. > > 1. A two-level or even hierarchical way to *enter* *normal* tags, >i.e. tags that are specified in the headline of a node. > > 2. A complex new structure that would somehow utilize properties to >crease a tag-like parallel structure that can be used in searches. > > Is this a correct view of what is being discussed? > I think so. My impression is that the present normal tags are approaching their limit. A multi-level normal tag will probably be longer text, and one core assumption of normal tags is that it is reasonable to display them and simply append them to the end of the headline text. With longer tags and multiple tag contexts I expect this to soon cause problems that are much more severe than just the problem of tag specification. Since there exists the properties capability, a more complex structure that is used in searches and display could be built upon that. R Horn ___ 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-capture adds newline(s) when it should not
Hi all,
I'm in the process of migrating from org-remember to org-capture.
Pretty easy going so far, but it seems org-capture adds newlines, which
I think it should not do.
My (test) capture-template is:
(("t" "Todo" entry
(file "~/.outlet/GTD.org")
"* TODO %?" :prepend t :empty-lines 0)
with the intention of inserting the captured task on the
first line of the file ~/.outlet/GTD.org. What happens when I capture
an task is this:
* TODO Captured task
Both before and after the task is a newline. Also, when capturing and
cancelling the capture with C-c C-k the newlines remain whereas the
task is removed.
I'm using the latest git version with emacs 24.0.50.1 on Ubuntu 10.10
Am I doing something wrong or is this a bug?
marcel
--
Marcel van der Boom -- http://hsdev.com/mvdb.vcf11
So! web applications -- http://make-it-so.info
Cobra build -- http://cobra.mrblog.nl
___
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: 7.01 & Xemacs 21.4.22: decompose-region is not known
>> Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose-region is not >> known; Carsten Dominik adds: >> >> (if (featurep 'emacs) >> (require 'rx)) >> >> To org-freemind >> otherwise it *does not* compile > Yes. I still need to et to fixing org-freemind.el. > Unfortunately, the day has not enough hours. By fixing you mean that it could compile under Xemacs? But couldn't you just add (if (featurep 'emacs) (require 'rx)) For the time being so that org could be used under Xemacs (and you would not receive the corresponding complains :-D ) Uwe ___ 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] [PATCH] quote the real csv separator
Dear Carsten,
dear Nick,
if you are using a standard German locale on either Windows or MacOS, MS Excel
will use semicolons instead of commas as separators when saving in CSV format -
so, really, it is "semicolon separated value" by default for MS products - the
wisdom of this approach is questionable (and one of the many quirks you
encounter when using Excel in a scientific setting with a traditional mix of
several locales). The reasoning, presumably, is that the German number format
uses "," as decimal separator and conflicts with also using commas to separate
columns. You can simulate this by switching your operating system to
international settings: German (Excel needs to be restarted to reflect these
changes).
Warm regards,
Stefan
On 24.10.2010, at 18:52, Nick Dokos wrote:
> Carsten Dominik wrote:
>
>> Hi Lukasz,
>>
>> thanks for the patch, but I do not understand it.
>>
>> The separator for csv is always the comma, or am I wrong here?
>> So this function should use comma, hard-coded. The only place
>> where it is used is when orgtbl-to-csv calls the generic
>> exporter. It does so with comma as separator and with
>> org-quote-csv-field as formatting function.
>>
>> What use case do you have in mind?
>>
>> - Carsten
>>
>
> [This is *not* a comment on the patch itself, which I have not looked at
> carefully.]
>
> CSV started out simple and grew to be a monster (but it is still useful
> despite all that). It's not formally defined, so there are several
> variations, dialects and subdialects. Here e.g. is the description of
> the python module that handles CSV: it defines an "excel" dialect and an
> "excel_tab" subdialect, the latter using a TAB as a delimiter. If you
> want more details and have python installed, start it up, import csv and
> then say "help(csv)".
>
> HTH,
> Nick
>
> ,
> | NAME
> | csv - CSV parsing and writing.
> |
> | FILE
> | /usr/lib/python2.5/csv.py
> |
> | MODULE DOCS
> | http://www.python.org/doc/current/lib/module-csv.html
> |
> | DESCRIPTION
> | This module provides classes that assist in the reading and writing
> | of Comma Separated Value (CSV) files, and implements the interface
> | described by PEP 305. Although many CSV files are simple to parse,
> | the format is not formally defined by a stable specification and
> | is subtle enough that parsing lines of a CSV file with something
> | like line.split(",") is bound to fail. The module supports three
> | basic APIs: reading, writing, and registration of dialects.
> |
> |
> | DIALECT REGISTRATION:
> |
> | Readers and writers support a dialect argument, which is a convenient
> | handle on a group of settings. When the dialect argument is a string,
> | it identifies one of the dialects previously registered with the module.
> | If it is a class or instance, the attributes of the argument are used as
> | the settings for the reader or writer:
> |
> | class excel:
> | delimiter = ','
> | quotechar = '"'
> | escapechar = None
> | doublequote = True
> | skipinitialspace = False
> | lineterminator = '\r\n'
> | quoting = QUOTE_MINIMAL
> |
> | SETTINGS:
> |
> | * quotechar - specifies a one-character string to use as the
> | quoting character. It defaults to '"'.
> | * delimiter - specifies a one-character string to use as the
> | field separator. It defaults to ','.
> | * skipinitialspace - specifies how to interpret whitespace which
> | immediately follows a delimiter. It defaults to False, which
> | means that whitespace immediately following a delimiter is part
> | of the following field.
> | * lineterminator - specifies the character sequence which should
> | terminate rows.
> | * quoting - controls when quotes should be generated by the writer.
> | It can take on any of the following module constants:
> |
> | csv.QUOTE_MINIMAL means only when required, for example, when a
> | field contains either the quotechar or the delimiter
> | csv.QUOTE_ALL means that quotes are always placed around fields.
> | csv.QUOTE_NONNUMERIC means that quotes are always placed around
> | fields which do not parse as integers or floating point
> | numbers.
> | csv.QUOTE_NONE means that quotes are never placed around fields.
> | * escapechar - specifies a one-character string used to escape
> | the delimiter when quoting is set to QUOTE_NONE.
> | * doublequote - controls the handling of quotes inside fields. When
> | True, two consecutive quotes are interpreted as one during read,
> | and when writing, each quote character embedded in the data is
Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose-region is not known
On Oct 25, 2010, at 12:16 PM, Uwe Brauer wrote: Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose- region is not known; Carsten Dominik adds: Org does: (require 'outline) (require 'noutline) I just downloaded the latest xemacs-base pkg and yes the compilation works, with respect to noutline! *But* I still have to modify org-freemind by (if (featurep 'emacs) (require 'rx)) To org-freemind otherwise it *does not* compile Yes. I still need to et to fixing org-freemind.el. Unfortunately, the day has not enough hours. - Carsten ___ 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] fig2 error, An Babel Demo
Hello, I am trying my hand at Org Babel as I am very excited about its potential. Particularly, I am interested in generating LaTeX (and HTML, XML, etc.) from an .org file which contains R code (and Python, SQL, etc.). Though I typically use Sweave for the purpose of incorporating R with LaTeX, the export and multiple language options with Org Mode intrigue me. My problem occurs while using foo.org from: http://orgmode.org/worg/org-contrib/babel/uses.php#foo I am able to generate foo.tex, however it will not compile to PDF given: !pdfTeX error: pdflatex (file ./fig2.pdf): PDF inclusion: required page does not exist <0> ==> Fatal error occurred, no output PDF file produced! Looking further into this by running a prompt for every code block, I discovered that fig2.pdf is indeed generated correctly. However, before the completion of the export to foo.tex, file2.pdf is again changed rendering it unusable by LaTeX. This change occurs after line 171; that is, after figure two is generated, but before the next example in foo.org occurs: #+begin_src R :exports none options(scipen=10) #+end_src Removing everything after line 171 results in a correct PDF (sans the remaining examples, naturally). I cannot seem to pin it to one particular R chunk. I would like to generate the example PDF in its entirety. Any suggestions or thoughts? Thank you, G. ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
>> Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose-region is not >> known; Carsten Dominik adds: > Org does: > (require 'outline) (require 'noutline) I forgot to add: not only does the compilation work, also org itself seems to work, so far Uwe ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
>> Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose-region is not >> known; Carsten Dominik adds: > Org does: > (require 'outline) (require 'noutline) I just downloaded the latest xemacs-base pkg and yes the compilation works, with respect to noutline! *But* I still have to modify org-freemind by (if (featurep 'emacs) (require 'rx)) To org-freemind otherwise it *does not* compile Uwe ___ 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] command names patch
org-time-stamp and others
diff --git a/doc/org.texi b/doc/org.texi
index 4f1a982..ef57655 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -5070,15 +5070,13 @@ format. All commands listed below produce timestamps in the correct
format.
@table @kbd
-...@kindex C-c .
-...@item C-c .
+...@orgcmd{c-c .,org-time-stamp}
Prompt for a date and insert a corresponding timestamp. When the cursor is
at an existing timestamp in the buffer, the command is used to modify this
timestamp instead of inserting a new one. When this command is used twice in
succession, a time range is inserted.
@c
-...@kindex C-c !
-...@item C-c !
+...@orgcmd{c-c !,org-time-stamp-inactive}
Like @kbd{C-c .}, but insert an inactive timestamp that will not cause
an agenda entry.
@c
@@ -5091,18 +5089,15 @@ Like @kbd{C-c .} and @kbd{C-c !}, but use the alternative format which
contains date and time. The default time can be rounded to multiples of 5
minutes, see the option @code{org-time-stamp-rounding-minutes}.
@c
-...@kindex C-c <
-...@item C-c <
+...@orgcmd{c-c <,org-date-from-calendar}
Insert a timestamp corresponding to the cursor date in the Calendar.
@c
-...@kindex C-c >
-...@item C-c >
+...@orgcmd{c-c >,org-goto-calendar}
Access the Emacs calendar for the current date. If there is a
timestamp in the current line, go to the corresponding date
instead.
@c
-...@kindex C-c C-o
-...@item C-c C-o
+...@orgcmd{c-c C-o,org-open-at-point}
Access the agenda for the date given by the timestamp or -range at
point (@pxref{Weekly/daily agenda}).
@c
___
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: Aligning Columns in HTML Export Tables
Carsten Dominik writes:
>
> I am actually using right now:
>
> th.right { text-align:center; }
> th.left { text-align:center; }
> th.center { text-align:center; }
>
> because is seem right to me that a table header is centrally
> aligned even if the fields are lift or right aligned.
yes, seems to be 'common sense' :-D [at least here in Italy(Europe) ;-)]
> Does anyone know enough rules of style to tell me
> if this is the right way, of if header fields are supposed
> to have the same alignments as the data fields?
"Headers are by default center aligned within table cells." [1]
[1] http://www.mcu.org.uk/articles/tables.html
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
Re: [Orgmode] Re: [PATCH] quote the real csv separator
On Oct 25, 2010, at 10:45 AM, Łukasz Stelmach wrote: Bernt Hansen writes: Łukasz Stelmach writes: Carsten Dominik writes: What use case do you have in mind? [...] My bank lets me download monthly reports as CSV. In fact they let me choose the separator and the default value is the comma. But I choose '|' because then I can open the csv as org file and just do (replace-regexp "^" "|") to get a beautiful org-mode table. There is an easier org-mode way I think. Just get the comma delimited data into your org file, select the region and C-c | to get your table. If you are inserting an external file with C-x i RET then C-x C-x marks the region and C-c | converts it to a table. Cool :-) It works like charm. I'll have to check how to convert decimal commas to periods. I still like '|' more for my perl script, though, because it's enough to split '\|' and not care about quoted commas. But this is my problem. OK, I won't insist on keeping the patch but I would like to get a rationale of :sep parameter in orgtbl-to-generic without a choice of how to quote it. orgtbl-to-generic is, well, very generic. It is up to the caller that when she/he specified :sep, to ensure the the separator does not show up in fields, of to specify :fmt in a way that it will take care of any necessary quoting. There is no generic way of quoting, sometimes it is prepending a character, bu in other cases something completely different might be needed. OR, if you think that CSV should stay as it is then I suggest such a rewrite: (defun orgtbl-to-csv (table params) (orgtbl-to-generic table (org-combine-plists params '(:sep "," :fmt org-quote-csv-field to make CSV :sep and and :fmt mandatory (that's how this all have starded). I don't understand, here is the current definition of orgtbl-to-csv: (defun orgtbl-to-csv (table params) "Convert the orgtbl-mode table to CSV material. This does take care of the proper quoting of fields with comma or quotes." (orgtbl-to-generic table (org-combine-plists '(:sep "," :fmt org-quote-csv-field) params))) so these are mandatory. I guess I do not understand what you are saying. Best wishes - Carsten ___ 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: Aligning Columns in HTML Export Tables
On Oct 25, 2010, at 11:02 AM, Giovanni Ridolfi wrote:
Carsten Dominik writes:
I am actually using right now:
th.right { text-align:center; }
th.left { text-align:center; }
th.center { text-align:center; }
because is seem right to me that a table header is centrally
aligned even if the fields are lift or right aligned.
yes, seems to be 'common sense' :-D [at least here in
Italy(Europe) ;-)]
Does anyone know enough rules of style to tell me
if this is the right way, of if header fields are supposed
to have the same alignments as the data fields?
"Headers are by default center aligned within table cells." [1]
OK, thanks for this.
- Carsten
___
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: 7.01 & Xemacs 21.4.22: decompose-region is not known
Carsten Dominik writes: > But I believe you told me that this outline.el has provide statements > for both outline and noutline, right? Yes. But if it's not loaded yet, you need to call it by "outline". (I.e. it's in file outline.el, not noutline.el.) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla ___ 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: Aligning Columns in HTML Export Tables
On Oct 25, 2010, at 10:51 AM, Christian Moe wrote:
On 10/25/10 6:36 AM, Baoqiu Cui wrote:
I am wondering if there
is any special reason to use "class" instead of "align". If not,
can we
change the elisp code to use "align"?
I believe the "align" attribute is slated for obsoletion in HTML5,
on the grounds that it's better handled by CSS.
http://www.w3.org/TR/html5/obsolete.html
It's a reason to go with "class" instead. Not a compelling one,
perhaps.
My only strong opinion on this is that I absolutely agree with the
choice not to set the "style" attribute locally on each table cell.
Hmm, butwe do now set the class in each cell. Is that any better?
- Carsten
But Sebastian Rose's request that prompted it, /could/ equally well
be addressed with the "align" attribute:
How about this (line-wrapped for readability):
1
bar
text
instead of
1
bar
text
??
Combined with the ways to add IDs and classes to tables, we could
then style the
columns better.
I would like to set this for right aligned tags as default:
td.right { font-family:monospace;text-align:right; }
Using the "align" attribute as follows,
1
bar
text
Sebastian could achieve the same with CSS like
td[align="right"] { font-family: monospace;}
In the same way one could even use CSS to override the alignment
specified by the "align" attribute, if for whatever reason this
seemed like a good idea...
One slight advantage of the "align" attribute over "class" is that
it doesn't require the default style to contain the extra verbiage
Carsten mentioned:
I have now in the default style:
td, th { vertical-align: top; }
th.right { text-align:right; }
th.left { text-align:left; }
th.center { text-align:center; }
td.right { text-align:right; }
td.left { text-align:left; }
td.center { text-align:center; }
Is there a way to write this more compactly?
Yours,
Christian
- Carsten
___
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: [PATCH] quote the real csv separator
Hi all, Carsten Dominik wrote: > Hi Lukasz, > > thanks for the patch, but I do not understand it. > > The separator for csv is always the comma, or am I wrong here? > So this function should use comma, hard-coded. Just to confirm what has been implictly shown by Nick, the separator can be many things, and is not limited to comma and tab. By default, on a Windows with French locale settings, the separator is the semi-colon... certainly because the comma is used as decimal separator. 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
On Oct 25, 2010, at 11:07 AM, Michael Sperber wrote: Carsten Dominik writes: But I believe you told me that this outline.el has provide statements for both outline and noutline, right? Yes. But if it's not loaded yet, you need to call it by "outline". (I.e. it's in file outline.el, not noutline.el.) Org does: (require 'outline) (require 'noutline) so this works. Thanks! - Carsten ___ 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] capture initial "level" and refile of capture buffer
On Oct 25, 2010, at 10:54 AM, Noorul Islam wrote: On Mon, Oct 25, 2010 at 12:41 PM, Carsten Dominik wrote: Hi Noorul, hi Richard, On Oct 23, 2010, at 12:16 PM, Noorul Islam wrote: On Sat, Oct 23, 2010 at 2:12 PM, Noorul Islam wrote: On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley > wrote: What determines the level of a new capture element? e.g I just created one and it started at "". feature request : when I added some sub elements to a capture buffer e.g * my new capture ** sub point *** sub sub point 1 *** sub sub point 2 and hit C-c C-w to refile, it only refiled the sub element (where cursor was) and then lost the rest. I would like to suggest that refile from the capture buffer should refile the entire buffer and not only the "current nested org item". Or am I missing something in my setup? On my box I have this observation. If I have something like this in my capture buffer * TODO Test * my new capture ** sub point *** sub sub point 1 *** sub sub point 2 and if I press C-c C-w at the last line (*** sub sub point 2) and refile it to refile.org then what I get in refile.org is this * TODO Test * my new capture ** sub point *** sub sub point 1 * sub sub point 2 The last one's level got changed. I have latest pull from git repo. Org-mode version 7.01trans (release_7.01h.833.g21ad0) GNU Emacs 23.2.2 (i686-pc-linux-gnu) of 2010-06-08 on sajida Fix org-capture bug. * lisp/org.el (org-capture-refile): Consider entire temporary buffer for refiling. diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 7915f7f..6c62114 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -548,7 +548,7 @@ already gone." (unless (eq (org-capture-get :type 'local) 'entry) (error "Refiling from a capture buffer makes only sense for `entry'- type templates")) - (let ((pos (point)) + (let ((pos (point-min)) (base (buffer-base-buffer (current-buffer))) (org-refile-for-capture t)) (org-capture-finalize) This patch catures the problem and brings forward a correct idea. But I believe we need to think a bit further. The current implementation of C-c C-w as a way to finish capture works as closely as possible to the standard refile mechanism. I.e. the tree *where the cursor is at* will be refiled. Your patch makes the cursor move back to beginning of the accessible part of the buffer and refiles from there. If the captured entry starts at this point, and if all the narrowed section contains is a single tree, this is a good solution. However, if we move away from having refile work in the exact same way as normally, the following questions arise: 1. Maybe the user has entered an empty line before the subtree. In this case, the outline node *before* the captured tree will now be refiled. 2. Maybe the user has widened the capture buffer. In this case the code will now refile the first node in the buffer, possibly very far from the current location of point. Or, it will throw an error because the may not be an outline node at point min. 3. Maybe the user has added several trees (siblings) into the capture buffer. In this case, the refile will only affect the first of those siblings. Fair enough. Thank you! So we have two solutions here: Solution 1: Be aware that you are just calling refile, so move the cursor to the appropriate place before running the command. If we insist this in the manual then I think no change is required. But what about the bug that I mentioned earlier, the one that looses the level? Still need to look at that one. - Carsten ___ 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: Re: Latex export: Differing behavior for symbols in headlines
Richard Lawrence writes:
Hi, Richard,
> Nick Dokos writes:
>
>>> 1) Is this difference between whole-document vs. current-subtree export
>>> the expected behavior?
>>>
>> Looks like a bug to me. I can reproduce it too.
>
> Was my original email enough to constitute a bug report?
Well, a week ago Carsten wrote[1]:
"Org-mode will never be a perfect TeX scanner, and this is really hard.
Help yourself and Org by using \( and \) as math delimiters [...] "
How about:
* Headline 1
** Headline 2, concerning \(\alpha\) and \(\beta\)
that will be exported as:
\title{Headline 2, concerning \($\alpha$\) and \($\beta$\)}
cheers,
Giovanni
[1] http://lists.gnu.org/archive/html/emacs-orgmode/2010-10/msg00981.html
___
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] capture initial "level" and refile of capture buffer
On Mon, Oct 25, 2010 at 12:41 PM, Carsten Dominik wrote: > Hi Noorul, hi Richard, > > > On Oct 23, 2010, at 12:16 PM, Noorul Islam wrote: > >> On Sat, Oct 23, 2010 at 2:12 PM, Noorul Islam wrote: >>> >>> On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley >>> wrote: What determines the level of a new capture element? e.g I just created one and it started at "". feature request : when I added some sub elements to a capture buffer e.g * my new capture ** sub point *** sub sub point 1 *** sub sub point 2 and hit C-c C-w to refile, it only refiled the sub element (where cursor was) and then lost the rest. I would like to suggest that refile from the capture buffer should refile the entire buffer and not only the "current nested org item". Or am I missing something in my setup? >>> >>> On my box I have this observation. >>> >>> If I have something like this in my capture buffer >>> >>> * TODO Test >>> >>> * my new capture >>> >>> ** sub point >>> >>> *** sub sub point 1 >>> *** sub sub point 2 >>> >>> >>> and if I press C-c C-w at the last line (*** sub sub point 2) and >>> refile it to refile.org then what I get in refile.org is this >>> >>> >>> * TODO Test >>> >>> * my new capture >>> >>> ** sub point >>> >>> *** sub sub point 1 >>> * sub sub point 2 >>> >>> >>> The last one's level got changed. >>> I have latest pull from git repo. >>> >>> Org-mode version 7.01trans (release_7.01h.833.g21ad0) >>> GNU Emacs 23.2.2 (i686-pc-linux-gnu) >>> of 2010-06-08 on sajida >>> >> >> Fix org-capture bug. >> >> * lisp/org.el (org-capture-refile): Consider entire temporary buffer >> for refiling. > > >> diff --git a/lisp/org-capture.el b/lisp/org-capture.el >> index 7915f7f..6c62114 100644 >> --- a/lisp/org-capture.el >> +++ b/lisp/org-capture.el >> @@ -548,7 +548,7 @@ already gone." >> (unless (eq (org-capture-get :type 'local) 'entry) >> (error >> "Refiling from a capture buffer makes only sense for `entry'-type >> templates")) >> - (let ((pos (point)) >> + (let ((pos (point-min)) >> (base (buffer-base-buffer (current-buffer))) >> (org-refile-for-capture t)) >> (org-capture-finalize) > > > This patch catures the problem and brings forward a correct idea. > But I believe we need to think a bit further. The current > implementation of C-c C-w as a way to finish capture works > as closely as possible to the standard refile mechanism. > I.e. the tree *where the cursor is at* will be refiled. > > Your patch makes the cursor move back to beginning of the > accessible part of the buffer and refiles from there. > > If the captured entry starts at this point, and if all > the narrowed section contains is a single tree, this > is a good solution. However, if we move away from having > refile work in the exact same way as normally, the > following questions arise: > > 1. Maybe the user has entered an empty line before the subtree. > In this case, the outline node *before* the captured tree > will now be refiled. > > 2. Maybe the user has widened the capture buffer. In this case > the code will now refile the first node in the buffer, possibly > very far from the current location of point. Or, it will > throw an error because the may not be an outline > node at point min. > > 3. Maybe the user has added several trees (siblings) into the > capture buffer. In this case, the refile will only > affect the first of those siblings. > Fair enough. Thank you! > So we have two solutions here: > > Solution 1: Be aware that you are just calling refile, so > move the cursor to the appropriate place before > running the command. > If we insist this in the manual then I think no change is required. But what about the bug that I mentioned earlier, the one that looses the level? Thanks and Regards Noorul ___ 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: Aligning Columns in HTML Export Tables
On 10/25/10 6:36 AM, Baoqiu Cui wrote:
I am wondering if there
is any special reason to use "class" instead of "align". If not, can we
change the elisp code to use "align"?
I believe the "align" attribute is slated for obsoletion in HTML5, on
the grounds that it's better handled by CSS.
http://www.w3.org/TR/html5/obsolete.html
It's a reason to go with "class" instead. Not a compelling one, perhaps.
My only strong opinion on this is that I absolutely agree with the
choice not to set the "style" attribute locally on each table cell.
But Sebastian Rose's request that prompted it, /could/ equally well be
addressed with the "align" attribute:
How about this (line-wrapped for readability):
1
bar
text
instead of
1
bar
text
??
Combined with the ways to add IDs and classes to tables, we could then style the
columns better.
I would like to set this for right aligned tags as default:
td.right { font-family:monospace;text-align:right; }
Using the "align" attribute as follows,
1
bar
text
Sebastian could achieve the same with CSS like
td[align="right"] { font-family: monospace;}
In the same way one could even use CSS to override the alignment
specified by the "align" attribute, if for whatever reason this seemed
like a good idea...
One slight advantage of the "align" attribute over "class" is that it
doesn't require the default style to contain the extra verbiage
Carsten mentioned:
I have now in the default style:
td, th { vertical-align: top; }
th.right { text-align:right; }
th.left { text-align:left; }
th.center { text-align:center; }
td.right { text-align:right; }
td.left { text-align:left; }
td.center { text-align:center; }
Is there a way to write this more compactly?
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
[Orgmode] Re: Unbillable clock time
Hi, Bernt Hansen wrote: > Ross Patterson writes: >> I would like to be able to designate some of my clock time as unbillable >> such that when using a clockreport the unbillable time is not included. I >> would also like to compare billable and unbillable time if possible. >> >> Currently I either manually change "CLOCK: *" to "UNBILLABLE: *" preserving >> history but it's kind of messy or I just delete the time altogether, losing >> history. >> >> Is there a better way to accomplish this? If not, may I request this >> feature. :-) Many time-keeping systems have a "billable" flag for entries. I also have that same "problem", though marginally (because of the ratio billed/unbilled in my case). > I just clock everything. You can make a level 1 heading of * Billable and * > Non-Billable and create tasks under that to clock. > > Then your clock reports will show summaries and the Billable/Non-Billable > stuff should be obvious. > > Alternatively you can keep separate project files for Billable and > non-Billable. I've used both approaches in the past. The problem is, sometimes, what's billable and what's not is know afterward. You can refile, then, yes, but it "completely" changes the structure of your docs. I'd like the idea of a property, or some other way to make that explicit without having to move stuff around. 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: [PATCH] quote the real csv separator
Bernt Hansen writes: > Łukasz Stelmach writes: >> Carsten Dominik writes: >>> What use case do you have in mind? [...] >> My bank lets me download monthly reports as CSV. In fact they let me >> choose the separator and the default value is the comma. But I choose >> '|' because then I can open the csv as org file and just do >> >> (replace-regexp "^" "|") >> >> to get a beautiful org-mode table. > > There is an easier org-mode way I think. Just get the comma delimited > data into your org file, select the region and C-c | to get your table. > > If you are inserting an external file with C-x i RET > then C-x C-x marks the region and C-c | converts it to a table. Cool :-) It works like charm. I'll have to check how to convert decimal commas to periods. I still like '|' more for my perl script, though, because it's enough to split '\|' and not care about quoted commas. But this is my problem. OK, I won't insist on keeping the patch but I would like to get a rationale of :sep parameter in orgtbl-to-generic without a choice of how to quote it. OR, if you think that CSV should stay as it is then I suggest such a rewrite: (defun orgtbl-to-csv (table params) (orgtbl-to-generic table (org-combine-plists params '(:sep "," :fmt org-quote-csv-field to make CSV :sep and and :fmt mandatory (that's how this all have starded). -- Miłego dnia, Łukasz Stelmach ___ 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: 7.01 & Xemacs 21.4.22: decompose-region is not known
On Oct 25, 2010, at 8:13 AM, Michael Sperber wrote:
Carsten Dominik writes:
On Oct 24, 2010, at 7:28 PM, Uwe Brauer wrote:
Regarding Re: [Orgmode] Re: 7.01 & Xemacs 21.4.22: decompose-
region is not known; Carsten Dominik
adds:
Hi Uwe,
Does the latest Org-mode git version work for you now?
For xemacs 21.4.X? No but the reason is simple the recent
version of org does not ship the noutline file, so no
wounder that I obtain an error message of the sort
While compiling toplevel forms in file /home/oub/ALLES/xemacs/site-
lisp/packages/org-mode-web/lisp/org.el:
!! File error (("Cannot open load file" "noutline"))
Error occurred processing lisp/org.el: Cannot open load file:
noutline
You mentioned that noutline will not be shipped any more,
but then I don't understand that error message.
I think noutline is now in XEmacs, in some package - but I do not
know
which versions of XEmacs will/can load this package. It should be in
a file outline.el and provide both outline and noutline.
The new outline.el (i.e. the one that ships with the current xemacs-
base
package) also works with 21.4. But it is called outline.el, not
noutline.el.
But I believe you told me that this outline.el has provide statements
for both outline and noutline, right?
Thanks.
- Carsten
___
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] capture initial "level" and refile of capture buffer
Hi Noorul, hi Richard, On Oct 23, 2010, at 12:16 PM, Noorul Islam wrote: On Sat, Oct 23, 2010 at 2:12 PM, Noorul Islam wrote: On Fri, Oct 22, 2010 at 5:13 PM, Richard Riley > wrote: What determines the level of a new capture element? e.g I just created one and it started at "". feature request : when I added some sub elements to a capture buffer e.g * my new capture ** sub point *** sub sub point 1 *** sub sub point 2 and hit C-c C-w to refile, it only refiled the sub element (where cursor was) and then lost the rest. I would like to suggest that refile from the capture buffer should refile the entire buffer and not only the "current nested org item". Or am I missing something in my setup? On my box I have this observation. If I have something like this in my capture buffer * TODO Test * my new capture ** sub point *** sub sub point 1 *** sub sub point 2 and if I press C-c C-w at the last line (*** sub sub point 2) and refile it to refile.org then what I get in refile.org is this * TODO Test * my new capture ** sub point *** sub sub point 1 * sub sub point 2 The last one's level got changed. I have latest pull from git repo. Org-mode version 7.01trans (release_7.01h.833.g21ad0) GNU Emacs 23.2.2 (i686-pc-linux-gnu) of 2010-06-08 on sajida Fix org-capture bug. * lisp/org.el (org-capture-refile): Consider entire temporary buffer for refiling. diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 7915f7f..6c62114 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -548,7 +548,7 @@ already gone." (unless (eq (org-capture-get :type 'local) 'entry) (error "Refiling from a capture buffer makes only sense for `entry'- type templates")) - (let ((pos (point)) + (let ((pos (point-min)) (base (buffer-base-buffer (current-buffer))) (org-refile-for-capture t)) (org-capture-finalize) This patch catures the problem and brings forward a correct idea. But I believe we need to think a bit further. The current implementation of C-c C-w as a way to finish capture works as closely as possible to the standard refile mechanism. I.e. the tree *where the cursor is at* will be refiled. Your patch makes the cursor move back to beginning of the accessible part of the buffer and refiles from there. If the captured entry starts at this point, and if all the narrowed section contains is a single tree, this is a good solution. However, if we move away from having refile work in the exact same way as normally, the following questions arise: 1. Maybe the user has entered an empty line before the subtree. In this case, the outline node *before* the captured tree will now be refiled. 2. Maybe the user has widened the capture buffer. In this case the code will now refile the first node in the buffer, possibly very far from the current location of point. Or, it will throw an error because the may not be an outline node at point min. 3. Maybe the user has added several trees (siblings) into the capture buffer. In this case, the refile will only affect the first of those siblings. So we have two solutions here: Solution 1: Be aware that you are just calling refile, so move the cursor to the appropriate place before running the command. Solution 2: Install two markers at the beginning and end of the region to which the buffer has been narrowed, and then select that entire region for refiling. This is non-trivial, but probably can be made to work. In either case we will probably have to update the manual to make things clearer. - Carsten ___ 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: Aligning Columns in HTML Export Tables
On Oct 23, 2010, at 9:28 PM, Sebastian Rose wrote:
Carsten Dominik writes:
I have now in the default style:
td, th { vertical-align: top; }
th.right { text-align:right; }
th.left { text-align:left; }
th.center { text-align:center; }
I am actually using right now:
th.right { text-align:center; }
th.left { text-align:center; }
th.center { text-align:center; }
because is seem right to me that a table header is centrally
aligned even if the fields are lift or right aligned.
Does anyone know enough rules of style to tell me
if this is the right way, of if header fields are supposed
to have the same alignments as the data fields?
td.right { text-align:right; }
td.left { text-align:left; }
td.center { text-align:center; }
Is there a way to write this more compactly?
- Carsten
But this is, what I often use:
/* Aligns block elements, too: */
.right {margin-left:auto; margin-right:0px; text-align:right;}
.left {margin-left:0px; margin-right:auto; text-align:left;}
.center {margin-left:auto; margin-right:auto; text-align:center;}
These are CSS classes I use frequently. It works for all HTML
elements
AND aligns table to the right in all important browsers. I first
thought "OK, we can do this ourselves per stylesheet", but why not
offer
this little goodie out-of-the-box?
So you are suggesting I should add these
to the style sheet. Sounds fine to me, with the
limitation that it might interfere with commonly
used classes?
I prefer to have at least the th.left/right/center in addition
due to the fact that I think I like centered headers.
Try:
(THERE'S A BUG: #+STYLE: lines are not wrapped in tags
anymore)
--8<---cut here---start->8---
#+STYLE: .right {margin-left:auto; margin-right:0px; text-
align:right;}
#+STYLE: .left {margin-left:0px; margin-right:auto; text-
align:left;}
#+STYLE: .center {margin-left:auto; margin-right:auto; text-
align:center;}
Did it ever do this? I don't think so, because the documentation of the corresponding variables is explicit about the fact that you need to put the