Re: [O] footnotes export verbatim
Samuel Wales samolog...@gmail.com writes: On 2/24/13, Nicolas Goaziou n.goaz...@gmail.com wrote: Samuel Wales samolog...@gmail.com writes: On 2/20/13, Nicolas Goaziou n.goaz...@gmail.com 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. :( It should now be fixed. Just replace \par with an empty line. The fix does not work. I tried blank line and it still exported verbatim. I then tried \par, and it still filled the footnote and inserted \par into it. I think we're not talking about the same thing. The fix allows empty lines in regular footnote definitions, not inline ones. If this cannot be fixed, then I need some way of filtering to achieve it. Filtering cannot help you here, since you need to, at least, agree with the structure of the document being parsed. If you want lists, tables, paragraphs... in a footnote, regular definitions are the way to go. If, for some reason, you refuse to use regular definitions, you could write a hook which would call `org-footnote-normalize', in order to transform your inline definitions in regular definitions, and then replace \par with an empty line. That hook function can be added in `org-export-before-parsing-hook'. Regards, -- Nicolas Goaziou
Re: [O] comments after paragraph remove newline
Samuel Wales samolog...@gmail.com writes: I wonder if we should consider something more fancy for ascii backend (only). Delete blank lines between comment and headline This is not needed: see `org-ascii-headline-spacing'. and between comment and comment. Done. Regards, -- Nicolas Goaziou
Re: [O] Bug: New HTML exporter incorrect attributes
Samuel Wales samolog...@gmail.com writes: For flexibility and future proofing, it might be worth considering universal syntax (e.g. $[link ... :attr1 ... :attr2 ... ...]) for fancy links instead of changing link syntax. I've called it extensible syntax too. There are already four completely different ways to write a link. I don't think adding a fifth would do any good. I suggest to either slightly change regular link syntax (e.g. [[link][desc][options]]) or replace it completely (the one you suggest is not bad). Regards, -- Nicolas Goaziou
Re: [O] org-fill-paragraph leaves point at end of table
Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: Calling `org-fill-paragraph' inside a table leaves point at the end of the table, for reasons that are totally unclear to me. I've tested this with up-to-date org and emacs -Q, so I'm hoping it's reproducible. I edebugged org-fill-paragraph, and it appears to do the right thing, going from the save-excursion to the cond to the org-table cond statement, and there calling `org-table-align'. That works correctly, but stepping forward you come to the end of the enclosing `save-excursion', and emerging from `save-excursion' puts point at the end of the table -- precisely what it's not supposed to do! I made a minimum sexp to reproduce the relevant bits of org-fill-paragraph: #+BEGIN_SRC emacs-lisp (save-excursion (let ((element (org-element-at-point))) (case (org-element-type element) (table-row (org-table-align) t #+END_SRC Putting point in a table and eval'ing that also leaves point at the end of the table. I tried using (call-interactively 'org-table-align) and it did the same thing. I'm baffled, particularly as it doesn't do this for any other element type. Any clever ideas? M-q after a bit of typing is already stuck in my fingers, and this bit of strangeness doesn't set the mark, so editing long tables is a pain... `org-table-align' inserts a whole new table and removes completely the previous one. This confuses `save-excursion' which doesn't recognize any familiar location anymore. I've pushed a fix for it. All filling tests pass, but if you notice anything suspicious, please signal it. Thank you for the report. Regards, -- Nicolas Goaziou
Re: [O] org-fill-paragraph leaves point at end of table
On 25 feb. 2013, at 10:10, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: Calling `org-fill-paragraph' inside a table leaves point at the end of the table, for reasons that are totally unclear to me. I've tested this with up-to-date org and emacs -Q, so I'm hoping it's reproducible. I edebugged org-fill-paragraph, and it appears to do the right thing, going from the save-excursion to the cond to the org-table cond statement, and there calling `org-table-align'. That works correctly, but stepping forward you come to the end of the enclosing `save-excursion', and emerging from `save-excursion' puts point at the end of the table -- precisely what it's not supposed to do! I made a minimum sexp to reproduce the relevant bits of org-fill-paragraph: #+BEGIN_SRC emacs-lisp (save-excursion (let ((element (org-element-at-point))) (case (org-element-type element) (table-row (org-table-align) t #+END_SRC Putting point in a table and eval'ing that also leaves point at the end of the table. I tried using (call-interactively 'org-table-align) and it did the same thing. I'm baffled, particularly as it doesn't do this for any other element type. Any clever ideas? M-q after a bit of typing is already stuck in my fingers, and this bit of strangeness doesn't set the mark, so editing long tables is a pain... `org-table-align' inserts a whole new table and removes completely the previous one. This confuses `save-excursion' which doesn't recognize any familiar location anymore. I've pushed a fix for it. All filling tests pass, but if you notice anything suspicious, please signal it. I do not expect problems, because you now fall back onto org-table-align without any save-excursion around it, AFAICS. org-table-align remembers line number and table row number and restores them, so this should work. - Carsten
Re: [O] [PATCH] Synchronize slideshow exporters to ox-html changes.
Hello, Rick Frankel r...@rickster.com writes: This patch fixes a couple of bugs in the s5 exporter and brings both exporters in-sync w/ the updates to ox-html (uppercase properties, and HTML_CONTAINER_CLASS fix). Note that ox-deck has so many lines of change due to whitespace cleanup (won't happen again :). I have trouble applying this patch. Could you rebase it against current master and resend it? Also, would you mind replacing in both files (+ (org-element-property :level headline) (plist-get info :headline-offset)) occurrences with: (org-export-get-relative-level headline info) Thank you. Regards, -- Nicolas Goaziou
Re: [O] [BUG, LaTeX] LATEX_CLASS_OPTIONS don't always work
Hi Nicolas, On Wed, Feb 20, 2013 at 08:27:31PM +0100, Nicolas Goaziou wrote: [...] Thank you for the detailed report. It should be fixed. I confirm, it works. Thank you! And thanks as well for the lesson in regular expressions. After one hour I finally understand your expression :-) . Regards -- Michael Strey www.strey.biz
Re: [O] C-c ^ not fully useful
Hi François, sorting list items and headlines is now done against the visible part of the item and headlines, i.e., it ignores hidden links and emphasis markers. I am not sure it is useful to add a parameter to `org-sort-list' and `org-sort-entries' to let the user change this default behavior: do you have a significant use-case for this? François Pinard pin...@iro.umontreal.ca writes: - Could some parameterisation be added so one could map user written functions over (free) option letters? Here again, my feeling is that it would be over-engineered -- would you use it yourself? How? Thanks for suggesting this improvements! -- Bastien
Re: [O] [PATCH] Synchronize slideshow exporters to ox-html changes.
Nicolas Goaziou n.goaz...@gmail.com writes: I have trouble applying this patch. Could you rebase it against current master and resend it? If I may nitpick, Rick, please take care of using proper sentences in the change log: start with an uppercase letter, end with a full stop. Your patch will go into Emacs, and this is the Emacs policy. Otherwise Nicolas will have to fix typos in the change log... Thanks in advance for this! -- Bastien
Re: [O] [PATCH] Synchronize slideshow exporters to ox-html changes.
Hi Rick, Rick Frankel r...@rickster.com writes: Note that ox-deck has so many lines of change due to whitespace cleanup (won't happen again :). It's better to make those whitespace changes into separate commits. Thanks! -- Bastien
Re: [O] [PATCH] bug in expansion of variables in babel Perl
Achim Gratz twisted the bytes to say: Hi Achim, thanks for taking the time to do this. I applied the patch, one of the hunks didn't apply due to Eric's changes, but that is not an issue, since they do the same: -- diff a/lisp/ob-perl.el b/lisp/ob-perl.el(rejected hunks) @@ -75,7 +75,7 @@ (defun org-babel-perl-var-to-perl (var) specifying a var of the same value. (if (listp var) (concat [ (mapconcat #'org-babel-perl-var-to-perl var , ) ]) -(format %S var))) +(format q(%s) var))) (defvar org-babel-perl-buffers '(:default . nil)) -- Everything works as intended, except for the return value of the perl code. Values in the list are concatenated, as one: #+begin_src perl :results table (1, 2, 3) #+end_src #+RESULTS: | 123 | #+begin_src perl :results table (1, 2, 3) #+end_src #+RESULTS: | 123 | I think the issue is that, at least in my computer the variable $\ returns empty (the record separator). #+begin_src perl :results output print value of \$\\ [$\]\n; #+end_src #+RESULTS: #+begin_example value of $\ [] #+end_example --daniel -- Daniel M. German Work. Finish. Publish. Michael Faraday http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with .
Re: [O] bug in expansion of variables in babel Perl
Achim Eric Schulte writes: Are you familiar with `org-babel-expand-src-block' bound to C-c C-v v? Achim I wasn't, obviously, and neither was the OP. If I understand the desire correctly, it should be what you're after. Perhaps an option to raise the expanded source code buffer along with the error buffer when an error is raised would be a useful addition. Achim Yes, so there's no three ways for Perl to get the same result for Achim comparison. :-P Just keep in mind, org-babel-expand-src-block is not exactly what emacs passes to perl. It does not contain the wrapping code. --dmg -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with .
Re: [O] [PATCH] datetree: Recognize year headline with tags as a match
Hi Tim, Tim Burt tcb...@rochester.rr.com writes: * lisp/org-datetree.el (org-datetree-find-year-create): Include regexp for tags. Syntax was taken directly from org-todo-line-tags-regexp in org.el. Applied, thanks a lot for the patch and the detailed change log! Best, -- Bastien
Re: [O] Feature: Group and limit items in agenda
Hi Samuel, Samuel Wales samolog...@gmail.com writes: One other use here is to show a small random sample of your tasks without affecting speed. In before sorting filter function, set a pseudorandom number (biased according to a distribution of your choice) on a text property. You can set some to appear always. In the mapcar function, use user-defined sorting to sort according to the numbers and limit to just the first 5. Yes, this is a nice use of `org-agenda-before-sorting-filter-function'. Can defadvice be relied on to keep working in future versions of Org? As much as possible, yes. -- Bastien
Re: [O] Publishing http links inside a begin_src
Emilio Torres Manzanera tor...@uniovi.es writes: I have downloaded a new version form an ELPA repository: Org-mode version 7.9.3e (7.9.3e-16-gf8b15d-elpa @ /home/emilio/.emacs.d/elpa/org-20130218/). It runs fine! Great, thanks for confirming, -- Bastien
Re: [O] evaluation of perl in babel
Achim Gratz twisted the bytes to say: Achim D M German writes: There are some bugs. For example, the interpretation of :results table, vector and list. Achim You may misunderstand some things, or I don't understand what you are Achim asking. It is (at least currently) the responsibility of the Perl Achim program (or any other Babel language) to deliver the result in such a Achim way that it can be interpreted correctly by the result type chosen (in Achim other word, the program output must be valid Org syntax in the given Achim context). You can't have the same program produce tables, vectors and Achim LaTeX output just by switching the results type. I understand. But what I want is the output to be wrapped accordingly, and my script to deliver exactly the output as expected. So say I want to generate HTML in my script, I can use :results output, but then I have to change to replace the #+being_example with #+begin_HTML. I guess that I can generate a two dimensional table with perl too using output (printing the necessary | and \n), but then it will be wrapped with #+begin_example. But I think the main problem comes from the way that Babel expects the result. In Babel, and except for :results output, the last expression in perl is considered the input to the results. Achim That is with the default wrapper function, which expects the program to Achim return something that either is a string or interpolates to a string Achim that Babel can interpret. You can easily define one yourself that does Achim different things, like simply open the output file then select the Achim filehandle for output. That's what I'd do in any case and I think it Achim would work just as you want. Perhaps a string can be the solution. Ok, I am testing: #+begin_src perl :results table (a|b|c|\n|c|d|e) #+end_src #+RESULTS: | a | b | c | \n | c | d | e | Ok, this seems to be more useful that returning a list of values. Is there a way to separate two rows in the result? Thanks again Achim, --daniel -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with .
Re: [O] Warning with latest git pull
Hi Achim, Achim Gratz strom...@nexgo.de writes: I hereby declare that XEmacs compatibility is broken already and he who wants to have this corrected should bring a working version of ert for XEmacs. Let's encourage XEmacs users to report bugs and incompatibility. Asking them to write an XEmacs ERT sounds a bit too much :) -- Bastien
[O] [new exporter] headline export to LaTeX
Since the last pull (release_7.9.3f-1205-g0030e1) headlines are exported
to LaTeX like this:
\subsection*[Headline]{Headline}
which does not produce proper headlines in the resulting pdf.
Regards,
--
henry, web: http://literaturlatenight.de
Re: [O] evaluation of perl in babel
On Mon, Feb 25, 2013 at 1:54 AM, D M German d...@uvic.ca wrote: Achim You may misunderstand some things, or I don't understand what you are Achim asking. It is (at least currently) the responsibility of the Perl Achim program (or any other Babel language) to deliver the result in such a Achim way that it can be interpreted correctly by the result type chosen (in Achim other word, the program output must be valid Org syntax in the given Achim context). You can't have the same program produce tables, vectors and Achim LaTeX output just by switching the results type. I understand. But what I want is the output to be wrapped accordingly, and my script to deliver exactly the output as expected. So say I want to generate HTML in my script, I can use :results output, but then I have to change to replace the #+being_example with #+begin_HTML. I guess that I can generate a two dimensional table with perl too using output (printing the necessary | and \n), but then it will be wrapped with #+begin_example. Ok, I got it. What I need is to return a string with whatever I need. A bit cumbersome, but I can live with it #+begin_src perl :results html table ba /b /table #+end_src #+RESULTS: #+BEGIN_HTML table ba /b /table #+END_HTML thanks again for the explanation, -- --dmg --- Daniel M. German http://turingmachine.org
Re: [O] Correct / best way of loading packages in contrib when using org compiled from git?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/02/13 16:42, Achim Gratz wrote: Bastien bzg at altern.org writes: Just for clarifications: is there any problem with adding ORG_ADD_CONTRIB = * to the local.mk file, apart from slightly longer compilation times? This should be okay, but it's not safe. If any non-emacs-lisp file gets added to contrib/lisp/ (e.g. a README file) then you will try to compile non-elisp files. *\.el is safer. This is a globbing pattern, not a regular expression, hence: *.el, but that would also pull in htmlize which you most likely don't want, so you might follow the lead in server.mk and make that org-* or org-*.el if you are worried that the Org maintainer forgets that only lisp files should go into the lisp directory. :-) Thanks Bastien and Achim - I will then use org-*.el Quick follow up question - what is the value for the Ubuntu package? Rainer Regards, Achim. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRKzZNAAoJENvXNx4PUvmC1EcH/AojCzTMu46oEjEClVLLfG0S dju5QTA+1hfl8UfbTcY34aOwXP0CiGSxQtGF53M0CYxjFMI44o5yXVfHoKtKLwHQ oII+6f6KT3kl2uhxJ6KUxZuvVZ5TRbse6Wse2NeacZRyHlioYYlf+nBVPBarZH+M hPJIOYYPQUN4tEOdVRpjaWGGMzrXHxUqbY3KEWlVR6tYgPhsg4Pv7dzTr6ObW9qV zrcBzHMoVTlgZXkNIcJu6wghwS2j/vLeFL3AHpxJyuM01nehY13KYsXxxl8ztDt3 YgGPsW3vbD0YdfEmhJLTPYxdskb13L5bFPMaFFObuoLdhI69PlmY3EEIXqUF0ZE= =teLG -END PGP SIGNATURE-
Re: [O] [new exporter] headline export to LaTeX
Hello,
henry atting s...@online.de writes:
Since the last pull (release_7.9.3f-1205-g0030e1) headlines are exported
to LaTeX like this:
\subsection*[Headline]{Headline}
which does not produce proper headlines in the resulting pdf.
It should be fixed now. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] Correct / best way of loading packages in contrib when using org compiled from git?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/02/13 22:17, Achim Gratz wrote: Rainer M Krug writes: Ok - that makes sense. I just checked in my contrib/lisp and I only have .el there, so none are compiled. Look in lisp, not contrib/lisp. True - because it compiles it there. If you set the load-path to include the contrib/lisp/ directory, then you don't need to install org-notmuch, and (require 'org-notmuch) will find it. Well - I don't install org, but just specify the load-path, so I have to specify that one as well. No problem. No, you don't want that if you use ORG_ADD_CONTRIB. Absolutely - if I use ORG_ADD_CONTRIB I don't want / need it, but If I don't, I do. Yes - that is what I am doing as well. Just curious, what would change for you if you installed Org into a user directory (besides using make up2 instead of make update)? Well - I could and I guess nothing would change. Why I like my setup at the moment is, that I have all emacs config, installation and elpa in my .emacs.d directory. Would this be the same after using make up2? Would I have to change paths somewhere? Just for clarifications: is there any problem with adding ORG_ADD_CONTRIB = * to the local.mk file, apart from slightly longer compilation times? Yes, you don't want all of contrib (htmlize.el in particular). Makes sense - changed it as described in the other email. PS: I update my git almost daily via the following script: This should be enough Actually, the git checkout master at the beginning should probably stay there as a defensive measure. Ok - I just re-activate this command - shouldn't hurt. Thanks a lot, Rainer Regards, Achim. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRKzddAAoJENvXNx4PUvmCl+QIAK7kGmIbrO1j/cgOjEJXd/Xr 6snTTUf4epB0ZAuOVEXoC38GA7bdVcxJa8kJlE/LC6SCgTncljS57T8PXXmlF29F 66QY5GMsMhS0ySR4NERrloo3TWlomcfD6jSc/EzBJHP4ErDQ4J52EL0RwcO71/F6 sTK96TM06UlSta389/cKn/PMtIwVqi/oav2z1zFINVNFjYCxEOVkj0+ei03k/bmO 8aywm19q0UOPPL2mjnCI8cxEzfpzX2/WZllplXvSYYUIf5bz+JmMMZfQsawmmzWA 9YX31Usb7i3TM/7OhlOX/sahjdlJ2JvV7uqxg2Dj2KnzrlXCXq1+jyNKU0GlFbQ= =4J3Q -END PGP SIGNATURE-
Re: [O] org-fill-paragraph leaves point at end of table
Carsten Dominik carsten.domi...@gmail.com writes: On 25 feb. 2013, at 10:10, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Eric Abrahamsen e...@ericabrahamsen.net writes: Calling `org-fill-paragraph' inside a table leaves point at the end of the table, for reasons that are totally unclear to me. I've tested this with up-to-date org and emacs -Q, so I'm hoping it's reproducible. I edebugged org-fill-paragraph, and it appears to do the right thing, going from the save-excursion to the cond to the org-table cond statement, and there calling `org-table-align'. That works correctly, but stepping forward you come to the end of the enclosing `save-excursion', and emerging from `save-excursion' puts point at the end of the table -- precisely what it's not supposed to do! I made a minimum sexp to reproduce the relevant bits of org-fill-paragraph: #+BEGIN_SRC emacs-lisp (save-excursion (let ((element (org-element-at-point))) (case (org-element-type element) (table-row (org-table-align) t #+END_SRC Putting point in a table and eval'ing that also leaves point at the end of the table. I tried using (call-interactively 'org-table-align) and it did the same thing. I'm baffled, particularly as it doesn't do this for any other element type. Any clever ideas? M-q after a bit of typing is already stuck in my fingers, and this bit of strangeness doesn't set the mark, so editing long tables is a pain... `org-table-align' inserts a whole new table and removes completely the previous one. This confuses `save-excursion' which doesn't recognize any familiar location anymore. I've pushed a fix for it. All filling tests pass, but if you notice anything suspicious, please signal it. I do not expect problems, because you now fall back onto org-table-align without any save-excursion around it, AFAICS. org-table-align remembers line number and table row number and restores them, so this should work. And sure enough, it does! Sorry for all the table-related stuff. I'm in one of those moments where you throw caution to the wind and entrust a time-sensitive company project to areas of git-master Orgmode you've never used before. Likely very stupid, but it's too late to turn back now. Thanks! E
Re: [O] [new exporter] headline export to LaTeX
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
henry atting s...@online.de writes:
Since the last pull (release_7.9.3f-1205-g0030e1) headlines are exported
to LaTeX like this:
\subsection*[Headline]{Headline}
which does not produce proper headlines in the resulting pdf.
It should be fixed now. Thank you.
Yes, thank you.
Regards,
--
henry atts, web: http://literaturlatenight.de
Re: [O] Correct / best way of loading packages in contrib when using org compiled from git?
Rainer M Krug r.m.k...@gmail.com writes: Quick follow up question - what is the value for the Ubuntu package? I'm not using Ubuntu so I don't know, sorry! -- Bastien
Re: [O] C-c ^ not fully useful
Hi Carsten, Carsten Dominik carsten.domi...@gmail.com writes: are you sure it removes emphasis markers as well? Looks to me that org-sort-remove-invisible only removes links. I guess it could be rewritten looking at invisibility properties, but that might be problematic when sorting includes a part of the buffer that has not yet been visible in a window and therefore might not be propertized properly. You are right, the version that removes emphasis markers based on the visibility[1] specs is buggy. I tweaked `org-sort-remove-invisible' so that it removes emphasis markers for good[2]. I did some testing and it works okay, let me know if you anticipate any other problem. Thanks, [1] http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=30d6dc [2] http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=662cb9 -- Bastien
Re: [O] C-c ^ not fully useful
On 25 feb. 2013, at 10:28, Bastien b...@altern.org wrote: Hi François, sorting list items and headlines is now done against the visible part of the item and headlines, i.e., it ignores hidden links and emphasis markers. Hi Bastien, are you sure it removes emphasis markers as well? Looks to me that org-sort-remove-invisible only removes links. I guess it could be rewritten looking at invisibility properties, but that might be problematic when sorting includes a part of the buffer that has not yet been visible in a window and therefore might not be propertized properly. - Carsten I am not sure it is useful to add a parameter to `org-sort-list' and `org-sort-entries' to let the user change this default behavior: do you have a significant use-case for this? François Pinard pin...@iro.umontreal.ca writes: - Could some parameterisation be added so one could map user written functions over (free) option letters? Here again, my feeling is that it would be over-engineered -- would you use it yourself? How? Thanks for suggesting this improvements! -- Bastien -- Having an entire horizon of things you half-care about. -- Merlin Mann in Inbox Zero
Re: [O] Warning with latest git pull
Hi Achim, Achim Gratz strom...@nexgo.de writes: We shouldn't define things that don't have an org prefix. Fair enough. (Note that `with-buffer-modified-unmodified', from which org-unmodified was heavily copied, lives in bookmark.el. Perhaps Emacs should put it elsewhere.) I don't really see why we needed to replace org-unmodified in the first place, especially since with-silent-modifications does _more_ than org-unmodified, Especially *because* it does more. In particular, it does set `buffer-file-name' and `buffer-file-truename' to nil, which is a problem when preparing the agenda buffers. not less as your comment in org-macs would imply. I fixed the comment, thanks. Here's a patch to restore org-unmodified in the sources, make it an alias to with-silent-modifications when possible and augment the replacement definition with a few things that with-silent-modifications does on top of what org-unmodified did. We might even copy the whole macro definition from subr.el, but I think we're close enough with this. Thanks -- I applied a different patch, using `org-with-silent-modifications' as a compatibility macro for `with-silent-modifications'. Best, -- Bastien
Re: [O] Adventures with org-footnote-auto-adjust
Hello, t...@tsdye.com (Thomas S. Dye) writes: In the document I'm editing, I have sentences like this: If you want a list to start with a different value (e.g., 20),[fn:17] start the text of the item with ~[@20]~. As a matter of style, I prefer the footnote (which contains qualifying text, rather than a reference) be at the end of the sentence, and that it immediately follow the period. So, I cut and paste to get this: If you want a list to start with a different value (e.g., 20), start the text of the item with ~[@20]~.[fn:17] Now, the next time I insert a footnote, with C-c C-x f, I get something like this: If you want a list to start with a different value (e.g., 20),[fn:17] start the text of the item with ~[@20]~.[fn:17] The text of the original footnote, [fn:17], is lost, though the mark remains in the text. If the new [fn:17] is some distance away, then the problem of duplicate numbers isn't readily apparent in the midst of other work. Of course, I subsequently discovered that `~.[fn:17]' wasn't working and put the space back in. Now, the footnote refers to the wrong text. I've learned that there are certain conditions (I don't know how many) where the space after a sentence won't accept a footnote insertion. There shouldn't be any of such conditions. The example sentence is one of these. Apparently, it is the `~.' combination that triggers the condition. Org is good enough to prohibit inserting a new footnote into one of these black holes (which is how I discovered them), but it doesn't mind if I cut and paste a footnote into one. I fixed it. Footnote references should be allowed there. I'm not certain how much mischief this might have caused. I discovered the problem when the text of *both* footnotes in a section of the document were incorrect. In my case, org-footnote-auto-adjust doesn't perform any crucial function--it just makes the Org mode buffer seem more orderly. Given that there are black holes in the buffer, whose presence have the ability to confuse org-footnote-auto-adjust so that data are lost, should org-footnote-auto-adjust be deprecated? `org-footnote-auto-adjust' still does its job when, for example, a new footnote is created or a footnote is deleted. It is fragile when copy-pasting a footnote reference across some text. Anyway, it should be possible to fix most of these black holes, if only we are aware of them. Thanks for your report. Regards, -- Nicolas Goaziou
Re: [O] Bug: New HTML exporter incorrect attributes
Hello Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: tftor...@tftorrey.com (T.F. Torrey) writes: You don't assign attributes to an image in a paragraph, you assign attributes to the paragraph itself. It would be nice if there actually was a way to assign an attribute to a paragraph, so that the ATTR_HTML: class=XXX syntax would export as p class=XXX, but that is a different issue. It would be ATTR_HTML: :class XXX. I try to unify syntax for attributes with syntax for Babel and AFAICT, `html' is the last back-end to have key=value syntax. I see that this does not presently work, and the author listed on ox-html.el is not currently active on this list. I hope you are not the only one working on this. It would be our great misfortune for you to become burned out. For the time being, Org syntax doesn't allow to specify attributes per link object. I think what you are saying is that the current intended behavior is for whatever is specified by ATTR_HTML to apply to every image or link in the paragraph. No. I am saying that ATTR_HTML behaviour in _undefined_ when a paragraph contains more than one link, as it has always been. If you carefully look at Org manual (in application with previous exporter framework), in Images in HTML export, you will notice that HTML attributes only apply to a single link pointing to an image, not to a paragraph containing many links. I see no such limitation in the Org manual (12.5.6). It says this: If you need to add attributes to an inlined image, use a `#+ATTR_HTML'. Though the example that follows doesn't show a paragraph, calling them inline indicates they will be within a paragraph. Org manual section 12.5.4 also shows ATTR_HTML applying to a hyperlink by itself, but hyperlinks would rarely be used that way in real life, and in fact the old exporter always applied ATTR_HTML attributes to the next item in a paragraph. I have always understood the manual to mean that an ATTR_HTML would apply to *the next thing* in the document that it could, and that was what happened in practice. That was a useful thing for them to do. As a consequence, attributes will be assigned to every link within the paragraph. Is this behavior helpful to anyone in any practical circumstances? I never said it was. It's not even a feature. I'm just explaining what is happening. If it isn't intended behavior, and it isn't helpful, then we should make it stop doing that. Moreover, this means that, not only does the new exporter fail where the old one succeeded, I worked hard to make the new export framework compatible with defined behaviour of previous exporter, not with handy undocumented side-effects it may have. It seems to me that, whether the user is happy with the output or not, the HTML exporter ought to produce valid HTML. I agree. But, in this case, you're using undefined Org syntax (which, admittedly, used to work for you). The HTML exporter should produce valid HTML regardless of the input. If there's a simple patch that mimics this for html back-end, I don't mind applying it. But it still won't make up for a real solution. Unless, that is, it is decided that this behaviour is an official feature supported by Org, in which case, it should be added to the manual. The Org manual describes ATTR_HTML as a feature that applies to the following image or link. It makes no mention of restrictions to following content in the paragraph, and neither does it say it will apply to all following images or links. The manual could be amended to say that ATTR_HTML applies to just the next image or link. To fit the current situation, it might say, In cases where ATTR_HTML is applied to an image in a paragraph, following links will not be made invalid. But why would anyone be expecting invalid HTML in the first place? Incidentally, I always thought that simply using another HTML_ATTR would handle multiple images or links in the old exporter. In other words, this: #+ATTR_HTML: width=10 alt= [Cool thing] [[file:cool_thing.jpg]] This is a paragraph about cool things. #+ATTR_HTML: class=bar Cool thing found here [[http://example.com/][example.com]]. Would become this: p img src=cool_thing.jpg width=10 alt= [Cool thing] /This is a paragraph about cool things. Cool thing found here a href=http://example.com/; class=barexample.com/a. /p I don't remember using that in the old exporter, but I thought it would work. It almost works in the new exporter, but it begins a new paragraph before the second #+ATTR_HTML. I'm not sure this is the intended behavior, though, because it isn't formatted like other new paragraphs. A more general workaround that would help everyone affected would be to temporarily modify ox-html.el so that attributes from ATTR_HTML only apply to the *first* item in the paragraph. This would have the advantage of mimicking the behavior of the old exporter (thus not breaking existing content) and of keeping
[O] Add agenda entries into diary to export weelky calendar
Hi, still trying to get a printed calendar including all org-agendas, I noticed that the calendar/diary built-in function in emacs allows export of calendar views. Guess that and some post-processing for the print-job is all I need. However, I did not find a way how-to add org-agenda entries into the diary resp. into the calendar export. I know it works vice versa, seeing diary entries in org-agenda views. Did someone manage to achieve this. Alternatively, would it be of interest (and how difficult would it be) to get org-agenda exports as daily/weekly/monthly calendar as PDF (via LaTeX) or HTML? Guess to start this one would have to look into the new exporter functions and create a list of all agenda entries feeding this into a template. However, most of the functionality is already there via calendar/diary and I wonder which way would be the best; using those functions or create own. Alternatives: I read about calfw and org2hpda. However, I did not found a way to generate a printable version of calfw (and I had trouble to set it up). For org2hpda I still struggle with the installation and it seems to be broken at the moment. Not sure. All the best Torsten
[O] new version of org-mew.el
Hi, The attached is the new version of org-mew.el with several new features. I would appreciate it if some of Mew users could try this. If this is fine, I would like Bastien to incorporate it to the git repo. The changes are as follows: org-mew-store-link - Works in mew message mode as well as mew summary mode. org-mew-open - Locates the message in the inbox folder given by `org-mew-inbox-folder' if the message is not found in the link's folder. - Uses id.db to search the message if the message is not found or the folder is not specified by the link. You can disable this by setting `org-mew-use-id-db' to nil. org-mew-search - new function - Shows all entries related to the message using `org-search-view'. See the docstring for details. org-mew-capture - new function - Guesses the capture template from the folder name and invoke `org-capture'. See the docstring for details. My daily workflow using these features is something like this. ~/.mew.el: (define-key mew-summary-mode-map ' 'org-mew-search) (eval-after-load mew-summary '(define-key mew-summary-mode-map \C-o 'org-mew-capture)) 1. In the Mew's inbox folder, I take a glance at new messages to find a message that requires any action. 2. If the message is a reply from somebody and associated with the existing orgmode entry, type M-x org-mew-search (or press ['] key simply) to find the entry. If I can find the entry successfully and think I should start the task right now, start the task by M-x org-agenda-clock-in. 3. If the message is a brand-new message, type M-x org-mew-capture, enter the refile folder, and the buffer to capture the message is shown up (without selecting the template by hand!). And I fill the template and type C-c C-c to complete the capture. Note that I have configured `org-capture-templates' so that the captured entry has a link to the message. Thanks, --Tokuya ;;; org-mew.el --- Support for links to Mew messages from within Org-mode ;; Copyright (C) 2008-2013 Free Software Foundation, Inc. ;; Author: Tokuya Kameshima kames at fa2 dot so-net dot ne dot jp ;; Keywords: outlines, hypermedia, calendar, wp ;; Homepage: http://orgmode.org ;; This file is part of GNU Emacs. ;; GNU Emacs is free software: you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation, either version 3 of the License, or ;; (at your option) any later version. ;; GNU Emacs is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with GNU Emacs. If not, see http://www.gnu.org/licenses/. ; ;; ;;; Commentary: ;; This file implements links to Mew messages from within Org-mode. ;; Org-mode loads this module by default - if this is not what you want, ;; configure the variable `org-modules'. ;;; Code: (require 'org) (defgroup org-mew nil Options concerning the Mew link. :tag Org Startup :group 'org-link) (defcustom org-mew-link-to-refile-destination t Create a link to the refile destination if the message is marked as refile. :group 'org-mew :type 'boolean) (defcustom org-mew-inbox-folder nil The folder where new messages are incorporated. If `org-mew-inbox-folder' is non-nil, `org-mew-open' locates the message in this inbox folder as well as the folder specified by the link. :group 'org-mew :type 'string) (defcustom org-mew-use-id-db t Use ID database to locate the message if id.db is created. :group 'org-mew :type 'boolean) (defcustom org-mew-subject-alist (list (cons (concat ^\\(?:\\(?:re\\|fwd?\\): *\\)* \\(?:[[(][a-z0-9._-]+[:,]? [0-9]+[])]\\)? * \\(?:\\(?:re\\|fwd?\\): *\\)* \\(.*\\)[ \t]*) 1)) Alist of subject regular expression and matched group number for search. :group 'org-mew :type '(repeat (cons (regexp) (integer (defcustom org-mew-capture-inbox-folders nil List of the inbox folders whose messages need refile marked before capture. `org-mew-capture' will ask you to put the refile mark on the message if the message's folder is any of these folders and the message is not marked. Nil means `org-mew-capture' never ask you destination folders before capture. :group 'org-mew :type '(repeat string)) (defcustom org-mew-capture-guess-alist nil Alist of the regular expression of the folder name and the capture template selection keys. For example, '((\^%emacs-orgmode$\ . \o\) (\\ . \t\)) the messages in \%emacs-orgmode\ folder will be captured with the capture template associated with \o\ key, and any other messages will be captured with the capture
Re: [O] [PATCH] Make html exporter respect css-url configuration variable.
Hello, Rick Frankel r...@rickster.com writes: * lisp/ox-html.el: (org-export-define-backend): add css url option (org-export-htmlized-org-css-url): modify docstring and options. (org-html--build-style): include css-url if specified. Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] bug in expansion of variables in babel Perl
D M German dmg at uvic.ca writes: I think the issue is that, at least in my computer the variable $\ returns empty (the record separator). Thinko on my side, what I wanted was the input record separator $/ (to avoid specifying a literal newline for those systems where this is actually multi-character). Regards, Achim.
Re: [O] [PATCH] Make html exporter respect css-url configuration variable.
By the way, `org-html-htmlized-org-css-url' docstring looks wrong. `org-export-as-org' doesn't exist anymore, neither do batch mode. So, is the variable still useful? If it is, could someone could fix its docstring so it reflects what is really happening? Thank you. Regards, -- Nicolas Goaziou
Re: [O] How to make the new exporter open PDF using evince?
On Feb 25, 2013 2:52 PM, Nick Dokos nicholas.do...@hp.com wrote: I like putting things in ~/.mailcap, but you can season to taste. Ok, that's 2 votes so far for mailcap. I'll try that later. Thanks! hjh
[O] Bug: turn-on-font-lock breaks org-mode in recent emacs [7.9.3e (7.9.3e-3-gb07a9b @ /usr/share/emacs/24.3.50/lisp/org/)]
Until today, I had have these two (legacy) lines in my orgmode configuration ;; (global-font-lock-mode 1) ; for all buffers which is already a default in emacs. This is also noted in the manual http://orgmode.org/manual/Activation.html However: it is still recommended in the Org-Mode Beginners Customization Guide http://orgmode.org/worg/org-configs/org-customization-guide.html The second line made a bit of a mess of my .org files with the 20130224 version of emacs-snapshot ;; (add-hook 'org-mode-hook 'turn-on-font-lock) ; org-mode buffers only org files would still open, but show up as (imaginary example) [[gnus:982.3334][link]] instead of the nice underlined clickable links. Emacs : GNU Emacs 24.3.50.1 (i486-pc-linux-gnu, GTK+ Version 3.4.2) of 2013-02-24 on dex, modified by Debian Package: Org-mode version 7.9.3e (7.9.3e-3-gb07a9b @ /usr/share/emacs/24.3.50/lisp/org/) current state: == (setq org-export-blocks '((src org-babel-exp-src-block nil) (export-comment org-export-blocks-format-comment t) (ditaa org-export-blocks-format-ditaa nil) (dot org-export-blocks-format-dot nil)) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-reverse-note-order t org-agenda-skip-scheduled-if-done t org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code) org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-refile-targets '((org-agenda-files :level . 1)) org-modules '(org-bbdb org-bibtex org-crypt org-docview org-gnus org-info org-jsinfo org-irc org-mew org-mhe org-rmail org-vm org-wl org-w3m) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-babel-pre-tangle-hook '(save-buffer) org-occur-hook '(org-first-headline-recenter) org-export-interblocks '((src org-babel-exp-non-block-elements)) org-log-done 'time org-metaup-hook '(org-babel-load-in-session-maybe) org-reveal-start-hook '(org-decrypt-entry) org-confirm-elisp-link-function 'yes-or-no-p org-export-latex-format-toc-function 'org-export-latex-format-toc-default org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-crypt-key nil org-agenda-include-diary t org-export-first-hook '(org-beamer-initialize-open-trackers) org-mode-hook '(#[nil \300\301\302\303\304$\207 [add-hook before-save-hook org-encrypt-entries nil t] 5] #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-link-frame-setup '((vm . vm-visit-folder-other-frame) (gnus . gnus) (file . find-file-other-window)) org-agenda-start-on-weekday nil org-tags-exclude-from-inheritance '(crypt) org-directory ~/d/org org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc org-beamer-auto-fragile-frames org-beamer-place-default-actions-for-lists) org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars) org-metadown-hook '(org-babel-pop-to-session-maybe) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-after-todo-state-change-hook '(org-clock-out-if-current) org-confirm-shell-link-function 'yes-or-no-p ) -- BOFH excuse #94: Internet outage
Re: [O] CSS link in html export for v. 7.9.3e woes
Hi Daniel, Daniel Hawthorne wrote: Greetings, After updating to 7.9.3e, I no longer am able to include a stylesheet link with the following syntax: #+STYLE: link rel=stylesheet type=text/css href=../relative/path/to/mystyle.css/ If I go back to my previous version, it works as expected. It is not a path issue; On the resulting site, it never tries to load the stylesheet. The release notes do not mention anything that would lead me to believe that this should have changed. Suggestions welcome. I got into the same trouble days ago. Nicolas' answer was to use the new syntax therefore, that is: #+HTML_STYLE: ... Best regards, Seb -- Sebastien Vauban
Re: [O] Bug: New HTML exporter incorrect attributes
tftor...@tftorrey.com (T.F. Torrey) writes: It would be ATTR_HTML: :class XXX. I try to unify syntax for attributes with syntax for Babel and AFAICT, `html' is the last back-end to have key=value syntax. I see that this does not presently work, and the author listed on ox-html.el is not currently active on this list. I hope you are not the only one working on this. It would be our great misfortune for you to become burned out. It's not much work once we agree about the real syntax. For example, for links, there are two ways to replace: #+ATTR_HTML: width=400px The easiest one, is simply to ask for `:options' before: #+ATTR_HTML: :options width=\400px\ This is heavier but will be consistent with other back-ends. Otherwise, there is also: #+ATTR_HTML: :width 400px But this requires to have a list of all properties supported. If we take that route, here is a suggested list of such properties for a tag: - rel - target - type - accesskey - class - style - title and for img - alt - height - width What do you think about it? The HTML exporter should produce valid HTML regardless of the input. We cannot remove the ability to shoot oneself in the foot. The HTML back-end cannot be responsible for undefined syntax. Think about: @@html:foo@@ The Org manual describes ATTR_HTML as a feature that applies to the following image or link. It makes no mention of restrictions to following content in the paragraph, and neither does it say it will apply to all following images or links. The manual could be amended to say that ATTR_HTML applies to just the next image or link. To fit the current situation, it might say, In cases where ATTR_HTML is applied to an image in a paragraph, following links will not be made invalid. But why would anyone be expecting invalid HTML in the first place? Incidentally, I always thought that simply using another HTML_ATTR would handle multiple images or links in the old exporter. In other words, this: #+ATTR_HTML: width=10 alt= [Cool thing] [[file:cool_thing.jpg]] This is a paragraph about cool things. #+ATTR_HTML: class=bar Cool thing found here [[http://example.com/][example.com]]. Would become this: p img src=cool_thing.jpg width=10 alt= [Cool thing] /This is a paragraph about cool things. Cool thing found here a href=http://example.com/; class=barexample.com/a. /p I don't remember using that in the old exporter, but I thought it would work. It almost works in the new exporter, but it begins a new paragraph before the second #+ATTR_HTML. I'm not sure this is the intended behavior, though, because it isn't formatted like other new paragraphs. This is the intended behaviour. Affiliated keywords can only exist at the beginning of the element they refer to. So, in the previous example, you start two paragraphs. Alternatively, having ATTR_HTML (or something more general) apply to the next thing, and having that work within paragraphs, is another possibility. However, this may not fit within the limitations of the new parser. Plus it's kind of ugly. The parser won't support it. It goes against the definition of an affiliated keyword. Moreover, it's merely a hack (what about links in tables?). And it's ugly, indeed. Until there is a proper solution, however, could we please modify the exporter to apply ATTR_HTML to only the next image or link? I am very sure that was the spirit of the old exporter, and it would be nice if I could maintain my documents in Org without resorting to (even more) hacks. Done. Regards, -- Nicolas Goaziou
Re: [O] Bug: New HTML exporter incorrect attributes
#+ATTR_HTML: :options width=\400px\ This is heavier but will be consistent with other back-ends. Otherwise, there is also: #+ATTR_HTML: :width 400px But this requires to have a list of all properties supported. How about both? I.e. a short-list of common options (class, title, id for links typically) plus a generic options as a back up to put whatever is not in the short-list ? /v, big fan of the ugliest solutions imaginable If we take that route, here is a suggested list of such properties for a tag: - rel - target - type - accesskey - class - style - title and for img - alt - height - width What do you think about it? The HTML exporter should produce valid HTML regardless of the input. We cannot remove the ability to shoot oneself in the foot. The HTML back-end cannot be responsible for undefined syntax. Think about: @@html:foo@@ The Org manual describes ATTR_HTML as a feature that applies to the following image or link. It makes no mention of restrictions to following content in the paragraph, and neither does it say it will apply to all following images or links. The manual could be amended to say that ATTR_HTML applies to just the next image or link. To fit the current situation, it might say, In cases where ATTR_HTML is applied to an image in a paragraph, following links will not be made invalid. But why would anyone be expecting invalid HTML in the first place? Incidentally, I always thought that simply using another HTML_ATTR would handle multiple images or links in the old exporter. In other words, this: #+ATTR_HTML: width=10 alt= [Cool thing] [[file:cool_thing.jpg]] This is a paragraph about cool things. #+ATTR_HTML: class=bar Cool thing found here [[http://example.com/][example.com]]. Would become this: p img src=cool_thing.jpg width=10 alt= [Cool thing] /This is a paragraph about cool things. Cool thing found here a href=http://example.com/; class=barexample.com (http://example.com)/a. /p I don't remember using that in the old exporter, but I thought it would work. It almost works in the new exporter, but it begins a new paragraph before the second #+ATTR_HTML. I'm not sure this is the intended behavior, though, because it isn't formatted like other new paragraphs. This is the intended behaviour. Affiliated keywords can only exist at the beginning of the element they refer to. So, in the previous example, you start two paragraphs. Alternatively, having ATTR_HTML (or something more general) apply to the next thing, and having that work within paragraphs, is another possibility. However, this may not fit within the limitations of the new parser. Plus it's kind of ugly. The parser won't support it. It goes against the definition of an affiliated keyword. Moreover, it's merely a hack (what about links in tables?). And it's ugly, indeed. Until there is a proper solution, however, could we please modify the exporter to apply ATTR_HTML to only the next image or link? I am very sure that was the spirit of the old exporter, and it would be nice if I could maintain my documents in Org without resorting to (even more) hacks. Done. Regards, -- Nicolas Goaziou
Re: [O] Bug: New HTML exporter incorrect attributes
Hello, Vincent Beffara vbeff...@ens-lyon.fr writes: #+ATTR_HTML: :options width=\400px\ This is heavier but will be consistent with other back-ends. Otherwise, there is also: #+ATTR_HTML: :width 400px But this requires to have a list of all properties supported. How about both? I.e. a short-list of common options (class, title, id for links typically) plus a generic options as a back up to put whatever is not in the short-list ? A generic :options keyword is a good idea, indeed. But we still have to agree on the common options part. For example, I think :id is dangerous, because Org already provides its own way to generate these properties (e.g. through #+NAME: keywords). If we make a list of such options, per tag type, I can try to implement it. Anyone wants to start? Regards, -- Nicolas Goaziou
[O] Possible to both clock into :CLOCK: and put notes in :LOGBOOK: ?
Platform: GNU Emacs 23.2.1 (i386-mingw-nt6.1.7600) of 2010-05-08 on G41R2F1 Org-mode version 7.9.1 (release_7.9.1-321-g9ebf47.dirty-git @ c:/Users/steinarb/Documents/git/org-mode/lisp/) I have org-clock-into-drawer set to CLOCK. The idea is to put clocking info in the :CLOCK: drawer to avoid clutter, and this works. But if I have this setting then notes created with `C-c C-z' end up on the top level, even if I manually create a :LOGBOOK: drawer. Is it possible to have both? Ie. for a particular node, both: - Put clocking into the :CLOCK: drawer - Put notes into the :LOGBOOK: drawer (if there is one)
Re: [O] [PATCH] datetree: Recognize year headline with tags as a match
On Mon, Feb 25, 2013 at 10:48:16AM +0100, Bastien wrote: Hi Tim, Tim Burt tcb...@rochester.rr.com writes: * lisp/org-datetree.el (org-datetree-find-year-create): Include regexp for tags. Syntax was taken directly from org-todo-line-tags-regexp in org.el. Applied, thanks a lot for the patch and the detailed change log! Best, I can confirm that latest git fixes my use case. Thank you both so much. Jeff -- The man who does not read good books has no advantage over the man who cannot read them. -- Mark Twain
Re: [O] evaluation of perl in babel
dmg d...@uvic.ca writes: On Mon, Feb 25, 2013 at 1:54 AM, D M German d...@uvic.ca wrote: Achim You may misunderstand some things, or I don't understand what you are Achim asking. It is (at least currently) the responsibility of the Perl Achim program (or any other Babel language) to deliver the result in such a Achim way that it can be interpreted correctly by the result type chosen (in Achim other word, the program output must be valid Org syntax in the given Achim context). You can't have the same program produce tables, vectors and Achim LaTeX output just by switching the results type. I understand. But what I want is the output to be wrapped accordingly, and my script to deliver exactly the output as expected. So say I want to generate HTML in my script, I can use :results output, but then I have to change to replace the #+being_example with #+begin_HTML. I guess that I can generate a two dimensional table with perl too using output (printing the necessary | and \n), but then it will be wrapped with #+begin_example. Ok, I got it. What I need is to return a string with whatever I need. A bit cumbersome, but I can live with it It might be worth spending some time with the Org-mode manual. http://orgmode.org/manual/Working-With-Source-Code.html You could also use :results org or :results raw, and then return raw Org-mode from your Perl script instead of html. Best, #+begin_src perl :results html table ba /b /table #+end_src #+RESULTS: #+BEGIN_HTML table ba /b /table #+END_HTML thanks again for the explanation, -- Eric Schulte http://cs.unm.edu/~eschulte
[O] tabulated-list
Hi, Org people. This morning, I could not load Org because ox.el calls function tabulated-list, which does not seem to exist on this version of Emacs. So I fetched the one at https://github.com/sigma/tabulated-list.el to get going, but others will likely have the same problem. François
Re: [O] tabulated-list
Hello, François Pinard pin...@iro.umontreal.ca writes: This morning, I could not load Org because ox.el calls function tabulated-list, which does not seem to exist on this version of Emacs. So I fetched the one at https://github.com/sigma/tabulated-list.el to get going, but others will likely have the same problem. Indeed, I introduced this change because I was reinventing the wheel in `org-export-stack'. I hadn't realized it was emacs24 only. Bastien, is there another solution besides reverting the commit? Regards, -- Nicolas Goaziou
Re: [O] {New exporter] What happened to the export template
Hello Bastien, Bastien wrote: Nicolas Goaziou n.goaz...@gmail.com writes: It has been removed. Such a template depends on the back-end used, which was not the case of the previous implementation. One idea would be to have an equivalent of the now-defunct `org-insert-export-options-template' but for each backend. For example `C-c C-e h t' would insert the default template for the HTML export. Is anyone interested in this? My personal answer is: yes! I constantly used it for inserting a title (defaulting to the name of the file, which is the best default), timestamp, etc. Regarding Rasmus objections, yes, maybe there are too much defaults inserted, or not yours. Maybe the template could be customized, but present in the code base with a common, good default? If not, anyway, I'll just mimick the old template with a YASnippet. Best regards, Seb PS- By the way, there is already such a sort of template for Beamer... -- Sebastien Vauban
Re: [O] [PATCH] ob-R.el, ox-latex.el: support for tikz graphics
Hello, Thanks for extracting that patch from the other one. Aaron Ecay aarone...@gmail.com writes: Tikz graphics should be exported to LaTeX by \include, not as a link. This commit changes the file extension used for tikz graphics from .tex to .tikz. I'm wondering if it's really meant to be inserted as an inline image. Does it support wrapfigure environment or width optional attribute? If it doesn't, it may be better to implement a dedicated (or a more general input function) formatting function that would be called from `org-latex-link'. What do you think? Regards, -- Nicolas Goaziou
Re: [O] Exporter question
Hello, Bastien b...@altern.org writes: Carsten Dominik carsten.domi...@gmail.com writes: I am curious why you chose the name optional_title for the property? Why not, for example TOC_TITLE or something like this? I suggest EXPORT_ALT_TITLE instead. The EXPORT_ prefix seems more consistent with EXPORT_TITLE, and ALT sounds clearer (and short enough) to me. Has it to be an export only property? I mean, it could be used in a library like org-toc.el. Also EXPORT_KEYWORD prefix is mostly used when there is a global #+KEYWORD: available. There is no #+ALT_TITLE: (yet?). So, what about ALT_TITLE instead? Regards, -- Nicolas Goaziou
Re: [O] [texinfo] Info links
Hello Tom.
On 21 February 2013 18:26, Thomas S. Dye t...@tsdye.com wrote:
Hi Jon,
Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:
Hello Tom,
On 21 February 2013 15:09, Thomas S. Dye t...@tsdye.com 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!
I've added support for both # and : in info links. So now it should
work either way.
Regards,
--
Jon
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [texinfo] Bug(?) in detailed node listing
Hi Tom, On 21 February 2013 18:44, Thomas S. Dye t...@tsdye.com wrote: Hi Jon, [...] 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. I've just pushed a fix for this. It also introduces a new defcustom to allow for choosing the column you want it to align at (org-texinfo-node-description-column). Regards, -- Jon Thanks for your help on this. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] bug-tracker
Hi, Suvayu Ali wrote: On Fri, Feb 22, 2013 at 08:56:54PM +0100, Andreas Röhler wrote: With exception of the noise, M-x report-emacs-bugs tends to send. Org already uses one of its own: org-submit-bug-report Maybe we could add an alias such as `M-x report-org-bugs' to mimick that one? Best regards, Seb -- Sebastien Vauban
Re: [O] Adventures with org-footnote-auto-adjust
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, t...@tsdye.com (Thomas S. Dye) writes: I've learned that there are certain conditions (I don't know how many) where the space after a sentence won't accept a footnote insertion. There shouldn't be any of such conditions. Great. I'll be on the lookout and will report when I find them. The example sentence is one of these. Apparently, it is the `~.' combination that triggers the condition. Org is good enough to prohibit inserting a new footnote into one of these black holes (which is how I discovered them), but it doesn't mind if I cut and paste a footnote into one. I fixed it. Footnote references should be allowed there. Yes, I can confirm that this is fixed. Thanks! I'm not certain how much mischief this might have caused. I discovered the problem when the text of *both* footnotes in a section of the document were incorrect. In my case, org-footnote-auto-adjust doesn't perform any crucial function--it just makes the Org mode buffer seem more orderly. Given that there are black holes in the buffer, whose presence have the ability to confuse org-footnote-auto-adjust so that data are lost, should org-footnote-auto-adjust be deprecated? `org-footnote-auto-adjust' still does its job when, for example, a new footnote is created or a footnote is deleted. It is fragile when copy-pasting a footnote reference across some text. In my case, the intended effects of `org-footnote-auto-adjust' were purely cosmetic in the Org buffer and didn't affect the output. Is there a situation where it does something that has an effect on output? Anyway, it should be possible to fix most of these black holes, if only we are aware of them. OK. Apologies for the graphic term. I hope it didn't offend. Dismay got the better of tact, I think. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [org-e-texinfo] generate menu items
Hello, On 23 February 2013 18:04, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, [...] I eventually added :OPTIONAL_TITLE: property. Get its parsed value with `org-export-get-optional-title' function. I patched ox-ascii, ox-latex and ox-html so they use it when building a TOC. I think only ox-odt and ox-texinfo are missing. Jonathan, could you have a look at it? I've replaced the use of :TEXINFO_MENU_TITLE: with :OPTIONAL_TITLE:. Tom, This will cause the menu titles to no longer export properly until you change the property names. Regards, -- Jon Thank you. Regards, -- Nicolas Goaziou
Re: [O] [bug] orgstruct has suddenly become overly opinionated about legal keystrokes
Hello, Eric Schulte wrote: I use orgstruct mode in my message mode, so that I may easily include tables and lists when writing and responding to mail. So do I... [...] is new behavior as of the last couple of weeks. ... and I also experience a quite recent change. Before, when composing an email, I could edit lists and convert them from itemized to enumerated ones, such in: - blond - 1. blond - brown - 2. brown ... by S-right'ing on it: ╭ │ S-right runs the command org-shiftright, which is an interactive Lisp │ function in `org.el'. │ │ It is bound to S-right, menu-bar Org TODO Lists Select keyword Next │ keyword, menu-bar Org Dates and Scheduling Change Date 1 Day Later. │ │ (org-shiftright optional ARG) │ │ Cycle the thing at point or in the current line, depending on context. │ Depending on context, this does one of the following: │ │ - switch a timestamp at point one day into the future │ - on a headline, switch to the next TODO keyword. │ - on an item, switch entire list to the next bullet type │ - on a property line, switch to the next allowed value │ - on a clocktable definition line, move time block into the future ╰ Now, in emails (not in regular Org files), that does not work anymore: ╭ │ right (translated from S-right) runs the command right-char, which is an │ interactive compiled Lisp function in `bindings.el'. │ │ It is bound to right. │ │ (right-char optional N) │ │ Move point N characters to the right (to the left if N is negative). │ On reaching beginning or end of buffer, stop and signal error. │ │ Depending on the bidirectional context, this may move either forward │ or backward in the buffer. This is in contrast with C-f │ and C-b, which see. ╰ Best regards, Seb -- Sebastien Vauban
Re: [O] Adventures with org-footnote-auto-adjust
t...@tsdye.com (Thomas S. Dye) writes: In my case, the intended effects of `org-footnote-auto-adjust' were purely cosmetic in the Org buffer and didn't affect the output. Is there a situation where it does something that has an effect on output? No, there is none. OK. Apologies for the graphic term. I hope it didn't offend. Dismay got the better of tact, I think. No offence taken. I couldn't come with a better name either. Regards, -- Nicolas Goaziou
Re: [O] [org-e-texinfo] generate menu items
Hello On 25 February 2013 11:09, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes: I've replaced the use of :TEXINFO_MENU_TITLE: with :OPTIONAL_TITLE:. Thank you for looking into it. Though, please use `org-export-get-optional-title' function instead. OPTIONAL_TITLE property only contains the raw string. The function will return the parsed string. I actually did use (org-export-get-optional-title), I just wrote the wrong information in the changelog. Sorry Regards, Jon Note: the function may be renamed soon, but I'll take care of that when it happens. Regards, -- Nicolas Goaziou
Re: [O] [bug] orgstruct has suddenly become overly opinionated about legal keystrokes
Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: [...] is new behavior as of the last couple of weeks. ... and I also experience a quite recent change. Before, when composing an email, I could edit lists and convert them from itemized to enumerated ones, such in: - blond - 1. blond - brown - 2. brown ... by S-right'ing on it: This should be fixed in master. de5ff23 org.el: Bind org-shift* in orgstruct-mode. Christopher
Re: [O] how can I insert a new heading after all at this level?
Hello David, On 19 February 2013 14:53, David Naumann naum...@cs.stevens.edu wrote: I'm a happy, frequent user of org mode but there's something I can't figure out from the manual. What I would like to be able to do is insert a new heading at the same level as current, _following_ all the others. For example, with the cursor on the A in this tree: * top - ** A ** B ** C * next I would like to insert a last sibling and move to it: * top ** A ** B ** C - ** * next Use case: adding to a very long chronological list. I have not seen a quick way to do this using the structure motion/editing commands in the manual, without scrolling in one way or another. If you have a hint, please reply to my address; I'm not on this mailing list. The following is a little long, however only one function is actually interactive. #+begin_src emacs-lisp (require 'org-element) (defun zin/org-next-element () Move to the end of the current element (start of next). (let ((end (org-element-property :end (org-element-at-point (goto-char end))) (defun zin/org-element-check-element (type optional name) Check if current element is of type TYPE. If not move to next element using `zin/org-next-element'. If NAME is non-nil, verify that the :name or :drawer-name property matches it. (save-excursion (save-restriction (save-excursion (org-up-element) (org-narrow-to-element)) (catch 'element (while (not (eobp)) (let ((cur-type (car (org-element-at-point))) ;; Allows for adaptation to non-headline cases. (cur-name (or (org-element-property :name (org-element-at-point)) (org-element-property :drawer-name (org-element-at-point) (if (and (string= type cur-type) (string= name cur-name)) (throw 'element (point)) (zin/org-next-element (defun zin/org-element-start-or-end (start optional level) Find start or ending point of an element's content. If START is non-nil, return the beginning of the content, if nil return the end. If LEVEL is equal to 1, parse the buffer for level 1 headlines. Any other value is ignored. ;; If level is 1, looking at top level headlines, there is no ;; containing element. (if (and level (= 1 level)) (let* ((map (org-element-map (org-element-parse-buffer) 'headline (lambda (hl) ;; return a list of beginning and ending ;; points of all level 1 headlines. (list (org-element-property :begin hl) (org-element-property :end hl))) 'nil 'nil 'headline)) ;; Find smallest (when start is 't) or largest (when ;; start is 'nil) point. (point (if start (apply 'min (mapcar 'car map)) (apply 'max (mapcar 'cadr map) point) ;; Not in a top level headline, deal with contents directly. (let ((top(org-element-property :contents-begin (org-element-at-point))) (bottom (org-element-property :contents-end (org-element-at-point (if start top bottom (defun zin/org-add-heading (start optional title) Create a new heading at the before or after all headings of current level. If START is non-nil, the new heading will be the first in the list. If nil it will be created after all the others. With optional TITLE, automatically insert the desired title, leaving the point on the following line. (interactive P) (org-back-to-heading) (let* ((level (org-element-property :level (org-element-at-point))) (point (save-excursion (ignore-errors (org-up-element)) (zin/org-element-start-or-end start level))) ;; Org-element minimal version of a headline at LEVEL with ;; TITLE (or blank) (headline `(headline (:level ,level :title ,(or title ) (if start ;; If placing headline above existing headlines, ensure you do ;; not place it above the content of the parent headline. (progn ;; Search from top of content of parent headline. Without ;; this it will put it above the current headline. (goto-char point) ;; Do not check to make sure content is skipped if in a ;; level 1 headline, just return the start of the top ;; headline. (unless (= 1 level) (goto-char (zin/org-element-check-element headline (goto-char point)) (org-save-outline-visibility 't
Re: [O] [org-e-texinfo] generate menu items
Hello, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes: I've replaced the use of :TEXINFO_MENU_TITLE: with :OPTIONAL_TITLE:. Thank you for looking into it. Though, please use `org-export-get-optional-title' function instead. OPTIONAL_TITLE property only contains the raw string. The function will return the parsed string. Note: the function may be renamed soon, but I'll take care of that when it happens. Regards, -- Nicolas Goaziou
Re: [O] [texinfo] Appendix?
Hello Tom, On 22 February 2013 18:28, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com wrote: Hello Tom On 22 February 2013 17:55, Thomas S. Dye t...@tsdye.com wrote: Aloha Jon, [...] I don't understand. This: * Concept index :PROPERTIES: :TEXINFO_MENU_TITLE: Concept Index :INDEX:cp :END: Gives me a numbered headline and an empty section. If I add this: @@info:@printindex cp@@ then an index is generated. The headline is still numbered. Am I doing something wrong? I don't think so. From the looks of things, index wasn't fixed along with other properties to be uppercase in ox-texinfo.el. I should be able to fix it on Monday (and make sure it now works), along with the spacing of the detailed node listing. Regards, Jon I've now fixed this. Headlines with an :INDEX: property will now export as: #+BEGIN_EXAMPLE @unnumbered TITLE (or equivalent unnumbered subheading) content of headline @printindex INDEX (assuming INDEX is a recognized type, otherwise it will simply be an unnumbered headline. I've additionally added support for appendices. These will export as @appendix TITLE. Indexes and appendices are mutually exclusive, indexes are tested for first. Regards, Jon
Re: [O] tabulated-list
Nicolas Goaziou n.goaz...@gmail.com writes: this change because I was reinventing the wheel in `org-export-stack'. I hadn't realized [tabulated-list.el] was emacs24 only. Bastien, is there another solution besides reverting the commit? Could tabulated-list.el be conveyed within Org as org-tabulated-list.el and loaded only if tabulated-list is not already available? François
Re: [O] org-drill - properties displayed during card review
Hi Paul, Paul Sexton psexton...@gmail.com writes: So if you download and use the org-drill.el from there, the problem will be fixed. Thanks for maintaining org-drill.el! I updated the version in the contrib/ repository to org-drill.el 2.3.7. Best, -- Bastien
Re: [O] {New exporter] What happened to the export template
Hello, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Hello Bastien, Bastien wrote: Nicolas Goaziou n.goaziou-re5jqeeqqe8avxtiumw...@public.gmane.org writes: It has been removed. Such a template depends on the back-end used, which was not the case of the previous implementation. One idea would be to have an equivalent of the now-defunct `org-insert-export-options-template' but for each backend. For example `C-c C-e h t' would insert the default template for the HTML export. Is anyone interested in this? My personal answer is: yes! I constantly used it for inserting a title (defaulting to the name of the file, which is the best default), timestamp, etc. You can also type #+ti M-TAB M-TAB to get the same result. It works for most default keywords. Regards, -- Nicolas Goaziou
Re: [O] [texinfo] Bug(?) in detailed node listing
Hi Jon, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes: Hi Tom, On 21 February 2013 18:44, Thomas S. Dye t...@tsdye.com wrote: Hi Jon, [...] 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. I've just pushed a fix for this. It also introduces a new defcustom to allow for choosing the column you want it to align at (org-texinfo-node-description-column). Nice. Thanks! One nit: You have one space between the `::' at the end of a long title and the start of the description, where the Org manual has two spaces. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [texinfo] Appendix?
Hi Jon, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes: Hello Tom, I've now fixed this. Headlines with an :INDEX: property will now export as: #+BEGIN_EXAMPLE @unnumbered TITLE (or equivalent unnumbered subheading) content of headline @printindex INDEX (assuming INDEX is a recognized type, otherwise it will simply be an unnumbered headline. Yes, this works nicely. I've additionally added support for appendices. These will export as @appendix TITLE. An :APPENDIX: property triggers this one, which works as advertised. Thanks! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [org-e-texinfo] generate menu items
Hi Jon, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes: Hello, On 23 February 2013 18:04, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, [...] I eventually added :OPTIONAL_TITLE: property. Get its parsed value with `org-export-get-optional-title' function. I patched ox-ascii, ox-latex and ox-html so they use it when building a TOC. I think only ox-odt and ox-texinfo are missing. Jonathan, could you have a look at it? I've replaced the use of :TEXINFO_MENU_TITLE: with :OPTIONAL_TITLE:. Tom, This will cause the menu titles to no longer export properly until you change the property names. I can confirm that this works. Thanks! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] org-drill - properties displayed during card review
Paul Sexton psexton...@gmail.com writes: I just never got around to fixing that minor glitch until now. I have committed a fix to the org-drill repository at http://bitbucket.org/eeeickythump/org-drill So if you download and use the org-drill.el from there, the problem will be fixed. Thanks very much - that seems to have done the trick.
Re: [O] [texinfo] Bug(?) in detailed node listing
Hello Tom, On 25 February 2013 11:57, Thomas S. Dye t...@tsdye.com wrote: Hi Jon, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes: Hi Tom, On 21 February 2013 18:44, Thomas S. Dye t...@tsdye.com wrote: Hi Jon, [...] 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. I've just pushed a fix for this. It also introduces a new defcustom to allow for choosing the column you want it to align at (org-texinfo-node-description-column). Nice. Thanks! One nit: You have one space between the `::' at the end of a long title and the start of the description, where the Org manual has two spaces. This should now be fixed (along with a logic error that was actually inserting description at column+5) Regards, Jon All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Warning with latest git pull
Bastien writes: I fixed the comment, thanks. I'm starting to sound like Drew, but the new comment says exactly what the old one did, just the two parts juxtaposed. The point of having the new macro is to avoid the question about reverting the file when the file visited by a buffer has been edited outside Emacs. You can do exactly the same changes (cosmetic or not) with both macros, but org-unmodified will ask you when the file and the buffer have diverged due to the file changing outside Emacs. You shouldn't do this of course unless you know with certainty that you are never going to save the file. There's another difference between these two: org-unmodified does not let you change read-only buffers (I don't know if that's intentional or not). With all this said, the compatibility part of org-with-silent-modifications can't simply be plugging in org-unmodified (this loses functionality that presumably was needed). The change to make from the implementation I gave would be losing the let-bindings for buffer-file-name buffer-file-truename and perhaps inhibit-read-only. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Correct / best way of loading packages in contrib when using org compiled from git?
Rainer M Krug writes: Well - I could and I guess nothing would change. Why I like my setup at the moment is, that I have all emacs config, installation and elpa in my .emacs.d directory. Would this be the same after using make up2? Would I have to change paths somewhere? You can install Org wherever you like if you let your Emacs configuration find it. You need to put suitable definitions for lispdir datadir and infodir into local.mk, the easiest way is probably to just point prefix at your emacs.d (you must use the absolute path, not the tilde abbreviation ~/...). Check the result of these changes with make config before you first install. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[O] M-S-(down-arrow) worked briefly this morning and now does not
Hi. I updated my emacs git, got the new org-mode, and tried M-S-UpArrow. And it worked. I was elated. And then I closed the program and re-opened it, and now it no longer works. The message is: This command is active in special context like tables, headlines or items --Susan
[O] pxref in texinfo export
Aloha all,
IIUC, there is currently no support for @pxref{} in the texinfo
exporter. This is a texinfo @-command that does one thing in the info
output and another in the LaTeX output.
My idea is to create a custom link type, something like this:
(org-add-link-type
pxref nil
(lambda (path desc format)
(cond
((eq format 'html)
(format span class=\pxref\%s/span path))
((eq format 'latex)
(format \\ref{%s} path))
((eq format 'texinfo)
(format @pxref{%s,%s} path desc)
I haven't tested this, but it should export approximately correctly and
I'm confident I can get the export part working.
What I can't figure out is how to have Org recognize that a link like
this:
[[pxref:Internal link]]
is really an internal link, rather than an external link. I'd like to
be able to click on this and end up at Internal link in the Org
buffer.
Is this possible? If so, can you point me to a solution?
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 HTML exporter: Oddities with figure placement
It seems that figure placement has changed in HTML files generated by the new (compared with the old) exporter. For example, here's a simple org file: - This is an org file [[file:figure.png]] * Abstract This is an abstract - When I export, all looks fine, except that the figure is centered (left to right) rather than being left-justified, which I could have sworn it used to be. Since I prefer left justification by default, I tried adding the line #+ATTR_HTML: align=left immediately before the figure link. Now when I export to HTML, the figure is left justified as I want, but the following text appears to the right of the figure, not below it, which isn't what I want. It seems odd that this would happen even when I have a blank line separating the figure link from the following text. Am I missing something? Thanks. Richard Stanton
Re: [O] Possible to both clock into :CLOCK: and put notes in :LOGBOOK: ?
Steinar Bang writes: But if I have this setting then notes created with `C-c C-z' end up on the top level, even if I manually create a :LOGBOOK: drawer. Is it possible to have both? Unless it's been broken recently it should, but you probably need to customize org-log-into-drawer to t (for LOGBOOK) or set the property LOG_INTO_DRAWER if you want to keep this setting different in different subtrees. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[O] HTML export: no date in postamble unless set manually
I have org-export-html-postamble set to t. When I export a simple org file that has no explicit #+date line (using the new exporter), I get a line that says Date: at the bottom of the resulting HTML file, but there's no date listed next to it. If I add an explicit #+date line, it is correctly transferred to the bottom of the HTML file, but wouldn't it make sense to have today's date listed if no explicit alternative is provided? At any rate, adding a line that says Date: with nothing after the colon doesn't seem like the optimal default setting. Thanks. Richard Stanton
Re: [O] M-S-(down-arrow) worked briefly this morning and now does not
Susan Cragin susancra...@earthlink.net wrote: Hi. I updated my emacs git, got the new org-mode, and tried M-S-UpArrow. And it worked. I was elated. And then I closed the program and re-opened it, and now it no longer works. The message is: This command is active in special context like tables, headlines or items Not sure what version you are using, but in the version I'm using which is from yesterday or the day before: Org-mode version 7.9.3f (release_7.9.3f-1199-g3a0e55 @ /home/nick/elisp/org-mode/lisp/) that message is only triggered if S-M-left or S-M-right is invoked on the non-special context (i.e. just an ordinary line). OTOH, S-M-up and S-M-down end up calling org-drag-line-backward and org-drag-line-forward respectively. So either you are pressing the wrong arrow key or a bug has been introduced in the last day or so. Nick
Re: [O] [texinfo] Bug(?) in detailed node listing
Hi Jon, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes: Hello Tom, One nit: You have one space between the `::' at the end of a long title and the start of the description, where the Org manual has two spaces. This should now be fixed (along with a logic error that was actually inserting description at column+5) I hadn't detected the logic error, but can confirm that the other fix works. Thanks! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] pxref in texinfo export
Hello Tom,
On 25 February 2013 12:52, Thomas S. Dye t...@tsdye.com wrote:
Aloha all,
IIUC, there is currently no support for @pxref{} in the texinfo
exporter. This is a texinfo @-command that does one thing in the info
output and another in the LaTeX output.
Ultimately there is actually no real difference between see @ref{}
and @pxref{}. I just checked using the first @pxref{} in org.texi
(Under Activation).
In org.texi it is shown as (@pxref{Conflicts}), in org.html it
becomes: (see a href=#ConflictsConflicts/a) while in the info
file (org) it is shown as (*note Conflicts::).
Opening the info file in Info (C-u C-h i path to info file), *node
Conflicts:: becomes see Conflicts. Adding see manually
before *note does not change the output. The same is the case for
@xref{}. @xref{} adds See before the link in html/LaTeX, and
uses *Note in the info document; See [[link]] produces the same See in
html/LaTeX, and creates See *note in the info file (which is
inserted as See link in Emacs Info.
Yes the output is different if looking at the info file directly,
however when viewing it withing Emacs the text is consistent.
I didn't implement support for @xref{} or @pxref{} in the texinfo
exporter, because I could not find a way to reliably determine the
context so as to use the right type of link in the texi file.
Using occur there were already 47 cases in org.texi where [Ss]ee
@ref was used rather than the stylistically appropriate @pxref/@xref.
Regards,
Jon
My idea is to create a custom link type, something like this:
(org-add-link-type
pxref nil
(lambda (path desc format)
(cond
((eq format 'html)
(format span class=\pxref\%s/span path))
((eq format 'latex)
(format \\ref{%s} path))
((eq format 'texinfo)
(format @pxref{%s,%s} path desc)
I haven't tested this, but it should export approximately correctly and
I'm confident I can get the export part working.
What I can't figure out is how to have Org recognize that a link like
this:
[[pxref:Internal link]]
is really an internal link, rather than an external link. I'd like to
be able to click on this and end up at Internal link in the Org
buffer.
Is this possible? If so, can you point me to a solution?
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] pxref in texinfo export
There are 4 different ref commands, all with slightly syntactic
requirements and outputs when compiled using makeinfo. I for one use
@pxref{} a lot, and it has different requirements for placement than
@ref or @xref (namely those two MUST have a . or , following the end
of the ref)
8.1 Different Cross Reference Commands
There are four different cross reference commands:
@xref Used to start a sentence in the printed manual saying ‘See . . .
’ or an Info
cross-reference saying ‘*Note name : node.’.
@ref Used within or, more often, at the end of a sentence; same as
@xref for Info;
produces just the reference in the printed manual without a preceding ‘See’.
@pxref Used within parentheses to make a reference that suits both an
Info file and a
printed book. Starts with a lower case ‘see’ within the
printed manual. (‘p’ is
for ‘parenthesis’.)
@inforef Used to make a reference to an Info file for which there is
no printed manual.
(from the Texinfo manual)
On Mon, Feb 25, 2013 at 10:32 AM, Jonathan Leech-Pepin
jonathan.leechpe...@gmail.com wrote:
Hello Tom,
On 25 February 2013 12:52, Thomas S. Dye t...@tsdye.com wrote:
Aloha all,
IIUC, there is currently no support for @pxref{} in the texinfo
exporter. This is a texinfo @-command that does one thing in the info
output and another in the LaTeX output.
Ultimately there is actually no real difference between see @ref{}
and @pxref{}. I just checked using the first @pxref{} in org.texi
(Under Activation).
In org.texi it is shown as (@pxref{Conflicts}), in org.html it
becomes: (see a href=#ConflictsConflicts/a) while in the info
file (org) it is shown as (*note Conflicts::).
Opening the info file in Info (C-u C-h i path to info file), *node
Conflicts:: becomes see Conflicts. Adding see manually
before *note does not change the output. The same is the case for
@xref{}. @xref{} adds See before the link in html/LaTeX, and
uses *Note in the info document; See [[link]] produces the same See in
html/LaTeX, and creates See *note in the info file (which is
inserted as See link in Emacs Info.
Yes the output is different if looking at the info file directly,
however when viewing it withing Emacs the text is consistent.
I didn't implement support for @xref{} or @pxref{} in the texinfo
exporter, because I could not find a way to reliably determine the
context so as to use the right type of link in the texi file.
Using occur there were already 47 cases in org.texi where [Ss]ee
@ref was used rather than the stylistically appropriate @pxref/@xref.
Regards,
Jon
My idea is to create a custom link type, something like this:
(org-add-link-type
pxref nil
(lambda (path desc format)
(cond
((eq format 'html)
(format span class=\pxref\%s/span path))
((eq format 'latex)
(format \\ref{%s} path))
((eq format 'texinfo)
(format @pxref{%s,%s} path desc)
I haven't tested this, but it should export approximately correctly and
I'm confident I can get the export part working.
What I can't figure out is how to have Org recognize that a link like
this:
[[pxref:Internal link]]
is really an internal link, rather than an external link. I'd like to
be able to click on this and end up at Internal link in the Org
buffer.
Is this possible? If so, can you point me to a solution?
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
--
Subhan Michael Tindall | Software Developer
| s...@rentrakmail.com
RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] pxref in texinfo export
Hello,
On 25 February 2013 13:40, Subhan Tindall subhan.tind...@rentrakmail.comwrote:
There are 4 different ref commands, all with slightly syntactic
requirements and outputs when compiled using makeinfo. I for one use
@pxref{} a lot, and it has different requirements for placement than
@ref or @xref (namely those two MUST have a . or , following the end
of the ref)
Not entirely true, @ref{} will add a period after the end of the reference
in the info output
if no period or comma present, @xref{} needs a comma or period. @pxref{}
can be
followed by a period, comma or right parenthesis, otherwise the info output
will include
a period as well.
So all three must have some sort of punctuation (or paren) following them
to ensure that
the references are clearly delimited.
Regards,
8.1 Different Cross Reference Commands
There are four different cross reference commands:
@xref Used to start a sentence in the printed manual saying ‘See . . .
’ or an Info
cross-reference saying ‘*Note name : node.’.
@ref Used within or, more often, at the end of a sentence; same as
@xref for Info;
produces just the reference in the printed manual without a preceding
‘See’.
@pxref Used within parentheses to make a reference that suits both an
Info file and a
printed book. Starts with a lower case ‘see’ within the
printed manual. (‘p’ is
for ‘parenthesis’.)
@inforef Used to make a reference to an Info file for which there is
no printed manual.
(from the Texinfo manual)
On Mon, Feb 25, 2013 at 10:32 AM, Jonathan Leech-Pepin
jonathan.leechpe...@gmail.com wrote:
Hello Tom,
On 25 February 2013 12:52, Thomas S. Dye t...@tsdye.com wrote:
Aloha all,
IIUC, there is currently no support for @pxref{} in the texinfo
exporter. This is a texinfo @-command that does one thing in the info
output and another in the LaTeX output.
Ultimately there is actually no real difference between see @ref{}
and @pxref{}. I just checked using the first @pxref{} in org.texi
(Under Activation).
In org.texi it is shown as (@pxref{Conflicts}), in org.html it
becomes: (see a href=#ConflictsConflicts/a) while in the info
file (org) it is shown as (*note Conflicts::).
Opening the info file in Info (C-u C-h i path to info file), *node
Conflicts:: becomes see Conflicts. Adding see manually
before *note does not change the output. The same is the case for
@xref{}. @xref{} adds See before the link in html/LaTeX, and
uses *Note in the info document; See [[link]] produces the same See in
html/LaTeX, and creates See *note in the info file (which is
inserted as See link in Emacs Info.
Yes the output is different if looking at the info file directly,
however when viewing it withing Emacs the text is consistent.
I didn't implement support for @xref{} or @pxref{} in the texinfo
exporter, because I could not find a way to reliably determine the
context so as to use the right type of link in the texi file.
Using occur there were already 47 cases in org.texi where [Ss]ee
@ref was used rather than the stylistically appropriate @pxref/@xref.
Regards,
Jon
My idea is to create a custom link type, something like this:
(org-add-link-type
pxref nil
(lambda (path desc format)
(cond
((eq format 'html)
(format span class=\pxref\%s/span path))
((eq format 'latex)
(format \\ref{%s} path))
((eq format 'texinfo)
(format @pxref{%s,%s} path desc)
I haven't tested this, but it should export approximately correctly and
I'm confident I can get the export part working.
What I can't figure out is how to have Org recognize that a link like
this:
[[pxref:Internal link]]
is really an internal link, rather than an external link. I'd like to
be able to click on this and end up at Internal link in the Org
buffer.
Is this possible? If so, can you point me to a solution?
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
--
Subhan Michael Tindall | Software Developer
| s...@rentrakmail.com
RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] M-S-(down-arrow) worked briefly this morning and now does not
Works. My mistake. Thanks for help. Susan
Re: [O] pxref in texinfo export
The point being that compiling .texinfo source into an Info file
treats references differently. For example:
(@pxref{my_node_name}). will compile just fine.
(@ref{my_node_name}). will not. There are also differences in case
(see v. See, note v. Note), and differences in output by ref type
depending on target output of file (info, DVI, HTML,...). For example,
@pxref generates different punctuation for typeset v. info files, @ref
does not generate a 'See ' in printed material while @xref does, etc.
Although the differences are subtle, they really are not equivalent
and should not be treated as such.
On Mon, Feb 25, 2013 at 10:48 AM, Jonathan Leech-Pepin
jonathan.leechpe...@gmail.com wrote:
Hello,
On 25 February 2013 13:40, Subhan Tindall subhan.tind...@rentrakmail.com
wrote:
There are 4 different ref commands, all with slightly syntactic
requirements and outputs when compiled using makeinfo. I for one use
@pxref{} a lot, and it has different requirements for placement than
@ref or @xref (namely those two MUST have a . or , following the end
of the ref)
Not entirely true, @ref{} will add a period after the end of the reference
in the info output
if no period or comma present, @xref{} needs a comma or period. @pxref{}
can be
followed by a period, comma or right parenthesis, otherwise the info output
will include
a period as well.
So all three must have some sort of punctuation (or paren) following them to
ensure that
the references are clearly delimited.
Regards,
8.1 Different Cross Reference Commands
There are four different cross reference commands:
@xref Used to start a sentence in the printed manual saying ‘See . . .
’ or an Info
cross-reference saying ‘*Note name : node.’.
@ref Used within or, more often, at the end of a sentence; same as
@xref for Info;
produces just the reference in the printed manual without a preceding
‘See’.
@pxref Used within parentheses to make a reference that suits both an
Info file and a
printed book. Starts with a lower case ‘see’ within the
printed manual. (‘p’ is
for ‘parenthesis’.)
@inforef Used to make a reference to an Info file for which there is
no printed manual.
(from the Texinfo manual)
On Mon, Feb 25, 2013 at 10:32 AM, Jonathan Leech-Pepin
jonathan.leechpe...@gmail.com wrote:
Hello Tom,
On 25 February 2013 12:52, Thomas S. Dye t...@tsdye.com wrote:
Aloha all,
IIUC, there is currently no support for @pxref{} in the texinfo
exporter. This is a texinfo @-command that does one thing in the info
output and another in the LaTeX output.
Ultimately there is actually no real difference between see @ref{}
and @pxref{}. I just checked using the first @pxref{} in org.texi
(Under Activation).
In org.texi it is shown as (@pxref{Conflicts}), in org.html it
becomes: (see a href=#ConflictsConflicts/a) while in the info
file (org) it is shown as (*note Conflicts::).
Opening the info file in Info (C-u C-h i path to info file), *node
Conflicts:: becomes see Conflicts. Adding see manually
before *note does not change the output. The same is the case for
@xref{}. @xref{} adds See before the link in html/LaTeX, and
uses *Note in the info document; See [[link]] produces the same See in
html/LaTeX, and creates See *note in the info file (which is
inserted as See link in Emacs Info.
Yes the output is different if looking at the info file directly,
however when viewing it withing Emacs the text is consistent.
I didn't implement support for @xref{} or @pxref{} in the texinfo
exporter, because I could not find a way to reliably determine the
context so as to use the right type of link in the texi file.
Using occur there were already 47 cases in org.texi where [Ss]ee
@ref was used rather than the stylistically appropriate @pxref/@xref.
Regards,
Jon
My idea is to create a custom link type, something like this:
(org-add-link-type
pxref nil
(lambda (path desc format)
(cond
((eq format 'html)
(format span class=\pxref\%s/span path))
((eq format 'latex)
(format \\ref{%s} path))
((eq format 'texinfo)
(format @pxref{%s,%s} path desc)
I haven't tested this, but it should export approximately correctly and
I'm confident I can get the export part working.
What I can't figure out is how to have Org recognize that a link like
this:
[[pxref:Internal link]]
is really an internal link, rather than an external link. I'd like to
be able to click on this and end up at Internal link in the Org
buffer.
Is this possible? If so, can you point me to a solution?
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
--
Subhan Michael Tindall | Software Developer
| s...@rentrakmail.com
RENTRAK |
Re: [O] org-sync and redmine
Hello Bastien, Bastien b...@altern.org writes: hob...@poukram.net (Rémi Letot) writes: So I get to ask if anyone that I'm not aware of is still currently working on org-sync, and if yes if they are interrested in fixing the redmine backend ? Daimrod is working on it and I think he is interested in the Redmine sync too. Yes, I would like to get the redmine backend practical, but I need time to understand org-sync and time to work on it, and I don't expect to find the time before mid-april. Daimrod, let me know if you want write access to org-sync.git repo on orgmode.org, you could then merge your changes directly. I'm still only playing with org-sync and I don't fully understand the changes I've merged, so I won't push before I'm more confident with my understanding of org-sync. Unless Aurélien is against it, because he wants to discuss before changes are made, you can give me the write access and I'll merge when I could. -- Daimrod/Greg pgp45PrLKeLyB.pgp Description: PGP signature
[O] Sending reminder Emails to other people with org-mode
Hi, A common workflow (of mine) is: Work on something, submit and wait several days or weeks for a review or reply before I can continue. So I switch to the next task. I'd love if org-mode could keep track of tasks that are waiting for others and semi-automatically remind those others in a weekly email that I'm waiting for them. I imagine a command that I could run over my tasks. The command finds such tasks, prepares a reminder mail that I can send directly from within emacs and remembers the date when I last naged the other. Any ideas? Thanks for your attention, Thomas Koch, http://www.koch.ro
Re: [O] Sending reminder Emails to other people with org-mode
Thomas Koch tho...@koch.ro wrote: Hi, A common workflow (of mine) is: Work on something, submit and wait several days or weeks for a review or reply before I can continue. So I switch to the next task. I'd love if org-mode could keep track of tasks that are waiting for others and semi-automatically remind those others in a weekly email that I'm waiting for them. I imagine a command that I could run over my tasks. The command finds such tasks, prepares a reminder mail that I can send directly from within emacs and remembers the date when I last naged the other. Any ideas? Thanks for your attention, It depends on how you set up your tasks, but I imagine something like the following will be fairly easy to set up: o When you submit, the task goes into a WAITING state and several properties are added: (who to nag, when the last nag went out). o You can then write a function that finds waiting tasks, and checks the relevant properties in order to construct the nagging email. The details will vary of course, but the mapping and property APIs should be able to deal with the org aspects. See (info (org) Using the mapping API) (info (org) Using the property API) The is-it-time-to-nag logic can be easily done in elisp. Sending email is also quite possible in elisp, but the details will depend on the mail package you decide to use. o The function can be run using a timer. See (info (elisp) Timers for Delayed Execution) There are lots of details elided in the above description of course, but this is probably a reasonable first approximation. Nick
Re: [O] HTML export: no date in postamble unless set manually
Richard Stanton stan...@haas.berkeley.edu wrote: I have org-export-html-postamble set to t. When I export a simple org file that has no explicit #+date line (using the new exporter), I get a line that says Date: at the bottom of the resulting HTML file, but there's no date listed next to it. If I add an explicit #+date line, it is correctly transferred to the bottom of the HTML file, but wouldn't it make sense to have today's date listed if no explicit alternative is provided? At any rate, adding a line that says Date: with nothing after the colon doesn't seem like the optimal default setting. The backend-specific variables have been renamed in the new exporter: try org-html-postamble. Check the FAQ: http://orgmode.org/worg/org-faq.html#new-exporter-switch for more details. Nick
[O] [RFC] Org version of the Org manual
Aloha all, An experiment to see if it is possible to convert the Org manual to Org is now (hopefully) at the proof of concept stage and I would like to determine whether or not the approach is viable. The experiment is here: https://github.com/tsdye/orgmanual.git The file orgmanual.org has a heading, * Instructions for use, that explains how to set up asynchronous export with the new exporter. The repo also contains orgmanual.info in case you don't want to hassle with exporting the org file and just want to see what it looks like in info. I'm able to generate an info file without makeinfo raising any errors or warnings. There is also a heading, * Improvements and fixes, that includes a list of problems that either need to be fixed or are in the process of being fixed. Obviously, the file is not perfect, but I do believe it is good enough to judge whether success will be possible. At any rate, I need to pull myself away from this project for a week or so to do other things and can't get caught up making editorial changes or working on the (to me) thorny issues that remain. Sections with problems have been given FIXME keywords. In some cases, problem text (especially in macros) has been replaced with `XXX'. Proposed fixes for these nagging issues will be greatly appreciated. By way of background, my initial goal was to replicate the Org manual precisely. This goal was abandoned when I realized that the various contributors to the manual (including me a few years ago) had different ideas about what a .texi file should look like and had created a somewhat eclectic product. The goal now is to have a functional equivalent of the manual. The ultimate goal is to maintain the Org manual in Org, rather than .texi, and to have the infrastructure in place in time to support the major revisions required by the forthcoming release of version 8.0. Many thanks to Nicolas Goaziou and to Jonathan Leech-Pepin for their excellent work on the new exporter framework and the texinfo exporter, and for their patience with my sometimes exasperated (and exasperating) queries. Jonathan showed me the way forward at an early stage and devised most of the macros. I look forward to picking this project up again in a week or so, or learning from my Org colleagues that the project ought to be scuttled. 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] [patch] ox-koma-letter
Hi,
I have been working on extending the KOMA letter support in Org. The
backend is still rough and I would like to more stuff such as
designing firstfood and firsthead with org elements (e.g. I use a
tabularx for my firstfood with varioues stuff).
I have changed the following objects:
1. Make keys sane; no reason why open pdf is O rather than o and why
k is used in place of l (as in the tex exporter).
2. Added AFTER_CLOSING and AFTER_LETTER keywords for arbitrary code
after \closing{.} and \end{letter}, respectively.
a. A weird bug I don't understand is why I cannot have
#+AFTER_CLOSING{\ps{ps:}}
b. Would it be better to have a dedicated, say, PS and ENCL rather
than the generic AFTER_CLOSING?
3. Added from-bank, invoice and other keywords like that. Still
many to go, but some of them would probably need some thought.
For instance firstfoot should work differently depending on
whether it is given a NAMEd table or a string. Any though?
I'm not a good programmer, so if someone could look through it, and
say whether it's OK it'd be happy to work more on in and submit it a
proper patch if deemed worthy.
Also, if someone has thoughts on how to improve the letter experience
that would be interesting to hear.
I'd love to hear an explanation of point a. above.
Further, perhaps we should remove all the silly defaults from the
defcustoms in ox-koma-letter?
–Rasmus
--
. . . Stallman was indeed the tallest possible mountain and by
standing on his shoulders you could see forever. . .diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el
index 07633e3..069d458 100644
--- a/contrib/lisp/ox-koma-letter.el
+++ b/contrib/lisp/ox-koma-letter.el
@@ -91,6 +91,23 @@
:group 'org-export-koma-letter
:type 'string)
+(defcustom org-koma-letter-from-bank
+ Sender's bank account, as a string.
+ :group 'org-export-koma-letter
+ :type 'string)
+
+(defcustom org-koma-letter-from-fax
+ Sender's fax number, as a string.
+ :group 'org-export-koma-letter
+ :type 'string)
+
+(defcustom org-koma-letter-from-url
+ Sender's url, as a string.
+ :group 'org-export-koma-letter
+ :type 'string)
+
+
+
(defcustom org-koma-letter-opening Dear Sir,
Letter's opening, as a string.
:group 'org-export-koma-letter
@@ -106,33 +123,42 @@
:group 'org-export-koma-letter
:type 'string)
-
+
;;; Define Back-End
(org-export-define-derived-backend koma-letter latex
:options-alist
- ((:closing CLOSING nil org-koma-letter-closing)
+ ((:after-closing AFTER_CLOSING nil newline)
+ (:after-letter AFTER_LETTER nil newline)
+ (:closing CLOSING nil org-koma-letter-closing)
(:from-address FROM_ADDRESS nil org-koma-letter-from-address newline)
+ (:from-bank FROM_BANK nil org-koma-letter-from-bank t)
+ (:from-fax FROM_FAX nil org-koma-letter-from-fax t)
+ (:from-url FROM_FAX nil org-koma-letter-from-url t)
+ (:invoice INVOICE nil t)
+ (:my-ref MY_REF nil t)
+ (:your-ref YOUR_REF nil t)
(:lco LCO nil org-koma-letter-class-option-file)
(:opening OPENING nil org-koma-letter-opening)
(:phone-number PHONE_NUMBER nil org-koma-letter-phone-number)
- (:signature SIGNATURE nil nil newline)
- (:to-address TO_ADDRESS nil nil newline))
+ (:signature SIGNATURE nil user-full-name newline)
+ (:to-address TO_ADDRESS nil nil newline)
+ )
:translate-alist ((export-block . org-koma-letter-export-block)
(export-snippet . org-koma-letter-export-snippet)
(keyword . org-koma-letter-keyword)
(template . org-koma-letter-template))
:menu-entry
(?k Export with KOMA Scrlttr2
- ((?K As LaTeX buffer org-koma-letter-export-as-latex)
- (?k As LaTeX file org-koma-letter-export-to-latex)
+ ((?L As LaTeX buffer org-koma-letter-export-as-latex)
+ (?l As LaTeX file org-koma-letter-export-to-latex)
(?p As PDF file org-koma-letter-export-to-pdf)
- (?O As PDF file and open
+ (?o As PDF file and open
(lambda (a s v b)
(if a (org-koma-letter-export-to-pdf t s v b)
(org-open-file (org-koma-letter-export-to-pdf nil s v b
-
+
;;; Transcode Functions
Export Block
@@ -204,7 +230,15 @@ holding export options.
(format \\setkomavar{signature}{%s}\n (plist-get info :signature))
(format \\setkomavar{fromemail}{%s}\n
(org-export-data (plist-get info :email) info))
+ (format \\setkomavar{frombank}{%s}\n
+ (org-export-data (plist-get info :from-bank) info))
(format \\setkomavar{fromphone}{%s}\n (plist-get info :phone-number))
+ (format \\setkomavar{frombank}{%s}\n (plist-get info :from-bank))
+ (format \\setkomavar{fromfax}{%s}\n (plist-get info :from-fax))
+ (format \\setkomavar{fromurl}{%s}\n (plist-get info :from-url))
+ (format \\setkomavar{myref}{%s}\n (plist-get info :my-ref))
+ (format \\setkomavar{yourref}{%s}\n
Re: [O] pxref in texinfo export
(Here are the attached files, forgot to add them)
On 25 February 2013 15:24, Jonathan Leech-Pepin
jonathan.leechpe...@gmail.com wrote:
Hello,
On 25 February 2013 14:01, Subhan Tindall
subhan.tind...@rentrakmail.comwrote:
The point being that compiling .texinfo source into an Info file
treats references differently. For example:
(@pxref{my_node_name}). will compile just fine.
(@ref{my_node_name}). will not.
Both work perfectly fine for me.
makeinfo (GNU texinfo) 5.0
There are also differences in case
(see v. See, note v. Note), and differences in output by ref type
depending on target output of file (info, DVI, HTML,...). For example,
@pxref generates different punctuation for typeset v. info files, @ref
does not generate a 'See ' in printed material while @xref does, etc.
Although the differences are subtle, they really are not equivalent
and should not be treated as such.
With a slight amount of work on the user's part, they can be made
functionally equivalent on export.
Using the two attached minimal .texi files (good-ref.texi is using
@xref/@pxref as is preferred while ref.texi is using @ref with
appropriate See/see added in the text) and disregarding filename
differences (since they are noted in the info output) I get the
following differences:
makeinfo --html --no-split good-ref.texi ref.texi
0 Diffs
makeinfo --docbook --no-split good-ref.texi ref.texi
Filename ID appears in diff
makeinfo --xml --no-split good-ref.texi ref.texi
Filename difference.
Links are different since TexinfoML does still distinguish xref/pxref
and ref in how they create the links.
makeinfo --no-split good-ref.texi ref.texi
The info file does show the expected differences between the two
documents, notably that the @xref{} becomes *Note while the
equivalent See @ref{} becomes See *note with @pxref{}-*note vs
see @ref{} - see *note.
However once they are viewed within the *info* buffer (C-u C-h i
good-ref.info/ref-only.info) the lines in question are visually
identical since *Note becomes See and *note becomes see if there
is not already see present.
I will not disagree that @ref, @pxref and @xref are subtly different,
however with slight user intervention @ref can be used in the same
above locations by simply replacing:
@xref{} - See @ref{}
@pxref{} - see @ref{}
I had to compare these possible outcomes when working on the texinfo
exporter. Since links are parsed before being included in their
paragraphs, I did not have a way to obtain context and therefore
attempt to guess (and be successful) at which type of reference was
intended by a link in Org. Restricting it to @ref{} in all cases,
even if it added a slight burden to the user (4 additional characters
to type in Org) if they wanted to emulate @xref or @pxref was in my
opinion the best choice.
Regards,
--
Jon
[...]
good-ref.texi
Description: TeXInfo document
ref.texi
Description: TeXInfo document
Re: [O] Bug: New HTML exporter incorrect attributes
Hello Nicolas, Thanks for your prompt reply, though I think our discussion is a little off-track here, as noted below. Nicolas Goaziou n.goaz...@gmail.com writes: tftor...@tftorrey.com (T.F. Torrey) writes: It would be ATTR_HTML: :class XXX. I try to unify syntax for attributes with syntax for Babel and AFAICT, `html' is the last back-end to have key=value syntax. This was your response to my comment that it would be handy to apply attributes to paragraphs, not the links or images within them. I see that this does not presently work, and the author listed on ox-html.el is not currently active on this list. I hope you are not the only one working on this. It would be our great misfortune for you to become burned out. It's not much work once we agree about the real syntax. For example, for links, there are two ways to replace: I think you are now talking about a syntax for adding attributes to links and images within paragraphs. In the e-mail to which you are replying, I thought were agreeing that modifying the inline link and image syntax was the best solution to these, and had thoughts on what that might look like in another thread. What you describe here still has the limitation that either all links and images in a paragraph must have the same attributes, or some must be invalid, or only the first is reachable. Apart from that, I have other more general concerns with this approach noted below. #+ATTR_HTML: width=400px The easiest one, is simply to ask for `:options' before: #+ATTR_HTML: :options width=\400px\ This is heavier but will be consistent with other back-ends. Yes, this is heavy. Escaping the quotes is unwieldy, and raises doubts about what else might need to be escaped. Also, given that the whole and only point of the ATTR_HTML keyword is for describing options, adding :options is redundant. From a design standpoint, it might be elegant that it matches other things, but here it seems very awkward, and I don't understand who it would benefit. This seems another step away from plain text toward another programming language. The first syntax looks like plain text. The second looks like programming. For babel, and actual programming languages, I'm sure this makes good sense. For applying a width to an image, it's overkill. For instance, compare this plain text: #+ATTR_HTML: :options width=\400px\ title=\My image\ [[file:image.jpg]] to the HTML alternative: img width=400px title=My image src=image.jpg/ Shouldn't the plain text be more straightforward to enter and easier to understand that what it is replacing? Here is the same thing in AsciiDoc: image:image.jpg[My image,width=400] Granted, I've already noted that I think we are moving toward inline attribute specifications, so this syntax for images and links is probably moot anyway, but I think the larger point still stands. I hate to say that I have other concerns as well, but I do, below. Otherwise, there is also: #+ATTR_HTML: :width 400px But this requires to have a list of all properties supported. If we take that route, here is a suggested list of such properties for a tag: - rel - target - type - accesskey - class - style - title and for img - alt - height - width What do you think about it? I think it is rather heavy-handed. I don't understand why this requires a list of properties supported. The old exporter would simply plug whatever you told it into the tag, trusting that you knew what you were doing. I'm sure this simplified the code, and it gave great power to the user. Why should the user need permission from the developers to apply any arbitrary attributes to their elements? Imposing these restrictions on users seems to make more work for the users, and more work for the developers, to the benefit of no one. Also, I don't know why attributes should be defined for each backend rather than once for everywhere. The attributes would be designated for an object, and each backend would decide which to use or ignore. For instance, though I know the LaTeX syntax not correct, this seems like massive overkill for making a link red: #+ATTR_LATEX: :options text-color: red #+ATTR_HTML: :options class=\red\ Here is a [[file:doc.html]][red link]]. FWIW, the same thing in AsciiDoc would be this: Here is a [red]#link:doc.html#[red link]. And it would work correctly for every backend, current or future. In AsciiDoc, the attributes belong to the item, and every backend is free to use or ignore them. Plain text sure looks appealing. Again, this is applying the old ATTR_ syntax instead of the suggested inline attribute designations, but if the new link syntax matches the spirit of the existing structure, something like this is in the works: Here is a [[file:doc.html][red link][@@html: class=\red\@@ @@latex: text-color: red@@]]. IMHO, the AsciiDoc approach is much better. The HTML exporter should produce valid HTML regardless of the input.
Re: [O] HTML export: no date in postamble unless set manually
Nick Dokos nicholas.do...@hp.com wrote: Richard Stanton stan...@haas.berkeley.edu wrote: I have org-export-html-postamble set to t. When I export a simple org file that has no explicit #+date line (using the new exporter), I get a line that says Date: at the bottom of the resulting HTML file, but there's no date listed next to it. If I add an explicit #+date line, it is correctly transferred to the bottom of the HTML file, but wouldn't it make sense to have today's date listed if no explicit alternative is provided? At any rate, adding a line that says Date: with nothing after the colon doesn't seem like the optimal default setting. The backend-specific variables have been renamed in the new exporter: try org-html-postamble. Check the FAQ: http://orgmode.org/worg/org-faq.html#new-exporter-switch for more details. OK, now that I've tried it a bit, I can see that the variable name is not the reason: I can reproduce the empty date after setting org-html-postamble to t. The code looks like this (ox-html.el:org-html--build-postamble): , | (let ((date (if (not (plist-get info :with-date)) |(org-export-data (plist-get info :date) info))) ` :with-date (i.e. org-export-with-date) is set to t but there is no default for an absent :date. This is probably another case of too many cooks (or variables in this case: org-export-with-date, org-html-postamble-format, and the :date entry in the plist have to cooperate in order to produce the desired result), so the behavior is difficult to explain and it's not clear that all the different combinations make sense - e.g. if org-export-with-date is nil, but the format includes a %d, we probably should not have an empty date field, whereas if org-export-with-date is t but there is no date supplied, it should probably default to today. Apologies for rushing to judgment. Nick
Re: [O] latex exporter: different itemize environment
Hi Nicolas,
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
Andreas Leha andreas.l...@med.uni-goettingen.de writes:
Hi all (and Nicolas),
from =org-e-latex.el= (I have to upgrade - I know):
,
| ;; Plain lists accept two optional attributes: `:environment' and
| ;; `:options'. The first one allows to use a non-standard environment
| ;; (i.e. inparaenum). The second one allows to specify optional
| ;; arguments for that environment (square brackets are not mandatory).
`
I can not make the :enviroment switch work.
Following is a small presentation with a non-indented version of
itemize. But when I export it, I still get an \begin{itemize} when
instead I'd like \begin{nonindentlist}.
What am I missing?
[...]
#+ATTR_LATEX: :environment nonindentlist
- some
- bullet
- points
It should be #+attr_beamer: :environment nonindentlist since this
property is defined in Beamer back-end's documentation.
Thanks for this. #+attr_beamer: works fine (although I am not sure, I
understand what you said here...)
Since arguments are the same and beamer back-end is derived from latex
anyway, lists should now accept both, though.
Regards,
Andreas
Re: [O] [PATCH] datetree: Recognize year headline with tags as a match
Jeffrey Brent McBeth mcb...@broggs.org writes: On Mon, Feb 25, 2013 at 10:48:16AM +0100, Bastien wrote: Hi Tim, Tim Burt tcb...@rochester.rr.com writes: * lisp/org-datetree.el (org-datetree-find-year-create): Include regexp for tags. Syntax was taken directly from org-todo-line-tags-regexp in org.el. Applied, thanks a lot for the patch and the detailed change log! Best, I can confirm that latest git fixes my use case. Thank you both so much. Excellent all the way 'round. Jeff -- Tim Burt www.rketburt.org It is healthful to every sane man to utter the art within him; -- GK Chesterton
Re: [O] [RFC] Org version of the Org manual
Hi Tom, wow, a daring project. This would indeed be a testimony to the quality of the exporter if this works and gives proper output! I am curious and looking forward to seeing the results. - Carsten On 25.2.2013, at 21:21, Thomas S. Dye t...@tsdye.com wrote: Aloha all, An experiment to see if it is possible to convert the Org manual to Org is now (hopefully) at the proof of concept stage and I would like to determine whether or not the approach is viable. The experiment is here: https://github.com/tsdye/orgmanual.git The file orgmanual.org has a heading, * Instructions for use, that explains how to set up asynchronous export with the new exporter. The repo also contains orgmanual.info in case you don't want to hassle with exporting the org file and just want to see what it looks like in info. I'm able to generate an info file without makeinfo raising any errors or warnings. There is also a heading, * Improvements and fixes, that includes a list of problems that either need to be fixed or are in the process of being fixed. Obviously, the file is not perfect, but I do believe it is good enough to judge whether success will be possible. At any rate, I need to pull myself away from this project for a week or so to do other things and can't get caught up making editorial changes or working on the (to me) thorny issues that remain. Sections with problems have been given FIXME keywords. In some cases, problem text (especially in macros) has been replaced with `XXX'. Proposed fixes for these nagging issues will be greatly appreciated. By way of background, my initial goal was to replicate the Org manual precisely. This goal was abandoned when I realized that the various contributors to the manual (including me a few years ago) had different ideas about what a .texi file should look like and had created a somewhat eclectic product. The goal now is to have a functional equivalent of the manual. The ultimate goal is to maintain the Org manual in Org, rather than .texi, and to have the infrastructure in place in time to support the major revisions required by the forthcoming release of version 8.0. Many thanks to Nicolas Goaziou and to Jonathan Leech-Pepin for their excellent work on the new exporter framework and the texinfo exporter, and for their patience with my sometimes exasperated (and exasperating) queries. Jonathan showed me the way forward at an early stage and devised most of the macros. I look forward to picking this project up again in a week or so, or learning from my Org colleagues that the project ought to be scuttled. 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] pxref in texinfo export
I noticed you left out @inforef, was that by design? It actually does
behave quite differently than other members of the @*ref family, and
the more arguments it gets the more different it looks IE Here's an
example with a full 5 arguments:
REF *note Arg2: (Arg4)Lore Ipsum.
INFOREF *note Arg2: (Arg3)Lore Ipsum Arg4, Arg5
On Mon, Feb 25, 2013 at 12:29 PM, Jonathan Leech-Pepin
jonathan.leechpe...@gmail.com wrote:
(Here are the attached files, forgot to add them)
On 25 February 2013 15:24, Jonathan Leech-Pepin
jonathan.leechpe...@gmail.com wrote:
Hello,
On 25 February 2013 14:01, Subhan Tindall subhan.tind...@rentrakmail.com
wrote:
The point being that compiling .texinfo source into an Info file
treats references differently. For example:
(@pxref{my_node_name}). will compile just fine.
(@ref{my_node_name}). will not.
Both work perfectly fine for me.
makeinfo (GNU texinfo) 5.0
There are also differences in case
(see v. See, note v. Note), and differences in output by ref type
depending on target output of file (info, DVI, HTML,...). For example,
@pxref generates different punctuation for typeset v. info files, @ref
does not generate a 'See ' in printed material while @xref does, etc.
Although the differences are subtle, they really are not equivalent
and should not be treated as such.
With a slight amount of work on the user's part, they can be made
functionally equivalent on export.
Using the two attached minimal .texi files (good-ref.texi is using
@xref/@pxref as is preferred while ref.texi is using @ref with
appropriate See/see added in the text) and disregarding filename
differences (since they are noted in the info output) I get the
following differences:
makeinfo --html --no-split good-ref.texi ref.texi
0 Diffs
makeinfo --docbook --no-split good-ref.texi ref.texi
Filename ID appears in diff
makeinfo --xml --no-split good-ref.texi ref.texi
Filename difference.
Links are different since TexinfoML does still distinguish xref/pxref
and ref in how they create the links.
makeinfo --no-split good-ref.texi ref.texi
The info file does show the expected differences between the two
documents, notably that the @xref{} becomes *Note while the
equivalent See @ref{} becomes See *note with @pxref{}-*note vs
see @ref{} - see *note.
However once they are viewed within the *info* buffer (C-u C-h i
good-ref.info/ref-only.info) the lines in question are visually
identical since *Note becomes See and *note becomes see if there
is not already see present.
I will not disagree that @ref, @pxref and @xref are subtly different,
however with slight user intervention @ref can be used in the same
above locations by simply replacing:
@xref{} - See @ref{}
@pxref{} - see @ref{}
I had to compare these possible outcomes when working on the texinfo
exporter. Since links are parsed before being included in their
paragraphs, I did not have a way to obtain context and therefore
attempt to guess (and be successful) at which type of reference was
intended by a link in Org. Restricting it to @ref{} in all cases,
even if it added a slight burden to the user (4 additional characters
to type in Org) if they wanted to emulate @xref or @pxref was in my
opinion the best choice.
Regards,
--
Jon
[...]
--
Subhan Michael Tindall | Software Developer
| s...@rentrakmail.com
RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] pxref in texinfo export
Hello, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes: I had to compare these possible outcomes when working on the texinfo exporter. Since links are parsed before being included in their paragraphs, I did not have a way to obtain context and therefore attempt to guess (and be successful) at which type of reference was intended by a link in Org. What kind of context would you need to know? The string that will be exported just before the current ref link? Regards, -- Nicolas Goaziou
Re: [O] pxref in texinfo export
I don't think there is a specific context that can clearly separate them. The differences are largely semantic, not syntactic. What is needed is some sort of marker on the tag in the original file telling it what kind of link is to be used. On Mon, Feb 25, 2013 at 1:38 PM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes: I had to compare these possible outcomes when working on the texinfo exporter. Since links are parsed before being included in their paragraphs, I did not have a way to obtain context and therefore attempt to guess (and be successful) at which type of reference was intended by a link in Org. What kind of context would you need to know? The string that will be exported just before the current ref link? Regards, -- Nicolas Goaziou -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
[O] [Feature] Highlighting of timestamps
Hello, With recent versions of Org mode, the Highlighting of timestamps is not happening between the right positions anymore: it begins one character before the beginning of the timestamp, as you can see on http://screencast.com/t/llxtNT3m. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] bug in expansion of variables in babel Perl
Achim D M German dmg at uvic.ca writes:
I think the issue is that, at least in my computer the variable $\
returns empty (the record separator).
Achim Thinko on my side, what I wanted was the input record separator $/
Achim (to avoid
Achim specifying a literal newline for those systems where this is actually
Achim multi-character).
Hi Achim,
Once I changed it:
(defvar org-babel-perl-wrapper-method
{
my @r = eval( q(
%s
));
open my $BO, qq(%s) or die qq( Perl: Could not open output file.$\\ );
print $BO join($/, @r), $/ ;
})
the result now has \n in between fields (literally):
#+name: t_output_table
#+begin_src perl :results table
print Test\n;
(1, 2)
#+end_src
#+RESULTS: t_output_table
| 1\n2\n |
what is the expected field separator for Org-babel?
Achim Regards,
Achim Achim.
--
Daniel M. German Prose is intrinsically linear;
a good book carries the reader forward
The Economist -on the crest of the words
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
