Re: [Question] adding document global properties drawer

[stardiviner]

In an *empty* Org file buffer, I press =[C-c C-x p]= to add properties drawer. 
It
works fine. But when the Org buffer has nodes already like this:

#+begin_src org
|

,* node 1

context
#+end_src

The "|" means the cursor point.

Then I press =[C-c C-x p]= again try to add document global properties drawer, 
It
insert nothing. No modification on buffer at all. Is this a bug?

-- 
[ 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: attachment: link type export to HTML invalid attach dir

[Nicolas Goaziou]

Gustav Wikström  writes:

> Ok, noted. To my defense I was thinking more in the terms of subtyping
> then hardcoding. Because we have multiple link types which try to
> share an interface. But the interface isn't perfect for all different
> kinds of links.

Then, I suggest to improve the interface.

> So it doesn't seem too farfetched that some of those link types would
> benefit from additional custom properties, specific for those types.
> =application= and =search-option= for example isn't universally
> applicable to all link types.

As a side note, :application is on its way out, i.e., "file+emacs" stuff
is in "org-compat.el".

Also, IIRC, "docview" links have "go to page" option, and they don't
touch the parser.

> What I'm trying to argue for here is: Maybe it's not that crazy after
> all to allow links to have additional properties in the parser based
> on its type? (While certainly still trying to avoid it if possible!)

If new link types may not function correctly without touching the
parser, how do you create new link types out of Org's core? This is not
modular at all.

> (Off topic) I'm sorry to hear that you think I'm intentionally making
> things fuzzy.

Not at all! My wording is terrible. When I wrote

Also, you sometimes seem to blur, on purpose, the difference between
"attachment" and "file" links.

I meant something like:

   It seems to me that your intent is to have "attachment" links
   transparently become "file" links to the user.

Hence my suggestion to use link abbreviations. There's nothing negative
in it.

> One can indeed use the buffer position to derive the part of the path
> that comes from the subtree. But leaving it at that puts more
> requirements on the user of the parsed link in order to use it.

And higher order functions in "org-attach" could take care of it. Note
that expanding a link in the parser means all attachment links are
always expanded, even if they are not used. There's a cost to consider.

Besides, parser focus on the contents of the buffer. I think it is out
of its scope to infer file names for abbreviation links. It's more the
job of the parts consuming the parsed data.

> There is no :raw-path available in the properties for a parsed link.
> If there were we surely wouldn't have this conversation and I'd be
> using that already! :) 

I meant :raw-link, sorry.

> I.e. I like this suggestion. I considered using the :raw-link
> property, but the way it's currently used by the parser (i.e.
> expanding abbreviations) stopped me.

Please take how link abbreviations are handled in the parser out of the
equation. I already stated this is not a good way to handle them. We
should probably expand them in a "temp-link" variable, and parse it,
while keeping original link in :raw-link (barring white spaces fixes).
That would not be perfect either, because we would still be inferring
stuff.

That's another topic, really. Let's just ignore it for now.

> So, we're discussing regarding attachment as either: an abbreviation
> or a proper separate link type? I'm not sure what other options we
> have? I personally can't categorize it as an abbreviation since that
> is handled by a separate piece of code with other specifications. I.e.
> attachment wouldn't fit well inside org-link-abbrev-alist. 

What makes you think it wouldn't fit well?

> Attachments should function in the same way as file links, with search
> options and all. But be limited to the current set of attached files.

This isn't incompatible with the above, AFAICT.

> That's basically the way it was before the patches to fix stardiviners
> issues. Except not functioning well enough. It would require quite
> some code in org-attach to replicate existing file links
> functionality. Mostly code duplication I presume.

I didn't read stardiviner issues. Would you mind summarizing them? Or,
at least could you explain what is not functioning well enough?

Anyhow, you may have missed the "let's spot the needs and improve these
tools" part. If current tools lead to code duplication, we can fix that.

> The raw-path option sounds better to my ears.

Except I was meaning :raw-link :)

> One improvement I can think of (outside of the discussion above) is to
> make it possible to pass the argument to org-link-open along to each
> separate link type specialization.

Isn't that the job of :follow when defining a new link type?

> That one has bugged me for some time now, when I've wanted to force
> opening attachment links in emacs but couldn't.

IMO, forcing users to open stuff in a specific, non-configurable, way is
a bad idea. Why would we know better than them?

