Re: Changed list indentation behavior: how to revert?
Hello all, I apologize in advance that this is so long. I've been following this thread closely, because I've been using Org mode daily for well over a decade, and this behavior affects me in several important ways. I think this summary might be helpful. Forever, it has been possible to start a heading in Org by typing a return one or more times, then typing an asterisk and a space and the heading text. To add a series of headings, just keep hitting return at the end of the current one, type an asterisk and a space and the next one, then repeat. If you want subheadings, it is as simple as typing more asterisks. Easy. This worked because electric-indent-mode defaulted to off, and although org-adapt-indentation defaulted to t, it didn't affect this situation. The default behavior here matters because Org is a killer feature of Emacs, enticing many people to give it a try, including my nine-year-old daughter. For them, it should behave by default the way it looks like it should. That means, typing asterisks and text for headings, followed by returns, and text, and more asterisks, should just work by default. #+NAME: Old Defaults: electric-indent-mode OFF and org-adapt-indent t #+begin_example org ,* Testing out Org, type here once or twice I get it! I'll type once or twice again and start a subheading. ,** Headings are easy! Now another or two for subhead content This is awesome! It works just as I expect, and I don't have to memorize a bunch of key chords just to get started. And folding is awesome! I love Org! I will stick with it and learn it all! #+end_example I have probably typed close to a million headings like this all by myself, and collectively we have probably typed billions or more. The last release, as everyone knows, turned on electric-indent-mode by default. So, right now, typing an Org document with default settings does not work like it looks like it should. This is the new experience for people used to the old defaults, and beginners like my daughter: #+NAME: New Defaults: electric-indent-mode ON and org-adapt-indent t #+begin_example org ,* I typed an asterisk for this heading, how about here once or twice Okay. This is indented. Since I'm new, I don't realize it isn't useful yet, or that it makes a difference at all. How about a subheading? I'll hit a couple times, they type two asterisks. ,** Is this a subheading? It looks like one. again here ... Okay, the indentation isn't the same, but maybe it's okay? I probably didn't even notice. ,*** I think I'm organizing my document with *'s and 's I'm going to try folding my stuff, becaue I saw that and it looks awesome. Wait! The instructions say will cycle the folding, but it only works on the top level. What? Okay, some searching said I have to modify init, or something, or type some weird key combinations. What? This looked like it was going to be easy. Nerds are liars. I can't figure this out, and I don't have time to mess with this. I'm going back to Word. Maybe I'll try Markdown tomorrow. #+end_example For new users, step one is either to start changing default settings, start learning key chords and/or arcane (to beginners) commands---or go back to Word or Markdown. Turning on electric-indent-mode, all by itself, shouldn't break the useful or customary indentation that the users of Org expect, but it has. Instead of starting a new heading by typing one or more times, then typing an asterisk and a space and a new heading, a user has to either hit some control characters with returns, or backspace to column zero, or something else. The manual shows heading and body formatting as this: #+NAME: Org Manual Sample: electric-indent-mode on, org-adapt-indent t #+begin_example org ,* Top level headline ,** Second level ,*** Third level some text ,*** Third level more text ,* Another top level headline #+end_example I don't recall ever seeing an Org document in real life with the body indented at the level of each heading, and I haven't seen anyone argue for that behavior on this thread. I've tried it, and the text body width rapidly becomes too narrow to be useful. As several people have noted, even the Org repositories turn this off, which suggests even the developers don't find it useful. Why this is set as the default, I have no idea, but it didn't really matter until now. An Org document looks like you can create it by typing asterisks, text, and returns, but you can't, not by default, anyway. That's the root of the problem: the longstanding default *behavior* has been changed. The only people unaffected are people who already had compensatory settings in their init files. As far as I can tell, turning on electric-indent-mode by default was done for no reason other than other Emacs modes have it as a default. The proper fix for this is one of two choices: 1. If keeping electric-indent-mode on is really important, the easiest way to
[O] Error when applying table formula
Hello, I'm getting a weird error. When I "make vanilla" from the current git repo, I don't get the error, so I'm sure it's something I've done, but I'm not sure what, and my customizations make tracking down the problem complicated. I know I can find out the source, but I'm hoping that someone has an idea that can save me some time. Then I type C-c C-c on a `#+TBLFM:` line, I get an error. This weird message appears in the *Warnings* buffer: Warning (emacs): There is no logger of name 268435455. I also get this in the *Backtrace* buffer: Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p t) byte-code("\301\302\303\245\304\"\303\245!\207" [most-positive-fixnum truncate log 2 10] 4) (defconst math-bignum-digit-length (byte-code "\301\302\303\245\304\"\303\245!\207" [most-positive-fixnum truncate log 2 10] 4) ("/usr/share/emacs/24.5/lisp/calc/calc.elc" . 79936)) calc-eval(("(8)-1" calc-internal-prec 12 calc-float-format (float 8) calc-angle-mode deg calc-prefer-frac nil calc-symbolic-mode nil calc-date-format ( "-" MM "-" DD " " Www (" " hh ":" mm)) calc-display-working-message t) nil) org-table-eval-formula(nil "$1-1" noalign nocst nostore noanalysis) org-table-recalculate(t) call-interactively(org-table-recalculate) org-table-calc-current-TBLFM() org-ctrl-c-ctrl-c(nil) call-interactively(org-ctrl-c-ctrl-c nil nil) command-execute(org-ctrl-c-ctrl-c) Also, the error appears in all my files, but when I tried to run org-lint to look for possible problems in a file that might have them, it simply stops with this message: Search failed: "^[ ]*#\\+[A-Za-z]+: +setup *$" Does anyone have any idea what a likely culprit might be? Emacs : GNU Emacs 24.5.1 (i586-pc-linux-gnu, GTK+ Version 3.18.2) of 2015-10-24 on x86-grnet-01, modified by Debian Package: Org-mode version 8.3.3 (release_8.3.3-501-g15d591.dirty @ /home/tftorrey/T/hacks/org-mode/lisp/) Thanks in advance, Terry
[O] Bug: Column view next allowed value throws error
Hello all, With the most recent Org from git, attempting to change to the next or previous allowed value in Column View throws an error: Symbol's value as variable is void: pom An ECM for the error: Type =make vanilla= at the command prompt. Change the scratch buffer to org-mode. Erase the buffer and paste this instead (not including the #+...EXAMPLE lines, of course: #+BEGIN_EXAMPLE ,* Top node for columns view :PROPERTIES: :COLUMNS: %25ITEM %TAGS %PRIORITY %TODO :END: ,** TODO This ,** TODO That #+END_EXAMPLE Move the cursor to the second heading. Press C-c C-x C-c to go to column view. Move to the P column. Press n to change the value to the next allowable value. This error appears: #+BEGIN_QUOTE Symbol's value as variable is void: pom #+END_QUOTE Performing the same steps but starting with emacs -Q in Debian Testing produces the expected results, no error. Emacs : GNU Emacs 24.5.1 (i586-pc-linux-gnu, GTK+ Version 3.18.2) of 2015-10-24 on x86-grnet-01, modified by Debian Package: Org-mode version 8.3.3 (release_8.3.3-470-g3142d1.dirty @ /home/tftorrey/T/hacks/org-mode/lisp/) Thanks in advance, Terry
Re: [O] Bug: org-map-entries seems broken
Hello, Thank you so much for looking into this. Kyle Meyerwrites: >> Hello, >> >> I have a function that uses org-map-entries to build a list of entries. [... 6 lines omitted ...] > > Things seem to be working on my end. Both release_8.3.3 and the > current master (23f31a9) are giving me the same results: [... 36 lines omitted ...] The problem, which took me several hours to figure out, was merely a massive misfire between my keyboard and chair. I apologize for the noise. Best, Terry
[O] Bug: org-map-entries seems broken
Hello, I have a function that uses org-map-entries to build a list of entries. It worked until recently. Now, it fails with simple combinations. For instance, 'LEVEL=1' matches what it should, and 'weblog' matches what it should, but 'LEVEL=1+weblog' does not match the intersecting set, or anything at all. Did I miss a change in the syntax, or maybe did a recent refactoring introduce an error? Does anyone else use this kind of matching and have it work? Emacs : GNU Emacs 24.5.1 (i586-pc-linux-gnu, GTK+ Version 3.18.2) of 2015-10-24 on x86-grnet-01, modified by Debian Package: Org-mode version 8.3.3 (release_8.3.3-435-gb78a9b @ /home/tftorrey/T/hacks/org-mode/lisp/) Thanks in advance, Terry -- T.F. Torrey
[O] Bug: Smart left single quote broken
Hello all, The smart quote code has gotten a little borked, at least in HTML. This: #+BEGIN_EXAMPLE He said, "You should believe me, 'cause it's 'true'." #+END_EXAMPLE Exports to this: #+BEGIN_EXAMPLE He said, You should believe me, cause its true. #+END_EXAMPLE The quote before "true" should be a left single quote, and it used to be, like this: #+BEGIN_EXAMPLE He said, You should believe me, cause its true. #+END_EXAMPLE I looked at the code, but it has become more convoluted than I can figure out in the time allotted. Hopefully the error is obvious to someone more familiar with it. Emacs : GNU Emacs 24.5.1 (i586-pc-linux-gnu, GTK+ Version 3.16.4) of 2015-06-28 on x86-csail-01, modified by Debian Package: Org-mode version 8.3.1 (release_8.3.1-190-g258966 @ /home/tftorrey/T/org-mode/lisp/) Best, Terry -- T.F. Torrey
Re: [O] Bug: Smart left single quote broken
> I doubt it is possible to tell that 'cause begins with an apostrophe and > not an opening single quote without grammatical analysis. Indeed. I pointed it out because it was unexpectedly doing the right thing. Thank you. T.
Re: [O] Bug: HTML export ignoring CUSTOM_ID properties
Hello Nicolas, Nicolas Goaziou m...@nicolasgoaziou.fr writes: [... 77 lines omitted ...] I hope this clarifies the purpose of the change. It does. Thank you very much for taking the time. [... 41 lines omitted ...] Are you still planning on throwing warnings or errors in the event of duplicate or invalid CUSTOM_ID's? I have implemented something related recently, but I'll comment about this in another thread. I look forward to reading it. Best, Terry -- T.F. Torrey
Re: [O] Bug: HTML export ignoring CUSTOM_ID properties
Hello Rasmus, Rasmus ras...@gmx.us writes: With the latest from Git master, the HTML export ignores CUSTOM_ID properties for subtrees. I've seen list traffic that the names of the export ID's are being changed, but this is not intentional, right? It doesn't ignore it, but it is translate to a generic anchor as needed. Isn't translating it to a generic anchor the same as ignoring it? Without a CUSTOM_ID you get a generic anchor. With a CUSTOM_ID you get a generic anchor. You click it and it still works. It's not ignored. Within the syntax it does the right thing. Because I know (knew) the id of the section about Clinton, I could link to my page from another document outside Org with a link to presidents.html#clinton. Presumably you could use presidents.org::#clinton still. Links may work from inside Org, but the original intent of CUSTOM_ID was to produce a stable ID for the HTML export that could be linked to from outside Org. With the changed functionality, all existing links to presidents.html#clinton are broken, because the usage of CUSTOM_ID has changed. Any custom CSS is also broken, for the same reason. With the new usage, CUSTOM_ID and ID have virtually the same functionality. Notice how my CUSTOM_ID's are no longer ID's at all. And simply adding text- to my CUSTOM_ID's is not an answer. For one thing, CUSTOM_ID exports should not change on the breeze of developer whims. For another, the ID should be attached to the heading, not the body of the text; otherwise, a person following the link would have no idea if it went to the Clinton section or not. Note that this also breaks any CSS styling for the section with the CUSTOM_ID (which I also use). If I used a CUSTOM_ID because wanted a swanky background for the heading saying Bill Clinton, the current export not only doesn't use that ID, it doesn't encompass the heading with his name in. I have a half-baked patch that restores the old behavior, but I have to think a bit more about it, and I won't have time today. Nicolas might also see it in the coming days. E.g. ox-latex has org-latex--label. The question is whether there should be a solution in ox or whether each backend should have org-BACKEND--label. As the current state is unusable, there would be no additional harm in applying your half-baked patch. Thus, I think it is a bug, unless there is a better way to allow per-section css. I will look at this later unless somebody beets me to it. Given the lack of outcry, I may be the only one using CUSTOM_ID's for HTML export. However, if usage is widespread enough and accidental duplicates are a problem enough that this needs to be addressed, wouldn't it be better for the exporter to simply report duplicate ID's as they are found? It was changed this week. Either no one is using it according to its original intended functionality, no one has republished their HTML documents with the latest from git, or people have simply not noticed that their links are broken. Finally, given that this doesn't appear to work at all in any form of its intended usage, how did this even get committed to master? Sure, code in master may have bugs, but this is more than a bug; this is unusable code that breaks code that worked. Shouldn't it be developed on a feature branch or in someone's private repo until it actually works? Master is where we develop things. The code on master is *supposed* to work as advertised. It identifies itself as 8.3 beta. Changes that break functionality in exploratory ways are alpha changes. Nicolas made the change and he's off this week. Feel free to use Org 8.2. Ha ha. There are many tools capable of exporting plain-text documents to HTML with predictable and stable ID's. If Org 8.3 is not going to be one of them, using Org 8.2 is not a solution. Unless there is a quick fix that restores external (non-Org-generated) links to sections with CUSTOM_ID's, please revert these changes until the development reaches a usable state. Won't happen. As you said, they aren't your changes and it isn't your decision. Best, Terry -- T.F. Torrey
Re: [O] Bug: HTML export ignoring CUSTOM_ID properties
Hello Aaron, Aaron Ecay aarone...@gmail.com writes: You wrote: Links may work from inside Org, but the original intent of CUSTOM_ID was to produce a stable ID for the HTML export that could be linked to from outside Org. I think this is true. Looking at the pages in Worg, for example, provides ample evidence of this strategy in action. If this functionality were not provided by CUSTOM_ID, we would need to invent a different property to serve the function. CUSTOM_ID is also sometimes needed for latex export (cf. org-latex-prefer-user-labels). It is important for IDs to be unique, and to conform to certain format restrictions. What if CUSTOM_ID properties were checked for these requirements when exporting, raising an error if they are not suitable and otherwise passing through to the export output? This would maintain CUSTOM_ID as an interface to labeling systems outside org (latex \ref{}, html #anchor links, ...), but would also make export more robust. It’s also in line with recent changes to raise export errors for undefined macros, unresolvable links, etc. This is what I suggested in an earlier e-mail (which was unreasonably cordial, yet summarily dismissed in a way that made me angry, and which was sent in response to the summary dismissal of my polite bug report). Does it warrant an error, though? I've been using the functionality extensively for years, and I can remember only one time that I had an inadvertent problem caused by a duplicate CUSTOM_ID. A simple warning would have headed that off. On the contrary, if the show is going to stop with an error, I will have to make sure my documents meet someone else's idea of what is useful. For instance, many of my documents get exported together (web pages with #news sections, for instance), and it would be unnecessarily inconvenient making the CUSTOM_ID unique across all agenda files. Someone else, however, might want that. I'm wondering why this is being addressed at all. Is this actually a problem for someone? Or is this just another attempt to save hypothetical users' feet? Or is it just a side-effect of other refactoring? Best, Terry -- T.F. Torrey
Re: [O] Bug: HTML export ignoring CUSTOM_ID properties
Hello Nicolas, First, thank you for your incredible work on Org. I hope you enjoyed your days off, but I have to admit that your announcement that you were taking the week off worried me. I seem to remember we lost Carsten and Bastien soon after they took a week off. When (if?) you finally get burned out and leave, all Org users will feel the loss. Nicolas Goaziou m...@nicolasgoaziou.fr writes: beta is indeed misleading. I suggest to ignore it. As Rasmus pointed out, master is where development happens. Some changes introduced here may break Org. If one such change makes Org unusable for you, you can easily revert Org to an earlier, working, commit, without fuss. Of course, we appreciate if you report the problem encountered beforehand. Yes, changes on master can and do occasionally break Org, but they are *supposed* to work. You wouldn't leave the spreadsheet functionality in an unusable state and just tell people to use 8.2. But yes, it should be a simple matter to revert the commit that caused the problem for me until the problem can be addressed. That was the second thing I looked at. However, the place where this change happened is not obvious in the git logs. I still don't know where it came from. I did see that most (maybe all) of your changes are accompanied by tests. I'm not very familiar with the testing. Are the tests restricted to merely checking if the code explodes? Or is there a possibility to test whether the code does what it is supposed to do? Presumably this change that broke functionality passed its tests just fine. Ha ha. There are many tools capable of exporting plain-text documents to HTML with predictable and stable ID's. Considering that not any string is eligible as HTML id (e.g., forbidden characters), either these tools are putting restrictions on chosen IDs or they are lying. They aren't lying because they don't claim to allow only valid ID's. They produce valid ID's on their own, but when a user calls for a specific ID (the {#clinton} construct in Markdown comes to mind), they just do what the user tells them to do. Which is a good thing. I sense there is a difference of philosophy at play here. In my view, the purpose of tools such as Org that convert documents to HTML is to do what the user tells them to do, even if that means creating invalid HTML. On many occasions in the past, and probably some in the present and the future, I have used conversion tools to produce technically invalid HTML as in intermediate format to be further processed by XSLT to a final product. A tool that refused to produce invalid HTML would be no help at all. In fact, I'm not aware of any tool that disallows that except maybe for some beginner level things. On the contrary, the slant of Org's development lately seems to be first to make sure users don't make any mistakes, and then to follow their instructions. As you said, they aren't your changes and it isn't your decision. I overlooked the problem in HTML and made a mistake. It happens, more often than I would like. However, you are not required to be obnoxious about it. It helps no one. Your mistakes are very rare, and your work is sincerely appreciated. I think your comment about my response is out of context, and I'm not sure your final statement is true. My polite comments were summarily dismissed, but now anyone who depended on CUSTOM_ID has been helped. The problem should be fixed in 0449b785b4b58ec16e1aac126634de70eee519a4. Thank you for reporting it. Thank you for your prompt action, but can I ask what you mean by fixed? Have you decided to revert CUSTOM_ID to its previous functionality? Are you still planning on changing its functionality and/or meaning? Are you still planning on throwing warnings or errors in the event of duplicate or invalid CUSTOM_ID's? Best, Terry -- T.F. Torrey
Re: [O] Bug: HTML export ignoring CUSTOM_ID properties
Hi Rasmus, As someone with all my personal and work files in Org, I sincerely appreciate all the work you do to improve Org. But... Rasmus ras...@gmx.us writes: With the latest from Git master, the HTML export ignores CUSTOM_ID properties for subtrees. I've seen list traffic that the names of the export ID's are being changed, but this is not intentional, right? It doesn't ignore it, but it is translate to a generic anchor as needed. Isn't translating it to a generic anchor the same as ignoring it? Without a CUSTOM_ID you get a generic anchor. With a CUSTOM_ID you get a generic anchor. Previously, both a generic anchor and the custom_id would be inserted in html. E.g. for a headline with id h1: h2 id=h1a id=sec-1 name=sec-1/a Yes, that was a little clunky, but it did work, and the name attributes could be suppressed. The problem is that we don't know that h1 is unique. However, in html custom_id serves as an important measure to facilitate css customization, e.g. on a section level-basis. Yes, the user was responsible for making sure CUSTOM_ID's were unique, but in practice that never amounted to what could be described as the problem. However, CUSTOM_ID's are not just CSS targets, they are link targets. Consider this typical usage: I have a page of my favorite presidents: #+BEGIN_SRC org * Favorite Presidents ** George Washington :PROPERTIES: :CUSTOM_ID: washington :END: He was tall. ** Bill Clinton :PROPERTIES: :CUSTOM_ID: clinton :END: He liked the ladies. #+END_SRC Because I know (knew) the id of the section about Clinton, I could link to my page from another document outside Org with a link to presidents.html#clinton. This is how all the links between documents are done on my website, and it's mostly how internal links in the HTML that becomes e-books is done. However, with the new export code, many, perhaps all, of my links are broken, because what comes out of the HTML exporter is this: #+BEGIN_HTML div id=outline-container-sec:4 class=outline-2 h2 id=sec:4span class=section-number-21/span Favorite Presidents/h2 div class=outline-text-2 id=text-1 /divdiv id=outline-container-sec:1 class=outline-3 h3 id=sec:1span class=section-number-31.1/span George Washington/h3 div class=outline-text-3 id=text-washington p He was tall. /p /div /div div id=outline-container-sec:2 class=outline-3 h3 id=sec:2span class=section-number-31.2/span Bill Clinton/h3 div class=outline-text-3 id=text-clinton p He liked the ladies. /p /div /div #+END_HTML Notice how my CUSTOM_ID's are no longer ID's at all. And simply adding text- to my CUSTOM_ID's is not an answer. For one thing, CUSTOM_ID exports should not change on the breeze of developer whims. For another, the ID should be attached to the heading, not the body of the text; otherwise, a person following the link would have no idea if it went to the Clinton section or not. Note that this also breaks any CSS styling for the section with the CUSTOM_ID (which I also use). If I used a CUSTOM_ID because wanted a swanky background for the heading saying Bill Clinton, the current export not only doesn't use that ID, it doesn't encompass the heading with his name in. Thus, I think it is a bug, unless there is a better way to allow per-section css. I will look at this later unless somebody beets me to it. Given the lack of outcry, I may be the only one using CUSTOM_ID's for HTML export. However, if usage is widespread enough and accidental duplicates are a problem enough that this needs to be addressed, wouldn't it be better for the exporter to simply report duplicate ID's as they are found? Finally, given that this doesn't appear to work at all in any form of its intended usage, how did this even get committed to master? Sure, code in master may have bugs, but this is more than a bug; this is unusable code that breaks code that worked. Shouldn't it be developed on a feature branch or in someone's private repo until it actually works? Unless there is a quick fix that restores external (non-Org-generated) links to sections with CUSTOM_ID's, please revert these changes until the development reaches a usable state. All the best, Terry -- T.F. Torrey
[O] Bug: HTML export ignoring CUSTOM_ID properties
Hello list, With the latest from Git master, the HTML export ignores CUSTOM_ID properties for subtrees. I've seen list traffic that the names of the export ID's are being changed, but this is not intentional, right? Emacs : GNU Emacs 24.4.1 (i586-pc-linux-gnu, GTK+ Version 3.14.5) of 2015-03-07 on binet, modified by Debian Package: Org-mode version 8.3beta (release_8.3beta-1045-gd8494b @ /home/tftorrey/T/org-mode/lisp/) All the best, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Hello Aaron, Aaron Ecay aarone...@gmail.com writes: Hi Terry, 2015ko martxoak 10an, T.F. Torrey-ek idatzi zuen: Of the things in your list, I think only the NEWS and Changelog are absent from the master branch in git. Lots of us happily use Org master from git without them every day. Do they really need to be done at all? Many people are very happy not using org at all. Perhaps we should just all quit and find other hobbies. OTOH, release milestones are important to the health of a software project and so yes, really need to be done. You seem to be arguing with a point I wasn't making. Release milestones are fine, but the current plan for doing them is too much work for the people involved. Couldn't a simpler way work? If Emacs 25 is taking Org out of core, does the code still have to be merged into the trunk? This is not on the table. Rather, the (tentative) proposal from the emacs side is for some packages to be developed in the GNU ELPA repository, and be extracted from there and bundled with emacs release tarballs (in addition to being released in ELPA). Org is sometimes cited as an example of a package that would benefit from this strategy, but there has been no discussion of this from the org side, and AFAIK no decision has been made whether we’d take advantage of this facility if/when it’s available. Interesting. Exposing new users to the vagaries of the master branch may rather lead to atheism. This sounds like the foot-shooting argument again. Could one not just as easily harm one's foot with the master version from git? Or is the assumption that only git users are smart enough to wield the power? Maybe Org is so powerful that it should not be released via by ELPA at all, for the sake of everyone's appendages. All the best, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
emac...@gmail.com (Richard Y. Kim) writes: tftor...@tftorrey.com (T.F. Torrey) writes: I wonder how much effort it would take to copy onto my own machine the scripts on the server that package the git maint version into an ELPA version, and modify them to package master instead. Probably not much. The shell script below is what I use to create my own org-plus-contrib ELPA package. Rather than relying on elpa.gnu.org, melpa.org, orgmode.org/elpa, etc., I've been creating my own packages over the past year or so. This way I know exactly which packages are installed in not only my emacs, but my colleagues who use my packages. So far this has worked out great for me. Looks excellent. Thank you! All the best, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Achim Gratz strom...@nexgo.de writes: Richard Y. Kim writes: # server.mk has the elpaplus makefile target echo include mk/server.mk Makefile […] # Undo the change made above git checkout Makefile You know, local.mk was introduced specifically so you wouldn't have to do anything like that. I did know that. I remember the massive overhaul of the makefile system (which, IIRC, you masterminded). Unfortunately, I am not a makefile guru, so merely knowing that is not enough. I wish I had fewer dirty hacks in my life, but I'd rather get something done with a dirty hack than not get it done at all. All the best, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Hello Aaron, Aaron Ecay aarone...@gmail.com writes: If the goal is to have the latest and greatest version of Org available via ELPA (for all the reasons some people use ELPA instead of git), there are two obvious options: 1. Org could have a stable release every month or so. 2. The Org server could be configured to automatically package the master version of Org every day, as the maint version is now. Option 1 is widely regarded as the best choice. However, it requires a lot of actual, repeated human effort. As Debian repeatedly demonstrates, this is very hard to do, even once. If option 1 could be done, it would already be done. Option 2 would be a one-time (mostly) human effort, and the daily work would be automated. But what would not be automated is the actual human effort that goes into making a release: writing NEWS and documentation for new features, testing for regressions, generating the emacs Changelog files, merging changes from emacs trunk back into to org code base, merging org code into emacs trunk, ... Someone still has to do all those things eventually. Or not, and the quality of org as a software product suffers. Refusing to make the git master version available through ELPA doesn't help any of those things get done. It simply denies the latest Org to those unable or afraid of using git. Of the things in your list, I think only the NEWS and Changelog are absent from the master branch in git. Lots of us happily use Org master from git without them every day. Do they really need to be done at all? If Emacs 25 is taking Org out of core, does the code still have to be merged into the trunk? If the manpower does not exist to support both a maint and a master branch, maybe they should be merged. Could that be done? Still just trying to make it easier to spread the gospel of Org, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Hello, Sebastien Vauban sva-n...@mygooglest.com writes: As Grant pointed out, it’s a lot more convenient working inside Emacs for switching between versions and such. How do you switch between versions in ELPA? IIUC, you only get the latest version, and if that one is not right, you're kind of stuck: you can't reinstall the previous version via the interface. Or maybe I have to learn something new? Only one version per package name is allowed, so with everything in one archive it won't currently work. However, with smaller archives each holding one version, it becomes possible. For instance, to get the latest package of the main version of Org, enable the Orgmode.org/elpa archive. To go back to the slightly older, perhaps more stable version in the GNU archive, remove the Orgmode.org/elpa archive from your archive configuration, uninstall Org, then reinstall it, and you will get the version from the GNU archive, which will now be the latest one the packages system can find. It's kind of a hack, sure, but until the package system is upgraded to handle dependence on multiple versions of the same package, it works. It would probably be inconvenient to do this for every package, but I don't mind doing it for major packages like Org. HTH, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Achim Gratz strom...@nexgo.de writes: The version of package manager that people most likely use today always choses the latest version from _any_ archive available when you update. You can't tell it to consider some archive more authoritative than another or that it should stick with whatever source archive the package was originally installed from. Of course. My explanation was worded poorly, because instead of sleeping I was wasting my time supporting someone else's request to be able to get the latest version of Org via ELPA. The current daily builds are here: […] That sort of contorsionist gymnastics defeats the whole point of having a package manager in the first place. If every package would have to do that we'd all end up juggling dozens of archives in our config files. The guidance for using Org via ELPA is already to add the Orgmode.org/elpa archive (paraphrased). Changing that to add Orgmode.org/elpa-stable for the stable version or Orgmode.org/elpa-unstable for the bleeding edge version is suddenly contortionist gymnastics? Really? Compared to using git? If the next version of Emacs breaks Org out of core into the GNU ELPA package archive, things can be even easier: Keep the stable version in the GNU package archive, and keep the unstable version in the archive on the orgmode.org server. I wouldn't hold my breath. At the moment that mechanism by which to do that is certainly not in place and there's no agreement on what it should look like. Agreement or not, something will be done. Already the mechanisms are in place that put the maint version in both locations. The biggest obstacle I to this that I see is that developers tend to hate the package manager and love git. (And personally, I think the contrib parts should either be merged into the core or split into separate packages, but that's another can of worms.) if you want to move things into core, clean those files up, create tests and get the copyrights assignmed to the FSF by their authors and propose their inclusion. If you want separate packages, I'm quite certain that this needs further modifications at least to some of the files. The current mode of operation is that they should be compiled together with the rest of Org and no checks are made if they work if installed sepaerately. Some of them likely do, others probably not. Yes, either choice would be an effort. However, there is currently the problem that some packages depend on org, and others on org-plus-contrib, which cause both to be installed (without some controtionist gymnastics). IMHO, the Org package at Orgmode.org/elpa should either always include contrib, as the git repository does, or split the contrib part into an org-contrib package that depends on org. All the best, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Hello again, Rasmus ras...@gmx.us writes: I want to collaborate on Org files with my wife and parents, ^^^ Do you? It sounds cool! It's complicated. I've convinced my parents to begin writing memoir-type books, and my wife works in non-profit, where good books are always good solutions. I push them toward using plain text files for the benefits we all know, and because I can turn the files into epub books, Kindle books, and PDF print books using my custom Org export code. I would love to introduce them to the awesomeness of Org. I think they could work in Emacs, and I'm sure they could handle updating things via ELPA, but I'm also pretty sure that the sight of git would send them screaming all the way back to Microsoft Word. At the same time, I don't want to use or write my custom code for an old version of Org, and the files produced by the maint and master versions of Org are slightly incompatible. So. The current process is for them to use Markdown formatting in their plain-text files. At least these can be converted with a quick script (and Calibre's ebook-convert) to epub, Kindle, and pdf versions. These are okay, but not great. For final versions, I will need to convert the Markdown down Org using Pandoc, then do the pretty exports using my Manuscript package. This is not a solution. This is a labor-intensive, error-prone hack. I would so much prefer to get them into Emacs and Org. And I could, if the master version was availble through ELPA. In a real-world situation, I want to collaborate on Org files with my wife and parents, and I want to use the current best version of Org (which has significant improvements to #+INCLUDE that I use), but I do not want to try to install git on their Windows machines, I agree. I have the same problem when I build documents (via CI) on a remote Debian server where I don't want to mess around with anything more than what comes with Emacs by default. This is another great use-case for an ELPA version of the git master. Serious Org users are already forced to install and run git to use the master version, and whatever the dangers, the practice is almost completely without problems. A bleeding edge ELPA would merely make that simpler. I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple of other packages will move to GNU ELPA and thus separate release channels (these packages will still be bundled with Emacs). This means we can push out new versions easily, making more frequent releases more attractive. Again, if you want to help out with preparing releases just let the list and Bastien now. I'm looking forward to this new arrangement (though it will be interesting when, AFAIK, Gnus still doesn't have a workflow through ELPA). However, I don't see how this will make it easier to push out new stable releases. That still has the inherent problem that making something called a stable version takes a lot of human effort. I wonder how much effort it would take to copy onto my own machine the scripts on the server that package the git maint version into an ELPA version, and modify them to package master instead. Probably not much. I could host that on my own server, or maybe upload it to Melpa. I think I will look into that. All the best, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Hello again, Achim Gratz strom...@nexgo.de writes: Rasmus writes: I agree. I have the same problem when I build documents (via CI) on a remote Debian server where I don't want to mess around with anything more than what comes with Emacs by default. You can use a tarball and the support for manual builds, described in: http://orgmode.org/worg/dev/org-build-system.html#sec-7 I think there is even an existing way to automate the whole process, isn't there? Org is awesome. But still, we were looking for an ELPA solution, not just a different workaround. I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple of other packages will move to GNU ELPA and thus separate release channels (these packages will still be bundled with Emacs). This means we can push out new versions easily, making more frequent releases more attractive. None of this is going to lift one core limitation of package manager: there can be only one. It doesn't support packages that subsume other packages, so org-whatever is totally different from org and would be installed together when referenced by dependencies even though it makes no sense. I wrote in my other e-mail that the limit is one per archive, but I don't think that's technically true. I think you can actually have as many as you want, even from the same archive, but only the one with the newest date (actually, greatest file name) will be installed. So, to make all the packages that depend on Org use the unstable version rather than the stable version, add-to-list 'package-archives the unstable archive rather than the stable archive. And if you want to keep have both the GNU archive and the Orgmode.org archive in your package-archives, and you want to have the unstable version from Orgmode.org installed instead of the stable version from the GNU archive, no problem: The one in the GNU archive has an older date because the unstable one on the Orgmode.org server gets updates every day, and thus the package manager will select that one to install. IIUC, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Hello, Rasmus ras...@gmx.us writes: As I think somebody said, the correct fix to this problem is more frequent released. I'm sure Bastien would appreciate help with this. Do you want to volunteer? If the goal is to have the latest and greatest version of Org available via ELPA (for all the reasons some people use ELPA instead of git), there are two obvious options: 1. Org could have a stable release every month or so. 2. The Org server could be configured to automatically package the master version of Org every day, as the maint version is now. Option 1 is widely regarded as the best choice. However, it requires a lot of actual, repeated human effort. As Debian repeatedly demonstrates, this is very hard to do, even once. If option 1 could be done, it would already be done. Option 2 would be a one-time (mostly) human effort, and the daily work would be automated. So, if the goal is to have the latest and greates version of Org available via ELPA (and it should be), option 2 is the only one that is possible in the real world, so that's the one we should set up. All the best, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Hello, Achim Gratz strom...@nexgo.de writes: It doesn't get any easier than it already is. Having both a stable and an unstable version of Org avilable via ELPA is a non-starter for the simple reason that the package manager can't deal with the versioning problems this would introduce. I think this is not only not a non-starter, I think it is very easy with the existing package manager. The package manager can only handle one version of a package *per archive*, so instead use one archive per version. The current daily builds are here: http://orgmode.org/elpa/ To allow choosing between stable (maint) and unstable (master), put the package archives here instead: Stable: http://orgmode.org/elpa-stable/ Unstable: http://orgmode.org/elpa-unstable/ Then, just add-to-list 'package-archives whichever flavor you want. (And actually, to do away with the current conflict between the org and org-plus-contrib packages, each of those should be in a separate archive as well.) If the next version of Emacs breaks Org out of core into the GNU ELPA package archive, things can be even easier: Keep the stable version in the GNU package archive, and keep the unstable version in the archive on the orgmode.org server. (And personally, I think the contrib parts should either be merged into the core or split into separate packages, but that's another can of worms.) All the best, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
A major benefit of an ELPA version of the bleeding edge version of Org is that it enables those of us who run Emacs and Org on machines where we can not install git (or just do not want to) to have the latest version of Org nonetheless. In a real-world situation, I want to collaborate on Org files with my wife and parents, and I want to use the current best version of Org (which has significant improvements to #+INCLUDE that I use), but I do not want to try to install git on their Windows machines, and I do not want to scare them off by introducing the world of Git in addition to Emacs. And it's not limited to #+INCLUDE. I've been using Org for many years, and no matter how good a release of Org has been, the version in maint has followed right behind with new killer features. Having that version in Elpa makes it easier for me to share the awesome. Aaron Ecay aarone...@gmail.com writes: IMO this is a bad idea. The bleeding edge version is expected to be somewhat unstable, and exposing it via ELPA will lead to foot-shooting incidents. I understand this concern in principle, but it is difficult for me to imagine how it would be validated in actual usage. Serious Org users are already forced to install and run git to use the master version, and whatever the dangers, the practice is almost completely without problems. A bleeding edge ELPA would merely make that simpler. I regularly use both the git master version of Org and the ELPA version of Org, and I do extensive elisp coding that interacts with both, and I do not remember a problem that could be described as foot-shooting. Any significant problems in a bleeding edge version would be resolved the same way they are in the master version of git, only with the solution packaged, delivered, and installed by the next day, except automatically. It is easy to imagine someone else unofficially packaging the bleeding edge version and making it available via ELPA, and hard to imagine that resulting in significant problems. Melpa is loaded with bleeding edge versions, but the problems I hear or see from it are very rare. Also, as noted before, if someone is unhappy with the bleeding edge version, switching back would be easy. On the other hand, it would be nice to have more regular releases from master to maint. AFAIK the last one was a year and a half ago (Org 8.2). However, this has traditionally required a lot of effort from Bastien and others, so it’s not a simple case of “wishing will make it so”. Very true, and no doubt there are benefits to having a stable version available. However, not providing the bleeding edge version on ELPA is not without cost. The mailing list is littered with responses from Nicolas saying that problem has been fixed in the master version One last thought: I think it would be better to name the versions stable and unstable, to match the meanings established by Debian. All the best, Terry -- T.F. Torrey
Re: [O] Bleeding edge in elpa
Nikolai Weibull n...@disu.se writes: Would it be of interest to anyone else if the bleeding edge version was available via elpa? I would also very much appreciate it. Terry -- T.F. Torrey
[O] Bug: nil in HTML export output
Hello, With the latest code from the git repo, the HTML export of items having drawers but no top-level content puts a stray nil in the outline-text- div. Minimal document to show bug: #+BEGIN_SRC org ,* Item without drawers does not make nil ,* Item with drawer and top-level content does not make nil :PROPERTIES: :CUSTOM_ID: item_1 :END: Here is top-level content. ,* Item with drawer but no top-level content makes nil :PROPERTIES: :CUSTOM_ID: item_1 :END: #+END_SRC Reproduced starting Emacs with emacs -q, loading Org from the latest pull from git, then exporting the test document using the export dispatcher. Snipped output: #+BEGIN_SRC html div id=outline-container-sec-1 class=outline-2 h2 id=sec-1span class=section-number-21/span Item without drawers does not make nil/h2 /div div id=outline-container-item_1 class=outline-2 h2 id=item_1a id=sec-2/aspan class=section-number-22/span Item with property drawer and top-level content does not make nil/h2 div class=outline-text-2 id=text-item_1 p Here is top-level content. /p /div /div div id=outline-container-item_1 class=outline-2 h2 id=item_1a id=sec-3/aspan class=section-number-23/span Item with property drawer but no top-level content makes nil/h2 div class=outline-text-2 id=text-item_1 nil/div /div #+END_SRC Emacs : GNU Emacs 24.4.1 (i586-pc-linux-gnu, GTK+ Version 3.14.5) of 2014-12-19 on brahms, modified by Debian Package: Org-mode version 8.3beta (release_8.3beta-764-ga1f540 @ /home/tftorrey/T/org-mode/lisp/) I haven't chased down the cause yet. Terry -- T.F. Torrey
Re: [O] New maintainer
Thank you for your hard work, Bastien. You've done a fantastic job under unusually adversarial conditions. On Thu, Apr 18, 2013 at 9:53 AM, Bastien b...@gnu.org wrote: Dear all, I'm stepping down as the Org maintainer. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! :) -- Bastien
[O] [Bug] HTML Exporter Does Not Convert \\ To br /
The old exporter would convert \\ at the end of a line to br / to force a line break. The manual still says that \\ will force a line break, but the new HTML exporter, while indeed breaking the line there, does not insert the br / to make it render as a new line. This is using the latest version from Git. I think this is a bug, not a limitation of the new exporter. Best regards, Terry -- T.F. Torrey
Re: [O] [Bug] HTML Exporter Does Not Convert \\ To br /
On Sun, Apr 21, 2013 at 4:02 AM, Eric Abrahamsen e...@ericabrahamsen.net wrote: Hi Terry, I just tried with emacs -Q (I'm on 24.3.1) and git Org mode, and the \\ is exported as br/. Can you check with emacs -Q? If you look in ox-html.el, you'll see that the function `org-html-line-break' should produce a br/\n. Could something else be going wrong? Thanks for the verification. Indeed, it does work with emacs -Q, and even with a simple restart of Emacs. Sorry for the noise. -- T.
Re: [O] (no subject)
Thank you for your thoughtful reply. -- T. Bastien b...@altern.org writes: Hi Terry, I hear you. I completely agree that Org should not be less flexible than it has been so far. At least not for very good reasons, shared by both the developers and the users. IOW: ease of maintainance and code consistency should not let us introduce rigidity for the users. Let's focus on the regressions and let's try to fix the ones that we can fix. As discussions have shown so far, Nicolas holds the keys when it comes to honoring Org's consistency regarding its syntax -- the document he wrote will help us all to speak about the same syntax and rules. But as you may have felt, I'm more on the user conveniency side, even if we need to sacrifice some consistency. There is a balance here, and I hope we keep a good one. So as I said: let's focus on what you perceive as regressions wrt what Org allows. The subject of this thread does not fall in this category: headlines have always been starting with stars, there is no regression here. On the contrary: a few years ago, we had no answer to this FAQ, now we can help users with several solution when the problem is aesthetic. Finally, I agree with Suvayu that the problem *is* mostly aesthetic, so the solutions we provide are enough (i.e., the FAQ, org-bullets.el in contrib/.) The question is rather whether we should have an Org option in core to allow users to tweak the appearance of the stars: my answer here is no, because I don't see why users would stop here. Once we offer such an option for headlines, why not for comments and other characters with a syntactic role? (I replied a question on stackoverflow on how to use % instead of # for comments...) Anyway -- Org still stands on the side of users' freedom, let's fix the real regressions. Thanks!
Re: [O] ox-html.el removal
Jambunathan K kjambunat...@gmail.com writes: Meanwhile, someone should fix up the FSF assignment notice on those files. As far as I am concerned, it is a routine housekeeping thing and hasn't taken effect. I am not assigning any copyright to FSF. Section 1a of the copyright assignment agreement is very specific: #+BEGIN_QUOTE: 1.(a) Developer hereby agrees to assign and does hereby assign to FSF Developer's copyright in changes and/or enhancements to the suite of programs known as EMACS (herein called the Program), including any accompanying documentation files and supporting files as well as the actual program code. These changes and/or enhancements are herein called the Works. #+END_QUOTE: As a signed contributor, you have already assigned copyright of your changes and/or enhancements to Emacs to the FSF (and therefore to this community). The agreement does not limit the assignment to those that land in an Emacs release, or those you don't change your mind about, or anything like that. Any changes and/or enhancements to Emacs became property of the FSF from the moment you wrote them. Because you are not the copyright holder, it isn't even your prerogative to decide which license the code is released under. It happens to be GPL, but the code is licensed by the copyright holder, which is the FSF, not you. Even listing you as an author in the file is a courtesy, not an obligation. Furthermore, any future code you might write concerning Org is also automatically property of the FSF, and by extension this community. You have no rights to it, moral or otherwise. #+BEGIN_QUOTE: (b) The assignment of par. 1(a) above applies to all past and future works of Developer that constitute changes and enhancements to the Program. #+END_QUOTE: With the copyright assignment in place, there is nothing to clear up for the next release of Emacs. The FSF owns the code. You gave it to them for $1 and other good and valuable consideration. There is no way to change these terms for code you have already written, unless you can convince the FSF to assign the copyright back to you, or win the rights through legal action, neither of which sound fruitful. If you are unhappy granting the copyright to your future Org code to the FSF, your only recourse is to terminate your agreement with the FSF. I don't precisely know how that would be done, given that the copyright assignment document makes no provision for its cancellation, but a simple, formal notice of termination of the agreement might suffice, even if made only to this list, which is operated by the FSF and managed by its representatives. Also, if you genuinely believe that anyone (including you) has a claim to the rights to the Emacs code you have written, Section 2 of the copyright assignment requires you to notify them: #+BEGIN_QUOTE: 2. Developer will report occasionally, on Developer's initiative and whenever requested by FSF, the changes and/or enhancements which are covered by this contract, and (to the extent known to Developer) any outstanding rights, or claims of rights, of any person, that might be adverse to the rights of Developer or FSF or to the purpose of this contract. #+END_QUOTE: Finally, this is only my understanding of the copyright assignment, but the terms seem straightforward and clear. If there really is uncertainty among the developers here about what the copyright assignment means, we should get clarification from RMS about the intent or FSF legal about its legal implications before it leads to a lot of hurt feelings (or worse). All the best, Terry -- T.F. Torrey
Re: [O] Create course material with org-mode
Hello Thorsten, Torsten Wagner torsten.wag...@gmail.com writes: Actually the topic is not exactly OT, I'm looking for a meta-system which helps me to keep all those different things together. Hopefully, in a way which allows me to generate different kind of course material from the same sources. I was wondering, can org-mode be such a meta-system e.g. could I keep materials of a certain topic within a single org-file and use (customized) exporters to create the desired outputs like a interactive HTML version, a printable PDF, exercises and questions for exams? E.g. a file structure like this * Theory text text text ** Interactive example :HTML Bable code ** more theory in detail *** Images ** lecture slides :BEAMER ** Exercises *** Solutions ** Exam questions *** 1 *** 2 *** 3 This is more or less precisely the structure I use for managing my work. I maintain each project as one Org file, keeping together all related text, todo lists, spreadsheets, web pages, letters, and even files like SVG files. This way I can add just one file (per project) to my agenda and not miss any tasks, and backing up my critical work is just a matter of copying my Org files. When needed, I also export the individual nodes as HTML, PDF, OpenDocument, csv, or whatever. This works very well for me, even when I am treating university classes as projects and keeping the syllabus, instruction material, lab material, data, tests, correspondence, and everything else together in one file. This file should ideally run through different exporters to generate interactive HTML for a website, printable PDF version, slides for a lecture, exercises with and without solution, exam questions, One task which might require some more attention (and code) would be to compile e.g. the entire script from different source files. Same for an entire exam, a set of exercise, etc. The benefit of an approach like above would be that I can keep all related infos close to each other. It would be much easier to make changes among all different outputs, create new material, etc. Hope this makes my idea more clear. Thanks for helping Torsten It was this capability of Org that first captured me as a user, and I still know of nothing else with so much accessibility, utility, and power. I'd be happy to give you more information about how to set up an Org file to export to different formats the way I use mine, but really the information is very clear in the manual. And of course, if you have any trouble, the list is really great. All the best, Terry -- T.F. Torrey
[O] [bug] [new exporter] [markdown] Underline exports as HTML
Hello, The new markdown exporter (which I didn't think I'd use, but now greatly appreciate) seems to export underlines as HTML rather than markdown. In other words, this: The _second_ thing. exports as this: The span style=text-decoration:underline;second/span thing. I'm not experienced with markdown, but this doesn't look right to me. Emacs : GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0) of 2012-12-24 on menkib, modified by Debian Package: Org-mode version 8.0-pre (release_8.0-pre-36-g0c7e2c @ /home/tftorrey/.emacs.d/elisp/org/lisp/) All the best, Terry -- T.F. Torrey
Re: [O] (no subject)
Hello, Bastien b...@altern.org writes: Hi Andreas, Andreas Röhler andreas.roeh...@easy-emacs.de writes: Hmm, AFAIS trouble might occur only if someone tries to load a non-default --i.e. not-starred-- org-file while the default is active. ... or if someone shares a file online using non-star character as the prefix for headlines: this file won't be processed by Org tools like org-ruby and the like. But even then it's quite easy to write a guess, which might start if org-mode didn't encounter the stars where expected. Org files are not just for Emacs, that's were the problem lies... I don't understand this heavy-handed approach. Plain text is great because I can do whatever I want. What I come up with might not work correctly in other tools (or anything at all), but I have the freedom to do interesting things, and to have my files look just the way I want them to. Emacs is great because it allows me the freedom of near-infinite customization. It has sensible defaults, but it allows me to break things however I want. Org, on the other hand, seems to be moving away from that in many ways. Headlines must start with stars because I might someday post something on the web and it wouldn't work for someone else? Other tools might not recognize my file correctly? A developer of some other tool might someday have a problem? These are not good reasons for limiting what I can do with my own Org files. I don't need or want supervision in how I create my files. I want freedom. If I wanted supervision, I wouldn't be using Emacs. Have you seen the lisp posted to the web? Somehow, Emacs and I survive that. Org started as a great tool that let me do cool things with my text files. I don't want to see it change to a rigid format for me to force my files into, where my only options are conform or leave. Org should err on the side of user freedom. IMHO, Terry -- T.F. Torrey
Re: [O] [new exporter] [html] Tables of Contents
Hello Jambunathan, Jambunathan K kjambunat...@gmail.com writes: Torrey One small problem, though: I see that if there is a TOC at the top and then one included later using #+TOC, the exporter gives them both the same id (div id=table-of-contents). Duplicate ID's makes the XML invalid. What do you suggest instead? id=table-of-contents-1 for the first #+TOC: keyword and so on? Why do you need two table of contents? I don't, though some might. As was explained earlier in this thread, if toc: options are set in the OPTIONS line, and a #+TOC is specified later, two tables of contents are generated, and they have the same ID. It is a feature of the new exporter, but duplicate ID's are not valid in XML. It is common for technical manuals to have a top-level table of contents at the front of the manual and a detailed table of contents later on. For instance, the GNU project Info manuals have that structure. This gives a significant advantage in that authors can link to the various instances just by knowing their own usage. For instance, if they provided a top-level toc at the beginning of their book, and a deeper-level toc later on, they could link to each separately by id by knowing this plan. This seems like a valid use-case. I would recommend that you just specify just the use-case and leave out the hows of implementation. Put your user hat and set aside the developer's hat. What a strange, semi-insulting thing to say. And misguided, too, as I was suggesting a design, not its implementation. As someone with all my own documents in Org and extensive experience developing XSLT and lisp to process the XHTML output of Org, I appreciate when the design of the HTML output is logical and useful. I would rather see a good design implemented in hacks than a poor design implemented in beautiful code. Regards, Terry -- T.F. Torrey
Re: [O] [new exporter] [html] Tables of Contents
Hello Jambunathan, I admire your energy and coding skill, but I wish you would stop occupying our time with replies like this. Your tone is insulting, and seems deliberately so, and none of this response is helpful to the original thread. I won't reply to more of your posts like this, so if you don't get a reply, know that it's because your message was insulting and off-topic. I'm only sending this on the odd chance that you are not aware of what you are doing, in which case this might be helpful to you. If you want to follow up to this message, I invite you to do so off-list, where it might have been best for me to post this as well. Best regards, Terry Jambunathan K kjambunat...@gmail.com writes: tftor...@tftorrey.com (T.F. Torrey) writes: This gives a significant advantage in that authors can link to the various instances just by knowing their own usage. For instance, if they provided a top-level toc at the beginning of their book, and a deeper-level toc later on, they could link to each separately by id by knowing this plan. This seems like a valid use-case. I would recommend that you just specify just the use-case and leave out the hows of implementation. Put your user hat and set aside the developer's hat. What a strange, semi-insulting thing to say. There is nothing strange in what I said. I wasn't insulting. And misguided, too, as I was suggesting a design, not its implementation. As someone with all my own documents in Org and extensive experience developing XSLT and lisp to process the XHTML output of Org, I appreciate when the design of the HTML output is logical and useful. When you were suggesting #+toc: :a b :b c :c d that is implementation specifics and you were arguing from a HTML standpoint. If you were in fact designing, you would have articulated your case for other backends and how your suggested changes would impact ox.el. I would rather see a good design implemented in hacks than a poor design implemented in beautiful code. If you have better ideas, show us the patch. Otherwise, I suggest that you wear your user hat and place the use-case before use while others can take care of the details.
Re: [O] [new exporter] [html] Tables of Contents
Hello Jambunathan, Jambunathan K kjambunat...@gmail.com writes: Is there a way your specific problem could be solved if we were to use CSS counters for numbering various things? Would you like to submit a patch to ox-html.el that uses CSS-based counters rather than counters computed with hand. No. I'm not sure I understand your motives here, but I think you would like to make changes to ox-html.el that would address the bug report/feature request I sent. If so, read on. The problem is that in situations where the HTML exporter produces two tables of contents, it gives them both the same ID. That makes the XML invalid, breaks some linking, and tends to choke XSLT processors. I suggested three different strategies for the ID: 1. A detailed schema (see original email) 2. Allowing user to designate the ID 3. Just adding a sequence number to the end Of these, 1 would probably be the hardest to implement, but would provide the most accessibility for users and post-processors. 2 would probably be the easiest to implement, but would have the problem that users wouldn't know they had to do it until something didn't work. 3 is probably the easiest to implement, but with the lowest utility. My personal choice would be for both 1 and 2 to be implemented, but as I'm not doing the work, that might be too much to ask. Just doing 3 would make the XML valid again (in these cases), and would be good enough for now. So, if you're looking to implement a solution, 1 and 2 please, or 3 if 1 and 2 are too much work right now. If, on the other hand, you're just trying to find a way to make my suggestions sound dumb, please see my previous e-mail. Best regards, Terry -- T.F. Torrey
Re: [O] [new exporter] [html] Tables of Contents
Hello Jambunathan, Jambunathan K kjambunat...@gmail.com writes: Jambunathan K kjambunat...@gmail.com writes: [... 13 lines omitted ...] Subtree export of headline 1, but with section numbers starting at 1. Subtree export of headline 2, but with section numbers starting at 2. Splice them together. Considering that HTML exporter can export a subtree, I believe you can do some XSLT magic so that the individual HTML generated by Org is transformed before being spliced. Do you really want this to be supported within the scope of the Org exporter? Are you sure you have explored all the tricks in your bag before raising this request. Just wanted to confirm, because you seem to be the HTML expert among the three of us... I'm not sure we are talking about the same issues. For one thing, you are replying to yourself here. I did not suggest this. My request was merely for valid XML ID's for tables of contents from the HTML exporter, given that most of the XML tricks in my bag depend on valid XML input. [... 11 lines omitted ...] Allow a subtree to take EXPORT_TOC property. (There should be a way to specifiy where this TOC will end up in - beginning of that chapter or end of the chapter) Similarly, one could introduce EXPORT_ENDNOTES property whereby each chapter can have it's own self-contained End Notes section. I don't think these are related to my original concern, but they do sound like interesting ideas that might be of use to me. They also sound like a lot of work. Should this be taken up again after the 8.0 release? Best regards, Terry -- T.F. Torrey
Re: [O] [new exporter] [html] Tables of Contents
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, tftor...@tftorrey.com (T.F. Torrey) writes: One small problem, though: I see that if there is a TOC at the top and then one included later using #+TOC, the exporter gives them both the same id (div id=table-of-contents). Duplicate ID's makes the XML invalid. What do you suggest instead? id=table-of-contents-1 for the first #+TOC: keyword and so on? Regards, If I were implementing this with abundant resources, I'd probably opt for a schema of base-type[-levels][-sequence], with these definitions: - base :: probably toc to group and identify these id's - type :: headlines, images, or other current or future types - level :: depth of map, if it makes sense for the type - sequence :: if necessary, the number of the copy of this configuration in this document This schema would produce id's such as these: - toc-headlines-1 :: lone instance of toc/headlines/one level - toc-headlines-2 :: lone instance of toc/headlines/two levels - toc-headlines-2-2 :: second instance of toc/headlines/two levels - toc-images :: lone instance of toc/images (do levels make sense?) - toc-tables :: first instance of list of tables - toc-tables-2 :: second instance of list of tables You get the idea. This gives a significant advantage in that authors can link to the various instances just by knowing their own usage. For instance, if they provided a top-level toc at the beginning of their book, and a deeper-level toc later on, they could link to each separately by id by knowing this plan. Another idea for achieving the same linkability without the plan, would be to support assigning an id in the plist (that isn't implemented yet), such as #+TOC: :type headlines :levels 2 :id toc-headlines-2. With this power would come the responsibility for the users to make sure id's were not duplicated. As a minimum, your suggestion (table-of-contents-1, etc.) would be reasonable for most use cases, and it's the shortest route to valid XML. Some users of Org are producing complex documents that will probably be active users of multiple toc types. I'm curious what kind of schema would work best for their use cases. Best regards, Terry -- T.F. Torrey
Re: [O] [ANN] Merge of new export framework on Wednesday
Hello, Rick Frankel r...@rickster.com writes: Also, shouldn't :html-style-include-default be :html-head-include-default? The variable and this property should stay html-style-include-default, or at worst become html-head-include-default-style. The intent of changing things from html-style... to html-head... was to make it clear that the use is for anything in the head, not merely style. It is still appropriate for variables that actually refer to style to have the word style in them. IMHO, Terry -- T.F. Torrey
Re: [O] Frustrated user of orgmode
Suvayu Ali fatkasuvayu+li...@gmail.com writes: On Mon, Mar 04, 2013 at 07:10:47PM +0530, Vikas Rawal wrote: Do we have even a sketchy documentation of what a user is supposed to http://orgmode.org/worg/org-faq.html#new-exporter-switch FWIW, I was trying to find this last night to answer a question, and even though I knew exactly what I was looking for, I couldn't find it. Granted, it was late and I was tired, but the site map has nothing, the index has only dead ends, and the Google custom search doesn't seem to narrow it down (lots and lots of things match exporter and new, and I couldn't remember enough specific text to make it work). (I was looking for the syntax for the new #+TOC keyword, and in the end I gave up and didn't find it until right now.) I'm not making myself sound smart here, but the point is that I will be happy when we get the documentation migrated over. In the meantime, if we could add some prominent links to the sitemap, index, and Worg index.html, that would have helped me a lot, and maybe others. Best regards, Terry -- T.F. Torrey
[O] [new exporter] [html] Tables of Contents
Hello, The new exporter currently puts the generated Table of Contents at the beginning of the exported document in addition to the location of #+TOC: headlines. I don't think it should insert it at the beginning when it is called later. However, I think the new exporter introduces disparities in the output options that give us a chance to do something better. In the new exporter, the type of generated Table of Contents depends on two different configurations: 1. In the #+OPTIONS line, the toc: option determines whether to include a TOC at the beginning, and how many levels /any/ TOC's should have. 2. The keyword #+TOC: can also be used to insert a generated TOC at a specific location in the document. This keyword allows options of headlines, images, and listings, but it has no provision for levels. Currently, using the OPTION toc:nil suppresses a default TOC. Later on, the #+TOC keyword is still recognized and acted upon, which I think is the correct behavior, but then it includes all levels in the generated TOC, because there no way to tell it otherwise. IMHO, the #+OPTIONS line toc: option is unnecessary. However, if used, it should only provide the document default options for generated TOC's. Instead, the #+TOC keyword should be changed to support the plist structure that has been adopted elsewhere. Thus, an example might be: #+TOC: :type headlines :levels 2 Other options might be included, too, such as the option to suppress dates or TODO states as Carsten requested, or perhaps even user-supplied options, something like this: #+TOC: :type headlines :levels 2 :dates nil :todo nil :title nil :extra-function my-custom-toc-headline-processor (In this example, the :title property means the Table of Contents at the top of the TOC, not the title of the headline.) I don't know how the current options (or these I've proposed) could be designated in the OPTIONS line. If we dropped support for the toc: option in the OPTIONS line, people would have to insert the #+TOC: keyword with its options where they wanted it. Would that be so bad? I was going to post a bug report saying that the initial generated TOC should not be included if there was a following #+TOC line, but then I couldn't answer what to do if the later TOC was only images or listings. My proposal eliminates this problem. All the best, Terry -- T.F. Torrey
Re: [O] Frustrated user of orgmode
Hello Suvayu, Suvayu Ali fatkasuvayu+li...@gmail.com writes: On Mon, Mar 04, 2013 at 11:42:24AM -0700, T.F. Torrey wrote: I'm not making myself sound smart here, but the point is that I will be happy when we get the documentation migrated over. FWIW, Worg (and Org) is a volunteer effort. That particular FAQ entry started with me putting up a rather sparse 5 or so item list sometime back. Later it was brought to the current level of detail by Bastien and others. My point is, the easiest way to improve documentation is to add it yourself[1] when you hit on something new. Please don't take my note as a complaint, it was intended only as a sympathetic groan. I well understand that Org is all-volunteer effort, and I have the deepest appreciation for and admiration of all involved. Emacs and Org have transformed my life! All the same ... when I'm working on something at three in the morning, and I *know* I saw (and saved) a bit of information, and the sitemap and the index and even Google just shrug their shoulders I would have been happy to add publicity for the information myself, if I could have just found it! If you do not know how to add to Worg take a look here: http://orgmode.org/worg/#sec-4 I have not yet sent my public key to Bastien to become a Worg contributor, but I expect to soon. If getting that to work is a problem, post on the list with the text and someone else will add it. I'm pretty sure that's a given. :-) Cheers, PS: I updated the index for that entry. Let me know if this is better. Hmm. I don't see it on the website, but it probably just hasn't been rebuilt yet, and I don't know where you might have added the index entry. In the most recent pull from Worg, however, I see that Bastien has started an Org-8.0 document. That will be a big help. Footnotes: [1] Here by you I do not mean specifically you Terry, just a place holder for any Org user. Thanks to you and everyone for your contributions. All the best, Terry -- T.F. Torrey
Re: [O] Frustrated user of orgmode
Hello Bastien, Bastien b...@altern.org writes: Hi Terry, tftor...@tftorrey.com (T.F. Torrey) writes: (I was looking for the syntax for the new #+TOC keyword, and in the end I gave up and didn't find it until right now.) This is in the manual. If you are using Org from master, just ~$ make doc and read the info/pdf page. The section is entitled Table of contents. Of course! I actually have that so it updates automatically in my machine, but I assumed the changes had not been documented yet. Thanks for the tip. In the meantime, if we could add some prominent links to the sitemap, index, and Worg index.html, that would have helped me a lot, and maybe others. I have migrated the migration instructions and tips here: http://orgmode.org/worg/org-8.0.html This is looking good. Let's update this page as much as we can. I hope and expect to soon. Thanks! Many thanks to you, Terry -- T.F. Torrey
Re: [O] [new exporter] [html] Tables of Contents
Hello Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Hello, tftor...@tftorrey.com (T.F. Torrey) writes: The new exporter currently puts the generated Table of Contents at the beginning of the exported document in addition to the location of #+TOC: headlines. I don't think it should insert it at the beginning when it is called later. I think it should. There's no reason for it to go against user's will, is there? With the old exporter, the OPTIONS toc: option controlled whether a TOC was generated at all. With toc:2 (for instance), if you had [TABLE-OF-CONTENTS] somewhere in the document, it would put the TOC there *instead* of at the top. I favor the new behavior. IIUC, your response means that what I proposed is already, mostly, the way things are intended: that the OPTIONS: toc: directive already only applies to the default settings and the TOC at the top. One small problem, though: I see that if there is a TOC at the top and then one included later using #+TOC, the exporter gives them both the same id (div id=table-of-contents). Duplicate ID's makes the XML invalid. However, I think the new exporter introduces disparities in the output [... 10 lines omitted ...] headlines, images, and listings, but it has no provision for levels. Of course it has: #+TOC: headlines 2 It is documented in the manual. I didn't realize that this had been updated. Thanks for the info. [... 15 lines omitted ...] Instead, the #+TOC keyword should be changed to support the plist structure that has been adopted elsewhere. Thus, an example might be: #+TOC: :type headlines :levels 2 Indeed. I have to change this. But I need to modify the parser for such attributes first. I'm sure there is no hurry. Other options might be included, too, such as the option to suppress dates or TODO states as Carsten requested, or perhaps even user-supplied options, something like this: #+TOC: :type headlines :levels 2 :dates nil :todo nil :title nil :extra-function my-custom-toc-headline-processor (In this example, the :title property means the Table of Contents at the top of the TOC, not the title of the headline.) Interesting. But that's some additional work for back-end developers. They could ignore what they can't or don't want to use, of course. I don't know how the current options (or these I've proposed) could be designated in the OPTIONS line. Some defcustom could be used. But we're not there yet. This approach seems obtuse and perhaps over-engineered to me, but I'll let it go. The new TOC design solves a thorny problem I had with the old exporter. Thanks a lot! Best regards, Terry -- T.F. Torrey
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
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] Bug: New HTML exporter incorrect attributes
Hello, First, as always, thanks for the prompt reply. Nicolas Goaziou n.goaz...@gmail.com writes: Hello, tftor...@tftorrey.com (T.F. Torrey) writes: Where attributes have been assigned to an image in a paragraph, the new exporter applies those attributes to both the image and a following link. 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. 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. As a consequence, attributes will be assigned to every link within the paragraph. Is this behavior helpful to anyone in any practical circumstances? Moreover, this means that, not only does the new exporter fail where the old one succeeded, the new one produces invalid HTML (anchors with invalid attributes) in the use case I described (ATTR_HTML to apply to an image beginning a paragraph which later has a link in it, which happens several times in almost all my documents). It seems to me that, whether the user is happy with the output or not, the HTML exporter ought to produce valid HTML. A hack could be implemented in ox-html.el so only image links get these attributes, but it would be the same with multiple images within the same paragraph. Again, I can't think of a practical situation where this would be helpful. If all the images and/or links had the same styling, simple CSS would suffice, and there would be no need for the ATTR_HTML. In my case, however, this would actually work. I know that it is possible to style links using ATTR_HTML, but does anyone actually do that in practice? I don't think I ever have. If no one uses it, would it be missed? A proper solution to the problem would be to slightly change link syntax. The link syntax change will be a welcome addition, though I understand that it is not a high priority. Until then, you'll have to use workarounds (like, for example, writing the other link in raw HTML syntax within an export snippet). Yes, a personal workaround would be to use the raw HTML syntax to mark the image in my example. This has the strong disadvantage, however, of meaning the image doesn't appear at all when the document is exported to other formats, and of requiring changes to all affected documents when the syntax changes again. 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 images for other export formats. Of course, anyone relying on the ATTR_HTML to set attributes for every image and/or link in a paragraph would have to adopt a different workaround, but ... does anyone really do this? In my case, rather than changing all my documents to use raw HTML for the images, I will write a filter function that walks through the final HTML and removes invalid and superfluous attributes from the anchor tags. This strikes me as a rather ugly hack, though. It seems unlikely to me that this issue only comes up with the HTML exporter. Surely some documents with primary output formats of LaTeX or OpenDocument have similar requirements. I wonder how those export backends handle situations like this. Thanks again for your help and hard work. Best regards, Terry -- T.F. Torrey
[O] Bug: New HTML exporter incorrect attributes
Hello, Where attributes have been assigned to an image in a paragraph, the new exporter applies those attributes to both the image and a following link. For example, this: #+BEGIN_SRC org #+ATTR_HTML: width=10 alt= [Cool thing] [[file:cool_thing.jpg]] Cool thing found here [[http://example.com/][example.com]]. #+END_SRC is exported to this: #+BEGIN_HTML p img src=cool_thing.jpg width=10 alt= [Cool thing] / Cool thing found here a href=http://example.com/; width=10 alt= [Cool thing] example.com/a. /p #+END_HTML Emacs : GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0) of 2012-12-24 on menkib, modified by Debian Package: Org-mode version 7.9.3e (7.9.3e-1173-g14df16 @ /home/tftorrey/.emacs.d/elisp/org/lisp/) Best regards, Terry -- T.F. Torrey
[O] FIXME lines in ox-html.el
Hello list, There are about 25 lines of what looks like function or filter names under the heading of FIXME in ox-html.el. Does anyone know if these are features handled by the old exporter but not yet by the new one, goals for new functionality, or something else? Do these need to be resolved before the new exporter can reliably replace the old one? Best regards, Terry -- T.F. Torrey
Re: [O] BIND org-html-style-include-*
Hello, Nicolas Goaziou n.goaz...@gmail.com writes: tftor...@tftorrey.com (T.F. Torrey) writes: Now, I have these: #+BIND: org-html-style-include-default nil #+BIND: org-html-style-include-scripts nil But they seem to be silently ignored, though if I setq the values ahead of time, the output is suppressed. Can these still be set using BIND? If so, what am I doing wrong? What is the value of `org-export-allow-bind-keywords'? Aha! That's the one I was looking for. Thanks. Also, the value of org-html-mathjax-template seems to be output now by default, and I don't remember seeing it before. Is this an intended change? If so, how can it be suppressed? (If not ... ???) I cannot answer you for now, because I don't know enough of the HTML back-end. I still don't see any similar options regarding MathJax. Perhaps everyone else uses MathJax, or the functionality simply hasn't been implemented yet. If only the HTML export backend maintainer were still on the list... Best regards, Terry -- T.F. Torrey
Re: [O] Macro expansion in new exporter
Hello Nicolas, Thank your for your thoughtful reply. Nicolas Goaziou n.goaz...@gmail.com writes: tftor...@tftorrey.com (T.F. Torrey) writes: 1. You wrote before that macros were scaled back because what they did could be done by babel. Is that really a good reason for removing functionality? Everything that Org does could be done in other tools, and yet ... we have Org. Macros were scaled down because the parser has to be able to know when it looks at one of them. This limits the places where a macro can be found. For example, it doesn't make much sense to expect a macro to be found in an example block. But scaling down macros made some of its features disappear. Since Babel code could provide them anyway, it generated no real regression. Perhaps. We still know of no easy/straightforward way at all to replicate using babel the behavior I had (creating 'p class=foobar/p' with a macro), let alone in a pair of single lines. To sum it up, they were not downgraded because of Babel, but if Babel hadn't been there, this wouldn't have happened. 2. You wrote to Carsten that macros could no longer contain newlines. That seems like an arbitrary limitation. Is it? In the parser, there's a difference between objects and elements. Distinction is made clear in the comments lines of org-element.el. To put it simply, objects cannot contain blank lines. Thanks for the tip. I've been very impressed with the comments in your code. Great work! Macros are objects. If I allow a newline in a macro, I allow two and therefore a blank line. For example a macro within a paragraph could potentially split it into two paragraphs. In this case, there would be a mismatch between what the user can see in the buffer, and what will happen during export. Babel code already has got this privilege (of breaking structure of the document). During alpha-test phase, bugs were reported because of unanticipated discrepancies between Babel code in original buffer and results in export buffer. Allowing macros to do the same would be asking for more trouble. Macros are so straightforward compared to babel, I wonder how much trouble they /could/ generate. 3. Is there really a reason why macro expansion is limited to a few keywords rather than all? Who would that trip up? Ditto for verbatim and code emphasis. Most keywords are simple key and values couples. The parser mustn't look into the values, as it may find constructs that do not exist. On the other hand some selected keywords have to be parsed, because their value is really Org data. They are defined in org-element.el. See `org-element-document-properties' and `org-element-parsed-keywords' for an exhaustive list. Thanks for this valuable tip. Verbatim and code emphasis contents are never parsed, by definition. I was reading that wrong. Code emphasis is not emphasis (italics). Sorry for the noise. 4. Given that macro values are easy to find in the source document, and unexpanded macros are easy to find in the output document, couldn't I just add a filter to the exporter to find and expand any unexpanded macros (and lingering newline indicators)? Is there an easy method for adding such a filter? It may be possible, although very hackish. Functions in filters are, at I have a lot of code that could be described as hackish, at best. I don't mind because producing beautiful code is pretty far down on my list of goals. I suspect, though, it would make you either laugh or feel nauseous, probably both. the moment, called from the export buffer. So you can probably read macro definitions there. I think a proper filter to use for that would be `org-export-filter-final-output-functions'. That's one I'm familiar with. Thanks. I still strongly suggest to use Babel instead. I wonder if an entry in the (underused) Library of Babel could replicate the macro functionality and eliminate the need for macros as separate things. I will have to look into that when I have more time. 5. Actually, why do macros need to be an exporter problem at all? Couldn't the macro functionality be put into a separate package that used hooks and filters to connect itself into the export routine and the various back-ends (if even necessary)? Then macros could be made to do interesting things without burdening the export engine (and its maintainer) at all. Macros are an exporter problem, albeit a limited one, because their expansion happens during the export process. Also, some macros are very export oriented and have to be handled at the export framework level (e.g. {{{author}}}). Though, an export back-end actually never sees any macro, as these are expanded before its translator functions are called. I'm pretty sure I could replicate (and even expand) the old macro functionality by hooking an expansion function into org-export-before-parsing-hook. Maybe I will write an extension to try. Most of the macro code lives in org.el
[O] Dynamic blocks in the new exporter
Hello again, Does the new export framework impose new restrictions on or change the functionality of dynamic blocks? Best regards, Terry -- T.F. Torrey
Re: [O] BIND org-html-style-include-*
Hello, Nicolas Goaziou n.goaz...@gmail.com writes: tftor...@tftorrey.com (T.F. Torrey) writes: I still don't see any similar options regarding MathJax. Perhaps everyone else uses MathJax, or the functionality simply hasn't been implemented yet. If only the HTML export backend maintainer were still on the list... Would you mind describing what is missing? It shouldn't be hard to implement it. By default, the HTML export engine includes some CSS for basic presentation, some JavaScript for interacting with code in the HTML, and some JavaScript for the MathJax functionality (among many other things, of course). The CSS can be not included by setting org-html-style-include-default to nil. The non-MathJax JavaScript can be not included by setting org-html-style-include-scripts to nil. However, the new HTML exporter includes the MathJax JavaScript every time, and I don't see any variable to set to suppress it. The old exporter did not export it. IIRC, it was off by default, and there was a setting to turn it on (don't quote me, I never used it). Recent posts by Bastien suggest that maybe it is supposed to be included only if LaTeX is used in the buffer, but I'm not sure he was talking about this issue. With the new exporter on my Org, even the most minimal Org file exported to HTML includes MathJax. My Org version is 7.9.3e-1032-g791a8d. The most recent pulls fail testing (which people must already know). (By the way, though it may be too late to change them now, the variables would be better named org-html-include-style-default and org-html-include-scripts-default and possibly org-html-include-scripts-mathjax. The HTML exporter has many things that might be included in the output, and having the variables all starting with org-html-include- would make them easier for everyone to find, understand, and modify.) (Similarly, as someone else wrote, #+HTML_STYLE would be much better named #+HTML_HEAD, given that style is just one of the many things this directive might put into the head element of the html.) All the best, Terry -- T.F. Torrey
Re: [O] Dynamic blocks in the new exporter
Hello Seb, Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hello T.F., T.F. Torrey wrote: Does the new export framework impose new restrictions on or change the functionality of dynamic blocks? I've used them quite extensively today. Did not notice anything wrong. What are you trying to tell us? I was merely inquiring to understand my options. Before the new exporter, I converted my more complex macros to dynamic blocks. They are very handy, and I'm already familiar with implementing them. Now I'm deciding the best way to replace macros that no longer work. I didn't want to begin porting macros to dynamic blocks only to find out that they had also been pared down in favor of babel. Thanks for the prompt reply. Best regards, Terry -- T.F. Torrey
Re: [O] Macro expansion in new exporter
Nicolas Goaziou n.goaz...@gmail.com writes: tftor...@tftorrey.com (T.F. Torrey) writes: This almost works, I think ... #+name: snippet-awesome #+begin_src org :exports results :results raw Snippet of awesome text that changes sometimes. #+end_src #+HTML: p class=foo #+CALL: snippet-awesome :results raw #+HTML: /p ... except that it doesn't actually export anything, and changing :exports to none doesn't help. And neither does removing the :results raw from the call. Wild guess: did you activate org in your Babel languages? Doh! And that was one of the things I checked, too. Now it works, but it isn't a solution because the CALL is wrapped in its own p. I'll figure something out. Thanks again. T. -- T.F. Torrey
Re: [O] BIND org-html-style-include-*
Hello, Bastien b...@altern.org writes: Hi Terry, tftor...@tftorrey.com (T.F. Torrey) writes: However, the new HTML exporter includes the MathJax JavaScript every time, and I don't see any variable to set to suppress it. This is not the case anymore since commit 4d7f4d87. Yes. Thank you for the fix. Recent posts by Bastien suggest that maybe it is supposed to be included only if LaTeX is used in the buffer, but I'm not sure he was talking about this issue. I hope I was -- the MathJax config will now be included if your HTML page contains LaTeX snippets to display. It will not be included otherwise. With the new exporter on my Org, even the most minimal Org file exported to HTML includes MathJax. My Org version is 7.9.3e-1032-g791a8d. The most recent pulls fail testing (which people must already know). You are behind a few commits, please update. make up2 reports these failures (and thus does not install): 6 unexpected results: FAILED test-org-babel/inline-src_blk-default-results-replace-line-1 FAILED test-org-babel/inline-src_blk-results-file FAILED test-org-babel/inline-src_blk-results-raw FAILED test-org-babel/inline-src_blk-results-scalar FAILED test-org-babel/inline-src_blk-results-silent FAILED test-org-babel/inline-src_blk-results-verbatim I was reluctant to run make update when the tests failed, but I did anyway for the rest of this. (By the way, though it may be too late to change them now, the variables would be better named org-html-include-style-default and org-html-include-scripts-default and possibly org-html-include-scripts-mathjax. The HTML exporter has many things that might be included in the output, and having the variables all starting with org-html-include- would make them easier for everyone to find, understand, and modify.) I somewhat agree. But C-h v org-html-include TAB expands and display all variables here, so maybe not such an issue. It is not too late to change the names of the variables, but I'd rather stick to these names because it lowers the effort when switching from 7.9 to 8.0. Yes, typing C-h v org-html-include finds these variables: org-html-style-include-default org-html-style-include-scripts It bothers me that the second one is misnamed. It has nothing to do with style. Even for just these two, starting with org-html-include (that is, org-html-include-style and org-html-include-script --- they should probably both be singular or plural) would be an improvement, and who knows what future development brings? These variables are already changing (from org-export-html-style-*) for 8.0. Now is a good time to DTRT. (Similarly, as someone else wrote, #+HTML_STYLE would be much better named #+HTML_HEAD, given that style is just one of the many things this directive might put into the head element of the html.) For this one I agree completely. I will make this change. All the people who just changed their files from #+STYLE to #+HTML_STYLE will curse us, or you anyway, but it would make me happy (the change, not them cursing you). Thank you for your time and attention. Best regards, Terry -- T.F. Torrey
Re: [O] Macro expansion in new exporter
Hello again, Like many others, I'm adapting my workflow to the new exporter. Like Carsten (but apparently few others), I've been using macros extensively. Though I've spent several days digging through the mailing list and code, I still don't have the answers I need, but hopefully I can ask intelligent questions. Nicolas Goaziou n.goaz...@gmail.com writes: On that topic, the main difference with the previous exporter is that macros are now required to be in a context that can be parsed. Thus, for example, the following is not a macro: ~{{{title}}}~ What is meant by a context that can be parsed? In my work, it has been very useful to use macros for snippets of text. Then, instead of changing the text everywhere when I want a change, I would just change the macro. So... For instance, I used to be able to do this: #+MACRO: status Draft #+HTML: p class=status{{{status}}}/p And on export to HTML, I would get what you would expect: p class=statusDraft/p With the new exporter, the macro is left unexpanded in the output: p class=status{{{status}}}/p Of course, I could also put the {{{status}}} in any ordinary text and have it there as well. In extensive experiments, I have not found any combination of input that would produce the old output using macros. The old behavior had an elegant, one-line solution. Perhaps the functionality could be duplicated with babel, but surely not as simply and directly as with the old macro system. Is there a way to replicate the old behavior in the new export engine? Also, in your response to Carsten's question about macros, you suggested this: #+MACRO: thumbright @@html:img src=./Content/$2/thumb.jpg style=float:right;width:$1;margin:0px 20px 0px 20px; alt=./Content/$2/thumb.jpg /@@ The @@ syntax looks new to me. Can you tell me what the function of the @@ is? Is this documented somewhere? Best regards, Terry -- T.F. Torrey
[O] BIND org-html-style-include-*
Hello, In my files, this used to work to suppress the default styles and javascript: #+BIND: org-export-html-style-include-default nil #+BIND: org-export-html-style-include-scripts nil Now, I have these: #+BIND: org-html-style-include-default nil #+BIND: org-html-style-include-scripts nil But they seem to be silently ignored, though if I setq the values ahead of time, the output is suppressed. Can these still be set using BIND? If so, what am I doing wrong? Also, the value of org-html-mathjax-template seems to be output now by default, and I don't remember seeing it before. Is this an intended change? If so, how can it be suppressed? (If not ... ???) Emacs: GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0) of 2012-12-24 on menkib, modified by Debian Package: Org-mode version 7.9.3e (7.9.3e-970-g728c0e @ /home/tftorrey/.emacs.d/elisp/org/lisp/) Best regards, Terry -- T.F. Torrey
Re: [O] Macro expansion in new exporter
Hello Nicolas, Thank you for your thoughtful clarification about macros in the new exporter. Probably in the long run I will find happiness using babel for what I want to do. In the meantime, however, I have a few more questions: 1. You wrote before that macros were scaled back because what they did could be done by babel. Is that really a good reason for removing functionality? Everything that Org does could be done in other tools, and yet ... we have Org. 2. You wrote to Carsten that macros could no longer contain newlines. That seems like an arbitrary limitation. Is it? 3. Is there really a reason why macro expansion is limited to a few keywords rather than all? Who would that trip up? Ditto for verbatim and code emphasis. 4. Given that macro values are easy to find in the source document, and unexpanded macros are easy to find in the output document, couldn't I just add a filter to the exporter to find and expand any unexpanded macros (and lingering newline indicators)? Is there an easy method for adding such a filter? 5. Actually, why do macros need to be an exporter problem at all? Couldn't the macro functionality be put into a separate package that used hooks and filters to connect itself into the export routine and the various back-ends (if even necessary)? Then macros could be made to do interesting things without burdening the export engine (and its maintainer) at all. Thanks again for your amazing work. Best regards, Terry -- T.F. Torrey
[O] Macro expansion in new exporter
Hello all, I really like the new exporter, and I appreciate the hard work of everyone involved. Right now, though, it's giving me a small problem: in the export to HTML, macro's are not expanded, so I have {{{title}}}, for instance, in the HTML output. I haven't been following the list as closely as I'd like, so I'm hoping I missed something relevant in the changeover. If anyone has any ideas, I'd appreciate them before I go digging. Emacs : GNU Emacs 24.3.50.1 (i686-pc-linux-gnu, GTK+ Version 3.6.0) of 2012-12-24 on menkib, modified by Debian Package: Org-mode version 7.9.2+ (7.9.2+-GNU-Emacs-24-3 (commit 488eea) @ mixed installation! /usr/share/emacs/24.3.50/lisp/org/ and /home/tftorrey/.emacs.d/elisp/org/lisp/) Terry -- T.F. Torrey
Re: [O] Problem with org-clock-persistence-insinuate in org-plus-contrib
That's curious. Achim Gratz writes: Actually, you will need to customize that variable if you want to use ditaa. But the error is that ob-ditaa is missing a (require 'org-compat), I've pushed a fix for that. But you may still do your own customizations for Org too early, you should defer them to after package-initialize has run. First, thanks so much for your help. My whole life is in Emacs and Org. My initial report should be amended, because after a few cycles, the error came back even with org-clock-persistence-insinuate commented out. I did not run and save a backtrace of that. I don't use ditaa at all, and I have no mention of it in my init file. Something else must have been pretty far off the rails to be calling it. Finally, the only things before package-initialize in my init file were some general Emacs interface settings (tool bar off, some others, I can post a list if anyone is interested). Nothing org related was before it. Nonetheless, when I move package-initialize to be the first thing in the init file, the problem goes away. Thanks again for your help. Best regards, Terry -- T.F. Torrey
[O] Problem with org-clock-persistence-insinuate in org-plus-contrib
nil) file-name-directory(nil) (expand-file-name ../contrib (file-name-directory (or load-file-name buffer-file-name))) (file-name-as-directory (expand-file-name ../contrib (file-name-directory (or load-file-name buffer-file-name (expand-file-name scripts (file-name-as-directory (expand-file-name ../contrib (file-name-directory (or load-file-name buffer-file-name) (file-name-as-directory (expand-file-name scripts (file-name-as-directory (expand-file-name ../contrib (file-name-directory (or load-file-name buffer-file-name)) (expand-file-name ditaa.jar (file-name-as-directory (expand-file-name scripts (file-name-as-directory (expand-file-name ../contrib (file-name-directory (or load-file-name buffer-file-name))) eval((expand-file-name ditaa.jar (file-name-as-directory (expand-file-name scripts (file-name-as-directory (expand-file-name ../contrib (file-name-directory (or load-file-name buffer-file-name #[(v) \302!\205;\303\304\305!\\205;J\203 \303\306\305!\\2046\307N\205;\310N\205;J\311\310N@!\232?\205; B\211\207 [v list boundp string-match \\`\\(org-\\|outline-\\) symbol-name \\(-hook\\|-function\\)\\' custom-type standard-value eval] 4](org-ditaa-jar-path) mapatoms(#[(v) \302!\205;\303\304\305!\\205;J\203 \303\306\305!\\2046\307N\205;\310N\205;J\311\310N@!\232?\205; B\211\207 [v list boundp string-match \\`\\(org-\\|outline-\\) symbol-name \\(-hook\\|-function\\)\\' custom-type standard-value eval] 4]) org-submit-bug-report() call-interactively(org-submit-bug-report record nil) command-execute(org-submit-bug-report record) execute-extended-command(nil org-submit-bug-report) call-interactively(execute-extended-command nil nil) #+END_QUOTE Best regards, Terry -- T.F. Torrey
[O] Bug: Bad timestamp 'habit'
Hello, I am currently unable to produce an agenda from my files. This bug crept in somewhere in the last few days, but I'm not sure exactly when. This habit timestamp: SCHEDULED: 2012-08-08 Wed .+1d Produces this error: condition-case: Bad timestamp `habit' at 210773 in buffer `Writing.org' Error was: (Not a standard Org-mode time string: habit) It works if I use the min/max format (2012-08-08 Wed .+1d/2d), but I don't want to do that, and according to the manual, that isn't required. Also, in this bug report data, I wonder why org-loaddefs.el can not be found. I run the org from a git repo, not compiled. Emacs : GNU Emacs 24.2.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2) of 2012-09-28 on louvi, modified by Debian Package: Org-mode version 7.9.2 (release_7.9.2-383-g09d6bc-git @ org-loaddefs.el can not be found!) If no one else sees this, I'll dig through my files to see what's broken, but I see lots of work has been done to the agenda creator recently, and maybe this is a new problem and an easy fix. Best, Terry -- T.F. Torrey
[O] [PATCH] Fix for relative symlinks in subdirectories
Hello all, When publishing a project that contains relative symlinks in subdirectories, org-publish-cache-ctime-of-src mistakenly connects the true file name with the base-dir of the project instead of the symlink, causing an error when the linked file is in a subdirectory and not the base-dir. The attached patch modifiies org-publish-cache-ctime-of-src to use the dir of the current file as the base-dir instead of simply the project base-dir. With this change, though, the base-dir argument to this function now never does anything. This doesn't seem to cause problems for me, but I am far from intimate with the workings of the org-publish cache system. Perhaps someone with better knowledge of the system could provide a better fix. Otherwise, the base-dir argument could be refactored out. ChangeLog entry: Fix for relative symlinks in subdirectories Modify org-publish-cache-ctime-of-src to use the dir of the current file as the base-dir instead of simply the project base-dir. TINYCHANGE Emacs : GNU Emacs 24.2.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2) of 2012-08-29 on nannyberry, modified by Debian Package: Org-mode version 7.9 (release_7.9-190-g845daf.dirty-git @ mixed installation! /usr/local/share/emacs/site-lisp/ and /home/tftorrey/.emacs.d/src/org-mode/lisp/) Best regards, Terry -- T.F. Torrey diff --git a/lisp/org-publish.el b/lisp/org-publish.el index e78e2d4..cd77c82 100644 --- a/lisp/org-publish.el +++ b/lisp/org-publish.el @@ -1191,7 +1191,7 @@ Returns value on success, else nil. (defun org-publish-cache-ctime-of-src (f base-dir) Get the FILENAME ctime as an integer. (let ((attr (file-attributes - (expand-file-name (or (file-symlink-p f) f) base-dir + (expand-file-name (or (file-symlink-p f) f) (file-name-directory f) (+ (lsh (car (nth 5 attr)) 16) (cadr (nth 5 attr)
[O] [PATCH] Works around bug in exporting subtree with HTML_CONTAINER_CLASS
Hello all, When exporting a subtree with an HTML_CONTAINER_CLASS property set, exporting fails with this error: (error Before first headline at position 455 in buffer *temp*) This happens because the system is trying to apply the class to the parent level, but the exporting of a subtree doesn't bring the parent level into the temp buffer. The attached patch modifies org-export-remember-html-container-classes to ignore the HTML_CONTAINER_CLASS property altogether in these cases. It would probably be better to apply the designated class to the container div or perhaps the body, but this change works for me, and I may be the only one bothered by this. If it is determined that another fix is more in the spirit of these files, I will not be offended. ChangeLog entry: Fix export of subtree with HTML_CONTAINER_CLASS Modify org-export-remember-html-container-classes to work around problem when exporting subtree with HTML_CONTAINER_CLASS property. TINYCHANGE All the best, Terry -- T.F. Torrey diff --git a/lisp/org-exp.el b/lisp/org-exp.el index c901a88..875bdf8 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -1476,8 +1476,11 @@ the current file. ^[ \t]*:HTML_CONTAINER_CLASS:[ \t]+\\(.+\\)$ nil t) (setq class (match-string 1)) (save-excursion + (if (re-search-backward ^\\* (point-min) t) + (progn (org-back-to-heading t) (put-text-property (point-at-bol) (point-at-eol) 'html-container-class class) +)) (defvar org-export-format-drawer-function nil Function to be called to format the contents of a drawer.
[O] [PATCH] Fixes org-rmail-follow-link
With creating links working in Rmail, now I see that following links fails with the error Message not found. The error comes from the use of the function widen in org-rmail-follow-link. In an RMAIL buffer, the widen function only widens to the current message. The function to widen to the entire buffer is rmail-widen. The attached patch replaces widen with rmail-widen and also removes the following two lines (added by Bastien as part of the previous patch re Rmail), because rmail-widen already displays full headers, so testing and toggling them on has no effect. GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2) of 2012-07-29 on doubah, modified by Debian Org-mode version 7.8.11 (release_7.8.11-392-g9dae6f-git @ mixed installation! /usr/local/share/emacs/site-lisp/ and /home/tftorrey/.emacs.d/src/org-mode/lisp/) Best to all, Terry -- T.F. Torrey diff --git a/lisp/org-rmail.el b/lisp/org-rmail.el index 9148a8e..d28a420 100644 --- a/lisp/org-rmail.el +++ b/lisp/org-rmail.el @@ -101,9 +101,7 @@ (rmail (if (string= folder RMAIL) rmail-file-name folder)) (setq message-number (save-restriction - (widen) - (when (eq rmail-header-style 'normal) - (rmail-toggle-header -1)) + (rmail-widen) (goto-char (point-max)) (if (re-search-backward (concat ^Message-ID:\\s-+ (regexp-quote
Re: [O] [PATCH] Fixes org-rmail-store-link
This is fixed now, thanks. I used a slightly different fix, taking `rmail-header-style' into account. Thanks anyway for the patch! It works for me. Thanks for the quick fix. Although ... -- T.F. Torrey
Re: [O] [PATCH] Fixes org-rmail-store-link
Nick Dokos nicholas.do...@hp.com writes: The attached patch remedies this by toggling on the full header display before getting the Message-ID. Shouldn't it be toggled off afterwards? That would seem logical to me, too, but the internal workings of org-rmail.el and the rmail functions (which I don't fully understand) already always leave the headers toggled off. In the long run, this should probably be changed to respect the state prior to storing the link, but for now, Bastien's patch makes the linking function work. Terry -- T.F. Torrey
[O] [PATCH] Fixes org-rmail-store-link
Hello all, Attempting to save a link in an Rmail buffer fails with the error Wrong type argument: arrayp, nil. Attempting to save a link in an Rmail buffer succeeds if all headers are shown (by pressing T to toggle the display). Attempting to save a link in an Rmail summary buffer always fails with the same error, even if all headers are shown. The error occurs because org-rmail-store-link attempts to get the Message-ID header with mail-fetch-field, then remove the angle brackets with org-remove-angle-brackets. However, without showing full headers, Message-ID is hidden, and (mail-fetch-field message-id) returns nil. When this is passed to org-remove-angle-brackets, the error is thrown. The attached patch remedies this by toggling on the full header display before getting the Message-ID. Emacs : GNU Emacs 24.1.50.1 (i686-pc-linux-gnu, GTK+ Version 3.4.2) of 2012-07-29 on doubah, modified by Debian Package: Org-mode version 7.8.11 (release_7.8.11-360-g7c4ac5-git @ mixed installation! /usr/local/share/emacs/site-lisp/ and /home/tftorrey/.emacs.d/src/org-mode/lisp/) Best to all, Terry -- T.F. Torrey diff --git a/lisp/org-rmail.el b/lisp/org-rmail.el index cb379d3..f8abbf4 100644 --- a/lisp/org-rmail.el +++ b/lisp/org-rmail.el @@ -52,6 +52,7 @@ (rmail-show-message rmail-current-message)) (when (fboundp 'rmail-narrow-to-non-pruned-header) (rmail-narrow-to-non-pruned-header)) + (rmail-toggle-header 0) (let* ((folder buffer-file-name) (message-id (mail-fetch-field message-id)) (from (mail-fetch-field from))
Re: [Orgmode] Minor docstring bug: org-footnote-goto-previous-reference
Date: Sun, 24 Oct 2010 08:57:35 +0530 Subject: Re: [Orgmode] Minor docstring bug: org-footnote-goto-previous-reference From: Noorul Islam noo...@noorul.com To: rpgold...@sift.info X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: Org Mode emacs-orgmode@gnu.org Sender: emacs-orgmode-bounces+tftorrey=tftorrey@gnu.org On Sun, Oct 24, 2010 at 5:00 AM, Robert Goldman rpgold...@sift.info wrote: The docstring for the command org-footnote-goto-previous-reference is Find the next previous of the footnote with label LABEL. ...which I can't actually parse. Find the (immediately) previous reference to the footnote with label LABEL. Is that better? Patch is attached. I modified it a bit. Noorul, Actually, your modification makes it grammatically incorrect. The word immediately is to modify the adjective previous, and in English, an adjective needs to be modified by an adverb. So, immediately previous would be correct, but immediate previous is not. Trying to be helpful, not merely nit-picking, Terry Fix doc string * lisp/org-footnote.el (org-footnote-goto-previous-reference): Fix doc string Proposed by Robert Goldman rpgold...@sift.info Thanks and Regards Noorul ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] arranging and publishing music with Org-mode and lilypond
Hello, From: Stefan Vollmar voll...@nf.mpg.de Date: Sun, 03 Oct 2010 00:26:39 +0200 To: emacs org-mode mailing list emacs-orgmode@gnu.org X-Mailer: Apple Mail (2.1081) X-detected-operating-system: by eggs.gnu.org: Solaris 9 Subject: [Orgmode] arranging and publishing music with Org-mode and lilypond Sender: emacs-orgmode-bounces+tftorrey=tftorrey@gnu.org Dear all, I believe that many members of this list with an interest in music (notation/composition) might find the http://lilypond.org project addictive (in the nicest possible manner): the concept is rather similar to writing TeX, there is very good Emacs support (if you know where to look), it is all OpenSource, there is extensive documentation (in LaTeX format with embedded lilypond snippets), the print quality is excellent. I mention this because while arranging some piece of music recently, I noticed that Org-mode might be helpful in this context - it is probably already possible by tweaking org-babel a bit: lilypond encourages the user to structure music in a way that lends itself rather naturally to processing with Org-mode - you can assign a theme, a few bar with notes or even whole voices to variables and use them repeatedly. And imagine using Org-mode's outline capabilities to structure a piece of music. Exporting an org-file with lilypond-snippets in it to PDF or HTML might also be an interesting option. I have not yet put any effort into it and just wanted to find out if anybody apart from me finds the combination of Org-mode and lilypond (potentially) exciting. I think this is very exciting. Best regards, Terry Warm regards, Stefan -- Dr. Stefan Vollmar, Dipl.-Phys. Head of IT group Max-Planck-Institut für neurologische Forschung Gleuelerstr. 50, 50931 Köln, Germany Tel.: +49-221-4726-213 FAX +49-221-4726-298 Tel.: +49-221-478-5713 Mobile: 0160-93874279 Email: voll...@nf.mpg.de http://www.nf.mpg.de ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: Question: Repeating Items?
I had a similar problem with duplicate agenda entries. After much aggravation, I discovered I had a duplicate entry for the file in the setq org-agenda-files section of my .emacs file. Could the new machine have multiple sections adding entries to org-agenda-files? Does the value of that variable show duplicates? -- T. From: Matt Lundin m...@imapmail.org To: Kenneth Miller kenn...@erdosmiller.com Date: Thu, 16 Sep 2010 11:33:48 -0400 User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. Cc: emacs-orgmode@gnu.org Subject: [Orgmode] Re: Question: Repeating Items? Sender: emacs-orgmode-bounces+tftorrey=tftorrey@gnu.org Hi Ken, Kenneth Miller kenn...@erdosmiller.com writes: I fired up org-mode on my new machine, pulled my org files from source control, set my agenda files and agenda-key, attempted to view my agenda, and got the following. I've replaced some of the names with random characters for privacy, but events and todos are repeating themselves over and over and I can't seem to figure out why. I've never encountered this problem. Could you please provide a test case org file (along with the relevant portions of your .emacs)? Also, could you please report what version of org-mode you are using (M-x org-version). Best, Matt Example: Tuesday 14 September 2010 em: Sched.11x: TODO Schedule Detectachem Monthly Review em: Sched.11x: TODO Detectachem Monthly Documentation em: Sched.11x: TODO Detectachem Monthly Billing em: Sched.11x: TODO Schedule Detectachem Monthly Review em: Sched.11x: TODO Detectachem Monthly Documentation em: Sched.11x: TODO Detectachem Monthly Billing em: Sched.11x: TODO Schedule Detectachem Monthly Review em: Sched.11x: TODO Detectachem Monthly Documentation em: Sched.11x: TODO Detectachem Monthly Billing em: Sched.11x: TODO Schedule Detectachem Monthly Review em: Sched.11x: TODO Detectachem Monthly Documentation em: Sched.11x: TODO Detectachem Monthly Billing em: Sched.11x: TODO Schedule Detectachem Monthly Review em: Sched.11x: TODO Detectachem Monthly Documentation em: Sched.11x: TODO Detectachem Monthly Billing em: Sched.10x: TODO Payroll em: Sched.10x: TODO Payroll em: Sched.10x: TODO Payroll em: Sched.10x: TODO Payroll em: Sched.10x: TODO Payroll pipe: In -31 d.: TODO Research wireless security for credit card transactions. pipe: In -31 d.: TODO Research wireless security for credit card transactions. pipe: In -31 d.: TODO Research wireless security for credit card transactions. pipe: In -31 d.: TODO Research wireless security for credit card transactions. pipe: In -31 d.: TODO Research wireless security for credit card transactions. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [ANN] Org to Atom, revisited
On 06/18/2010 09:03 AM, David Maus wrote: Olivier Schwander wrote: [here]: http://ictsoc.de/code/org-atom/example.atom Is there the source of this feed somewhere ? It would be nice to have a self sufficient example. I've uploaded the source of the example feed to http://ictsoc.de/code/org-atom/example.org But it's really as straightforward as the simple example in the documentation. * Download and installation Maybe it would be useful to have the emacs lisp fragment users need to put in their .emacs file ? And add this part to the Download and install section of the online manual. I'll put more detailed install instructions there as soon as there is a decision about including org-atom into Org or not (yet). 1.2 Headline properties A headline that matches the TAGS/PROP/TODO query for feed entries requires at least two headline properties to be present: The =ID= property with a unique identifier of the headline (preferable a UUID) and a property called =atom_published= containing a time stamp with the date an entry should be considered to be published. If these two properties are not present, they are automatically created using Org's default method to create ID properties[2] and current time and date for the publishing date[3] Maybe it should be better to extract timestamp from the usual timestamp below headlines, like this one: * Some title [2010-06-16 mer. 14:19] or * DONE Some title CLOSED: [2010-06-16 mer. 14:19] Actually, with this solution, it would be better to remove the timestamp used from the export, since it will displayed by the reader. The problem is, that the Atom specification requires an entry to have at least a atom:updated element. Thus there must be timestamp somewhere. Binding the timestamp to a special position in Org mode markup would limit the functionality of the exporter. However: I understand that it could be reasonable to not use a property, but an already present timestamp. What about something like this: The name of the published and updated property can be customized. It can either be a string with the property name or the symbol 'timestamp_ia. If it is this symbol, the exporter uses the first inactive timestamp of a headline. If the headline does not have an inactive timestamp, the exporter throws an error. This would be a welcome addition. I would use it, and perhaps it would entice RMS to adopt Org Mode as well. It's pretty close to what he uses for his political notes: http://www.stallman.org/archives/2010-mar-jun.html 1.3 Export settings content: turn on/off publishing content When content is t, the headline is exported both in title and in content, is this a feature or a bug ? If it's a feature, it should be nice to have an option to disable it. Hah! Good catch. Never paid attention to this. Just pushed a commit that removes the title in the content element. Thanks for the comment and suggestions. -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode Org Mode gets better all the time. Thanks again. - Terry ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] [ANN] Org to Atom, revisited
David, This is really great work, and I'm excited about using it for my own site. Hopefully this will be included in the official Org mode soon. Thank you for this. - Terry On 06/15/2010 09:51 AM, David Maus wrote: The Org to Atom exporter I've preliminary announce some weeks ago entered a state I consider to be stable and consistent enough to be included into Org mode. It provides export, publishing and a sitemap functions that let you create an Atom feed for a web page project based on (multiple) Org mode files. An example that shows the support of inline images in feed entry content can be found [here]. [here]: http://ictsoc.de/code/org-atom/example.atom * Download and installation The Org to Atom exporter is maintained in a copy of Org mode's git repository in branch org-atom located at git://github.com/dmj/dmj-org-mode.git You can download the most recent version at [http://github.com/dmj/dmj-org-mode/raw/org-atom/lisp/org-atom.el] To use the exporter you need a recent version of atom-syndication.el, an elisp implementation of the Atom Syndication Format. You can get atom-syndication.el from github, too: git://github.com/dmj/atom-syndication.git * Usage Please see the almost complete documentation below or read via web at [http://ictsoc.de/code/org-atom.html] * Backward incompatibility If you have used an older version of the exporter you need to revise your configuration due to incompatible changes. Most notably: - in-buffer options and publishing properties have be (re)renamed to start with #+FEED and :feed instead of #+ATOM and :atom; - support for the atom:category element is temporarily removed; - some default values have changed: - content is not published by default - names of the atom:updated and atom:published property default to atom_updated and atom_published * Things yet to be done Besides support of even more atom elements (e.g. use tags for the atom:category element), the exporter would require a proper documentation for the Org mode manual, and of course some real-world testing. Thus I'm interested not just in bugs, glitches, inconsistencies, and complains about the exporter but some feedback about the present documentation, too. * Documentation Publish Atom feeds based on Org files = Date: 2010-06-15 18:49:21 CEST Table of Contents = 1 Exporting an Org file to Atom 1.1 In-buffer options 1.2 Headline properties 1.3 Export settings 1.4 Example 2 Publish feeds for a web page project 2.1 Publish a feed for each file in the project 2.2 Publish a combined feed for project files 1 Exporting an Org file to Atom An Atom feed consists of a head with feed meta data (e.g. feed title and description) and one or more feed entries. The exporter maps Org mode subtrees to Atom feed entries and requires special in-buffer options with feed as well as headline properties with entry specific meta data. 1.1 In-buffer options == An Atom feed is identified by a globally unique identifier, preferably a UUID. Such an identifier must be present in a Org file supposed to get exported or published to Atom in the =#+FEED_ID= in-buffer option. If you do not use a UUID, the value of this in-buffer option must be a proper IRI, like for example a URL that identifies this particular feed. To be able to properly reference feed entry content and the feed itself[1], at least the URL of the feed must be given by the =#+FEED_URL=. By default Org assumes the published content available in the same place like the feed with the name of the Org file and the extension defined in =org-export-html-extension=. For example a feed for the file =example.org= with the in-buffer option =#+FEED_URL= set to =http://example.tld/feed.atom= is expected to reference content located on the URL =http://example.tld/example.html=. If you indent to use different URLs for the feed and the referenced content, you can set the content URL manually by providing the in-buffer option =#+FEED_CONTENT_URL=. Prospective feed entries are found by using the TAGS/PROP/TODO query specified in the =#+FEED_MAP_ENTRIES= option. If present, the exporter uses the in-buffer options =#+TITLE= and =#+DESCRIPTION= for the feed title and description. If no title is given, the exporter uses the file name. If you want the feed title or description to be different than title and description of the published HTML file, you can use the in-buffer options =#+FEED_TITLE= and =#+FEED_DESCRIPTION=. Atom feeds are required to have an associated author of a feed and its entries. Exporting an Org file to Atom thus always uses the author specified with the =#+AUTHOR= option as the name of the author of a feed. If this option is not present, Org falls back to use