Re: Asynchronous org-agenda-redo

2019-12-12 Thread Adam Porter
Ihor Radchenko  writes:

>> Be sure to read the Emacs Lisp manual regarding threads.  They are
>> cooperative, so functions called as threads must yield back to the main
>> thread for Emacs to do anything else before the function returns.
>
> I tried to read the manual, but I clearly misunderstand something.
> The manual says:
>
>>   Currently, thread switching will occur upon explicit request via
>> ‘thread-yield’, when waiting for keyboard input... 
>
> So, except directly calling thread-yield, it should be possible to
> trigger switching the current thread when keyboard input is expected.
> I tried the following demo code:
>
> (defun test ()
>   (let ((a 0))
> (dotimes (_ 5)
>   (setq a (1+ a))
>   (sleep-for 2)
>   (message "%s" a
>
> (progn ;This should return to command loop quickly
>   (make-thread #'test)
>   (message "Executed...")); `eval-last-sexp' here
>
> I can move around the buffer while the progn is running.
> However, it is not the case with `org-agenda-redo' for a reason I do not
> fully understand.

Org Agenda code does not wait for keyboard input; it's busy building the
agenda.  This is the case with most code in Emacs: it's not written to
be asynchronous, and it doesn't return to the main thread until done.
So you can sprinkle yields here and there and maybe be able to move
point around while some code is running, but that will decrease
performance, as well as introducing another level of complexity and
another class of bugs (e.g. what if the user modifies a buffer while the
agenda code is scanning it?).

>> 1.  The process would have to load the same Org buffers, which takes
>> time, especially in large buffers.  Depending on configuration, it
>> can take some time, indeed.
>
>> 3.  Ensuring that configuration and state between the main Emacs process
>> and the separate, agenda-generating process is not necessarily
>> simple.  Consider as well that if a buffer had unsaved changes,
>> those would not be readable by the other process, which would lead
>> to invalid results.  One could force the buffers to be saved first,
>> but that may not always be desirable, as saving buffers can have
>> side effects.
>
> Why cannot org-buffer simply be copied into the subordinate process? If
> all be buffer-locals, text properties, and overlays are copied directly
> from the main emacs process, there may be no need to even initialise
> org-mode (the idea is to do something similar to clone-buffer).

AFAIK there exists no way to do such a thing.  Buffers are not designed
to be serialized/deserialized like that.  You could try writing some
Elisp code to do it, but the end result would probably be much slower
than existing agenda code, as well as more difficult to debug.

> The question though is whether buffer-locals + overlays + propertized
> .org files text + org-agenda-buffer copy can be sufficient to make the
> org-agenda-redo run properly. Are there any other buffers, variables,
> or other environment settings used by org-agenda-redo?

As you can see in org-agenda.el, it's complicated.  Remember that an
Emacs process is like a Lisp image, full of state.  The more symbols and
other structures you copy to the async Emacs process (by printing and
reading them as text, remember), the slower it's going to be--and it
will always be slower than not using async.

>> If your agenda buffers are taking too long to refresh, you might
>> consider org-ql's views/saved-searches as an alternative. ...
>
> I know org-ql and I am pretty sure that it will improve performance.
> Actually, if one can make built-in org-agenda asynchronous, org-ql can
> probably use similar approach and become even faster :)

Asynchronous code is not faster; it's generally slower because of
yielding and synchronization.

> I am trying on default org-agenda now mostly because my current config
> is heavily geared towards default agenda and I am not sure if
> refactoring everything to use org-ql will worth it at the end in terms
> of performance. I use too many slow custom skip-functions.

org-ql doesn't use skip functions, just queries.




Re: Bug: Orgguide missing in Org-9.3 package [9.3 (9.3-elpa @ /home/David/.emacs.d/elpa/org-9.3/)]

2019-12-12 Thread Kyle Meyer
Nicolas Goaziou  writes:

> David Masterson  writes:
>
>> Subject says it all -- I didn't have orgguide in the installation of the
>> org-9.3 package, so I pulled the latest git master and copied it from
>> there.  I guess the build process needs a fix.
>
> AFAICT, the build process properly generates the texinfo file for the
> Org guide. It may be an issue related to how Org was merged with Emacs.
>
> I'm Cc'ing Kyle, as I think he has write access to Emacs repository, and
> can fix it.

Sorry, I don't have write access.  But this issue seems to be about the
Org ELPA tarball, so I don't understand how it'd be related to the
recent Org sync with the Emacs repo.

Checking the tarball at  as
well as some recent ones at , I didn't spot
orgguide in any of them.  And when I run `make elpa' from the Org repo,
the tarball indeed seems to be missing the orgguide info file.  Assuming
there's not a good reason that orgguide is omitted, I think fixing this
is just a matter of adding orgguide to server.mk's ORGELPA variable.

-- >8 --
Subject: [PATCH] server.mk: Add orgguide to ELPA package

* mk/server.mk (ORGELPA): Include orgguide.

Reported-by: David Masterson 
---
 mk/server.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mk/server.mk b/mk/server.mk
index 94818bb84..2c5294507 100644
--- a/mk/server.mk
+++ b/mk/server.mk
@@ -38,7 +38,7 @@ ORGFULL   = README COPYING lisp/ \
etc/ contrib/ doc/ testing/
 ORGFULL  := $(ORGFULL:%/=%/*)
 ORGELPA   = README_ELPA COPYING etc/ORG-NEWS lisp/ \
-   doc/dir doc/org doc/orgcard.pdf \
+   doc/dir doc/org doc/orgguide doc/orgcard.pdf \
etc/styles/ org-pkg.el
 ORGELPA  := $(ORGELPA:%/=%/*)
 ORGELPAPLUS := $(ORGELPA:org-pkg%=org-plus-contrib-pkg%)
-- 
2.24.0




Re: Best way to template a big table

2019-12-12 Thread Leslie Watter
Hi all,

As I've understood you want to setup the structure of the table and have
some prompts to add rows to the table.

Using org-mode I have a capture skeleton here that uses

--- org capture template
#+begin_src elisp
;;
  ("Lu" "Fuel" table-line
 (file+olp "~/org/TODO.org" "Car" "Fuel Control")
 "|%<%Y-%m-%d> | %^{Price} | %^{ototanterior} | %^{ototatual} |  |
%^{liters} |  %^{RSxl} | %^{Average} | %^{GasType}|
")
#+end_src

And at TODO.org I have the following structure

#+begin_example
 * Car
** Fuel Control

|   Date |   Price | otot anterior | otot atual | partial | Liters |
 R$/l |Average | Fuel type  |
|+-+---++--++---+---+---|
(...)

#+end_example

I've just written the structure of the table and every time I have a new
entry I use capture to fill in the table. You'll get a prompt with the name
of the strings asked.

Hope it helps.

Cheers,

LEslie


On Thu, Dec 12, 2019 at 3:33 PM Berry, Charles 
wrote:

>
>
> > On Dec 12, 2019, at 8:03 AM, Lawrence Bottorff 
> wrote:
> >
> > I just figured out that this
> >
> > #+BEGIN_SRC emacs-lisp :results table
> > '((H1 H2 H3) (text11 text12 text13) (text21 text22 text23) (... ... ...)
> (textN1 textN2 textN3))
> > #+END_SRC
> >
> > #+RESULTS:
> > | H1 | H2 | H3 |
> > | text11 | text12 | text13 |
> > | text21 | text22 | text23 |
> > | ...| ...| ...|
> > | textN1 | textN2 | textN3 |
> >
> > is probably a better way all around, i.e., "best practice." If any one
> knows how to get the horizontal lines added in. . . .
>
>
> Add an `hline' in the right place. Like this:
>
> #+BEGIN_SRC emacs-lisp :results table
> '((H1 H2 H3) hline (text11 text12 text13) (text21 text22 text23) (... ...
> ...) (textN1 textN2 textN3))
> #+END_SRC
>
> HTH,
>
> Chuck
>
>

-- 
Leslie H. Watter


Re: Bug: org-capture-get-template can't use a lambda for template function. [9.2.6 (9.2.6-7-g634880-elpaplus @ /home/n/.emacs.d/elpa/org-plus-contrib-20191118/)]

2019-12-12 Thread Nicolas Goaziou
Hello,

No Wayman  writes:

> Noticed that one cannot use a lambda function as a template generating
> function.
> Doing so results in the error:
>
> Wrong type argument: symbolp, (lambda...)
>
> The cause is the fboundp check in org-capture-get-template.
> Changing this to functionp allows a lambda to be specified and is
> consistent with what org-capture-set-target-location allows.

Fixed. Thank you for the report and the analysis.

Regards,

-- 
Nicolas Goaziou



RE: [O] FW: [RFC] Link-type for attachments, more attach options

2019-12-12 Thread Gustav Wikström
Hi,

> -Original Message-
> From: stardiviner 
> Sent: den 12 december 2019 10:53
> To: Gustav Wikström 
> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org
> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options
> 
> ...
> 
> For example, I press =[Ctrl-c Ctrl-a]= to attach a file. Then I press =[Ctrl-c
> Ctrl-l]= (~org-insert-link~) to insert link which will show a list of
> completions
> which are all link types prefix like ~attachment:~, and
> =file:data/a2//attachFile.png=. I mean the second link. it is already in
> completion list, but ~attchment:~ does not have this support.

Hmm, I'm not sure I follow. Is it in the same suggestion list for link type 
prefixes 
that you also get the file-link to the newly attached file? I tried to 
reproduce that 
using emacs -q just now but couldn't... Is there a customization that you've 
enabled?

Regards
Gustav 


Re:

2019-12-12 Thread Marco Wahl
Tim Visher  writes:

> On Thu, Dec 12, 2019 at 4:14 AM Marco Wahl  wrote:
>
>> Justin Vallon  writes:
>>
>> > When I use "emacs --no-init-file", I get the default distribution org
>> > packages, and "> > in my downloaded-melpa-install of org, it does not work.
>> >
>> > Distro org-version is 9.1.9, melpa is 9.3.  describe-key TAB shows
>> > org-cycle, which is a kitchen-sink function.  The docs of the function
>> > has not changed between the versions.
>> >
>> > I believe "> > but I don't have any version besides 9.3 in ~/.emacs.d/elpa.
>>
>> Possibly you want to switch to the new feature (accessible C-c C-,)
>> which BTW allows to wrap regions.
>>
>> The "> See the documentation in section Structure Templates.
>>
>
> What feature are you referring to, Marco? My `C-c C-,` sets the heading
> priority.

This is a reference to the feature announced in ORG-NEWS
e.g. https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS.

Org 9.2 comes with a new template expansion mechanism, combining
~org-insert-structure-template~ bound to ~C-c C-,~.

And also the feature is described in the info documentation in section
"Structure Templates".

Possibly you have defined your personal "C-c C-," Tim?


HTH



Re: Best way to template a big table

2019-12-12 Thread Berry, Charles



> On Dec 12, 2019, at 8:03 AM, Lawrence Bottorff  wrote:
> 
> I just figured out that this 
> 
> #+BEGIN_SRC emacs-lisp :results table
> '((H1 H2 H3) (text11 text12 text13) (text21 text22 text23) (... ... ...) 
> (textN1 textN2 textN3))
> #+END_SRC
> 
> #+RESULTS:
> | H1 | H2 | H3 |
> | text11 | text12 | text13 |
> | text21 | text22 | text23 |
> | ...| ...| ...|
> | textN1 | textN2 | textN3 |
> 
> is probably a better way all around, i.e., "best practice." If any one knows 
> how to get the horizontal lines added in. . . .


Add an `hline' in the right place. Like this:

#+BEGIN_SRC emacs-lisp :results table
'((H1 H2 H3) hline (text11 text12 text13) (text21 text22 text23) (... ... ...) 
(textN1 textN2 textN3))
#+END_SRC

HTH,

Chuck



Re:

2019-12-12 Thread Tim Visher
On Thu, Dec 12, 2019 at 1:15 PM Marco Wahl  wrote:

> Tim Visher  writes:
>
> > On Thu, Dec 12, 2019 at 4:14 AM Marco Wahl 
> wrote:
> >
> >> Justin Vallon  writes:
> >>
> >> > When I use "emacs --no-init-file", I get the default distribution org
> >> > packages, and " However,
> >> > in my downloaded-melpa-install of org, it does not work.
> >> >
> >> > Distro org-version is 9.1.9, melpa is 9.3.  describe-key TAB shows
> >> > org-cycle, which is a kitchen-sink function.  The docs of the function
> >> > has not changed between the versions.
> >> >
> >> > I believe " >> > but I don't have any version besides 9.3 in ~/.emacs.d/elpa.
> >>
> >> Possibly you want to switch to the new feature (accessible C-c C-,)
> >> which BTW allows to wrap regions.
> >>
> >> The " >> See the documentation in section Structure Templates.
> >>
> >
> > What feature are you referring to, Marco? My `C-c C-,` sets the heading
> > priority.
>
> This is a reference to the feature announced in ORG-NEWS
> e.g. https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS.
>
> Org 9.2 comes with a new template expansion mechanism, combining
> ~org-insert-structure-template~ bound to ~C-c C-,~.
>
> And also the feature is described in the info documentation in section
> "Structure Templates".
>
> Possibly you have defined your personal "C-c C-," Tim?
>

Ah. Apparently I can't press `C-,` in the terminal. So emacs was receiving
`C-c ,`. That makes sense.


Bug: org-capture-get-template can't use a lambda for template function. [9.2.6 (9.2.6-7-g634880-elpaplus @ /home/n/.emacs.d/elpa/org-plus-contrib-20191118/)]

2019-12-12 Thread No Wayman



Remember to cover the basics, that is, what you expected to happen 
and
what in fact did happen.  You don't know how to make a good 
report?  See


https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Noticed that one cannot use a lambda function as a template 
generating function.

Doing so results in the error:

Wrong type argument: symbolp, (lambda...)

The cause is the fboundp check in org-capture-get-template.
Changing this to functionp allows a lambda to be specified and is 
consistent with what org-capture-set-target-location allows.


I'm not sure if there are any corner cases I'm unaware of, but it 
seems like a simple patch:


diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index ef3561563..a8a4e1e89 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -706,7 +706,7 @@ of the day at point (if any) or the current 
HH:MM time."

  (setq txt (org-file-contents file))
(setq txt (format "* Template file %s not found" (nth 1 txt)
 ((and (listp txt) (eq (car txt) 'function))
-  (if (fboundp (nth 1 txt))
+  (if (functionp (nth 1 txt))
  (setq txt (funcall (nth 1 txt)))
	(setq txt (format "* Template function %s not found" (nth 1 
txt)

 ((not txt) (setq txt ""))

Thanks,
nv

Emacs  : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X 
toolkit, cairo version 1.17.3, Xaw3d scroll bars)

of 2019-12-10
Package: Org mode version 9.2.6 (9.2.6-7-g634880-elpaplus @ 
/home/n/.emacs.d/elpa/org-plus-contrib-20191118/)




Re: Best way to template a big table

2019-12-12 Thread Lawrence Bottorff
I just figured out that this

#+BEGIN_SRC emacs-lisp :results table
'((H1 H2 H3) (text11 text12 text13) (text21 text22 text23) (... ... ...)
(textN1 textN2 textN3))
#+END_SRC

#+RESULTS:
| H1 | H2 | H3 |
| text11 | text12 | text13 |
| text21 | text22 | text23 |
| ...| ...| ...|
| textN1 | textN2 | textN3 |

is probably a better way all around, i.e., "best practice." If any one
knows how to get the horizontal lines added in. . . .

On Thu, Dec 12, 2019 at 5:29 AM Simon Butler  wrote:

> Hi
>
> On 2019-12-12 07:05, Lawrence Bottorff wrote:
> > I've got a big table that I would like to create a template for, i.e.,
> > the rows and columns and the myriad | and -. Then a key chord would
> > produce it in an org file ready for values to be entered. I've seen
> > the post-9.2 tempo-define-template, but that looks more suited to
> > smaller things. There is Emacs Skeleton, but I'd like to ask people
> > who perhaps have faced this issue before for a "best practice" answer.
> >
> > LB
>
> Not sure about 'best practice', but yasnippet works well.
>
> Simon
>
>
>


Re: Asynchronous org-agenda-redo

2019-12-12 Thread Ihor Radchenko
> Be sure to read the Emacs Lisp manual regarding threads.  They are
> cooperative, so functions called as threads must yield back to the main
> thread for Emacs to do anything else before the function returns.

I tried to read the manual, but I clearly misunderstand something.
The manual says:

>   Currently, thread switching will occur upon explicit request via
> ‘thread-yield’, when waiting for keyboard input... 

So, except directly calling thread-yield, it should be possible to
trigger switching the current thread when keyboard input is expected.
I tried the following demo code:

(defun test ()
  (let ((a 0))
(dotimes (_ 5)
  (setq a (1+ a))
  (sleep-for 2)
  (message "%s" a

(progn ;This should return to command loop quickly
  (make-thread #'test)
  (message "Executed...")); `eval-last-sexp' here

I can move around the buffer while the progn is running.
However, it is not the case with `org-agenda-redo' for a reason I do not
fully understand. 

For the async.el, I agree that loading packages may take time, but I
believe that the configuration might be transferred more easily (though
it may depend on the org-agenda and user-defined
org-agenda-skip-functions implementation).

> 1.  The process would have to load the same Org buffers, which takes
> time, especially in large buffers.  Depending on configuration, it
> can take some time, indeed.

> 3.  Ensuring that configuration and state between the main Emacs process
> and the separate, agenda-generating process is not necessarily
> simple.  Consider as well that if a buffer had unsaved changes,
> those would not be readable by the other process, which would lead
> to invalid results.  One could force the buffers to be saved first,
> but that may not always be desirable, as saving buffers can have
> side effects.

Why cannot org-buffer simply be copied into the subordinate process? If
all be buffer-locals, text properties, and overlays are copied directly
from the main emacs process, there may be no need to even initialise
org-mode (the idea is to do something similar to clone-buffer). The
question though is whether buffer-locals + overlays + propertized .org
files text + org-agenda-buffer copy can be sufficient to make the
org-agenda-redo run properly. Are there any other buffers, variables, or
other environment settings used by org-agenda-redo?

> If your agenda buffers are taking too long to refresh, you might
> consider org-ql's views/saved-searches as an alternative. ...

I know org-ql and I am pretty sure that it will improve performance.
Actually, if one can make built-in org-agenda asynchronous, org-ql can
probably use similar approach and become even faster :)
I am trying on default org-agenda now mostly because my current config
is heavily geared towards default agenda and I am not sure if
refactoring everything to use org-ql will worth it at the end in terms
of performance. I use too many slow custom skip-functions.

> ... The built-in
> caching in org-ql significantly improves performance, especially when
> refreshing views.

Yeah. I wish org-entry-get and other org-get* functions support caching
as well... Or, at least, org-agenda functions might also support simple
caching based on file modifications.

Best,
Ihor

Adam Porter  writes:

> Be sure to read the Emacs Lisp manual regarding threads.  They are
> cooperative, so functions called as threads must yield back to the main
> thread for Emacs to do anything else before the function returns.
>
> If you're feeling adventurous, you could experiment with adding yields
> in relevant agenda functions.  But that wouldn't be suitable for merging
> into Org, because that yielding also decreases performance generally.
>
> As long as Elisp threads are cooperative, they are of very limited use.
>
> Generating agendas with async.el in a separate Emacs process is an
> interesting idea, but probably generally impractical for a few reasons:
>
> 1.  The process would have to load the same Org buffers, which takes
> time, especially in large buffers.  Depending on configuration, it
> can take some time, indeed.
> 2.  The process would also have to load the same packages (or, at least,
> all the necessary ones, which depends on configuration), which takes
> time.
> 3.  Ensuring that configuration and state between the main Emacs process
> and the separate, agenda-generating process is not necessarily
> simple.  Consider as well that if a buffer had unsaved changes,
> those would not be readable by the other process, which would lead
> to invalid results.  One could force the buffers to be saved first,
> but that may not always be desirable, as saving buffers can have
> side effects.
>
> If your agenda buffers are taking too long to refresh, you might
> consider org-ql's views/saved-searches as an alternative.  The built-in
> caching in org-ql significantly improves performance, especially when
> refreshing views.

Re:

2019-12-12 Thread Tim Visher
On Thu, Dec 12, 2019 at 4:14 AM Marco Wahl  wrote:

> Justin Vallon  writes:
>
> > When I use "emacs --no-init-file", I get the default distribution org
> > packages, and " > in my downloaded-melpa-install of org, it does not work.
> >
> > Distro org-version is 9.1.9, melpa is 9.3.  describe-key TAB shows
> > org-cycle, which is a kitchen-sink function.  The docs of the function
> > has not changed between the versions.
> >
> > I believe " > but I don't have any version besides 9.3 in ~/.emacs.d/elpa.
>
> Possibly you want to switch to the new feature (accessible C-c C-,)
> which BTW allows to wrap regions.
>
> The " See the documentation in section Structure Templates.
>

What feature are you referring to, Marco? My `C-c C-,` sets the heading
priority.


org/matlab the python kernel and a problem (python 2 vs 3)

2019-12-12 Thread Uwe Brauer



Hi

I am on Ubuntu 16.05 running either python 2.7 or 3.5.
I had matlab 2018b installed, and used the python engine to run matlab
commands from org file in a fast way.


I did, after installing the corresponding python3 modules, in the matlab
installation directory 

sudo -H python3 setup.py install 

I started the engine via 
/usr/bin/python3
in the python prompt:

import matlab.engine
eng = matlab.engine.start_matlab()

And for org I used 


  (add-to-list 'org-src-lang-modes '("matlab" . matlab))
  (setq python-shell-interpreter "python3")
  ;; set default headers for convenience
  (setq org-babel-default-header-args:matlab
'((:results . "output replace")
  (:session . "matlab")
  (:kernel . "matlab")
  (:exports . "code")
  (:cache .   "no")
  (:noweb . "no")
  (:hlines . "no")
  (:tangle . "no")))
  (defalias 'org-babel-execute:matlab 'org-babel-execute:ipython)
  (defalias 'org-babel-prep-session:matlab 'org-babel-prep-session:ipython)
  (defalias 'org-babel-matlab-initiate-session 
'org-babel-ipython-initiate-session)

Worked like charm

However I had to upgrade to 2019b
then the installation via python 3.5 failed


OSError: MATLAB Engine for Python supports Python version 2.7, 3.6, and 3.7, 
but your version of Python is 3.5

So I used 2.7 and changed the org setting accordingly.

However when I tried to execute matlab code, emacs run forever and
nothing happened.

Did anybody got this to work with python2.7?

Thanks

Uwe Brauer  




Re: Asynchronous org-agenda-redo

2019-12-12 Thread Ihor Radchenko
Hi Diego,
> I cannot answer your question, but I am curious about using async together
> with tangling, since for some of my buffers, tangling takes some time and
> freezes Emacs in the process. Do you have some examples of this that you
> could share?

See the relevant code from my config below. Let me know if you have any
questions or suggestions.

Also, my config is written in the way that everything related to user
interaction can be disabled if I load emacs for tangling
(with org-tangle-flag). This is to speed up the async process.  

#+begin_src emacs-lisp
(defvar yant/org-babel-tangle-async-process-list nil
  "Plist of (file . process) for all the currently running async tangle 
processes.")


(defun yant/org-babel-tangle-async (file  target-file lang)
  "Invoke `org-babel-tangle-file' asynchronously."
  (require 'async)
  (let ((oldproc (plist-get yant/org-babel-tangle-async-process-list file)))
(when (or (not oldproc)
  (async-wait oldproc))
  (message "Tangling %s..." (buffer-file-name))
  (plist-put yant/org-babel-tangle-async-process-list
 file
 (async-start
  (let ((args (list file target-file lang)))
`(lambda ()
   (require 'org)
   (setq org-tangle-flag t)
   (load "~/.emacs.d/config.el")
   (apply #'org-babel-tangle-file ',args)))
  (let ((message-string (format "Tangling (%S %S %S) 
completed." file target-file lang)))
`(lambda (result) (message ,message-string

(defvar yant/auto-tangle-list nil
  "List of files, which can be safely tangled on save.
The list is saved between Emacs sessions.")

(when init-flag
  (use-package savehist
:config
(add-to-list 'savehist-additional-variables 'yant/auto-tangle-list))
  (savehist-mode +1)
  (defun yant/toggle-buffer-auto-tangle (arg)
"Toggle auto tangling of a buffer."
(interactive "P")
(if (not (eq major-mode 'org-mode))
(message "Org-mode is not active in buffer \"%s\"" (buffer-name))
  (cond ((not arg)
 (if (member (buffer-file-name) yant/auto-tangle-list)
 (progn (setq yant/auto-tangle-list (delete (buffer-file-name) 
yant/auto-tangle-list))
(message "Auto tangling disabled for %s" 
(buffer-file-name)))
   (add-to-list 'yant/auto-tangle-list (buffer-file-name))
   (message "Auto tangling enabled for %s" (buffer-file-name
((or (and (not (listp arg)) (> arg 0))
 (equal arg '(4)))
 (add-to-list 'yant/auto-tangle-list (buffer-file-name))
 (message "Auto tangling enabled for %s" (buffer-file-name)))
(t
 (setq yant/auto-tangle-list (delete (buffer-file-name) 
yant/auto-tangle-list))
 (message "Auto tangling disabled for %s" (buffer-file-name))

  (bind-key "C-c C-*" #'yant/toggle-buffer-auto-tangle org-mode-map))

(defun yant/org-babel-tangle-current-buffer-async ()
  "Tangle current buffer asynchronously."
  (when (and (eq major-mode 'org-mode)
 (member (buffer-file-name) yant/auto-tangle-list))
(yant/org-babel-tangle-async (buffer-file-name

(add-hook 'after-save-hook #'yant/org-babel-tangle-current-buffer-async)
#+end_src


Diego Zamboni  writes:

> Hi Ihor,
>
> I cannot answer your question, but I am curious about using async together
> with tangling, since for some of my buffers, tangling takes some time and
> freezes Emacs in the process. Do you have some examples of this that you
> could share?
>
> Thanks,
> --Diego
>
>
> On Thu, Dec 12, 2019 at 9:21 AM Ihor Radchenko  wrote:
>
>> I am thinking if it is possible to implement org-agenda-redo
>> asynchronously.
>>
>> Rebuilding agenda should normally not affect any buffer except agenda
>> buffer. So, it should be sufficient to block any agenda modifying
>> commands in the agenda buffer, redo the agenda buffer in separate
>> thread, and replace the old agenda with the calculated one.
>> Then, emacs should remain responsive while updating agenda (except for
>> modifying the agenda buffer).
>>
>> For example, this naive code kind of works (forgetting that buffer-local
>> variables will not be passed to the thread):
>>
>> (define-advice org-agenda-redo (:around (oldfun  all) make-async)
>>   (make-thread oldfun "org-agenda-redo"))
>>
>> The problem is that emacs does not become responsive...
>>
>> Another approach would be using async.el package, which allows calling
>> arbitrary function in subordinate emacs process. Then, the main emacs
>> instance should not be "frozen" (I use same approach for tangling and it
>> works fine).
>>
>> However, the question is how to pass the .org and agenda buffers to this
>> subordinate process. Opening the .org files there is not a good option
>> since it would give too much overhead to this asynchronous agenda.
>>
>> Any 

Re: Bug: org-use-fast-todo-selection prefix option removed [9.3 (9.3-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20191203/)]

2019-12-12 Thread Allen Li
On Thu, Dec 12, 2019 at 10:48 AM Kyle Meyer  wrote:
>
> Allen Li  writes:
>
> > The option to set org-use-fast-todo-selection to 'prefix was removed
> > without my noticing.  This breaks my workflow since I like the default
> > cycling behavior and only occasionally use fast todo selection to
> > switch between todo state sets.
> >
> > It was removed in commit f1c030bed54737319aeb1d592e3340d6a48cea3a
>
> Carsten proposed that change here:
>
>   https://lists.gnu.org/archive/html/emacs-orgmode/2019-08/msg00138.html
>
> A couple of people chimed in to say they were in favor and nobody raised
> an objection.  I personally prefer the new behavior as well.
>
> While I think we should reassess that change if it turns out that it
> breaks many people's workflow, for now I'd recommend that you advise
> org-todo.

My problem with this is that there is a hard feature regression
here in that the ONLY way to jump to a particular TODO state is
by enabling fast todo selection, which requires one to ALWAYS use
fast todo selection.  There is no way to both not use fast todo
selection and also jump to a particular TODO state.

For example, the old behavior allowed one to use completion to
select a TODO state to jump to with C-u C-c C-t, which does not
require enabling fast todo selection.

This makes using ! or @ with TODO keywords basically unusable
without fast todo selection.



Re: Asynchronous org-agenda-redo

2019-12-12 Thread Diego Zamboni
Hi Ihor,

I cannot answer your question, but I am curious about using async together
with tangling, since for some of my buffers, tangling takes some time and
freezes Emacs in the process. Do you have some examples of this that you
could share?

Thanks,
--Diego


On Thu, Dec 12, 2019 at 9:21 AM Ihor Radchenko  wrote:

> I am thinking if it is possible to implement org-agenda-redo
> asynchronously.
>
> Rebuilding agenda should normally not affect any buffer except agenda
> buffer. So, it should be sufficient to block any agenda modifying
> commands in the agenda buffer, redo the agenda buffer in separate
> thread, and replace the old agenda with the calculated one.
> Then, emacs should remain responsive while updating agenda (except for
> modifying the agenda buffer).
>
> For example, this naive code kind of works (forgetting that buffer-local
> variables will not be passed to the thread):
>
> (define-advice org-agenda-redo (:around (oldfun  all) make-async)
>   (make-thread oldfun "org-agenda-redo"))
>
> The problem is that emacs does not become responsive...
>
> Another approach would be using async.el package, which allows calling
> arbitrary function in subordinate emacs process. Then, the main emacs
> instance should not be "frozen" (I use same approach for tangling and it
> works fine).
>
> However, the question is how to pass the .org and agenda buffers to this
> subordinate process. Opening the .org files there is not a good option
> since it would give too much overhead to this asynchronous agenda.
>
> Any suggestions? Alternative ideas?
>
> Best,
> Ihor
>
>
>


Re: [PATCH] Fix verbatim block fontification to end blocks on headlines

2019-12-12 Thread Adam Porter
May I recommend using the rx macro for regexps?  They are much easier
for humans to parse, which helps reduce errors like the ones mentioned
here.  And they are about to gain some very useful new features
in Emacs 27.




Re: Asynchronous org-agenda-redo

2019-12-12 Thread Adam Porter
Be sure to read the Emacs Lisp manual regarding threads.  They are
cooperative, so functions called as threads must yield back to the main
thread for Emacs to do anything else before the function returns.

If you're feeling adventurous, you could experiment with adding yields
in relevant agenda functions.  But that wouldn't be suitable for merging
into Org, because that yielding also decreases performance generally.

As long as Elisp threads are cooperative, they are of very limited use.

Generating agendas with async.el in a separate Emacs process is an
interesting idea, but probably generally impractical for a few reasons:

1.  The process would have to load the same Org buffers, which takes
time, especially in large buffers.  Depending on configuration, it
can take some time, indeed.
2.  The process would also have to load the same packages (or, at least,
all the necessary ones, which depends on configuration), which takes
time.
3.  Ensuring that configuration and state between the main Emacs process
and the separate, agenda-generating process is not necessarily
simple.  Consider as well that if a buffer had unsaved changes,
those would not be readable by the other process, which would lead
to invalid results.  One could force the buffers to be saved first,
but that may not always be desirable, as saving buffers can have
side effects.

If your agenda buffers are taking too long to refresh, you might
consider org-ql's views/saved-searches as an alternative.  The built-in
caching in org-ql significantly improves performance, especially when
refreshing views.




Re: Best way to template a big table

2019-12-12 Thread Simon Butler
Hi

On 2019-12-12 07:05, Lawrence Bottorff wrote:
> I've got a big table that I would like to create a template for, i.e.,
> the rows and columns and the myriad | and -. Then a key chord would
> produce it in an org file ready for values to be entered. I've seen
> the post-9.2 tempo-define-template, but that looks more suited to
> smaller things. There is Emacs Skeleton, but I'd like to ask people
> who perhaps have faced this issue before for a "best practice" answer.
>
> LB

Not sure about 'best practice', but yasnippet works well.

Simon




Re: PATCH: Re: Recurring TODO with hours not scheduled correctly

2019-12-12 Thread Nicolas Goaziou
Hello,

Justin Vallon  writes:

> Following up with a patch to make .+1h work "like" .+1d:
>
> - When computing the new scheduled date, the repeater-type "." would
> shift the scheduled date to today, then adjust by the interval.
> Shifting the date would leave the time unchanged
> - When shifting by hours, the old time would remain, and then be shifted
> by the interval
> - With the patch, ".+1h" will shift schedule-date to now (vs today),
> then add "1h" as before.  ".+1d" will have the old behavior (shift date,
> but leave time alone).
> - That is:
>   - ".+1d" is tomorrow at same scheduled time
>   - ".+1h" is in one hour
>   - ".+24h" is 24h from now.

That seems reasonable.

Would you mind providing an entry in ORG-NEWS, possibly some pointers in
the manual, if appropriate, and add a few tests in
`test-org/auto-repeat-maybe' located in test-org.el file?

Thank you!

Regards,

-- 
Nicolas Goaziou



Re: [PATCH] Fix verbatim block fontification to end blocks on headlines

2019-12-12 Thread Tom Gillespie
Thank you very much for the feedback. I will make the additional fixes
against maint along with the changes for clarity and send them along
tomorrow. Additional replies in line. Best,
Tom

On Thu, Dec 12, 2019 at 12:40 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> Tom Gillespie  writes:
>
> > This patch is a change to how org fontifies verbatim source blocks re: [1].
> > Hopefully it answers Nicolas's question from that thread. Best!
>
> OK. Now I see what you meant. Thank you.
>
> > (when (re-search-forward
> > -  (concat "^[ \t]*#\\+end" (match-string 4) "\\>.*")
> > +  (concat "\\(^\\*\\|^[ \t]*#\\+end" (match-string 4) 
> > "\\>.*\\)")
>
> I haven't tested it, but I think this will not produce the expected
> result:
>
>   #+begin_example
>   *bold*
>   #+end_example
>
> I.e., headlines are asterisks at column 0 /followed by a space/.

Yep, you are exactly right.

>
> >nil t)  ;; on purpose, we look further than LIMIT
> >   ;; We do have a matching #+end line
> >   (setq beg-of-endline (match-beginning 0)
> > @@ -5326,10 +5326,11 @@ by a #."
> >   (add-text-properties
> >beg (if whole-blockline bol-after-beginline end-of-beginline)
> >'(face org-block-begin-line))
> > - (add-text-properties
> > -  beg-of-endline
> > -  (min (point-max) (if whole-blockline (min (point-max) (1+ 
> > end-of-endline)) end-of-endline))
> > -  '(face org-block-end-line))
> > + (when (not (string= (match-string 1) "*"))
>
> `when' + `not' -> `unless'
>
> > +   (add-text-properties
> > +beg-of-endline
> > +(min (point-max) (if whole-blockline (min (point-max) (1+ 
> > end-of-endline)) end-of-endline))
> > +'(face org-block-end-line)))
>
> Arguably, I think
>
>   (min (point-max) (1+ end-of-endline))
>
> could be replaced, for clarity, by
>
>   (let (... (beg-of-next-line (line-beginning-position 2)) ...)
>...
>(add-text-properties
> beg-of-endline
> (min (point-max) (if whole-blockline beg-of-next-line end-of-endline

Probably right. I will review since I didn't look carefully at that
code, but it is a good opportunity to make some improvements while we
are looking at it.

>
> I'm also not convinced that the (min (point-max) ...) left is necessary.
>
> Could you send an updated patch (on top of maint)?
>
> Regards,
>
> --
> Nicolas Goaziou



Re: [O] FW: [RFC] Link-type for attachments, more attach options

2019-12-12 Thread stardiviner


Gustav Wikström  writes:

> Hi stardiviner,
>
> It is my belief that =[Ctrl-C Ctrl-l]= already is supported. You will only 
> get suggestions for attachments if there are any attachments on the outline 
> node you're in. Or in any of its parents if inheritance is configured.
>

For example, I press =[Ctrl-c Ctrl-a]= to attach a file. Then I press =[Ctrl-c
Ctrl-l]= (~org-insert-link~) to insert link which will show a list of 
completions
which are all link types prefix like ~attachment:~, and
=file:data/a2//attachFile.png=. I mean the second link. it is already in
completion list, but ~attchment:~ does not have this support.

> Regards Gustav
> -
> From: Emacs-orgmode  on behalf 
> of stardiviner 
> Sent: Thursday, December 12, 2019 6:21:30 AM
> To: emacs-orgmode@gnu.org 
> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options 
>  
>
> Hi Gustav,
>
> I suggest to add support for =[Ctrl-C Ctrl-l]= like ~file:~ link type. which 
> will
> auto in completion list. It will be convenient for user.


-- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  



Re:

2019-12-12 Thread Marco Wahl
Justin Vallon  writes:

> When I use "emacs --no-init-file", I get the default distribution org
> packages, and " in my downloaded-melpa-install of org, it does not work.
>
> Distro org-version is 9.1.9, melpa is 9.3.  describe-key TAB shows
> org-cycle, which is a kitchen-sink function.  The docs of the function
> has not changed between the versions.
>
> I believe " but I don't have any version besides 9.3 in ~/.emacs.d/elpa.

Possibly you want to switch to the new feature (accessible C-c C-,)
which BTW allows to wrap regions.

The "

Re: Bug: Orgguide missing in Org-9.3 package [9.3 (9.3-elpa @ /home/David/.emacs.d/elpa/org-9.3/)]

2019-12-12 Thread Nicolas Goaziou
Hello,

David Masterson  writes:

> Subject says it all -- I didn't have orgguide in the installation of the
> org-9.3 package, so I pulled the latest git master and copied it from
> there.  I guess the build process needs a fix.

AFAICT, the build process properly generates the texinfo file for the
Org guide. It may be an issue related to how Org was merged with Emacs.

I'm Cc'ing Kyle, as I think he has write access to Emacs repository, and
can fix it.

Thank you.

Regards,

-- 
Nicolas Goaziou



Re: [PATCH] Fix verbatim block fontification to end blocks on headlines

2019-12-12 Thread Nicolas Goaziou
Hello,

Tom Gillespie  writes:

> This patch is a change to how org fontifies verbatim source blocks re: [1].
> Hopefully it answers Nicolas's question from that thread. Best!

OK. Now I see what you meant. Thank you.

> (when (re-search-forward
> -  (concat "^[ \t]*#\\+end" (match-string 4) "\\>.*")
> +  (concat "\\(^\\*\\|^[ \t]*#\\+end" (match-string 4) "\\>.*\\)")

I haven't tested it, but I think this will not produce the expected
result:

  #+begin_example
  *bold*
  #+end_example

I.e., headlines are asterisks at column 0 /followed by a space/.
  
>nil t)  ;; on purpose, we look further than LIMIT
>   ;; We do have a matching #+end line
>   (setq beg-of-endline (match-beginning 0)
> @@ -5326,10 +5326,11 @@ by a #."
>   (add-text-properties
>beg (if whole-blockline bol-after-beginline end-of-beginline)
>'(face org-block-begin-line))
> - (add-text-properties
> -  beg-of-endline
> -  (min (point-max) (if whole-blockline (min (point-max) (1+ 
> end-of-endline)) end-of-endline))
> -  '(face org-block-end-line))
> + (when (not (string= (match-string 1) "*"))

`when' + `not' -> `unless'

> +   (add-text-properties
> +beg-of-endline
> +(min (point-max) (if whole-blockline (min (point-max) (1+ 
> end-of-endline)) end-of-endline))
> +'(face org-block-end-line)))

Arguably, I think 

  (min (point-max) (1+ end-of-endline))

could be replaced, for clarity, by

  (let (... (beg-of-next-line (line-beginning-position 2)) ...)
   ...
   (add-text-properties
beg-of-endline 
(min (point-max) (if whole-blockline beg-of-next-line end-of-endline

I'm also not convinced that the (min (point-max) ...) left is necessary.

Could you send an updated patch (on top of maint)?

Regards,

-- 
Nicolas Goaziou



Asynchronous org-agenda-redo

2019-12-12 Thread Ihor Radchenko
I am thinking if it is possible to implement org-agenda-redo
asynchronously.

Rebuilding agenda should normally not affect any buffer except agenda
buffer. So, it should be sufficient to block any agenda modifying
commands in the agenda buffer, redo the agenda buffer in separate
thread, and replace the old agenda with the calculated one.
Then, emacs should remain responsive while updating agenda (except for
modifying the agenda buffer).

For example, this naive code kind of works (forgetting that buffer-local
variables will not be passed to the thread):

(define-advice org-agenda-redo (:around (oldfun  all) make-async)
  (make-thread oldfun "org-agenda-redo"))

The problem is that emacs does not become responsive...

Another approach would be using async.el package, which allows calling
arbitrary function in subordinate emacs process. Then, the main emacs
instance should not be "frozen" (I use same approach for tangling and it
works fine).  

However, the question is how to pass the .org and agenda buffers to this
subordinate process. Opening the .org files there is not a good option
since it would give too much overhead to this asynchronous agenda.

Any suggestions? Alternative ideas?

Best,
Ihor




Re: [SOLVED]

2019-12-12 Thread Uwe Brauer
>>> "JK" == John Kitchin  writes:

> That is the default value of that variable. I guess you had set it
> elsewhere to be getting citep before.

Right, moreover in some obscure place which was not easy to find, and
the setting was also not commented, so it unclear to me why I did this.

Bad bad practise.

Uwe 


smime.p7s
Description: S/MIME cryptographic signature