[O] autotagging based on buffer content
Hi, I just thought Id ask this again Does anyone have the solution or elisp skills for a system built into templates to auto tag based on source buffer contents? This would be immensely useful I think. (previously asked here: http://comments.gmane.org/gmane.emacs.orgmode/55137) Ideally, for example, I would journal an email which would auto tag with something like GERMANLESSONS if the buffer contained German-Flashcards.com. regards r. -- Sent using Emacs/Gnus from home ...
Re: [O] [org-e-html] New HTML exporter has an extra blank line in pre sections
Hello, Bernt Hansen be...@norang.ca writes: I noticed that the new exporter has one extra blank line in the output of source and example blocks while the old exporter does not. I removed a couple of newline characters in org-e-html.el. The problem should be fixed. Could you confirm this? Regards, -- Nicolas Goaziou
Re: [O] alignment of description list in Org and export old and new
Hello, Michael Brand michael.ch.br...@gmail.com writes: For this alignment with M-q (fill-paragraph) and C-c C-c on description list I suggest a formatting cookie, similar to Org table where 19 on any row narrows the column: - when any item contains only : align all descriptions to the widest term of the list - when any item contains only 19: align all descriptions as if the widest term would be 19 wide, if necessary start the description on the next line to not hide the rest of a longer term - when none of the items matches ^[0-9]*$: rearrange whitespace like now, which means without aligning I think this would complicate code base for little benefit. I suggest to live with that kind of limitation. Regards, -- Nicolas Goaziou
Re: [O] Checkboxes for description lists
Hello, Robert Yates robert.francis.ya...@gmail.com writes: What is the reason for disallowing the commands for adding and toggling checkboxes on descripton list items (that is - partA :: partB list items) ? (attempting to do so results in the message Cannot add a checkbox to a description list item) Good question. I think I thought I had a good reason to do so when I implemented this rule... Oh, well. I removed this limitation in org-list.el and modified new exporters so they handle checkboxes in description lists correctly (that is by adding checkbox before the tag, not before the description). If it breaks something beyond repair, I'll just revert the patch. While at simplifying this `org-list-automatic-rules' variable, I think that `indent' and `bullet' rules should be hard-coded too. There's no real reason to make them configurable after all. Then `org-list-automatic-rules' could be set to a boolean value and renamed to `org-list-update-statistics-cookies' or something similar. Any objection to that? Regards, -- Nicolas Goaziou
Re: [O] org-e-html: Including ATTR_HTML: title=hover text
Hello, William Crandall bc3141...@gmail.com writes: You mentioned before using filters. I take it these are the ones described in org-export-filters.el (line 1775), The Filter System. Has anyone written up any worked examples of these? org-e-ascii.el and org-e-html.el both use filters. Also, I posted a few examples on this list while answering to requests from users. And, is that the best tool for adding attributes to links? Besides your canonical example, I don't know exactly what are your needs. Hence, it may be, but that's hard to tell. Filters are meant to modify output from transcoders (so you're working with HTML, or LaTeX, or... material) before it is concatenated into global result. They allow the user to have the last word in any situation. You can also define your own transcoders if you prefer to work on parsed data. Now, if the attributes you want to add have no pattern with regards to related link, you cannot do much programmatically and you'll have to insert HTML code manually. Also, besides code comments, you may have a look at: http://orgmode.org/worg/dev/org-export-reference.html Regards, -- Nicolas Goaziou
Re: [O] [org-e-html] New HTML exporter has an extra blank line in pre sections
Nicolas Goaziou n.goaz...@gmail.com writes: Bernt Hansen be...@norang.ca writes: I noticed that the new exporter has one extra blank line in the output of source and example blocks while the old exporter does not. I removed a couple of newline characters in org-e-html.el. The problem should be fixed. Could you confirm this? Hi Nicolas, This fix works. Thanks! Regards, Bernt
[O] New exporter variables
Hi Nicolas, Are there analogous variables to --8---cut here---start-8--- (setq org-export-author-info nil) (setq org-export-creator-info nil) (setq org-export-time-stamp-file nil) --8---cut here---end---8--- in the new exporter to control export of the author, creator, and timestamp by default? I haven't been able to find those yet. Thanks, Bernt
Re: [O] New exporter variables
Hello, Bernt Hansen be...@norang.ca writes: Are there analogous variables to (setq org-export-author-info nil) (setq org-export-creator-info nil) (setq org-export-time-stamp-file nil) in the new exporter to control export of the author, creator, and timestamp by default? I haven't been able to find those yet. Yes. I have standardized the name of the first two since every other opt-in/out variable had the prefix org-export-with-. They have become, respectively, `org-export-with-author' and `org-export-with-creator'. `org-export-time-stamp-file' has kept its name, to avoid confusion with `org-export-with-timestamps'. Regards, -- Nicolas Goaziou
Re: [O] new exporter
Nicolas Goaziou writes:
I do not notice anything like this. There are many compilation errors
on some files, but they are the same before and after removing an
org-e-*.el file.
I get them very consistently, in both Emacs 23.3 and 24.1, with and
without my patches.
org-mode rm lisp/org-{export,element,e-*}.{el,elc}
org-mode ln contrib/lisp/org-{export,element,e-*}.el lisp/
org-mode make compile
org-mode rm lisp/org-e-*.elc
org-mode make compile-dirty
If I pre-load either org-element or org-export (or both) and they have
been byte-compiled things get worse to the point where Emacs simply
craps out. I don't know why this is happening, but it's very obvious
that these files can't be used byte-compiled. Whatever the reason, it
needs fixing.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] new exporter
Hello, Achim Gratz strom...@nexgo.de writes: If I pre-load either org-element or org-export (or both) and they have been byte-compiled things get worse to the point where Emacs simply craps out. I don't know why this is happening, but it's very obvious that these files can't be used byte-compiled. Whatever the reason, it needs fixing. What happens if you revert commit: 4b0121fc2a18e00ce2c80e145563e41accfc4ddb Regards, -- Nicolas Goaziou
Re: [O] new exporter
Nicolas Goaziou writes: What happens if you revert commit: 4b0121fc2a18e00ce2c80e145563e41accfc4ddb I've played with that before. As I already said, the requires and maybe even the circular dependencies are not the problem. It apparently croaks on the runtime use of cl macros and/or functions, but just exactly how is a mystery to me. I also do not know if the byte-compiler output is already faulty or if running it (as in load or require) before byte-compiling another file is triggering the error. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] new exporter
Achim Gratz strom...@nexgo.de writes: It apparently croaks on the runtime use of cl macros and/or functions, but just exactly how is a mystery to me. org-element uses `every' twice. Since this function doesn't belong to cl but cl-extra, could it be the source of the problem? If so, it may be worth a try to remove them from code base.
Re: [O] new exporter
Nicolas Goaziou writes: Achim Gratz strom...@nexgo.de writes: It apparently croaks on the runtime use of cl macros and/or functions, but just exactly how is a mystery to me. org-element uses `every' twice. Since this function doesn't belong to cl but cl-extra, could it be the source of the problem? Dunno. I have just rid org-element and org-export of all cl macros (incf, decf, loop, case, ...) and things start to compile correctly. But that is too big a hammer obviously. The use of cl macros at compile time is officially sanctioned, so the reason for this must be that you violate some assumption about their use or capture symbols used by the byte compiler. If so, it may be worth a try to remove them from code base. I'd start with the uses of macros inside let clauses. These look really fishy to me some of those symbols look like something the byte-compiler might use itself: count, line, etc. It is clear by now that something throws the byte-compiler off really hard. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] [latex] Problems with old exporter (for Beamer) and with new exporter
Hello,
Sebastien Vauban
wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes:
With the new exporter, most things work. What does not work:
- macro does not get executed (no string in orange color),
Macro are meant to produce contents, not to talk to back-ends. Every
text they produce will be protected.
- the =\end{verbatim}= disappears from the LaTeX output
This is a limitation from LaTeX: you cannot have \end{verbatim} string
within a verbatim environment.
Regards,
--
Nicolas Goaziou
Re: [O] org-e-html: Including ATTR_HTML: title=hover text
Hello Nicolas, Many thanks for explaining the logic and functionality of the new exporter. I confess I am puzzled by the choice to drop the ability to apply attributes to links. The use case I'm aiming for is a standard HTML feature: 3.2.3.2 The 'title' attribute The title attribute represents advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the image credit or a description of the image; on a paragraph, it could be a footnote or commentary on the text; on a citation, it could be further information about the source; and so forth. http://www.w3.org/TR/html5/global-attributes.html#the-title-attribute In org-e-html today, it is only possible to attach a unique attribute to a paragraph; all links within that paragraph inherit its attributes. If a paragraph contains two links, they are both forced to show the same tooltip. The old exporter allowed this specificity, correctly interleaving link and image titles in one paragraph: Org input: -- A paragraph with three papers, and an image: #+ATTR_HTML: title=Paper #1 [[./local/01.html][a first paper]] followed by #+ATTR_HTML: title=Paper #2 [[./local/02.html][a second paper]] which describe stuff. It then offers a cat #+ATTR_HTML: title=Some cats alt=Cat image [[./local/cats.png]] and finally a third, PDF paper #+ATTR_HTML: title=Paper #3 [[./local/03.pdf][a third paper]] -- Old exporter: -- p A paragraph with three papers, and an image: a href=./local/01.html title=Paper #1a first paper/a followed by a href=./local/02.html title=Paper #2a second paper/a which describe stuff. It then offers a cat img src=./local/cats.png title=Some cats alt=Cat image / and finally a third, PDF paper a href=./local/03.pdf title=Paper #3a third paper/a /p -- I believe that this ability, this specificity within paragraphs, is generally quite useful, and I hope that you will consider it for the new exporter. If I'm missing something, if there /is/ a way to add individual link attributes, please let me know. It doesn't sound like filters allow that. Thanks again, for building and explaining. -BC Org-mode version 7.8.11 (release_7.8.11-64-g168c83) GNU Emacs 24.1.50.1 (i386-mingw-nt6.1.7601) Windows 7
