[O] org-agenda-log-mode omits some items from LOGBOOK drawers

2019-01-16 Thread N. Jackson


In Org Agenda, `C-u l', which IIUC is supposed to "show all possible
log items, not only the ones configured in
`org-agenda-log-mode-items'" shows clocking of work, closing of
entries, and other state changes of entries (tagged in the agenda
with "Clocked", "Closed", and "State" respectively).

That is very useful. However, note entries in the LOGBOOK drawer
(created with org-add-note) are unfortunately omitted.

Also, all my LOGBOOK drawers contain a CREATED inactive time stamp
(placed there by my capture templates), but these CREATED entries
are also omitted.

Am I doing something wrong? Are these other entries from the LOGBOOK
drawer expected to be included in the Agenda with `C-u l' -- I
realise that "all possible log items" is not the same as "all log
items", but it isn't clear why it wouldn't be possible!






[O] Feature request: Numeric prefix argument for org-move-item-up/down

2018-08-10 Thread N. Jackson
It would be nice if org-move-item-up (and org-move-item-down) took
a numeric prefix argument to specify how many times to move the
item up (or down).

I was surprised that this is missing and I'm guessing there might
be a good reason for that? Otherwise, I think this would be a
useful addition.

Thanks,
N.




Re: [O] Capture broken with org-plus-contrib-20170917

2017-09-21 Thread N. Jackson
Hi Josiah,

At 09:48 -0700 on Thursday 2017-09-21, Josiah Schwab wrote:

> Have you looked at the incompatible changes described in the
> release notes?

No, I hadn't. This is the downside of having the convenience of a
package manager in Emacs rather than installing things manually --
one neglects to read the release notes!

> I believe this change (and the migration) are described in
> "org-capture-templates no longer accepts S-expressions as file
> names".

Indeed. You are quite right, that explains the problem exactly.

> Hope that helps,

Yes it did, thank you. Thanks for the quick answer.

I have now bitten the bullet and "fixed" all my capture templates.
One advantage of this is that they are now slightly easier to
read!

N.




[O] Capture broken with org-plus-contrib-20170917

2017-09-21 Thread N. Jackson
After an Emacs package update a few days ago, my Org captures no
longer work. This is with org-plus-contib-20170917 from
http://orgmode.org/elpa/.

After I select a capture template to run, I get the error message

  Invalid file location: nil

and setting debug-on-error I see this:

  Debugger entered--Lisp error: (error "Invalid file location: nil")
signal(error ("Invalid file location: nil"))
error("Invalid file location: %S" nil)
org-capture-expand-file((concat org-directory "/notes.org"))
org-capture-target-buffer((concat org-directory "/notes.org"))
org-capture-set-target-location()
org-capture(nil)
funcall-interactively(org-capture nil)
call-interactively(org-capture nil nil)
command-execute(org-capture)

. Checking the value returned by the concat,

  M-: (concat org-directory "/notes.org")

the correct value

  "/data/org/notes.org"

is returned. This is the correct file and it exists etc..

There have been no changes to my org configuration since June of
2016 and I have had no problem with my captures until the latest
Emacs package update.

An example of the capture templates that are suddenly failing is
this one:

  (setq org-capture-templates
  '(
  ("n"
   "Note"
   ;; This one is a bit ugly. I see the guts of the template while the 
prompt is displayed. Also the PROPERTIES drawer is after the LOGBOOK instead of 
before.
   entry (file (concat org-directory "/notes.org"))
   "* %^{Enter Note Title}%^g\n   :PROPERTIES:\n   :Created:  %U\n  
 :END:\n\n%?\n%i\n"
   :kill-buffer t :empty-lines 1 :clock-in t :clock-resume t)
  )
  )

I found a work-around, in that if I change the `entry' line of the
capture template to read

  entry (file "notes.org")

the capture works again (taking advantage of what I assume must be
a new(ish) feature that org-directory is automatically used when
the file name in the capture template is unqualified).

Is this problem a new bug in Org, or is it simply that my capture
templates are wrong and that they've only worked all these years
by some accident?

If my capture templates are valid, then I would much rather see
Org put back the way it was so that they work, rather than have to
go through the error-prone process of having to edit them all (I
have dozens of them).

Thank you and best regards,
N.





[O] bug#23917: Re: bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out

2016-07-22 Thread N. Jackson
At 21:08 -0400 on Thursday 2016-07-21, npost...@users.sourceforge.net wrote:

