[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-18 Thread Stefan Monnier
> The more general problem is when there's at least one more
> sub-expression, whose start and/or end are after the new EOB.
> Those sub-expression's data will be completely bogus after the
> adjustment,

If they were after the EOB, they were already bogus to start with.
So there's really not much harm moving them around.  And in any case,
that's what has been happening for ever and has proved safe enough.

>> So I think a safe fix is to try and relax the check we added to
>> replace-match so it doesn't get all worked up when something ≥ EOB gets
>> changed to something else that's also ≥ EOB.
> And lose the other sub-expressions in a more general case?  Really?

I'm not sure what you mean by "losing sub-expressions".  But yes,
I think the behavior of save-match-data you describe is not
a real problem.  Arguably if save-match-data moves positions from
outside BEGV...ZV to inside it it's a problem.  But if it moves them
from outside BEG...Z to inside it, I think it's perfectly fine.

>> Or maybe instead of signaling an error, we could simply skip the "Adjust
>> search data for this change".
> That would still sweep the problem under the carpet, leaving the match
> data bogus, so I don't like doing that.

Maybe I'm not 100% satisfied with the behavior either, but I don't think
it's a significant problem and I don't think it'd cause the crash we saw
in bug#23869.

> The crash in bug#23869 was due to this:
>
>   newpoint = search_regs.start[sub] + SCHARS (newtext);
>   [...]
>   /* Now move point "officially" to the start of the inserted replacement.  */
>   move_if_not_intangible (newpoint);  <<<
>
> because due to clobbering, newpoint became -1.

Ah, I see.

Then maybe another fix is to compute newpoint before we call
replace_range, so it uses search_regs.start[sub] before the
*-change-functions can mess it up.  IOW:

@@ -2726,9 +2726,9 @@ since only regular expressions have distinguished 
subexpressions.  */)
   unsigned  num_regs = search_regs.num_regs;
 
   /* Replace the old text with the new in the cleanest possible way.  */
+  newpoint = search_regs.start[sub] + SCHARS (newtext);
   replace_range (search_regs.start[sub], search_regs.end[sub],
 newtext, 1, 0, 1);
-  newpoint = search_regs.start[sub] + SCHARS (newtext);
 
   if (case_action == all_caps)
 Fupcase_region (make_number (search_regs.start[sub]),

Would that be sufficient to avoid the crash?  Why not?


Stefan





[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-18 Thread Eli Zaretskii
> From: Stefan Monnier 
> Cc: Robert Pluim ,  23...@debbugs.gnu.org,  
> alex.ben...@linaro.org,  jwieg...@gmail.com,  nljlistb...@gmail.com
> Date: Mon, 18 Jul 2016 20:58:35 -0400
> 
> > In the case in point, a single character at EOB (= 62) was deleted,
> > which made EOB be 61, one less than its previous value.  When
> > save-match-data was called from within a hook set up by Org, it tried
> > to record the end of the sub-expression as 62, but set-marker silently
> > changed that to 61.  That "corrected" value was subsequently restored
> > when save-match-data was exited, whereas replace-match expected to see
> > the original value of 62, and therefore barfed.
> 
> I think this change performed by save-match-data is harmless: the old
> value (62) was not valid any more anyway.

In this particular case, yes.  But only in this case, because (a)
there's actually only one sub-expression, and (b) it ends exactly at
EOB.

The more general problem is when there's at least one more
sub-expression, whose start and/or end are after the new EOB.  Those
sub-expression's data will be completely bogus after the adjustment,
should the buffer-modification hooks use save-match-data.

> So I think a safe fix is to try and relax the check we added to
> replace-match so it doesn't get all worked up when something ≥ EOB gets
> changed to something else that's also ≥ EOB.

And lose the other sub-expressions in a more general case?  Really?

> Or maybe instead of signaling an error, we could simply skip the "Adjust
> search data for this change".

That would still sweep the problem under the carpet, leaving the match
data bogus, so I don't like doing that.

> This said, I don't fully understand what's going on: bug#23869 reported
> a crash, but AFAICT the match-data here is only used to adjust
> search_regs which seems like it wouldn't cause a crash, even if the new
> values are bogus.

The crash in bug#23869 was due to this:

  newpoint = search_regs.start[sub] + SCHARS (newtext);
  [...]
  /* Now move point "officially" to the start of the inserted replacement.  */
  move_if_not_intangible (newpoint);  <<<

because due to clobbering, newpoint became -1.

> > -   '((save-match-data-internal (match-data)))
> > +   '((save-match-data-internal (match-data 'integers)))
> 
> That looks risky.

Then how about manually doing the equivalent of save-match-data around
the call to replace_range, calling match-data with non-nil argument?





[O] how to update and add info to babel documentation?

2016-07-18 Thread dmg
hi there,

I was trying to find the sources for the babel language documentation.
Specifically:


http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-sqlite.html

Could anybody please tell me which is the best way to submit a patch to it?

Specifically, I would like to document the use of variables in the mode. I
had to read its source code to know that you can to prefix the variable
name with
$ for it to work, eg:


#+BEGIN_SRC sqlite :db /tmp/rip.db :var x="table"
select * from $x;
#+END_SRC


​thank you,​

-- 
--dmg

---
Daniel M. German
http://turingmachine.org


[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-18 Thread Stefan Monnier
> In the case in point, a single character at EOB (= 62) was deleted,
> which made EOB be 61, one less than its previous value.  When
> save-match-data was called from within a hook set up by Org, it tried
> to record the end of the sub-expression as 62, but set-marker silently
> changed that to 61.  That "corrected" value was subsequently restored
> when save-match-data was exited, whereas replace-match expected to see
> the original value of 62, and therefore barfed.

I think this change performed by save-match-data is harmless: the old
value (62) was not valid any more anyway.

So I think a safe fix is to try and relax the check we added to
replace-match so it doesn't get all worked up when something ≥ EOB gets
changed to something else that's also ≥ EOB.

Or maybe instead of signaling an error, we could simply skip the "Adjust
search data for this change".  I like the idea of signaling an error, as
a debugging help, but maybe for emacs-25 we should go for something less
intrusive after all?

This said, I don't fully understand what's going on: bug#23869 reported
a crash, but AFAICT the match-data here is only used to adjust
search_regs which seems like it wouldn't cause a crash, even if the new
values are bogus.  So maybe signaling an error is important because the
crash happens further down.

> - '((save-match-data-internal (match-data)))
> + '((save-match-data-internal (match-data 'integers)))

