Re: [O] Problem with org-insert-heading on multi-line items?
Tom Davey writes: > Hello Carsten, > > My apologies for the very tardy reply. You wrote me in June: > >> I believe this issue no longer exists in the current master, >> it was fixed a while ago. Could you please confirm? > > I just upgraded to 8.07, and unfortunately I don't believe it's fixed. > I'm finding the same behavior I described earlier: org-insert-heading > will add a checkbox to a new list item as long as the previous item > extends over two or more lines, even if no checkbox exists in that > previous item. Thanks much and sorry again for the delay in replying. > I can't reproduce this, but given that I could not reproduce Matt Lundin's infinite loop for the longest time (and still cannot consistently) I have to doubt myself: can we have a show of hands? -- Nick
Re: [O] three bugs/misfeatures in org-reveal (or is org-reveal the wrong way to reveal around point?)
Hi Sebastien, On 8/6/13, Sebastien Vauban wrote: > Just a question: did you play with the following settings? Yes. They don't seem to fix it. > --8<---cut here---start->8--- > ;; show full hierarchy when revealing a location > (setq org-show-hierarchy-above t) I always have this. > > ;; don't show following heading when revealing a location > (setq org-show-following-heading nil) Its default value is ((default)). Yet it shows the following heading anyway. Seems like a bug. > > ;; don't show all sibling headings when revealing a location > (setq org-show-siblings nil) Opposite of what I want. > > ;; show the entry below a headline when revealing a location > ;; (setq org-show-entry-below t) > (setq org-show-entry-below '((org-goto . t))) Setting it to t in some cases reveals a headline, then an ellipsis on a line by itself below that which stands for the entire subtree. I don't want ellipses in unusual places like that. It did not show the entry as it was supposed to. However, if it worked for me, I would use this variable. > Do they impact or resolve some of the things you consider as bugs? They do not resolve them. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] Problem with org-insert-heading on multi-line items?
Hello Carsten, My apologies for the very tardy reply. You wrote me in June: > I believe this issue no longer exists in the current master, > it was fixed a while ago. Could you please confirm? I just upgraded to 8.07, and unfortunately I don't believe it's fixed. I'm finding the same behavior I described earlier: org-insert-heading will add a checkbox to a new list item as long as the previous item extends over two or more lines, even if no checkbox exists in that previous item. Thanks much and sorry again for the delay in replying. Regards, Tom Davey -- Tom Davey t...@tomdavey.com New York NY USA
Re: [O] [PATCH] Emacs Org Babel Scheme (Geiser) support
Thanks for such a well-written, well-documented, and most of all useful contribution! Definitely a big improvement over my initial implementation. I've applied the patch to my system, but I'm having trouble getting it to work--I'm not getting any results. For example, this block: #+BEGIN_SRC scheme (display "This is the output") "This is the value" #+END_SRC Returns nil, whether I'm asking for output or value. I'm running emacs 23.4.1 on Debian wheezy, with Geiser 3.0. Could you send me a copy of your ob-scheme.el to help me track this down? Kind Regards, Mike
Re: [O] [BUG] Infinite loop in org-agenda-show-new-time
Oh, oh: I just tried following the steps in your last email and I *did* get the infinite loop, with the same backtrace that you did. Then I tried it again just now and it did not happen again. Is this thing not 100% reproducible? In any case, I'm working through the rest of your email. I should have more later on tonight. -- Nick
Re: [O] How to pass named table reference in source block variable
Thorsten Jolitz writes: > Roland Donat writes: > >> Hello, >> >> I have the following table : >> #+TBLNAME: T > > This does the job in Emacs Lisp: > > #+TBLNAME: T > | | x | 1 | > | ^ | | varx | > > #+begin_src emacs-lisp :var x=T[0,-1] > x > #+end_src > > #+results: > : 1 Nit: I believe #+TBLNAME is obsolete/deprecated/frowned upon - use #+name going forward. -- Nick
Re: [O] How to pass named table reference in source block variable
Roland Donat writes: > Hello, > > I have the following table : > #+TBLNAME: T > | | x | 1 | > | ^ | | varx | > > And I would like to use the reference T$var_x (=1) as input in a source block > variable. > For example, I would have expected the following behavior for this source > code : > #+begin_src python :var x=T$varx :return x > x > #+end_src > > #+RESULTS: > : 1 > > But instead, I get the emacs message : org-babel-ref-resolve: Reference > 'T$varx' not found in this > buffer > > Any idea to produce the desired result would be much appreciated! > > Thanks you in advance. > > Roland. This does the job in Emacs Lisp: #+TBLNAME: T | | x | 1 | | ^ | | varx | #+begin_src emacs-lisp :var x=T[0,-1] x #+end_src #+results: : 1 -- cheers, Thorsten
[O] How to pass named table reference in source block variable
Hello, I have the following table : #+TBLNAME: T | | x | 1 | | ^ | | varx | And I would like to use the reference T$var_x (=1) as input in a source block variable. For example, I would have expected the following behavior for this source code : #+begin_src python :var x=T$varx :return x x #+end_src #+RESULTS: : 1 But instead, I get the emacs message : org-babel-ref-resolve: Reference 'T$varx' not found in this buffer Any idea to produce the desired result would be much appreciated! Thanks you in advance. Roland.
[O] Babel support for evaluating CoffeeScript code blocks
Has anyone created a support for CoffeeScript? Obviously, putting it in the org-babel-load-languages allows me to edit code, however, evaluating this requires more. If no one has done this, can someone point me in a way to call out to the "coffee" command (or "node") instead of "moz"? Thanks for the help!
Re: [O] Trouble with Export
jh> For starters, =M-x org-export= is the old exporter. Yes, that's what I was running ... jh> Have you followed along with the upgrade guide? - jh>http://orgmode.org/worg/org-8.0.html Hadn't seen that yet ... thanks for the reference. jh> Please try =C-c C-e h h= and see if that fares any better. Yes, much better! Before, I'd used =C-c C-e h h=, but couldn't remember the key binding to invoke it. So, I was directly invoking 'org-export'. Sorry for the oversight ... still new to Org (coming from using Planner for *many* years) ... got a lot more to learn ... Thanks! -Kenneth PS Are there release notes somewhere for the latest 8.0.7? I tried http://orgmode.org/Changes.html, but it only referred to 8.0.3 ...
Re: [O] [BUG] Infinite loop in org-agenda-show-new-time
Nick Dokos writes: > So you revert that commit and the infloop goes away? I looked at the > functions briefly and I don't understand how this commit could affect > what move-to-column does. Just to confirm: Did you try rescheduling with the agenda buffer filtered only to the home tag using the sample file I provided? To trigger the bug one must attempt to reschedule an item when 1) the agenda is filtered by tags and 2) the item being changed contains invisible lines immediately beneath it (b/c of the filtering). Both these conditions are necessary to cause the bug on my end. When the agenda buffer is filtered to a tag (i.e., when it contains invisible lines), move-to-column treats the entire invisible region as a single line. Moving to the end of the line moves the point to the end of the entire invisible region. An easy way to see this behavior in action is to do the following: Take the following sample file (test.org): --8<---cut here---start->8--- * TODO A :home: SCHEDULED: <2013-08-06 Tue> * TODO B :work: SCHEDULED: <2013-08-06 Tue> * TODO C :play: SCHEDULED: <2013-08-06 Tue> --8<---cut here---end--->8--- 1. Call the agenda restricted to that file. --8<---cut here---start->8--- Day-agenda (W32): Tuesday 6 August 2013 test: Scheduled: TODO A :home: test: Scheduled: TODO B :work: test: Scheduled: TODO C :play: --8<---cut here---end--->8--- 2. Narrow an agenda buffer to the tag home. --8<---cut here---start->8--- Day-agenda (W32): Tuesday 6 August 2013 test: Scheduled: TODO A :home: --8<---cut here---end--->8--- 3. Move to the beginning of the task "A" line. 4. Call either M-x move-end-of-line or M-x move-to-column 100 (or another large number). 5. M-: (point) On my machine the point is at 287, which is at the at the end of the task "C" line (i.e., the end of the entire invisible region). If I call move-end-of-line on the task "A" line when the buffer is not filtered, the point moves to 125 - i.e., the end of the task A line. In other words, within the agenda buffer, move-to-column and move-end-of-line will move to the point to the end of the entire invisible region. That is why removing the local binding of buffer-invisibility-spec to nil triggers this bug, because when that variable is nil, the function org-agenda-show-new-time temporarily treats the agenda buffer as if it were visible (i.e., it ignores the invisible overlay). I reproduced the problem with emacs -Q, so I can confirm that it is not a result of my configuration. > org-move-to-column is just a compatibility function that calls > move-to-column whose doc says: > > Move point to column COLUMN in the current line. > > So I'm not sure why it ends up on a different line. I think the following explains why this is happening: (info "(elisp) Invisible Text") , |Ordinarily, functions that operate on text or move point do not care | whether the text is invisible. The user-level line motion commands | ignore invisible newlines if `line-move-ignore-invisible' is non-`nil' | (the default), but only because they are explicitly programmed to do so. | |However, if a command ends with point inside or at the boundary of | invisible text, the main editing loop relocates point to one of the two | ends of the invisible text. Emacs chooses the direction of relocation | so that it is the same as the overall movement direction of the | command; if in doubt, it prefers a position where an inserted char | would not inherit the `invisible' property. Additionally, if the text | is not replaced by an ellipsis and the command only moved within the | invisible text, then point is moved one extra character so as to try | and reflect the command's movement by a visible movement of the cursor. | |Thus, if the command moved point back to an invisible range (with | the usual stickiness), Emacs moves point back to the beginning of that | range. If the command moved point forward into an invisible range, | Emacs moves point forward to the first visible character that follows | the invisible text and then forward one more character. ` > Can you provide emacs and org versions? Maybe there is something weird > in what you use. (org-version) "Org-mode version 8.0.7 (release_8.0.7-367-gd1d918 @ /home/matt/org-mode/lisp/)" (emacs-version) GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.2) of 2013-07-30 on -var-lib
Re: [O] Trouble with Export
John Hendy writes: > The error .txt file looks pretty garbled... do you have an explanation > for that (piped through something that didn't work quite right), or > might you have an encoding/locale setup issue? > The OP was using compiled code when he got the backtrace. -- Nick
Re: [O] Trouble with Export
On Tue, Aug 6, 2013 at 10:42 AM, Kenneth Jacker wrote: > [ Ubuntu 12.04.2; org-8.0.7 ] > > I was working on this file (as well as other more complicated ones): > > * alpha > * beta >* b1 >* b2 > * gamma > > and I invoked 'org-export'. Entering an `h' produced these errors: > > For starters, =M-x org-export= is the old exporter. Have you followed along with the upgrade guide? - http://orgmode.org/worg/org-8.0.html Please try =C-c C-e h h= and see if that fares any better. The error .txt file looks pretty garbled... do you have an explanation for that (piped through something that didn't work quite right), or might you have an encoding/locale setup issue? John > > Tried to figure out what's wrong, but failed. The same behavior occurs > when using the prior 8.0.6. > > > Anyone have any ideas what's wrong? > > Thanks, > > -Kenneth > -- > Prof Kenneth H Jacker k...@cs.appstate.edu > Computer Science Dept www.cs.appstate.edu/~khj > Appalachian State Univ > Boone, NC 28608 USA > >
[O] Trouble with Export
[ Ubuntu 12.04.2; org-8.0.7 ] I was working on this file (as well as other more complicated ones): * alpha * beta * b1 * b2 * gamma and I invoked 'org-export'. Entering an `h' produced these errors: Exporting... (New file) org-export-preprocess-string: Wrong number of arguments: #[(&optional sort-only) "ÃÃ!  S  Ã_S ÃÂ* ÃÃ\"Â+ ÃPÃÃÂ56Ã7ÂebÂà Â6Âà 6@86A@98 Z Ã87\"Â:A@Âf TÂ;Ã68;Ât Ã:8<= Ã68b¨ 6A@Ã68|Â6A@bÂÃÃ;\"cÂ<¨ >¨ à Â:Âà Ã68º ÃÃ8!8?8;?<Ã9!¯7B7)-Â<