> I made the same adjustments to the saved sub_start and sub_end
> variables, but I had a mistake in that adjustment which caused the false
> positives.  Fixed in the attached v2 patch.  We could just drop the
> check, though I've already found it useful to catch bugs
> (https://github.com/joaotavora/yasnippet/issues/720).
>
> If I drop the checks (see attached v3 patch), then after following the
> bug#23869 recipe, I get:
>
> ## -*- Octave -*-
> -module(bug).
> -export([identity/1, is_even/1, size/1, reverse/1]).

Thanks Noam,

Both the v2 and the v3 patch work for me with all my Org captures under
my full config, and with the simple recipe under `emacs -Q".

I'm not familiar with the details of the bug or the patches, but turning
off checks doesn't sound right, so I've stayed with the v2 patch.

I am now running the v2 patch as my every day Emacs.

FWIW, my versions of Emacs and Org are:

GNU Emacs 25.0.95.15 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
 of 2016-07-22 built on moondust
Repository revision: 4157159a37b43712440da91a45a6d5f71eb96e8a

and 

Org-mode version 8.3.5 (8.3.5-elpa @ /home/nlj/.emacs.d/elpa/org-20160719/)

.





[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out

2016-07-21 Thread N. Jackson
At 10:19 +0200 on Thursday 2016-07-21, Robert Pluim wrote:
>
> nljlistb...@gmail.com (N. Jackson) writes:
>
>> At 20:56 -0400 on Wednesday 2016-07-20, npost...@users.sourceforge.net wrote:
>>>
>>> From: Noam Postavsky <npost...@gmail.com>
>>> Subject: [PATCH v1] Adjust match data before calling after-change-funs
>>
>> It puzzles me that your patch doesn't work for the emacs -Q recipe but
>> does work for my normal configuration, so much so that I suspected that
>> I had made a mistake, but I have reset and reapplied the patch three
>> times and I continue to see the same results.
>
> You're not alone: this patch doesn't fix the issue for me either with
> emacs -Q or with my normal capture templates.

FWIW, taking into account that I needed to rebuild Org Mode using the
patched Emacs, I redid my tests of Noam's patch and got the same
puzzling results as before. That is the patch *does* fix the problem for
me with my normal caputure templates, but it does not fix the problem
with the simple recipe in emacs -Q.

N.





[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out

2016-07-21 Thread N. Jackson
At 10:08 +0200 on Thursday 2016-07-21, Robert Pluim wrote:
>>
> nljlistb...@gmail.com (N. Jackson) writes:
>
>> At 21:09 +0300 on Monday 2016-07-18, Eli Zaretskii wrote:
>>
>>> 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,
>>
>> FWIW on my system applying this patch does not resolve the org-capture
>> issue. I'm testing with org-20160718 from GNU Elpa and latest Emacs 25
>> branch from the git (Repository revision: 
>> 4157159a37b43712440da91a45a6d5f71eb96e8a).
>
> save-match-data is a macro. Did you recompile org with the modified
> emacs?

Thanks Robert. I failed to take that into account.

After re-applying Eli's patch above and then rebuilding Org Mode from
GNU Elpa (now org-20160719), the org-capture match-data-clobbered
error/abort no longer occurs, neither with the simple recipe in emacs -Q
nor with my own capture templates with my full config loaded.

Sorry for the noise.

[For completeness, I should say that I then removed the patch and
rebuilt org-20160719 again, and confirmed that it does trigger the bug
in both emacs -Q and with my configuration.]

N.






[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out

2016-07-21 Thread N. Jackson
At 20:56 -0400 on Wednesday 2016-07-20, npost...@users.sourceforge.net wrote:
>
> From a8098080dff5f83f7cbcbec2bc263f9db3b45ad9 Mon Sep 17 00:00:00 2001
> From: Noam Postavsky 
> Date: Wed, 20 Jul 2016 20:15:14 -0400
> Subject: [PATCH v1] Adjust match data before calling after-change-funs
>
> * src/insdel.c (replace_range): Add new parameter ADJUST_MATCH_DATA, if
> true.  Update all callers except Freplace_match to pass 0 for the new
> parameter.
> * src/search.c (update_search_regs): New function, extracted from
> Freplace_match.
> (Freplace_match): Remove match data adjustment code, pass 1 for
> ADJUST_MATCH_DATA to replace_range instead.
> ---
>  src/cmds.c|  2 +-
>  src/editfns.c |  6 +++---
>  src/insdel.c  | 10 --
>  src/lisp.h|  4 +++-
>  src/search.c  | 50 +-
>  5 files changed, 44 insertions(+), 28 deletions(-)
>
> diff --git a/src/cmds.c b/src/cmds.c
> index 1e44ddd..4003d8b 100644
> --- a/src/cmds.c
> +++ b/src/cmds.c
> @@ -447,7 +447,7 @@ internal_self_insert (int c, EMACS_INT n)
> string = concat2 (string, tem);
>   }
>  
> -  replace_range (PT, PT + chars_to_delete, string, 1, 1, 1);
> +  replace_range (PT, PT + chars_to_delete, string, 1, 1, 1, 0);
>Fforward_char (make_number (n));
>  }
>else if (n > 1)
> diff --git a/src/editfns.c b/src/editfns.c
> index 412745d..32c8bec 100644
> --- a/src/editfns.c
> +++ b/src/editfns.c
> @@ -3192,7 +3192,7 @@ DEFUN ("subst-char-in-region", Fsubst_char_in_region,
> /* replace_range is less efficient, because it moves the gap,
>but it handles combining correctly.  */
> replace_range (pos, pos + 1, string,
> -  0, 0, 1);
> +  0, 0, 1, 0);
> pos_byte_next = CHAR_TO_BYTE (pos);
> if (pos_byte_next > pos_byte)
>   /* Before combining happened.  We should not increment
> @@ -3405,7 +3405,7 @@ DEFUN ("translate-region-internal", 
> Ftranslate_region_internal,
> /* This is less efficient, because it moves the gap,
>but it should handle multibyte characters correctly.  */
> string = make_multibyte_string ((char *) str, 1, str_len);
> -   replace_range (pos, pos + 1, string, 1, 0, 1);
> +   replace_range (pos, pos + 1, string, 1, 0, 1, 0);
> len = str_len;
>   }
> else
> @@ -3446,7 +3446,7 @@ DEFUN ("translate-region-internal", 
> Ftranslate_region_internal,
>   {
> string = Fmake_string (make_number (1), val);
>   }
> -   replace_range (pos, pos + len, string, 1, 0, 1);
> +   replace_range (pos, pos + len, string, 1, 0, 1, 0);
> pos_byte += SBYTES (string);
> pos += SCHARS (string);
> cnt += SCHARS (string);
> diff --git a/src/insdel.c b/src/insdel.c
> index 4ad1074..fc3f19f 100644
> --- a/src/insdel.c
> +++ b/src/insdel.c
> @@ -1268,7 +1268,9 @@ adjust_after_insert (ptrdiff_t from, ptrdiff_t 
> from_byte,
>  /* Replace the text from character positions FROM to TO with NEW,
> If PREPARE, call prepare_to_modify_buffer.
> If INHERIT, the newly inserted text should inherit text properties
> -   from the surrounding non-deleted text.  */
> +   from the surrounding non-deleted text.
> +   If ADJUST_MATCH_DATA, then adjust the match data before calling
> +   signal_after_change.  */
>  
>  /* Note that this does not yet handle markers quite right.
> Also it needs to record a single undo-entry that does a replacement
> @@ -1279,7 +1281,8 @@ adjust_after_insert (ptrdiff_t from, ptrdiff_t 
> from_byte,
>  
>  void
>  replace_range (ptrdiff_t from, ptrdiff_t to, Lisp_Object new,
> -bool prepare, bool inherit, bool markers)
> +   bool prepare, bool inherit, bool markers,
> +   bool adjust_match_data)
>  {
>ptrdiff_t inschars = SCHARS (new);
>ptrdiff_t insbytes = SBYTES (new);
> @@ -1426,6 +1429,9 @@ replace_range (ptrdiff_t from, ptrdiff_t to, 
> Lisp_Object new,
>MODIFF++;
>CHARS_MODIFF = MODIFF;
>  
> +  if (adjust_match_data)
> +update_search_regs (from, to, from + SCHARS (new));
> +
>signal_after_change (from, nchars_del, GPT - from);
>update_compositions (from, GPT, CHECK_BORDER);
>  }
> diff --git a/src/lisp.h b/src/lisp.h
> index 6a98adb..25f811e 100644
> --- a/src/lisp.h
> +++ b/src/lisp.h
> @@ -3516,7 +3516,7 @@ extern void adjust_after_insert (ptrdiff_t, ptrdiff_t, 
> ptrdiff_t,
>ptrdiff_t, ptrdiff_t);
>  extern void adjust_markers_for_delete (ptrdiff_t, ptrdiff_t,
>  ptrdiff_t, ptrdiff_t);
> -extern void replace_range (ptrdiff_t, ptrdiff_t, Lisp_Object, bool, bool, 
> bool);
> +extern void replace_range (ptrdiff_t, ptrdiff_t, Lisp_Object, bool, bool, 
> bool, bool);
>  extern 

[O] bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out

2016-07-21 Thread N. Jackson
At 21:09 +0300 on Monday 2016-07-18, Eli Zaretskii wrote:

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

FWIW on my system applying this patch does not resolve the org-capture
issue. I'm testing with org-20160718 from GNU Elpa and latest Emacs 25
branch from the git (Repository revision: 
4157159a37b43712440da91a45a6d5f71eb96e8a).

With these versions of Org and Emacs and your patch applied, with a
recipe similar to that posted by Robert Pluim on 2016-07-18,
specifically

  src/emacs -Q

  M-: (custom-set-variables '(package-selected-packages (quote 
(org-20160718 RET
  M-x package-initialize RET

  C-x C-f   ; find file.
  C-S-backspace ; kill-whole-line.
  ~/.notes RET  ; Open the file expected by default capture template.
  M-x org-mode RET  ; put the buffer into Org Mode.
  M-x org-capture RET t ; Run the default "Task" capture template bound to the 
t key.

I get the error: 

  org-capture: Capture template ‘t’: Match data clobbered by buffer 
modification hooks

. I also get a similar error with your patch and my full configuration
loaded and using my own capture templates:

  org-capture: Capture abort: (error Match data clobbered by buffer 
modification hooks)

.

The results above are same as I get if I do not apply your patch.

[On the other hand, with the same version of Org as above and Emacs from the
25.0.95 tarball, I do not see these error.]






[O] Bug: org-add-note closes log book drawer

2016-07-20 Thread N. Jackson
When org-log-into-drawer is t and the log book drawer is open, using
org-add-note closes the log book drawer.

I think it would be better if org-add-note left the state (open or
closed) of the log book drawer alone.

In comparison org-clock-in and org-clock-out do leave the state of the
log book drawer alone, which is much more satisfactory.

This is with org-20160718 from GNU Elpa (which is Org Mode version
8.3.4) on GNU Emacs 25.0.95 (from the pre-release tarball).




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] 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] Struggling with setting up ox-koma-letter.el

2016-06-28 Thread N. Jackson
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?

Thanks,
N.



koma-letter-test.pdf
Description: Example letter PDF output file


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

2016-06-28 Thread N. Jackson
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/.

I get an error message when I try to export the example letter using
`C-c C-e k p'. The message is

org-export-as: Wrong number of arguments: #[(templates)
"ŠebˆÆ^XÇÈÆÉ#…\\^@Ê ^YË !Ì=ƒX^@Í \"^[ÎÏ \"‰^\ ÎÐ
\"E‰^]ƒ<^@ÑÒÎÓ \"\"ˆ‚W^@ƒW^@^MB^PÎÔ
\"bˆÕÆxˆ`|ˆŠcˆ)+)‚^F^@*‡" [record object
templates value begin signature nil re-search-forward "{{{[-A-Za-z0-9_]"
t ...] 6 ("/data/projects/vc/emacs/emacs-25.0.95/lisp/org/org-macro.elc"
. 3784)], 3

