Re: [O] Remove the build-in orgmode
Thanks for the reply and the tips. Just add another small tip to this thread: `-Q`/`-q` skips ELPA load path. So we need to manually add the ELPA load path to the debugorg.el. It looks like that by default the ELPA org-mode load path is ~/.emacs.d/org/$DATE On Fri, Jun 6, 2014 at 10:57 PM, Thorsten Jolitz tjol...@gmail.com wrote: Achim Gratz strom...@nexgo.de writes: Nick Dokos writes: I did that in the past (presumably for reasons similar to Thorsten's) and I don't bother any longer (overriding is simple enough as you point out), but the question still bugs me: what's so bad about it? The reason it is bad is that parts of the code have already leaked out from the org/ directory via custom-load and autoloads and that's going to break things in the least convenient moment – for instance when you try to hunt down bugs via -Q. There simply is no way to remove the builtin Org from Emacs other than at build time and it's best not to pretend otherwise. Some day Emacs might actually treat its built-in packages as actual packages so that you can de-activate or replace them, but I wouldn't hold my breath. That sounds reasonable enough, but somehow that least convenient moment never happens, while I remember *many* such moments when I still had more than one Org on my machine ... but maybe I just don't huntdown bugs via -Q often enough. -- cheers, Thorsten
[O] patch: Oracle engine for SQL blocks
Hi, This patch makes Oracle a supported database for SQL source code blocks: - separate or unified logins, take your pick of: :dbuser user :dbpassword password :dbhost connect_id :dbuser user/password@connect_id :cmdline user/password@connect_id - support for :colnames on/off - helpful error messages in minibuffer if execution fails - good looking result block (most of the time) I've tested this extensively on Windows 7. It only needs the sqlplus executable and file redirection, so it should work everywhere. I am willing to execute an FSF copyright assignment. Regards, John 0001-ob-sql.el-Implement-Oracle-engine.patch Description: Binary data
[O] ditaa problem with latest org mode
I am wondering if anyone else running Mavericks (OSX 10.9.2) on a Mac is also having problems with ditaa? I'm running Emacs 24.3 and org-mode 8.2.6 Whenever I try to process some ditaa source code (either via an org file or even from the command line) using the version if ditaa that comes with org, I get the following unpleasant error ditaa version 0.9, Copyright (C) 2004--2009 Efstathios (Stathis) Sideris Exception in thread main java.lang.NoSuchMethodError: org.stathissideris.ascii2image.core.ConversionOptions.init(Lorg/apache/commons/cli/CommandLine;)V at org.stathissideris.ascii2image.core.CommandLineConverter.main(Unknown Source) even when running with the simplest of ditaa files. I get the same error if I use Apples Java (java 6) or Oracle's Java (java 7u60). PlantUML code runs like a charm, so it's something in the way Java is interacting with ditaa. It does work on a similar Mac (in the office) running OSX 10.7 with org mode 8.2.1, so I'm suspecting that there's something messed up with Mavericks. Is anyone else seeing this? Thanks, Adrian
Re: [O] [RFC] org-noweb: org-tangle + org-weave for literate programming using Org
2014-06-10 19:54 GMT+02:00 Grant Rettke g...@wisdomandwonder.com: On Tue, Jun 10, 2014 at 9:46 AM, Nicolas Girard girard.nico...@gmail.com wrote: - About =org-babel-use-quick-and-dirty-noweb-expansion=: should it be set to 't' by default ? I'd be tempted to say yes, given the dramatic performance gain Use Emacs to run Emacs Lisp and set org-babel-use-quick-and-dirty-noweb-expansion to nil. Hi Grant, thanks for your reply. There might be a slight misunderstanding though. My question was: should org-tangle and org-weave enable org-babel-use-quick-and-dirty-noweb-expansion before doing their jobs ? For now I let the default value to be =nil=, and I was wondering if it wouldn't be bette to do the opposite instead, that is, enable quick-and-dirty-noweb-expansion by default and provide a -noquick option. What do you think ? Cheers, Nicolas
Re: [O] Repeat work / week days
Nick Dokos ndokos at gmail.com writes: `C-c C-x c' (`org-clone-subtree-with-time-shift') Thanks. This looks like the best solution.
Re: [O] still seeing semi-regular lockups
Daimrod daim...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Daimrod daim...@gmail.com writes: I've attached part of the traces (the whole traces are way too big) and the backtraces. Thanks for looking into this. However, you are running a compiled Org, which renders backtraces less useful. Ok, I was wondering why the backtraces was so ugly, I didn't think about byte-compilation... Thanks for the tip. Also, you may want to disable cache refresh on idle time with, e.g., (setq org-element-cache-sync-idle-time 3600) It could make the bug easier to reproduce. Thanks, I'll try again this w.e. Okay, so I've found a more or less reliable way to reproduce this bug (on my machine at least). 1. $ emacs -Q -l debug.el test.org 2. Expand headline (S-TAB) 3. go below the first headline (C-n) 4. press `i' a couple of seconds ~10 chars 5. delete the line (C-a C-k) 6. goto 4 until if locks up As I said, it's not completely reliable but so far the lockup always happens. Sometimes it happens after the third iteration, sometimes after the tenth iteration, but it always happen. I've attached `debug.el' and `test.org'. `debug.el' setup the environment to reproduce the bug, you may need to change the path to your orgmode source base and you'll need `adaptive-wrap-prefix-mode' (available on ELPA). I've been able to reproduce the bug without `adaptive-wrap-prefix-mode' though other people have reported the same symptoms without using it. `test.org' is a simple org file with two headlines. It seems that two headlines are required to trigger the cache mechanism (with `org-element-cache--sync'). Do you confirm the lockup with this setting? Best, * i * i i debug.el Description: application/emacs-lisp -- Daimrod/Greg
Re: [O] Orgmode on Android.
Hallo John, On 10 June 2014 23:27, John Hendy jw.he...@gmail.com wrote: More information would be helpful. There is a setup procedure from the Emacs/Org side, and also from the Mobile-Org side. What, for example, did you do for the steps described here? - http://orgmode.org/manual/MobileOrg.html I will document my steps tonight and send it. And did you push from Emacs? Yes. There's too many variables here, so more steps and descriptions are probably going to be necessary. I wrote an ad-hoc howto in another post on the Org mailing list a couple months ago: - http://article.gmane.org/gmane.emacs.orgmode/82891 That might help walk through the steps to see if something might have gone awry? I suspect there is nothing wrong on my emacs-side because the MobileOrg on my Iphone is working. I recently bought an Android tablet and just wanted it there too. I have read last night (GMT+2) about a bug as far as something changed recently in the Dropbox API and I suspected that the problem might be related to it (https://github.com/matburt/mobileorg-android/wiki/FAQ): Because mobileorg-android still uses the deprecated v0 of the Dropbox API, you will need to file a Dropbox API support request from the developer site https://www.dropbox.com/developers and ask them to specifically enable your app keys to work with API v0. NOTE: I received this from Dropbox 3/27/14 in response to a request to enable my keys for API v0: Thanks for writing in. The old v0 version of the API is no longer available, so unfortunately I can't make it available for your app. There's a migration guide here though: https://www.dropbox.com/developers/reference/migration; I am not a developer (as far as orgmode is concerned) and i did not have time so far to look at the migration reference referred to in the above quote. Regards Johann Regards Johann
Re: [O] babel python example not reproducible
Works for me, see example below #+BEGIN_SRC python :results output :session foo x=100 print hello 2 print bye #+END_SRC #+RESULTS: : : hello : 2 : bye #+BEGIN_SRC python :results output :session foo print hello good bye print Printing value from previous session, x #+END_SRC #+RESULTS: : : hello good bye : Printing value from previous session 100 The only difference is that I like to give my session a name and for what it is worth I am using ipython (don't think this will make a difference). You can do this including the following statement in your .emacs file (setq python-shell-interpreter ipython) (setq python-shell-interpreter-args --pylab) Hope this help. Cheers, M
[O] Include TODO for once-off events?
I use the following to include once-off events in my Agenda: --8---cut here---start-8--- * Once-Off Task 2014-06-11 Wed 09:00 --8---cut here---end---8--- What is the difference (benefit) to rather doing this: --8---cut here---start-8--- * TODO Once-Off Task 2014-06-11 Wed 09:00 --8---cut here---end---8--- The second method gives me a red TODO in the Agenda and allows me to mark the task as DONE. Is that the primary reason for using TODO? If the state of a task is not important, there is no need to include TODO?
Re: [O] Include TODO for once-off events?
SabreWolfy sabrewo...@gmail.com writes: I use the following to include once-off events in my Agenda: * Once-Off Task 2014-06-11 Wed 09:00 What is the difference (benefit) to rather doing this: * TODO Once-Off Task 2014-06-11 Wed 09:00 The second method gives me a red TODO in the Agenda and allows me to mark the task as DONE. Is that the primary reason for using TODO? If the state of a task is not important, there is no need to include TODO? Yup, if you don't care about keeping track of the state of the task, there's not much point in using the todo keyword. But generally I think people use plain headlines + timestamps (no keyword) to keep track of _events_, and headlines plus a keyword to keep track of _tasks_. If it's a task that needs doing until it's done, then use a keyword, if only for the satisfaction of marking it finished. More to the point, the Agenda will only show you not-done todos -- picking and choosing what you want displayed in your agenda is one of the main reasons for using todo keywords. If it's just something like a meteor shower that will come and go, there's nothing for you to do, and hence no need for a todo keyword. E
Re: [O] ditaa problem with latest org mode
I'm on:
Emacs version: GNU Emacs 24.3.1 (x86_64-apple-darwin13.1.0, NS
apple-appkit-1265.19)
of 2014-04-24 on orion
Org version: 8.2.6
java version 1.8.0_05
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
ditaa0_9.jar
And org-babel-tangle on this
#+begin_src ditaa :file ditaa-simple.png :tangle no :exports both
+--+ +-+ +-+ +-+
|{io} | |{d} | |{s} | |cBLU |
| Foo +---+ Bar +---+ Baz +---+ Moo |
| | | | | | | |
+--+ +-+ +--+--+ +-+
|
/-\ | +--+
| | | | c1AB |
| Goo +--+---=--+ Shoo |
\-/ | |
+--+
#+end_src
Produces a png.
Grant Rettke | AAAS, ACM, ASA, FSF, IEEE, SIAM, Sigma Xi
g...@wisdomandwonder.com | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson
On Tue, Jun 10, 2014 at 9:29 PM, Adrian Burd adrianbur...@gmail.com wrote:
I am wondering if anyone else running Mavericks (OSX 10.9.2) on a Mac is
also having problems with ditaa? I'm running Emacs 24.3 and org-mode 8.2.6
Whenever I try to process some ditaa source code (either via an org file or
even from the command line) using the version if ditaa that comes with org,
I get the following unpleasant error
ditaa version 0.9, Copyright (C) 2004--2009 Efstathios (Stathis) Sideris
Exception in thread main java.lang.NoSuchMethodError:
org.stathissideris.ascii2image.core.ConversionOptions.init(Lorg/apache/commons/cli/CommandLine;)V
at org.stathissideris.ascii2image.core.CommandLineConverter.main(Unknown
Source)
even when running with the simplest of ditaa files.
I get the same error if I use Apples Java (java 6) or Oracle's Java (java
7u60).
PlantUML code runs like a charm, so it's something in the way Java is
interacting with ditaa.
It does work on a similar Mac (in the office) running OSX 10.7 with org mode
8.2.1, so I'm suspecting that there's something messed up with Mavericks.
Is anyone else seeing this?
Thanks,
Adrian
Re: [O] [RFC] org-noweb: org-tangle + org-weave for literate programming using Org
Understood. The quick and dirty approach removes the ability for headings to inherit the noweb properties of, and override, the properties of its parent header. That feature enables the true literate programming to remove it would be a great loss. Grant Rettke | AAAS, ACM, ASA, FSF, IEEE, SIAM, Sigma Xi g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson On Wed, Jun 11, 2014 at 3:18 AM, Nicolas Girard girard.nico...@gmail.com wrote: 2014-06-10 19:54 GMT+02:00 Grant Rettke g...@wisdomandwonder.com: On Tue, Jun 10, 2014 at 9:46 AM, Nicolas Girard girard.nico...@gmail.com wrote: - About =org-babel-use-quick-and-dirty-noweb-expansion=: should it be set to 't' by default ? I'd be tempted to say yes, given the dramatic performance gain Use Emacs to run Emacs Lisp and set org-babel-use-quick-and-dirty-noweb-expansion to nil. Hi Grant, thanks for your reply. There might be a slight misunderstanding though. My question was: should org-tangle and org-weave enable org-babel-use-quick-and-dirty-noweb-expansion before doing their jobs ? For now I let the default value to be =nil=, and I was wondering if it wouldn't be bette to do the opposite instead, that is, enable quick-and-dirty-noweb-expansion by default and provide a -noquick option. What do you think ? Cheers, Nicolas
[O] bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Nicolas Richard theonewiththeevill...@yahoo.fr writes: David Griffiths dogriffi...@gmail.com writes: Debugger entered--Lisp error: (error `recenter'ing a window that does not display current-buffer.) recenter((4)) org-overview() So that's a duplicate of #17724. It is fixed in org-mode (upstream) master branch. The easy fix is to use emacs-24 branch :) (otherwise just remove that call to recenter in org-overview). PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. -- Bastien
[O] bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Bastien b...@altern.org writes: PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. For me, fixing also org-fix-ellipsis-at-bol made all tests run as expected. -- Nico.
[O] bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Nicolas Richard theonewiththeevill...@yahoo.fr writes: Bastien b...@altern.org writes: PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. For me, fixing also org-fix-ellipsis-at-bol made all tests run as expected. What do you mean by fixing? Removing it entirely? -- Bastien
[O] bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
From: Bastien b...@altern.org Date: Wed, 11 Jun 2014 17:50:02 +0200 Cc: 17...@debbugs.gnu.org, David Griffiths dogriffi...@gmail.com PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. Say thanks to Stefan for flagging all those bugs ;-)
[O] bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Say thanks to Stefan for flagging all those bugs ;-) Now that I think about it, I should make `car' signal an error every 100th call, as well. Would flag many bugs (with some false positives, of course, but what's a few false positives among friends?)! Stefan
[O] bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
From: Stefan Monnier monn...@iro.umontreal.ca Cc: Bastien b...@altern.org, theonewiththeevill...@yahoo.fr, 17...@debbugs.gnu.org, dogriffi...@gmail.com Date: Wed, 11 Jun 2014 14:15:08 -0400 Say thanks to Stefan for flagging all those bugs ;-) Now that I think about it, I should make `car' signal an error every 100th call, as well. Would flag many bugs (with some false positives, of course, but what's a few false positives among friends?)! Not just 'car', 'cdr' as well, I'd say.
[O] bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Bastien b...@altern.org writes: Nicolas Richard theonewiththeevill...@yahoo.fr writes: Bastien b...@altern.org writes: PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. For me, fixing also org-fix-ellipsis-at-bol made all tests run as expected. What do you mean by fixing? Removing it entirely? Yes, I admit, I did : (defsubst org-fix-ellipsis-at-bol () nil) But I must have done something wrong or misread the results because now I see some other failures. Moreover, the backtrace that I get from make test seems incomplete and it's not obvious to me where the recenter call is made. OTOH I hope that wrapping every call to recenter in a (when (eq (current-buffer) (window-buffer)) (recenter ...)) would fix the tests, no ? -- Nico.
[O] org-mode and/versus make/makefiles
hi, all. if this is out of scope, or likely to be too much of a rat hole, please let me know (and otherwise ignore). occasionally, i work on something complicated enough that i feel the need of using make to manage dependencies, allow for cleaning up working directories (via make clean functionality), and generally organize the structure of my project (by forcing me to specify the various input files, output files (targets), and processes). but, when this happens, i have a hard time splitting the responsibilities for various parts of my build process between the makefile and the .org file. for example, i very much like writing small scripts in my .org file, rather than as stand-alone files. but, then if i decide to migrate the output of that script to the makefile, i have to split out the script to a separate file (and thus lose, or obfuscate, whatever version control history i have of that script). as another example, occasionally i feel i should have the .org file call out to the makefile, either to build something, or to retrieve some shared parameter (second-normal-form obsessiveness). or, have the makefile call the .org file, via some mechanism i've not explored, for similar reasons. then, if i have one calling the other calling the first... i'm wondering if anyone else, having wrestled with these issues, has any recipes for some approximation of happiness. or, some totally different approach i'm too set in my ways to see. cheers, Greg Minshall
Re: [O] org-mode and/versus make/makefiles
On Wed, Jun 11, 2014 at 2:24 PM, Greg Minshall minsh...@acm.org wrote: i'm wondering if anyone else, having wrestled with these issues, Yes. has any recipes for some approximation of happiness. or, some totally different approach i'm too set in my ways to see. For me it has been the same approach defined in the macro writers handbook: 1. Do it manually until I know how it works. 2. Make sure that it works well in a couple other places. 3. Automate it Sometimes it is just easier to explain to a human what is happening when you use a makefile because if you are using noweb references then you've already got a lot on your cognitive plate. My build is kind of basic, but it depends upon your perspective. The Makefile just makes it crystal clear, it prepares the document for tangling or does the weaving, nothing more, and for now that works fine. Use the best tool for the job, by your definition.
Re: [O] bug in exporter (org-babel-exp-process-buffer)
Charles C. Berry ccbe...@ucsd.edu writes:
When run with master, after the prompt for evaluating the src block,
an error is thrown. *Messages* shows
,
| Evaluate this emacs-lisp code block on your system? (y or n) y
| executing Emacs-Lisp code block...
| Code block evaluation complete.
| cond: Wrong type argument: integer-or-marker-p, nil
`
evidently the result of (goto-char ,head) with nil as the value of
head when trying to evaluate src_R{...}.
Adding the lines results in correct export with no prompt at the
(later) inline src block.
Applied to master. Thank you.
Regards,
--
Nicolas Goaziou
Re: [O] still seeing semi-regular lockups
Hello, Daimrod daim...@gmail.com writes: Okay, so I've found a more or less reliable way to reproduce this bug (on my machine at least). 1. $ emacs -Q -l debug.el test.org 2. Expand headline (S-TAB) 3. go below the first headline (C-n) 4. press `i' a couple of seconds ~10 chars 5. delete the line (C-a C-k) 6. goto 4 until if locks up As I said, it's not completely reliable but so far the lockup always happens. Sometimes it happens after the third iteration, sometimes after the tenth iteration, but it always happen. I've attached `debug.el' and `test.org'. [...] Do you confirm the lockup with this setting? Yes, I do. I will investigate on this soon. Thank you for providing this recipe. Regards, -- Nicolas Goaziou
Re: [O] Tangling with variables in R
Hi Rainer, Rainer M Krug rai...@krugs.de writes: Hi I just realized (again) that tangling with variables in R contains many particularities. 1) it only works with non-tables, i.e. single values. When defining the following variables: #+NAME: YEARS | | year | |---+---| | 1 | 1990 | | 2 | 2000 | #+PROPERTY: var+ YEARS=YEARS #+PROPERTY: var+ PRESENT=2008 I get the following code in the tangled .R file: , | YEARS - read.table(/var/folders/50/wcr5bjwn75q595n6x82gxj28gn/T/babel-97151aBD/R-import-97151vpn, | header=TRUE, | row.names=1, | sep=\t, | as.is=TRUE) | PRESENT - 2008 ` Variable transfer from tables does not work, as it is based on a temporary file, which is not easy to distribute together with the tangled.R file and requires manual work as the path will be different. I consider this as a bug which should be fixed. Me too, see http://thread.gmane.org/gmane.emacs.orgmode/51067 2) With regards to variables which are defined non-file wide, (i.e. in properties in a subtree and variables defined per code block and function call), these are set when they occur in the tangled code, but they are not unset *for the next code block* or *for R code in the next subtree* (I hope you know what I mean). They are therefore similar to the use of a session header argument instead of non-session evaluation of the code. This is a (conceptually) a more complex issue, and requires some initial thought on how this should be dealt with and how the tangled code should relate to the executed code. - Should the tangled .R file result in the same output as the execution in the org file, i.e. an accompanying .R file to a exported pdf, so that the .R file can be used to reproduce the graphs and analysis in the .pdf exported from the .org? or - Is tangling a completely thing to execution, and the resulting R code in the .R file is not expected to reproduce the results in the org file? - Finally, does tangling with variables makes sense? My opinions are a) *All* variables should be transferred to the .R file. This can be already disabled via the :no-expand header argument. Unfortunately, this is combined with noweb expansion, and it might be useful to split these two, i.e. to be able to only disable variable expansion but to keep noweb (I don't use noweb so far, so it is not a problem to me as it is now). b) The variable assignments should be per code block / function call. So a tangled block should look as follow: #+NAME: YEARS | | year | |---+---| | 1 | 1990 | | 2 | 2000 | #+PROPERTY: var+ YEARS=YEARS #+PROPERTY: var+ PRESENT=2008 #+begin_src R x - 4 cat(x^2) #+end_src should result in something like the following: , | ## # Set the variables | YEARS - TRANSFER_TABLE() | PRESENT - TRANSFER_VALUE() | ## Here begins the real code | x - 4 | cat(x^2) | ## # Unset all variables previously set ` but I prefer the following approach, as the result would be very similar, only that the variables are still present afterwards which would make debugging easier: , | ## # Unset all variables previously set | ## # Set the variables | YEARS - TRANSFER_TABLE() | PRESENT - TRANSFER_VALUE() | ## Here begins the real code | x - 4 | cat(x^2) ` This is effectively already implemented by using R environments. See [1] and particularly [2] and [3] for how it is implemented. This does not yet address the concern about the transfer of tables, but I will look at this. These are good thoughts! For the general question on whether tangling should directly reflect weaving, there was a long (and fruitless) discussion or R-devel lately. See http://thread.gmane.org/gmane.comp.lang.r.devel/36031 and maybe http://thread.gmane.org/gmane.comp.lang.r.devel/36031/focus=36075 where Yihui states that it is very hard to tangle code that produces the same result as weaving. This might actually be easier in org than in Sweave/knitr, but still the org setup will have a big impact, that would be hard to replicate in the tangled R code. Setting aside the general question: In my opinion, it should definitely be possible to tangle with variables. I think the approach of the environments to address (2) is a good one. Apologies for a long post, but I would like to know which direction of the tangling / variable transfer from org to R should take - I don't want to spend a lot of time solving a problem which does not really exist. So - any comments? Suggestions? See above. And thanks for your work on ob-R! Keep it up! Thanks, Rainer Footnotes: [1] https://github.com/rkrug/orgmode-dev [2] https://github.com/rkrug/orgmode-dev/blob/R-env/lisp/ob-R.el [3] https://github.com/rkrug/orgmode-dev/blob/R-env/etc/R/org_functions.R Best, Andreas
Re: [O] still seeing semi-regular lockups
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Daimrod daim...@gmail.com writes: Okay, so I've found a more or less reliable way to reproduce this bug (on my machine at least). 1. $ emacs -Q -l debug.el test.org 2. Expand headline (S-TAB) 3. go below the first headline (C-n) 4. press `i' a couple of seconds ~10 chars 5. delete the line (C-a C-k) 6. goto 4 until if locks up As I said, it's not completely reliable but so far the lockup always happens. Sometimes it happens after the third iteration, sometimes after the tenth iteration, but it always happen. I've attached `debug.el' and `test.org'. [...] Do you confirm the lockup with this setting? Yes, I do. I will investigate on this soon. Thank you for providing this recipe. Cool! Also, I should have mentioned that I didn't trace the function `org-element--cache-key-less-p' because when I do so, Emacs stays locked even when I send it the signal SIGUSR2. However, this function appears in the backtrace produced by `xbacktrace' in a gdb session if I call it during a lockup. My guess is that the lockup happens in `org-element--cache-key-less-p', called by `org-element--cache-process-request'. Best, -- Daimrod/Greg
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Bastien b...@altern.org writes: Nicolas Richard theonewiththeevill...@yahoo.fr writes: David Griffiths dogriffi...@gmail.com writes: Debugger entered--Lisp error: (error `recenter'ing a window that does not display current-buffer.) recenter((4)) org-overview() So that's a duplicate of #17724. It is fixed in org-mode (upstream) master branch. The easy fix is to use emacs-24 branch :) (otherwise just remove that call to recenter in org-overview). PS: The change about throwing an error when recentering a window that does not display the current buffer breaks ~37 tests in Org master branch, even with this fix. I need to digg this further. Err, what's the rational behind this change? In the meantime I've a simple fix (quickly tested for `org-agenda' which was also broken). From 659bc5072253967ee2737f668c8ac035a4b8aa32 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gr=C3=A9goire=20Jadi?= gregoire.j...@gmail.com Date: Thu, 12 Jun 2014 10:14:16 +0900 Subject: [PATCH] Use `org-recenter' as a wrapper around `recenter' * lisp/org.el (org-recenter): New function that behaves exactly like `recenter' except that it sets the `current-buffer' to the buffer displayed by the selected window. (org-fix-ellipsis-at-bol) (org-optimize-window-after-visibility-change) (org-first-headline-recenter) * contrib/lisp/org-index.el (org-index) (org-index--create-new-index) (org-index--do-head) * contrib/lisp/org-toc.el (org-toc-goto) * lisp/org-agenda.el (org-agenda-list) (org-agenda-redo) (org-recenter-heading) (org-agenda-recenter) * lisp/org-bibtex.el (org-execute-file-search-in-bibtex) * lisp/org-clock.el (org-clock-goto) * lisp/org-table.el (org-table-show-reference): Use `org-recenter' instead of `recenter'. --- contrib/lisp/org-index.el | 12 ++-- contrib/lisp/org-toc.el | 4 ++-- lisp/org-agenda.el| 12 ++-- lisp/org-bibtex.el| 2 +- lisp/org-clock.el | 2 +- lisp/org-table.el | 4 ++-- lisp/org.el | 13 + 7 files changed, 27 insertions(+), 22 deletions(-) diff --git a/contrib/lisp/org-index.el b/contrib/lisp/org-index.el index 64974eb..f77d64d 100644 --- a/contrib/lisp/org-index.el +++ b/contrib/lisp/org-index.el @@ -633,7 +633,7 @@ command \head\ for reference \237\. ;; simply go into table (goto-char org-index--below-hline) (show-subtree) - (recenter) + (org-recenter) (if what-adjusted (setq message-text Nothing to search for; at index table) (setq message-text At index table))) @@ -1581,7 +1581,7 @@ retrieves the value of the count-column for reference 12. (org-id-goto id) (org-show-context) (show-subtree) -(recenter 1) +(org-recenter 1) (setq org-index-id id) (if (y-or-n-p This is your new index table. It is already set for this emacs session. Do you want to save its id to make it available for future emacs sessions too ? ) (progn @@ -1598,7 +1598,7 @@ retrieves the value of the count-column for reference 12. (goto-char org-index--point) (org-show-context) (show-subtree) -(recenter 1) +(org-recenter 1) (delete-other-windows) ;; show new index (select-window (split-window-vertically)) @@ -1606,7 +1606,7 @@ retrieves the value of the count-column for reference 12. (org-id-goto id) (org-show-context) (show-subtree) -(recenter 1) +(org-recenter 1) (error Please compare your existing index (upper window) and a temporary new one (lower window) to correct the previous error (\%s\); the explanations following the new index table should help. reason) @@ -1778,12 +1778,12 @@ retrieves the value of the count-column for reference 12. (pop-to-buffer buffer) (goto-char point) (org-reveal t) -(recenter) +(org-recenter) (pop-to-buffer *org-index-occur*)) (org-pop-to-buffer-same-window buffer) (goto-char point) (org-reveal t) -(recenter))) +(org-recenter))) (setq message-text (format Did not find '%s' (or ref link)) message-text)) diff --git a/contrib/lisp/org-toc.el b/contrib/lisp/org-toc.el index 255b79e..e06de55 100644 --- a/contrib/lisp/org-toc.el +++ b/contrib/lisp/org-toc.el @@ -294,8 +294,8 @@ If CYCLE is non-nil, cycle the targeted subtree in the Org window. (org-show-entry)) (org-show-context))) (if org-toc-recenter-mode - (if (= org-toc-recenter 1000) (recenter) - (recenter org-toc-recenter))) + (if (= org-toc-recenter 1000) (org-recenter) + (org-recenter org-toc-recenter))) (cond ((null jump) (switch-to-buffer-other-window toc-buf)) ((eq jump 'delete) diff --git
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
+(defun org-recenter (optional arg) + Like `recenter' but ensure that the `current-buffer' is +properly set. + (with-current-buffer (window-buffer) +(recenter arg))) This doesn't make much sense: in many case (window-buffer) can be a buffer completely unrelated to Org. Stefan
[O] bug#17746: bug#17746: 24.4.50; byte-code: `recenter'ing a window that does not display current-buffer. when composing a message
Stefan Monnier monn...@iro.umontreal.ca writes: +(defun org-recenter (optional arg) + Like `recenter' but ensure that the `current-buffer' is +properly set. + (with-current-buffer (window-buffer) +(recenter arg))) This doesn't make much sense: in many case (window-buffer) can be a buffer completely unrelated to Org. Hmm, what was the previous behaviour of `recenter'? (i.e. before it reports an error) Did it just do nothing? Best, -- Daimrod/Greg
[O] How to escape an asterisk on org-mode
Hi Org Mode: I'm trying to escape an asterisk character, i.e. * to use in regular text. I.e., The person wanted to say *BSD. And I don't want to use a verbatim or code block because monospace is not what I need. I've tried \* to escape the character and it doesn't work. I'm on Org 8.2.5h. Thanks in advance.
[O] [Patch] Create org-gnus links to real groups, not virtual groups
If you create a link to a gnus message while in a nnvirtual group, the link will become un-followable as soon as you exit the virtual group. This patch checks to see if we're in a virtual group, and if so it creates the link to the original group instead. E From 2d1dbbeb071e256ff37be798e8e04689a40665c8 Mon Sep 17 00:00:00 2001 From: Eric Abrahamsen e...@ericabrahamsen.net Date: Thu, 12 Jun 2014 12:53:15 +0800 Subject: [PATCH] Create org-gnus links from original group, not virtual lisp/org-gnus.el (org-gnus-store-link): If we happen to be in a virtual group when storing a link to a message, we want the link to point to the message's real group, as a link to a virtual group can't be followed later. --- lisp/org-gnus.el | 4 1 file changed, 4 insertions(+) diff --git a/lisp/org-gnus.el b/lisp/org-gnus.el index 2c79347..48afb3c 100644 --- a/lisp/org-gnus.el +++ b/lisp/org-gnus.el @@ -170,6 +170,10 @@ If `org-store-link' was called with a prefix arg the meaning of (subject (copy-sequence (mail-header-subject header))) (to (cdr (assq 'To (mail-header-extra header newsgroups x-no-archive desc link) + (when (eq (car (gnus-find-method-for-group gnus-newsgroup-name)) + 'nnvirtual) + (setq group (car (nnvirtual-map-article + (gnus-summary-article-number) ;; Remove text properties of subject string to avoid Emacs bug ;; #3506 (set-text-properties 0 (length subject) nil subject) -- 2.0.0
Re: [O] How to escape an asterisk on org-mode
James Ryland Miller james.ryland.mil...@gmail.com writes: Hi Org Mode: I'm trying to escape an asterisk character, i.e. * to use in regular text. I.e., The person wanted to say *BSD. And I don't want to use a verbatim or code block because monospace is not what I need. I've tried \* to escape the character and it doesn't work. I'm on Org 8.2.5h. *What* doesn't work? Since you don't tell us, I tried exporting the following to latex and html: --8---cut here---start-8--- * foo The person wanted to say *BSD. --8---cut here---end---8--- and it works fine in both cases (albeit in Org-mode version 8.2.6 (release_8.2.6-1122-g1d7c75)). -- Nick