RE: attachment: link type export to HTML invalid attach dir

[Gustav Wikström]

Hi Nicolas,

Thanks for your comments!

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 19 januari 2020 22:12
> To: Gustav Wikström 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: attachment: link type export to HTML invalid attach dir
> 
> Hello,
> 
> Gustav Wikström  writes:
> 
> > Functionally it's in a good (and maintainable) state right now, in my
> > opinion. But I do understand that the contextual attribute added to
> > the parser may require some discussion.
> 
> This is not my main gripe here, although I'm not convinced that extra
> attribute is warranted. My concern is that you hard-code "attachment"
> type in the parser. I don't think this is the correct way to handle the
> situation.

Ok, noted. To my defense I was thinking more in the terms of subtyping then 
hardcoding. Because we have multiple link types which try to share an 
interface. But the interface isn't perfect for all different kinds of links. So 
it doesn't seem too farfetched that some of those link types would benefit from 
additional custom properties, specific for those types. =application= and 
=search-option= for example isn't universally applicable to all link types. And 
link abbreviations are completely hidden from the parser output, since even the 
raw-link is expanded. So maybe, in the quest for completion, link abbreviations 
should have custom properties as well? And allowing some kind of sub-typing 
might make the parsed output more easy to use, because the interpreter can 
infer based on type (which already exist as a link property) what extra 
properties to use.

What I'm trying to argue for here is: Maybe it's not that crazy after all to 
allow links to have additional properties in the parser based on its type? 
(While certainly still trying to avoid it if possible!)

> Some link types specifically handle files, e.g., "docview", yet do not
> need a special treatment in the parser. Note that "file" links have a good
> reason to be treated specially there, besides their obvious importance, as
> their type can be omitted. E.g., [[~/file.org]]. OTOH, I see no strong
> reason to handle "attachments" in here, since they behave like any other
> link type.
> 
> Worse, the parser is more or less the definition of the Org syntax.
> Therefore, including "attachment" in the parser is a signal meaning that
> in order to fully implement Org syntax, e.g., in another language, one
> need to support attachment links. Attachment links are undoubtedly useful,
> but they are not core, at all. So, I feel uneasy about leaking that type
> of link in the Element library.
> 
> Also, you sometimes seem to blur, on purpose, the difference between
> "attachment" and "file" links. If there should be no difference of
> treatment between them, as I already suggested, you may want to consider
> "attachment" as some functional link abbreviation. Then the "attachment"
> type doesn't really exist, much like the "bugzilla" link type from the
> manual.

(Off topic) I'm sorry to hear that you think I'm intentionally making things 
fuzzy. If it seems so, then please take it as a lack of clarity of thought or 
communication rather than intentional bad will. (/Off topic)

> In any case, we need a proper definition, a proper category too, for
> "attachment" links. Meanwhile, modifying the parser is just grasping at
> straws.
> 
> > I argue that the attachment folder is a part of the attachment link,
> > even though the information is found at a different location in the
> > document (i.e. as a property to nodes in the document hierarchy).
> > Parsing an attachment link would then be incomplete if that
> > information is discarded.
> 
> I argue that the buffer position of the attachment link and the path as
> written in the link are enough to fully expand the attachment file name.

One can indeed use the buffer position to derive the part of the path that 
comes from the subtree. But leaving it at that puts more requirements on the 
user of the parsed link in order to use it. Which takes us back to my first 
implementation of how the exporters would deal with the parsed link information 
(d70db54dbc).

> If I'm wrong, which could be, I probably didn't invest enough time in the
> Attach changes, then having the expanded form in :path and the initial
> form in :raw-path is enough.
> 
> > One option to adding an attribute could be to modify existing
> > properties by adding the attachment folder to, for example, the path
> > property. But that means to remove information about what was written
> > as path in the original link.
> 
> There is :raw-path for that purpose.

There is no :raw-path available in the properties for a parsed link. If there 
were we surely wouldn't have this conversation and I'd be using that already! 
:) I.e. I like this suggestion. I considered using the :raw-link property, but 
the way it's currently used by the parser (i.e. expanding abbreviations) 
stopped me. It felt rather like no matter how I tried to utilize the 

Re: Displaying remote images

[Jack Kamm]

Hi there,