I can't read this error message due to all the escaped characters, but I
do see a mention of an incorrect file. The org-macro.elc file mentioned
in the error message is the one built in to Emacs and it should be
hidden.

I have normal-looking load path shadows, with the the elpa version
hiding the version built in to Emacs (e.g. list-load-path-shadows shows
for example that ~/.emacs.d/elpa/org-plus-contrib-20160620/org-macro
hides /data/projects/vc/emacs/emacs-25.0.95/lisp/org/org-macro).

I would welcome any help with getting this working.

Thanks,
N.





Re: [O] Bug: File mode specification error opening Org file without headline on first line [8.3.4 (8.3.4-39-ge0acd8-elpa @ /home/nlj/.emacs.d/elpa/org-20160418/)]

2016-04-21 Thread N. Jackson
Thanks Kyle.

At 21:41 -0400 on Wednesday 2016-04-20, Kyle Meyer wrote:
>
> Based on your configuration dump, it seems like you're using outshine,

You are right. I had installed navi-mode (and its dependencies outshine
and outorg) a few months ago to try it out. I have removed them and the
problem is fixed. [FWIW, I had version 2.0 of all three files.]

Thank you, and sorry for the noise.

[I never found the time to actually try navi-mode; perhaps I'll have
some spare time in the future when I can re-install it and give it a
test drive.]

