Re: [O] [RFC] Could we get rid of Org specific "mark ring"

[Allen Li]

On Mon, Feb 26, 2018 at 5:54 PM Samuel Wales  wrote:

> On 2/26/18, Nicolas Goaziou  wrote:
> > I guess these are rhetorical questions because I answered them above.

> real questions, fyi, but never mind.

> >> if not, then i will have to use local mark
> >> ring.  this means i have to think about whether the file i was in was
> >> the same file or not.
> >
> > In practice, when I have no clue about where I was before, I first try
> > a local ring jump. If it fails, I do a global ring jump. This is
> > a no-brainer.

> i see.  but 1 step [current org pop behavior] is the only no brainer
> to me.  2 steps could take me to a similar link in the same file and
> really confuse me.

> i actually don't care what file the previous link was in.  or what
> file i am in.  org is a forest.

> i care just what project i am in.

> but even if i get used to the 2 steps, there are more issues:

> 1] the local "try a local ring jump" jump will move me away from where
> i was, which is undesirable.

> 2] and it seems that the global jump will not be guaranteed to take me
> to the actual link i did RET on.  i might have forgotten what it was.
> knowing i can get back to it can be reassuring.

> > The current situation is worse. I have to know how I made it to the
> > current location, i.e., with an Org command or not. It is harder to
> > mitigate.

> can't this be fixed by pushing to both emacs mark rings in addition to
> the current org behavior?  then you can just use emacs mark rings.

> > I changed `org-mark-ring-push' to also push to Emacs mark ring. This is
> > better, but, out of the 3 problems I stated at the beginning of this
> > thread, it only solves the second one.

> i presume you mean:

> - Emacs already provides two of them: the local one and the global one.
>This feels like re-inventing the wheel;

> the solution seems to require a new command [such as a wrapper to
> global mark pop to go to the exact location.  i presume you will push
> to it upon RET on a link.  if not then we need that too.].  otherwise
> behavior is changed significantly.

> - Org mark ring and Emacs mark ring are sometimes out of sync, hence bug
>#23745;

> i never encountered the bug, but a push or two presumably fixes it.
  thank you.

> - `org-mark-ring-goto' binding (C-c &) conflicts with some minor modes
>(e.g., Yasnippet).

> i'm ok with removing the binding.

> am i really the only objector?  if i  knew what to do to get my
> currently non-confusing behavior back i'd be ok with it of course.

I retract my previous stance and think that we should keep the
org-mark-ring for now.  While I do not use the org-mark-ring, I do use
xref's marker ring, and I appreciate the value of a "link ring"
separate from mark-ring and global-mark-ring.

I also do not find global-mark-ring very intuitive to use.  The
feature appears to date back to 1994 (with essentially no changes
since then) with an unhelpful commit message, and the mailing list
archives do not go back that far, so I cannot fathom what use case the
author had for it.

The fact that xref, org, and anaconda-mode, to name the three I am
aware of, all have seen fit to invent their own "link ring" instead of
using the standard mark, suggests that there is a real need for a kind
of "link ring" built into Emacs proper.

Marks make sense in a single file because they serve the dual purpose
of delimiting the region and allowing the user to jump back to the
previous location of point.  However, it’s not really useful for the
"follow link" type jumps that org or xref use.  I don’t really see a
need to operate on the region between a link and the destination of
the link, assuming the destination is in the same file, but that
region is often useful for the other ways that mark is set (e.g.,
yank, isearch-forward).

Furthermore, the semantics of hyperlinking have been established;
users expect to be able to jump back after following a link, and
it is a useful feature.

My opinion is thus to keep org-mark-ring for now and discuss on
emacs-devel.  It’s true that emacs-devel is conservative (and slow),
but I think it’s worth asking at least.



> thank you for engaging.

[O] bug#23745: bug#23745: 25.0.94; Org: (pop-to-mark-command) doesn't work when using (org-open-at-point) to visit a same-file link

[Samuel Wales]

quite useful to have this for reference in the org mailing list, as we
are discussing it.

Re: [O] [RFC] Could we get rid of Org specific "mark ring"

[Samuel Wales]

On 2/26/18, Nicolas Goaziou  wrote:
> I guess these are rhetorical questions because I answered them above.

real questions, fyi, but never mind.

>> if not, then i will have to use local mark
>> ring.  this means i have to think about whether the file i was in was
>> the same file or not.
>
> In practice, when I have no clue about where I was before, I first try
> a local ring jump. If it fails, I do a global ring jump. This is
> a no-brainer.

i see.  but 1 step [current org pop behavior] is the only no brainer
to me.  2 steps could take me to a similar link in the same file and
really confuse me.

i actually don't care what file the previous link was in.  or what
file i am in.  org is a forest.

i care just what project i am in.

but even if i get used to the 2 steps, there are more issues:

1] the local "try a local ring jump" jump will move me away from where
i was, which is undesirable.

2] and it seems that the global jump will not be guaranteed to take me
to the actual link i did RET on.  i might have forgotten what it was.
knowing i can get back to it can be reassuring.

> The current situation is worse. I have to know how I made it to the
> current location, i.e., with an Org command or not. It is harder to
> mitigate.

can't this be fixed by pushing to both emacs mark rings in addition to
the current org behavior?  then you can just use emacs mark rings.

