Re: org 9.2.6 and org 9.1.9

[Fraga, Eric]

On Wednesday, 27 Nov 2019 at 17:00, Tim Cross wrote:
> I would agree that org should be a package in elpa and not bundled into
> emacs core. 

I would argue the opposite!  I would like to see org tightly integrated
into Emacs, in the same way that gnus now is.  Development of org would
be in step with the development of Emacs.  This would avoid any
dependency issues entirely.

But I have no problem with the current situation even if I have had to
be very careful in how I load org in my initialisation files...

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78

Re: org 9.2.6 and org 9.1.9

[Stefan Kangas]

Jean-Christophe Helary  writes:

> > Yes, it is a bit of dependency hell.
>
> I see 2 solutions here:
>
> 1) org is only provided as a built-in package and updated there when necessary

Even if we removed it from GNU ELPA, nothing stops unofficial packages
from cropping up when users want to run the latest and greatest.
Users of such packages would then report bugs when things broke, and
we would be back where we started.

(BTW, there already is a separate package archive on https://orgmode.org/elpa/.)

> 2) org is removed from the built in packages

Option 2 would be extremely unfortunate, to put it mildly.  It would
leave a lot of users without functionality they've come to expect and
depend on to be there in the default install.  GNU ELPA is not always
a practical alternative (just to give one example, on servers or
networks not connected to the internet).

And even if we remove org-mode, who is to say that other packages
won't see the same issues in the future?  Should we just accept that
we have to remove any package from Emacs which runs into this?

IMO, let's work on fixing the underlying problems instead.  Elsewhere
in this thread, Stefan Monnier and others has pointed out what needs
to be done: now we need to figure out how to do it.

Best regards,
Stefan Kangas

Re: org 9.2.6 and org 9.1.9

[Stefan Kangas]

Stefan Monnier  writes:
>
> > What should happen is that
> > 1) packages.el should see that I'm trying to install a package that requires
> > 9.2.6 as a dependency and it should notify me that 9.1.9 is already
> > installed and do I really want to do that, etc.
> >
> > 2) *or* just consider that it's better for me to use 9.2.6 instead of
> > whatever comes with emacs and make sure that the older package is forgotten
> > by emacs.
>
> I think 2 is the right option.  package.el was designed such that you
> can have various versions of a given package installed.  Only one of the
> can be activated at any given time, because Emacs Lisp doesn't provide any
> way to do better, but having both Org-9.1.9 and Org-9.2.6 installed
> should be a perfectly normal situation.
>
> Any misbehavior that results from this should be reported as a bug
> (especially if it can be reproduced).

I fully agree.  If package.el has a bug, we should fix it.

See also the previous discussion here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125

Best regards,
Stefan Kangas

Re: org 9.2.6 and org 9.1.9

[Stefan Kangas]

Tim Cross  writes:

> I would agree that org should be a package in elpa and not bundled into emacs 
> core. The user can then choose which version to install (ignoring the package 
> dependency problem).

I disagree with removing Org-mode from Emacs core, as I've explained elsewhere.

> This won't fix all the issues as anyone installing a new major version when 
> an existing version is already loaded will run into the same problems. Bottom 
> line, as org stands now, upgrading when org is already loaded is problematic.

It would be very unfortunate if we removed Org-mode from Emacs core
with the sole motivation to band-aid an issue with upgrading packages
in package.el.

So I would put your above argument more bluntly: removing Org-mode
from Emacs core would be to sweep the problem under the rug.
package.el is still broken.

Best regards,
Stefan Kangas

Re: org 9.2.6 and org 9.1.9

[Tim Cross]

But I don't think the issue is with package.el per se. You get the same
problem if you try to install org-mode manually without package.el. What is
really needed to fix this problem is some mechanism which will ensure all
org related definitions are somehow purged from the running instance before
attempting to install and compile a new version.  Provided there is no
org-mode functionality loaded when you install a later version with
package.el, it works fine.

On Wed, 27 Nov 2019 at 17:29, Stefan Kangas  wrote:

> Tim Cross  writes:
>
> > I would agree that org should be a package in elpa and not bundled into
> emacs core. The user can then choose which version to install (ignoring the
> package dependency problem).
>
> I disagree with removing Org-mode from Emacs core, as I've explained
> elsewhere.
>
> > This won't fix all the issues as anyone installing a new major version
> when an existing version is already loaded will run into the same problems.
> Bottom line, as org stands now, upgrading when org is already loaded is
> problematic.
>
> It would be very unfortunate if we removed Org-mode from Emacs core
> with the sole motivation to band-aid an issue with upgrading packages
> in package.el.
>
> So I would put your above argument more bluntly: removing Org-mode
> from Emacs core would be to sweep the problem under the rug.
> package.el is still broken.
>
> Best regards,
> Stefan Kangas
>


-- 
regards,

Tim

--
Tim Cross

Re: org 9.2.6 and org 9.1.9

[Tim Cross]

I would agree that org should be a package in elpa and not bundled into
emacs core. The user can then choose which version to install (ignoring the
package dependency problem). This won't fix all the issues as anyone
installing a new major version when an existing version is already loaded
will run into the same problems. Bottom line, as org stands now, upgrading
when org is already loaded is problematic.

On Wed, 27 Nov 2019 at 16:44, Jean-Christophe Helary <
jean.christophe.hel...@traduction-libre.org> wrote:

> Thank you Stefan. I'll try to reproduce the issue and then I'll report.
>
> Jean-Christophe
>
> > On Nov 27, 2019, at 12:24, Stefan Monnier 
> wrote:
> >
> >> What should happen is that
> >> 1) packages.el should see that I'm trying to install a package that
> requires
> >> 9.2.6 as a dependency and it should notify me that 9.1.9 is already
> >> installed and do I really want to do that, etc.
> >>
> >> 2) *or* just consider that it's better for me to use 9.2.6 instead of
> >> whatever comes with emacs and make sure that the older package is
> forgotten
> >> by emacs.
> >
> > I think 2 is the right option.  package.el was designed such that you
> > can have various versions of a given package installed.  Only one of the
> > can be activated at any given time, because Emacs Lisp doesn't provide
> any
> > way to do better, but having both Org-9.1.9 and Org-9.2.6 installed
> > should be a perfectly normal situation.
> >
> > Any misbehavior that results from this should be reported as a bug
> > (especially if it can be reproduced).
> >
> >
> >Stefan
>
>