Apologies for the delay on this. I've now got a more complete patch for
displaying remote images inline. Since downloading many remote images
could potentially hang Emacs on a slow connection, I've added an option
to control whether remote images are displayed. I've also added an
option to cache the remote images by visiting them in Emacs buffers.

The default behavior is not to display remote images, but to issue a
message that references the option that controls remote image display.

Best,
Jack

>From 88c37616fc7b910deec34f3013af36ceca8cde9b Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Sun, 19 Jan 2020 14:08:01 -0800
Subject: [PATCH] org.el: Add inline remote image display

* lisp/org.el (org-display-inline-images): Add inline remote image
display. Remote image display is controlled by the new option
`org-display-remote-inline-images'.
---
 etc/ORG-NEWS |  6 ++
 lisp/org.el  | 53 +++-
 2 files changed, 54 insertions(+), 5 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 67c3ca2ed..d219ff16a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -35,6 +35,12 @@ value in call to =java=.
 After editing a source block, Org will restore the window layout when
 ~org-src-window-setup~ is set to a value that modifies the layout.
 
+*** Display remote inline images
+
+Added the capability to display remote images inline.  Whether the
+images are actually displayed are controlled by the new option
+~org-display-remote-inline-images~.
+
 ** New functions
 *** ~org-columns-toggle-or-columns-quit~
 == bound to ~org-columns-toggle-or-columns-quit~ replaces the
diff --git a/lisp/org.el b/lisp/org.el
index e011ff61e..383c9ccaf 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16739,6 +16739,53 @@ INCLUDE-LINKED is passed to `org-display-inline-images'."
 ;; For without-x builds.
 (declare-function image-refresh "image" (spec  frame))
 