N.




[O] Bug: File mode specification error opening Org file without headline on first line [8.3.4 (8.3.4-39-ge0acd8-elpa @ /home/nlj/.emacs.d/elpa/org-20160418/)]

2016-04-20 Thread N. Jackson

For several months now I have been getting the error "File mode
specification error: (error Before first heading)" when I open some of
my Org files. [After the error message, the file opens just fine and Org
works normally.]

What distinguishes the Org files that do not suffer from this problem
from those that do is that they have a headline in the first line of
the file.

A fairly minimal recipe:

1. $ cat > ~/temp-org-test.org
An introduction.

* A Headline 

  Some text.

** Sub-Topic 1

** Sub-Topic 2

*** Additional entry
^D

2. $ emacs &

3. Visit ~/temp-org-test.org

At this point the error message "File mode specification error: (error
Before first heading)" is displayed.

Note: This test file is from
http://orgmode.org/worg/dev/org-syntax.html.

Setting debug-on-error, I get the following backtrace:

Debugger entered--Lisp error: (error "Before first heading")
  signal(error ("Before first heading"))
  error("Before first heading")
  outline-back-to-heading()
  outline-flag-subtree(t)
  hide-subtree()
  (save-excursion (goto-char (point-min)) (hide-subtree) (show-children 
keep-levels) (condition-case err (while (outline-get-next-sibling) 
(hide-subtree) (show-children keep-levels)) (error nil)))
  outline-hide-sublevels(1)
  org-overview()
  org-content()
  org-set-startup-visibility()
  org-mode()
  set-auto-mode-0(org-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(# "~/temp-org-test.org" 
nil nil "~/temp-org-test.org" (801256 64773))
  find-file-noselect("/home/nlj/temp-org-test.org" nil nil nil)
  find-file("/home/nlj/temp-org-test.org")

On the other hand, if I edit the test file and add a headline on the
first line of the file, for example

* COMMENT This is dummy headline

then the error does not occur. Of course, this seems a rather ugly
work-around.


Emacs  : GNU Emacs 25.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
 of 2016-04-18
Package: Org-mode version 8.3.4 (8.3.4-39-ge0acd8-elpa @ 
/home/nlj/.emacs.d/elpa/org-20160418/)

current state:
==
(setq
 org-export-backends '(ascii beamer html icalendar latex odt)
 org-tab-first-hook '(org-hide-block-toggle-maybe 
org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 outline-minor-mode-hook '(outshine-hook-function)
 org-speed-command-hook '(org-speed-command-default-hook 
org-babel-speed-command-hook)
 org-reverse-note-order t
 org-occur-hook '(org-first-headline-recenter)
 org-checkbox-hierarchical-statistics nil
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-agenda-start-on-weekday nil
 org-log-done t
 org-format-latex-options '(:foreground default :background default :scale 1.5
:html-foreground "Black" :html-background 
"Transparent"
:html-scale 1.0 :matchers ("begin" "$1" "$" "$$" 
"\\(" "\\["))
 org-confirm-shell-link-function 'yes-or-no-p
 org-finalize-agenda-hook '(nlj-agenda-to-appt)
 org-startup-folded 'content
 org-file-apps '((auto-mode . emacs) ("\\.mm\\'" . default) ("\\.x?html?\\'" . 