-- 
regards,

Tim

--
Tim Cross

Re: org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

Thank you Stefan. I'll try to reproduce the issue and then I'll report.

Jean-Christophe

> On Nov 27, 2019, at 12:24, Stefan Monnier  wrote:
> 
>> What should happen is that
>> 1) packages.el should see that I'm trying to install a package that requires
>> 9.2.6 as a dependency and it should notify me that 9.1.9 is already
>> installed and do I really want to do that, etc.
>> 
>> 2) *or* just consider that it's better for me to use 9.2.6 instead of
>> whatever comes with emacs and make sure that the older package is forgotten
>> by emacs.
> 
> I think 2 is the right option.  package.el was designed such that you
> can have various versions of a given package installed.  Only one of the
> can be activated at any given time, because Emacs Lisp doesn't provide any
> way to do better, but having both Org-9.1.9 and Org-9.2.6 installed
> should be a perfectly normal situation.
> 
> Any misbehavior that results from this should be reported as a bug
> (especially if it can be reproduced).
> 
> 
>Stefan

Re: org 9.2.6 and org 9.1.9

[Stefan Monnier]

> What should happen is that
> 1) packages.el should see that I'm trying to install a package that requires
> 9.2.6 as a dependency and it should notify me that 9.1.9 is already
> installed and do I really want to do that, etc.
>
> 2) *or* just consider that it's better for me to use 9.2.6 instead of
> whatever comes with emacs and make sure that the older package is forgotten
> by emacs.

I think 2 is the right option.  package.el was designed such that you
can have various versions of a given package installed.  Only one of the
can be activated at any given time, because Emacs Lisp doesn't provide any
way to do better, but having both Org-9.1.9 and Org-9.2.6 installed
should be a perfectly normal situation.

Any misbehavior that results from this should be reported as a bug
(especially if it can be reproduced).


Stefan

Re: org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

> On Nov 27, 2019, at 11:59, Cook, Malcolm  wrote:
> 
> Tim,
>  
> Yes, it is a bit of dependency hell.

I see 2 solutions here:

1) org is only provided as a built-in package and updated there when necessary
2) org is removed from the built in packages

The current situation is really weird.

Jean-Christophe