That looks risky.


Stefan





Re: [O] links-9.0 v3

2016-07-18 Thread John Kitchin
Sounds good. Thanks for your patience, I learned a lot doing this! I
look forward to using it in the wild ;)

Nicolas Goaziou writes:

> John Kitchin  writes:
>
>> Ok. I have attached 20 patches with the updates below.
>
> Applied, with minor tweaks (trailing white spaces and too wide lines).
> Thank you for all this work.
>
> Ultimately, I removed `org--open-file-link' altogether since default
> behaviour for file+apps links DTRT. I also started to deprecate
> file+apps links, i.e., they are still supported but we start suggesting
> to use plain "file" links instead.
>
> Regards,


-- 
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



Re: [O] links-9.0 v3

2016-07-18 Thread Nicolas Goaziou
John Kitchin  writes:

> Ok. I have attached 20 patches with the updates below.

Applied, with minor tweaks (trailing white spaces and too wide lines).
Thank you for all this work.

Ultimately, I removed `org--open-file-link' altogether since default
behaviour for file+apps links DTRT. I also started to deprecate
file+apps links, i.e., they are still supported but we start suggesting
to use plain "file" links instead.

Regards,



Re: [O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread Kaushal Modi
+1 for org 9.0 in master.

On Mon, Jul 18, 2016 at 4:36 PM Rasmus  wrote:

> Nicolas Goaziou  writes:
>
> >> I would suggest that you push the latest maint branch org version to the
> >> master branch of emacs now, so that it would be fairly tested by the
> time
> >> the next to next emacs release happens (25.2?).
> >
> > My secret plan is to have Org 9.0 merged in Emacs master branch just
> > after Emacs 25.1 is released.
> >
> > Meanwhile, I think we can release Org 8.3.5 which, hopefully will be the
> > last stable release in the 8.3.X series.
> >
> > Bastien, WDYT?
>
> FWIW I was going to argue for a quick 9.0 as well.  Though I'd like to get
> all my WIP finished beforehand...
>
> --
> ⠠⠵
>
-- 

Kaushal Modi


Re: [O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread Rasmus
Nicolas Goaziou  writes:

>> I would suggest that you push the latest maint branch org version to the
>> master branch of emacs now, so that it would be fairly tested by the time
>> the next to next emacs release happens (25.2?).
>
> My secret plan is to have Org 9.0 merged in Emacs master branch just
> after Emacs 25.1 is released.
>
> Meanwhile, I think we can release Org 8.3.5 which, hopefully will be the
> last stable release in the 8.3.X series.
>
> Bastien, WDYT?

FWIW I was going to argue for a quick 9.0 as well.  Though I'd like to get
all my WIP finished beforehand...

-- 
⠠⠵




Re: [O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread Rasmus
Kaushal Modi  writes:

> On Mon, Jul 18, 2016 at 12:02 PM Nicolas Goaziou 
> wrote:
>
>> I'm fairly surprised about this answer because we have been repeatedly
>> asking for an update, and they refused every time.
>>
>> Org 8.3 was meant to be included in Emacs 25 and it was released about
>> one year ago.
>>
>
> There's miscommunication between the emacs-devel and emacs-orgmode mailing
> lists.

The message was pretty clear.

-- 
A clever person solves a problem. A wise person avoids it




Re: [O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread Rasmus
Kaushal Modi  writes:

> On Mon, Jul 18, 2016 at 11:55 AM Rasmus  wrote:
>
>> nljlistb...@gmail.com (N. Jackson) writes:
>>
>> Org 8.3.4 will be part of Emacs 25.1.  Maybe Org 8.4 will be part of Emacs
>> 25.2.
>>
>
> How does that work? emacs 25.1 is already in the final versions of pretests
> and the it still has org version 8.2.10. Shouldn't the 8.3.4 version have
> been merged a long time before the pretests were even started?

Right, I got confused.  8.2.10.
Thanks for correcting me!

-- 
The Kids call him Billy the Saint



[O] Question about archiving

2016-07-18 Thread Thomas Moyer
There seems to be three different ways to archive entries.

1. Set archive property on item
2. Move to archive sibling
3. Move to archive file

Can someone explain the difference, and what the pros/cons are of using
each?

Thanks!

Tom


Re: [O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread N. Jackson
At 19:49 +0200 on Monday 2016-07-18, Nicolas Goaziou wrote:
>
> My secret plan is to have Org 9.0 merged in Emacs master branch just
> after Emacs 25.1 is released.

The effectiveness of this strategy might depend upon whether Emacs 25.2
is cut from what is now the Emacs master branch or from the emacs-25
branch. My understanding is that this has not yet been decided.




[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-18 Thread Eli Zaretskii
> From: John Wiegley 
> Cc: Robert Pluim ,  Stefan Monnier 
> ,  23...@debbugs.gnu.org,  alex.ben...@linaro.org,  
> nljlistb...@gmail.com
> Date: Mon, 18 Jul 2016 12:04:11 -0700
> 
> > Eli Zaretskii  writes:
> 
> > My suggestion to fix this is below. I ask for opinions on (1) whether this
> > looks like TRT, (2) whether it is safe enough for emacs-25, and (3) whether
> > someone has better ideas.
> 
> I didn't even know match-data took arguments, so I defer to your judgment on
> this issue, Eli.

Neither did I, but I've read the code through which I stepped ;-)





[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-18 Thread John Wiegley
> Eli Zaretskii  writes:

> My suggestion to fix this is below. I ask for opinions on (1) whether this
> looks like TRT, (2) whether it is safe enough for emacs-25, and (3) whether
> someone has better ideas.

I didn't even know match-data took arguments, so I defer to your judgment on
this issue, Eli.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2


signature.asc
Description: PGP signature


Re: [O] Customizing todo state for habits

2016-07-18 Thread Milan Zamazal
> "CL" == Clarissa Littler  writes:

CL> the default behavior of habits seems to be to, when completed,
CL> to revert the state to the first todo keyword in your listing
CL> but I want to have different todo states for different habits
CL> depending on the /kind/ of task it is.

Rules for repeated tasks apply, as described in Org manual, section
Repeated tasks, footnote 1.

-- 
http://www.zamazal.org




[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-18 Thread Eli Zaretskii
> From: Robert Pluim 
> CC: 23...@debbugs.gnu.org, Alex Bennée
>  , jwieg...@gmail.com, nljlistb...@gmail.com
> Date: Mon, 18 Jul 2016 14:24:59 +0200
> 
> (I'm moving this discussion to the bug, let me know if that's not OK)

Thanks.

> Make sure that you have org-20160704 from elpa.
> 
> # emacs -Q
> 
> ;evaluate the following 
> (custom-set-variables
>  '(package-selected-packages
>(quote
> (org-20160704
> (package-initialize)
> 
> ; Now do:
> 
> C-x C-f ~/.notes
> M-x org-mode
> M-x org-capture
> t
> 
> ; This should result in:
> Capture template ‘t’: Match data clobbered by buffer modification
> hooks

Thanks again.

It turns out the validation added in 3a9d6296, to solve bug#23869,
exposed a very serious bug we seem to have always had with
save-match-data called from buffer-modification hooks.

The basic problem is that set-marker restricts the buffer position
passed as its argument to valid limits, between 1 and EOB.  So if you
call set-marker with a value beyond EOB, the marker's position will
silently set to EOB.

Now, when buffer-modification hooks run due to changes made by
replace-match, the replacement has already been done.  If that
replacement shrinks the buffer, then when save-match-data is called,
and calls match-data, the latter will see the new (smaller) value of
EOB.  By default, match-data records the data in markers it creates
for beginning and end of each matched sub-expression.  So the result
is that beginning and/or end of any sub-expression that was beyond the
new EOB will be recorded as EOB.  Then restoring this saved match data
will clobber the data of those sub-expressions.

In the case in point, a single character at EOB (= 62) was deleted,
which made EOB be 61, one less than its previous value.  When
save-match-data was called from within a hook set up by Org, it tried
to record the end of the sub-expression as 62, but set-marker silently
changed that to 61.  That "corrected" value was subsequently restored
when save-match-data was exited, whereas replace-match expected to see
the original value of 62, and therefore barfed.

My suggestion to fix this is below.  I ask for opinions on (1) whether
this looks like TRT, (2) whether it is safe enough for emacs-25, and
(3) whether someone has better ideas.  If someone thinks I've
misunderstood the issue, don't hesitate to explain why, because
frankly it feels very strange to find bugs that seem to have existed
since 1990.

diff --git a/lisp/subr.el b/lisp/subr.el
index e9e19d3..1bb1cb3 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3466,7 +3466,7 @@ save-match-data
   ;; if you need to recompile all the Lisp files using interpreted code.
   (declare (indent 0) (debug t))
   (list 'let
-   '((save-match-data-internal (match-data)))
+   '((save-match-data-internal (match-data 'integers)))
(list 'unwind-protect
  (cons 'progn body)
  ;; It is safe to free (evaporate) markers immediately here,





Re: [O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread Nicolas Goaziou
Hello,

Kaushal Modi  writes:

> There's miscommunication between the emacs-devel and emacs-orgmode mailing
> lists.

Probably.

> I would suggest that you push the latest maint branch org version to the
> master branch of emacs now, so that it would be fairly tested by the time
> the next to next emacs release happens (25.2?).

My secret plan is to have Org 9.0 merged in Emacs master branch just
after Emacs 25.1 is released.

Meanwhile, I think we can release Org 8.3.5 which, hopefully will be the
last stable release in the 8.3.X series.

Bastien, WDYT?


Regards,

-- 
Nicolas Goaziou



[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-18 Thread Eric S Fraga
On Monday, 18 Jul 2016 at 14:50, Kaushal Modi wrote:
> @Eric Would it be possible for you to provide a recipe to recreate
> this issue from an emacs -Q session?

With emacs-snapshot (aka 25.0.95.1), and the following emacs-minimal.el
file:

--8<---cut here---start->8---
(add-to-list 'load-path "~/git/org-mode/lisp")
(require 'org)
(setq org-capture-templates '(("t" "todo" entry (file+datetree 
"/tmp/tasks.org") "* TODO %^{Task} %^G\nSCHEDULED: %t\n%i%?")))
--8<---cut here---end--->8---

the following sequence:

--8<---cut here---start->8---
emacs -Q -l emacs-minimal.el
M-x org-capture RET t this is a test RET testing RET
--8<---cut here---end--->8---

gives

--8<---cut here---start->8---
Debugger entered--Lisp error: (error "Capture template ‘t’: Match data 
clobbered by buffer modification hooks")
  signal(error ("Capture template ‘t’: Match data clobbered by buffer 
modification hooks"))
  error("Capture template `%s': %s" "t" "Match data clobbered by buffer 
modification hooks")
  (condition-case error (org-capture-place-template (equal (car 
(org-capture-get :target)) (quote function))) ((error quit) (if (and 
(buffer-base-buffer (current-buffer)) (string-match "\\`CAPTURE-" 
(buffer-name))) (kill-buffer (current-buffer))) (set-window-configuration 
(org-capture-get :return-to-wconf)) (error "Capture template `%s': %s" 
(org-capture-get :key) (nth 1 error
  (if (equal goto 0) (org-capture-insert-template-here) (condition-case error 
(org-capture-place-template (equal (car (org-capture-get :target)) (quote 
function))) ((error quit) (if (and (buffer-base-buffer (current-buffer)) 
(string-match "\\`CAPTURE-" (buffer-name))) (kill-buffer (current-buffer))) 
(set-window-configuration (org-capture-get :return-to-wconf)) (error "Capture 
template `%s': %s" (org-capture-get :key) (nth 1 error (if (and 
(derived-mode-p (quote org-mode)) (org-capture-get :clock-in)) (condition-case 
nil (progn (if (org-clock-is-active) (org-capture-put :interrupted-clock 
(copy-marker org-clock-marker))) (org-clock-in) (set (make-local-variable 
(quote org-capture-clock-was-started)) t)) (error "Could not start the clock in 
this capture buffer"))) (if (org-capture-get :immediate-finish) 
(org-capture-finalize)))
  (cond ((equal entry "C") (customize-variable (quote org-capture-templates))) 
((equal entry "q") (user-error "Abort")) (t (org-capture-set-plist entry) 
(org-capture-get-template) (org-capture-put :original-buffer orig-buf 
:original-file (or (buffer-file-name orig-buf) (and (featurep (quote dired)) 
(car (rassq orig-buf dired-buffers :original-file-nondirectory (and 
(buffer-file-name orig-buf) (file-name-nondirectory (buffer-file-name 
orig-buf))) :annotation annotation :initial initial :return-to-wconf 
(current-window-configuration) :default-time (or org-overriding-default-time 
(org-current-time))) (org-capture-set-target-location) (condition-case error 
(org-capture-put :template (org-capture-fill-template)) ((error quit) (if 
(get-buffer "*Capture*") (kill-buffer "*Capture*")) (error "Capture abort: %s" 
error))) (setq org-capture-clock-keep (org-capture-get :clock-keep)) (if (equal 
goto 0) (org-capture-insert-template-here) (condition-case error 
(org-capture-place-template (equal (car (org-capture-get :target)) (quote 
function))) ((error quit) (if (and (buffer-base-buffer ...) (string-match 
"\\`CAPTURE-" ...)) (kill-buffer (current-buffer))) (set-window-configuration 
(org-capture-get :return-to-wconf)) (error "Capture template `%s': %s" 
(org-capture-get :key) (nth 1 error (if (and (derived-mode-p (quote 
org-mode)) (org-capture-get :clock-in)) (condition-case nil (progn (if 
(org-clock-is-active) (org-capture-put :interrupted-clock ...)) (org-clock-in) 
(set (make-local-variable ...) t)) (error "Could not start the clock in this 
capture buffer"))) (if (org-capture-get :immediate-finish) 
(org-capture-finalize)
  (let* ((orig-buf (current-buffer)) (annotation (if (and (boundp (quote 
org-capture-link-is-already-stored)) org-capture-link-is-already-stored) 
(plist-get org-store-link-plist :annotation) (condition-case nil (progn 
(org-store-link nil)) (error nil (entry (or org-capture-entry 
(org-capture-select-template keys))) initial) (setq initial (or 
org-capture-initial (and (org-region-active-p) (buffer-substring (point) 
(mark) (if (stringp initial) (progn (remove-text-properties 0 (length 
initial) (quote (read-only t)) initial))) (if (stringp annotation) (progn 
(remove-text-properties 0 (length annotation) (quote (read-only t)) 
annotation))) (cond ((equal entry "C") (customize-variable (quote 
org-capture-templates))) ((equal entry "q") (user-error "Abort")) (t 
(org-capture-set-plist entry) (org-capture-get-template) (org-capture-put 
:original-buffer orig-buf :original-file (or 

Re: [O] links-9.0 v3

2016-07-18 Thread John Kitchin

Nicolas Goaziou writes:

> John Kitchin  writes:
>
>> I am not sure what you mean for this. Let me know if it isn't fixed in
>> the attached patches. I thought I had squashed everything into a concise
>> history.
>
> No worries. Let's just apply the 21 patches.

Ok. I have attached 20 patches with the updates below.

>
>> I think this code below (which should be in the patches) handles the
>> option correctly.
>>
>> (defun org--open-file-link (path app)
>
> It should, but I didn't see it in the previous patch, hence my remark.
>
>> -(defvar org-store-link-functions nil
>> -  "List of functions that are called to create and store a link.
>>  Each function will be called in turn until one returns a non-nil
>> -value.  Each function should check if it is responsible for creating
>> -this link (for example by looking at the major mode).
>> -If not, it must exit and return nil.
>> -If yes, it should return a non-nil value after a calling
>> -`org-store-link-props' with a list of properties and values.
>> -Special properties are:
>> +value.  Each function should check if it is responsible for
>> +creating this link (for example by looking at the major mode).  If
>> +not, it must exit and return nil.  If yes, it should return a
>> +non-nil value after a calling `org-store-link-props' with a list
>> +of properties and values. Special properties are:
>
> Missing a space after the full stop above.
>
>> +(defun org--open-file-link (path app)
>> +  "Open PATH using APP.
>> +
>> +PATH is from a file link, and can have the following syntax:
>> + [[file:~/code/main.c::255]]
>> + [[file:~/xx.org::My Target]]
>> + [[file:~/xx.org::*My Target]]
>> + [[file:~/xx.org::#my-custom-id]]
>> + [[file:~/xx.org::/regexp/]]
>> +
>> +APP is '(4) to open the PATH in Emacs, or 'system to use a system
>> application."
>
> Maybe something like:
>
>   Called it with \\[universal-argument] to open PATH in Emacs. If ARG is
>   `system', use a system application instead.
>
>
> Regards,
>From 9255b7f7b5462a82fb720720fc10eb5a1bd17297 Mon Sep 17 00:00:00 2001
From: John Kitchin 
Date: Thu, 7 Jul 2016 09:58:29 -0400
Subject: [PATCH 01/20] Create `org-link-parameters'

* lisp/org-element.el: Replace `org-link-types' variable with
  `org-link-types' function.

* lisp/org.el: Replace the `org-link-types' variable with
  `org-link-types' function. Create `org-link-get-parameter' and
  `org-link-set-parameters' functions. Remove `org-add-link-type'. Add
  `org-store-link-functions' function and remove
  `org-store-link-functions' variable. Add `org--open-file-link' for use
  as a :follow function for file type links.

* lisp/org.el: Set :follow functions for file links in `org-link-parameters.
Define `org-open-file-link' that opens a file link with an app.

* testing/lisp/test-ox.el: Remove usage of the `org-link-types'
  variable.

* lisp/org-compat.el: Move `org-add-link-type' and mark it as obsolete.

* lisp/ox.el: Change org-add-link-type comment in ox.el.
---
 lisp/org-compat.el  |  31 +
 lisp/org-element.el |   4 +-
 lisp/org.el | 168 
 lisp/ox.el  |   2 +-
 testing/lisp/test-ox.el |  16 ++---
 5 files changed, 156 insertions(+), 65 deletions(-)

diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 92fdb1c..a856ff7 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -374,6 +374,37 @@ Implements `define-error' for older emacsen."
 (put name 'error-conditions
 	 (copy-sequence (cons name (get 'error 'error-conditions))
 
+(defun org-add-link-type (type  follow export)
+  "Add a new TYPE link.
+FOLLOW and EXPORT are two functions.
+
+FOLLOW should take the link path as the single argument and do whatever
+is necessary to follow the link, for example find a file or display
+a mail message.
+
+EXPORT should format the link path for export to one of the export formats.
+It should be a function accepting three arguments:
+
+  paththe path of the link, the text after the prefix (like \"http:\")
+  descthe description of the link, if any
+  format  the export format, a symbol like `html' or `latex' or `ascii'.
+
+The function may use the FORMAT information to return different values
+depending on the format.  The return value will be put literally into
+the exported file.  If the return value is nil, this means Org should
+do what it normally does with links which do not have EXPORT defined.
+
+Org mode has a built-in default for exporting links.  If you are happy with
+this default, there is no need to define an export function for the link
+type.  For a simple example of an export function, see `org-bbdb.el'.
+
+If TYPE already exists, update it with the arguments.
+See `org-link-parameters' for documentation on the other parameters."
+  (org-link-add type :follow follow :export export) 
+  (message "Created %s link." type))
+
+(make-obsolete 'org-add-link-type 

Re: [O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread Kaushal Modi
On Mon, Jul 18, 2016 at 12:02 PM Nicolas Goaziou 
wrote:

> I'm fairly surprised about this answer because we have been repeatedly
> asking for an update, and they refused every time.
>
> Org 8.3 was meant to be included in Emacs 25 and it was released about
> one year ago.
>

There's miscommunication between the emacs-devel and emacs-orgmode mailing
lists.

I would suggest that you push the latest maint branch org version to the
master branch of emacs now, so that it would be fairly tested by the time
the next to next emacs release happens (25.2?).
-- 

Kaushal Modi


Re: [O] links-9.0 v3

2016-07-18 Thread Nicolas Goaziou
John Kitchin  writes:

> I am not sure what you mean for this. Let me know if it isn't fixed in
> the attached patches. I thought I had squashed everything into a concise
> history.

No worries. Let's just apply the 21 patches.

> I think this code below (which should be in the patches) handles the
> option correctly.
>
> (defun org--open-file-link (path app)

It should, but I didn't see it in the previous patch, hence my remark.

> -(defvar org-store-link-functions nil
> -  "List of functions that are called to create and store a link.
>  Each function will be called in turn until one returns a non-nil
> -value.  Each function should check if it is responsible for creating
> -this link (for example by looking at the major mode).
> -If not, it must exit and return nil.
> -If yes, it should return a non-nil value after a calling
> -`org-store-link-props' with a list of properties and values.
> -Special properties are:
> +value.  Each function should check if it is responsible for
> +creating this link (for example by looking at the major mode).  If
> +not, it must exit and return nil.  If yes, it should return a
> +non-nil value after a calling `org-store-link-props' with a list
> +of properties and values. Special properties are:

Missing a space after the full stop above.

> +(defun org--open-file-link (path app)
> +  "Open PATH using APP.
> +
> +PATH is from a file link, and can have the following syntax:
> + [[file:~/code/main.c::255]]
> + [[file:~/xx.org::My Target]]
> + [[file:~/xx.org::*My Target]]
> + [[file:~/xx.org::#my-custom-id]]
> + [[file:~/xx.org::/regexp/]]
> +
> +APP is '(4) to open the PATH in Emacs, or 'system to use a system
> application."

Maybe something like:

  Called it with \\[universal-argument] to open PATH in Emacs. If ARG is
  `system', use a system application instead.


Regards,



Re: [O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread Kaushal Modi
On Mon, Jul 18, 2016 at 11:55 AM Rasmus  wrote:

> nljlistb...@gmail.com (N. Jackson) writes:
>
> Org 8.3.4 will be part of Emacs 25.1.  Maybe Org 8.4 will be part of Emacs
> 25.2.
>

How does that work? emacs 25.1 is already in the final versions of pretests
and the it still has org version 8.2.10. Shouldn't the 8.3.4 version have
been merged a long time before the pretests were even started?
-- 

Kaushal Modi


Re: [O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread Nicolas Goaziou
Hello,

nljlistb...@gmail.com (N. Jackson) writes:

> I'm wondering if there will be an updated version of Org Mode
> bundled with Emacs 25?

No, AFAICT Org mode will not be updated.

> (I asked this question on the Emacs developers' list and they
> suggested [1] that I ask the Org Mode developers.)

I'm fairly surprised about this answer because we have been repeatedly
asking for an update, and they refused every time. 

Org 8.3 was meant to be included in Emacs 25 and it was released about
one year ago.


Regards,

-- 
Nicolas Goaziou



Re: [O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread Rasmus
nljlistb...@gmail.com (N. Jackson) writes:

> I'm wondering if there will be an updated version of Org Mode
> bundled with Emacs 25?

Org 8.3.4 will be part of Emacs 25.1.  Maybe Org 8.4 will be part of Emacs
25.2.

-- 
Evidence suggests Snowden used a powerful tool called monospaced fonts




[O] Will there be an updated Org Mode in Emacs 25?

2016-07-18 Thread N. Jackson
Hello Org Mode developers,

I'm wondering if there will be an updated version of Org Mode
bundled with Emacs 25?

In the tarball for the most recent pre-release version (25.0.95)
the bundled Org Mode is 8.2.10. This is the same version that was
bundled with Emacs 24.5 15 months ago or so, and presumably it is
even older than that!

As the release or the next Emacs looks like it will be fairly soon (on
the order of a few weeks?), this would seem to be something needing
addressing fairly soon. :)

(I asked this question on the Emacs developers' list and they
suggested [1] that I ask the Org Mode developers.)

Thanks.

Regards,
N.

[1] http://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00792.html




Re: [O] links-9.0 v3

2016-07-18 Thread John Kitchin

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin  writes:
>
>> Here are my current suggestions for the org-link 9.0.
>
> Thank you.

I think I fixed the points you made in the previous email.

>
>> Let me know what the best way to send these might be. It looks like it
>> might be 21 patches right now.
>
> AFAIU, many among them introduce code that no longer exists in the final
> draft. It would be nice to make them disappear, using interactive
> rebasing, as suggested earlier in this thread.

I am not sure what you mean for this. Let me know if it isn't fixed in
the attached patches. I thought I had squashed everything into a concise
history. 

>
> If that's not possible, just send them over here, I'll apply them.
>
> BTW sent patch doesn't seem to include an option handler. Am I missing
> something?

What do you mean by an option handler?

Do you mean for this file:path::option

I think this code below (which should be in the patches) handles the
option correctly.

(defun org--open-file-link (path app)
  "Open PATH using APP.

PATH is from a file link, and can have the following syntax:
 [[file:~/code/main.c::255]]
 [[file:~/xx.org::My Target]]
 [[file:~/xx.org::*My Target]]
 [[file:~/xx.org::#my-custom-id]]
 [[file:~/xx.org::/regexp/]]

APP is '(4) to open the PATH in Emacs, or 'system to use a system application."
  (let* ((fields (split-string path "::")) 
 (option (and (cdr fields)
  (mapconcat #'identity (cdr fields) ""
(apply #'org-open-file
   (car fields)
   app
   (cond ((not option) nil)
 ((string-match-p "\\`[0-9]+\\'" option)
  (list (string-to-number option)))
 (t (list nil
  (org-link-unescape option)))


>
> Regards,

>From ddc863fc16b8fe4b430e2f86b7ad96a0e90219cc Mon Sep 17 00:00:00 2001
From: John Kitchin 
Date: Thu, 7 Jul 2016 09:58:29 -0400
Subject: [PATCH 01/20] Create `org-link-parameters'

* lisp/org-element.el: Replace `org-link-types' variable with
  `org-link-types' function.

* lisp/org.el: Replace the `org-link-types' variable with
  `org-link-types' function. Create `org-link-get-parameter' and
  `org-link-set-parameters' functions. Remove `org-add-link-type'. Add
  `org-store-link-functions' function and remove
  `org-store-link-functions' variable. Add `org--open-file-link' for use
  as a :follow function for file type links.

* lisp/org.el: Set :follow functions for file links in `org-link-parameters.
Define `org-open-file-link' that opens a file link with an app.

* testing/lisp/test-ox.el: Remove usage of the `org-link-types'
  variable.

* lisp/org-compat.el: Move `org-add-link-type' and mark it as obsolete.

* lisp/ox.el: Change org-add-link-type comment in ox.el.
---
 lisp/org-compat.el  |  31 +
 lisp/org-element.el |   4 +-
 lisp/org.el | 167 
 lisp/ox.el  |   2 +-
 testing/lisp/test-ox.el |  16 ++---
 5 files changed, 155 insertions(+), 65 deletions(-)

diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 92fdb1c..a856ff7 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -374,6 +374,37 @@ Implements `define-error' for older emacsen."
 (put name 'error-conditions
 	 (copy-sequence (cons name (get 'error 'error-conditions))
 
+(defun org-add-link-type (type  follow export)
+  "Add a new TYPE link.
+FOLLOW and EXPORT are two functions.
+
+FOLLOW should take the link path as the single argument and do whatever
+is necessary to follow the link, for example find a file or display
+a mail message.
+
+EXPORT should format the link path for export to one of the export formats.
+It should be a function accepting three arguments:
+
+  paththe path of the link, the text after the prefix (like \"http:\")
+  descthe description of the link, if any
+  format  the export format, a symbol like `html' or `latex' or `ascii'.
+
+The function may use the FORMAT information to return different values
+depending on the format.  The return value will be put literally into
+the exported file.  If the return value is nil, this means Org should
+do what it normally does with links which do not have EXPORT defined.
+
+Org mode has a built-in default for exporting links.  If you are happy with
+this default, there is no need to define an export function for the link
+type.  For a simple example of an export function, see `org-bbdb.el'.
+
+If TYPE already exists, update it with the arguments.
+See `org-link-parameters' for documentation on the other parameters."
+  (org-link-add type :follow follow :export export) 
+  (message "Created %s link." type))
+
+(make-obsolete 'org-add-link-type "org-link-add." "Org 9.0")
+
 (provide 'org-compat)
 
 ;;; org-compat.el ends here
diff --git a/lisp/org-element.el b/lisp/org-element.el
index 269bc7d..9452641 100644
--- 

[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-18 Thread Kaushal Modi
I use org-capture heavily, but I do not use a template that causes this
issue.

This issue was posted once again today on the org mailing list and I would
vote for this to be made a blocking bug too.

One useful update we get from Eric Fraga (
http://thread.gmane.org/gmane.emacs.orgmode/108289 ) is that this bug is
seen only after 25.0.94 pretest.

@Eric Would it be possible for you to provide a recipe to recreate this
issue from an emacs -Q session?
-- 

Kaushal Modi


Re: [O] error in capture

2016-07-18 Thread Eric S Fraga
On Monday, 18 Jul 2016 at 13:31, Aaron Ecay wrote:
> Hi Eric,
>
> It’s a known bug in recent versions of org and/or emacs.  No one knows
> exactly what triggers the problem yet, and it’s being discussed in the
> emacs bug tracker .

Thanks.  I hadn't seen anything on the list but had not thought to check
the emacs bug reports.

I've downgraded my Emacs back to 25.0.94 and everything is fine now.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.94.1, Org release_8.3.4-1049-g481709



Re: [O] error in capture

2016-07-18 Thread Aaron Ecay
Hi Eric,

It’s a known bug in recent versions of org and/or emacs.  No one knows
exactly what triggers the problem yet, and it’s being discussed in the
emacs bug tracker .

-- 
Aaron Ecay



[O] error in capture

2016-07-18 Thread Eric S Fraga
Hello,

I have just updated my org from git (because I also updated Emacs) and
now get this error when trying to capture:

Debugger entered--Lisp error: (error "Capture template ‘t’: Match data 
clobbered by buffer modification hooks")
  signal(error ("Capture template ‘t’: Match data clobbered by buffer 
modification hooks"))
  error("Capture template `%s': %s" "t" "Match data clobbered by buffer 
modification hooks")
  org-capture(nil)
  funcall-interactively(org-capture nil)
  call-interactively(org-capture nil nil)
  command-execute(org-capture)

Any suggestions of what to look for?  My capture templates have all been
working just fine for a very long time now...  This particular template
has not changed in years:

("t" "todo" entry (file+datetree "~/s/notes/tasks.org")
 "* TODO %^{Task} %^G\nSCHEDULED: %t\n%i%?")

thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.95.1, Org release_8.3.4-1049-g481709



[O] bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)

2016-07-18 Thread Robert Pluim
(I'm moving this discussion to the bug, let me know if that's not OK)

Eli Zaretskii  writes:

>> From: Alex Bennée 
>> Cc: Eli Zaretskii , "N. Jackson" , 
>> emacs-de...@gnu.org
>> Date: Sun, 17 Jul 2016 18:28:36 +0100
>> 
>> I've just uninstalled the ELPA installed org and run into the same
>> problem with the bundled version. It certainly doesn't happen with all
>> my capture templates but this particular entry with %a and %c does
>> trigger the error. From my *Messages:
>> 
>> Clipboard pasted as level 2 subtree
>> org-capture: Capture template ‘g’: Match data clobbered by buffer 
>> modification hooks
>> "/home/alex/src/emacs/install/share/emacs/25.0.95/lisp/org/org.elc"
>
> Can you come up with a reproducible recipe, starting with "emacs -Q",
> and then loading everything required for the reproduction?  Otherwise,
> I don't see how this problem could be resolved, given the sadly small
> number of people on board who are capable of debugging such problems.
>

Make sure that you have org-20160704 from elpa.

# emacs -Q

;evaluate the following 
(custom-set-variables
 '(package-selected-packages
   (quote
(org-20160704
(package-initialize)

; Now do:

C-x C-f ~/.notes
M-x org-mode
M-x org-capture
t

; This should result in:
Capture template ‘t’: Match data clobbered by buffer modification
hooks

I've tried to follow who clobbers it via GDB, but I keep getting
lost. For me it's always search_regs.end[sub] that has the unexpected
value.

Regards

Robert





Re: [O] links-9.0 v3

2016-07-18 Thread Nicolas Goaziou
John Kitchin  writes:

> What do you think of this approach:
>
>  (defcustom org-link-parameters
> -  '(("file"  :complete 'org-file-complete-link)
> -("file+emacs" :follow (lambda (path) (org-open-file path '(4
> -("file+sys" :follow (lambda (path) (org-open-file path 'system)))
> +  '(("file"  :complete #'org-file-complete-link)
> +("file+emacs" :follow (lambda (path) (org-open-file-link path '(4
> +("file+sys" :follow (lambda (path) (org-open-file-link path 'system)))

It could work, but I suggest to rename it `org--open-file-link' or some
such, i.e., make it an internal function, because it could be confusing
with `org-open-link-from-string'.

>  ("http") ("https") ("ftp") ("mailto")
>  ("news") ("shell") ("elisp")
>  ("doi") ("message") ("help"))
> @@ -10732,6 +10732,30 @@ they must return nil.")
>  
>  (defvar org-link-search-inhibit-query nil) ;; dynamically scoped
>  (defvar clean-buffer-list-kill-buffer-names) ; Defined in midnight.el
> +
> +(defun org-open-file-link (path app)
> +  "Open PATH using APP.
> +
> +PATH is from a file link, and can have the following

missing "syntax"?

> + [[file:~/code/main.c::255]]
> + [[file:~/xx.org::My Target]]
> + [[file:~/xx.org::*My Target]]
> + [[file:~/xx.org::#my-custom-id]]
> + [[file:~/xx.org::/regexp/]]
> +
> +APP is '(4) to open the PATH in Emacs, or 'system to use a system 
> application."
> +  (let* ((fields (split-string path "::"))  
> +  (option (when (cdr fields)
> +(mapconcat 'identity (cdr fields) ""

(and (cdr field)
 (mapconcat #'identity (cdr fields) ""))
 
> +(apply #'org-open-file
> +(car fields)
> +app
> +(cond ((not option) nil)
> +  ((org-string-match-p "\\`[0-9]+\\'" option)

org-string-match-p -> string-match-p


Regards,



Re: [O] how to speed up an org-mode file?

2016-07-18 Thread Sharon Kimble
Nicolas Goaziou  writes:

> Hello,
>
> Sharon Kimble  writes:
>
>> I'm working on an org-mode file about cancer which is 945.1kb, is
>> converted to a tex file of 1.0mb and a pdf of 2.0mb with 505 pages. The
>> conversion is done through this code snippet '(global-set-key (kbd
>> "s-#") 'org-latex-export-to-latex)'. There is no problem with the
>> conversion to tex or conversion to pdf.
>>
>> However, the org-mode file is increasingly slowing down and becoming
>> difficult to move about within the file, and also enter new information
>> within it.
>>
>> How then can I speed it up within the org file please?
>
> It would help to have some profiling to determine where the bottleneck
> is. You could use `elp-instrument-package' on "org-" prefix and report
> results here.

What I've done has been to split the cancer file up into 2, cancer.org
being 445k, and cancer-1.org being 544k. I initially had misgivings
about it with regard to footnotes, but they seem to be working okay, and
both files are now very easy to add to and also move around in.

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
Debian 8.4, fluxbox 1.3.7, emacs 25.0.95


signature.asc
Description: PGP signature


Re: [O] links-9.0 v3

2016-07-18 Thread Nicolas Goaziou
Hello,

John Kitchin  writes:

> Here are my current suggestions for the org-link 9.0.

Thank you.

> Let me know what the best way to send these might be. It looks like it
> might be 21 patches right now.

AFAIU, many among them introduce code that no longer exists in the final
draft. It would be nice to make them disappear, using interactive
rebasing, as suggested earlier in this thread.

If that's not possible, just send them over here, I'll apply them.

BTW sent patch doesn't seem to include an option handler. Am I missing 
something?

Regards,

-- 
Nicolas Goaziou



Re: [O] Clocking without timestamp

2016-07-18 Thread Sanel Zukan
Nicolas Goaziou  writes:
> This syntax isn't valid. Actually it is rather unexpected that it was
> producing something meaningful before.
>
> CLOCK lines require at least a time-stamp.

Didn't know about this. Thanks!

> Regards,
>
> -- 
> Nicolas Goaziou

Best,
Sanel


pgp1_xfrmhjM3.pgp
Description: PGP signature


Re: [O] Struggling with setting up ox-koma-letter.el

2016-07-18 Thread Rasmus
Hi,

Sorry about the slow reply.

nljlistb...@gmail.com (N. Jackson) writes:

> At 16:09 -0300 on Sunday 2016-06-26, N. Jackson wrote:
>
>> I am trying to get ox-koma-letter.el working in my Emacs (25.0.95).
>>
>> I have been following the instructions at
>> http://orgmode.org/worg/exporters/koma-letter-export.html and I am
>> testing with the "A simple letter example"
>> (http://orgmode.org/cgit.cgi/worg.git/plain/exporters/koma-letter-new-example.org).
>>
>> My org and my ox-koma-letter.el are from the Org Elpa org-plus-contrib
>> package (version 20160620) and are located in
>> ~/.emacs.d/elpa/org-plus-contrib-20160620/.
>
> After the version 20160627 update came down, I no longer get any error
> messages on export, which is great.
>
> However, the PDF generated by the exporter isn't quite right. Some of
> the problems with it are likely due to my LaTeX setup (page size etc.)
> and I'm investigating those, and some might be flaws in
> koma-letter-new-example.org, but I think I still don't have
> ox-koma-letter.el properly configured yet.
>
> For example, it seems to not be recognising the "location" headline and
> hence it is treating it as the first undefined headline in the file and
> is using it as the salutation.

Perhaps you are not using the most recent version?  The ELPA version would
be the "maint" version, I guess.

Could you try the master version?

  
http://orgmode.org/cgit.cgi/org-mode.git/tree/contrib/lisp/ox-koma-letter.el

Thanks,
Rasmus

-- 
I feel emotional landscapes they puzzle me




Re: [O] Struggling with setting up ox-koma-letter.el

2016-07-18 Thread Robert Klein
Hi,

On Tue, 28 Jun 2016 10:03:18 -0300
nljlistb...@gmail.com (N. Jackson) wrote:

> At 16:09 -0300 on Sunday 2016-06-26, N. Jackson wrote:
> 
> > I am trying to get ox-koma-letter.el working in my Emacs (25.0.95).
> >
> > I have been following the instructions at
> > http://orgmode.org/worg/exporters/koma-letter-export.html and I am
> > testing with the "A simple letter example"
> > (http://orgmode.org/cgit.cgi/worg.git/plain/exporters/koma-letter-new-example.org).
> >
> > My org and my ox-koma-letter.el are from the Org Elpa
> > org-plus-contrib package (version 20160620) and are located in
> > ~/.emacs.d/elpa/org-plus-contrib-20160620/.
> 
> After the version 20160627 update came down, I no longer get any error
> messages on export, which is great.
> 
> However, the PDF generated by the exporter isn't quite right. Some of
> the problems with it are likely due to my LaTeX setup (page size etc.)
> and I'm investigating those, and some might be flaws in
> koma-letter-new-example.org, but I think I still don't have
> ox-koma-letter.el properly configured yet.
> 
> For example, it seems to not be recognising the "location" headline
> and hence it is treating it as the first undefined headline in the
> file and is using it as the salutation.
> 
> My .PDF output file is attached for comparison with the correct one at
> http://orgmode.org/cgit.cgi/worg.git/plain/exporters/koma-letter-new-example.pdf.
> 
> Any suggestions?

afaik the elpa version is the maintenance version of 8.3.4.

The example looks fine when using the develpoment version of org
(i.e. master branch of the git repository).

Best regards
Robert