Re: [Orgmode] text color + highlight
Hi Eric, Did you read my proposals in detail? Samuel On 2010-08-08, Eric Schulte wrote: > Hi, > > The attached patch implements in-buffer coloring and html export using > the syntax proposed below. > > While I think this is an improvement over my previous patch, this idea > still has some shortcoming including the fact that > - nested color specifications aren't working for export (and could be > tricky to implement) > - when using a dark-background Emacs theme colors that look good in the > buffer generally don't look good in the html export and vise versa > > The following Org-mode buffer demonstrates this patch > --8<---cut here---start->8--- > #+Title: A Buffer with Color > > * top > Some colors [color[green]are] green, and [color[red]also] red, and even html > colors > like [color[#610B5E]these others] sometimes subtler colors. > > These can also be [background[yellow]highlighted]. > --8<---cut here---end--->8--- > > Cheers -- Eric > > -- Q: How many CDC "scientists" does it take to change a lightbulb? A: "You only think it's dark." [CDC has denied a deadly disease for 25 years] == Retrovirus: http://www.wpinstitute.org/xmrv/index.html -- PLEASE DONATE === PNAS must publish the original Lo and Alter NIH/FDA XMRV paper verbatim along with the new paper. ___ 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: keys and command name info
On Aug 9, 2010, at 12:26 AM, Gregor Zattler wrote: Hi Carsten, org-mode developers, * Carsten Dominik [02. Aug. 2010]: I am not sure I would like such a change because I think it makes the manual harder and less fluid to read and considerably longer. It makes the manual longer as in bytes/bandwidth but not as in lines which IMHO corresponds with the amount of time one needs to read the manual. If it's consistent within the manual it's IMHO not confusing or harder to read because it's easy to skip. To me actually this hints look like headings. They would support me in skimming a section of commands in order to find the right one. Those paragraphs with key sequences at the beginning are hard to skim because all the info which stands out is not relevant if one searches for a specific action. Seeing how the command is named in the context of usage information might help lisp novices in getting an idea why some solutions work the way they do. Hi Gregor, thanks for chiming in and summarizing your arguments. And that you say it makes it easier to find the right command may be a good argument to insert the command names. Some of the original arguments, that these names would stick more easily and that it would make it easy for a hacker to find the command name for rebinding, these do not fly, I think. I don't think anyone calls Org commands with M-x, and if a hacker needs to find a command name, `C-h b' and in particular `C-h k' are the perfect ways to get to the names. I have put a version of the manual as modified by Andreas here: http://orgmode.org/org-manual-with-command-names.pdf Not all the command names are in there, but quite a few are. I'd like to hear from more people - if they would like to have the names there (i.e. if it would help them finding a command) - if the position (first thing in the command description) is right, or if it would be better to have it - last thing in the description - or after the first sentence, this is how the GNUS manual does it. Thanks to Andreas for his work so far, and please, let me hear more opinions. - 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] text color + highlight
On Aug 8, 2010, at 11:00 PM, Eric Schulte wrote:
Vinh Nguyen writes:
On Fri, Aug 6, 2010 at 8:15 PM, Eric Schulte
wrote:
In playing with the patched code I sent out, I noticed that it may
be
doing weird things to my headings (#+Title: etc...) in some Org-mode
files, so probably it could use some more tweaking before any merge,
also I'd not want to rush what could be a reasonably large change
into
Org-mode without more discussion, but I agree I'd ultimately like
to see
some form of this functionality appear in Org-mode.
Best -- Eric
Eric, so are you tweaking the code to give it a more org-like syntax?
If not, I'll have to get dirty with your patch to figure out the lisp
code.
You're right the regular parentheses will probably be mixed up with
lisp code. Sebastian also brought up that curly braces are hard to
type on a German keyboard. Just googled up the layout -- don't even
seen them.
What syntax to use...
I've thought briefly about the following syntax
[color[red] text to be colored red]
Nope, I am against this syntax. If we introduce a more general syntax,
then it should be done in the way Samuel proposed. WHich means
we firs get a keyword indtroducing the piece, and then properties.
Like
$[style :color red the red text]
or
$[face :color :italic t red the red text]
Something like the $ before "[" also would seem critical to disambiguate
from other uses of "[".
However, I am not too excited about extra syntax to get this kind of
thing.
Would not oppose it, but probably never use it.
- Carsten
- this would be extensible, e.g.
[background[yellow] highlighted text]
could export to the following html
highlighted text
- this would avoid "{}"s
- this would look more "org-like" than the pure latex solution
the only issue with the above is that it may conflate a new /markup/
syntax with org-mode's existing /link/ syntax.
Thoughts? -- Eric
___
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] why not auto-renumbering list ?
Hi Nicolas, On Aug 7, 2010, at 2:41 PM, Nicolas Goaziou wrote: Hello, I'm still into lists, First, my apologies that I have so far not found the time to test your improved list implementation. I think this is a far-reaching change, which is why it needs careful testing before we apply it. I really hope to get to this soon. Have you had any testing feedback from anyone else so far? Have you tested it in all the export backends? and I'm wondering about the global usefulness of `org-auto-renumber-ordered-lists', provided that: - it isn't noticeably slower to renumber and fix a list than to simply fix its indentation; - you can use [...@start:num] to enforce a special numbering; - some actions on a list will renumber it whatever the value of this variable is. So, I'd like to hear about other users. Do you set this variable to nil? If so, what is your use case? I don't think anyone sets this to nil. But there is a use case for this, if someone wants some strange specific numbering, then it might be useful to allow turning it off. There is no harm in having this possibility. If there's a need for decreasing numbers or numbers increasing by more than one, I could add [...@step:num] and [...@start:num,@step:num] as possibilities, but it looks a bit overkill to me. To me as well. Anyway, the idea behind this would be to: - remove `org-maybe-renumber-ordered-list', - remove `org-maybe-renumber-ordered-list-safe', - remove this variable, - rename `org-fix-bullet-type' to `org-fix-bullet', - call `org-fix-bullet' unconditionally when acting on a list instead of having to decide if the function should renumber or simply fix indentation. While this sounds reasonable - it also unnecessary to me. Why fix something that works? - 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: [PATCH] Proposed command: org-agenda-clock-goto
On Aug 7, 2010, at 10:14 AM, Bastien wrote: Bernt Hansen writes: I'm not against this change since I've never used J in the agenda before (mostly because I wasn't aware of this key binding at all). C-c C-x C-j is now bound to org-agenda-clock-goto in agenda buffers and to org-clock-goto is org buffers. I hesitated long, and I'm still not convinved this is the best choice. Since `J' is an agenda-only keybinding, maybe using `J' would make more sense. I have not looked up which way it is now, but thinking again it seems to me that this would be the right way: C-c C-x C-j jumps to the entry in the org buffer, both from the agenda and from normal buffers. "J" would then be available to find the clock entry in the agenda, if it is present there. We could extend this command to show the clock entry in the other window if the line cannot be found in the agenda window... - Carsten What's your take on this? Is there a way to rebind agenda keys in case I want to use J for something different (similar to the user speed key settings?) (org-defkey org-agenda-mode-map "J" 'your-function) In general, he best way to do user keys is to bind them in the mode hook of the mode you need them for, in this case org-agenda-mode-hook. I don't really want to overwrite the standard org-agenda-keymap bindings but it might be useful to have user bindings that on top of those as we do for the speed key settings. I think doing the hook think is good enough for this case. The speed key implementation is different. - 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] questions about links
On 08/07/2010 07:00 PM, scraw...@gmail.com wrote: > Hi guys, > > Ok, if I make "foo" a link: > > blah blah [[foo]] blah > > it will pop over to "foo" elsewhere in the buffer. > > (This is a tangent, but I see carets in the documentation, like > "" , but they don't seem to be needed-- the link finds > "foo" just fine) > > Can I make [[foo]] link to all the foos in the buffer, > maybe via a list with a bit of context from which to > choose? Try this one: [[elisp:(occur "foo")]] "occur" is a standard emacs feature which lists all lines matching a given regexp. If you're going to use this, I'd recommend setting org-confirm-elisp-link-function to 'with-y-or-n for less annoyance while still being warned you are about to follow a link that can execute arbitrary code. > also, once I'm at the target, how can I return easily to > the anchor and refold whatever section the target was in? You can go back to where you came from using C-c &: | C-c & runs the command org-mark-ring-goto, which is an interactive | Lisp function in `org.el'. | | It is bound to C-c &. | | (org-mark-ring-goto &optional n) | | Jump to the previous position in the mark ring. | With prefix arg n, jump back that many stored positions. When | called several times in succession, walk through the entire ring. | Org-mode commands jumping to a different position in the current file, | or to another Org-mode file, automatically push the old position | onto the ring. I don't know about refolding the target headline. HTH, Jan ___ 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] text color + highlight
Am 09.08.2010, 08:28 Uhr, schrieb Carsten Dominik : Nope, I am against this syntax. If we introduce a more general syntax, then it should be done in the way Samuel proposed. WHich means we firs get a keyword indtroducing the piece, and then properties. Like $[style :color red the red text] or $[face :color :italic t red the red text] Something like the $ before "[" also would seem critical to disambiguate from other uses of "[". I'd prefer this kind of syntax, too. Btw, shouldn't the syntax be: $[face :color red :italic t the red italic text] ?? (i.e. the red following the :color keyword, not the ':italic t') I didn't find a canonical way to make a paragraph or a longer text passage italic However, I am not too excited about extra syntax to get this kind of thing. Would not oppose it, but probably never use it. - 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] text color + highlight
Am 09.08.2010, 09:37 Uhr, schrieb Robert Klein : Sorry dropped something on the keyboard and sent the message early :( Am 09.08.2010, 08:28 Uhr, schrieb Carsten Dominik : Nope, I am against this syntax. If we introduce a more general syntax, then it should be done in the way Samuel proposed. WHich means we firs get a keyword indtroducing the piece, and then properties. Like $[style :color red the red text] or $[face :color :italic t red the red text] Something like the $ before "[" also would seem critical to disambiguate from other uses of "[". I'd prefer this kind of syntax, too. Btw, shouldn't the syntax be: $[face :color red :italic t the red italic text] ?? (i.e. the red following the :color keyword, not the ':italic t') I didn't find a canonical way to make a paragraph or a longer text passage italic, so I'd love an easy way to get it. BTW, if simply '$[' is free, why not use this for style, e.g.: $[:italic t :bold nil :color teal My italic and teal text] (sorry for the double mail) Best regards Robert However, I am not too excited about extra syntax to get this kind of thing. Would not oppose it, but probably never use it. - 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] What license for Worg?
On Wed, Aug 04, 2010 at 06:36:45AM +0200, Bastien wrote: > Here is what I read at the bottom of every emacswiki.org page: > > This work is licensed to you under version 2 of the GNU General Public > License. [..] > So this is GPLv2. Any idea why this isn't GPLv3? No clue. I must confess that I'm writing this email without the benefit of a net connection, so I can't check if emacs itself has moved to GPLv3. If it hasn't I can imagine wanting to keep emacs wiki compatible with emacs itself. > Also, I find the formulation a bit confusing. Is it the standard > formulation when multi-licensing? Where can I found an example of a > clear multi-licensing statement? I'm not a lawyer or even particularly interested in the technicalities of such, but I do think that the emacs-wiki statement errs on the side of being human intelligible at the expense of concision. > I've not made up my mind yet, but I would go for something like that: > > The content of the Worg website is licensed under the CC BY-SA 3.0 and > the GPLv3 and the GFDL 1.3. You can choose to receive the content of > Worg under any of these three licenses. > > Good? I'd include "or later" statements, so that Worg can optionally take advantage of any updates to these licenses if they are revised to fix issues that arise (which is, again, the same as emacs itself.) More than anything, the "or later" statements, reduce potential future headache. Perhaps something like The content of the Worg website is licensed under the CC BY-SA 3.0 (or later) and the GNU GPLv3 (or later) and the GNU FDL 1.3 (or later). You can choose to receive the content of Worg under any of these three licenses. Again, just a thought. Cheers, sam -- tycho(ish) @ ga...@tychoish.com http://www.tychoish.com/ http://www.cyborginstitute.com/ "don't get it right, get it written" -- james thurber ___ 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: keys and command name info
Carsten Dominik writes: > On Aug 9, 2010, at 12:26 AM, Gregor Zattler wrote: > >> Hi Carsten, org-mode developers, >> * Carsten Dominik [02. Aug. 2010]: >>> I am not sure I would like such a change because I think it >>> makes the manual harder and less fluid to read and considerably >>> longer. >> >> It makes the manual longer as in bytes/bandwidth but not as in >> lines which IMHO corresponds with the amount of time one needs to >> read the manual. >> >> If it's consistent within the manual it's IMHO not confusing or >> harder to read because it's easy to skip. >> >> To me actually this hints look like headings. They would support >> me in skimming a section of commands in order to find the right >> one. Those paragraphs with key sequences at the beginning are >> hard to skim because all the info which stands out is not >> relevant if one searches for a specific action. >> >> Seeing how the command is named in the context of usage >> information might help lisp novices in getting an idea why some >> solutions work the way they do. > > Hi Gregor, thanks for chiming in and summarizing your arguments. > And that you say it makes it easier to find the right command > may be a good argument to insert the command names. > > Some of the original arguments, that these names would stick > more easily and that it would make it easy for a hacker to > find the command name for rebinding, these do not fly, I think. > I don't think anyone calls Org commands with M-x, and if a > hacker needs to find a command name, `C-h b' and in particular > `C-h k' are the perfect ways to get to the names. > > I have put a version of the manual as modified by Andreas here: > >http://orgmode.org/org-manual-with-command-names.pdf > > Not all the command names are in there, but quite a few are. > I'd like to hear from more people > > - if they would like to have the names there (i.e. if it would > help them finding a command) > - if the position (first thing in the command description) > is right, or if it would be better to have it > - last thing in the description > - or after the first sentence, this is how the GNUS manual >does it. Having the function names in the manual at all makes it look a bit overloaded and might lose us a couple of newbies, I think. Personally, I would not have use for it. If the names are included in the manual I strongly object to them being at the beginning of the first sentence. The fixed starting column of the sentences becomes variable and that makes it hard to skim through for those who don't want to read the function names. What about having them in the same line as the keybinding but aligned to the right? `C-c [' org-agenda-file-to-front Add current file to the list of agenda files. The file is added to the front of the list. If it was already in the list, it is moved to the front. With prefix arg, file is added/moved to the end. It would make the manual longer, but at least it looks clean. It is easy to neglect the function names if one wants, and just as easy to skim through them. Andreas > > Thanks to Andreas for his work so far, and please, let me > hear more opinions. > > - 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 ___ 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: called-interactively-p : org-capture
On Aug 8, 2010, at 9:19 PM, Richard Riley wrote:
Richard Riley writes:
I upgraded to latest git version and modified my setup to use
org-capture.
Even using the default templates and keybindings in the docs I get
the
following backtrace when trying to create a new todo item based on
org-capture-templates
,
| Debugger entered--Lisp error: (error "Capture template `t':
called-interactively-p")
| signal(error ("Capture template `t': called-interactively-p"))
| error("Capture template `%s': %s" "t" called-interactively-p)
| byte-code("Áp!
___
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
Hmm : a combination of wiping org mode completely, reinstalling and
some
restructuring of my emacs-init and this has now cured itself.
Good.
As a side note : the new org-capture UI and functionality is superb!
Nice one.
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
[Orgmode] Re: [PATCH] Org Manual: Document time range spec at the date/time prompt
Re-submitting my earlier patch. Please ignore the earlier one.
> Comments:
> Support for specifying the duration in absolute minutes could be
> useful in some cases. (In my case, I was trying to plug in the
> duration of a BBC production specified in minutes - for eg 92 min,
> 116 min, 205 min etc).
> Related bugs:
> 1. While trying to specify time range as '2:00-3:00' I see the
> following message - 'Error in post-command-hook: (parse-error not
> an integer 3:)'. The corresponding calendar entry gets created
> though.
> 2. Is there support for agenda to wrap around the day. For example
> how would the following entries be interpreted 23:00+2:00,
> 3:00+48. Just curious.
>From ddc86808233b21f72bb544f5ebfdde5e5db115f7 Mon Sep 17 00:00:00 2001
From: Jambunathan K
Date: Sun, 8 Aug 2010 22:41:07 +0530
Subject: [PATCH] Org Manual: Document time range spec at the date/time prompt
* org.texi (The date/time prompt): Document specification of time
ranges.
TINYCHANGE
---
doc/org.texi | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index 13af2df..4938f48 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -5212,6 +5212,16 @@ The function understands English month and weekday
abbreviations. If
you want to use unabbreviated names and/or other languages, configure
the variables @code{parse-time-months} and @code{parse-time-weekdays}.
+You can specify a time range by giving start and end times or by giving a
+start time and a duration (in HH:MM format). Use '-' or '--' as the separator
+in the former case and use '+' as the separator in the latter case. E.g.
+
+...@example
+11am-1:15pm--> 11:00-13:15
+11am--1:15pm --> same as above
+11am+2:15 --> same as above
+...@end example
+
@cindex calendar, for selecting date
@vindex org-popup-calendar-for-date-prompt
Parallel to the minibuffer prompt, a calendar is popped u...@footnote{if
--
1.7.0.4
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [Bug] Refiling troubles with inlined Org (thru Babel)
Hello, Here is a complete minimal example... --8<---cut here---start->8--- #+TITLE: Refiling troubles with inlined Org #+AUTHOR:Sebastien Vauban #+DATE: 2010-08-09 #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en_US * First section ** The item I wanna refile I'm trying to refile this subtree to the "second one" section. #+BEGIN_SRC org ** Totals *** Using a table formula #+END_SRC This causes troubles, as you already can see just by marking this subtree (`C-c @'). * Second one --8<---cut here---end--->8--- 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] TODO DONE strikethrough
I could not (re)find a reference I saw a while back about setting DONE TODO items with a strikethrough. Can anyone remember how to set this? Thanks 'Mash --- 'to life is doxology http://toshine.org ___ 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: keys and command name info
Hi Andreas, org-mode developers, * Andreas Burtzlaff [09. Aug. 2010]: > Carsten Dominik writes: >> I have put a version of the manual as modified by Andreas here: >> >>http://orgmode.org/org-manual-with-command-names.pdf >> >> Not all the command names are in there, but quite a few are. >> I'd like to hear from more people >> >> - if they would like to have the names there (i.e. if it would >> help them finding a command) >> - if the position (first thing in the command description) >> is right, or if it would be better to have it >> - last thing in the description >> - or after the first sentence, this is how the GNUS manual >>does it. > > Having the function names in the manual at all makes it look a bit > overloaded and might lose us a couple of newbies, I think. Personally, I > would not have use for it. > > If the names are included in the manual I strongly object to them being > at the beginning of the first sentence. The fixed starting column of the > sentences becomes variable and that makes it hard to skim through for > those who don't want to read the function names. +1 for the same reasons. This is especially true for paragraphs like those: C-c C-n (outline-next-visible-heading) Next heading. C-c C-p (outline-previous-visible-heading) Previous heading. C-c C-f (org-forward-same-level) Next heading same level. C-c C-b (org-backward-same-level) Previous heading same level. C-c C-u (outline-up-heading) Backward to higher level heading. C-c C-j (org-goto) Jump to a different place without changing the current outline visibility. Shows the document structure in a temporary buffer, where you can use the following keys to find your destination: > What about having them in the same line as the keybinding but aligned to > the right? > > `C-c [' org-agenda-file-to-front > Add current file to the list of agenda files. The file is added to > the front of the list. If it was already in the list, it is moved > to the front. With prefix arg, file is added/moved to the end. > > It would make the manual longer, but at least it looks clean. > It is easy to neglect the function names if one wants, and just as easy > to skim through them. +1 for the same reasons. But Andreas Röhlers original variant is IMHO even better: >| [ ... ] >| `C-c [', org-agenda-file-to-front >| Add current file to the list of agenda files. The file is added to >| the front of the list. If it was already in the list, it is moved >| to the front. With prefix Argument, file is added/moved to the end. Here the command name serves as a kind of a heading, it's easy to search these locations while at the same time it's easy to skim over the pages and not bother with the command names. My preference: 1. as in Andreas Röhlers original ASCII rendering 2. as in Andreas Burtzlaffs ASCII rendering 3. not at all 4. as in the test manual Just me 2¢. Either way, org-mode is great. Gregor P.S.: Some of the command names don't help that much: C-c C-c (org-ctrl-c-ctrl-c) If there is a checkbox (see Section 5.6 [Checkboxes], page 46) in the item line, toggle the state of the checkbox. If not, this command makes sure that all the items on this list level use the same bullet. Furthermore, if this is an ordered list, make sure the numbering is OK. C-c - (org-ctrl-c-minus) Cycle the entire list level through the different item- ize/enumerate bullets (`-', `+', `*', `1.', `1)'). With a numeric prefix argument N, select the Nth bullet from this list. If there is an active region when calling this, all lines will be converted to list items. If the first line already was a list item, any item markers will be removed from the list. Finally, even without an active region, a normal line will be converted into a list item. C-c * (org-ctrl-c-star) Turn a plain list item into a headline (so that it becomes a subheading at its location). See Section 2.5 [Structure editing], page 7, for a detailed explanation. But even this gives a clue in how it all works. ___ 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: keys and command name info
On Aug 9, 2010, at 12:19 PM, Gregor Zattler wrote: Hi Andreas, org-mode developers, * Andreas Burtzlaff [09. Aug. 2010]: Carsten Dominik writes: I have put a version of the manual as modified by Andreas here: http://orgmode.org/org-manual-with-command-names.pdf Not all the command names are in there, but quite a few are. I'd like to hear from more people - if they would like to have the names there (i.e. if it would help them finding a command) - if the position (first thing in the command description) is right, or if it would be better to have it - last thing in the description - or after the first sentence, this is how the GNUS manual does it. Having the function names in the manual at all makes it look a bit overloaded and might lose us a couple of newbies, I think. Personally, I would not have use for it. If the names are included in the manual I strongly object to them being at the beginning of the first sentence. The fixed starting column of the sentences becomes variable and that makes it hard to skim through for those who don't want to read the function names. +1 for the same reasons. This is especially true for paragraphs like those: C-c C-n (outline-next-visible-heading) Next heading. C-c C-p (outline-previous-visible-heading) Previous heading. C-c C-f (org-forward-same-level) Next heading same level. C-c C-b (org-backward-same-level) Previous heading same level. C-c C-u (outline-up-heading) Backward to higher level heading. C-c C-j (org-goto) Jump to a different place without changing the current outline visibility. Shows the document structure in a temporary buffer, where you can use the following keys to find your destination: What about having them in the same line as the keybinding but aligned to the right? `C-c [' org-agenda-file-to- front Add current file to the list of agenda files. The file is added to the front of the list. If it was already in the list, it is moved to the front. With prefix arg, file is added/moved to the end. It would make the manual longer, but at least it looks clean. It is easy to neglect the function names if one wants, and just as easy to skim through them. +1 for the same reasons. But Andreas Röhlers original variant is IMHO even better: | [ ... ] | `C-c [', org-agenda-file-to-front | Add current file to the list of agenda files. The file is added to | the front of the list. If it was already in the list, it is moved | to the front. With prefix Argument, file is added/moved to the end. Here the command name serves as a kind of a heading, it's easy to search these locations while at the same time it's easy to skim over the pages and not bother with the command names. My preference: 1. as in Andreas Röhlers original ASCII rendering 2. as in Andreas Burtzlaffs ASCII rendering 3. not at all 4. as in the test manual Just me 2¢. Either way, org-mode is great. Gregor P.S.: Some of the command names don't help that much: C-c C-c (org-ctrl-c-ctrl-c) If there is a checkbox (see Section 5.6 [Checkboxes], page 46) in the item line, toggle the state of the checkbox. If not, this command makes sure that all the items on this list level use the same bullet. Furthermore, if this is an ordered list, make sure the numbering is OK. C-c - (org-ctrl-c-minus) Cycle the entire list level through the different item- ize/enumerate bullets (`-', `+', `*', `1.', `1)'). With a numeric prefix argument N, select the Nth bullet from this list. If there is an active region when calling this, all lines will be converted to list items. If the first line already was a list item, any item markers will be removed from the list. Finally, even without an active region, a normal line will be converted into a list item. C-c * (org-ctrl-c-star) Turn a plain list item into a headline (so that it becomes a subheading at its location). See Section 2.5 [Structure editing], page 7, for a detailed explanation. For these cases the dispatcher command could be replaced with the specific command that will be called by the dispatcher when in this context.. - Carsten But even this gives a clue in how it all works. ___ 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: TODO DONE strikethrough
Hi Mash, 'Mash wrote: > I could not (re)find a reference I saw a while back about setting DONE TODO > items with a strikethrough. > > Can anyone remember how to set this? Customize the face `org-done' to be something like this: --8<---cut here---start->8--- (org-done ((t (:foreground "green3" :weight bold :strike-through t --8<---cut here---end--->8--- (extract from my color-theme; can be done using the `customize-face' interface) 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] why not auto-renumbering list ?
Hello, > Carsten Dominik writes: > First, my apologies that I have so far not found the time to test > your improved list implementation. No worries, I needed that time anyways, as some internals have undergone big changes since then. I particularly think about the now (hopefully) working indent/outdent code, that was quite hairy to implement. > Have you had any testing feedback from anyone else so far? Not yet, unfortunately. > Have you tested it in all the export backends? Yes, on all major backends: HTML, LaTeX, ASCII and DocBook. Well, to be honest, in the case of DocBook, I only looked at the xml produced, and it seems valid to me. For this exporter, changes were very similar to those applied to the HTML one anyways. > I don't think anyone sets this to nil. But there is a use case for > this, if someone wants some strange specific numbering, > then it might be useful to allow turning it off. There is no harm > in having this possibility. There's always (in my branch): 2. [...@start:2] I like 3. prime numbered 5. [...@start:5] lists It sure is heavy on syntax, but benefit is that every exporter will reflect that unusual numbering. > While this sounds reasonable - it also unnecessary to me. > Why fix something that works? Because it is not consistent in the current implementation. Please have this test: Type the following list in an Org buffer, with `org-auto-renumber-ordered-lists' set to nil. 10. this is 1. first sub-item 2. second sub-item 11. a test 12. list Now, outdent first sub-item: top-level list gets renumbered, no matter what. Why? Worse: indentation of second sub-item is now wrong. Undo the indentation. Now cycle bullets of top level list once, to have parenthesis instead of dot after the number. There goes the numbering. And, again, exporters, except ASCII, will not take into consideration hand-numbered lists. This is not consistent either. As an intermediate solution, I can make `org-auto-renumber-ordered-lists' really block all renumbering attempt while still keeping indentation correct. It won't solve the exporter problem, though. I honestly don't think hand-numbering lists is a solution. I know Org is about simplicity, but [...@start:xx] enforced numbers definitely fare better here. And use cases are, in my opinion, so infrequent that it will not cripple Org simplicity either. 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] why not auto-renumbering list ?
> 2. [...@start:2] I like > 3. prime numbered > 5. [...@start:5] lists > It sure is heavy on syntax, but benefit is that every exporter will > reflect that unusual numbering. Thinking about it, we could even lighten [...@start:xx] syntax by making it [...@num]. It would also make more sense since it can be used repeatedly in a list. Thus: 6. [...@6] I like 28. [...@28] perfect numbered 496. [...@496] lists Regards, -- Nicolas ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: keys and command name info
Carsten Dominik wrote: > Some of the original arguments, that these names would stick > more easily and that it would make it easy for a hacker to > find the command name for rebinding, these do not fly, I think. > I don't think anyone calls Org commands with M-x, and if a > hacker needs to find a command name, `C-h b' and in particular > `C-h k' are the perfect ways to get to the names. > > I have put a version of the manual as modified by Andreas here: > >http://orgmode.org/org-manual-with-command-names.pdf > > Not all the command names are in there, but quite a few are. > I'd like to hear from more people > > - if they would like to have the names there (i.e. if it would > help them finding a command) > - if the position (first thing in the command description) > is right, or if it would be better to have it > - last thing in the description > - or after the first sentence, this is how the GNUS manual >does it. > > Thanks to Andreas for his work so far, and please, let me > hear more opinions. > I have wished for the command names to be in the manual before but as you say, C-h k works (although sometimes after the C-h k, I find myself saying "Oh, that one...", whereas I could have said that with a couple of keystrokes less if the name were in the manual :) ) As for the position, spot-checking the emacs manual shows the command name at the end of the first sentence in the key description and right after the key sequence in running text. Here's an example of both instances: , | `C-d' | `' | Delete next character (`delete-char'). If your keyboard has a | function key (usually located in the edit keypad), Emacs | binds it to `delete-char' as well. | | `' | `' | Delete previous character (`delete-backward-char'). | | `M-\' | Delete spaces and tabs around point (`delete-horizontal-space'). | | `M-' | Delete spaces and tabs around point, leaving one space | (`just-one-space'). | | `C-x C-o' | Delete blank lines around the current line (`delete-blank-lines'). | | `M-^' | Join two lines by deleting the intervening newline, along with any | indentation following it (`delete-indentation'). | |The most basic delete commands are `C-d' (`delete-char') and | (`delete-backward-char'). `C-d' deletes the character after point, the | ... ` I would vote for consistency above all. I also think (in contrast to Andreas Burtzlaff) that this helps newbies : I remember finding it very helpful when I first started writing elisp. And I also remember the (momentary) annoyance I felt when I was first reading the Org manual: I was used to the emacs manual conventions and habits die hard! My 2 cents, 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
[Orgmode] Install warning for org-7 for forgetful users
I ran into this, so I'll warn others. It might belong in the notes for org-7.01. If you have a newer version of emacs that has org already integrated, you get some, but not all, of the org-7.01 features functioning if you have org-7.01 set as the auto-load directory. I had been using org by having the lines: (setq load-path (cons "~/org-6.xxx/lisp" load-path)) (require 'org-install) in my .emacs. I forgot that I had upgraded emacs and org was now integrated into emacs. I just changed org-6.xxx to org-7.01g to try out the new version. Odd things resulted. It actually worked well enough to do some work, but then I found occasional stuff that did not work. I used the brute force fix of just moving all the org-* files into a temporary directory, thus slowing down the startup but ensuring that I could test the new version without having headaches if I wanted to revert. There might be a better method than this. It's probably worth mentioning in the release notes. ___ 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] Install warning for org-7 for forgetful users
Yeah, this is a big issue and I haven't seen it being mentioned on the org manual. Emacs has org integrated, which is good for casual users, and for org of course, but creates some headaches if you want to stay on the bleeding edge of development. I also did what you have done, in my case, on OSX, cd'ed into Emacs.app and removed org manually, then it started loading my version of org. The details should be in a previous post of mine in this list. Marcelo. On Mon, Aug 9, 2010 at 10:16 AM, Robert Horn wrote: > I ran into this, so I'll warn others. It might belong in the notes for > org-7.01. > > If you have a newer version of emacs that has org already integrated, > you get some, but not all, of the org-7.01 features functioning if you > have org-7.01 set as the auto-load directory. I had been using org by > having the lines: > > (setq load-path (cons "~/org-6.xxx/lisp" load-path)) > (require 'org-install) > > in my .emacs. I forgot that I had upgraded emacs and org was now > integrated into emacs. I just changed org-6.xxx to org-7.01g to try out > the new version. Odd things resulted. It actually worked well enough > to do some work, but then I found occasional stuff that did not work. I > used the brute force fix of just moving all the org-* files into a > temporary directory, thus slowing down the startup but ensuring that I > could test the new version without having headaches if I wanted to revert. > > There might be a better method than this. It's probably worth > mentioning in the release notes. > > ___ > 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] [Bug] Refiling troubles with inlined Org (thru Babel)
Did you try C-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
[Orgmode] Re: keys and command name info
Gregor Zattler writes: > Hi Andreas, org-mode developers, > * Andreas Burtzlaff [09. Aug. 2010]: >> Carsten Dominik writes: >>> I have put a version of the manual as modified by Andreas here: >>> >>>http://orgmode.org/org-manual-with-command-names.pdf >>> >>> Not all the command names are in there, but quite a few are. >>> I'd like to hear from more people >>> >>> - if they would like to have the names there (i.e. if it would >>> help them finding a command) I would like the command names in the manual. - Emacs-lisp has a lovely tradition of naming functions *very* descriptively and not being afraid to use long names in the interests of accuracy. It's a shame to lose all that by displaying only key sequences. It's a linguistic world of its own and I like being exposed to it. - While one can do C-h k, that's not the same as the way one learns the function names by skimming the manual >>> - if the position (first thing in the command description) >>> is right, or if it would be better to have it >>> - last thing in the description >>> - or after the first sentence, this is how the GNUS manual >>>does it. I definitely would want them out on a line of their own with the key sequence. I liked the right-aligned model. Or if not right-aligned, is it possible not to have the comma? Maybe a different font? Dan >> >> Having the function names in the manual at all makes it look a bit >> overloaded and might lose us a couple of newbies, I think. Personally, I >> would not have use for it. >> >> If the names are included in the manual I strongly object to them being >> at the beginning of the first sentence. The fixed starting column of the >> sentences becomes variable and that makes it hard to skim through for >> those who don't want to read the function names. > > +1 for the same reasons. > > This is especially true for paragraphs like those: > > C-c C-n (outline-next-visible-heading) Next heading. > C-c C-p (outline-previous-visible-heading) Previous heading. > C-c C-f (org-forward-same-level) Next heading same level. > C-c C-b (org-backward-same-level) Previous heading same level. > C-c C-u (outline-up-heading) Backward to higher level heading. > C-c C-j (org-goto) Jump to a different place without changing the current > outline > visibility. Shows the document structure in a temporary buffer, where > you can > use the following keys to find your destination: > > >> What about having them in the same line as the keybinding but aligned to >> the right? >> >> `C-c [' org-agenda-file-to-front >> Add current file to the list of agenda files. The file is added to >> the front of the list. If it was already in the list, it is moved >> to the front. With prefix arg, file is added/moved to the end. >> >> It would make the manual longer, but at least it looks clean. >> It is easy to neglect the function names if one wants, and just as easy >> to skim through them. > > +1 for the same reasons. > But Andreas Röhlers original variant is IMHO even better: > >>| [ ... ] >>| `C-c [', org-agenda-file-to-front >>| Add current file to the list of agenda files. The file is added to >>| the front of the list. If it was already in the list, it is moved >>| to the front. With prefix Argument, file is added/moved to the end. Yes, but let's lose the extra comma. `C-c [' org-agenda-file-to-front > > Here the command name serves as a kind of a heading, it's easy > to search these locations while at the same time it's easy to > skim over the pages and not bother with the command names. > > > > My preference: > > 1. as in Andreas Röhlers original ASCII rendering > 2. as in Andreas Burtzlaffs ASCII rendering > 3. not at all > 4. as in the test manual > > > > Just me 2¢. Either way, org-mode is great. Gregor > > > P.S.: Some of the command names don't help that much: > > C-c C-c (org-ctrl-c-ctrl-c) If there is a checkbox (see Section 5.6 > [Checkboxes], > page 46) in the item line, toggle the state of the checkbox. If not, > this command > makes sure that all the items on this list level use the same bullet. > Furthermore, > if this is an ordered list, make sure the numbering is OK. > C-c - (org-ctrl-c-minus) Cycle the entire list level through the different > item- > ize/enumerate bullets (`-', `+', `*', `1.', `1)'). With a numeric > prefix argument > N, select the Nth bullet from this list. If there is an active region > when calling > this, all lines will be converted to list items. If the first line > already was a list > item, any item markers will be removed from the list. Finally, even > without an > active region, a normal line will be converted into a list item. > C-c * (org-ctrl-c-star) Turn a plain list item into a headline (so that it > becomes > a subheading at its location). See Section 2.5 [St
Re: [Orgmode] [Bug] Refiling troubles with inlined Org (thru Babel)
Hi Seb, If you edit the contents of your org source blocks using org-edit-special (bound to C-c ') then it will protect org-mode syntax and prevent these sort of issues. Best -- Eric Sébastien Vauban writes: > Hello, > > Here is a complete minimal example... > > #+TITLE: Refiling troubles with inlined Org > #+AUTHOR:Sebastien Vauban > #+DATE: 2010-08-09 > #+DESCRIPTION: > #+KEYWORDS: > #+LANGUAGE: en_US > > * First section > > ** The item I wanna refile > > I'm trying to refile this subtree to the "second one" section. > > #+BEGIN_SRC org > ** Totals > *** Using a table formula > #+END_SRC > > This causes troubles, as you already can see just by marking this subtree > (`C-c @'). > > * Second one > > Best regards, > Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: Re[6]: [Orgmode] programming for org-mode
Ivanov Dmitry wrote: >I modified the scheme and the function. I think, that these 2 if-s >just complicate the code for comprehension: we have 3 cases, for each >of them we should return the appropriate value. Yes, `cond' is more suitable here. >All the tests work fine with the new version. >When I tried >(org-read-prop "(1 2 3))") -> (1 2 3) >It gave me (1 2 3), ignoring the last ')'. Seems to be the read >function bug. Not sure if it is a bug or the indended behavior. `read' returns the first valid lisp expression in finds. E.g. (read "(a b c) foo bar") => (a b c) I think this is good enough at this place. A complete solutation would require to parse the entire string. >At last I got rid of these nasty little squares on the scheme :) :D Of course the next step for you would be to tame the beast called git and prepare a proper patch. The steps are: 1. create a topic branch for the fix 2. change the function, commit to topic branch and provide a proper commit message (http://orgmode.org/worg/org-contribute.php#sec-4) 3. create a patch against current master 4. send the patch manually or using git send-email Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpUzKCyn824n.pgp Description: PGP signature ___ 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: keys and command name info
Dan Davison writes: > Gregor Zattler writes: > >> Hi Andreas, org-mode developers, >> * Andreas Burtzlaff [09. Aug. 2010]: >>> Carsten Dominik writes: I have put a version of the manual as modified by Andreas here: http://orgmode.org/org-manual-with-command-names.pdf Not all the command names are in there, but quite a few are. I'd like to hear from more people - if they would like to have the names there (i.e. if it would help them finding a command) > > I would like the command names in the manual. > > - Emacs-lisp has a lovely tradition of naming functions *very* > descriptively and not being afraid to use long names in the interests > of accuracy. It's a shame to lose all that by displaying only key > sequences. It's a linguistic world of its own and I like being exposed > to it. > - While one can do C-h k, that's not the same as the way one learns the > function names by skimming the manual Also, it does not add length to the HTML version of the manual, because the key sequences are already on a line of their own. And the same is true for a certain proportion of the pdf entries (when the key sequence is long, then it seems to go on its own line). > - if the position (first thing in the command description) is right, or if it would be better to have it - last thing in the description - or after the first sentence, this is how the GNUS manual does it. > > I definitely would want them out on a line of their own with the key > sequence. I liked the right-aligned model. > > Or if not right-aligned, is it possible not to have the comma? Maybe a > different font? > > Dan > >>> >>> Having the function names in the manual at all makes it look a bit >>> overloaded and might lose us a couple of newbies, I think. Personally, I >>> would not have use for it. >>> >>> If the names are included in the manual I strongly object to them being >>> at the beginning of the first sentence. The fixed starting column of the >>> sentences becomes variable and that makes it hard to skim through for >>> those who don't want to read the function names. >> >> +1 for the same reasons. >> >> This is especially true for paragraphs like those: >> >> C-c C-n (outline-next-visible-heading) Next heading. >> C-c C-p (outline-previous-visible-heading) Previous heading. >> C-c C-f (org-forward-same-level) Next heading same level. >> C-c C-b (org-backward-same-level) Previous heading same level. >> C-c C-u (outline-up-heading) Backward to higher level heading. >> C-c C-j (org-goto) Jump to a different place without changing the current >> outline >> visibility. Shows the document structure in a temporary buffer, >> where you can >> use the following keys to find your destination: >> >> >>> What about having them in the same line as the keybinding but aligned to >>> the right? >>> >>> `C-c [' org-agenda-file-to-front >>> Add current file to the list of agenda files. The file is added to >>> the front of the list. If it was already in the list, it is moved >>> to the front. With prefix arg, file is added/moved to the end. >>> >>> It would make the manual longer, but at least it looks clean. >>> It is easy to neglect the function names if one wants, and just as easy >>> to skim through them. >> >> +1 for the same reasons. >> But Andreas Röhlers original variant is IMHO even better: >> >>>| [ ... ] >>>| `C-c [', org-agenda-file-to-front >>>| Add current file to the list of agenda files. The file is added to >>>| the front of the list. If it was already in the list, it is moved >>>| to the front. With prefix Argument, file is added/moved to the end. > > Yes, but let's lose the extra comma. > > `C-c [' org-agenda-file-to-front > > > > > >> >> Here the command name serves as a kind of a heading, it's easy >> to search these locations while at the same time it's easy to >> skim over the pages and not bother with the command names. >> >> >> >> My preference: >> >> 1. as in Andreas Röhlers original ASCII rendering >> 2. as in Andreas Burtzlaffs ASCII rendering >> 3. not at all >> 4. as in the test manual >> >> >> >> Just me 2¢. Either way, org-mode is great. Gregor >> >> >> P.S.: Some of the command names don't help that much: >> >> C-c C-c (org-ctrl-c-ctrl-c) If there is a checkbox (see Section 5.6 >> [Checkboxes], >> page 46) in the item line, toggle the state of the checkbox. If not, >> this command >> makes sure that all the items on this list level use the same >> bullet. Furthermore, >> if this is an ordered list, make sure the numbering is OK. >> C-c - (org-ctrl-c-minus) Cycle the entire list level through the different >> item- >> ize/enumerate bullets (`-', `+', `*', `1.', `1)'). With a numeric >> prefix argument >> N, select the Nth bullet from this list. If there is an active >> region
Re: [Orgmode] What license for Worg?
Bastien wrote: >Hi Tycho, >tycho garen writes: >> This seems fine, the only possible concern that I have with this is >> that GFDL licensed code snippets aren't compatible with the GPL. I'm >> not sure how much actual code is in worg, and if this is an issue, but >> it's worth considering. >Mhh.. yes, you're right. >> My impulse for free-software-style writing projects is to use the >> emacs wiki license statement which says CC-BY-SA/GFDL/GPL 3 or later >> (with a clarification of what constitutes "corresponding source >> code"), but that might be a bit vague in some cases. >Here is what I read at the bottom of every emacswiki.org page: > This work is licensed to you under version 2 of the GNU General Public > License. Alternatively, you may choose to receive this work under any > other license that grants the right to use, copy, modify, and/or > distribute the work, as long as that license imposes the restriction > that derivative works have to grant the same rights and impose the > same restriction. For example, you may choose to receive this work > under the GNU Free Documentation License, the CreativeCommons > ShareAlike License, the XEmacs manual license, or similar licenses. >So this is GPLv2. Any idea why this isn't GPLv3? >Also, I find the formulation a bit confusing. Is it the standard >formulation when multi-licensing? Where can I found an example of a >clear multi-licensing statement? IIRC there was some back and forth about compatibility of this statement and the GPL, but cannot remember where I read this. This is obvious, but why not just drop a message to FSF legal team with the question about this issue? After all, Org mode is part of Gnu Emacs and Worg is Org's community page. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpRqXhQ1zICU.pgp Description: PGP signature ___ 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] FYI: Spanish translation of Org mode manual and blog post about "Timestamp calculations in Emacs with org-mode"
These two things recently hit my inbox: Timestamp calculations in Emacs with org-mode http://www.hollenback.net/index.php/EmacsOrgTimestamps (via emacswiki.org) Manual de Org http://gnu.manticore.es/manual-org-emacs (via emacswiki.org) Best, -- David pgpstcYHcOr0S.pgp Description: PGP signature ___ 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] Install warning for org-7 for forgetful users
Hi, the installation instructions for Org tell you that you need make the autoload file org-install.el by typing make. If you do not do this, autoloading will be broken. If you do, I do not see what would go wrong. - Carsten On Aug 9, 2010, at 7:58 PM, Marcelo de Moraes Serpa wrote: Yeah, this is a big issue and I haven't seen it being mentioned on the org manual. Emacs has org integrated, which is good for casual users, and for org of course, but creates some headaches if you want to stay on the bleeding edge of development. I also did what you have done, in my case, on OSX, cd'ed into Emacs.app and removed org manually, then it started loading my version of org. The details should be in a previous post of mine in this list. Marcelo. On Mon, Aug 9, 2010 at 10:16 AM, Robert Horn wrote: I ran into this, so I'll warn others. It might belong in the notes for org-7.01. If you have a newer version of emacs that has org already integrated, you get some, but not all, of the org-7.01 features functioning if you have org-7.01 set as the auto-load directory. I had been using org by having the lines: (setq load-path (cons "~/org-6.xxx/lisp" load-path)) (require 'org-install) in my .emacs. I forgot that I had upgraded emacs and org was now integrated into emacs. I just changed org-6.xxx to org-7.01g to try out the new version. Odd things resulted. It actually worked well enough to do some work, but then I found occasional stuff that did not work. I used the brute force fix of just moving all the org-* files into a temporary directory, thus slowing down the startup but ensuring that I could test the new version without having headaches if I wanted to revert. There might be a better method than this. It's probably worth mentioning in the release notes. ___ 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 - 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] FYI: Spanish translation of Org mode manual and blog post about "Timestamp calculations in Emacs with org-mode"
On Aug 9, 2010, at 9:50 PM, David Maus wrote: These two things recently hit my inbox: Timestamp calculations in Emacs with org-mode http://www.hollenback.net/index.php/EmacsOrgTimestamps (via emacswiki.org) Manual de Org http://gnu.manticore.es/manual-org-emacs (via emacswiki.org) I am now linking to this from the homepage. Can anyone with a bit more spanish knowledge identify the translator, so that I can credit him? 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
[Orgmode] Re: [Bug] Refiling troubles with inlined Org (thru Babel)
Hi Eric and Samuel, "Eric Schulte" wrote: >> #+BEGIN_SRC org >> ** Totals >> *** Using a table formula >> #+END_SRC > > If you edit the contents of your org source blocks using org-edit-special > (bound to C-c ') then it will protect org-mode syntax and prevent these sort > of issues. Did not know about that extra step. Sorry for that. Thanks anyway! 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] FYI: Spanish translation of Org mode manual and blog post about "Timestamp calculations in Emacs with org-mode"
Carsten Dominik wrote: > > On Aug 9, 2010, at 9:50 PM, David Maus wrote: > > > These two things recently hit my inbox: > > > > Timestamp calculations in Emacs with org-mode > > http://www.hollenback.net/index.php/EmacsOrgTimestamps > > (via emacswiki.org) > > > > Manual de Org > > http://gnu.manticore.es/manual-org-emacs > > (via emacswiki.org) > > I am now linking to this from the homepage. Can anyone with a bit > more spanish knowledge identify the translator, so that I can credit > him? > The Credits section has an "English" button that says: , | This site initially claims to be a sort of quasi-personal page with | some suggestions and contributions on Emacs, as a framework for ideas | and projects that the manticore association has for the near future: | therefore focuses considerably on the Internationalization (i18n) and | the "end users". | | I am smc here at manticore dot es. You can write me there if you | wish, for matters relating to the GNU operating system and GNU Emacs | and the like. | | This site was made with Drupal. It is not meant -yet- for the massive | registration of unoccupied surfers, so you will not see the option to | "register", but you can get it as always through ?q=user. | | Everything that is published here is under the terms of the GNU Free | Documentation License (GFDL), the most updated version provided by the | Free Software Foundation (FSF). In the case of translations or | documentation that has to do with official GNU packages, I transfer | copyright to the FSF. ` HTH, 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] FYI: Spanish translation of Org mode manual and blog post about "Timestamp calculations in Emacs with org-mode"
On Aug 9, 2010, at 10:14 PM, Nick Dokos wrote: Carsten Dominik wrote: On Aug 9, 2010, at 9:50 PM, David Maus wrote: These two things recently hit my inbox: Timestamp calculations in Emacs with org-mode http://www.hollenback.net/index.php/EmacsOrgTimestamps (via emacswiki.org) Manual de Org http://gnu.manticore.es/manual-org-emacs (via emacswiki.org) I am now linking to this from the homepage. Can anyone with a bit more spanish knowledge identify the translator, so that I can credit him? The Credits section has an "English" button that says: , | This site initially claims to be a sort of quasi-personal page with | some suggestions and contributions on Emacs, as a framework for ideas | and projects that the manticore association has for the near future: | therefore focuses considerably on the Internationalization (i18n) and | the "end users". | | I am smc here at manticore dot es. You can write me there if you | wish, for matters relating to the GNU operating system and GNU Emacs | and the like. | | This site was made with Drupal. It is not meant -yet- for the massive | registration of unoccupied surfers, so you will not see the option to | "register", but you can get it as always through ?q=user. | | Everything that is published here is under the terms of the GNU Free | Documentation License (GFDL), the most updated version provided by the | Free Software Foundation (FSF). In the case of translations or | documentation that has to do with official GNU packages, I transfer | copyright to the FSF. ` No name here either, right? - Carsten HTH, 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
[Orgmode] Re: How to get pretty printed source code in PDFLaTeX
Hi Dan,
Dan Davison wrote:
> Sébastien Vauban
> writes:
>> Sebastian Rose wrote:
>>> Dan Davison writes:
Can you point me to an example that shows how to make source code in
latex look (almost) as nice as html?
>>>
>>> That is supposed to work with the `listings' package. I havent tried that
>>> yet.
>>
>> If I understand you right, here's such an example you're after:
>>
>> * Much better code
>>
>> For that, you need to customize =listings=:
>>
>> #+begin_LaTeX
>> % typeset source code listings
>> \usepackage{listings} % must be loaded after `babel'
>> \lstloadlanguages{C}
>> \definecolor{...@lstbackground}{html}{cc} % light yellow
>> \definecolor{...@lstkeyword}{html}{ff} % blue
>> \definecolor{...@lstidentifier}{html}{00} % black
>> \definecolor{...@lstcomment}{html}{ff} % red
>> \definecolor{...@lststring}{html}{008000} % dark green
>> \lstset{%
>> basicstyle=\ttfamily\scriptsize, % the font that is used for the code
>> tabsize=4, % sets default tabsize to 4 spaces
>> numbers=left, % where to put the line numbers
>> numberstyle=\tiny, % line number font size
>> stepnumber=0, % step between two line numbers
>> breaklines=false, %!! don't break long lines of code
>> showtabs=false, % show tabs within strings adding particular underscores
>> showspaces=false, % show spaces adding particular underscores
>> showstringspaces=false, % underline spaces within strings
>> keywordstyle=\color{...@lstkeyword},
>> identifierstyle=\color{...@lstidentifier},
>> stringstyle=\color{...@lststring},
>> commentstyle=\color{...@lstcomment},
>> backgroundcolor=\color{...@lstbackground}, % sets the background color
>> captionpos=b, % sets the caption position to `bottom'
>> extendedchars=false %!?? workaround for when the listed file is in UTF-8
>> }
>> #+end_LaTeX
>>
>> #+SRCNAME: srcModifyDB2.sql
>> #+BEGIN_SRC sql :tangle srcModifyDB.sql
>> -- add column `DossierSentToSecteur' (if column does not exist yet)
>> IF NOT EXISTS (SELECT *
>>FROM INFORMATION_SCHEMA.COLUMNS
>>WHERE TABLE_NAME = 'dossier'
>>AND COLUMN_NAME = 'DossierSentToSecteur')
>> BEGIN
>> ALTER TABLE dossier
>> ADD DossierSentToSecteur smalldatetime NULL
>> END
>> GO
>> #+END_SRC
>>
>> I've put the PDF (for easy access) onto my Web site:
>>
>> http://www.mygooglest.com/sva/ECM-Listings.pdf
>
> Wow, that's really nice. Thanks for sharing that.
I really thought that you used such a thing for a long time, having done so
much for Org-Babel. Maybe you were more interested by the execution stuff,
rather than its printing? For me, the opposite: I was much interested by the
printing, now by accessing all the power of Babel.
> I think we should aim to get to a point where org-mode can produce such
> nicely formatted source code out-of-the-box.
I share your point. I'm willing to participate, or even begin, such a page on
Worg, with the above info.
> Maybe we could even make latex inherit the colours and fonts that emacs is
> currently using for source code mark up?
For sure, that'd be nice. You mean the way htmlize works, and keeps my colors,
right?
Dunno what it implies for Org-LaTeX... Generating your own class customization,
and having it loaded by default (in the list of LaTeX packages)?
> I was going to suggest doing this with listings but then came across minted,
> and I wonder whether that's even more suitable? (See the other post I just
> made.)
Never heard about it before, while I'm trying to follow info about TeX as
well.
I'm very impressed by the quality and reaction time of
french.computers.text.tex. So, I decided to ask them what they thought about
Listings vs Minted.
See on
[[http://groups.google.com/groups/search?as_umsgid%3D87lj8gp4rr.fsf%40mundaneum.com][Email
from Sébastien Vauban: Listings vs Minted]]
What's interesting is that 2 brilliant people of that list responded on that.
I could try to translate the whole, but there already is a lot. Just
highlighting that they don't trust that much all the facts that have been used
against Listings (and prove what they say): about Utf-8, or the number of
languages, etc.
They agree with one inconvenient of Listings: the fact that, by default, it
uses bad settings (like no color, and proportional font).
On the other hand, they don't like implying the use of an external language to
LaTeX. Impacts on shell-escape.
The discussion is going on. I'll keep you posted.
For sure, the objective of getting better out-of-the-box is a goal we can
reach.
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: FYI: Spanish translation of Org mode manual and blog post about "Timestamp calculations in Emacs with org-mode"
Carsten Dominik writes: > On Aug 9, 2010, at 10:14 PM, Nick Dokos wrote: > >> Carsten Dominik wrote: >> >>> >>> On Aug 9, 2010, at 9:50 PM, David Maus wrote: >>> These two things recently hit my inbox: Timestamp calculations in Emacs with org-mode http://www.hollenback.net/index.php/EmacsOrgTimestamps (via emacswiki.org) Manual de Org http://gnu.manticore.es/manual-org-emacs (via emacswiki.org) >>> >>> I am now linking to this from the homepage. Can anyone with a bit >>> more spanish knowledge identify the translator, so that I can credit >>> him? >>> >> >> The Credits section has an "English" button that says: >> >> , >> | This site initially claims to be a sort of quasi-personal page with >> | some suggestions and contributions on Emacs, as a framework for >> ideas >> | and projects that the manticore association has for the near future: >> | therefore focuses considerably on the Internationalization (i18n) >> and >> | the "end users". >> | >> | I am smc here at manticore dot es. You can write me there if you >> | wish, for matters relating to the GNU operating system and GNU Emacs >> | and the like. >> | >> | This site was made with Drupal. It is not meant -yet- for the >> massive >> | registration of unoccupied surfers, so you will not see the option >> to >> | "register", but you can get it as always through ?q=user. >> | >> | Everything that is published here is under the terms of the GNU Free >> | Documentation License (GFDL), the most updated version provided by >> the >> | Free Software Foundation (FSF). In the case of translations or >> | documentation that has to do with official GNU packages, I transfer >> | copyright to the FSF. >> ` > > No name here either, right? But a hint: "I am smc here at manticore dot es." That's either an email address or some username at the site. Here is the message announcing the translation: http://gnu.manticore.es/node/638 Maybe they respond to a comment to that message? Andreas > > - Carsten > >> >> HTH, >> 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 Andreas ___ 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: FYI: Spanish translation of Org mode manual and blog post about "Timestamp calculations in Emacs with org-mode"
On Aug 9, 2010, at 10:50 PM, Andreas Burtzlaff wrote: Carsten Dominik writes: On Aug 9, 2010, at 10:14 PM, Nick Dokos wrote: Carsten Dominik wrote: On Aug 9, 2010, at 9:50 PM, David Maus wrote: These two things recently hit my inbox: Timestamp calculations in Emacs with org-mode http://www.hollenback.net/index.php/EmacsOrgTimestamps (via emacswiki.org) Manual de Org http://gnu.manticore.es/manual-org-emacs (via emacswiki.org) I am now linking to this from the homepage. Can anyone with a bit more spanish knowledge identify the translator, so that I can credit him? The Credits section has an "English" button that says: , | This site initially claims to be a sort of quasi-personal page with | some suggestions and contributions on Emacs, as a framework for ideas | and projects that the manticore association has for the near future: | therefore focuses considerably on the Internationalization (i18n) and | the "end users". | | I am smc here at manticore dot es. You can write me there if you | wish, for matters relating to the GNU operating system and GNU Emacs | and the like. | | This site was made with Drupal. It is not meant -yet- for the massive | registration of unoccupied surfers, so you will not see the option to | "register", but you can get it as always through ?q=user. | | Everything that is published here is under the terms of the GNU Free | Documentation License (GFDL), the most updated version provided by the | Free Software Foundation (FSF). In the case of translations or | documentation that has to do with official GNU packages, I transfer | copyright to the FSF. ` No name here either, right? But a hint: "I am smc here at manticore dot es." That's either an email address or some username at the site. Here is the message announcing the translation: http://gnu.manticore.es/node/638 Maybe they respond to a comment to that message? I am trying, 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
[Orgmode] [babel] strategies for generating multiple graphics files from same code block
Hello, I'm using org-mode to write R code and generate figures. I have multiple files generated per code block, one png and one PDF. This is so that I can display the graphic: 1) Inline in my org-mode buffer (png) 2) Upon export to HTML, viewable in the browser (png) 3) Included in a separate PDF, *not* from exporting my org-mode file. For this, I would like a PDF version of the graphic to be generated, and pdflatex can use it (pdf) So, for points 1 and 2 above, no problem. * Figure 1 Here is the first figure. #+begin_src R :file figure1.png :width 960 :exports both :tangle fig1.R plot(1,1) #+end_src For point 3, I use tangling to write the source code to a file. I notice that the graphical code is wrapped by the export process by a call to png() and dev.off(). My question, is there any facility to have the tangled code generate a PDF, instead of PNG? I still need the png for goals 1 and 2, but the pdf for goal 3. Anyone else have any other strategies for realizing all 3 of my goals? I suppose one would be to define a named code block, and use the noweb syntax: Define the plot #+srcname: fig-test #+begin_src R plot(1,1) #+end_src Tangle, but don't export #+begin_src R :file figure1.pdf :exports none :tangle fig1.R :noweb yes <> #+end_src Export, but don't tangle #+begin_src R :file figure1.png :exports both :noweb yes <> #+end_src This is not too bad, but maybe there's an alternative approach? Thanks! Erik Iverson ___ 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] FYI: Spanish translation of Org mode manual and blog post about "Timestamp calculations in Emacs with org-mode"
Carsten Dominik wrote: > > , ... > > | I am smc here at manticore dot es. ... > > ` > > No name here either, right? > No name, but there is an email address. 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
[Orgmode] Re: [PATCH] Mode-specific fontification of babel source blocks
Dan Davison writes:
> "David O'Toole" writes:
>
>> I've got a preliminary patch that adds optional "native" fontification
>> for source blocks. It uses the block's declared mode to fontify the
>> block text. So now blocks look the way they should, and this opens the
>> way to further enhancements.
>
> Hi David,
>
> This is great! Here's a patch which allows the src blocks to have
> switches and header args, and also uses `org-src-lang-modes' to find the
> major mode.
I'm resending this as a match against the current master branch, and as
an attachment so that it goes into the patchwork system. I am keeping
this line of patches in branch `src-block-fontification' at
git://github.com/dandavison/org-devel.git
Dan
diff --git a/lisp/org.el b/lisp/org.el
index af4f793..ef6e769 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5017,17 +5017,24 @@ will be prompted for."
'(display t invisible t intangible t))
t)))
+(defvar org-src-fontify-natively nil
+ "When non-nil, fontify source blocks like their major mode would.")
+
(defun org-fontify-meta-lines-and-blocks (limit)
"Fontify #+ lines and blocks, in the correct ways."
(let ((case-fold-search t))
(if (re-search-forward
- "^\\([ \t]*#\\+\\(\\([a-zA-Z]+:?\\| \\|$\\)\\(_\\([a-zA-Z]+\\)\\)?\\)\\(.*\\)\\)"
+ ;; 12 3 3 4 5 5 4 26 677 1
+ "^\\([ \t]*#\\+\\(\\([a-zA-Z]+:?\\| \\|$\\)\\(_\\([a-zA-Z]+\\)\\)?\\)[ \t]*\\([^ \t\n]*\\)[ \t]*\\(.*\\)\\)"
limit t)
- (let ((beg (match-beginning 0))
- (beg1 (line-beginning-position 2))
- (dc1 (downcase (match-string 2)))
- (dc3 (downcase (match-string 3)))
- end end1 quoting block-type)
+ (let* ((beg (match-beginning 0))
+ (block-start (match-end 0))
+ (block-end nil)
+ (language (match-string 6))
+ (beg1 (line-beginning-position 2))
+ (dc1 (downcase (match-string 2)))
+ (dc3 (downcase (match-string 3)))
+ end end1 quoting block-type)
(cond
((member dc1 '("html:" "ascii:" "latex:" "docbook:"))
;; a single line of backend-specific content
@@ -5047,6 +5054,7 @@ will be prompted for."
(concat "^[ \t]*#\\+end" (match-string 4) "\\>.*")
nil t) ;; on purpose, we look further than LIMIT
(setq end (match-end 0) end1 (1- (match-beginning 0)))
+ (setq block-end (match-beginning 0))
(when quoting
(remove-text-properties beg end
'(display t invisible t intangible t)))
@@ -5056,6 +5064,28 @@ will be prompted for."
(add-text-properties beg beg1 '(face org-meta-line))
(add-text-properties end1 end '(face org-meta-line))
(cond
+ ((and org-src-fontify-natively language)
+ (let* ((lang-mode
+ (or (cdr (assoc language org-src-lang-modes)) (intern language)))
+ (mode-command (intern (concat (symbol-name lang-mode) "-mode")))
+ (string (buffer-substring-no-properties block-start block-end))
+ (modified (buffer-modified-p))
+ (fontified-output
+ (with-temp-buffer
+ (insert string)
+ (message language)
+ (funcall mode-command)
+ (font-lock-fontify-buffer)
+ (add-text-properties
+ (point-min) (point-max)
+ '(font-lock-fontified t fontified t font-lock-multiline t))
+ (buffer-substring (point-min) (point-max)
+ (when fontified-output
+ (assert (stringp fontified-output))
+ (goto-char block-start)
+ (delete-region block-start block-end)
+ (insert fontified-output)
+ (set-buffer-modified-p modified
(quoting
(add-text-properties beg1 end1 '(face org-block)))
((not org-fontify-quote-and-verse-blocks))
___
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] need detailed instructions for submitting the patch
The http://orgmode.org/worg/org-contribute.php#sec-3 says: "Git can be used to make patches and send them via email - this is perfectly fine for minor changes. These patches will be automatically registered at John Wiegley's patchwork server" Please, tell me, what commands should I run to create a patch, upload it and get any feedback from the senior developers? I think, that these commands should be added to the manual, so everybody would know, how to do it. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [babel] strategies for generating multiple graphics files from same code block
Hi Erik, There is a planned feature for Org-babel which should subsume these use cases, namely backend-conditional header arguments. These would allow you to specify different header arguments (including file) depending on the export target, be that html, latex, or none if you are just interactively evaluating inside of an Org-mode buffer. This is still in the early stages, and is waiting until I have a reasonable amount of free time. Cheers -- Eric Erik Iverson writes: > Hello, > > I'm using org-mode to write R code and generate figures. > > I have multiple files generated per code block, one png and one PDF. > This is so that I can display the graphic: > > 1) Inline in my org-mode buffer (png) > 2) Upon export to HTML, viewable in the browser (png) > 3) Included in a separate PDF, *not* from exporting my org-mode > file. For this, I would like a PDF version of the graphic to be > generated, and pdflatex can use it (pdf) > > So, for points 1 and 2 above, no problem. > > * Figure 1 > Here is the first figure. > > #+begin_src R :file figure1.png :width 960 :exports both :tangle fig1.R > plot(1,1) > #+end_src > > For point 3, I use tangling to write the source code to a file. I > notice that the graphical code is wrapped by the export process by a > call to png() and dev.off(). > > My question, is there any facility to have the tangled code generate a > PDF, instead of PNG? I still need the png for goals 1 and 2, but the > pdf for goal 3. Anyone else have any other strategies for realizing > all 3 of my goals? > > I suppose one would be to define a named code block, and use the noweb > syntax: > > Define the plot > #+srcname: fig-test > #+begin_src R > plot(1,1) > #+end_src > > Tangle, but don't export > #+begin_src R :file figure1.pdf :exports none :tangle fig1.R :noweb yes > <> > #+end_src > > Export, but don't tangle > #+begin_src R :file figure1.png :exports both :noweb yes > <> > #+end_src > > This is not too bad, but maybe there's an alternative approach? > > Thanks! > Erik Iverson > > ___ > 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] [babel] strategies for generating multiple graphics files from same code block
Sounds good, and perhaps another 'export' target could be tangling of the code. On 08/09/2010 06:00 PM, Eric Schulte wrote: Hi Erik, There is a planned feature for Org-babel which should subsume these use cases, namely backend-conditional header arguments. These would allow you to specify different header arguments (including file) depending on the export target, be that html, latex, or none if you are just interactively evaluating inside of an Org-mode buffer. This is still in the early stages, and is waiting until I have a reasonable amount of free time. Cheers -- Eric Erik Iverson writes: Hello, I'm using org-mode to write R code and generate figures. I have multiple files generated per code block, one png and one PDF. This is so that I can display the graphic: 1) Inline in my org-mode buffer (png) 2) Upon export to HTML, viewable in the browser (png) 3) Included in a separate PDF, *not* from exporting my org-mode file. For this, I would like a PDF version of the graphic to be generated, and pdflatex can use it (pdf) So, for points 1 and 2 above, no problem. * Figure 1 Here is the first figure. #+begin_src R :file figure1.png :width 960 :exports both :tangle fig1.R plot(1,1) #+end_src For point 3, I use tangling to write the source code to a file. I notice that the graphical code is wrapped by the export process by a call to png() and dev.off(). My question, is there any facility to have the tangled code generate a PDF, instead of PNG? I still need the png for goals 1 and 2, but the pdf for goal 3. Anyone else have any other strategies for realizing all 3 of my goals? I suppose one would be to define a named code block, and use the noweb syntax: Define the plot #+srcname: fig-test #+begin_src R plot(1,1) #+end_src Tangle, but don't export #+begin_src R :file figure1.pdf :exports none :tangle fig1.R :noweb yes <> #+end_src Export, but don't tangle #+begin_src R :file figure1.png :exports both :noweb yes <> #+end_src This is not too bad, but maybe there's an alternative approach? Thanks! Erik Iverson ___ 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] need detailed instructions for submitting the patch
On Tue, Aug 10, 2010 at 01:59:57AM +0400, Ivanov Dmitry wrote: > The http://orgmode.org/worg/org-contribute.php#sec-3 says: > "Git can be used to make patches and send them via email - this is > perfectly fine for minor changes. These patches will be > automatically registered at John Wiegley's patchwork server" > > Please, tell me, what commands should I run to create a patch, > upload it and get any feedback from the senior developers? The following command will make a patch between the staging area (in your computer), and the file you modified: git diff -p org-whatever.el If you already committed your changes to your index (staging area), then you should compare against a particular branch (in this example, origin/master): git diff -p origin/master org-whatever.el You email the output to this mailing list, adding [PATCH] to the subject, and description of what you fixed or changed. At least, this is how I do it. Regards, .j. ___ 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] notmuch support for org-mode?
On Tue, 10 Aug 2010 09:40:05 +1000, Bart Bunting wrote: > Hi all,, > > A while back a notmuch link patch was posted to the list. > > I think it was written by David Bremner but don't appear to be able to > find the exact mail now. > > Is there any update on the patch and or plans to include it in official > org-mode release? > Sadly the patches remain mired in negotiations between the FSF and my university as far as inclusion in an official org-mode release. But, you are welcome to use them in the mean time. You can find them at http://pivot.cs.unb.ca/git/?p=org-mode.git;a=shortlog;h=refs/heads/notmuch-link The network to that machine is down right now thanks to high voltage electrical work, but it should be up again tommorow. d ___ 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: need detailed instructions for submitting the patch
Juan writes: > On Tue, Aug 10, 2010 at 01:59:57AM +0400, Ivanov Dmitry wrote: >> The http://orgmode.org/worg/org-contribute.php#sec-3 says: >> "Git can be used to make patches and send them via email - this is >> perfectly fine for minor changes. These patches will be >> automatically registered at John Wiegley's patchwork server" >> >> Please, tell me, what commands should I run to create a patch, >> upload it and get any feedback from the senior developers? > > The following command will make a patch between the staging area > (in your computer), and the file you modified: > > git diff -p org-whatever.el > > If you already committed your changes to your index (staging area), > then you should compare against a particular branch (in this example, > origin/master): > > git diff -p origin/master org-whatever.el > > You email the output to this mailing list, adding [PATCH] to the > subject, and description of what you fixed or changed. > > At least, this is how I do it. > > Regards, > .j. It's easier to make real commits on a topic branch and use either git send-email or git format-patch to create the properly formatted patch files. I personally use git send-email --annotate -N (where N is the number of commits I want to create patches for. For example, git send-email --annotate -1 if it is a single commit) I have the following in my .git/config so that git send-email knows where to send the resulting patches ,[ .git/config ] | [sendemail] | to = emacs-orgmode@gnu.org ` Alternatively, git format-patch will create sequentially numbered files which you can edit and mail manually from your email client. HTH, Bernt ___ 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: keys and command name info
Dan Davison writes: > I would like the command names in the manual. > > - Emacs-lisp has a lovely tradition of naming functions *very* > descriptively and not being afraid to use long names in the interests > of accuracy. It's a shame to lose all that by displaying only key > sequences. It's a linguistic world of its own and I like being exposed > to it. > - While one can do C-h k, that's not the same as the way one learns the > function names by skimming the manual I am 'just a user', with next to nothing elisp skills under his belt. However, I am willing to learn and I try to modify simple bits to the best of my abilities. So, I should probably argue against inclusion of the command names... But I do not. I got into Emacs because of orgmode, but I did not stop there. The Info system is just great for discovering lots of possibilities, and I really got accustomed to seeing the elisp commands associated to the keybindings. Somehow, from the start right until this thread started, it feld curious to me that these are not "right there". Sure, I have less need for them in orgmode than in, say w3m or gnus, because the defaults are so great I never considered to change them, but I (as a still fairly recent Emacs user) felt the documentation - as great as it is! - to be somewhat out of the line in this regard. I do not see my behaviour will change over the times to come, and right, `C-h k' is available to everyone, but I still would humbly vote for following the accustomed style, i.e. including the elisp function names. It is, in my case, rather a vote motivated by consistency. Memnon ___ 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: What license for Worg?
Hi, > IIRC there was some back and forth about compatibility of this > statement and the GPL, but cannot remember where I read this. Thats exactly what I remembered, and I searched gmane for it. This topic (emacswiki and license) came up when bzr was adopted and the main document for transition was on emacswiki. If this is the thread you are referring to, its the one starting with this message: ,--- | From: Richard Stallman gnu.org> | Subject: Bad choice of license in BzrForEmacsDevs | Newsgroups: gmane.emacs.devel | Date: 2009-11-23 02:29:13 GMT (37 weeks, 23 hours and 4 minutes ago) | | http://www.emacswiki.org/emacs/BzrForEmacsDevs | allows GPL version 2, but not the current version. | This is not a good thing. Would the author(s) please | change it to allow future versions of the GNU GPL as well? | The documentation we recommend to Emacs developers has to | set a good example for licensing as well as have useful | information. | | Are there other pages on emacswiki.org which have this problem? ` Memnon ___ 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] text color + highlight
Hi,
>>
>> - this would be extensible, e.g.
>>
>> [background[yellow] highlighted text]
>>
>> could export to the following html
>>
>> highlighted text
>>
>> - this would avoid "{}"s
>>
>> - this would look more "org-like" than the pure latex solution
>>
>> the only issue with the above is that it may conflate a new /markup/
>> syntax with org-mode's existing /link/ syntax.
>>
>> Thoughts? -- Eric
I'd like an extensible inline markup construct (not primarily for coloring).
Would it make sense to hijack custom links for this purpose, and use
existing bracketed link syntax rather than add a new syntax?
For semantic tagging (my chief interest), one might e.g. define a
`class' link type and an HTML export handler to wrap the contents in
tags.
: [[class:animals][some text about animals]]
As for color: If one is satisfied with getting colors on export,
defining a `color' link type and appropriate export handlers will do.
: [[color:red][some colored text]]
If one also wants the text to appear in the right color within Org-mode,
and does not want the pseudo-link markup to be underlined and look like
links, it would require additional Org functionality (I think):
User-defined custom faces for different link types.
What syntax to use...
I've thought briefly about the following syntax
[color[red] text to be colored red]
Nope, I am against this syntax. If we introduce a more general syntax,
then it should be done in the way Samuel proposed. WHich means
we firs get a keyword indtroducing the piece, and then properties.
Like
$[style :color red the red text]
or
$[face :color :italic t red the red text]
Something like the $ before "[" also would seem critical to disambiguate
from other uses of "[".
However, I am not too excited about extra syntax to get this kind of thing.
Would not oppose it, but probably never use it.
- Carsten
Those examples are not very readable IMO -- without a separator it's
hard to see where the property values end and the marked up text begins.
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] Bug: org-insert-link path promt lacks tab-completion [7.01trans]
If I enter or edit a link with org-insert-link, I only get tab-completion for the URL prefix (e.g. fi puts "file"), but not for the path name for "file:" links. So, if I type C-c C-l file:~/.ema , I expect to get file:~/.emacs (the possibilities are .emacs and .emacs.d/), but all I get is the message "[No prefix completions]" in the minibuffer juxtaposed to what's already there (the message disappears after about a second). Emacs : GNU Emacs 24.0.50.10 (i686-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-08-09 on neko Package: Org-mode version 7.01trans current state: == (setq org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars) org-metaup-hook '(org-babel-load-in-session-maybe) org-after-todo-state-change-hook '(org-clock-out-if-current) org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup) org-export-latex-format-toc-function 'org-export-latex-format-toc-default 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-reveal-start-hook '(org-decrypt-entry) org-export-first-hook '(org-beamer-initialize-open-trackers) org-agenda-before-write-hook '(org-agenda-add-entry-text) 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 '((lambda nil (setq org-mouse-context-menu-function (quote org-mouse-context-menu)) (when (memq (quote context-menu) org-mouse-features) (org-defkey org-mouse-map [mouse-3] nil) (org-defkey org-mode-map [mouse-3] (quote org-mouse-show-context-menu)) ) (org-defkey org-mode-map [down-mouse-1] (quote org-mouse-down-mouse)) (when (memq (quote context-menu) org-mouse-features) (org-defkey org-mouse-map [C-drag-mouse-1] (quote org-mouse-move-tree)) (org-defkey org-mouse-map [C-down-mouse-1] (quote org-mouse-move-tree-start)) ) (when (memq (quote yank-link) org-mouse-features) (org-defkey org-mode-map [S-mouse-2] (quote org-mouse-yank-link)) (org-defkey org-mode-map [drag-mouse-3] (quote org-mouse-yank-link)) ) (when (memq (quote move-tree) org-mouse-features) (org-defkey org-mouse-map [drag-mouse-3] (quote org-mouse-move-tree)) (org-defkey org-mouse-map [down-mouse-3] (quote org-mouse-move-tree-start)) ) (when
[Orgmode] Re: How to get pretty printed source code in PDFLaTeX
Sébastien Vauban writes: > Hi Dan, > > Dan Davison wrote: >> Sébastien Vauban >> >> writes: >>> Sebastian Rose wrote: Dan Davison writes: > Can you point me to an example that shows how to make source code in > latex look (almost) as nice as html? That is supposed to work with the `listings' package. I havent tried that yet. >>> >>> If I understand you right, here's such an example you're after: >>> >>> * Much better code [...] >>> I've put the PDF (for easy access) onto my Web site: >>> >>> http://www.mygooglest.com/sva/ECM-Listings.pdf >> >> Wow, that's really nice. Thanks for sharing that. > > I really thought that you used such a thing for a long time, having done so > much for Org-Babel. Maybe you were more interested by the execution stuff, > rather than its printing? For me, the opposite: I was much interested by the > printing, now by accessing all the power of Babel. You're probably right that I should have looked into it. But seeing as the HTML export of code is so nice and requred no configuration, I never got round to it. Although I did write my Ph.D. in latex, and I am enjoying using the listings package for formatting pseudocode in a paper which I'm supposed to be writing, I do need to become better friends with latex, it's true. >> I think we should aim to get to a point where org-mode can produce such >> nicely formatted source code out-of-the-box. > > I share your point. I'm willing to participate, or even begin, such a page on > Worg, with the above info. > >> Maybe we could even make latex inherit the colours and fonts that emacs is >> currently using for source code mark up? > > For sure, that'd be nice. You mean the way htmlize works, and keeps my colors, > right? > > Dunno what it implies for Org-LaTeX... Generating your own class > customization, > and having it loaded by default (in the list of LaTeX packages)? Usage of listings is controlled by the variable `org-export-latex-listings', so the simplest start would be: if that is non-nil then code like yours could be inserted into the latex output. > >> I was going to suggest doing this with listings but then came across minted, >> and I wonder whether that's even more suitable? (See the other post I just >> made.) > > Never heard about it before, while I'm trying to follow info about TeX as > well. > > I'm very impressed by the quality and reaction time of > french.computers.text.tex. So, I decided to ask them what they thought about > Listings vs Minted. , | "sur un post de Dan Davison parlant d'un nouveau paquet qui | serait mieux que Listings." ` Hey, I never said that! :) I said it might be better *for export of code from org-mode*. But seriously, no problem, in addition to my character assassination, from what I could make out they made lots of good points. Although I will watch out now if I come across any francophones who look like they might be tex enthusiasts (wouldn't one always...) What I meant is that seeing as org-users who set `org-export-latex-listings' get black and white code with ugly fonts by default, there are two improvement options for us: 1. we work on incorporating nice listings configuration into org mode so that Org users get nice colours and fonts by default 2. we add an option to allow Org users to use the minted package, which gives them nice colours and fonts automatically. (2) was easy and so I did it straight away. And (1) is still something we want to do, not least because listings is in standard latex distributions and doesn't have an extra python requirement. Assuming that minted/pygments are stable software that will be around for a while, I would vote for both options ultimately being available in org-mode. > > See on > [[http://groups.google.com/groups/search?as_umsgid%3D87lj8gp4rr.fsf%40mundaneum.com][Email > from Sébastien Vauban: Listings vs Minted]] > > What's interesting is that 2 brilliant people of that list responded on that. > I could try to translate the whole, but there already is a lot. Just > highlighting that they don't trust that much all the facts that have been used > against Listings (and prove what they say): about Utf-8, or the number of > languages, etc. > > They agree with one inconvenient of Listings: the fact that, by default, it > uses bad settings (like no color, and proportional font). > > On the other hand, they don't like implying the use of an external language to > LaTeX. Impacts on shell-escape. > > The discussion is going on. I'll keep you posted. > > For sure, the objective of getting better out-of-the-box is a goal we can > reach. Excellent, I think that will be a good addition to org-mode. Dan > > Best regards, > Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