>  
> Quoting myself from Re: [O] How to safely update from ver. 8.2.10 to 8.3.x :
>  
>  
> Here's what I do, at the shell:
>  
>   emacs -Q -batch -eval "(progn (require 'package) (add-to-list 
> 'package-archives '(\"org\" . \"http://orgmode.org/elpa/\;;))  
> (package-initialize) (package-refresh-contents) (package-install 
> 'org-plus-contrib))"
>  
> This assures that org is not already loaded when org is compiled, which I've 
> learned is the source of creating a mess.
>  
> Note: I use org-plus-contrib from melpa instead of org.  If you want just 
> org, 
> you could simply:
>  
>   emacs -Q -batch -eval "(progn (require 'package) 
> (package-initialize) 
> (package-refresh-contents) (package-install 'org-plus-contrib))"
>  
> HTH,
>  
> Malcolm
>  
>  
>  
> From: Emacs-orgmode  On Behalf 
> Of Tim Cross
> Sent: Tuesday, November 26, 2019 3:41 PM
> To: Nick Dokos 
> Cc: Org-mode ; Emacs developers 
> Subject: Re: org 9.2.6 and org 9.1.9
>  
> CAUTION: This email was received from an External Source
>  
> 
> There is a very important rule which must be followed wrt org-mode 
> installation. It is critical that no version of org is already loaded before 
> installing a new version. This can be quite tricky as many of us have org 
> setups which automatically load some org functionality without explicitly 
> opening an org file or agenda view (for example, you might be using an org 
> add-on for email). Situation is worse if we are loading org as part of our 
> init.el.
>  
> I'm also not sure that tweaking the load-path order is sufficient if your 
> installing org via M-x package-install as there is a 'chicken and egg' 
> problem with the initial install. If your init.el file is loading org 
> functionality and you only have the built-in org version installed, that 
> version will be loaded before you run package-install. Probably works if you 
> install via your init.el though.
>  
> I've found the safest thing to do is only use autoload or use-package with 
> deferred loading for org and whenever updating org (I use the 
> org-plus-contrib package from the org elpa repo) only update immediately 
> after a fresh restart of emacs and before doing anything else.  Failing to do 
> this often results in a broken build as you get a set of new org elc files 
> which contains definitions from two different org versions. When the versions 
> are only different in minor version numbers, this mixed build may not even be 
> noticeable, but when major version differences exist, you get the symptom of 
> broken functionality, missing definitions or unbound symbols.
>  
> The situation is made worse by package maintainers specifying the latest org 
> version rather than the version built into Emacs when the bundled version 
> would be sufficient.
>  
> It took me a while to structure my init.el file such that no org 
> functionality was loaded until I used something which depends on it. However, 
> once I did, provided I only update org in a fresh new session, all works 
> flawlessly. I found use-package package really helped with this. 
>  
>  
>  
> On Wed, 27 Nov 2019 at 06:22, Nick Dokos  wrote:
> Jean-Christophe Helary  writes:
> 
> > org 9.1.9 is a built-in
> >
> > but org 9.2.6 comes as a dependency to some packages and having both 
> > installed creates conflicts.
> >
> 
> What conflicts are you seeing? I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems: the only thing I do is to set my load-path to point to the
> right place (and make sure that that setting precedes the
> /usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):
> 
> (add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))
> 
> Although that has been enough for me, it's probably safer to delete
> from load-path all other org entries, thereby making the built-in
> version invisible to emacs - in my case, I just have the one:
> 
>(delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)
> 
> That way, if you happen to do something like `(require 'old-org-req)'
> with a requirement that is not satisfied by current org, but is
> satisfied by the built-in org, you'd get an error, rather than getting
> a mixed installation.
> 
> > Why does that happen ?
> >
> > Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues
> > with that situation and that's extremely confusing. What is the best
> > way to solve that ?
> >
> 
> I think the above should be enough (and IME it is), but maybe someone can
> think of other things that might trip one up.
> 
> -- 
> Nick
> 
> "There are only two hard problems in computer science: 

RE: org 9.2.6 and org 9.1.9

[Cook, Malcolm]

Tim,



Yes, it is a bit of dependency hell.



Quoting myself from Re: [O] How to safely update from ver. 8.2.10 to 
8.3.x
 :





Here's what I do, at the shell:



  emacs -Q -batch -eval "(progn (require 'package) (add-to-list

'package-archives '(\"org\" . 
\"http://orgmode.org/elpa/\;;))

(package-initialize) (package-refresh-contents) (package-install

'org-plus-contrib))"



This assures that org is not already loaded when org is compiled, which I've

learned is the source of creating a mess.



Note: I use org-plus-contrib from melpa instead of org.  If you want just org,

you could simply:



  emacs -Q -batch -eval "(progn (require 'package) (package-initialize)

(package-refresh-contents) (package-install 'org-plus-contrib))"



HTH,



Malcolm



From: Emacs-orgmode  On Behalf 
Of Tim Cross
Sent: Tuesday, November 26, 2019 3:41 PM
To: Nick Dokos 
Cc: Org-mode ; Emacs developers 
Subject: Re: org 9.2.6 and org 9.1.9

CAUTION: This email was received from an External Source

There is a very important rule which must be followed wrt org-mode 
installation. It is critical that no version of org is already loaded before 
installing a new version. This can be quite tricky as many of us have org 
setups which automatically load some org functionality without explicitly 
opening an org file or agenda view (for example, you might be using an org 
add-on for email). Situation is worse if we are loading org as part of our 
init.el.

I'm also not sure that tweaking the load-path order is sufficient if your 
installing org via M-x package-install as there is a 'chicken and egg' problem 
with the initial install. If your init.el file is loading org functionality and 
you only have the built-in org version installed, that version will be loaded 
before you run package-install. Probably works if you install via your init.el 
though.

I've found the safest thing to do is only use autoload or use-package with 
deferred loading for org and whenever updating org (I use the org-plus-contrib 
package from the org elpa repo) only update immediately after a fresh restart 
of emacs and before doing anything else.  Failing to do this often results in a 
broken build as you get a set of new org elc files which contains definitions 
from two different org versions. When the versions are only different in minor 
version numbers, this mixed build may not even be noticeable, but when major 
version differences exist, you get the symptom of broken functionality, missing 
definitions or unbound symbols.

The situation is made worse by package maintainers specifying the latest org 
version rather than the version built into Emacs when the bundled version would 
be sufficient.

It took me a while to structure my init.el file such that no org functionality 
was loaded until I used something which depends on it. However, once I did, 
provided I only update org in a fresh new session, all works flawlessly. I 
found use-package package really helped with this.



On Wed, 27 Nov 2019 at 06:22, Nick Dokos 
mailto:ndo...@gmail.com>> wrote:
Jean-Christophe Helary 
mailto:jean.christophe.hel...@traduction-libre.org>>
 writes:

> org 9.1.9 is a built-in
>
> but org 9.2.6 comes as a dependency to some packages and having both 
> installed creates conflicts.
>

What conflicts are you seeing? I have the built-in 9.1.9 org that
comes with emacs but I run (close to) latest master and I see no
problems: the only thing I do is to set my load-path to point to the
right place (and make sure that that setting precedes the
/usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):

(add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))

Although that has been enough for me, it's probably safer to delete
from load-path all other org entries, thereby making the built-in
version invisible to emacs - in my case, I just have the one:

   (delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)

That way, if you happen to do something like `(require 'old-org-req)'
with a requirement that is not satisfied by current org, but is
satisfied by the built-in org, you'd get an error, rather than getting
a mixed installation.

> Why does that happen ?
>
> Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues
> with that situation and that's extremely confusing. What is the best
> way to solve that ?
>

I think the above should be enough (and IME it is), but maybe someone can
think of other things that might trip one up.

--
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler



--
regards,

Tim

--
Tim Cross

Re: Editting from the agenda view

[Sebastian Miele]

Hi Shérab,

Shérab  writes:

> Dear Victor,
>
> Many thanks for your response and sorry for the delay of mine!
>
> Victor A. Stoichita (2019/11/23 09:14 +0100):
>>
>> Le 22 Nov 2019, Shérab  a écrit :
>> > When I am in an agenda view, say the weekly view, how can I edit one of
>> > the listed entries? I may want to do that either because I notice I have
>> > made a typo that I would like to fix, or because I would like to
>> > re-schedule the entry for another date.
>>
>> To reschedule an entry remotely from the agenda view, you can press S-right
>> (org-agenda-do-date-later) or S-left (org-agenda-do-date-earlier).
>
> I indeed remember having seen these commands!
> The thing is that I am using emacs in the Linux console where these
> bindings do not work, so I couldn't try them. Is there a way to bind
> them to different key bindings? I am asking becuase I assume the
> bindings you mention are specific to the agenda view and the way to
> modify them is thus different from ordinary, global bindings. Am I
> correct?

After opening the agenda, inspection of the buffer-local variable
major-mode (e.g. by C-h v) reveals that the major mode in the agenda
buffer is org-agenda-mode. A search for a variable containing
"org-agenda", and "map" reveals that most probably org-agenda-mode-map
is the keymap used there. It follows the usual naming scheme for major
mode maps.

After (require 'org-agenda) it will be possible to (define-key
org-agenda-mode-map KEY BINDING) in an init file.

Best wishes
Sebastian

Re: [PATCH] Add support for month trees

[Jason Dunsmore]

Hi Nicolas,

I've addressed each of your points in my updated patch (attached).

Thanks,
Jason

On Tue, Nov 26, 2019 at 3:22 AM Nicolas Goaziou 
wrote:

> Hello,
>
> Jason  writes:
>
> > Please find my attached patch which implements a way to capture entries
> > grouped by month.
>
> Thank you.
>
> > I was searching for this option, but only found a way to group entries by
> > week or day.
> >
> > I found the following posts where other people also need this feature:
> > https://emacs.stackexchange.com/questions/48414/monthly-date-tree
> > https://lists.gnu.org/archive/html/emacs-orgmode/2018-02/msg00092.html
>
> I think this can be tested in "next" branch. Could you rebase your patch
> against it?
>
> > * etc/ORG-NEWS: Document new `:tree-type month' option.
>
> No need to provide this information in the commit message, IMO. Of
> course, it doesn't hurt in any case. Just sayin'.
>
> > +Use ~week~ to make a week tree instead of the month-day tree,
> > +i.e., place the headings for each day under a heading with the
> > +current ISO week. Use @code{month} to group entries by month
> > +only. Default is to group entries by day.
>
> You need to put two spaces after full stops.
>
> > + (cond
> > +  ((eq (org-capture-get :tree-type) 'week)
> > +   #'org-datetree-find-iso-week-create)
> > +  ((eq (org-capture-get :tree-type) 'month)
> > +   #'org-datetree-find-month-create)
> > +  (t
> > +   #'org-datetree-find-date-create))
>
> Could you refactor that with `case' instead? I.e.,
>
> (case (org-capture-get :tree-type)
>  (`week ...)
>  ...)
> > +  (if (eq time-grouping 'day)
> > +   (org-datetree--find-create
> > +"^\\*+[ \t]+%d-%02d-\\([0123][0-9]\\) \\w+$"
> > +year month day)
>
> Please use `when' (or `unless') instead of one-armed `if'.
>
> Could you send an updated patch?
>
> Regards,
>
> --
> Nicolas Goaziou
>
From b432ba4edb1fccf53a1a6f187e710b825b054673 Mon Sep 17 00:00:00 2001
From: Jason Dunsmore 
Date: Wed, 6 Nov 2019 21:49:43 -0600
Subject: [PATCH] org-capture.el: Add support for month trees

* doc/org-manual.org: Add `:tree-type month' option for capture
  templates.
* lisp/org-capture.el (org-capture-set-target-location): Add
  `:tree-type month' option to capture templates to group entries by
  month.
* lisp/org-datetree.el (org-datetree-find-month-create): Add
  `org-datetree-find-month-create' function to add datetree entries
  grouped by month.
* testing/lisp/test-org-datetree.el
  (test-org-datetree/find-month-create): Add test for new function.
---
 doc/org-manual.org|  7 ---
 etc/ORG-NEWS  |  5 -
 lisp/org-capture.el   |  7 ---
 lisp/org-datetree.el  | 27 +++
 testing/lisp/test-org-datetree.el | 11 +++
 5 files changed, 46 insertions(+), 11 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ee7092d14..8c310a0f9 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -7599,9 +7599,10 @@ Now lets look at the elements of a template definition.  Each entry in
 
   - ~:tree-type~ ::
 
-When ~week~, make a week tree instead of the month tree, i.e.,
-place the headings for each day under a heading with the current
-ISO week.
+Use ~week~ to make a week tree instead of the month-day tree,
+i.e., place the headings for each day under a heading with the
+current ISO week.  Use @code{month} to group entries by month
+only.  Default is to group entries by day.
 
   - ~:unnarrowed~ ::
 
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 689a07871..0b97948e6 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -345,7 +345,9 @@ the headline to use for making the table of contents.
 ,* Another section
 ,#+TOC: headlines 1 :target "#TargetSection"
 #+end_example
-
+*** New option to group captured datetime entries by month
+A new `:tree-type month' option was added to org-capture-templates to
+group new datetime entries by month.
 ** New functions
 *** ~org-dynamic-block-insert-dblock~
 
@@ -358,6 +360,7 @@ dynamic block in ~org-dynamic-block-alist~.
 *** ~org-table-cell-left~
 *** ~org-table-cell-right~
 *** ~org-habit-toggle-display-in-agenda~
+*** ~org-datetree-find-month-create~
 ** Removed functions and variables
 *** Removed Org Drill
 
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 67343e02a..39121d1fb 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -998,9 +998,10 @@ Store them in the capture property list."
 	   ;; Make a date/week tree entry, with the current date (or
 	   ;; yesterday, if we are extending dates for a couple of hours)
 	   (funcall
-	(if (eq (org-capture-get :tree-type) 'week)
-		#'org-datetree-find-iso-week-create
-	  #'org-datetree-find-date-create)
+	(pcase (org-capture-get :tree-type)
+	  ('week #'org-datetree-find-iso-week-create)
+	  ('month #'org-datetree-find-month-create)

Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

[Sean Whitton]

Hello David,

Thank you for the investigation.

On Tue 26 Nov 2019 at 10:52PM +00, David Edmondson wrote:

> The poor behaviour is just a side effect of the way that queries are
> composed to implement the filter functionality. Does the attached patch
> help?

Unfortunately, it is still broken in my test case.

>> Further, my package 'mailscripts' tries to pass the current value of
>> `notmuch-show-thread-id' to notmuch-extract-patch(1).
>>
>> https://git.spwhitton.name/mailscripts/tree/mailscripts.el#n72
>>
>> https://manpages.debian.org/notmuch-extract-patch
>>
>> If `notmuch-show-thread-id' contains a query which returns a single
>> message, the wrong value is passed to notmuch-extract-patch(1), such
>> that it may not extract all of the patches in the thread.
>
> It's not clear to me that this is broken.
>
> notmuch-extract-patch seems to be properly extracting patches from the
> messages that match the query.
>
> If the current `notmuch-show' buffer query doesn't match the entire
> thread, why should `notmuch-extract-thread-patches' be expected to apply
> patches from the whole thread?

The purpose of `notmuch-extract-thread-patches' is to extract a whole
git-send-email(1) patch series at a time, because that is usually what
one wants to do.  There are `notmuch-extract-message-patches' and
`notmuch-show-pipe-message' for single patches.

(I note that this is a mailscripts design question, not strictly
relevant to the issue of ol-notmuch.el causing the
notmuch-show-thread-id variable to be mispopulated.  Thank you for your
engagement with mailscripts, regardless!)

-- 
Sean Whitton

Re: org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

Nick, thank you for your reply.

> On Nov 27, 2019, at 4:15, Nick Dokos  wrote:
> 
> Jean-Christophe Helary  writes:
> 
>> org 9.1.9 is a built-in
>> 
>> but org 9.2.6 comes as a dependency to some packages and having both 
>> installed creates conflicts.
>> 
> 
> What conflicts are you seeing?

At one point I was unable to archive subtrees because some function was 
undefined.
I uninstalled 9.2.6 and the issues was fixed.

> I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems:

Obviously you are not the typical user... :)

What should happen is that
1) packages.el should see that I'm trying to install a package that requires 
9.2.6 as a dependency and it should notify me that 9.1.9 is already installed 
and do I really want to do that, etc.

2) *or* just consider that it's better for me to use 9.2.6 instead of whatever 
comes with emacs and make sure that the older package is forgotten by emacs.

But honestly, I think 1) should be the default for any package.


