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. > * <>Directors > > Paragraph with a /dedicated target/: <> > > -[end] > 1. Both links out (first two p's), to id's in an and a , > do not generate links (foo). You are using targets. So you shouldn't use "#"es. This was what Nicolas was trying to tell you. > 2. At both anchors, , in the and the , the tag > is not closed with an . 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 Paragraph with a /dedicated target/: <> * 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.
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]] * <>Directors Paragraph with a /dedicated target/: <> -[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): Link and description, to anchor in headline: Directors Link and description, to anchor in paragraph: BC directors Directors Paragraph with a dedicated target: bc BC -[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): Link and description, to anchor in headline: Directors Link and description, to anchor in paragraph: BC Directors Paragraph with a dedicated target: BC -[end] -- I see four discrepancies, in two groups: 1. Both links out (first two p's), to id's in an and a , do not generate links (foo). 2. At both anchors, , in the and the , the tag is not closed with an . 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 tags, and making the <> 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 wrote: > > Hello, > > William Crandall writes: > >
[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] Smart Quotes Exporting
On 06/01/2012 01:11 PM, Nicolas Goaziou wrote: Hello, "Mark E. Shoulson" 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, y
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] 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 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] whole-adze dataset?
Greg Minshall 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] bug in selective export when selected heading follows excluded heading
Hi Eric, On Thu, May 31, 2012 at 11:10 PM, Eric S Fraga wrote: > Eric S Fraga 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.
[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] encoding problem
Bernt Hansen wrote: > Nick Dokos 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
Re: [O] encoding problem
Nick Dokos writes: > Bernt Hansen wrote: > >> Eric S Fraga writes: >> >> > Bernt Hansen writes: >> > >> >> Julien Cubizolles 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] Smart Quotes Exporting
Hello, "Mark E. Shoulson" 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] Testing: org-export-e-html
Hello,
William Crandall 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: directors
>new: directors
>
> 2. [[#directors]]
>old: #directors
>new: Directors
>
> 3. [[directors][Directors]]
>old: Directors
>new: Directors
>
> 4. [[#directors][Directors]]
>old: Directors
>new: Directors
>
>
> In no case is the output the same!
directors 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 tag (as the old version does).
> Other than that, "new" seems fine.
>
> ("Old" generates a 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 ):
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] encoding problem
Bernt Hansen wrote: > Eric S Fraga writes: > > > Bernt Hansen writes: > > > >> Julien Cubizolles 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] Setting user-defined properties while ido-mode is active
Jason Dunsmore 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
Eric S Fraga writes: > Bernt Hansen writes: > >> Julien Cubizolles 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] Annoying behavior of RET after a timestamp
Bastien wrote: > Hi Nick, > > Nick Dokos 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] 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 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] a line in BEGIN_SRC/END_SRC block disappeared when publishing
Hi Bastien,
On Fri, Jun 1, 2012 at 9:01 PM, Bastien wrote:
> Hi Liang,
>
> Liang Wang 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] Annoying behavior of RET after a timestamp
Hi Matt, Matt Lundin 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] Annoying behavior of RET after a timestamp
Hi Nick, Nick Dokos 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] 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 wrote: > Nick Dokos writes: > >> Bastien 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] 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] a line in BEGIN_SRC/END_SRC block disappeared when publishing
Hi Liang,
Liang Wang 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] make doc fails on current head
Nick Dokos writes: > Bastien 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] 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 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
[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] Windows (Cygwin) make: Works, but org-release(void)
Hi William, William Crandall 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
Re: [O] encoding problem
Bernt Hansen writes: > Julien Cubizolles 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] make doc fails on current head
Bastien 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] [PATCH] org-reload doesn't use full emacs load-path?
Achim Gratz 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] if both schedule and deadline, appear only once in agenda
SW 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] make doc fails on current head
Hi Bastien On Fri, Jun 1, 2012 at 9:48 AM, Bastien 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] bug in .texi?
Hi Samuel, Samuel Wales 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 Jonathan, Jonathan Leech-Pepin 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] make doc fails on current head
Hi Michael, I just reverted my commit, thanks. Michael Brand 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] Broken LaTeX export
SW writes: > Nick Dokos 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