> I changed `org-mark-ring-push' to also push to Emacs mark ring. This is
> better, but, out of the 3 problems I stated at the beginning of this
> thread, it only solves the second one.

i presume you mean:

- Emacs already provides two of them: the local one and the global one.
  This feels like re-inventing the wheel;

the solution seems to require a new command [such as a wrapper to
global mark pop to go to the exact location.  i presume you will push
to it upon RET on a link.  if not then we need that too.].  otherwise
behavior is changed significantly.

- Org mark ring and Emacs mark ring are sometimes out of sync, hence bug
  #23745;

i never encountered the bug, but a push or two presumably fixes it.  thank you.

- `org-mark-ring-goto' binding (C-c &) conflicts with some minor modes
  (e.g., Yasnippet).

i'm ok with removing the binding.

am i really the only objector?  if i  knew what to do to get my
currently non-confusing behavior back i'd be ok with it of course.

thank you for engaging.

Re: [O] Removing ding each time I type TAB when not after a structure template with org-tempo enabled

[Nicolas Goaziou]

Hello,

Brent Goodrick  writes:

> Thanks. This is close, but not completely fixed: When I have the point at
> the start of a line in a Org file, and type the TAB key, it does not move
> like it should up underneath the prior heading.

I see. I pushed another fix into master. Hopefully, this is now
completely fixed.

Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] face for upcoming deadlines in agenda

[Nicolas Goaziou]

Alex Branham  writes:

> Done, thanks
>
> 
>
> From 66a394b3736306e4039b29393915b4ca1821a86b Mon Sep 17 00:00:00 2001
> From: Alex Branham 
> Date: Mon, 26 Feb 2018 18:39:50 -0600
> Subject: [PATCH] * lisp/org-faces.el(org-upcoming-distant-deadline-face): new
>  face

Applied. Thank you.

Re: [O] face for upcoming deadlines in agenda

[Alex Branham]

On Mon 26 Feb 2018 at 18:30, Nicolas Goaziou  wrote:

> Hello,
>
> Alex Branham  writes:
>
>> I've attached a patch which gives a name to the 0.0 face in
>> org-agenda-deadline-faces. This lets themes customize the value more
>> easily. (I've already signed the FSF copyright papers)
>
> Thank you. Could you also provide a short ORG-NEW entry about it?

Done, thanks



>From 66a394b3736306e4039b29393915b4ca1821a86b Mon Sep 17 00:00:00 2001
From: Alex Branham 
Date: Mon, 26 Feb 2018 18:39:50 -0600
Subject: [PATCH] * lisp/org-faces.el(org-upcoming-distant-deadline-face): new
 face

---
 etc/ORG-NEWS  | 2 +-
 lisp/org-faces.el | 9 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index aff372582..a40dd1b9a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -188,7 +188,7 @@ you should expect to see something like:
 #+BEGIN_EXAMPLE
   ,#+STARTUP: shrink
 #+END_EXAMPLE
-
+*** New face ~org-upcoming-distant-deadline~ which is meant to be used as the 
face for distant deadlines, see ~org-agenda-deadline-faces~
 ** New functions
 *** ~org-insert-structure-template~
 
diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 750ada1e9..ef00f5b2c 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -511,13 +511,18 @@ which days belong to the weekend."
 (((class color) (min-colors 8)  (background light)) (:foreground "red"))
 (((class color) (min-colors 8)  (background dark)) (:foreground "red" 
:bold t))
 (t (:bold t)))
-  "Face for items scheduled previously, and not yet done."
+  "Face for items scheduled previously, and not yet done.
+See also `org-agenda-deadline-faces'."
   :group 'org-faces)
 
+(defface org-upcoming-distant-deadline '((t :inherit org-default))
+  "Face for items scheduled previously, not done, and have a distant deadline.
+See also `org-agenda-deadline-faces'.")
+
 (defcustom org-agenda-deadline-faces
   '((1.0 . org-warning)
 (0.5 . org-upcoming-deadline)
-(0.0 . default))
+(0.0 . org-upcoming-distant-deadline))
   "Faces for showing deadlines in the agenda.
 This is a list of cons cells.  The cdr of each cell is a face to be used,
 and it can also just be like \\='(:foreground \"yellow\").
-- 
2.16.2


>From 66a394b3736306e4039b29393915b4ca1821a86b Mon Sep 17 00:00:00 2001
From: Alex Branham 
Date: Mon, 26 Feb 2018 18:39:50 -0600
Subject: [PATCH] * lisp/org-faces.el(org-upcoming-distant-deadline-face): new
 face

---
 etc/ORG-NEWS  | 2 +-
 lisp/org-faces.el | 9 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index aff372582..a40dd1b9a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -188,7 +188,7 @@ you should expect to see something like:
 #+BEGIN_EXAMPLE
   ,#+STARTUP: shrink
 #+END_EXAMPLE
-
+*** New face ~org-upcoming-distant-deadline~ which is meant to be used as the face for distant deadlines, see ~org-agenda-deadline-faces~
 ** New functions
 *** ~org-insert-structure-template~
 
diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 750ada1e9..ef00f5b2c 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -511,13 +511,18 @@ which days belong to the weekend."
 (((class color) (min-colors 8)  (background light)) (:foreground "red"))
 (((class color) (min-colors 8)  (background dark)) (:foreground "red" :bold t))
 (t (:bold t)))