Jean-Christophe Helary
---
http://mac4translators.blogspot.com @brandelune

Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

[David Edmondson]

On Tuesday, 2019-11-26 at 14:57:28 -07, Sean Whitton wrote:

> On Tue 26 Nov 2019 at 08:05PM +00, David Edmondson wrote:
>
>> Could you explain how you were using `notmuch-show-thread-id' in a way
>> that was broken by the presence of an arbitrary query?
>
> I've observed that the standard notmuch command
> `notmuch-show-filter-thread' doesn't work in a buffer opened by
> `org-notmuch-follow-link'.

The poor behaviour is just a side effect of the way that queries are
composed to implement the filter functionality. Does the attached patch
help?

> Further, my package 'mailscripts' tries to pass the current value of
> `notmuch-show-thread-id' to notmuch-extract-patch(1).
>
> https://git.spwhitton.name/mailscripts/tree/mailscripts.el#n72
>
> https://manpages.debian.org/notmuch-extract-patch
>
> If `notmuch-show-thread-id' contains a query which returns a single
> message, the wrong value is passed to notmuch-extract-patch(1), such
> that it may not extract all of the patches in the thread.

It's not clear to me that this is broken.

notmuch-extract-patch seems to be properly extracting patches from the
messages that match the query.

If the current `notmuch-show' buffer query doesn't match the entire
thread, why should `notmuch-extract-thread-patches' be expected to apply
patches from the whole thread?

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index e13ca3d7..ecbc03d2 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1311,7 +1311,7 @@ and THREAD.  The next query is THREAD alone, and serves as a
 fallback if the prior matches no messages."
   (let (queries)
 (push (list thread) queries)
-(if context (push (list thread "and (" context ")") queries))
+(if context (push (list "(" thread ") and (" context ")") queries))
 queries))
 
 (defun notmuch-show--build-buffer ( state)

dme.
-- 
I can't explain, you would not understand. This is not how I am.

Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

[Sean Whitton]

Hello David,

On Tue 26 Nov 2019 at 08:05PM +00, David Edmondson wrote:

> Could you explain how you were using `notmuch-show-thread-id' in a way
> that was broken by the presence of an arbitrary query?