default)
 ("\\.pdf\\'" . "evince %s"))
 org-agenda-skip-scheduled-if-done t
 org-support-shift-select 'always
 org-default-notes-file "/data/org//notes.org"
 org-capture-templates '(("t" "Todo" entry
  (file+headline (concat org-directory 
"/organiser.org") "Todos")
  "* TODO %?\n:LOGBOOK:\n  CREATED: %U\n:END:\n%i\n" 
:prepend t
  :kill-buffer t :empty-lines 1)
 ("e" "Event" entry
  (file+headline (concat org-directory 
"/organiser.org") "Events")
  "* %?\n:LOGBOOK:\n  CREATED: %U\n:END:\n%i\n" 
:kill-buffer t
  :empty-lines 1)
 ("a" "Appointment" entry
  (file+headline (concat org-directory "/organiser.org")
   "Appointments")
  "* APPT %?\n:LOGBOOK:\n  CREATED: %U\n:END:\n%i\n" 
:kill-buffer t
  :empty-lines 1)
 ("l" "Log" plain (file (concat org-directory 
"/log.org"))
  "* %U\n\n%?\n%i\n" :kill-buffer t :empty-lines 1 
:clock-in t
  :clock-resume t)
 ("n" "Note" entry
  (file+headline (concat org-directory "/notes.org") 
"Notes")
  "* %^{Enter Note Title}%^g\n   :PROPERTIES:\n   
:Created:  %U\n   :END:\n\n%?\n%i\n" :kill-buffer t :empty-lines 1 :clock-in t 
:clock-resume t)
 ("o" "Old-style Dated Note" entry
  (file+headline (concat org-directory "/notes.org") 
"Dated Notes")
  "* %U\n%?\n%i\n" :kill-buffer t :empty-lines 1 
:clock-in t
  

[O] bug#5753: something, something, org-mode, shift-select, something

2014-02-11 Thread N. Jackson
The following message is a courtesy copy of an article
that has been posted to gnu.emacs.bug as well.

Lars Ingebrigtsen la...@gnus.org writes:

 Lennart Borgman lennart.borg...@gmail.com writes:

 Shift-select in cua-mode does not work in org-mode although
 org-replace-disputed-keys is t, org-disputed-keys are set for shift
 arrow keys and org-support-shift-select is always

 Is this problem still present in Emacs 24.3?

Naturally I can't answer for the OP (and I don't know about disputed
keys) but I can report that in general this problem persists in Emacs
24.3.

On GNU Emacs 24.3.1 [1], shift select does not work in org mode. I'm not
certain this is a bug, as my understanding is that the org authors did
not design it to work with shift select?

In any case, I use a very simple workaround which makes shift select
work just fine in org mode; I've never had any problems with it. It
looks like this (Note: It is of unknown provenance, aside from the
attribution in the comment.):