-  "Face for items scheduled previously, and not yet done."
+  "Face for items scheduled previously, and not yet done.
+See also `org-agenda-deadline-faces'."
   :group 'org-faces)
 
+(defface org-upcoming-distant-deadline '((t :inherit org-default))
+  "Face for items scheduled previously, not done, and have a distant deadline.
+See also `org-agenda-deadline-faces'.")
+
 (defcustom org-agenda-deadline-faces
   '((1.0 . org-warning)
 (0.5 . org-upcoming-deadline)
-(0.0 . default))
+(0.0 . org-upcoming-distant-deadline))
   "Faces for showing deadlines in the agenda.
 This is a list of cons cells.  The cdr of each cell is a face to be used,
 and it can also just be like \\='(:foreground \"yellow\").
-- 
2.16.2

Re: [O] face for upcoming deadlines in agenda

[Nicolas Goaziou]

Hello,

Alex Branham  writes:

> I've attached a patch which gives a name to the 0.0 face in
> org-agenda-deadline-faces. This lets themes customize the value more
> easily. (I've already signed the FSF copyright papers)

Thank you. Could you also provide a short ORG-NEW entry about it?

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] [RFC] Could we get rid of Org specific "mark ring"

[Nicolas Goaziou]

Hello,

Samuel Wales  writes:

> On 2/25/18, Nicolas Goaziou  wrote:

>> If you're still in the same document, the local mark ring moves you back
>> to the previous location. If you are not in the same document anymore,
>> the global mark ring brings you back to the previous location.

> i am at a link in file a that sends me to file b.  i click on it
> [actually ret on it].  i pop the global mark ring.
>
> you are saying i will always get back to the link in file a always?
>
> now same example with the link pointing to file a.  will the global
> mark ring take me there?

I guess these are rhetorical questions because I answered them above.

> if not, then i will have to use local mark
> ring.  this means i have to think about whether the file i was in was
> the same file or not.

In practice, when I have no clue about where I was before, I first try
a local ring jump. If it fails, I do a global ring jump. This is
a no-brainer.

> almost always, by the time i have done whatever
> i was doing at target, that is totally forgotten.  the cognitive
> overhead criterion in my first paragraph is violated.  so i /think/ my
> statement about the back button behavior being broken with your change
> is true.  please correct if that is wrong.

The current situation is worse. I have to know how I made it to the
current location, i.e., with an Org command or not. It is harder to
mitigate.

>>> [for the bug that seems to have prompted your proposal, we could be
>>> discussing pushing to the global and local mark rings.  but this does
>>> not seem to be what we are discussing.]

I changed `org-mark-ring-push' to also push to Emacs mark ring. This is
better, but, out of the 3 problems I stated at the beginning of this
thread, it only solves the second one.

> i am saying that it's not a substitute for the current org behavior.

My proposal is slightly different than the current Org behaviour, but
the features are the same. I don't think Org own mark ring is really
needed. It makes Org less integrated in the Emacs ecosystem.

Regards,

-- 
Nicolas Goaziou

[O] bug#23745: 25.0.94; Org: (pop-to-mark-command) doesn't work when using (org-open-at-point) to visit a same-file link

[Nicolas Goaziou]

Hello,

Dima Kogan  writes:

> Hi. Consider this org-mode file:
>
> =
> * 
> b
>
> * 
> [[]]
> =
>
> With the point at the [[]] link, I can visit the  heading with
> C-c C-o (org-open-at-point), and I can go back to where I was with the
> org-specific C-c & (org-mark-ring-goto). But I should also be able to go
> back with C-u C-SPC (effectively pop-to-mark-command), since that works
> for inside-the-same-buffer jumps in all other emacs context, including
> non-org ones. I suspect all we would need to do is to
> (push-mark-command) before we jump in (org-open-at-point). Is this
> simply forgotten, or was it omitted on purpose? If the former, I'll post
> a patch.

Fixed.

Now `org-mark-ring-push' also calls `push-mark'. Ultimately, I think the
latter should replace former, although navigation with Org dedicated
mark ring is still slightly easier (e.g., no distinction between global
and local rings).

Thank you.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] Bug: org-paste-subtree displaces folded content [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180212/)]

[Nicolas Goaziou]

Hello,

Allen Li  writes:

> I modified the example a bit and made the undesired behavior unclear.
>
> * foo
> :PROPERTIES:
> :ID: a
> :END:
> * bar
> :PROPERTIES:
> :ID: b
> :END:
>
> Folded, this looks like
>
> * foo...
> * bar...
>
> With point on the f in foo, press C-c C-x C-w.  With point on the b in bar,
> press C-c C-x C-y.  Results in
>
> * bar
> * foo...
>
> Unfolded, this looks like
>
> * bar
> * foo
> :PROPERTIES:
> :ID: a
> :END:
> :PROPERTIES:
> :ID: b
> :END:
>
> I would expect C-c C-x C-y to work like C-RET rather than M-RET, that is to
> always append after the heading and body rather than splitting it.

