Re: [O] bug in selective export when selected heading follows excluded heading
Eric S Fraga e.fr...@ucl.ac.uk writes: Hsiu-Khuern Tang tan...@gmail.com writes: Hi, Here's an input file, a.org: #+OPTIONS: toc:nil #+EXPORT_EXCLUDE_TAGS: exclude #+EXPORT_SELECT_TAGS: include * chap1 ** sec1 :exclude: ** sec2 :include: If I export this file, the heading gets mangled. E.g., the ascii export is: Confirmed with up to date org. To follow this up further, the solution is to put the :include: tag on the top level heading (chap1) as well. Then the export works fine. There is still a bug but whether sec2 should be output at all or not, given that chap1 has no tag, is unclear! Undefined situation basically. HTH, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.10-630-g4144c5.dirty
Re: [O] Broken LaTeX export
SW sabrewo...@gmail.com writes: Nick Dokos nicholas.dokos at hp.com writes: Interesting: it seems to be a latex bug of some sort, but I haven't had time to play with it too much yet. I'm trying things like modifying the tex file slightly and seeing if the empty page(s)/overfull page(s) persist. So far, it seems that all the packages that org includes are innocent: I took them all out and the strangeness persists. [...] However, this is a work-around, not a solution, as part of the appeal of org-mode and the LaTeX export is to be able to work with and generate outlines and structures of documents first, before adding all the content. A simple solution which keeps your interest in the outline structure at this stage of the writing is to add the line #+options: H:3 to the document (remembering to refresh org by typing C-c C-c on this line). This converts all 4th level headings and lower to lists on export without you having to change the document content at all. For your test document, this works just fine. Once you have added enough text, you can change the 3 to 5 and your document should export just fine. HTH, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.10-630-g4144c5.dirty
Re: [O] make doc fails on current head
Hi Michael, I just reverted my commit, thanks. Michael Brand michael.ch.br...@gmail.com writes: but I can confirm that it should really compile to @@#$2 and not to @#$2 or something else. So what does @@#$2 really means? Does the first @ stand for This is a field coordinate and the rest for the coordinates range itself? -- Bastien
Re: [O] make doc fails on current head
Hi Jonathan, Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes: Under the current git head (4144c55) I get the following error when trying to run =make doc=. Fixed, thanks for reporting this. -- Bastien
Re: [O] bug in .texi?
Hi Samuel, Samuel Wales samolog...@gmail.com writes: ... make -C doc info makeinfo --no-split org.texi -o org org.texi:2450: Unknown command `#$2)'. makeinfo: Removing output file `org' due to errors; use --force to preserve. make[1]: *** [org] Error 1 make: *** [info] Error 2 makeinfo (GNU texinfo) 4.13 Fixed by reverting the commit, thanks. -- Bastien
Re: [O] make doc fails on current head
Hi Bastien On Fri, Jun 1, 2012 at 9:48 AM, Bastien b...@gnu.org wrote: So what does @@#$2 really means? Does the first @ stand for This is a field coordinate yes and the rest for the coordinates range itself? it is not a range, but as @# and $# can be used to get the row or column number of the field where the formula result goes it will evaluate to @1$2, @2$2 and so on. I tried to be brief in the manual but there are more examples on Worg: Field coordinates in formulas (@# and $#) http://orgmode.org/worg/org-hacks.html#field-coordinates-in-formulas Michael
Re: [O] if both schedule and deadline, appear only once in agenda
SW sabrewo...@gmail.com writes: However, this is not what my question is about. My question relates to advance warning that an item is scheduled in the future. I want to know on Friday that I have scheduled a large project to start on Monday. That is, I would like to know beforehand that I need to start working on a large project in a few days time. One approach is to consider that thinking about a large project about to start is itself a task so you could look at adding a task for the Friday, when you first scheduled the large task for the Monday, to tell you start thinking... This might sound silly but it can actually be quite useful if you get into the habit of thinking about such aspects when you schedule tasks. And, of course, you can group related tasks like these as subheadings under a common headline. Something to think about over the weekend ;-) -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.10-630-g4144c5.dirty
Re: [O] [PATCH] org-reload doesn't use full emacs load-path?
Achim Gratz strom...@nexgo.de writes: Eric S Fraga writes: Seems to work just fine. Thanks! Thanks for testing. Bastien, could you please install the patch? Done, thanks. -- Bastien
Re: [O] make doc fails on current head
Bastien b...@gnu.org wrote: So what does @@#$2 really means? Does the first @ stand for This is a field coordinate and the rest for the coordinates range itself? @# is the current row number, so @@#$2 is a reference to the current row, second column. Michael has a couple of nontrivial examples (e.g. transposing a table) using this facility on worg: http://orgmode.org/worg/org-hacks.html#field-coordinates-in-formulas-transpose-table where he is using the current row and current col to form a reference to the transposed location: @$#$@# The row whose number is the number of the current column and the column whose number is the number of the current row. Nick
Re: [O] encoding problem
Bernt Hansen be...@norang.ca writes: Julien Cubizolles j.cubizol...@free.fr writes: I'm having a very strange problem with character encoding. I write all my text files with emacs, with non-ascii characters (I'm french). I keep a copy of many files (latex/org/...) on separate machines using unison. Very often after a synchronization, the non-ascii charaters are completely displayed wrong (à for à, ç for ç) in the org files, but never in the latex files. I guess it's more an Emacs than org files but I can't see what's special in the org files that makes them more prone to such errors. Is there a way to *fix* easily these corruptions on a file, ie searching for all weird characters to replace ? How could I prevent this from happening again (checking/changing character encoding maybe ?) Thanks for your help, Julien. Hi Julien, I get prompts for encoding when saving/exporting (on Windows only) so I put the following at the top of my org-files # -*- coding: utf-8 -*- which seems to fix the problem for me. Maybe this will help? I used to have this problem and it was incredibly annoying. I also started adding the line Bernt suggests but I kept forgetting for new files. I finally solved this problem by adding the following lines to my emacs initialisation: #+begin_src emacs-lisp (prefer-coding-system 'utf-8) (set-charset-priority 'unicode) (setq default-process-coding-system '(utf-8-unix . utf-8-unix)) #+end_src I couldn't tell you which of these matter or whether they are all necessary but I don't have these problems any longer so I haven't investigated any further! -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.10-630-g4144c5.dirty
Re: [O] Windows (Cygwin) make: Works, but org-release(void)
Hi William, William Crandall bc3141...@gmail.com writes: ;; Functionality of Org-mode's org-install.el is supplanted by ;; Package Manager's org-autoloads.el. Since Package Manager ;; autoloads Org-mode, the following line (require 'org-install) in ;; your .emacs is no longer required and can be safely removed. http://orgmode.org/worg/org-faq.html I've removed this instruction now. Thanks, -- Bastien
[O] Crash in GNU Emacs 24.0.97.1 (i386-mingw-nt5.1.2600) of 2012-05-17 on MARVIN when jumpin to end of long lines of org-mode file
Hi all, I have emacs crashing since several versions. Being in org-mode I have a long line like this (following 3 lines concatenated) #+BEGIN: clocktable :maxlevel 0 :fileskip0 t :scope (~/org/DIPLAN/DIPLAN.org ~/org/DIPLAN/DIPLAN.org_archive ~/org/DIPLAN/Seuffer.org ~/org/DIPLAN/ebm-papst.org ~/org/DIPLAN/PREH.org ~/org/DIPLAN/PADUA/PADUA.org ~/org/DIPLAN/PADUA/Lastenheft.org ~/org/DIPLAN/PADUA/Pflichtenheft.org ~/org/DIPLAN/PADUA/Zeitaufschreibung.org) :block 2012-04 Point is at the beginning of the line. If I press C-e Emacs crashes reproducably. My major mode is Org, version Org-mode version 7.8.10 (release_7.8.10-598-g747d71 Enabled minor modes: Abbrev Auto-Composition Auto-Compression Auto-Encryption Blink-Cursor Delete-Selection Display-Time File-Name-Shadow Font-Lock Global-Font-Lock Icicle Iswitchb Line-Number Minibuffer-Depth-Indicate Mouse-Wheel Recentf Shell-Dirtrack Show-Paren Transient-Mark When I switch to text-mode the crashes do not appear anymore! How can I track down the reason for the crashes? Cheers, Rainer
Re: [O] Crash in GNU Emacs 24.0.97.1 (i386-mingw-nt5.1.2600) of 2012-05-17 on MARVIN when jumpin to end of long lines of org-mode file
Hi Rainer, Rainer Stengele rainer.steng...@online.de writes: I have emacs crashing since several versions. I can't test with your version of Emacs. Being in org-mode I have a long line like this (following 3 lines concatenated) #+BEGIN: clocktable :maxlevel 0 :fileskip0 t :scope (~/org/DIPLAN/DIPLAN.org ~/org/DIPLAN/DIPLAN.org_archive ~/org/DIPLAN/Seuffer.org ~/org/DIPLAN/ebm-papst.org ~/org/DIPLAN/PREH.org ~/org/DIPLAN/PADUA/PADUA.org ~/org/DIPLAN/PADUA/Lastenheft.org ~/org/DIPLAN/PADUA/Pflichtenheft.org ~/org/DIPLAN/PADUA/Zeitaufschreibung.org) :block 2012-04 There is a missing #+END. Do you still have the crash with #+END? Can you send the complete .org file to test? How can I track down the reason for the crashes? C-h f org-end-of-line RET C-x o TAB RET M-x edebug-defun RET then C-e in your file again to see if you can find the problem with org-end-of-line. HTH, -- Bastien
Re: [O] make doc fails on current head
Nick Dokos nicholas.do...@hp.com writes: Bastien b...@gnu.org wrote: So what does @@#$2 really means? Does the first @ stand for This is a field coordinate and the rest for the coordinates range itself? @# is the current row number, so @@#$2 is a reference to the current row, second column. Got it, thanks to you and Michael for the detailed answers. -- Bastien
Re: [O] a line in BEGIN_SRC/END_SRC block disappeared when publishing
Hi Liang, Liang Wang netcas...@gmail.com writes: #+BEGIN_SRC emacs-lisp (eval-after-load 'yasnippet '(yas/define-snippets 'org-mode '((elisp #+BEGIN_SRC emacs-lisp $0 ,#+END_SRC #+BEGIN_SRC emacs-lisp ... #+END_SRC #+END_SRC Why not this #+BEGIN_SRC emacs-lisp (eval-after-load 'yasnippet '(yas/define-snippets 'org-mode '((elisp #+BEGIN_SRC emacs-lisp $0\n#+END_SRC #+BEGIN_SRC emacs-lisp ... #+END_SRC #+END_SRC ? -- Bastien
Re: [O] Setting user-defined properties while ido-mode is active
On Thu, May 31 2012, Thorsten Jolitz wrote: However, I have to deactivate ido-mode everytime I want to set a user-defined property with C-c C-x p, since ido-mode shows me all the predefined property names and does not let me enter my own property name. Did anybody else experience this, or am I simply ignorant of some basic ido-mode functionality here? You can type the name of the new property and hit enter. The prompt will say [No match], but just ignore it. The new property will be created. Regards, Jason
Re: [O] make doc fails on current head
I can confirm it's fixed And thanks for the answer, hadn't realized you could use @# and $# for references. On Fri, Jun 1, 2012 at 8:56 AM, Bastien b...@gnu.org wrote: Nick Dokos nicholas.do...@hp.com writes: Bastien b...@gnu.org wrote: So what does @@#$2 really means? Does the first @ stand for This is a field coordinate and the rest for the coordinates range itself? @# is the current row number, so @@#$2 is a reference to the current row, second column. Got it, thanks to you and Michael for the detailed answers. -- Bastien
Re: [O] Annoying behavior of RET after a timestamp
Hi Nick, Nick Dokos nicholas.do...@hp.com writes: There was a recent commit 8c91f690a561113eee0d16cdb6e8afc6bcae2089 to follow a time stamp as a link. I have no problem with that but the code uses the org-at-timestamp-p function, which (perversely IMO) thinks that I am in a timestamp even when I'm right *after* the closing bracket; so pressing RET after inserting a time stamp follows the link, instead of inserting a newline. Since I do that fairly often, I find the behavior annoying. I agree this can be annoying. The behavior is now to insert a new line when the point is right after the timestamp. Thanks! -- Bastien
Re: [O] Annoying behavior of RET after a timestamp
Hi Matt, Matt Lundin m...@imapmail.org writes: But if a little traditional usability is lost for the sake of consistency, then we should change org-at-timestamp-p. (And Nicolas has done heroic work in bringing consistency to the definition of various org elements!) FWIW, I didn't change the behavior/output of `org-at-timestamp-p', I've used `org-ts-what', which stores information on what place we are in the matched timestamp. -- Bastien
Re: [O] a line in BEGIN_SRC/END_SRC block disappeared when publishing
Hi Bastien, On Fri, Jun 1, 2012 at 9:01 PM, Bastien b...@gnu.org wrote: Hi Liang, Liang Wang netcas...@gmail.com writes: #+BEGIN_SRC emacs-lisp (eval-after-load 'yasnippet '(yas/define-snippets 'org-mode '((elisp #+BEGIN_SRC emacs-lisp $0 ,#+END_SRC #+BEGIN_SRC emacs-lisp ... #+END_SRC #+END_SRC Why not this #+BEGIN_SRC emacs-lisp (eval-after-load 'yasnippet '(yas/define-snippets 'org-mode '((elisp #+BEGIN_SRC emacs-lisp $0\n#+END_SRC #+BEGIN_SRC emacs-lisp ... #+END_SRC #+END_SRC Thanks. This one works. Liang.
Re: [O] Crash in GNU Emacs 24.0.97.1 (i386-mingw-nt5.1.2600) of 2012-05-17 on MARVIN when jumpin to end of long lines of org-mode file
Rainer Stengele rainer.steng...@online.de wrote: Hi all, I have emacs crashing since several versions. Being in org-mode I have a long line like this (following 3 lines concatenated) #+BEGIN: clocktable :maxlevel 0 :fileskip0 t :scope (~/org/DIPLAN/DIPLAN.org ~/org/DIPLAN/DIPLAN.org_archive ~/org/DIPLAN/Seuffer.org ~/org/DIPLAN/ebm-papst.org ~/org/DIPLAN/PREH.org ~/org/DIPLAN/PADUA/PADUA.org ~/org/DIPLAN/PADUA/Lastenheft.org ~/org/DIPLAN/PADUA/Pflichtenheft.org ~/org/DIPLAN/PADUA/Zeitaufschreibung.org) :block 2012-04 Point is at the beginning of the line. If I press C-e Emacs crashes reproducably. My major mode is Org, version Org-mode version 7.8.10 (release_7.8.10-598-g747d71 Enabled minor modes: Abbrev Auto-Composition Auto-Compression Auto-Encryption Blink-Cursor Delete-Selection Display-Time File-Name-Shadow Font-Lock Global-Font-Lock Icicle Iswitchb Line-Number Minibuffer-Depth-Indicate Mouse-Wheel Recentf Shell-Dirtrack Show-Paren Transient-Mark When I switch to text-mode the crashes do not appear anymore! How can I track down the reason for the crashes? Is there a core dump? If so, try running gdb like so: , | $ gdb /path/to/emacs /path/to/core | ... | (gdb) bt ` to get a backtrace. There is some information about what to do in the emacs manual: (info (emacs) Checklist) Nick
Re: [O] Annoying behavior of RET after a timestamp
Bastien b...@gnu.org wrote: Hi Nick, Nick Dokos nicholas.do...@hp.com writes: There was a recent commit 8c91f690a561113eee0d16cdb6e8afc6bcae2089 to follow a time stamp as a link. I have no problem with that but the code uses the org-at-timestamp-p function, which (perversely IMO) thinks that I am in a timestamp even when I'm right *after* the closing bracket; so pressing RET after inserting a time stamp follows the link, instead of inserting a newline. Since I do that fairly often, I find the behavior annoying. I agree this can be annoying. The behavior is now to insert a new line when the point is right after the timestamp. Thanks! The annoyance is gone. Nick
Re: [O] encoding problem
Eric S Fraga e.fr...@ucl.ac.uk writes: Bernt Hansen be...@norang.ca writes: Julien Cubizolles j.cubizol...@free.fr writes: I'm having a very strange problem with character encoding. I write all my text files with emacs, with non-ascii characters (I'm french). I keep a copy of many files (latex/org/...) on separate machines using unison. Very often after a synchronization, the non-ascii charaters are completely displayed wrong (à for à, ç for ç) in the org files, but never in the latex files. I guess it's more an Emacs than org files but I can't see what's special in the org files that makes them more prone to such errors. Is there a way to *fix* easily these corruptions on a file, ie searching for all weird characters to replace ? How could I prevent this from happening again (checking/changing character encoding maybe ?) Thanks for your help, Julien. Hi Julien, I get prompts for encoding when saving/exporting (on Windows only) so I put the following at the top of my org-files # -*- coding: utf-8 -*- which seems to fix the problem for me. Maybe this will help? I used to have this problem and it was incredibly annoying. I also started adding the line Bernt suggests but I kept forgetting for new files. I finally solved this problem by adding the following lines to my emacs initialisation: #+begin_src emacs-lisp (prefer-coding-system 'utf-8) (set-charset-priority 'unicode) (setq default-process-coding-system '(utf-8-unix . utf-8-unix)) #+end_src I couldn't tell you which of these matter or whether they are all necessary but I don't have these problems any longer so I haven't investigated any further! Thanks Eric! I'll try this and drop my mode line setting in each org file. I still encounter this when archiving for the first time to a new file -- since I'm archive utf-8 content and the new target org file prompts for encoding with my current setup. Regards, Bernt
Re: [O] Setting user-defined properties while ido-mode is active
Jason Dunsmore jasondunsm...@gmail.com writes: On Thu, May 31 2012, Thorsten Jolitz wrote: However, I have to deactivate ido-mode everytime I want to set a user-defined property with C-c C-x p, since ido-mode shows me all the predefined property names and does not let me enter my own property name. Did anybody else experience this, or am I simply ignorant of some basic ido-mode functionality here? You can type the name of the new property and hit enter. The prompt will say [No match], but just ignore it. The new property will be created. That works, thanks. -- cheers, Thorsten
Re: [O] encoding problem
Bernt Hansen be...@norang.ca wrote: Eric S Fraga e.fr...@ucl.ac.uk writes: Bernt Hansen be...@norang.ca writes: Julien Cubizolles j.cubizol...@free.fr writes: I'm having a very strange problem with character encoding. I write all my text files with emacs, with non-ascii characters (I'm french). I keep a copy of many files (latex/org/...) on separate machines using unison. Very often after a synchronization, the non-ascii charaters are completely displayed wrong (à for à, ç for ç) in the org files, but never in the latex files. I guess it's more an Emacs than org files but I can't see what's special in the org files that makes them more prone to such errors. Is there a way to *fix* easily these corruptions on a file, ie searching for all weird characters to replace ? How could I prevent this from happening again (checking/changing character encoding maybe ?) Thanks for your help, Julien. Hi Julien, I get prompts for encoding when saving/exporting (on Windows only) so I put the following at the top of my org-files # -*- coding: utf-8 -*- which seems to fix the problem for me. Maybe this will help? I used to have this problem and it was incredibly annoying. I also started adding the line Bernt suggests but I kept forgetting for new files. I finally solved this problem by adding the following lines to my emacs initialisation: #+begin_src emacs-lisp (prefer-coding-system 'utf-8) (set-charset-priority 'unicode) (setq default-process-coding-system '(utf-8-unix . utf-8-unix)) #+end_src I couldn't tell you which of these matter or whether they are all necessary but I don't have these problems any longer so I haven't investigated any further! Thanks Eric! I'll try this and drop my mode line setting in each org file. I still encounter this when archiving for the first time to a new file -- since I'm archive utf-8 content and the new target org file prompts for encoding with my current setup. Regards, Bernt Isn't the setting of LANG used during initialization to set these things? I have LANG set to en_US.UTF-8 and new buffers are in utf-8-unix (except for mail composition buffers: they are in undecided-unix). I'm pretty sure I'm not mucking with coding systems anywhere in my emacs initialization otherwise. Nick
Re: [O] Testing: org-export-e-html
Hello, William Crandall bc3141...@gmail.com writes: 1. [[directors]] 2. [[#directors]] 3. [[directors][Directors]] 4. [[#directors][Directors]] As I see it (do let me know what I'm getting wrong!), the old version gets all links right. (But old makes one error(?) see next section.) 1. [[directors]] old: a href=#sec-1directors/a new: idirectors/i 2. [[#directors]] old: a href=#directors#directors/a new: a href=#sec-1Directors/a 3. [[directors][Directors]] old: a href=#sec-1Directors/a new: iDirectors/i 4. [[#directors][Directors]] old: a href=#directorsDirectors/a new: a href=#sec-1Directors/a In no case is the output the same! idirectors/i is a fallback output meaning that export engine wasn't able to find which object you were linking to. Provide targets for these links and the output will be different. #4 would be most useful for my purposes, as it allows identifying target links precisely. Org has syntax to identify target links precisely. I gave you a few examples in a previous mail. Turning to the output for targets, the new version does not close the a tag (as the old version does). Other than that, new seems fine. (Old generates a pre section from the PROPERTIES drawer, whether it is open or closed, with your encoding. Not my focus, but is this an old bug?) Properties drawers are ignored in every back-end by default. There is no old or new bug, the behaviour has evolved. Output (new engine) (Also: two extra blank-lines before each p): That was a mistake in `org-e-html.el'. There should be as much blank lines in the Org buffer as in HTML output. I fixed the problem in a recent commit. Regards, -- Nicolas Goaziou
Re: [O] Smart Quotes Exporting
Hello, Mark E. Shoulson m...@kli.org writes: Oh, certainly; they're all a disaster. I think I said that in the writeup at the top. This is just proof of concept, nothing is in the right place, nothing is properly documented. They have to be defcustoms, there needs to be a good :type in the defcustom as well as a proper docstring. You'll get no argument from me about the lack (or inaccuracy) of docstrings and such. I hadn't gotten that far yet. I said the patch was only if you wanted to tinker with the development as this progresses. No worries, I was just making some comments before forgetting about them. +(defun org-e-latex--quotation-marks (text info) + (org-export-quotation-marks text info org-e-latex-quote-replacements)) + ;; (mapc (lambda(l) + ;; (let ((start 0)) + ;;(while (setq start (string-match (car l) text start)) + ;; (let ((new-quote (concat (match-string 1 text) (cdr l + ;;(setq text (replace-match new-quote t t text)) + ;;(cdr (or (assoc (plist-get info :language) org-e-latex-quotes) + ;; ;; Falls back on English. + ;; (assoc en org-e-latex-quotes + ;; text) Use directly `org-e-latex-quote-replacements' in code then. Not sure I understand this comment. Since `org-e-latex--quotation-marks' just calls `org-export-quotation-marks', you can remove completely the former from org-export.el and use the latter instead. So... there's the filter-parse-tree-functions hook gets applied within the parse tree... so a back-end can add a function to that list which looks over the parse-tree and watches for these border cases (and also the ones within ordinary strings). Looks like it's going to be tough to work in any flexibility to define further per-language or per-backend cleverness to handle anything beyond the canonical set of open-double, close-double, open-single, close-single, and mid-word. To be sure, anything we do will most assuredly fail even on some fairly reasonable input, in which case the users are pretty much on their own and will have to do things the hard way. And I could use that as the answer here, that, well, it'll work only within plain-text strings (and I might possibly still have to use that answer), but I would rather include the situations you bring up in the supported set and not throw up my hands at it. So, yes, will look at that. Actually it isn't very hard to handle this problem. But it will be different than the fontification used in an Org buffer. You might want to look at `org-element-normalize-contents', which solves a similar problem: removing maximum common indentation at the parsed paragraph level. As a first approximation, I can imagine a function accepting an element, an object or a secondary string and returning an equivalent element, object or secondary string, with its quotes smartified. The algorithm could go like this: Walk element/object/secondary-string's contents . 1. When a string is encountered: 1. If it has a quote as its first or last position, check for objects before or after the string to guess its status. An object never starts with a white space, but you may have to check :post-blank property in order to know if previous object had white spaces at its end. 2. For each quote everywhere else in the string, your regexp can handle it fine. 2. When an object belonging to `org-element-recursive-objects' is encountered, apply the function to this object. 3. Accumulate returned strings or objects. Use accumulated data as the contents of the new object to return (i.e. just add the type and the same properties at the beginning of this list if it was an object or an element, return it as-is if that was a secondary string). On the elements side, only paragraphs, verse-blocks and table-rows can directly contain quotes. Also, headline, inlinetask item and footnote-reference have secondary strings containing quotes. I'm not sure yet where and how to install such a function, but I will think about it when it is implemented. Regards, -- Nicolas Goaziou
Re: [O] encoding problem
Nick Dokos nicholas.do...@hp.com writes: Bernt Hansen be...@norang.ca wrote: Eric S Fraga e.fr...@ucl.ac.uk writes: Bernt Hansen be...@norang.ca writes: Julien Cubizolles j.cubizol...@free.fr writes: I'm having a very strange problem with character encoding. I write all my text files with emacs, with non-ascii characters (I'm french). I keep a copy of many files (latex/org/...) on separate machines using unison. Very often after a synchronization, the non-ascii charaters are completely displayed wrong (à for à, ç for ç) in the org files, but never in the latex files. I guess it's more an Emacs than org files but I can't see what's special in the org files that makes them more prone to such errors. Is there a way to *fix* easily these corruptions on a file, ie searching for all weird characters to replace ? How could I prevent this from happening again (checking/changing character encoding maybe ?) Thanks for your help, Julien. Hi Julien, I get prompts for encoding when saving/exporting (on Windows only) so I put the following at the top of my org-files # -*- coding: utf-8 -*- which seems to fix the problem for me. Maybe this will help? I used to have this problem and it was incredibly annoying. I also started adding the line Bernt suggests but I kept forgetting for new files. I finally solved this problem by adding the following lines to my emacs initialisation: #+begin_src emacs-lisp (prefer-coding-system 'utf-8) (set-charset-priority 'unicode) (setq default-process-coding-system '(utf-8-unix . utf-8-unix)) #+end_src I couldn't tell you which of these matter or whether they are all necessary but I don't have these problems any longer so I haven't investigated any further! Thanks Eric! I'll try this and drop my mode line setting in each org file. I still encounter this when archiving for the first time to a new file -- since I'm archive utf-8 content and the new target org file prompts for encoding with my current setup. Regards, Bernt Isn't the setting of LANG used during initialization to set these things? I have LANG set to en_US.UTF-8 and new buffers are in utf-8-unix (except for mail composition buffers: they are in undecided-unix). I'm pretty sure I'm not mucking with coding systems anywhere in my emacs initialization otherwise. Nick Maybe - I'm having this issue on Windows... -Bernt
Re: [O] encoding problem
Bernt Hansen be...@norang.ca wrote: Nick Dokos nicholas.do...@hp.com writes: Isn't the setting of LANG used during initialization to set these things? I have LANG set to en_US.UTF-8 and new buffers are in utf-8-unix (except for mail composition buffers: they are in undecided-unix). I'm pretty sure I'm not mucking with coding systems anywhere in my emacs initialization otherwise. Nick Maybe - I'm having this issue on Windows... Ah - OK: forgive my parochialism. I guess the question is whether whatever version of emacs you are using can access the locale information on Windows and do the equivalent of what it does on POSIX-y systems. Nick
[O] whole-adze dataset?
hi. sorry for the noise. i'm trying to figure out where the whole-adze dataset comes from. in R Source Code Blocks in Org Mode http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html the example Graphics Produced by ggplot2 references whole-adze (should that be whole.adze?), but web searches have been useless. what am i missing? cheers, Greg Minshall
Re: [O] bug in selective export when selected heading follows excluded heading
Hi Eric, On Thu, May 31, 2012 at 11:10 PM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Eric S Fraga e.fr...@ucl.ac.uk writes: Confirmed with up to date org. Thanks for confirming the bug. ... There is still a bug but whether sec2 should be output at all or not, given that chap1 has no tag, is unclear! Undefined situation basically. The Selective export section of the manual does say, If a selected tree is a subtree, the heading hierarchy above it will also be selected for export, but not the text below those headings. I find this behavior useful to avoid having too many tags. HTH, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.1.50.1 : using Org release_7.8.10-630-g4144c5.dirty - Hsiu-Khuern.
Re: [O] whole-adze dataset?
Greg Minshall minsh...@umich.edu writes: hi. sorry for the noise. i'm trying to figure out where the whole-adze dataset comes from. in R Source Code Blocks in Org Mode http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html the example Graphics Produced by ggplot2 references whole-adze (should that be whole.adze?), but web searches have been useless. what am i missing? cheers, Greg Minshall Aloha Greg, This was meant as a syntax example, rather than something that works when cut and pasted. I was lazy and just used something I was working on at the time (the graph it produces is at http://adzes.tsdye2.com/adzes.html#sec-1-4, if you are interested). I've pushed a change to Worg that should make it clear that it is just a syntax example. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Ido org-refile results in misfiling
One thing that may help is using C-space to lock previous matches with ido completion. For instance, you start ido completion (does not matter in which context: buffers, files, functions, etc) and start typing This will give you a bunch of matches. Then use C-space to lock these matches and it is like starting ido completion again but limited to whatever matched the previous typing. Using this method when you have many matches is usually much easier then trying to find what you want in a single pass. -- Darlan At Thu, 31 May 2012 19:51:36 -0700, Samuel Wales samolog...@gmail.com wrote: Ido and org-refile are a superb combination that enhances Org significantly. It is a killer feature IMO. However, in my usage there is a substantial risk of misfiling: 1) If I start from a fresh Emacs, myorg is sufficient to select computer/emacs/org/myorg/. This is good. 2) If I refile something to computer/emacs/org/myorg/strategy and examples/various todo kw and maybe some tags/, various is enough to select it. Note that this is below myorg. Also good. 3) (Just as an aside, if I then refile something else to the same entry, I don't even need to enter various. It is the default. A nice feature.) 4) Now suppose I want to refile something to myorg. I enter myorg but I get various. Detail on this subtle issue is below: === My expectation is that if myorg selects myorg once, it should always do so no matter what my refile history is. This expectation is violated. It violates a sort of referential transparency. The same narrowing inputs should produce the same narrowed outputs (in my expectation at least). I suspect that the reason for the unexpected behavior is related (in some way) to the defaulting in 3, which is useful. However, the false defaulting in 4 is NOT useful in any obvious way. === Proposed solution: I think that as soon as the user starts selecting something, the default should be discarded. === With my expectation, it is never necessary to check the offered olpaths except as a confirmation. With the current behavior, checking is always necessary because in edge cases, there will be a guaranteed misfile. Here is why: the only reason that default showed up at all is that the narrowing input /happened/ to match both headlines. Otherwise the default would have been discarded. So it is an edge case that allowed the offer to misfile. In other cases, the correct default would be provided. If I wanted various, RET would be sufficient. User checking is significantly more error-prone because one olpath is a substring of the other. Likewise, the requirement to navigate in the list is burdensome as 4 is never useful as far as I can tell. === Is there any way to fix this? I tried looking at ido customizations and got lost. If you can't reproduce witn your ido settings, I'll try to provide an MCE at some point. Might take a while though. Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Ido org-refile results in misfiling
Hi Darian, I use the technique you describe all the time for other purposes, and I agree it is wonderful. However, that solves almost exactly the *opposite* problem. :) In this case, it would lock in a default selection that is already locked in. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com
Re: [O] Smart Quotes Exporting
On 06/01/2012 01:11 PM, Nicolas Goaziou wrote: Hello, Mark E. Shoulsonm...@kli.org writes: Oh, certainly; they're all a disaster. I think I said that in the writeup at the top. This is just proof of concept, nothing is in the right place, nothing is properly documented. They have to be defcustoms, there needs to be a good :type in the defcustom as well as a proper docstring. You'll get no argument from me about the lack (or inaccuracy) of docstrings and such. I hadn't gotten that far yet. I said the patch was only if you wanted to tinker with the development as this progresses. No worries, I was just making some comments before forgetting about them. Ah, ok. Good! Thanks. +(defun org-e-latex--quotation-marks (text info) + (org-export-quotation-marks text info org-e-latex-quote-replacements)) + ;; (mapc (lambda(l) + ;; (let ((start 0)) + ;; (while (setq start (string-match (car l) text start)) + ;; (let ((new-quote (concat (match-string 1 text) (cdr l + ;; (setq text (replace-match new-quote t t text)) + ;; (cdr (or (assoc (plist-get info :language) org-e-latex-quotes) + ;;;; Falls back on English. + ;;(assoc en org-e-latex-quotes + ;; text) Use directly `org-e-latex-quote-replacements' in code then. Not sure I understand this comment. Since `org-e-latex--quotation-marks' just calls `org-export-quotation-marks', you can remove completely the former from org-export.el and use the latter instead. Well, that was done on purpose, and maybe the reason will make sense. As I see it, each exporter should be able to have its own smartifier function, and the export engine should make no assumptions about that: just call the individual exporter's function. On the other hand, many (but perhaps not all!) of the exporters may find themselves using essentially the same code just with different replacement strings. So I thought that general-purpose should be in org-export.el, just for the convenience of exporters should they choose to make use of it. So, many of the exporters' smartifier functions will really just be calls to the more general-purpose function. Does that make sense? So... there's the filter-parse-tree-functions hook gets applied within the parse tree... so a back-end can add a function to that list which looks over the parse-tree and watches for these border cases (and also the ones within ordinary strings). Looks like it's going to be tough to work in any flexibility to define further per-language or per-backend cleverness to handle anything beyond the canonical set of open-double, close-double, open-single, close-single, and mid-word. To be sure, anything we do will most assuredly fail even on some fairly reasonable input, in which case the users are pretty much on their own and will have to do things the hard way. And I could use that as the answer here, that, well, it'll work only within plain-text strings (and I might possibly still have to use that answer), but I would rather include the situations you bring up in the supported set and not throw up my hands at it. So, yes, will look at that. Actually it isn't very hard to handle this problem. But it will be different than the fontification used in an Org buffer. Yes, the fontification on-screen is different, and uses a rather different function--but if I can help it, the same regexps! So things work the same everywhere. I also started thinking a little about what you write below, how we can inspect the characters just after or before quotes at the very beginning or end of each chunk. It would be nice if it could all be encapsulated neatly in the regexp(s). As a first approximation, I can imagine a function accepting an element, an object or a secondary string and returning an equivalent element, object or secondary string, with its quotes smartified. The algorithm could go like this: Walk element/object/secondary-string's contents . Need it be element/object/secondary-string? At the bottom level it's always about strings; the higher levels don't affect the processing of each string in isolation. Do we need to intercept it at the element level or just wait to grab things in the plain-text filter, since we have access at that point too? (Might also be that my understanding of the process and the nature of elements is faulty or limited. Will have to see what works.) 1. When a string is encountered: 1. If it has a quote as its first or last position, check for objects before or after the string to guess its status. An object never starts with a white space, but you may have to check :post-blank property in order to know if previous object had white spaces at its end. Hmm, this may in fact answer my question above: you need to be able to get at the object level to test the post-blank. I'll experiment. 2. For each quote everywhere else in the string,
[O] org-babel R :results output changes with block level :session setting
I'm trying to use org-mode to reproduce the HTML slide show made with knitr demonstrated at http://goo.gl/bOJJo . The following single code block works #+BEGIN_SRC R :results output html library(googleVis) G - gvisGeoChart(Exports, Country, Profit, options = list(width = 250, height = 120)) print(G) #+END_SRC and wraps it in the needed HTML block, but if I set :session on the block the R prompt is included in the output. If i set a file level session property it works fine, but if on a single block inserts the prompt. I was expecting these would behave identically. Is this the expected behavior? Greg signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] Testing: org-export-e-html
Hello Jambunathan and Nicolas, Thanks for your recent updates! Links are proving to be quite a challenge. Here is my new test file, and new and old HTML output, comparing the two engines: old: C-c C-e h (org-export, in org-exp.el) new: M-x org-export-dispatch h (in org-export.el) The entire content of test.org: -- - Org (input): Link and description, to anchor in headline: [[#directors][Directors]] Link and description, to anchor in paragraph: [[#bc][BC]] * directorsDirectors Paragraph with a /dedicated target/: bc -[end] -- Reading the Manual (7.8.11), Section 4.2, this org code should, I think, export exactly as the old engine does it, with anchor href's linking to two targets (Firefox renders it perfectly): -- - Old HTML (output): p Link and description, to anchor in headline: a href=#directorsDirectors/a /p p Link and description, to anchor in paragraph: a href=#bcBC/a /p div id=outline-container-1 class=outline-2 h2 id=sec-1a name=directors class=targetdirectors/a Directors/h2 div class=outline-text-2 id=text-1 p Paragraph with a idedicated target/i: a name=bc class=targetbc/a BC /p /div /div -[end] -- The old engine is fine (if attuned to HTML4 more than HTML5). Here is the new output (Org-mode release_7.8.11-32-g02f3ee). -- - New HTML (output): p Link and description, to anchor in headline: iDirectors/i /p p Link and description, to anchor in paragraph: iBC/i /p div id=outline-container-1 class=outline-2 h2 id=sec-1a id=directors name=directors/Directors/h2 div class=outline-text-2 id=text-1 p Paragraph with a idedicated target/i: a id=bc name=bc/BC /p /div /div -[end] -- I see four discrepancies, in two groups: 1. Both links out (first two p's), to id's in an h and a p, do not generate links (a href=#foofoo/a). 2. At both anchors, a, in the h2 and the p, the a tag is not closed with an /a. This may be related to the errors noted in point one, as the HTML is malformed without them. I *really like* the direction the new engine is heading, with id attributes in a tags, and making the target non-visible. And tighter spacing. All good stuff! Many thanks for doing the heavy lifting! I look forward to your next commits. -BC Org-mode: 7.8.11 (release_7.8.11-32-g02f3ee) Emacs: 24.1.50.1 Windows 7 On Fri, Jun 1, 2012 at 9:38 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, William Crandall bc3141...@gmail.com writes:
Re: [O] Testing: org-export-e-html
Crandall There is some confusion on your end :-). - Org (input): Link and description, to anchor in headline: [[#directors][Directors]] Link and description, to anchor in paragraph: [[#bc][BC]] Remove the #es. * directorsDirectors Paragraph with a /dedicated target/: bc -[end] 1. Both links out (first two p's), to id's in an h and a p, do not generate links (a href=#foofoo/a). You are using targets. So you shouldn't use #es. This was what Nicolas was trying to tell you. 2. At both anchors, a, in the h2 and the p, the a tag is not closed with an /a. This may be related to the errors noted in point one, as the HTML is malformed without them. Put the HTML file in nxml-mode and do C-c C-n. I see no validation errors. The HTML file definitely is not malformed. [Context switch] Here is the modified Org file you should be using. When you are linking to headlines, use CUSTOM_IDs and *not* targets. Links to CUSTOM_IDs have a `#' in front while don't targets are *without* `#'es. --8---cut here---start-8--- Link and description, to anchor in headline: [[directors][Directors]] Link and description, to anchor in paragraph: [[bc][BC]] * directors Directors Paragraph with a /dedicated target/: bc * Headline wiith CUSTOM_ID :PROPERTIES: :CUSTOM_ID: director-1 :END: #+target: invisible * Recommendation about using links Always link to headline using [[#director-1][Headline wiith CUSTOM_ID]]. Use targets when you want to jump to obscure location [[bc]]. Never use [[invisible][Invisible target]]. They will disappear on export. For more information on how links are structured see the [[http://lists.gnu.org/archive/html/emacs-orgmode/2012-02/msg00752.html][this post]]. --8---cut here---end---8--- Btw, thanks for your patience and sticking it out right through to the end. Jambunathan K.