I've observed that the standard notmuch command
`notmuch-show-filter-thread' doesn't work in a buffer opened by
`org-notmuch-follow-link'.

Further, my package 'mailscripts' tries to pass the current value of
`notmuch-show-thread-id' to notmuch-extract-patch(1).

https://git.spwhitton.name/mailscripts/tree/mailscripts.el#n72

https://manpages.debian.org/notmuch-extract-patch

If `notmuch-show-thread-id' contains a query which returns a single
message, the wrong value is passed to notmuch-extract-patch(1), such
that it may not extract all of the patches in the thread.

-- 
Sean Whitton

Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

[Sean Whitton]

Hello,

On Tue 26 Nov 2019 at 08:17PM +01, ra...@free.fr wrote:

> Your approach probably works most of the time, but I don't like the idea
> of having to perform 2 queries when one should be enough.
>
> I think a better approach would be to change notmuch-show (or add a
> new version) that would allow taking arbitrary queries (and
> especially, message ids) as input. This probably used to be the case.
>
> Note that the command line notmuch show function does accept arbitrary
> search terms as an argument
>
> I think updating notmuch-show to compute the thread id from the query
> (instead of assuming that the input is a thread id) would be the best
> way to go, but you should see that with the notmuch developers.

I agree with you that it would be best if `notmuch-show' were extended
to accept arbitrary notmuch queries instead of only thread IDs.

However, I also believe that ol-notmuch.el should be updated in the
meantime.  notmuch.el presently exposes an API, `notmuch-show', which
takes a thread ID.  ol-notmuch.el is misusing that API by passing in a
value of a different type -- a notmuch query rather than a thread ID.

That's a bug: even if an API is more limited than we would like it to
be, we should use it in the way that it is documented to be used by its
developers.