I changed the behaviour of `org-paste-subtree' in master. Does it solve
the issue?

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] face for upcoming deadlines in agenda

[Alex Branham]

I've attached a patch which gives a name to the 0.0 face in
org-agenda-deadline-faces. This lets themes customize the value more
easily. (I've already signed the FSF copyright papers)

Thanks again!
Alex

--

>From 1a3f167583f9c964b37f92f2f0a4d67840749677 Mon Sep 17 00:00:00 2001
From: Alex Branham 
Date: Mon, 26 Feb 2018 16:41:40 -0600
Subject: [PATCH] * lisp/org-faces.el(org-upcoming-distant-deadline-face): new
 face

---
 lisp/org-faces.el | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 750ada1e9..ef00f5b2c 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -511,13 +511,18 @@ which days belong to the weekend."
 (((class color) (min-colors 8)  (background light)) (:foreground "red"))
 (((class color) (min-colors 8)  (background dark)) (:foreground "red" 
:bold t))
 (t (:bold t)))
-  "Face for items scheduled previously, and not yet done."
+  "Face for items scheduled previously, and not yet done.
+See also `org-agenda-deadline-faces'."
   :group 'org-faces)

+(defface org-upcoming-distant-deadline '((t :inherit org-default))
+  "Face for items scheduled previously, not done, and have a distant deadline.
+See also `org-agenda-deadline-faces'.")
+
 (defcustom org-agenda-deadline-faces
   '((1.0 . org-warning)
 (0.5 . org-upcoming-deadline)
-(0.0 . default))
+(0.0 . org-upcoming-distant-deadline))
   "Faces for showing deadlines in the agenda.
 This is a list of cons cells.  The cdr of each cell is a face to be used,
 and it can also just be like \\='(:foreground \"yellow\").
--
2.16.2


>From 1a3f167583f9c964b37f92f2f0a4d67840749677 Mon Sep 17 00:00:00 2001
From: Alex Branham 
Date: Mon, 26 Feb 2018 16:41:40 -0600
Subject: [PATCH] * lisp/org-faces.el(org-upcoming-distant-deadline-face): new
 face

---
 lisp/org-faces.el | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org-faces.el b/lisp/org-faces.el
index 750ada1e9..ef00f5b2c 100644
--- a/lisp/org-faces.el
+++ b/lisp/org-faces.el
@@ -511,13 +511,18 @@ which days belong to the weekend."
 (((class color) (min-colors 8)  (background light)) (:foreground "red"))
 (((class color) (min-colors 8)  (background dark)) (:foreground "red" :bold t))
 (t (:bold t)))
-  "Face for items scheduled previously, and not yet done."
+  "Face for items scheduled previously, and not yet done.
+See also `org-agenda-deadline-faces'."
   :group 'org-faces)
 
+(defface org-upcoming-distant-deadline '((t :inherit org-default))
+  "Face for items scheduled previously, not done, and have a distant deadline.
+See also `org-agenda-deadline-faces'.")
+
 (defcustom org-agenda-deadline-faces
   '((1.0 . org-warning)
 (0.5 . org-upcoming-deadline)
-(0.0 . default))
+(0.0 . org-upcoming-distant-deadline))
   "Faces for showing deadlines in the agenda.
 This is a list of cons cells.  The cdr of each cell is a face to be used,
 and it can also just be like \\='(:foreground \"yellow\").
-- 
2.16.2

Re: [O] face for upcoming deadlines in agenda

[Alex Branham]

On Mon 26 Feb 2018 at 16:16, Nicolas Goaziou  wrote:

> Hello,
>
> Alex Branham  writes:
>
>> Is there a face that controls agenda items with an upcoming deadline are
>> displayed? It seems to just use "default" for me. I'm talking about
>> items with a deadline within 'org-deadline-warning-days' number of days
>> from now.
>
> See `org-agenda-deadline-faces'

Perfect, thanks!

Alex 

Re: [O] face for upcoming deadlines in agenda

[Nicolas Goaziou]

Hello,

Alex Branham  writes:

> Is there a face that controls agenda items with an upcoming deadline are
> displayed? It seems to just use "default" for me. I'm talking about
> items with a deadline within 'org-deadline-warning-days' number of days
> from now.

See `org-agenda-deadline-faces'

Regards,

-- 
Nicolas Goaziou

[O] Ical to org, in Go lang.

[Robert Horn]

I have been working on converting ICal format files (.ics, .vcs, etc.)
into org content.  This is now ready to share (by adventurous users
only).

What it does now:

It is a command line executable, written in Go.  It takes one or more
arguments that are either local files or URLs to be fetched.  It scans
these for Ical content.  It converts the events found into text in Org
format.  At present it ignores everything else.

 The org content at the moment is of the form

 * Event Summary 
   SCHEDULED: 
   :PROPERTY:
   various extracts from original Ical
   :END:
 ** Description
   extracted description
 ** Location
   extracted location

It uses a modified version of the ics-golang package.  The modifications
are to deal with parsing a wider variety of Ical sources and to capture
more information that I think useful.  Different Ical creators use
different combinations of Ical components, attributes, etc.  When I'm
done I will be asking the maintainer of ics-golang to accept changes.

The output goes to stdout.


My intended uses:

 1.) Downloading and synchronizing with a Google calendar.  So far
 I've verified that it does download from google calendar URLs, and
 converts the ICal formatted content.

 2.) Convert Ical formatted attachments.  I get a lot of these in
 emails.  I'll eventually add something to emacs or mu4e. So far
 I've saved them to files and converted the files.

 3.) Convert big and small files of ICal dumps from various sources.
 For testing I've got a 90,000+ history of events (several years
 worth) that I archived from a previous job.  It shows that at the
 moment on an ordinary PC it converts at about 500 events per
 second.


Current Capabilities:
 1.) It converts my test files into org events properly.  All output is to 
stdout at present.
 2.) It fetches URLs from Google and converts them.
 3.) It reads files and converts them.
 4.) Error handling is poor and rudimentary.
 5.) It only works with explicit command line arguments.  Stdin does not 
work.  No options yet.  No help.  Stdout only.  But it does take multiple 
arguments.
 6.) Mixed URL (http:// only) and file names work.  At the moment fetching 
is done in parallel, but processing the results waits for all fetching to 
complete.  Fetching is done in parallel, but conversion waits until all the 
fetches are complete.

Definite Plans:

 1.) finish development, test files, etc. for a proper release.

 2.) Deal with duplicates somehow.  I want to have a command that I can
 automatically schedule to download and synchronize URLs from Google
 and elsewhere.  I foresee a pair of executable commands, this the
 fetch/convert and another one to merge the results with an existing
 org-mode file, eliminating duplicate events.

 3.) Settle on the most useful org layout.  For example, should
 location be covered in the body or in the headline?  I found that
 some of the locations that I get are multi-line locations.  At the
 moment location is a subordinate headline.  4.) Take suggestions.

 Where it is:

 github repository:  https://github.com/rjhorniii/ical2org-go for 
ical2org-go
 github repository:  https://github.com/rjhorniii/ics-golang for extended 
ics-golang.  This is temporary and just until the changes are stable, submitted 
to the maintainers, and accepted.


A note on time zones:

Org-mode does not use time zone tagged timestamps.  There are a variety
of good reasons for this.  As soon as you deal with significant travel
and teleconferences that originate in various parts of the world you hit
complex edge conditions.  The person involved can establish the right
thing to do fairly easily.  I've found no software calendar that handles
this properly.  For example, if I plan to be in New York on Monday and
Tuesday, Chicago on Wednesday, and Berlin on Thursday and Friday, what
timezone should be attached to which events?  I personally use the rule:
local time there and then.  So I want Monday and Tuesday to be
America/NewYork, Wednesday to be America/Chicago, and Thursday/Friday to
be Europe/Berlin.  Note that I did not use UTC offsets.  I want the
times to be then local time.  I don't want to worry about whether at
that time and location it is summer time or not.  I find org agendas are
most useful this way, even though different days and events are
different time zones.

This program converts everything assuming that the event creator local
time zone is the one that matches my rule of "then/there time".  This is
not always correct.  It is especially a problem for teleconferences
across time zones.  The creator specified time zone(s) for the event and
put in the properties drawer.  This allows a human to know what was
sent.  I then assume that between the description, the zones, and the
times, a person can decide whether and how to adjust the active
timestamps in the 

Re: [O] Hooking document specific src blocks into default actions

[Alex Bennée]

Alex Bennée  writes:

> Hi,
>
> I've been using these for a while but I recently wanted to add a
> function at the head of the ctrl-c-ctrl-c processing:
>
>   (defvar my-org-default-action nil
> "Default action for this document to run on `org-ctrl-c-ctrl-c'.
>   \\
>   This will run via `org-ctrl-c-ctrl-c-hook' and should return a
>   non-nil result if it processed something. As such it can override
>   default `org-mode' behaviour for \\[org-ctrl-c-ctrl-c]. If you
>   want something to run at the end then you need to use
>   `my-org-default-code-block'")
>   (make-variable-buffer-local 'my-org-default-action)
>
>   (defun my-org--do-action (func-or-string)
> "Evaluate a code block or call a function `FUNC-OR-STRING' from org-file."
> (let ((current-point (point)))
>   (cond
>((stringp func-or-string)
> (save-excursion
>   (org-babel-goto-named-src-block func-or-string)
>   (org-babel-when-in-src-block
>(org-babel-eval-wipe-error-buffer)
>(org-babel-execute-src-block current-prefix-arg nil
> '((:called-from . current-point))
> ((functionp func-or-string)
>  (funcall func-or-string))
> (t (error "What to do with: %s" func-or-string)

OK the problem here was org-babel-when-in-src-block wraps the result. So
now I have a simpler:

  (defun my-org--do-action (func-or-string)
"Evaluate a code block or call a function `FUNC-OR-STRING' from org-file."
(let ((action-result))
  (cond
   ((stringp func-or-string)
(save-excursion
  (org-babel-goto-named-src-block func-or-string)
  (when (memq (org-element-type (org-element-context))
  '(inline-src-block src-block))
(org-babel-eval-wipe-error-buffer)
(setq action-result (org-babel-execute-src-block t)
   ((functionp func-or-string)
(setq action-result (funcall func-or-string)))
   (t (error "What to do with: %s" func-or-string)))
  (if action-result
  (message "%s: %s" func-or-string action-result)
nil)))

This works well, so on to the next problem. I have in my org file:

# -*- my-org-default-action: "team-default-action" -*-

with:

#+name: team-default-action
#+begin_src emacs-lisp
  (let ((called-point (car org-mark-ring))
(processed))
(save-excursion
  (message "Checking at: %s" called-point)
  (goto-char called-point)
  (when (org-at-heading-p)
(let ((heading (nth 4 (org-heading-components)))
  (virt-rx (rx "[virt:" (group (one-or-more digit)) "]")))
  (when (string-match virt-rx heading)
(let ((ticket (match-string 1 heading)))
  (message "found: %s with %s" heading ticket)
  (org-sbe "update-ticket"
   (virt-ticket ticket))
  (setq processed (format "Updated ticket: %s/%s" heading 
ticket)))
(unless processed
  (message "No default action"))
processed)
#+end_src

However as this block needs to call the various helper functions I'm
using the org-sbe macro. However I can't work out how to evaluate
"ticket" in a way to keep the macro happy. Obviously it is designed for
use in tables so I'm possibly abusing it beyond what it can do.

Any ideas?

--
Alex Bennée

[O] face for upcoming deadlines in agenda

[Alex Branham]

Is there a face that controls agenda items with an upcoming deadline are
displayed? It seems to just use "default" for me. I'm talking about
items with a deadline within 'org-deadline-warning-days' number of days
from now.

If not, is there any way of getting someone to implement that? I'd do it
myself, but the way Emacs deals with faces is a bit of a mystery to me.

Thanks,
Alex

Emacs  : GNU Emacs 26.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2018-02-10
Package: Org mode version 9.1.7 (release_9.1.7-1-ga01045 @ 
/home/alex/.emacs.d/lib/org/lisp/)

Re: [O] Ridiculously long (2 minutes) startup time for org agenda

[Daniel Clemente]

It can be many things. My emacs was taking 6 minutes to open for some
years, due to many reasons: a slow computer, many org files and very large
(>100 files, >25 Mb in total), lack of optimizations from my side and from
org-mode's side. I got used to it but it's a very bad experience, specially
when it crashes (and I made it crash a lot).
Now org-mode has improved and I disabled the slow parts, and it opens very
fast (<20 seconds). I still open large files.

The problem may not only be in org but in emacs (e.g. vc-mode can be slow),
though from the instrumentation you send, it doesn't seem to be the case
because it doesn't spend time opening the files.

org-agenda-prepare-buffers is the slow function, so it's the one you should
check. Try to use edebug in it (C-u M-C-x) and run it slowly to see in
which section it's the slowest. Then optimize that part. You'll see many
optimization there (ignore properties, etc.). I had to disable many slow
things, like <<>> (when you use a lot, e.g. 1000 per file, it's too
slow and even crashes), I think that these radio targets were the main
reason of the slowness.

Try creating a very large file and then check opening it, to see if it's
also slow.
Try things in a clean emacs (e.g. starting with: emacs -Q), because you may
have some other mode enabled that wants to do lots of things when you open
the files.

You can test many more things. But keep testing, because it's possible to
make it work faster.


On Mon, Feb 19, 2018 at 3:00 AM, JI Xiang  wrote:

> Hello, first time posting on the mailing list. I encountered a problem
> where my agenda view (C-c a a) is taking ridiculously long (nearly 2
> minutes) to be shown the first time. From the second time onwards, the time
> is about 11 seconds, which is still very long by any means.
>
> I wondered whether it has something to do with me having many files in the
> agenda list, so I tried to restrict the list to just one file. But still
> the first call to org-agenda-list took 12 seconds. This shouldn’t be
> normal, right?
>
> The following are shown in the Messages buffer during the call.
>
> Press key for agenda command:
> Restoring clock data
> Loading /home/jx/.emacs.d/.cache/org-clock-save.el (source)...done
> [yas] Prepared just-in-time loading of snippets successfully.
> Importmagic and/or epc not found. importmagic.el will not be working.
> Setting up indent for shell type zsh
> Indentation variables are now local.
> Indentation setup for shell type zsh
> Using vacuous schema
> Shell native completion is disabled, using fallback
>
> I’m not sure why they would be there, especially the “using vacuous
> schema” and “shell native completion” part. Are the messages related to
> some #BEGIN_SRC blocks in the org files? I don’t think I would ever need
> source code blocks when I’m viewing an agenda buffer?
>
> I posted the question on Emacs.SE
> 
> and somebody suggested me use elp-instrument to perform a profiling. The
> results are as follows:
>
>
> Function Name, Call Count, Elapsed Time, Average Time
>
> org-agenda 1   116.6048159   116.6048159
> org-agenda-list 1   116.29427357  116.29427357
> org-agenda-prepare 1   109.15345470  109.15345470
> org-agenda-prepare-buffers 1   108.98258905  108.98258905
> org-agenda-get-day-entries 12887.0089191339  0.0054417074
> org-agenda-get-scheduled 12883.726361062   0.0028931374
> org-agenda-get-deadlines 12882.1579713230  0.0016754435
> org-agenda--timestamp-to-absolute 14544   1.1317418120   7.781...e-05
> org-agenda-get-timestamps 12880.3673404320  0.0002852021
> org-agenda-get-sexps 12880.3438970410  0.0002670008
> org-agenda-get-restriction-and-command 1   0.310503975
> 0.310503975
> org-agenda-get-blocks 12880.3083237900  0.0002393818
> org-agenda-prepare-window 1   0.157091024   0.157091024
> org-agenda-skip 86240.0781296389  9.059...e-06
> org-agenda-files 49  0.026090686   0.0005324629
> org-agenda-finalize 1   0.013325178   0.013325178
> org-agenda-mode 1   0.009848546   0.009848546
> org-agenda-finalize-entries 23  0.006178961   0.0002686504
> org-agenda-today-p 26040.0061717839  2.370...e-06
> org-agenda-skip-eval 16968   0.0052723920  3.107...e-07
> org-agenda-highlight-todo 112 0.0039840550  3.557...e-05
> org-agenda-format-item 112 0.0038309749  3.420...e-05
> org-agenda-new-marker 208 0.0031529359  1.515...e-05
> org-agenda-format-date-aligned 28  0.0007373120  2.633...e-05
> org-agenda-add-time-grid-maybe 28  0.0003810809  1.361...e-05
> org-agenda-fix-displayed-tags 112 0.000342384   3.057e-06
> org-agenda-fontify-priorities 

Re: [O] mailto link for the #+email keyword: Suppressing backslash and braces "escaping" for latex exports

[John Kitchin]

Something besides:

#+BEGIN_EXPORT html
mailto:some...@example.com?Subject=Hello%20again; target="_top">Send 
Mail
#+END_EXPORT

or


@@html:mailto:some...@example.com?Subject=Hello%20again; 
target="_top">Send Mail@@

?
H. Dieter Wilhelm writes:

> John Kitchin  writes:
>
>> I posted this on your stack exchange question:
>>
>> #+latex_class: report
>> #+options: author:nil email:nil
>> #+latex_header: \author{Some user 
>> \thanks{\href{mailto:b...@comp.org}{b...@comp.org}}}
>
> Perfect, thanks a lot John!
>
> Hmm, I'm asking now myself how can I get a mailto link for an html
> export as well? ;-)
>
>Dieter
> [...]
>
> l


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

[O] Hooking document specific src blocks into default actions

[Alex Bennée]

Hi,

I've been using these for a while but I recently wanted to add a
function at the head of the ctrl-c-ctrl-c processing:

  (defvar my-org-default-action nil
"Default action for this document to run on `org-ctrl-c-ctrl-c'.
  \\
  This will run via `org-ctrl-c-ctrl-c-hook' and should return a
  non-nil result if it processed something. As such it can override
  default `org-mode' behaviour for \\[org-ctrl-c-ctrl-c]. If you
  want something to run at the end then you need to use
  `my-org-default-code-block'")
  (make-variable-buffer-local 'my-org-default-action)

  (defun my-org--do-action (func-or-string)
"Evaluate a code block or call a function `FUNC-OR-STRING' from org-file."
(let ((current-point (point)))
  (cond
   ((stringp func-or-string)
(save-excursion
  (org-babel-goto-named-src-block func-or-string)
  (org-babel-when-in-src-block
   (org-babel-eval-wipe-error-buffer)
   (org-babel-execute-src-block current-prefix-arg nil
'((:called-from . current-point))
((functionp func-or-string)
 (funcall func-or-string))
(t (error "What to do with: %s" func-or-string)

  (defun my-org-run-default-action ()
"Execute default action for this org file."
(interactive)
(when my-org-default-action
  (my-org--do-action my-org-default-action)))

  (add-to-list 'org-ctrl-c-ctrl-c-hook
   'my-org-run-default-action)

However I've run into a small problem that when I execute the source
block I end up with 't every time as we successfully executed the block
even if it didn't end up doing anything at the time.

Is there a better way to invoke source blocks from the current
org-document than this? One where the eventual result can be returned
into the calling lisp so org-ctrl-c-ctrl-c-hook can move on if we didn't
do anything?

--
Alex Bennée

Re: [O] org alters output of bash code blocks when run with :session

[Nicolas Goaziou]

Hello,

Tyler Smith  writes:

> I am running a short bash command from an org mode code block, using
> the program `fold` to wrap it at 60 characters. If I run the code
> without a session argument, the results display as expected. However,
> when I set the session argument (which I have to do in the context of
> the long literate analysis I'm doing), some of the output characters
> don't appear.
>
> Steps to reproduce:
>
> emacs -Q
>
> Open the following file and execute each code block in turn:
>
> +
>
> #+BEGIN_SRC elisp setup
> (org-babel-do-load-languages
>  'org-babel-load-languages
>  '((shell . t)))
> #+END_SRC
>
> 
> #+RESULTS:
> 
>
> #+BEGIN_SRC bash no session :results replace verbatim
>  echo 
> '8,,CEFGDF,,,CC,CF:,,C8CFGFCF@G+FF:B3CDFGGGFGGCFDGGGFCF:,FF9>FEC,FFDGGDGFDFFEEFGEGC5>5?C*CGGF+3:*<7*2>+*<9CGCD::C=*@DCFCFFGG  | fold -w 60
> #+END_SRC
>
> 
> #+RESULTS:
> : 8,,CEFGDF,,,CC,CF:,,C8CFGFGG
> : GGCF@G+FF:B3CDFGGGFGGCFD
> : GGGFCF:,FF9>FEC,FFDGGDGFDFFEEFGE
> : GC5>5?C*CGGF+3:*<7*2>+*<9CGCD::C=*@DCFCFFGG 
>
> #+BEGIN_SRC bash session :results replace verbatim :session my-session
>  echo 
> '8,,CEFGDF,,,CC,CF:,,C8CFGFCF@G+FF:B3CDFGGGFGGCFDGGGFCF:,FF9>FEC,FFDGGDGFDFFEEFGEGC5>5?C*CGGF+3:*<7*2>+*<9CGCD::C=*@DCFCFFGG  | fold -w 60
> #+END_SRC
>
> 
> #+RESULTS:
> : 8,,CEFGDF,,,CC,CF:,,C8CFGFGG
> : GGCF@G+FF:B3CDFGGGFGGCFD
> : FEC,FFDGGDGFDFFEEFGE
> : 5?C*CGGF+3:*<7*2>+*<9CGCD::C=*@DCFCFFGG +
>
> Notice the difference between the two bash results blocks. In the
> first, the input string is folded at column 60, without any other
> changes. In the second, a string of characters has been deleted:
>
> - `GGGFCF:,FF9>` from the beginning of the third line 
> - `GC5>` from the beginning of the fourth line
>
> The fact that the deleted strings both start at the beginning of
> a line and end with a `>` suggests that the session thinks they should
> be redirected somehow, and in the process is dropping them completely.
> However, when I look at the session buffer, the output appears as
> expected, with no missing characters.
>
> How do I force the babel session to leave the output alone, and print
> it verbatim into the org file?

It may be related to other problems related to prompt in shell sessions.
See for example
,
, and for
step forward a solution
.

Patches welcome!

Regards,

-- 
Nicolas Goaziou

Re: [O] src-blocks with captions do not respect attr_latex :placement options

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> org-latex-default-figure-position is defined as "htbp"
>
> where as :placement is usually defined as "[H]". One has brackets, and
> one doesn't. This is reflected in ox-latex too.
>
> For example in this code (line 3219. ox-latex.el)
>
> (or (plist-get attr :placement)
> (format "[%s]" (plist-get info
> :latex-default-figure-position)))
>
> it is implied that :latex-default-figure-position does not have
> brackets, but that (plist-get attr :placement) does since it is later
> used in line 3259 as:
>
> (format "\\begin{%s}%s\n" float-env placement)
>
> So, it seems like one either has to add [] to the default
> org-latex-default-figure-position, or put them in the template, or
> change how the :placement value is used. It doesn't seem like we can
> have it both ways without testing if there are brackets or not. It also
> doesn't seem right to modify org-latex-default-figure-position just to
> get float listings to be "[H]" for src blocks.

OK. Note that Org provides `org-unbracket-string'.

Regards,

-- 
Nicolas Goaziou

Re: [O] question on org-element-interpret-data and when it works

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> I am trying to find some ways to programatically modify org-elements that
> use fewer regexps and motion commands. It seems like org-dp (
> https://github.com/tj64/org-dp) was intended to do that but it is not clear
> enough how you might use it, and it also doesn't seem to support
> plain-lists yet.

[...]

> It works on some things, e.g. headlines, src blocks. I put the point on one
> of those things, run this command, and then I can paste it somewhere to see
> that it did indeed work.
>
> But, it does not work on plain-lists, or paragraphs. I either get an empty
> string, or Wrong type argument: char-or-string-p, nil
>
> Is it possible to do what I am describing? Am I just missing how to get the
> element data in the right form?

You cannot change a non-terminal element without changing its contents.
In particular plain-lists, tables and paragraphs are fully defined by
their contents, i.e., they do not decorate contents like headlines. In
this case, data returned by `org-element-context' is incomplete in this
case. You probably need to parse the buffer between :begin and :end and
modify structure recursively.

Regards,

-- 
Nicolas Goaziou

Re: [O] Expose value-begin and value-end instead of just value in org-element API

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> Wow. I would not have guessed either one of these! Thanks for sharing
> them. Is that documented somewhere? 

[...]

> For elements with a :contents-begin where does :post-affiliated come in?

See 

> Once you get the idea, maybe, but this approach seems specific to
> src-blocks (maybe any block) where there are delimiting lines. It
> doesn't work on all elements (which to be fair was not claimed). I think
> the OP was interested in something more consistent, which I am
> sympathetic to.

Some elements are very different from others. What would be the innards
of an horizontal line or a planning line?

> Some things aren't clear to me what should happen though, especially in
> composite elements like tables and plain lists. E.g. To just select a
> table without the affiliated lines, one can use :contents-begin and
> :contents-end, once you get the table element (e.g. by walking up the
> :parent chain if you are in a cell or row).
>
> In the absence of a single way, maybe there could be a small number of
> ways to do this? How many cases do you think there are?
>
> - blocks (which have :value)
> - composite elements (which have :contents-begin/end and/or non-nil :parents)
> - regular elements (which have :contents-begin/end)

There is no difference between regular elements and composite elements.
Also, all blocks do not have a value (e.g., center blocks).

> I can see this argument, but I am still unclear on which elements need a
> value, and which don't. For example, src-blocks have a value, but a
> paragraph doesn't, nor do items in a plain list, at least from
> (org-element-context).

In a parse tree, some elements are terminal (i.e., leaves), others are
not. Non-terminal elements have :contents-begin and :contents-end
properties. Others have :value, if it makes sense, or nothing (e.g.,
planning lines).

Source blocks are terminal elements. Paragraphs, lists and items are
not.

Regards,

-- 
Nicolas Goaziou