Re: [O] Sending BibTeX entries from Zotero to Org-mode via Fireforg
Hi Bastien, Bastien writes: >> >> I'm not sure if simply changing the "max version" parameter in >> install.rdf in fireforg.xpi is the best idea. > > Maybe -- can you try and tell? I can change it to 18.0.1, and even though it installs, it reads "Error" in the add-on/status bar. I just guess it's due to the Org-mode version (7.6) and hopefully it works in newer versions. > org-protocol.el is part of Org's core. Do you maybe know since what version? Cheers, Marko signature.asc Description: PGP signature
[O] tangle multiple code blocks belonging to the same file
Hi, I know C-u C-c C-v t tangles current code block only, even if there are other code blocks that have the same tangle file name. Isn't it counterintuitive? It makes more sense that this command tangles all the code blocks that belongs to the same file, in my opinion. Any other ideas? Thanks, Zech
[O] FIXME lines in ox-html.el
Hello list, There are about 25 lines of what looks like function or filter names under the heading of FIXME in ox-html.el. Does anyone know if these are features handled by the old exporter but not yet by the new one, goals for new functionality, or something else? Do these need to be resolved before the new exporter can reliably replace the old one? Best regards, Terry -- T.F. Torrey
Re: [O] [New exporter] htmlize included file ?
> #+include: "foo.java" java > > Any obvious reason for this ? > > The reason is really obvious... and to my great shame, I already asked for something similar a couple of months ago. #+include: "foo.java" SRC java I keep finding old blocks without this "src" keyword. Sorry for the noise, Fabrice Popineau
Re: [O] [texinfo] Bug(?) in detailed node listing
Hi Jon, Jonathan Leech-Pepin writes: > Hello Tom, > > On 20 February 2013 19:45, Thomas S. Dye wrote: > >> Aloha all, >> >> I can't figure out how to get the detailed node listing formatted >> correctly, so I want to call this a bug. An example shows the problem: >> >> * Hacking::How to hack your way around >> * MobileOrg:: Viewing and capture on a mobile device >> * History and Acknowledgments::How Org came into being >> >> --- The Detailed Node Listing --- >> >> Introduction >> >> * Summary:: Brief summary of >> what \ >> Org-mode does >> * Installation:: How to install a >> downl\ >> oaded version of Org-mode >> >> > I'm guessing you mean the extra distance between the title and the > description of the listing? Yes. > > This is not exactly a bug... In an attempt to get all the descriptions > to line up correctly I aligned them all based on the longest > subheading. I'm guessing in this case there is an extremely long one > somewhere farther down. > Yes, that explains it. > I couldn't find any specification as to how far they should be aligned, > otherwise I would have set them to a specific column instead of > basing them on the longest headline. > > I should be able to fix this to be more reasonable, however I would > need an opinion as to what distance would be appropriate/desireable. * MobileOrg:: Viewing and capture on a mobile device * History and Acknowledgments:: How Org came into being * GNU Free Documentation License:: The license for this documentation. * Main Index:: An index of Org's concepts and features Based on this example from the Org manual, it looks as if the descriptions should start on column 32 or the third column after the end of the title, whichever is greater. Thanks for your help on this. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [texinfo] Info links
Hi Jon,
Jonathan Leech-Pepin writes:
> Hello Tom,
>
> On 21 February 2013 15:09, Thomas S. Dye wrote:
>
>> Aloha all,
>>
>> This link (which works correctly in the Org mode buffer):
>>
>> [[info:emacs#Indirect Buffers][GNU Emacs Manual]]
>>
>> exports to texinfo like this:
>>
>> @ref{top,GNU Emacs Manual,,emacs#Indirect Buffers,}
>>
>> when I was hoping to approximate this:
>>
>> @ref{Indirect Buffers,,,emacs,GNU Emacs Manual}
>>
>> Is this a bug, or should I be doing something differently?
>>
>> This was an oversight by me. I only set ':' as the splitter in the path.
> I'm not at the machine that has the right SSH key to be able to push
> the fix, however if you change the # to : it should export properly (I'll
> add # as a marker to split on as well once I'm at the right machine).
>
> This will also work properly in Org to access the correct node.
Yes, the : works fine everywhere. Thanks!
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] Need some clever macro help
Nicolas Goaziou writes:
> I don't understand what you mean with "can't get it to work". What
> doesn't work?
>
> When I expand this macro, I obtain the following:
>
> @@info:@kbd{@@/@@info:}@@
>
> What would be expected instead?
This works now. It must have been fixed in one of the recent changes.
Sorry for the noise.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [texinfo] Bug(?) in detailed node listing
Hello Tom, On 20 February 2013 19:45, Thomas S. Dye wrote: > Aloha all, > > I can't figure out how to get the detailed node listing formatted > correctly, so I want to call this a bug. An example shows the problem: > > * Hacking::How to hack your way around > * MobileOrg:: Viewing and capture on a mobile device > * History and Acknowledgments::How Org came into being > > --- The Detailed Node Listing --- > > Introduction > > * Summary:: Brief summary of > what \ > Org-mode does > * Installation:: How to install a > downl\ > oaded version of Org-mode > > I'm guessing you mean the extra distance between the title and the description of the listing? This is not exactly a bug... In an attempt to get all the descriptions to line up correctly I aligned them all based on the longest subheading. I'm guessing in this case there is an extremely long one somewhere farther down. I couldn't find any specification as to how far they should be aligned, otherwise I would have set them to a specific column instead of basing them on the longest headline. I should be able to fix this to be more reasonable, however I would need an opinion as to what distance would be appropriate/desireable. Regards, Jon > Help? > > All the best, > Tom > > -- > T.S. Dye & Colleagues, Archaeologists > 735 Bishop St, Suite 315, Honolulu, HI 96813 > Tel: 808-529-0866, Fax: 808-529-0884 > http://www.tsdye.com > >
Re: [O] [texinfo] Info links
Hello Tom,
On 21 February 2013 15:09, Thomas S. Dye wrote:
> Aloha all,
>
> This link (which works correctly in the Org mode buffer):
>
> [[info:emacs#Indirect Buffers][GNU Emacs Manual]]
>
> exports to texinfo like this:
>
> @ref{top,GNU Emacs Manual,,emacs#Indirect Buffers,}
>
> when I was hoping to approximate this:
>
> @ref{Indirect Buffers,,,emacs,GNU Emacs Manual}
>
> Is this a bug, or should I be doing something differently?
>
> This was an oversight by me. I only set ':' as the splitter in the path.
I'm not at the machine that has the right SSH key to be able to push
the fix, however if you change the # to : it should export properly (I'll
add # as a marker to split on as well once I'm at the right machine).
This will also work properly in Org to access the correct node.
Regards,
Jon
> All the best,
> Tom
>
> --
> T.S. Dye & Colleagues, Archaeologists
> 735 Bishop St, Suite 315, Honolulu, HI 96813
> Tel: 808-529-0866, Fax: 808-529-0884
> http://www.tsdye.com
>
>
[O] [New exporter] htmlize included file ?
Hi, I have a problem with htmlize. I'm running the very latest trunk version of org-mode. If I write an src block code with : #+begin_src java ... #+end_src I get htmlized output. But it does not work with : #+include: "foo.java" java Any obvious reason for this ? Thanks for any help, -- Fabrice
Re: [O] org-meta-return
[continues off-topic] > Have you tried a Dvorak keyboard? A friend of mine ridicules me for being a QWERTY typist, but I have found no empirical evidence that it is actually superior. At best, it has been proven, in /some/ studies, to be /slightly/ superior; and from a cost-benefit standpoint, /slight/ superiority according to /some/ studies (and I should add, only at extreme speeds), is not worth relearning how to type. I should add, he, too, changed the default Emacs keybindings to be positional. But he ended up changing /different/ defaults. 2013/2/20 Nick Dokos > [Warning: off-topic] > > 42 147 wrote: > > > My hands might be smaller than average, or, at least, smaller than yours. > > To reach I must shift my entire arm to the right and > > downward. To reach no such movement is necessary. Maybe a slight > > turn of the wrist to the right. > > > > I doubt my hands are bigger than yours: I have to do exactly what you > describe (at least on the bigger keyboards). It's just not as big a deal > for me as it is for you. > > > > Of course, these things are *highly* personal preferences, and you > might > > > have a lower tolerance for pain than I have, but I have to ask: where > > > exactly is your key relative to ? > > > > Warning, digression: > > > > I'm ultra cautious about finger / wrist strain. Even if I feel slight > > discomfort from a keybinding, I will change it to be more ergonomic and > > strain-free. Practically every basic Emacs movement command has been > > rebound for optimum comfort as a QWERTY typist. > > > > Many of the default Emacs keybindings are notational, not positional. For > > example, C-p and C-n. I've made them all positional. C-p / C-] are now > > paired together for previous-line / next-line. C-q / C-e for > > beginning-of-line / end-of-line. From a positional standpoint, C-p / C-n > > makes absolutely no sense. > > > > Agreed - they are only mnemonically significant. And I think you are > right in taking precautions. As I said, I'm a sufficiently bad typist > so that all these sins have not bitten me (at least not yet - and they > are rapidly running out of time). > > Have you tried a Dvorak keyboard? My son uses a QWERTY keyboard, mapped > in software to Dvorak - he learnt to touch type on one by switching > all the keycaps, although he didn't need the crutch > after a while, so his second keyboard has all the keycaps in the > standard places - they just produce different characters than what the > keycaps say. This had two advantages for him: the Dvorak placement > which reduces strain (supposedly at least), and the fact that I > couldn't say to him "Move over and let me drive for a while". I tried > a couple of times and I can still hear his laughter... I suspect > that unless one is an experienced Dvorak typist, it is a better security > device than many passwords :-) > > I'm not sure a Dvorak keyboard would help with emacs chords though. > Another possibility is one of the funky Kinesis keyboards: a colleague > would wax ecstatic about his, but he was not an emacs user. And they > are too expensive to buy one just to try it out. > > I'd be interested if somebody has tried either a Dvorak keyboard or > a Kinesis one with emacs - but this is way off-topic by now, so maybe > not. > > Nick > > >
Re: [O] Warning with latest git pull
Hi Thomas, t...@tsdye.com (Thomas S. Dye) writes: > Here is a warning I don't remember seeing before, posted here in case it > is useful information: > > Compiling /Users/dk/.emacs.d/src/org-mode/lisp/org.el... > > In org-current-time: > org.el:5341:16:Warning: `time-to-seconds' is an obsolete function (as of > 21.1); use `float-time' instead. > org.el:5342:12:Warning: `time-to-seconds' is an obsolete function (as of > 21.1); use `float-time' instead. Fixed, thanks! -- Bastien
Re: [O] Need some clever macro help
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
> t...@tsdye.com (Thomas S. Dye) writes:
>
>> I can't get the following macro to work:
>>
>> - {{{kbd(/)}}} ~org-agenda-filter-by-tag~ ::
>>
>> Here is its definition:
>>
>> #+MACRO: markup @@info:@$1{@@$2@@info:}@@
>> #+MACRO: kbd {{{markup(kbd,$1)}}}
>>
>
> Sorry, I mean to say I can't get it to work when the argument is '/'.
> The macro works otherwise.
I don't understand what you mean with "can't get it to work". What
doesn't work?
When I expand this macro, I obtain the following:
@@info:@kbd{@@/@@info:}@@
What would be expected instead?
Regards,
--
Nicolas Goaziou
[O] [texinfo] Info links
Aloha all,
This link (which works correctly in the Org mode buffer):
[[info:emacs#Indirect Buffers][GNU Emacs Manual]]
exports to texinfo like this:
@ref{top,GNU Emacs Manual,,emacs#Indirect Buffers,}
when I was hoping to approximate this:
@ref{Indirect Buffers,,,emacs,GNU Emacs Manual}
Is this a bug, or should I be doing something differently?
All the best,
Tom
--
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
Re: [O] [PATCH] session with python-mode.el complains of void py-toggle-shells
Am 24.01.2013 15:10, schrieb Bastien: Hi Andreas, Andreas Röhler writes: Okay, I'll dig into. For the moment: assume this code should not be needed, python-mode.el should act that all. But let me have a closer look, Great, thanks a lot! So let's start with this... BTW, being deeply impressed by org-mode and babel in special. commit e7a5839b5a10d0a27e26b8f1d16296f4c20a1350 Author: Andreas Roehler Date: Thu Feb 21 20:46:49 2013 +0100 Depend default python-mode from existing feature The former (if (featurep 'xemacs) 'python-mode 'python) makes a wrong assumption, as python-mode.el provides 'python-mode which does not depend from use of XEmacs A next step should enable users to choose environment via defcustom diff --git a/lisp/ob-python.el b/lisp/ob-python.el index 02d762c..1b3b892 100644 --- a/lisp/ob-python.el +++ b/lisp/ob-python.el @@ -43,7 +43,7 @@ (defvar org-babel-python-command "python" "Name of the command for executing Python code.") -(defvar org-babel-python-mode (if (featurep 'xemacs) 'python-mode 'python) +(defvar org-babel-python-mode (if (featurep 'python-mode) 'python-mode 'python) "Preferred python mode for use in running python interactively. This will typically be either 'python or 'python-mode.")
Re: [O] [RFC] Small syntax change for footnote definitions
Thank you for asking the list. Does this allow blank lines to separate paragraphs in inline footnote definitions? If so, it sounds very good. I presume we can still do === 1) a b. 1) c === On 2/21/13, Nicolas Goaziou wrote: > I suggest to end a footnote definition at a headline, another footnote > definition or *two* blank lines. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
Re: [O] [RFC] Small syntax change for footnote definitions
Samuel Wales writes: > Does this allow blank lines to separate paragraphs in inline footnote > definitions? No. Inline definitions stay inlined and as such, cannot contain blank lines. My proposal is only about full footnote definitions. > If so, it sounds very good. > > I presume we can still do > > === > 1) a > > b. > > 1) c > === Yes, the limitation is only about two consecutive lists. In this case, they are not consecutive. Regards, -- Nicolas Goaziou
Re: [O] [RFC] [PATCH] conditional use of latex packages
Aaron Ecay writes: > 2013ko otsailak 21an, Nicolas Goaziou-ek idatzi zuen: >> If you need occasional packages, they should go into >> `org-latex-classes'. Adding a new class is cheap. For example you can >> create a class "article-with-tikz". It also allows to include >> arbitrary code within the header. > > But not with this. It leads to combinatorial explosion: you need > article-with-tikz, article-with-biblatex, > article-with-tikz-and-biblatex, article-with-tikz-and-booktabs, I think you're nitpicking here. Tikz may be heavy to load (I don't know, I use asymptote) but not booktabs. There's no serious reason to have both "article-with-tikz" and "article-with-tikz-and-booktabs". Anyway, the point of classes is not to focus on packages only, but on whole headers. Thus, I suggest to define classes per type of document you create. I'm quite sure you don't need 2^n templates, n being the number of packages you use, for that. And if you need a specific package for a specific document, there is LATEX HEADER keyword. > Apart from that, I think that the latex exporter should “know” that you > need the booktabs package to export a table with the booktabs option. > So, if I send someone an org document with a booktabs table, it will > export correctly without the recipient needing to fiddle with > ‘org-latex-classes’ or ‘-packages-alist’. And the same reasoning > applies to longtables, tikz graphics, etc. Obviously this is not true > of arbitrarily complex LaTeX constructs, but longtables, booktabs and > tikz are all supported natively by org’s syntax. Again, this goes against the rule "do not load a package automatically". You're talking about optimizing LaTeX header (load a package only when you need it). I think it's way out of Org's purpose. Is it really important if one package is required even if it won't be used? Is it worth adding another set of variables for that? I don't think so. Don't get me wrong. There's nothing inherently wrong with your approach, and it may even sound handy, but the truth is there's little benefit. >> I don't mind that change. Would you mind providing it as a separate >> set of patches? > > If the consensus is that the optional package functionality is not > wanted, I can do so. My point was that they provide distinct features, so they should be included in different sets. But that's your call, really. >> I don't mind removing "longtable" from >> `org-latex-default-packages-alist'. I think there's no reason for it >> to be there. > > Except that the latex exporter supports it, Technically, latex exporter supports every package. That doesn't mean all of them should by included in `org-latex-default-packages-alist'. > which is also why wrapfig is in there, and several packages providing > symbols for org-entities. wrapfig and entities are a different matter. You may need them without even realizing it. So, if they were removed from the default list, that would cripple user's experience. On the other hand, you need longtable package only when you explicitly write "longtable" somewhere (e.g. in an :environment property or in `org-latex-default-table-environment'). The user knows what he's doing in this case. > I think that a logical goal is for ‘org-latex-default-packages-alist’ > to disappear (or be shrunk to only a couple of entries), and all > packages not explicitly requested by the user (in > ‘org-latex-packages-alist’ or in an ‘org-latex-classes’ entry) to be > loaded only if actually needed by the exporter. (Whether or not this > endpoint is reached depends, as you point out, on whether the problem > of package load order can be solved in a satisfactory way.) I assume this would not be made to get a header of 30 lines instead of 40, but to allow an user to use features without even thinking about the packages they require. FWIW, I think that: 1. it's impossible to guess every package required by an user, so he would ultimately have to mess with even more variables to get what he wants (I only suggest to tweak `org-latex-class' and, optionally to stuff package GCD in `org-latex-packages-alist'). 2. In general, it's a bad idea to hide LaTeX internals too much as it can become very hard to fix a problem when things happen in your back. Your work on this is interesting, but it's a can of worms, really. Regards, -- Nicolas Goaziou
Re: [O] Bug in new exporter with babel blocks
Nicolas, Thank you for your explanations, which were very helpful. 2013ko urtarrilak 23an, Nicolas Goaziou-ek idatzi zuen: > You needn't. org-exp-blocks functionalities are supported by the new > exporter out of the box. Can you say more about this? I looked for but did not find a replacement to the org-export-blocks variable (an alist associating block types with functions to export them). I found it very easy to hook into the new exporter, but perhaps I missed something? > Special blocks are de facto, recursive, much like drawers. Their > contents have to be parsed. For parsing, yes. But for export I want a way to say “I don’t care what Org thinks the export of this block is. Give me the raw contents, and I will tell you what the export should be.” This is how the ditaa special-block code used to work; I see that it has now morphed into a babel language, which makes some kind of sense. I’m not sure it does in general. My use case is glossed examples for linguistics: my special block contains three lines, which are a sentence in a foreign language and a translation. By inserting markup in a way which is easy to automate, you can get LaTeX to align the words of one language with the words of the other. I don’t want any org processing of the text of the examples: it might contain backslashes, stars, etc., all of which should be passed verbatim to LaTeX. This does not feel like source code, it cannot be evaluated or tangled, I would not want these blocks to be included in org-babel-next-src-block, etc. >> I’d also be happy to discover another, better way of getting the raw >> text content of the special-block that doesn’t succumb to this >> problem. > > If you must, you can try: > > (org-element-interpret-data (org-element-contents special-block)) > > from `org-e-latex-special-block'. I would up patching org-elements to add a :contents property to special-block elements, which is populated when parsing the original buffer (and thus dodges the different-buffer-for-export problem). I can then retrieve this in my export backend function. It is a very simple patch: ---cut-here--- diff --git i/lisp/org-element.el w/lisp/org-element.el index 3dc1e72..b67e5e6 100644 --- i/lisp/org-element.el +++ w/lisp/org-element.el @@ -1389,6 +1389,9 @@ Assume point is at the beginning of the block." :hiddenp hidden :contents-begin contents-begin :contents-end contents-end +:contents (and contents-begin contents-end + (buffer-substring-no-properties +contents-begin contents-end)) :post-blank (count-lines pos-before-blank end) :post-affiliated post-affiliated) (cdr affiliated) ---cut-here--- Is including support for special blocks that should be exported “raw” a compelling reason to install such a patch? I think the only downside would be increased memory usage/decreased speed for parsed objects (since they are now storing an extra string), but I think that would be very small (though I haven’t benchmarked anything). Thanks, -- Aaron Ecay
Re: [O] need: custom agenda for last 7 days
Actually I think the behavior of agendas is somewhat broken in this regard - a 6 day span shows 6 days, an 8 day span shows 8 days, a 7 day span shows a weekly agenda starting on Monday. Silently redefining the meaning of a variable like this depending on it's value is pretty horrible. But thanks to everybody for the tips, I think I can work out what I want from here! Subhan On Thu, Feb 21, 2013 at 3:39 AM, Jeremy "LeJyBy" wrote: [SNIP] > I tried (and failed) to find how to define a custom command in the agenda to > this purpose, but the last function fulfilled my wish. An unexpected twist > (which you might like) is that (org-agenda-list nil (- (org-today) 7) 7) > gives a > 7 day agenda starting Monday of last week, rather than 7 days ago. > > I hope it helps! > > Many thanks to all people involved in org-mode for their good work and > patience > with the "rowdy" users! > > -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] org-bullets extension
E Sabof writes: > In any case, I've updated org-bullets to use compose-region. You can > get it from here: https://github.com/sabof/org-bullets Hi, Evgeni (and gang). I've been trying this new org-bullets today, and I did not meet yet some of the problems I observed before. So, at first glance, it looks good: I'll use it more regularly in the incoming days. Thanks for this! :-) François
Re: [O] [RFC] Small syntax change for footnote definitions
Aaron Ecay writes: > Nicolas, > > I don’t know how difficult this would be in terms of the code, but would > it be possible to introduce a new syntax for multiparagraph footnotes? > Something like: > > #+begin_footnote 12 > This is footnote number 12. > > etc. > #+end_footnote > > This has the advantage that long footnote definitions could be folded, > which (AFAIK) they currently cannot. They cannot be folded, but they can be collected in a specific headline, which can be folded. > And it would not have the problem with multiple lists. Consecutive lists limitation is anecdotal, really. Also, this syntax would break every footnote definition, unless you mean to add syntax only for multiparagraph footnotes. But I think we don't have to go that far. My proposal doesn't really introduce some new syntax. It merely normalizes a corner-case. Regards, -- Nicolas Goaziou
Re: [O] [RFC] Small syntax change for footnote definitions
Nicolas, I don’t know how difficult this would be in terms of the code, but would it be possible to introduce a new syntax for multiparagraph footnotes? Something like: #+begin_footnote 12 This is footnote number 12. etc. #+end_footnote This has the advantage that long footnote definitions could be folded, which (AFAIK) they currently cannot. And it would not have the problem with multiple lists. Just a suggestion, -- Aaron Ecay
Re: [O] [RFC] [PATCH] conditional use of latex packages
2013ko otsailak 21an, Nicolas Goaziou-ek idatzi zuen: > Obviously, if you need a package in every document you write, it > should go into `org-latex-packages-alist'. I agree with this. > > If you need occasional packages, they should go into > `org-latex-classes'. Adding a new class is cheap. For example you can > create a class "article-with-tikz". It also allows to include > arbitrary code within the header. But not with this. It leads to combinatorial explosion: you need article-with-tikz, article-with-biblatex, article-with-tikz-and-biblatex, article-with-tikz-and-booktabs, Apart from that, I think that the latex exporter should “know” that you need the booktabs package to export a table with the booktabs option. So, if I send someone an org document with a booktabs table, it will export correctly without the recipient needing to fiddle with ‘org-latex-classes’ or ‘-packages-alist’. And the same reasoning applies to longtables, tikz graphics, etc. Obviously this is not true of arbitrarily complex LaTeX constructs, but longtables, booktabs and tikz are all supported natively by org’s syntax. > I don't want to take that route. Bad things can happen if you load > packages in the wrong order, or with wrong options. This is a can of > worms. That's why no package is ever loaded automatically. That’s true. I don’t think that this will replace ‘org-latex-classes’ – for certain kinds of setup it will be necessary to explicitly spell out the latex code. But the hope is that the kind of packages that this is targeted at (which implement formatting options, but don’t generally muck with lower-level things like hyperref) ordering will not be an issue. That might be an optimistic assumption about the state of LaTeX packages, though... The patch currently does not insert the optional packages in a specific order, but it would be possible to do so (using the ‘org-latex-optional-packages-options-alist’ variable to specify the ordering). > > I don't mind that change. Would you mind providing it as a separate > set of patches? If the consensus is that the optional package functionality is not wanted, I can do so. > I don't mind removing "longtable" from > `org-latex-default-packages-alist'. I think there's no reason for it > to be there. Except that the latex exporter supports it, which is also why wrapfig is in there, and several packages providing symbols for org-entities. I think that a logical goal is for ‘org-latex-default-packages-alist’ to disappear (or be shrunk to only a couple of entries), and all packages not explicitly requested by the user (in ‘org-latex-packages-alist’ or in an ‘org-latex-classes’ entry) to be loaded only if actually needed by the exporter. (Whether or not this endpoint is reached depends, as you point out, on whether the problem of package load order can be solved in a satisfactory way.) -- Aaron Ecay
Re: [O] need: custom agenda for last 7 days
Nick Dokos writes:
> Samuel Loury wrote:
>
>> ╭
>> │ (defun my/org-last-week ()
>> │ (- (org-today) 7)
>> │ )
>> │
>> │
>> │ (add-to-list 'org-agenda-custom-commands
>> │ '("w" "Weekly Logs"
>> │ (
>> │(agenda nil
>> │(
>> │ (org-agenda-overriding-header
>> │ "Review for last week")
>> │ (org-agenda-span 8)
>> │ )
>> │)
>> │)
>> │ (
>> │(org-agenda-start-day 'my/org-last-week)
>
> I think that's wrong: there is no support afaik for this variable to have
> a function value.
Hum. You're right. I forgot I also patched the org-agenda.el code for
this to work.
> Should that be
>
> (org-agenda-start-day (my/org-last-week))
That works well indeed. And does not need any patch.
Thanks for the correction.
--
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A
pgp4HQ_kj8AOG.pgp
Description: PGP signature
[O] How to escape backslashes from TeX when exporting to pdf?
OK, I feel very silly... Blame it on switching back and forth from org-mode to textile. The \textbackslash escape works reasonably well in plain text. However, if I had used the appropriate "~" instead of "@" to highlight the paths, it would have exported correctly. So, I needed to change this: (e.g. @N:\bacon\cheeseburger\no\tomato@) or a semicolon separated to this: (e.g. ~N:\bacon\cheeseburger\no\tomato~) or a semicolon separated And everything works well. Thanks! ___ Jos'h Fuller, Production Programmer Arc Productions Ltd. p: 416.682.5237 | f: 416.682.5209 | http://www.arcproductions.com 230 Richmond Street East | Toronto, ON M5A 1P4 |
[O] How to escape backslashes from TeX when exporting to pdf?
Hi! I have a section in a document where I have to specify some DOS file paths (yes, I /know/...). Unfortunately, I have other stuff in the document that uses these options: #+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:nil -:t f:t *:t TeX:t LaTeX:nil skip:t d:nil tags:not-in-toc Is there any way I can "escape" the backslashes so they will show up correctly in the final pdf? I tried the standard trick of doubling the backslashes, and that worked about as well as you might expect... Sample text: Global Paths Paths are specified using a *Paths* object. Affected fields *shall* accept the specification of either a single path (e.g. @N:\bacon\cheeseburger\no\tomato@) or a semicolon separated search path specification (e.g. @N:\bacon\cheeseburger\no\tomato;N:\chicken\sandwich\@). ___ Jos'h Fuller, Production Programmer Arc Productions Ltd. p: 416.682.5237 | f: 416.682.5209 | http://www.arcproductions.com 230 Richmond Street East | Toronto, ON M5A 1P4 |
Re: [O] [RFC] [PATCH] conditional use of latex packages
Hello, Aaron Ecay writes: > The current way that org handles LaTeX packages for export isn’t > optimal. The org-latex-(default-)packages-alist variables define a set > of packages that are loaded always. If a user wants to use advanced > functionality (booktabs for nicer table export, listings or minted for > nicer source code), s/he has to add the packages to these variables > manually.And a package like longtables is imported into every > document, slowing down compilation even when it is not used. I think you are misusing latex back-end configuration. Obviously, if you need a package in every document you write, it should go into `org-latex-packages-alist'. If you need occasional packages, they should go into `org-latex-classes'. Adding a new class is cheap. For example you can create a class "article-with-tikz". It also allows to include arbitrary code within the header. > The attached patches (specifically 1, 2, and 5) introduce a mechanism to > load certain packages only when needed. It is possible to customize > these packages by specifying options to be passed to their \usepackage > (only inserted if needed to properly export the document), as well as > arbitrary code to place in the document’s preamble if the package is > used. I don't want to take that route. Bad things can happen if you load packages in the wrong order, or with wrong options. This is a can of worms. That's why no package is ever loaded automatically. Notwithstanding conditional package insertion, `org-latex-classes' provides the same set of features. > The other patches in the series (3, 4) fix the latex exporter’s handling > of tikz image files, as generated by R’s tikzDevice function. > Currently, a link to the file containing the graphics code is inserted. > The proper behavior is to \input the file; the source code therein is > compiled into a graph by LaTeX as it compiles the document. (Tikz is a > very expensive latex package to load; the ability to load tikz only when > necessary motivated the optional packages mechanism.) I don't mind that change. Would you mind providing it as a separate set of patches? Anyway, nothing can be applied before FSF registration is complete. > I think these patches need more testing, but I wanted to send them along > for feedback. If it is not desired to change the status quo > wrt. packages like booktabs and minted (must be manually added), and > wrapfig and longtable (will always be used even if not needed), it would > be possible to accept only patches 1, 3, and 4. (But obviously I think > the other patches are a marked improvement.) I don't mind removing "longtable" from `org-latex-default-packages-alist'. I think there's no reason for it to be there. Regards, -- Nicolas Goaziou
Re: [O] need: custom agenda for last 7 days
Samuel Loury wrote:
> ╭
> │ (defun my/org-last-week ()
> │ (- (org-today) 7)
> │ )
> │
> │
> │ (add-to-list 'org-agenda-custom-commands
> │ '("w" "Weekly Logs"
> │(
> │ (agenda nil
> │ (
> │ (org-agenda-overriding-header
> │ "Review for last week")
> │ (org-agenda-span 8)
> │ )
> │ )
> │ )
> │(
> │ (org-agenda-start-day 'my/org-last-week)
I think that's wrong: there is no support afaik for this variable to have
a function value. Should that be
(org-agenda-start-day (my/org-last-week))
perhaps?
Nick
> │ (org-agenda-start-with-clockreport-mode t)
> │ (org-agenda-start-with-log-mode t)
> │ (org-agenda-archives-mode t)
> │ (org-agenda-show-log 'clockcheck)
> │ )
> │)
> │ )
> ╰
> Hope it helps.
> --
> Konubinix
> GPG Key: 7439106A
> Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A
[O] [RFC] Small syntax change for footnote definitions
Hello,
Following a thread started by Samuel Wales (see
http://permalink.gmane.org/gmane.emacs.orgmode/66558), it appears that
the standard way to include multiple paragraphs in a footnote definition
is to rely on "\par" LaTeXism.
There are two problems here. Firstly, the parser would have to go out of
its way to support this trick. Secondly, it isn't very regular wrt Org
syntax.
I suggest to end a footnote definition at a headline, another footnote
definition or *two* blank lines.
Pros:
- Small modification to code base.
- More regular syntax (lists use the same)
Cons:
- Still impossible to have two consecutive lists (because they need
to be separated by 2 blank lines).
- Small incompatibility with previous syntax.
Is there any objection to apply this patch?
Regards,
--
Nicolas Goaziou
>From 18a95bdc2667ea01a75a7b9ddaff55cd4ea5c329 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
Date: Thu, 21 Feb 2013 15:30:16 +0100
Subject: [PATCH] Require 2 blank lines to separate footnote definition
* lisp/org-element.el (org-element-footnote-definition-parser):
Require 2 blank lines to separate footnote definition.
* lisp/org-footnote.el (org-footnote-at-definition-p): Require 2 blank
lines to separate footnote definition.
Footnote definitions can still be separated with other footnote
definitions and headlines. This change allows to have multiple
paragraphs in a footnote definition.
---
lisp/org-element.el | 2 +-
lisp/org-footnote.el | 13 +++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 3dc1e72..012aea7 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -693,7 +693,7 @@ Assume point is at the beginning of the footnote definition."
(re-search-forward
(concat org-outline-regexp-bol "\\|"
org-footnote-definition-re "\\|"
-"^[ \t]*$") limit 'move))
+"\n\\([ \t]*\n\\)\\{2,\\}") limit 'move))
(match-beginning 0)
(point
(contents-begin (progn (search-forward "]")
diff --git a/lisp/org-footnote.el b/lisp/org-footnote.el
index 9aa388b..d99bdec 100644
--- a/lisp/org-footnote.el
+++ b/lisp/org-footnote.el
@@ -251,11 +251,12 @@ otherwise."
(when (save-excursion (beginning-of-line) (org-footnote-in-valid-context-p))
(save-excursion
(end-of-line)
- ;; Footnotes definitions are separated by new headlines or blank
- ;; lines.
- (let ((lim (save-excursion (re-search-backward
- (concat org-outline-regexp-bol
- "\\|^[ \t]*$") nil t
+ ;; Footnotes definitions are separated by new headlines, another
+ ;; footnote definition or 2 blank lines.
+ (let ((lim (save-excursion
+ (re-search-backward
+ (concat org-outline-regexp-bol
+ "\\|\n\\([ \t]*\n\\)\\{2,\\}") nil t
(when (re-search-backward org-footnote-definition-re lim t)
(let ((label (org-match-string-no-properties 1))
(beg (match-beginning 0))
@@ -271,7 +272,7 @@ otherwise."
(re-search-forward
(concat org-outline-regexp-bol "\\|"
org-footnote-definition-re "\\|"
- "^[ \t]*$") bound 'move))
+ "\n\\([ \t]*\n\\)\\{2,\\}") bound 'move))
(match-beginning 0)
(point)
(list label beg end
--
1.8.1.4
Re: [O] need: custom agenda for last 7 days
Subhan: here is a fonction you can use to generate your weekly report: #+BEGIN_SRC lisp (defun my/weekly-report nil "Generate the agenda list for last 8 days with report mode on" (org-agenda-list nil (- (org-today) 8) 8) ; 8 day agenda starting 8 days ago (setq org-agenda-clockreport-mode nil) (org-agenda-clockreport-mode) ) #+END_SRC Samuel: I love your solution (much more elegant than mine!), but even with emacs -q I get the error #+BEGIN_SRC org-agenda-list: Wrong type argument: number-or-marker-p, my/org-last-week #+END_SRC I am using GNU Emacs 24.3.50.1 and Org-mode version 7.9.3d.
Re: [O] footnotes export verbatim
Samuel Wales writes: > On 2/20/13, Nicolas Goaziou wrote: >> The basic syntax is similar to the one used by `footnote.el', i.e. >> a footnote is defined in a paragraph that is started by a footnote >> marker in square brackets in column 0, no indentation allowed. If you >> need a paragraph break inside a footnote, use the LaTeX idiom `\par'. > > I am aware of that, but blank lines were allowed after a while. One > issue was filling. > > Even \par fails to work now. :( This last bit would be disturbing if true. However, on my system at least, \par in the middle of an inline footnote *does* lead to the start of a new paragraph within the footnote when exported to latex/pdf. Mind you, my org is not quite up to date (day or so old). YMMV. -- : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org 7.9.3e-1140-g272ca4
Re: [O] need: custom agenda for last 7 days
Subhan Tindall rentrakmail.com> writes: > I have a question regarding a custom agenda report. I've found the > variable org-agenda-span to set the number of days shown. But, I > can't seem to some up with a way to make it start in the past. > IE I want to see all agenda items for today and the previous 6 days. Hi Subhan. - Would the following serve you? ((org-agenda-list nil (- (org-today) 7) 6) ; 6 day agenda starting 6 days ago I tried (and failed) to find how to define a custom command in the agenda to this purpose, but the last function fulfilled my wish. An unexpected twist (which you might like) is that (org-agenda-list nil (- (org-today) 7) 7) gives a 7 day agenda starting Monday of last week, rather than 7 days ago. I hope it helps! Many thanks to all people involved in org-mode for their good work and patience with the "rowdy" users!
Re: [O] need: custom agenda for last 7 days
Subhan Tindall writes:
> I have a question regarding a custom agenda report. I've found the
> variable org-agenda-span to set the number of days shown. But, I
> can't seem to some up with a way to make it start in the past.
> IE I want to see all agenda items for today and the previous 6 days.
> Also, can someone point me at a good tutorial for customized agendas
> including all option variables & what they do? I can't seem to put my
> fingers on one.
> Thanks!
> Subhan
> '(org-agenda-custom-commands (quote (("w" "Weekly Logs" agenda ""
> ((org-agenda-span 8))
>
>
> --
> Subhan Michael Tindall | Software Developer
> | s...@rentrakmail.com
> RENTRAK | www.rentrak.com | NASDAQ: RENT
>
Hi, this is what I have
╭
│ (defun my/org-last-week ()
│ (- (org-today) 7)
│ )
│
│
│ (add-to-list 'org-agenda-custom-commands
│'("w" "Weekly Logs"
│ (
│ (agenda nil
│ (
│(org-agenda-overriding-header
│ "Review for last week")
│(org-agenda-span 8)
│)
│ )
│ )
│ (
│ (org-agenda-start-day 'my/org-last-week)
│ (org-agenda-start-with-clockreport-mode t)
│ (org-agenda-start-with-log-mode t)
│ (org-agenda-archives-mode t)
│ (org-agenda-show-log 'clockcheck)
│ )
│ )
│)
╰
Hope it helps.
--
Konubinix
GPG Key: 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE 5C36 75D2 3CED 7439 106A
pgpHsftn3PDMi.pgp
Description: PGP signature
[O] Correct / best way of loading packages in contrib when using org compiled from git?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I am using org-mode from git and compile it. I would like to use the org-notmuch module in the contrib directory, and I activate it using: (add-to-list 'load-path "~/.emacs.d/org-mode/contrib/lisp") (require 'org-notmuch) But, as Suvayo pointed out to me, in default.mk it says: # Define if you want to include some (or all) files from contrib/lisp # just the filename please (no path prefix, no .el suffix), maybe with globbing #ORG_ADD_CONTRIB = org-e-* org-md org-export # e.g. the new exporter So I would have to add ORG_ADD_CONTRIB = org-notmuch to the local.mk file Nevertheless, I would like to stick with a configutration which uses the normal compiled version and all configurations are in one file (emacs.org), so I would prefer the require... approach. But I would like to have some clarification, what the differences are between the two approaches and if (and if yes, why) it would be advisable to use the second approach. Thanks lot, Rainer PS: I update my git almost daily via the following script: #3 #!/bin/sh cd ~/.emacs.d/org-mode-git/org-mode git checkout master git fetch --tags origin git pull git gc git checkout master make clean make make autoloads make doc make info #3 - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRJgtRAAoJENvXNx4PUvmC6GgIANoMPX4TEwfjKVMstEoCHjFX FYA1y2gRKFRRx0Qe/7gRMz7eMvHKrblnzH1A67MmUpGTO2H607pInMEsHsjWIcVH EqfffwHdbSVMHaZwr6mKW+j0CXvGwVzviT2OrHl8BPMdt5DKScYuJBy7FUq2jKYg 9nZ7ATVs4ADy/Nxsqq7dcuJf2wDkw4ZWDgOnKu2guD5IFUVOgqe5H1vjEUa/veOH V1VpuTjN7R5lWhVvxjDlLPzq4O3QGzmq5zj6S07wFJlx2dstN7mo6SP2RoiKO3Zl Wc2KyK1+sMVpdZJDKtIyrJa1F4VTr40R0NtuC/ookq9j5b8H4R26LtDkxtUoncw= =vRYR -END PGP SIGNATURE-
Re: [O] org-capture, datetree, and tags
Tim Burt writes:
> Jeffrey Brent McBeth writes:
>
>> I'm trying to capture into a datetree using org-capture, but if my tree has
>> a tag on it (in particular noexport), then it creates a new datetree instead
>> of using the one I have.
>> Example .emacs:
>> (global-set-key "\C-cc" 'org-capture)
>> (setq org-capture-templates
>> '(("t" "Test" plain (file+datetree "~/Test.org")
>> "%^{Greeting} World
>> I'm going to work this time")))
>>
>> Example Test.org:
>>
>> * 2013
>> :noexport:
>> ** 2013-02 February
>> *** 2013-02-19 Tuesday
>> Hello World
>> I'm going to work this time
>>
>> So, based on the above, if I type C-cct Silly C-cc, I'll get this:
>>
>> * 2013
>> :noexport:
>> ** 2013-02 February
>> *** 2013-02-19 Tuesday
>> Hello World
>> I'm going to work this time
>> * 2013
>> ** 2013-02 February
>> *** 2013-02-19 Tuesday
>> Silly World
>> I'm going to work this time
>>
>> Thanks for your attention,
>> Jeffrey McBeth
>
> I can confirm both the behavior and a usecase for a tagged datetree.
>
> In org-datetree.el the function org-datetree-find-year-create searches for
> the year on a headline and will not match content with anything beyond the
> fourth digit.
> : (defun org-datetree-find-year-create (year)
> : (let ((re "^\\*+[ \t]+\\([12][0-9][0-9][0-9]\\)$")
> : match)
>
> In this particular case the tag in question is :noexport: with white space
> fore (and maybe aft), and the following change to the regular expression
> was tested with success.
> : (defun org-datetree-find-year-create (year)
> : (let ((re "^\\*+[ \t]+\\([12][0-9][0-9][0-9]\\)[ \t]+:noexport:[ \t]*$")
> : match)
> Of course this only matches the specific tag in this example *and* only
> matches a datetree with this tag. The regular expression needs to be
> improved to include a valid tag set as optional.
Improved the regular expression to permit multiple tags of letters,
numbers, underscores, and at signs.
: (defun org-datetree-find-year-create (year)
:(let ((re "^\\*+[ \t]+\\([12][0-9][0-9][0-9]\\)[
\t]*\\(:[[:alnum:]_@]*\\)*:*[ \t]*$")
: match)
I've tested with the following headlines:
- 2013
- both with and without trailing spaces
- 2013 :abc:
- 2013 :abc123:
- 2013 :abc123:_underscore:@attaboy::
- 2013 :noexport:
Any comments on the regular expression are welcome before I make patch.
--
Tim Burt
www.rketburt.org
"It is healthful to every sane man to utter the art within him;" -- GK
Chesterton
Re: [O] C-c ^ not fully useful
On Mon, Feb 18, 2013 at 02:36:57PM -0500, François Pinard wrote: > > - Could org-sort, by default and for most of its current option letters, > sort alphabetically (or lexicographically as they say!) over the > visual aspect of the line instead of its physical contents? It might > be difficult if Emacs has no function to reach the visual aspect of a > line. I guess that most users would expect a visual sort. I think this is a good idea. It should be possible to just test if the first entity is a "link" and extract the title part using org-elements > - Options might be added to sort over the physical contents of the line > instead. And there always is M-x sort-lines RET !). Agreed. > - Could some parameterisation be added so one could map user written > functions over (free) option letters? Again, a good idea. :) Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] [RFC] [PATCH] conditional use of latex packages
Hello Aaron, On Wed, Feb 20, 2013 at 11:02:21PM -0500, Aaron Ecay wrote: > Hello, > > The current way that org handles LaTeX packages for export isn’t > optimal. The org-latex-(default-)packages-alist variables define a set > of packages that are loaded always. If a user wants to use advanced > functionality (booktabs for nicer table export, listings or minted for > nicer source code), s/he has to add the packages to these variables > manually. And a package like longtables is imported into every > document, slowing down compilation even when it is not used. [...] I fully sympathise with your intentions and will test the patches at the earliest when I have some time (probably tomorrow). Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] bbdb or bbdb3 or org-contacts
On Mon, Jan 28, 2013 at 1:52 PM, David Rogers wrote: > > Also look at ASynK, which can synchronize between Google and bbdb3: > > https://karra-asynk.appspot.com/ > > ASynK also works with BBDB v2 with a small-ish patch that adds timestamp support. As no one is really maintaining BBDB2.x any more this is not integrated 'upstream'. See here for more info on the patch: http://karra-asynk.appspot.com/doc/asynk/asynk_2.html#SEC8