;; This snippit from jisang-yoo on reddit to enable shift select in org
;; mode when cua-mode is on.
(eval-after-load org
'(progn
   (eval-after-load cua-base
 '(progn
(defadvice org-call-for-shift-select (before
org-call-for-shift-select-cua activate)
  (if (and cua-mode
   org-support-shift-select (not (use-region-p)))
  (cua-set-mark)))
;; End jisang-yoo snippit

With this in my org settings, I have no problems with shift select
except that you cannot start a selection on a timestamp (because shift
with cursor keys adjusts timestamps), but I've learnt to automatically
start my selection from the end of the line above the timestamp so I
don't have any problems.

I hope this information is of some use.

[1] GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2) of
2013-08-14 on buildvm-15.phx2.fedoraproject.org







[O] bug#5753: something, something, org-mode, shift-select, something

2014-02-11 Thread N. Jackson
This post is for the sake of completeness, and to summarise / add to my
previous posts on this bug, namely:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#17
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#35
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#41

In GNU Emacs 23.3.1 [1] and 24.3 [2], either of the settings

(setq org-support-shift-select t)

or

(setq org-support-shift-select (quote always))

will enable shift selection in org-mode, as described in

C-h v org-support-shift-select RET

_only if_ cua-mode is turned off. But if cua-made is turned on, shift
selection fails everywhere in org mode -- no selection gets made. Adding
the following workaround fixes the problem:

;; This snippet from jisang-yoo on reddit to enable shift select in org
;; mode when cua-mode is on.
(eval-after-load org
'(progn
   (eval-after-load cua-base
 '(progn
(defadvice org-call-for-shift-select (before
org-call-for-shift-select-cua activate)
  (if (and cua-mode
   org-support-shift-select (not (use-region-p)))
  (cua-set-mark)))
;; End jisang-yoo snippet

In GNU Emacs GNU Emacs 24.3.50.1 [3] org-support-shift-select works
essentially as documented, and the workaround is not required. :)

---

[1] GNU Emacs 23.3.1 (i386-mingw-nt5.1.2600) of 2011-03-10 on Windows XP
(5.1.2600) with Org-mode version 7.9.2 (7.9.2-48-gb7c5cf-elpa) of
2012-10-15.

[2] GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.8.2) of
2013-08-14 on Fedora 19 with Org-mode version 8.2.5h
(8.2.5h-6-g8e1386-elpa) of 2014-02-03.

[3] GNU Emacs 24.3.50.1 (Repository revision: 116400) of 2014-02-10 on
Fedora 19 and Org-mode version 8.2.5c (release_8.2.5c) of unknown date.






[O] bug#5753: something, something, org-mode, shift-select, something

2014-02-11 Thread N. Jackson
Bastien b...@altern.org writes:

 Can you try the two recipes I gave here:
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5753#26

Wherein Bastien bzg at gnu.org writes:

 With Emacs from trunk:

Ah, that sounds like the start of a new adventure...

... which went _far_ more smoothly than I expected! I am now testing
with GNU Emacs 24.3.50.1 Repository revision: 116400 and Org-mode
version 8.2.5c.

 ~$ emacs RET 
 C-x C-f test.org RET 
 M-x cua-mode RET 
 M-: (setq org-support-shift-select t) RET 
 M-: (insert blahblah) RET C-a
 S-right
 
 will select correctly here.
 
 ~$ emacs RET 
 M-: (setq org-support-shift-select t) RET 
 M-: (setq org-replace-disputed-keys t) RET 
 M-: (insert * A headline) RET 
 C-a
 S-right
 
 will also select correctly instead of switching the TODO keyword.

 and tell me where it does not produce the expected output?

The first recipe is ambiguous because M-x cua-mode RET toggles the
on/off or off/on state of cua-mode, so it depends on how it is set in
one's configuration files.

In any case, with both recipes, Org behaves correctly in 24.3.50.1. The
first recipe fails in 24.3.1 when cua-mode is not enabled in one's
configuration files (i.e. when you turn it on at the beginning of the
recipe).

Here's a simpler recipe:

emacs -Q 
M-: (org-support-shift-select t) RET 
M-x cua-mode RET; Turn _on_ cua mode 
C-x C-f new-test.org RET 
a 
S-left; Expected: a is selected / highlighted 
C-x ; Expected: a is removed to the clipboard

In Emacs 24.3.1 (as, I believe, in Emacs 23), the S-left just moves
the cursor, no selection is highlighted, and the C-x fails to remove the
a to the clipboard. This defect is fixed in Emacs 24.3.50.1. :)

As far as shift selection over headlines, todos, and datestamps is
concerned, in general, shift selection behaviour in Emacs 24.3.50.1
(unlike in Emacs 24.3.1) now seems to behave as it is described in the
doc string:

C-h v org-support-shift-select RET

as follows:

org-support-shift-select is a variable defined in `org.el'.  Its
value is always Original value was nil

Documentation: Non-nil means make shift-cursor commands select text
when possible.

In Emacs 23, when `shift-select-mode' is on, shifted cursor keys
start selecting a region, or enlarge regions started in this way.
In Org-mode, in special contexts, these same keys are used for other
purposes, important enough to compete with shift selection.  Org
tries to balance these needs by supporting `shift-select-mode'
outside these special contexts, under control of this variable.

The default of this variable is nil, to avoid confusing behavior.
Shifted cursor keys will then execute Org commands in the following
contexts:
- on a headline, changing TODO state (left/right) and priority
- (up/down) on a time stamp, changing the time in a plain list item,
- changing the bullet type in a property definition line, switching
- between allowed values in the BEGIN line of a clock table
- (changing the time block).
Outside these contexts, the commands will throw an error.

When this variable is t and the cursor is not in a special context,
Org-mode will support shift-selection for making and enlarging
regions.  To make this more effective, the bullet cycling will no
longer happen anywhere in an item line, but only if the cursor is
exactly on the bullet.

If you set this variable to the symbol `always', then the keys will
not be special in headlines, property lines, and item lines, to make
shift selection work there as well.  If this is what you want, you
can use the following alternative commands: `C-c C-t' and `C-c ,' to
change TODO state and priority, `C-u C-u C-c C-t' can be used to
switch TODO sets, `C-c -' to cycle item bullet types, and properties
can be edited by hand or in column view.

However, when the cursor is on a timestamp, shift-cursor commands
will still edit the time stamp - this is just too good to give up.

