[O] Bug: org-agenda-skip-scheduled-if-deadline-is-shown is ignored [8.3.6 (release_8.3.6-1226-ge4d4c6 @ /home/luke/elisp/org-mode/lisp/)

2016-10-17 Thread Luke 
Setting org-agenda-skip-scheduled-if-deadline-is-shown to a non-nil 
value in a custom agenda command seems to have no effect. Items that 
were scheduled three days ago and have a deadline yesterday still appear 
twice in the agenda.


If I checkout tags/release_8.3.6 this bug does not seem to appear (the 
"Scheduled" entry is missing from the agenda, as expected). I'm guessing 
it's been introduced since then.



Emacs  : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-04-17 on lgw01-04, modified by Debian
Package: Org mode version 8.3.6 (release_8.3.6-1226-ge4d4c6 @ 
/home/.../elisp/org-mode/lisp/)

Re: [O] Bug: Agenda: Sorting TODOs (with tags) by effort does not work [8.3.6 (8.3.6-7-g4d7d52-elpaplus @ /home/luke/.emacs.d/elpa/org-plus-contrib-20161010/)]

2016-10-17 Thread Luke 

On 17/10/16 16:47, Nicolas Goaziou wrote:

Hello,

Luke  writes:


On 16/10/16 20:32, Nicolas Goaziou wrote:

Fixed. Thank you.


Thanks for that. Unfortunately, it doesn't seem to fix the issue
I reported.


Are you using development version? The fix landed there.

Regards,



My apologies, I incorrectly thought that the org-mode.org/elpa archive 
tracked the development version.


After using the git archive instead, everything seems to work correctly. 
Thanks!

Re: [O] org-special-ctrl-a/e no longer has the expected effect

2016-10-17 Thread Nicolas Goaziou 
Hello,

Matt Lundin  writes:

> Commit 8d2f0a441174c703ed0ed570e2f0eaf0da5d6aeb broke the expected
> behavior org-beginning-of-line.
>
> Steps to reproduce:
>
> (setq org-special-ctrl-a/e '(nil . t)) ;; i.e., I want special
>;; treament of the end of a
>;; headline but not the
>;; beginning 
>
> * A headline
> ^ cursor initially here
>
> Press C-a
>
> Expected behavior:
>
> * A headline
> ^ cursor moves here
>
> Actual behavior:
>
> * A headline
>   ^ cursor moves here
>
> This behavior is not what one would expect from the docstring of
> org-special-ctrl-a/e.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] org-special-ctrl-a/e no longer has the expected effect

2016-10-17 Thread Matt Lundin 
Commit 8d2f0a441174c703ed0ed570e2f0eaf0da5d6aeb broke the expected
behavior org-beginning-of-line.

Steps to reproduce:

(setq org-special-ctrl-a/e '(nil . t)) ;; i.e., I want special
   ;; treament of the end of a
   ;; headline but not the
   ;; beginning 

* A headline
^ cursor initially here

Press C-a

Expected behavior:

* A headline
^ cursor moves here

Actual behavior:

* A headline
  ^ cursor moves here

This behavior is not what one would expect from the docstring of
org-special-ctrl-a/e.

Thanks,
Matt

[O] A few more questions

2016-10-17 Thread Peter Davis 
I'm still trying to get a clear path from org-mode to DocBook, and I
have a few remaining obstacles. Any suggestions appreciated.

1) Is there any way to export syntax-highlighted source code as an SVG
or other graphics format? Converting to DocBook via texi, I lose all the
great syntax highlighting that makes the code snippets so much easier to
read.

2) Is there any way to include tables whose cells contain long lines of
text that should wrap? I can get this by manually breaking the text
across multiple rows of the table, and then re-editing in the HTML or
XML, but sheesh, that's a lot of work.

Thank you!

-pd


-- 
  Peter Davis
  www.techcurmudgeon.com

Re: [O] Bug: Agenda: Sorting TODOs (with tags) by effort does not work [8.3.6 (8.3.6-7-g4d7d52-elpaplus @ /home/luke/.emacs.d/elpa/org-plus-contrib-20161010/)]

2016-10-17 Thread Nicolas Goaziou 
Hello,

Luke  writes:

> On 16/10/16 20:32, Nicolas Goaziou wrote:
>> Fixed. Thank you.
>
> Thanks for that. Unfortunately, it doesn't seem to fix the issue
> I reported.

Are you using development version? The fix landed there.

Regards,

-- 
Nicolas Goaziou

Re: [O] Is there a org-babel-map-src-blocks but for tables?

2016-10-17 Thread Nick Dokos 
Nicolas Goaziou  writes:

> Pierre-Henry Frohring  writes:
>
>> Probably good to put that in the doc (http://orgmode.org/org.html)!
>
> Not sure where it could fit, tho.
>

The mapping API section perhaps?

-- 
Nick

Re: [O] Bug: Agenda: Sorting TODOs (with tags) by effort does not work [8.3.6 (8.3.6-7-g4d7d52-elpaplus @ /home/luke/.emacs.d/elpa/org-plus-contrib-20161010/)]

2016-10-17 Thread Luke 

On 16/10/16 20:32, Nicolas Goaziou wrote:

Fixed. Thank you.


Thanks for that. Unfortunately, it doesn't seem to fix the issue I reported.

Provided the TODOs have no tags assigned, then I can sort them no 
problem. However, when I add tags to some of the TODOs, all the TODOs 
with tags appear at the top of the agenda. It's as if the tags are 
somehow overriding the sorting strategy.


Regards,
--
Luke

Re: [O] Basic visibility cycling bug in 8.3.6

2016-10-17 Thread Nicolas Goaziou 
Hello,

Marcus Zibrowius  writes:

Cc'ing to the list for further discussion.

> Excellent!   Thanks a lot for helping so quickly.  I still maintain that
> the behaviour is different for me in org-mode 7.9.3, but I understand
> now that it's a (new?) feature rather than a bug.

I misread your version string. The behaviour you describe doesn't happen
in Org 7.9.3f, but was introduced in
2efbd0f138180fe14773d5485ad3c59332d6ddb3, i.e., between Org 7.9.3f and
and Org 7.9.4. I can indeed observe the same with the latter.

However this change never made it into the following release, i.e., Org
8.0. You're observing a very short-lived feature.

> Let me reiterate what I think is different , now that I understand
> better what is happening:  in org-mode 8.3.6, if I start with 
>
> * a
> ** b
> ** c
> ** d
> ** e
> ** f
> ** g
> ** h
>
> with point at e, then if I collapse with Shift+TAB and reexpand with
> TAB, I get only:
>
> * a...
> ** e
> ...
>
> with point at the beginning of the line **e, and I can reexpand the
> whole tree with C-c C-r.   So the line in which point was is somehow
> remembered.  In contrast, Shift+TAB followed by TAB in org-mode 7.9.3f
> (details below) brings back the whole tree directly, but forgets where
> point was:  point ends up just right of a.

I think it is important to preserve point when cycling view. It would be
surprising if a function modifying visibility also moved it. Besides,
this is useful when one wants to have a glimpse to the overview (S-TAB)
and go back to the editing location (another S-TAB) immediatly after.

I have no strong opinion on what should be displayed when pressing TAB
in this case, tho. It seems the implentation of `org-cycle' sort of
decided for us, i.e., it wasn't meant to handle this situation.

Regards,

-- 
Nicolas Goaziou0x80A93738