+(defcustom org-display-remote-inline-images 'skip-warn
+  "How to display remote inline images.
+Possible values of this option are:
+
+skip-warn Don't display, and emit a message about it.
+skip-silent   Don't display, and don't warn about it.
+download-always   Always download and display remote images.
+cache-in-buffer   Display remote images, and open them in separate buffers for
+  cache'ing.  Silently update the image buffer when a file
+  change is detected."
+  :type '(choice
+	  (const skip-warn)
+	  (const skip-silent)
+	  (const download-always)
+	  (const cache-in-buffers))
+  :group 'org-appearance)
+
+(defun org-inline-image--buffer-unibyte ()
+  (string-make-unibyte (buffer-substring-no-properties
+			(point-min) (point-max
+
+(defun org-inline-image--create (file width)
+  (let* ((remote-p (file-remote-p file))
+	 (file-or-data
+	  (if remote-p
+	  (pcase org-display-remote-inline-images
+		(`download-always (with-temp-buffer (insert-file-contents file)
+		(org-inline-image--buffer-unibyte)))
+		(`cache-in-buffers (let ((revert-without-query '(".*")))
+ (with-current-buffer
+	 (find-file-noselect file)
+   (org-inline-image--buffer-unibyte
+		(`skip-warn (message
+			 (concat "Set `org-display-remote-inline-images'"
+ " to display remote images."))
+			nil)
+		(`skip-silent nil)
+		(_ (message (concat "Invalid value of "
+"`org-display-remote-inline-images'"))
+		   nil))
+	file)))
+(when file-or-data
+  (create-image file-or-data
+		(and (image-type-available-p 'imagemagick)
+			 width 'imagemagick)
+		remote-p :width width
+
 (defun org-display-inline-images ( include-linked refresh beg end)
   "Display inline images.
 
@@ -16857,11 +16904,7 @@ buffer boundaries with possible narrowing."
 'org-image-overlay)))
 		  (if (and (car-safe old) refresh)
 			  (image-refresh (overlay-get (cdr old) 'display))
-			(let ((image (create-image file
-		   (and (image-type-available-p 'imagemagick)
-			width 'imagemagick)
-		   nil
-		   :width width)))
+			(let ((image (org-inline-image--create file width)))
 			  (when image
 			(let ((ov (make-overlay
    (org-element-property :begin link)
-- 
2.25.0

Re: attachment: link type export to HTML invalid attach dir

[Nicolas Goaziou]

Hello,

Gustav Wikström  writes:

> Functionally it's in a good (and maintainable) state right now, in my
> opinion. But I do understand that the contextual attribute added to
> the parser may require some discussion.

This is not my main gripe here, although I'm not convinced that extra
attribute is warranted. My concern is that you hard-code "attachment"
type in the parser. I don't think this is the correct way to handle the
situation.

Some link types specifically handle files, e.g., "docview", yet do not
need a special treatment in the parser. Note that "file" links have
a good reason to be treated specially there, besides their obvious
importance, as their type can be omitted. E.g., [[~/file.org]]. OTOH,
I see no strong reason to handle "attachments" in here, since they
behave like any other link type.

Worse, the parser is more or less the definition of the Org syntax.
Therefore, including "attachment" in the parser is a signal meaning that
in order to fully implement Org syntax, e.g., in another language, one
need to support attachment links. Attachment links are undoubtedly
useful, but they are not core, at all. So, I feel uneasy about leaking
that type of link in the Element library.

Also, you sometimes seem to blur, on purpose, the difference between
"attachment" and "file" links. If there should be no difference of
treatment between them, as I already suggested, you may want to consider
"attachment" as some functional link abbreviation. Then the "attachment"
type doesn't really exist, much like the "bugzilla" link type from the
manual.

In any case, we need a proper definition, a proper category too, for
"attachment" links. Meanwhile, modifying the parser is just grasping at
straws.

> I argue that the attachment folder is a part of the attachment link,
> even though the information is found at a different location in the
> document (i.e. as a property to nodes in the document hierarchy).
> Parsing an attachment link would then be incomplete if that
> information is discarded.

I argue that the buffer position of the attachment link and the path as
written in the link are enough to fully expand the attachment file name.

If I'm wrong, which could be, I probably didn't invest enough time in
the Attach changes, then having the expanded form in :path and the
initial form in :raw-path is enough.

> One option to adding an attribute could be to modify existing
> properties by adding the attachment folder to, for example, the path
> property. But that means to remove information about what was written
> as path in the original link.

There is :raw-path for that purpose.

> So I argue to keep path as the original path. But that means extra
> information is needed to also make it work in the filesystem. If we
> would translate an attachment link to a file link in ox.el that means
> we remove the option for exporters to decide for themselves what to do
> with the link. And I think the exporter should have that option. :)

Let's first think about what category of object an attachment link
belongs to. Then we can discuss about how to export it. 

Again, if "attachment" == "file", the exporters shouldn't treat them
differently. If "attachment" is a new link type, it should define its
own rules in its own library, namely "org-attach.el".

> Right now the ASCII exporter for example outputs attachment links as
> attachment:expanded_path instead of file:expanded_path. Since the link
> type actually is attachment. And for a solemnly textual export the
> exported information should be kept as close to source as possible. So
> either we explicitly and always say attachment-links *are* file-links
> in disguise (i.e. even change type in the parser), or we don't say
> that, and then don't say that all the way to the edge of the system.
> And let the uses of the link type decide themselves what to do. Which
> is what I propose.

As I explained above, your proposal is not crystal clear.

My gut feeling is that "attachment" links are just a regular link type,
that can be opened, and exported, like "file" links. They should live in
"org-attach.el", using the provided tools to define new link types, like
almost every other link types do. If those tools are not enough to
express all the subtleties of "attachment" links, then let's spot the
needs and improve those tools. That will benefit to every developer that
wants to implement a new link type, what creating another corner case in
the parser cannot do.


Regards,

-- 
Nicolas Goaziou

[RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Dan Drake]

I asked about a way to specify a time when using org-resolve-clock instead
of a number of minutes:

https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00010.html

I've implemented this myself and a patch is attached. Comments welcome --
my change works, but I'm not sure about coding style, and right now there's
no error checking.

I marked the patch as a tiny change, but it does add a new menu option and
behavior to org-resolve-clock, so there may be an argument that it's not,
from a user perspective, a "tiny change", but code-wise it's quite simple:
the core logic really isn't more than "ask the user for a time and
subtract".

I hope this change can be incorporated into the official Org release.

Regards,

Dan


-- 
Ceci n'est pas une .signature.
From 7c369696c2eb9ebcd72ac9e7415d2481c4da7d80 Mon Sep 17 00:00:00 2001
From: Dan Drake 
Date: Sun, 19 Jan 2020 08:24:12 -0600
Subject: [PATCH] org-clock.el: add `t' option to org-clock-resolve

* org-clock.el (org-clock-resolve): add `t' option. This works just like
`k', but asks the user to specify a time, instead of a number of
minutes.

Often when you are interrupted at a task and get back to it, you know
what time the interruption happened. This option makes it easy to tell
org-resolve-clocks about that. For example, say you clocked into task A
at, say, 9:37:

* original task A
  :LOGBOOK:
  CLOCK: [2020-01-21 Mon 09:37]
  :END:

While working on task A, you get a phone call. When the call is done,
you'd like to update your time logging to reflect the phone call. Your
phone says the call was at 11:09.

With C-c C-x C-z, you can use the `K' option, but you need to figure out
the number of minutes to keep. It's easier to look at the phone, or to
mentally note the time when an interruption starts. With the new option,
you can select `T', and just specify a time of 11:09. The state is now:

* original task A
  :LOGBOOK:
  CLOCK: [2020-01-21 Mon 09:37]--[2020-01-21 Mon 11:09] => 1:32
  :END:

You add the phone call to your org buffer and do C-c C-x C-i to clock
in. Org asks you to start the time from when the previous task ended,
you say yes, and the state is now:

* original task A
  :LOGBOOK:
  CLOCK: [2020-01-21 Mon 09:37]--[2020-01-21 Mon 11:09] => 1:32
  :END:
* task B, phone call
  :LOGBOOK:
  CLOCK: [2020-01-21 Mon 11:09]
  :END:

At this point, you can clock back into task A, or any other task.

The key feature here is to be able to just type in a time -- in any
format accepted by org-read-date -- instead of specifying a number of
minutes.

TINYCHANGE
---
 lisp/org-clock.el | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 06df2d497..a73b500a8 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -986,6 +986,12 @@ CLOCK is a cons cell of the form (MARKER START-TIME)."
 		 (org-flag-drawer nil element))
 		   (throw 'exit nil)))
 
+(defun time-to-mins-to-keep (start-time)
+  "Asks the user for a time and returns the number of minutes
+from START-TIME to that time."
+  (floor (/ (float-time
+	 (time-subtract (org-read-date t t) start-time)) 60)))
+
 (defun org-clock-resolve (clock  prompt-fn last-valid fail-quietly)
   "Resolve an open Org clock.
 An open clock was found, with `dangling' possibly being non-nil.
@@ -1022,6 +1028,9 @@ k/K  Keep X minutes of the idle time (default is all).  If this
  that many minutes after the time that idling began, and then
  clocked back in at the present time.
 
+t/T  Like `k', but will ask you to specify a time, instead of a
+ number of minutes.
+
 g/G  Indicate that you \"got back\" X minutes ago.  This is quite
  different from `k': it clocks you out from the beginning of
  the idle period and clock you back in X minutes ago.
@@ -1041,19 +1050,21 @@ to be CLOCKED OUT."
 		(while (or (null char-pressed)
 			   (and (not (memq char-pressed
 	   '(?k ?K ?g ?G ?s ?S ?C
-		?j ?J ?i ?q)))
+		?j ?J ?i ?q ?t ?T)))
 (or (ding) t)))
 		  (setq char-pressed
 			(read-char (concat (funcall prompt-fn clock)
-	   " [jkKgGSscCiq]? ")
+	   " [jkKtTgGSscCiq]? ")
    nil 45)))
 		(and (not (memq char-pressed '(?i ?q))) char-pressed)
 	 (default
 	   (floor (org-time-convert-to-integer (org-time-since last-valid))
 		  60))
 	 (keep
-	  (and (memq ch '(?k ?K))
-	   (read-number "Keep how many minutes? " default)))
+	  (or (and (memq ch '(?k ?K))
+		   (read-number "Keep how many minutes? " default))
+	  (and (memq ch '(?t ?T))
+		   (time-to-mins-to-keep last-valid
 	 (gotback
 	  (and (memq ch '(?g ?G))
 	   (read-number "Got back how many minutes ago? " default)))
@@ -1068,7 +1079,7 @@ to be CLOCKED OUT."
 	  (org-clock-resolve-clock clock 'now nil t nil fail-quietly))
   (org-clock-jump-to-current-clock clock))
  ((or (null ch)
-	  (not (memq 

Re: [RFC PATCH] Changes to pop-up source buffers

[Jack Kamm]

Hi Kyle,

Thanks for taking the time to do a thorough review of the patch, I found
your response (especially the many examples you included) to be very
illuminating.

I agree that relying more on display-buffer-based functions is good, but
in retrospect I may have been over-eager, especially since
reorganize-frame can't be switched over, and split-window-right might
require writing a new action function.

My main motivation was to use my own display-buffer configuration to
show the source buffer. So I've rewritten the patch to be smaller and
more conservative, just adding a "plain" option to org-src-window-setup,
and not changing the implementation of any existing options.  I think
this is less likely to disrupt existing workflows or introduce
accidental bugs.

What do you think of using this smaller patch instead?

As an aside, in case we do decide to re-implement some of the display
options, now or in future, I did have a slight discrepancy from the
behavior you describe for split-window-right:

> Quickly testing, this has a slight change in behavior.  If there is
> already a window below the current Org buffer window, the new source
> window will be popped up below the _other_ window rather than the Org
> buffer.  I think this could be fixed (and the code in general
> simplified) by using display-buffer-below-selected.

On my own system, the window pops up below the existing Org buffer, even
if I have several existing horizontal splits. I'm not sure why.

>From a9cb8889df25697ff73e7c1e72987dac01875c8a Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Sun, 19 Jan 2020 08:28:36 -0800
Subject: [PATCH] org-src: Add option 'plain to org-src-window-setup

* lisp/org-src.el (org-src-window-setup): Add option 'plain for
org-src-window-setup, that uses vanilla display-buffer to show the
source window.
---
 etc/ORG-NEWS| 7 +++
 lisp/org-src.el | 6 ++
 2 files changed, 13 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 67c3ca2ed..b32d37e65 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -35,6 +35,13 @@ value in call to =java=.
 After editing a source block, Org will restore the window layout when
 ~org-src-window-setup~ is set to a value that modifies the layout.
 
+*** New option to show source buffers using "plain" display-buffer
+
+Added option ~'plain~ to ~org-src-window-setup~ to show source buffers
+using ~display-buffer~. This allows users to control how source
+buffers are displayed by modifying ~display-buffer-alist~ or
+~display-buffer-base-action~.
+
 ** New functions
 *** ~org-columns-toggle-or-columns-quit~
 == bound to ~org-columns-toggle-or-columns-quit~ replaces the
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 878821b14..52e99cf04 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -148,6 +148,9 @@ the existing edit buffer."
   "How the source code edit buffer should be displayed.
 Possible values for this option are:
 
+plain  Show edit buffer using `display-buffer'.  Users can
+   further control the display behavior by modifying
+   `display-buffer-alist' and its relatives.
 current-window Show edit buffer in the current window, keeping all other
windows.
 split-window-below Show edit buffer below the current window, keeping all
@@ -801,6 +804,9 @@ Raise an error when current buffer is not a source editing buffer."
 
 (defun org-src-switch-to-buffer (buffer context)
   (pcase org-src-window-setup
+(`plain
+ (when (eq context 'exit) (quit-restore-window))
+ (pop-to-buffer buffer))
 (`current-window (pop-to-buffer-same-window buffer))
 (`other-window
  (switch-to-buffer-other-window buffer))
-- 
2.25.0

Re: Help me secure some free time for org-mode in 2020

[Jorge P . de Morais Neto]

Hello Bastien.

Em [2019-12-16 seg 19:09:55+0100], Bastien escreveu:

> My plan for 2020 is to ensure a smooth transition while I step down
> as the maintainer---at least by the end of 2020, probably by July.

You stepping down is a pity.

> As my timetable (and family life) has become more stable, I am more
> confident I can dedicate some of my free time again to maintaining
> until the transition is done: also because there are many ideas I
> would like to try, discuss and implement---Org possibilities still
> feel endless!

That is a relief.  But I hope you can still work on Org in the long run.

> If you want to help me secure some free time, please go ahead!
>
> I recommend using https://liberapay.com/bzg

I have just donated € 10.  I'm sorry for donating so little, but the
Brazilian Real is undervalued against the Euro (as well as against the
US Dollar).  Besides, I have some debt.

Regards and thank you!
-- 
- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
- Free/libre software for Replicant, LineageOS and Android: https://f-droid.org
- [[https://www.gnu.org/philosophy/free-sw.html][What is free software?]]

ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)

[Karl Voit]

Hi all,


BACKGROUND:

I'm using org-depend since ages[1]. As a matter of fact, it was the
initial reason why I started with Org mode in the first place.

One of my many workflows[2] exports the agenda for the upcoming 60
days into an ICS file via a cron job during night:

: emacs-snapshot --batch --load /home/vk/.emacs.d/init.el --eval '(progn 
(my-export-agenda))'

my-export-agenda[6] basically consists of:
: (org-agenda-list nil nil 60)
: (org-agenda-write (concat my-user-emacs-directory 
"var/export/agenda-export.ics"))

This ICS file is then postprocessed and uploaded to my calendar server
so that my mobile phone calendar is able to display events and
appointments.


This workflow stopped working end of December.


ERRORS and INVESTIGATION:

Error message when this batch run of Emacs exits after 5 hours(!):
: Lisp nesting exceeds ‘max-lisp-eval-depth’

I updated my Org version[3] recently to get v9.3 from git maint. This
was Wed Dec 4 10:37:19 2019 +0100. So the issue with the ICS export
did not appear at the same time of the update.

I also get:
: [...]
: Preparing diary...done
: Preparing diary...done
: Position saved to mark ring, go back with ‘C-c &’. [1038 times]
: org-before-first-heading-p: Variable binding depth exceeds max-specpdl-size

I changed the value for the variables without changing the result:
: (setq max-specpdl-size 1)
: (setq max-lisp-eval-depth 5)

I even upgraded my Emacs version from 25 to 27[3]. No change.

I reduced my set of org-agenda-files and did some test runs: most
single org files resulted in an ICS export. Some single org files did
result in the error.

Reducing the export period from 60 to 7 days did not change the error.

I also get following as execution cancellation error:
: Before first headline at position 586 in buffer  *temp*-99684

When running the job, I see *lots* lines like[4]:
: Garbage collecting...
: Garbage collecting...done

To me, it's a data-related issue with my Org mode files so that others
most likely are not able to reproduce my issue at all.

Disabling org-depend results in a working ICS export that took much
less time. I'm not sure if org-depend is directly related or just
reduces "the complexity" such that the job is able to be finalized.


QUESTIONS:

I'm looking for ideas what I may check in order to be able to use
org-depend again.

Should I do a profiler report? How do I have to do this in order to
get good results?

Further more: is here somebody able to tell if org-edna[5] does have
this issues as well? After all, org-edna is somewhat more complex than
org-depend.


A migration from org-depend to org-edna would be doable to me but with
a decent effort. (I'm thinking of migrating only tasks that are not
DONE or CANCELLED as I do think closed tasks do not irritate org-edna
with old org-depend syntax.)



[1] https://karl-voit.at/2016/12/18/org-depend/
Almost everything I use is :BLOCKER: properties and very
rarely :TRIGGER: events.

[2] just a selection is described on 
https://karl-voit.at/2019/09/25/using-orgmode/

[3] Org mode version 9.3 (release_9.3-3-g46319b.dirty @ mixed installation!
GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
   3.22.11) of 2019-12-15, unofficial emacs-snapshot build

[4] I setup up "gcmh" package because of a comment on:

https://www.reddit.com/r/orgmode/comments/e9p84n/scaling_org_better_to_use_more_medsize_files_or/fcm5bsc/

[5] https://elpa.gnu.org/packages/org-edna.html

[6] https://github.com/novoid/dot-emacs/blob/master/config.org


-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

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

[Gustav Wikström]

Hi,

> -Original Message-
> From: stardiviner 
> Sent: den 19 januari 2020 05:28
> To: Gustav Wikström 
> Cc: numbch...@gmail.com; emacs-orgmode@gnu.org
> Subject: Re: [O] FW: [RFC] Link-type for attachments, more attach options
> 
> [...]
> 
> From the source code, it seems indeed still original code logic.
> 
> Then I checked out my Emacs init git log, confirmed it is ~'attached~
> option value at first time. So this is my mistake.
> 
> Because this new ~attachment:~ link type has potential issues like on
> exporting.

The issue with attachment links in the exporters should be fixed since the 
report of the export issues you sent a short while back. Any external exporter 
you use may ofc still need to be updated for attachment links.

> So I decided to still use old ~file:~ link type. So I thought should set
> ~org-attach-store-link-p~ to ~t~. It indeed use ~file:~ link type instead
> of ~attachment:~ now. But the store link behavior affected.
> 
> So the problem is how can I use both ~file:~ link type for attachments and
> use this new attached store link?

Understood, and I see no issue with complementing org-attach-store-link-p with 
another option. One that stores a file link to the attached files location. 
Pushed a change for that just now.