XEmacs user should have this variable set to nil, because
`shift-select-mode' is in Emacs 23 or later only.

You can customize this variable.

This is very very helpful stuff, clearly presented, and I feel it ought
to be in the info manual as well.

[The only part that I don't see working properly is the changing of
bullet types. As far as I can tell, this doesn't happen -- but it's not
something I've ever tried to do and maybe I'm not using it right.]

I just did a cursory look at the effect of org-replace-disputed-keys,
because I don't use this. Was an issue with this reported in the
original bug? If so, I can test it more thoroughly.

I hope the above report is of some use.

Regards,
N.






[O] bug#5753: something, something, org-mode, shift-select, something

2014-02-11 Thread N. Jackson
Bastien b...@gnu.org writes:

 can you tell me what exactly the bug is wrt cua-mode and org-mode?

Hi Bastien,

Well, I can tell you the symptoms; I'm sorry to report that I know
nothing of the internals.

I have this snippet of code in my configuration files and with it
everything works fine and has been working fine for a few years:

;; This snippet from jisang-yoo on reddit to enable shift select in
;; org mode when cua-mode is on.
(eval-after-load org
'(progn
   (eval-after-load cua-base
 '(progn
(defadvice org-call-for-shift-select (before
org-call-for-shift-select-cua activate)
  (if (and cua-mode
   org-support-shift-select (not
   (use-region-p)))
  (cua-set-mark)))
;; End jisang-yoo snippet

If I comment out that snippet and restart Emacs, then shift selection no
longer works in org-mode unless I turn off cua-mode.

When I say shift selection doesn't work, I mean that when I hold down
the shift key and move the cursor with the arrow keys I don't get any
highlighting of the text I'm trying to select. And it's not just a
failure to highlight the selection, there seems to be no selection
happening because a cut or copy of the imaginary selection doesn't do
anything.

If I toggle off cua-mode (from the menu for example), then shift
selection immediately starts working in org-mode. If I leave cua-mode
tuned on and M-x fundamental-mode, then shift selection immediately
starts working in the buffer with org file. That is to say, the symptoms
are simple and 100% reproducible.

 If the bug is here for Emacs 24.3, can you try downloading and
 installing the latest Org stable version (http://orgmode.org) and see
 if the bug is still there?

I am currently using Org-mode version 8.2.5h-6-g8e1386-elpa of
2014-02-03 on GNU Emacs 24.3.1. If you need me to try a newer version of
Org, I can do so, although I do prefer to use the version from Elpa as
it seems it would be easier to uninstall it if it breaks my Emacs.

 Thanks in advance for your help,

You're welcome. Please let me know if you need me to install the latest
Org stable version or do any specific testing.

N.






[O] bug#5753: something, something, org-mode, shift-select, something

2014-02-11 Thread N. Jackson
Bastien b...@gnu.org writes:

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

 Ah, that sounds like the start of a new adventure...

 ... which went _far_ more smoothly than I expected! I am now testing
 with GNU Emacs 24.3.50.1 Repository revision: 116400 and Org-mode
 version 8.2.5c.

 Yes, sorry, I meant emacs -Q in my recipes.

 I can't reproduce the bug with GNU Emacs 24.3.50.6, so it has probably
 been fixed between 24.3.50.1 and 24.3.50.6.

Bastien, you misunderstood what I wrote (sorry).

I _did_ build 24.3.50(.1) from the current (yesterday's) trunk from
Bazaar.

And, assuming the failure of shift selection in cua-mode _is_ the bug
the OP was reporting (I was never clear about that), then the bug _is_
fixed using that build, as I wrote here:

 In any case, with both recipes, Org behaves correctly in 24.3.50.1. 

and here:

 emacs -Q 
 M-: (org-support-shift-select t) RET 
 M-x cua-mode RET; Turn _on_ cua mode 
 C-x C-f new-test.org RET 
 a 
 S-left; Expected: a is selected / highlighted 
 C-x ; Expected: a is removed to the clipboard

 In Emacs 24.3.1 (as, I believe, in Emacs 23), the S-left just moves
 the cursor, no selection is highlighted, and the C-x fails to remove
 the a to the clipboard. This defect is fixed in Emacs 24.3.50.1. :)
 
 I'll close it when you have a chance to build Emacs from current
 trunk.

Lennart, I believe you were the original poster? Is the one above the
bug you intended to report? (I was confused by the discussion of
org-replace-disputed-keys, which doesn't seem to be a factor here.) And
if so, do you want to test on 24.3.50, or are you satisfied that the bug
is fixed?

 Thanks again for the detailed reports!

You're welcome, but clearly I need to improve my clarity! Thank you for
being there to do something about them.

Regards,
N.







Re: [O] Bug: org-indent-mode cursor movement [7.8.03]

2012-06-18 Thread N . Jackson
Update: This is now resolved (for me).

The jumping cursor behaviour I was seeing was either a problem with my 
installation of Version 7.8.11 org-20120611 or a bug in that version. 

Reverting to the built-in version (Version 6.33x) (by turning off 
the Emacs package manager) fixed the problem, and so did updating to 
Version 7.8.11 org-20120618 (from ELPA using the package manager). 







Re: [O] Bug: org-capture Does not take user to any new buffer

2012-06-18 Thread N . Jackson
Update: This is now resolved (for me).

The capture failures I was seeing (when the type was entry rather 
than plain) was either a problem with my installation of 
Version 7.8.11 org-20120611 or a bug in that version. 

Reverting to the built-in version of Org Mode (Version 6.33x) (by turning off 
the Emacs package manager) fixed the problem, and so did updating to 
Version 7.8.11 org-20120618 (from ELPA using the package manager). 





Re: [O] Bug: org-capture Does not take user to any new buffer

2012-06-15 Thread N . Jackson
 On Tue, Jun 5, 2012 at 9:07 AM, Mike Fitzgerald mikef656 at gmail.com 
wrote:

 I'm presented with an *Org Select* buffer that offers me the available 
choices 
 However, this part does not work as expected:when I select one of those I 
select one of those, I get a CAPTURE-foo.org bufferI would expect: A) new 
buffer would be created and B) EMACS would switch to it andC) Some message with 
value to the userB and C do not happen.  A happens but I need to manually 
switch 
to itI get a message that has little value:    Capture template `j': org-
called-interactively-pI have never used the working version of capture (this 
is 
it), but I have usedremember a little and seem to recall it gives a message 
something
 

