Re: Google SoC organisation application
> Google's SoC organisation applications are currently open, and close on > <2020-02-20>. I know that Org participated once, in 2012. > > Would it be a good idea to submit an application to do so again? > With the rise in interest in computational notebooks, blogging tools, > and other features that Org possesses I'd imagine we have a decent shot. > > If so, we have just over two weeks to do so. Note that, as always, the GNU Project will be applying as a mentoring organization [1] [2]. This means that, in case org-mode doesn't apply or doesn't get admitted as a mentoring organization (and of course assuming GNU is accepted) org-related projects can still be done under the overall GNU umbrella. Salud! [1] http://www.gnu.org/s/soc-projects [2] https://lists.gnu.org/archive/html/summer-of-code/
Google SoC organisation application
Hello All, Google's SoC organisation applications are currently open, and close on <2020-02-20>. I know that Org participated once, in 2012. Would it be a good idea to submit an application to do so again? With the rise in interest in computational notebooks, blogging tools, and other features that Org possesses I'd imagine we have a decent shot. If so, we have just over two weeks to do so. All the best, Timothy.
Re: Google SoC organisation application
On 02/02/2021 10:54, TEC wrote: > Hello All, > > Google's SoC organisation applications are currently open, and close on > <2020-02-20>. I know that Org participated once, in 2012. > > Would it be a good idea to submit an application to do so again? > With the rise in interest in computational notebooks, blogging tools, > and other features that Org possesses I'd imagine we have a decent shot. Applying only makes sense if there are concrete ideas about projects suitable for GSoC participants and if only if there are Org contributors that can work as mentors. Suitable projects should be of the right level of complexity for the students to have a chance to have them implemented in the allotted time, which this year is not much, and have a clear design approved by the Org maintainers, so that most of the time available to the students will not be spent discussing it. Do you have any idea about suitable projects? However, I I think the availability of mentors can be the hardest requirement. I think that it would not be fair for the students if the code they would produce does not have good chances to entering the code base in a timely fashion. Thus, mentors (or, at least, co-mentors) should be among the Org maintainers. Is anyone available? Please understand that the GSoC is not a way to get labor for the project sponsored by Google: it is very likely that the time investment required to the mentors would be more than enough to implement what the students will do during the GSoC. The GSoC is more an opportunity to form a possible future long term contributor to the project. Cheers, Dan
Re: Google SoC organisation application
All good points, but I'll just quickly respond to this: Daniele Nicolodi writes: > Please understand that the GSoC is not a way to get labor for the > project sponsored by Google: it is very likely that the time investment > required to the mentors would be more than enough to implement what the > students will do during the GSoC. The GSoC is more an opportunity to > form a possible future long term contributor to the project. As it happens, this is precisely why I decided to start this thread. I see GSoC as a great chance to help people who have been tentatively considering getting into Org development a little push and hopefully create some new long-term contributors :) With projects, I know I at least have no shortage of ideas; mentors might be hard though 樂. -- Timothy
Re: patch: ob-clojure improvements
<#secure method=pgpmime mode=sign>
Hi, Tim, popup this thread to request review.
Tim Cross writes:
I am also interested in ob-clojure and ob-clojurescript improvements. However,
right now, I'm a tad busy and haven't had time to review what has been done.
Hopefully, can make some time in the next month or so.
Tim
stardiviner writes:
agzam.ibragi...@gmail.com writes:
There seems to be a bit of lack of interest for these things. But I'm sure some
people (myself included) would love to see these kinds of improvements.
Yes, I rarely saw Clojurians in this mailing list.
As I said before, I have never participated in contributing to Org source, some
guidance would be appreciated.
Org Mode has contribution guide here
http://orgmode.org/worg/org-contribute.html#patches
Should I keep building it and posting patches? Should I try to go
incrementally, one small change at a time, or should I just get everything
working first? If it turns out to be a bigger work, should I ask for permission
to work in a branch and get access to pushing things to it? Maybe things just
move slowly, because obviously you can't force maintainers to drop everything
and concentrate effort to get your things in. Maybe I just have to be a little
bit more patient?
I think a complete work contains many patches should be better, Also write
testing if necessary.
I remember ob-clojure.el code are mostly reviewed by Bastien Guerry. I included
him in Cc: in this email.
On Sat, Jun 20, 2020 at 1:23 AM stardiviner wrote:
Glad to see your patch, really useful in some cases. Thanks.
Ag Ibragimov writes:
Hi everyone, here's my attempt to add clojure CLI and babashka support
for ob-clojure.el
- Adds a header parameter to override org-babel-clojure-backend - Adds :args
param (right now only used for clojure-cli)
I have tested it with these minimal cases:
#+beginsrc clojure :backend clj-cli :args "-Sdeps '{:deps {inflections
{:mvn/version \"0.13.2\"}}}'"
(use 'inflections.core) (plural "word") #+endsrc
#+beginsrc clojure :backend babashka :results output (range 10) #+endsrc
Please let me know what you think. Any advice is appreciated, since I
have never contributed before. Thank you.
– [ stardiviner ] I try to make every word tell the meaning that I want to
express.
Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix:
stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
--
[ stardiviner ]
I try to make every word tell the meaning that I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
Re: Google SoC organisation application
Jose E. Marchesi writes: >> Google's SoC organisation applications are currently open, and close on >> <2020-02-20>. I know that Org participated once, in 2012. >> >> Would it be a good idea to submit an application to do so again? >> With the rise in interest in computational notebooks, blogging tools, >> and other features that Org possesses I'd imagine we have a decent shot. >> >> If so, we have just over two weeks to do so. > > Note that, as always, the GNU Project will be applying as a mentoring > organization [1] [2]. That's nice, I don't see Org listed under https://www.gnu.org/software/soc-projects/ideas-2020.html but good to know (particularly for any SoC eligible people reading this ML) :) If nothing else, I think it could be worth applying separately for the extra recognition, and perhaps Google might approve more applications when Org and GNU are both listed? I don't really know how this works in depth though. -- Timothy
Re: [PATCH] Query when exiting with running clock
Allen Li writes: > This is a patch adding a query function when exiting Emacs, warning the > user if there is a running clock. This is useful for preventing the > user from accidentally leaving dangling clocks. I have had success > using a modified personal version of this code. Thanks. I'd find this useful as well. > My personal version instead prompts the user to clock out and save the > buffer. I didn't use it for the patch because it seems a little hacky > to me; e.g., kill-emacs-query-functions doesn't mention whether > functions can have side effects, and the UI is inconsistent with > save-buffers-kill-emacs. The code for my personal version: Fwiw that's what Emacs's lisp/calendar/timeclock.el does: (defun timeclock-query-out () "Ask the user whether to clock out. This is a useful function for adding to `kill-emacs-query-functions'." (and (equal (car timeclock-last-event) "i") (y-or-n-p "You're currently clocking time, clock out? ") (timeclock-out)) ;; Unconditionally return t for `kill-emacs-query-functions'. t) > Subject: [PATCH 1/2] org-clock: Replace org-clocking-buffer with > org-clock-is-active > > org-clocking-buffer and org-clock-is-active have the same definition. > org-clocking-buffer is defined in org-clock.el while > org-clock-is-active is defined in org.el. org-clock.el requires > org.el. > > org-clocking-buffer is kept as an alias to preserve backward > compatibility with any user code. Dropping the duplicate definitions using an alias sounds good, though as I mention below I'd prefer the spots that are specifically concerned with a buffer to keep using the org-clocking-buffer name. > * lisp/org-clock.el (org-clocking-buffer): Changed to alias. > (org-clocking-p): Changed reference to org-clocking-buffer. > (org-clock-out): Changed reference to org-clocking-buffer. > (org-clock-cancel): Changed reference to org-clocking-buffer. > (org-clock-sum): Changed reference to org-clocking-buffer. > (org-clock-out-if-current): Changed reference to org-clocking-buffer. > (org-clock-save): Changed reference to org-clocking-buffer. > --- > lisp/org-clock.el | 20 +--- > 1 file changed, 9 insertions(+), 11 deletions(-) > > diff --git a/lisp/org-clock.el b/lisp/org-clock.el > index 892ae1810..37459580b 100644 Hmm, this patch doesn't apply to the current master (041459727). The preimage blob is quite old: $ git describe 892ae1810 release_8.2.7b-7-gbacfe5b4f:lisp/org-clock.el $ git log --oneline --format="%h %cd" --find-object=892ae1810 ca21b7b86 Mon Jan 12 12:35:10 2015 +0100 bacfe5b4f Fri Jul 25 11:02:55 2014 +0200 > --- a/lisp/org-clock.el > +++ b/lisp/org-clock.el > @@ -503,13 +503,11 @@ of a different task.") >(mapc (lambda (m) (org-check-and-save-marker m beg end)) > org-clock-history)) > > -(defun org-clocking-buffer () > - "Return the clocking buffer if we are currently clocking a task or nil." > - (marker-buffer org-clock-marker)) > +(defalias 'org-clocking-buffer #'org-clock-is-active) > > (defun org-clocking-p () >"Return t when clocking a task." > - (not (equal (org-clocking-buffer) nil))) > + (not (equal (org-clock-is-active) nil))) Eh, so this too could just be an alias to org-clock-is-active, or, if it looks like any callers really depend on this being t rather than just non-nil (but why would they?), `(and (org-clock-is-active) t)' would be better. Anyway, I know you're just doing the plain substitution here, so I'm fine keeping it at that. > > (defvar org-clock-before-select-task-hook nil >"Hook called in task selection just before prompting the user.") > @@ -1501,7 +1499,7 @@ to, overriding the existing value of > `org-clock-out-switch-to-state'." > ts te s h m remove) >(setq org-clock-out-time now) >(save-excursion ; Do not replace this with `with-current-buffer'. > - (org-no-warnings (set-buffer (org-clocking-buffer))) > + (org-no-warnings (set-buffer (org-clock-is-active))) This is an example of a spot that I think should continue using the org-clocking-buffer variant for readability. And scanning the other spots in this patch, I think they actually all fall into this category. > Subject: [PATCH 2/2] org-clock: Query when exiting with running clock > > It's annoying to accidentally quit Emacs with a running clock, then > resolve the clock the next time when Emacs is started. > > * lisp/org-clock.el (org-clock-kill-emacs-query): New function. > --- > lisp/org-clock.el | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/lisp/org-clock.el b/lisp/org-clock.el > index 37459580b..bc1762f63 100644 > --- a/lisp/org-clock.el > +++ b/lisp/org-clock.el > @@ -2886,6 +2886,15 @@ The details of what will be saved are regulated by the > variable > (if (outline-invisible-p) > (org-show-context)) > > +(defun org-clock-kill-emacs-query () > + "Query user when killing Emacs. > +This function
Re: Free up C-c SPC/org-table-blank-field?
Kyle Meyer writes: > Eric Abrahamsen writes: > >> Hi all, >> >> The C-c SPC keybinding is pretty prime property (it's also, according to >> Emacs conventions, meant to be reserved for the user, though I know >> that's already out the window with Org), > > Based on my reading of (info "(elisp)Key Binding Conventions"), I think > `C-c SPC` doesn't fall into the user's `C-c LETTER' territory but > instead into the this group: > > Sequences consisting of ‘C-c’ followed by any other ASCII > punctuation or symbol character are allocated for minor modes. > Using them in a major mode is not absolutely prohibited, but if you > do that, the major mode binding may be shadowed from time to time > by minor modes. > Agreed. > But, either way, I don't disagree with what you say next. > >> and it's currently bound to `org-table-blank-field', which is useless >> unless you... happen to be in a table. I don't use tables often (or >> blank fields when I do), which means this binding is effectively just >> removed. Does it actually need a key binding? I've never used it and just use to move to the next field, leaving the field blank. >> >> What do people think about making it a no-op when not on a table >> (letting it fall through to the global map), or putting it in a keymap >> text property on tables, or otherwise not hogging the binding? > > In my view, the first would be fine, and the second also unless someone > chimes in with a technical reason not to. For the last, perhaps `C-c > C-SPC' would be an okay replacement, though I'd assume that would break > some users' muscle memory in a surprising and unpleasant way. I'm not familiar with how this is all put together inside org mode. If it is possible to configure things so that it is only bound when inside a table and does not shadow other bindings for that sequence outside a table, I think that would be a positive change. However, I do also note that this is the type of change which tends to cause 'ripples' and may have unexpected impact in other areas, such as other packages, predefined or 'canned' emacs configurations etc. -- Tim Cross
Re: patch: ob-clojure improvements
OK. As the patch is over 6 months old, it would be good if the original
author can confirm it is still the latest version and if not, re-send
the most recent version.
Christopher Miles writes:
> <#secure method=pgpmime mode=sign>
>
> I checked this thread, seems the original first email of thread contains the
> patch. And it's not merged into Org git yet.
>
> Tim Cross writes:
>
> OK, will push it up the todo list. Where can I get the latest version of the
> patch or has it been added into the org git repo?
>
> Christopher Miles writes:
>
> <#!secure method=pgpmime mode=sign>
>
> Hi, Tim, popup this thread to request review.
>
> Tim Cross writes:
>
> I am also interested in ob-clojure and ob-clojurescript improvements.
> However, right now, I'm a tad busy and haven't had time to review what has
> been done. Hopefully, can make some time in the next month or so.
>
> Tim
>
> stardiviner writes:
>
> agzam.ibragi...@gmail.com writes:
>
> There seems to be a bit of lack of interest for these things. But I'm sure
> some people (myself included) would love to see these kinds of improvements.
>
> Yes, I rarely saw Clojurians in this mailing list.
>
> As I said before, I have never participated in contributing to Org source,
> some guidance would be appreciated.
>
> Org Mode has contribution guide here
> http://orgmode.org/worg/org-contribute.html#patches
>
> Should I keep building it and posting patches? Should I try to go
> incrementally, one small change at a time, or should I just get everything
> working first? If it turns out to be a bigger work, should I ask for
> permission to work in a branch and get access to pushing things to it? Maybe
> things just move slowly, because obviously you can't force maintainers to
> drop everything and concentrate effort to get your things in. Maybe I just
> have to be a little bit more patient?
>
> I think a complete work contains many patches should be better, Also write
> testing if necessary.
>
> I remember ob-clojure.el code are mostly reviewed by Bastien Guerry. I
> included him in Cc: in this email.
>
> On Sat, Jun 20, 2020 at 1:23 AM stardiviner wrote:
>
> Glad to see your patch, really useful in some cases. Thanks.
>
> Ag Ibragimov writes:
>
> Hi everyone, here's my attempt to add clojure CLI and babashka support for
> ob-clojure.el - Adds a header parameter to override org-babel-clojure-backend
> - Adds :args param (right now only used for clojure-cli)
>
> I have tested it with these minimal cases:
>
> #+beginsrc clojure :backend clj-cli :args "-Sdeps '{:deps {inflections
> {:mvn/version \"0.13.2\"}}}'" (use 'inflections.core) (plural "word") #+endsrc
>
> #+beginsrc clojure :backend babashka :results output (range 10) #+endsrc
>
> Please let me know what you think. Any advice is appreciated, since I have
> never contributed before. Thank you.
>
> – [ stardiviner ] I try to make every word tell the meaning that I want to
> express.
>
> Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix:
> stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
--
Tim Cross
Re: Free up C-c SPC/org-table-blank-field?
Eric Abrahamsen writes: > Hi all, > > The C-c SPC keybinding is pretty prime property (it's also, according to > Emacs conventions, meant to be reserved for the user, though I know > that's already out the window with Org), Based on my reading of (info "(elisp)Key Binding Conventions"), I think `C-c SPC` doesn't fall into the user's `C-c LETTER' territory but instead into the this group: Sequences consisting of ‘C-c’ followed by any other ASCII punctuation or symbol character are allocated for minor modes. Using them in a major mode is not absolutely prohibited, but if you do that, the major mode binding may be shadowed from time to time by minor modes. But, either way, I don't disagree with what you say next. > and it's currently bound to `org-table-blank-field', which is useless > unless you... happen to be in a table. I don't use tables often (or > blank fields when I do), which means this binding is effectively just > removed. > > What do people think about making it a no-op when not on a table > (letting it fall through to the global map), or putting it in a keymap > text property on tables, or otherwise not hogging the binding? In my view, the first would be fine, and the second also unless someone chimes in with a technical reason not to. For the last, perhaps `C-c C-SPC' would be an okay replacement, though I'd assume that would break some users' muscle memory in a surprising and unpleasant way.
Re: [PATCH] Remove Emacs 21 compat code for bookmark-after-jump-hook
Stefan Kangas writes: > The attached patch removes support for missing bookmark-after-jump-hook, > which was introduced in Emacs 22. This can be dropped unless there is a > need for this feature to support versions earlier than Emacs 22 > (released in June 2007). No, no need. The oldest supported version is Emacs 24.4 (though in my view we're due for bump). > Subject: [PATCH] Remove Emacs 21 compat code for bookmark-after-jump-hook > > * lisp/org-compat.el (bookmark-after-jump-hook): Remove Emacs 21 > compat code. Thanks. Pushed (2ed1c20ff).
[PATCH] Remove Emacs 21 compat code for bookmark-after-jump-hook
The attached patch removes support for missing bookmark-after-jump-hook, which was introduced in Emacs 22. This can be dropped unless there is a need for this feature to support versions earlier than Emacs 22 (released in June 2007). From 89947f5152afecb276010fa52fa025a2bb63b66f Mon Sep 17 00:00:00 2001 From: Stefan Kangas Date: Tue, 2 Feb 2021 16:35:48 +0100 Subject: [PATCH] Remove Emacs 21 compat code for bookmark-after-jump-hook * lisp/org-compat.el (bookmark-after-jump-hook): Remove Emacs 21 compat code. --- lisp/org-compat.el | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 88bf21b6a..8cbf33137 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -1104,14 +1104,7 @@ ELEMENT is the element at point." (org-show-context 'bookmark-jump))) ;; Make `bookmark-jump' shows the jump location if it was hidden. -(eval-after-load 'bookmark - '(if (boundp 'bookmark-after-jump-hook) - ;; We can use the hook - (add-hook 'bookmark-after-jump-hook 'org-bookmark-jump-unhide) - ;; Hook not available, use advice - (defadvice bookmark-jump (after org-make-visible activate) - "Make the position visible." - (org-bookmark-jump-unhide +(add-hook 'bookmark-after-jump-hook 'org-bookmark-jump-unhide) Calendar -- 2.29.2
Re: [PATCH] capture: Fix handling of time range for :time-prompt
Kyle Meyer writes: > Pushed (3e64d3475). Thank you! >> As far as I can tell, that is not fully possible today, even with this >> patch. The reason is that time *range* information entered at the prompt >> generated by :time-prompt gets thrown away. The reason for *that* is >> that org-read-date is called with t as its to-time argument (the second >> argument), so that the date is returned in Emacs' internal time >> representation, which doesn't represent ranges. > > Hmm. Is it really about the TO-TIME argument? If org-read-date is > called with TO-TIME as nil, doesn't it still throw away the end of the > range? > > (let ((org-time-was-given nil) > (org-end-time-was-given nil)) > (org-read-date nil nil nil "Date for tree entry:")) > ;; enter "3pm-4pm" => "2021-02-01 15:00" > > Or, actually, it stores the end in org-end-time-was-given, but it does > that regardless of the TO-TIME argument. Ah, that's interesting, thanks for pointing it out. I thought I had checked to see if org-end-time-was-given had a value after org-read-date gets called for a capture :time-prompt, but now I see that of course that wouldn't work without the surrounding let binding... OK, so with your patch, the way is clear to stick this value in org-capture-plist and make use of it when filling %T and friends in templates. I'll see if I can come up with a patch to do that, and report back. -- Best, Richard
Re: patch: ob-clojure improvements
OK, will push it up the todo list. Where can I get the latest version of
the patch or has it been added into the org git repo?
Christopher Miles writes:
> <#secure method=pgpmime mode=sign>
>
> Hi, Tim, popup this thread to request review.
>
> Tim Cross writes:
>
> I am also interested in ob-clojure and ob-clojurescript improvements.
> However, right now, I'm a tad busy and haven't had time to review what has
> been done. Hopefully, can make some time in the next month or so.
>
> Tim
>
> stardiviner writes:
>
> agzam.ibragi...@gmail.com writes:
>
> There seems to be a bit of lack of interest for these things. But I'm sure
> some people (myself included) would love to see these kinds of improvements.
>
> Yes, I rarely saw Clojurians in this mailing list.
>
> As I said before, I have never participated in contributing to Org source,
> some guidance would be appreciated.
>
> Org Mode has contribution guide here
> http://orgmode.org/worg/org-contribute.html#patches
>
> Should I keep building it and posting patches? Should I try to go
> incrementally, one small change at a time, or should I just get everything
> working first? If it turns out to be a bigger work, should I ask for
> permission to work in a branch and get access to pushing things to it? Maybe
> things just move slowly, because obviously you can't force maintainers to
> drop everything and concentrate effort to get your things in. Maybe I just
> have to be a little bit more patient?
>
> I think a complete work contains many patches should be better, Also write
> testing if necessary.
>
> I remember ob-clojure.el code are mostly reviewed by Bastien Guerry. I
> included him in Cc: in this email.
>
> On Sat, Jun 20, 2020 at 1:23 AM stardiviner wrote:
>
> Glad to see your patch, really useful in some cases. Thanks.
>
> Ag Ibragimov writes:
>
> Hi everyone, here's my attempt to add clojure CLI and babashka support
> for ob-clojure.el
> - Adds a header parameter to override org-babel-clojure-backend - Adds :args
> param (right now only used for clojure-cli)
>
> I have tested it with these minimal cases:
>
> #+beginsrc clojure :backend clj-cli :args "-Sdeps '{:deps {inflections
> {:mvn/version \"0.13.2\"}}}'"
> (use 'inflections.core) (plural "word") #+endsrc
>
> #+beginsrc clojure :backend babashka :results output (range 10) #+endsrc
>
> Please let me know what you think. Any advice is appreciated, since I
> have never contributed before. Thank you.
>
> – [ stardiviner ] I try to make every word tell the meaning that I want to
> express.
>
> Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix:
> stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
--
Tim Cross
Re: Google SoC organisation application
>>> Google's SoC organisation applications are currently open, and close on >>> <2020-02-20>. I know that Org participated once, in 2012. >>> >>> Would it be a good idea to submit an application to do so again? >>> With the rise in interest in computational notebooks, blogging tools, >>> and other features that Org possesses I'd imagine we have a decent shot. >>> >>> If so, we have just over two weeks to do so. >> >> Note that, as always, the GNU Project will be applying as a mentoring >> organization [1] [2]. > > That's nice, I don't see Org listed under > https://www.gnu.org/software/soc-projects/ideas-2020.html but good to > know (particularly for any SoC eligible people reading this ML) :) > > If nothing else, I think it could be worth applying separately for the > extra recognition, and perhaps Google might approve more applications > when Org and GNU are both listed? I don't really know how this works in > depth though. Applying separately is _always_ a good idea in GSOC. It basically means more odds to get more slots for projects.
Re: Get =#+RESULTS= without re-evaluating source code block?
John Kitchin writes: > I discovered that it matters a lot which block you cache. You have to > cache the long running block. I had put cache on the block with noweb > expansion, and then the long running block still runs every time. That > was a surprise to me, since nothing was changing in that block, so I > thought it would just use the cached result. > Just to elaborate a bit: Org mode checks whether to reevaluate a cached block by checksumming it and seeing if the sum is different from before. That's why you have to mark the actual block for caching, not its callers. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
[bug] erratic behavior of org refile
in recent maint [past few weeks perhaps?]. when i refile a task or goto a task using org-refile, sometimes refile is quite slow. then it sometimes sends me to an impossible location. by "impossible" i mean that either my refile targets variable is not respected or my refile verify function is not respected. for example, it can take me to "please" and it will take me to a doneified entry. does refile use a timer? the occasional slowness suggests it is filling a cache or something, but i have refile caching turned off. it seems to be erratic according to elapsed time or speed of typing or something. this is just a subjective impression. this is not a perfect bug report. i am using my own code, which has not changed. i use ido and ido-hacks, which also have not changed. my habits also have not changed. and i can't produce a repro for you at this time. so i just wnat to know if: 1] anybody experiences this recently 2] anybody can think of any change to refile code that could cause this 3] anybody can think of any reason why this might occur thank you. -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
batch archiving is too slow for my computer ... is it really intensive?
maint. i have an old computer, which usually has no problems if i am careful, except org is recently somewhat slower. with agenda batch archiving, however, even for just a few entries, the cpu overheats. the cpu never gets above 28% in a dual core in gkrellm, meaning that only 1/4 of total capacity in a dual core is used. i don't know why that makes it overheat. here is a profiler report for archiving 2 entries. then 2 entries again. is this kind of a normal profiler report? thanks. - command-execute 297,963,432 99% - call-interactively 297,963,432 99% - funcall-interactively 297,963,432 99% - org-agenda-bulk-action 273,550,028 91% - org-agenda-archive 272,853,572 91% - funcall-interactively 272,853,508 91% - org-agenda-archive-with 272,853,508 91% - org-archive-subtree 272,828,828 91% - org-show-all262,058,419 87% - org-cycle-hide-drawers 260,230,547 87% - # 260,226,323 87% - org-element-at-point 254,156,375 85% - org-element--parse-to 251,281,887 84% - org-element--current-element 247,748,793 83% - org-element-planning-parser13,355,147 4% - org-element-timestamp-parser 11,180,859 3% - org-parse-time-string 5,781,180 1% string-to-number 3,726 0% match-string-no-properties2,206,416 0% match-string 1,863 0% - org-at-heading-p 841,472 0% outline-on-heading-p 106,496 0% + org-element--list-struct 528,710 0% org-element-property-drawer-parser414,880 0% org-element--collect-affiliated-keywords 348,220 0% + org-element-drawer-parser 340,004 0% org-element-paragraph-parser 296,720 0% org-element-plain-list-parser 155,040 0% org-element-item-parser18,496 0% org-element-comment-parser 8,192 0% outline-previous-heading 106,574 0% + org-at-heading-p 1,374,384 0% + org-hide-drawer-toggle 5,006,924 1% + org-flag-region 1,827,872 0% + find-file-noselect9,965,693 3% + org-entry-put 233,830 0% + org-get-category118,306 0% + org-reveal 78,080 0% + org-update-statistics-cookies65,870 0% + org-get-outline-path 54,804 0% + org-entry-get50,410 0% + org-paste-subtree32,604 0% + org-cut-subtree 27,552 0% + org-archive--compute-location25,772 0% + org-copy-subtree 21,428 0% abbreviate-file-name 16,432 0% org-string-nw-p 12,524 0% do-after-load-evaluation 11,682 0% + jit-lock-after-change 8,696 0% + org-get-tags 5,408 0% org-up-heading-safe 4,096 0% + substitute-env-in-file-name 1,154 0% + find-buffer-visiting 1,048 0% + org-back-to-heading 1,024 0% + org-remove-subtree-entries-from-agenda 8,240 0% # 1,604 0% + org-unlogged-message693,000 0% + read-char-exclusive 1,456 0% + save-some-buffers 15,634,438 5% + ido-hacks-execute-extended-command 8,770,778 2% + tooltip-show-help-non-mode
Re: patch: ob-clojure improvements
<#secure method=pgpmime mode=sign>
I checked this thread, seems the original first email of thread contains the
patch. And it's not merged into Org git yet.
Tim Cross writes:
OK, will push it up the todo list. Where can I get the latest version of the
patch or has it been added into the org git repo?
Christopher Miles writes:
<#!secure method=pgpmime mode=sign>
Hi, Tim, popup this thread to request review.
Tim Cross writes:
I am also interested in ob-clojure and ob-clojurescript improvements. However,
right now, I'm a tad busy and haven't had time to review what has been done.
Hopefully, can make some time in the next month or so.
Tim
stardiviner writes:
agzam.ibragi...@gmail.com writes:
There seems to be a bit of lack of interest for these things. But I'm sure some
people (myself included) would love to see these kinds of improvements.
Yes, I rarely saw Clojurians in this mailing list.
As I said before, I have never participated in contributing to Org source, some
guidance would be appreciated.
Org Mode has contribution guide here
http://orgmode.org/worg/org-contribute.html#patches
Should I keep building it and posting patches? Should I try to go
incrementally, one small change at a time, or should I just get everything
working first? If it turns out to be a bigger work, should I ask for permission
to work in a branch and get access to pushing things to it? Maybe things just
move slowly, because obviously you can't force maintainers to drop everything
and concentrate effort to get your things in. Maybe I just have to be a little
bit more patient?
I think a complete work contains many patches should be better, Also write
testing if necessary.
I remember ob-clojure.el code are mostly reviewed by Bastien Guerry. I included
him in Cc: in this email.
On Sat, Jun 20, 2020 at 1:23 AM stardiviner wrote:
Glad to see your patch, really useful in some cases. Thanks.
Ag Ibragimov writes:
Hi everyone, here's my attempt to add clojure CLI and babashka support for
ob-clojure.el - Adds a header parameter to override org-babel-clojure-backend -
Adds :args param (right now only used for clojure-cli)
I have tested it with these minimal cases:
#+beginsrc clojure :backend clj-cli :args "-Sdeps '{:deps {inflections
{:mvn/version \"0.13.2\"}}}'" (use 'inflections.core) (plural "word") #+endsrc
#+beginsrc clojure :backend babashka :results output (range 10) #+endsrc
Please let me know what you think. Any advice is appreciated, since I have
never contributed before. Thank you.
– [ stardiviner ] I try to make every word tell the meaning that I want to
express.
Blog: https://stardiviner.github.io/ IRC(freenode): stardiviner, Matrix:
stardiviner GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
--
[ stardiviner ]
I try to make every word tell the meaning that I want to express.
Blog: https://stardiviner.github.io/
IRC(freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