This misuse of the API causes numerous other hard-to-diagnose bugs.  For
example, if you use `org-notmuch-follow-link' to open an Org-mode link
like "notmuch:id:f...@bar.baz", the standard notmuch command
`notmuch-show-filter-thread' doesn't work.  And if you use `C-u c i` to
yank the thread ID for pasting into a shell, say, you will yank a value
which is not a thread ID.

-- 
Sean Whitton

Re: org 9.2.6 and org 9.1.9

[Tim Cross]

There is a very important rule which must be followed wrt org-mode
installation. It is critical that no version of org is already loaded
before installing a new version. This can be quite tricky as many of us
have org setups which automatically load some org functionality without
explicitly opening an org file or agenda view (for example, you might be
using an org add-on for email). Situation is worse if we are loading org as
part of our init.el.

I'm also not sure that tweaking the load-path order is sufficient if your
installing org via M-x package-install as there is a 'chicken and egg'
problem with the initial install. If your init.el file is loading org
functionality and you only have the built-in org version installed, that
version will be loaded before you run package-install. Probably works if
you install via your init.el though.

I've found the safest thing to do is only use autoload or use-package with
deferred loading for org and whenever updating org (I use the
org-plus-contrib package from the org elpa repo) only update immediately
after a fresh restart of emacs and before doing anything else.  Failing to
do this often results in a broken build as you get a set of new org elc
files which contains definitions from two different org versions. When the
versions are only different in minor version numbers, this mixed build may
not even be noticeable, but when major version differences exist, you get
the symptom of broken functionality, missing definitions or unbound symbols.

The situation is made worse by package maintainers specifying the latest
org version rather than the version built into Emacs when the bundled
version would be sufficient.

It took me a while to structure my init.el file such that no org
functionality was loaded until I used something which depends on it.
However, once I did, provided I only update org in a fresh new session, all
works flawlessly. I found use-package package really helped with this.



On Wed, 27 Nov 2019 at 06:22, Nick Dokos  wrote:

> Jean-Christophe Helary 
> writes:
>
> > org 9.1.9 is a built-in
> >
> > but org 9.2.6 comes as a dependency to some packages and having both
> installed creates conflicts.
> >
>
> What conflicts are you seeing? I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems: the only thing I do is to set my load-path to point to the
> right place (and make sure that that setting precedes the
> /usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):
>
> (add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))
>
> Although that has been enough for me, it's probably safer to delete
> from load-path all other org entries, thereby making the built-in
> version invisible to emacs - in my case, I just have the one:
>
>(delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)
>
> That way, if you happen to do something like `(require 'old-org-req)'
> with a requirement that is not satisfied by current org, but is
> satisfied by the built-in org, you'd get an error, rather than getting
> a mixed installation.
>
> > Why does that happen ?
> >
> > Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues
> > with that situation and that's extremely confusing. What is the best
> > way to solve that ?
> >
>
> I think the above should be enough (and IME it is), but maybe someone can
> think of other things that might trip one up.
>
> --
> Nick
>
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
>
>
>

-- 
regards,

Tim

--
Tim Cross

Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

[David Edmondson]

On Thursday, 2019-11-21 at 14:37:44 -07, Sean Whitton wrote:

> The function `org-notmuch-follow-link' in {org,ol}-notmuch.el calls
> `notmuch-show' with an arbitrary notmuch search query.  However, the
> docstring for `notmuch-show' specifies that a notmuch thread ID, rather
> than an arbitrary notmuch query, should be supplied to `notmuch-show'.
>
> The effect of this is that the variable `notmuch-show-thread-id' may
> contain an arbitrary search query rather than a thread ID.  That broke
> some code of mine which uses that variable.