I am seeing similar behaviour from Org Capture. That is:

- It doesn't open the buffer for the user to add text to the capture.

- A message byte-code: Capture template `t': org-called-interactively-p is 
displayed.

- The capture _does_ get written to the target file.

- However the capture written to the target file contains %? literally 
inserted into the entry.

 
 (setq org-log-done t)(setq org-capture-templates
   '((t Todo entry (file+headline ~/org/gtd.org Tasks)
 
  * TODO %?\n  %i\n  %a)
     (j Journal entry (file+datetree ~/org/journal.org)
  * %?\nEntered on %U\n  %i\n  %a)))

I'm using templates similar to these.

The main thing I can add, is that if I change entry to plain, Capture works 
just fine. (Of course, in many cases one wants entries, so this is not a 
solution.)

I'm using GNU Emacs 23.3.1 ((i386-mingw-nt5.1.2600) of 2011-03-10) and Org 
Version 20120611 (7.8.11) which I downloaded/installed with the Emacs package 
manager system.

I apologise if there is already a solution to this issue (I didn't see it), and 
I hope this additional information is helpful.

Regards,
N.

 
 ;org-capture binding 
 ;(global-set-key \C-c-c 'org-capture)(global-set-key [(control c) (c)] 'org-
capture)Does this look OK?
 ThanksMike 
 On Mon, Jun 4, 2012 at 10:56 PM, Nick Dokos nicholas.dokos at hp.com 
wrote:Mike Fitzgerald mikef656 at gmail.com wrote:
  To duplicate:
 
 I haven't tried specifically to duplicate your setup but org-capture
 seems to work fine here.
 
  1) Run org-capture with C-c c
  2) User is Promoted with the two templates expected 
  (copied the templates from the org-mode site)
 
  3) Enter j for journal
  4) Expect switch to new buffer
  5) No switch occurs
 So what happens instead? If I start capture, I get another window where
 I'm presented with an *Org Select* buffer that offers me the available
 choices and when I select one of those, I get a CAPTURE-foo.org buffer
 for some value of foo.  This is actually an indirect buffer and the
 text should be inserted into the target location already, so you can
 look at ~/org/journal.org (or whatever) and see that it contains the
 partial entry just started.  See the description of org-capture: C-h f
 org-capture RET.
 If I were you, I'd probably use edebug to step through the org-capture
 function (and I'd forget about byte compiling anything until whatever
 problem you have is identified and solved).
 HTH,
 Nick
 
  Note that journal.org is open, but I need to switch to it
 
  I expected EMACS to switch to a new buffer after choosing
  the template.
 
  Running GNU EMACS 23.3 on Win7
 
  Org mode update byte compiled by hand (without make) using
   
     (defun my/compile-org(optional directory)
   Compile all *.el files that come with org-mode.
       (interactive)
     ;Found on a org-mode related page.
 
  Thanks
 
  Mike
 
  Remember to cover the basics, that is, what you expected to happen and
  what in fact did happen.  You don't know how to make a good report?  See
 
   http://orgmode.org/manual/Feedback.html#Feedback
 
  Your bug report will be posted to the Org-mode mailing list.
  
 
  Emacs  : GNU Emacs 23.3.1 (i386-mingw-nt6.1.7600)
   of 2011-03-10 on 3249CTO
  Package: Org-mode version 7.8.11
 
  current state:
  ==
  (setq
   org-log-done 'time
   org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
   org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-
command-hook)
   org-metaup-hook '(org-babel-load-in-session-maybe)
   org-capture-templates '((t Todo entry (file+headline ~/org/gtd.org 
Tasks)
                * TODO %?\n  %i\n  %a)
               (j Journal entry (file+datetree ~/org/journal.org)
                * %?\nEntered on %U\n  %i\n  %a)
               )
   org-after-todo-state-change-hook '(org-clock-out-if-current)
   org-export-latex-format-toc-function 'org-export-latex-format-toc-default
   org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-
command-maybe
            org-babel-hide-result-toggle-maybe)
   org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-
configure-edit-buffer)
   

Re: [O] Bug: org-indent-mode cursor movement [7.8.03]

2012-06-13 Thread N . Jackson
Andrew Stine illuminati1113 at gmail.com writes:
 
 When org-indent-mode is active, the cursor repeatedly jumps to the
 bottom of the buffer. This makes using the buffer impossible while
 org-indent-mode is active.
 

I am experiencing the same behaviour (cursor jumping to the end of the buffer 
whenever I try to move it). This happens when I have 

#+STARTUP: indent

in an org-mode file.

Editing the file in Fundamental Mode and removing the #+STARTUP: indent line 
from the file (and switching back to Org Mode), fixes the problem.

I am using Org-mode version 7.8.11 with GNU Emacs 23.3.1 
(i386-mingw-nt5.1.2600).