Re: [O] long delay after selecting capture template
Eric S Fragawrites: > I've had this problem in the past. I found that setting this variable helps: > > ,[ C-h v x-selection-timeout RET ] > | x-selection-timeout is a variable defined in ‘C source code’. > | Its value is 10 > | > | Documentation: > | Number of milliseconds to wait for a selection reply. > | If the selection owner doesn’t reply in this time, we give up. > | A value of 0 means wait as long as necessary. This is initialized from the > | "*selectionTimeout" resource. > ` > > For me, a value of 10 works well in most cases. Sometimes this means > that the selection from another application (e.g. the browser) is not > found but at least it doesn't stall. Thanks, mine was set to 5000. Seems like I've seen it stall for longer than 5 seconds, but perhaps in those cases one of the primary or clipboard selections timed out as well. I'm on OpenBSD by the way. -- Allan Streib Indiana University School of Informatics and Computing Digital Science Center :: Community Grids Lab :: FutureSystems Allan
Re: [O] long delay after selecting capture template
On Thursday, 24 Mar 2016 at 09:27, Allan Streib wrote: [...] > Debugging the function, the "stall" happens on the indicated line below, > the call to org-get-x-clipboard with the value 'SECONDARY [...] > I've heard of primary and clipboard X11 selections, but not secondary. I > found a web post[1] suggesting it's a "near-extinct" feature. > > If I comment out that line the delay vanishes. I've had this problem in the past. I found that setting this variable helps: ,[ C-h v x-selection-timeout RET ] | x-selection-timeout is a variable defined in ‘C source code’. | Its value is 10 | | Documentation: | Number of milliseconds to wait for a selection reply. | If the selection owner doesn’t reply in this time, we give up. | A value of 0 means wait as long as necessary. This is initialized from the | "*selectionTimeout" resource. ` For me, a value of 10 works well in most cases. Sometimes this means that the selection from another application (e.g. the browser) is not found but at least it doesn't stall. HTH, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-668-g809a83
Re: [O] long delay after selecting capture template
Allan Streibwrites: > Eric Abrahamsen writes: > >> Another thing you can try is edebugging `org-capture-fill-template' and >> stepping through it, and just see if anything weird happens. See the >> Elisp manual for how to edebug, if you haven't before. >> >> Does it only happen for the "t" template? What's the "t" template look >> like? > > I've really just started with org mode and task capture; so far I've > only used the default "todo" (t) template. > > Debugging the function, the "stall" happens on the indicated line below, > the call to org-get-x-clipboard with the value 'SECONDARY > > [...] > >;; Is the link empty? Then we do not want it... >(v-a (if (equal v-a "[[]]") "" v-a)) >(clipboards (remove nil (list v-i > (org-get-x-clipboard 'PRIMARY) > (org-get-x-clipboard 'CLIPBOARD) >>>> (org-get-x-clipboard 'SECONDARY) <<< > v-c))) > > [...] > > I've heard of primary and clipboard X11 selections, but not secondary. I > found a web post[1] suggesting it's a "near-extinct" feature. > > If I comment out that line the delay vanishes. Well that's some fairly successful sleuthing. The bad news is you know now as much as (or more than) I do about your problem, and I don't know what to tell you from here. I'd say tell the list what system you're using, and what desktop environment, and hope someone has some wisdom to bestow. Otherwise... just comment that line out. E
Re: [O] long delay after selecting capture template
Eric Abrahamsenwrites: > Another thing you can try is edebugging `org-capture-fill-template' and > stepping through it, and just see if anything weird happens. See the > Elisp manual for how to edebug, if you haven't before. > > Does it only happen for the "t" template? What's the "t" template look > like? I've really just started with org mode and task capture; so far I've only used the default "todo" (t) template. Debugging the function, the "stall" happens on the indicated line below, the call to org-get-x-clipboard with the value 'SECONDARY [...] ;; Is the link empty? Then we do not want it... (v-a (if (equal v-a "[[]]") "" v-a)) (clipboards (remove nil (list v-i (org-get-x-clipboard 'PRIMARY) (org-get-x-clipboard 'CLIPBOARD) >>> (org-get-x-clipboard 'SECONDARY) <<< v-c))) [...] I've heard of primary and clipboard X11 selections, but not secondary. I found a web post[1] suggesting it's a "near-extinct" feature. If I comment out that line the delay vanishes. Footnotes: [1] https://sjohannes.wordpress.com/2010/02/28/what-is-the-x11-secondary-selection/ Allan
Re: [O] long delay after selecting capture template
Eric Abrahamsenwrites: > I guess I would `toggle-debug-on-quit', then call capture, and while > you're waiting for it to return, hit "C-g". That ought to pop up a > backtrace, and you can see what code was being executed during the > delay. It might be obvious what's wrong, or you can post the backtrace > here. I tried this but get no backtrace. Messages buffer contains: Debug on Quit enabled globally Template key: byte-code: Capture abort: (quit) At the "Template key:" prompt, I had typed t, then C-g Allan
Re: [O] long delay after selecting capture template
Allan Streibwrites: > Hi, > > When I want to capture a task I hit C-c c and then t to select the task > template. > > Between striking the t key and seeing the template rendered, there is a > delay of several seconds (sometimes up to 10 seconds). No errors are > logged and the template eventually displays and everything is normal. > > As the whole point of capturing is to quickly log task items and get > back to the primary work at hand, this delay can be annoying. Any > suggestions at where to look to resolve this? I guess I would `toggle-debug-on-quit', then call capture, and while you're waiting for it to return, hit "C-g". That ought to pop up a backtrace, and you can see what code was being executed during the delay. It might be obvious what's wrong, or you can post the backtrace here. Yours, Eric
[O] long delay after selecting capture template
Hi, When I want to capture a task I hit C-c c and then t to select the task template. Between striking the t key and seeing the template rendered, there is a delay of several seconds (sometimes up to 10 seconds). No errors are logged and the template eventually displays and everything is normal. As the whole point of capturing is to quickly log task items and get back to the primary work at hand, this delay can be annoying. Any suggestions at where to look to resolve this? GNU Emacs 24.5.1 (x86_64-unknown-openbsd, X toolkit, Xaw3d scroll bars) of 2015-10-19 Org-mode version 8.2.10 (release_8.2.10 @ /usr/local/share/emacs/24.5/lisp/org/) Thanks, Allan
Re: [O] long delay after selecting capture template
Allan Streibwrites: > Eric Abrahamsen writes: > >> I guess I would `toggle-debug-on-quit', then call capture, and while >> you're waiting for it to return, hit "C-g". That ought to pop up a >> backtrace, and you can see what code was being executed during the >> delay. It might be obvious what's wrong, or you can post the backtrace >> here. > > I tried this but get no backtrace. Messages buffer contains: > > > Debug on Quit enabled globally > Template key: > byte-code: Capture abort: (quit) Ah, the org-capture code condition-cases quit. At least we know that the problem is in `org-capture-fill-template'! I can't remember off the top of my head if there's a way to tell emacs to actually debug on quit, even if quit is handled by `condition-case'. Another thing you can try is edebugging `org-capture-fill-template' and stepping through it, and just see if anything weird happens. See the Elisp manual for how to edebug, if you haven't before. Does it only happen for the "t" template? What's the "t" template look like? Eric