Could you explain how you were using `notmuch-show-thread-id' in a way
that was broken by the presence of an arbitrary query?

(Not arguing right or wrong, just trying to understand the problem.)

> `org-notmuch-follow-link' needs to continue to accept an arbitrary query
> (as notmuch thread IDs are not stable), but it should convert it to a
> thread ID before passing it to `notmuch-show'.

dme.
-- 
I'd rather be with you than flying through space.

Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

[racin]

Hi,


> 
> Here is my workaround.  If this approach seems sensible I can prepare a
> patch to `org-notmuch-follow-link` in ol-notmuch.el.

Your approach probably works most of the time, but I don't like the idea 
of having to perform 2 queries when one should be enough.

I think a better approach would be to change notmuch-show (or add a new 
version) that would
allow taking arbitrary queries (and especially, message ids) as input. This 
probably used to be the case.

Note that the command line notmuch show function does accept arbitrary search 
terms as an argument

I think updating notmuch-show to compute the thread id from the query (instead 
of assuming that the input is
a thread id) would be the best way to go, but you should see that with the 
notmuch developers.

Best regards
Matthieu Lemerre


> 
>(use-package org-notmuch
>  :init
>  ;; the default value for `org-notmuch-open-function' is
>  ;; `org-notmuch-follow-link', but that function is broken: it calls
>  ;; `notmuch-show' with a search query rather than a thread ID.  This
>  ;; causes `notmuch-show-thread-id' to be populated with a value
>  ;; which is not a thread ID, which breaks various other things
>  ;;
>  ;; so use a custom function instead
>  (defun spw--org-notmuch-follow-link (search)
>(let ((thread-id
>   (substring
>(shell-command-to-string
> (combine-and-quote-strings (list "notmuch" "search"
>  "--output=threads" 
> "--limit=1"
>  "--format=text"
>  "--format-version=4" 
> search)))
>0 -1)))
>  (notmuch-show thread-id nil nil search search)))
>  (setq org-notmuch-open-function 'spw--org-notmuch-follow-link))
> 
> --
> Sean Whitton

Re: Editting from the agenda view

[Victor A. Stoichita]

Le 26 Nov 2019, Shérab  a écrit :

To reschedule an entry remotely from the agenda view, you can 
press S-right
(org-agenda-do-date-later) or S-left 
(org-agenda-do-date-earlier).


I indeed remember having seen these commands!
The thing is that I am using emacs in the Linux console where 
these
bindings do not work, so I couldn't try them. Is there a way to 
bind

them to different key bindings? I am asking becuase I assume the
bindings you mention are specific to the agenda view and the way 
to
modify them is thus different from ordinary, global bindings. 
Am I

correct?


Indeed they are not global bindings. I don’t know how to rebind 
them for the agenda view.
Meanwhile, the same functions in the agenda view are also bound to 
C-c C-x  and C-c C-x . These should work in the 
terminal, but I’m not sure how handy they are as "shortcuts".


Victor

Re: org 9.2.6 and org 9.1.9

[Nick Dokos]

Jean-Christophe Helary  writes:

> org 9.1.9 is a built-in
>
> but org 9.2.6 comes as a dependency to some packages and having both 
> installed creates conflicts.
>

What conflicts are you seeing? I have the built-in 9.1.9 org that
comes with emacs but I run (close to) latest master and I see no
problems: the only thing I do is to set my load-path to point to the
right place (and make sure that that setting precedes the
/usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):

(add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))

Although that has been enough for me, it's probably safer to delete
from load-path all other org entries, thereby making the built-in
version invisible to emacs - in my case, I just have the one:

   (delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)

That way, if you happen to do something like `(require 'old-org-req)'
with a requirement that is not satisfied by current org, but is
satisfied by the built-in org, you'd get an error, rather than getting
a mixed installation.

> Why does that happen ?
>
> Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues
> with that situation and that's extremely confusing. What is the best
> way to solve that ?
>

I think the above should be enough (and IME it is), but maybe someone can
think of other things that might trip one up.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: org-enable-table-editor is removed since 9.1

[Nick Dokos]

Tomasz Piotrowski  writes:

> If I try to edit a table in org-mode, e.g., add a row to it, I get a
> message
>
> "eval: Symbol’s value as variable is void: org-enable-table-editor".
>
> This is in line with changes made in version 9.1:
> https://orgmode.org/Changes_old.html#org8981857
>
> This makes the manual for editing tables:
> https://orgmode.org/manual/Built_002din-table-editor.html
>
> unusable for me. Indeed, I get the same message:
>
> "eval: Symbol’s value as variable is void: org-enable-table-editor"
>
> when I tried to submit the bug using:
>
> M-x org-submit-bug-report 
>
> I am on version 9.2.6, but I think all versions since 9.1 are affected.
>

Turn on debug-on-error and try again - a stack trace should be produced which 
should help
to identify the place where the symbol is used:

   M-x toggle-debug-on-error RET
   M-x org-submit-bug-report RET

You either have a mixed installation (i.e. you are using a mixture of 9.2.6
and a 9.1-or-earlier version), or you are using this symbol in one of
your initialization files and/or in your customizations.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

[Sean Whitton]

Dear maintainers,

On Thu 21 Nov 2019 at 02:37PM -07, Sean Whitton wrote:

> The function `org-notmuch-follow-link' in {org,ol}-notmuch.el calls
> `notmuch-show' with an arbitrary notmuch search query.  However, the
> docstring for `notmuch-show' specifies that a notmuch thread ID, rather
> than an arbitrary notmuch query, should be supplied to `notmuch-show'.
>
> The effect of this is that the variable `notmuch-show-thread-id' may
> contain an arbitrary search query rather than a thread ID.  That broke
> some code of mine which uses that variable.
>
> `org-notmuch-follow-link' needs to continue to accept an arbitrary query
> (as notmuch thread IDs are not stable), but it should convert it to a
> thread ID before passing it to `notmuch-show'.

Here is my workaround.  If this approach seems sensible I can prepare a
patch to `org-notmuch-follow-link` in ol-notmuch.el.

(use-package org-notmuch
  :init
  ;; the default value for `org-notmuch-open-function' is
  ;; `org-notmuch-follow-link', but that function is broken: it calls
  ;; `notmuch-show' with a search query rather than a thread ID.  This
  ;; causes `notmuch-show-thread-id' to be populated with a value
  ;; which is not a thread ID, which breaks various other things
  ;;
  ;; so use a custom function instead
  (defun spw--org-notmuch-follow-link (search)
(let ((thread-id
   (substring
(shell-command-to-string
 (combine-and-quote-strings (list "notmuch" "search"
  "--output=threads" "--limit=1"
  "--format=text"
  "--format-version=4" search)))
0 -1)))
  (notmuch-show thread-id nil nil search search)))
  (setq org-notmuch-open-function 'spw--org-notmuch-follow-link))

-- 
Sean Whitton

Re: Editting from the agenda view

[Shérab]

Dear Victor,

Many thanks for your response and sorry for the delay of mine!

Victor A. Stoichita (2019/11/23 09:14 +0100):
> 
> Le 22 Nov 2019, Shérab  a écrit :
> > When I am in an agenda view, say the weekly view, how can I edit one of
> > the listed entries? I may want to do that either because I notice I have
> > made a typo that I would like to fix, or because I would like to
> > re-schedule the entry for another date.
> 
> To reschedule an entry remotely from the agenda view, you can press S-right
> (org-agenda-do-date-later) or S-left (org-agenda-do-date-earlier).

I indeed remember having seen these commands!
The thing is that I am using emacs in the Linux console where these
bindings do not work, so I couldn't try them. Is there a way to bind
them to different key bindings? I am asking becuase I assume the
bindings you mention are specific to the agenda view and the way to
modify them is thus different from ordinary, global bindings. Am I
correct?

> C-c C-s (org-agenda-schedule) and C-c C-d (org-agenda-deadline) also
> work without leaving the agenda view.

I shall thy these! Thanks!

Best wishes,

Shérab.

Re: org-enable-table-editor is removed since 9.1

[Tomasz Piotrowski]

Nicolas,

I will check the libraries, thank you.

Tomasz


Nicolas Goaziou writes:

> Tomasz Piotrowski  writes:
>
>> Many thanks for the reply. Please find the backtrace attached. This
>> variable org-enable-table-editor has been removed in org v.9.1., which
>> is stated explicitly in the release notes for v.9.1:
>> https://orgmode.org/Changes_old.html
>>
>> I use v.9.2.6. The error appears each time I try to edit an org-mode
>> table, for example, inserting row using M-RET which calls
>>
>> M-RET (translated from ) runs the command org-meta-return
>> (found in org-mode-map), which is an interactive Lisp closure in
>> ‘org.el’.
>
> [...]
>
>>   (eq org-enable-table-editor 'optimized)
>>   eval((eq org-enable-table-editor 'optimized))
>>   custom-initialize-reset(orgtbl-optimized (eq org-enable-table-editor 
>> 'optimized))
>>   custom-declare-variable(orgtbl-optimized (eq org-enable-table-editor 
>> 'optimized) "Non-nil means use the optimized table editor versi..." :group 
>> org-table :type boolean)
>
> This looks like a Frankenorg, there is no such code in Org 9.2.6. You
> may want to double-check your Org installation, you are probably mixing
> old and new libraries.

Re: org-enable-table-editor is removed since 9.1

[Nicolas Goaziou]

Tomasz Piotrowski  writes:

> Many thanks for the reply. Please find the backtrace attached. This
> variable org-enable-table-editor has been removed in org v.9.1., which
> is stated explicitly in the release notes for v.9.1:
> https://orgmode.org/Changes_old.html
>
> I use v.9.2.6. The error appears each time I try to edit an org-mode
> table, for example, inserting row using M-RET which calls
>
> M-RET (translated from ) runs the command org-meta-return
> (found in org-mode-map), which is an interactive Lisp closure in
> ‘org.el’.

[...]

>   (eq org-enable-table-editor 'optimized)
>   eval((eq org-enable-table-editor 'optimized))
>   custom-initialize-reset(orgtbl-optimized (eq org-enable-table-editor 
> 'optimized))
>   custom-declare-variable(orgtbl-optimized (eq org-enable-table-editor 
> 'optimized) "Non-nil means use the optimized table editor versi..." :group 
> org-table :type boolean)

This looks like a Frankenorg, there is no such code in Org 9.2.6. You
may want to double-check your Org installation, you are probably mixing
old and new libraries.

Re: org-enable-table-editor is removed since 9.1

[Tomasz Piotrowski]

Hello,

Many thanks for the reply. Please find the backtrace attached. This
variable org-enable-table-editor has been removed in org v.9.1., which
is stated explicitly in the release notes for v.9.1:
https://orgmode.org/Changes_old.html

I use v.9.2.6. The error appears each time I try to edit an org-mode
table, for example, inserting row using M-RET which calls

M-RET (translated from ) runs the command org-meta-return
(found in org-mode-map), which is an interactive Lisp closure in
‘org.el’.

It is bound to M-RET.

(org-meta-return  ARG)

Insert a new heading or wrap a region in a table.
Calls ‘org-insert-heading’, ‘org-insert-item’ or
‘org-table-wrap-region’, depending on context.  When called with
an argument, unconditionally call ‘org-insert-heading’.




Nicolas Goaziou writes:

> Hello,
>
> Tomasz Piotrowski  writes:
>
>> If I try to edit a table in org-mode, e.g., add a row to it, I get a
>> message
>>
>> "eval: Symbol’s value as variable is void: org-enable-table-editor".
>
> You should check, and possibly send, the full backtrace. Org code base
> does not contain any reference to this variable. This may be related to
> your configuration.
>
> Regards,



backtrace
Description: Binary data

Re: [PATCH] Add support for month trees

[Nicolas Goaziou]

Hello,

Jason  writes:

> Please find my attached patch which implements a way to capture entries
> grouped by month.

Thank you.

> I was searching for this option, but only found a way to group entries by
> week or day.
>
> I found the following posts where other people also need this feature:
> https://emacs.stackexchange.com/questions/48414/monthly-date-tree
> https://lists.gnu.org/archive/html/emacs-orgmode/2018-02/msg00092.html

I think this can be tested in "next" branch. Could you rebase your patch
against it?

> * etc/ORG-NEWS: Document new `:tree-type month' option.

No need to provide this information in the commit message, IMO. Of
course, it doesn't hurt in any case. Just sayin'.

> +Use ~week~ to make a week tree instead of the month-day tree,
> +i.e., place the headings for each day under a heading with the
> +current ISO week. Use @code{month} to group entries by month
> +only. Default is to group entries by day.

You need to put two spaces after full stops.

> + (cond
> +  ((eq (org-capture-get :tree-type) 'week)
> +   #'org-datetree-find-iso-week-create)
> +  ((eq (org-capture-get :tree-type) 'month)
> +   #'org-datetree-find-month-create)
> +  (t
> +   #'org-datetree-find-date-create))

Could you refactor that with `case' instead? I.e.,

(case (org-capture-get :tree-type)
 (`week ...)
 ...)
> +  (if (eq time-grouping 'day)
> +   (org-datetree--find-create
> +"^\\*+[ \t]+%d-%02d-\\([0123][0-9]\\) \\w+$"
> +year month day)

Please use `when' (or `unless') instead of one-armed `if'.

Could you send an updated patch?

Regards,

-- 
Nicolas Goaziou

Re: org-enable-table-editor is removed since 9.1

[Nicolas Goaziou]

Hello,

Tomasz Piotrowski  writes:

> If I try to edit a table in org-mode, e.g., add a row to it, I get a
> message
>
> "eval: Symbol’s value as variable is void: org-enable-table-editor".

You should check, and possibly send, the full backtrace. Org code base
does not contain any reference to this variable. This may be related to
your configuration.

Regards,

-- 
Nicolas Goaziou