Re: [O] Behavior of `org-show-entry'

[Kyle Meyer]

Eric Abrahamsen  writes:

> Kyle Meyer  writes:

[...]

>> Based on how org-show-entry calls it, outline-flag-region shows the text
>> from the current heading to the next.  So it seems to behave as
>> documented: "[s]how the body directly following this heading".
>
> Okay, but I still don't see how this would ever be the desired result.
> You can't get to *any* next visibility state without first wasting a
> .

Yeah, fair enough.  I can't think of a situation where I would desire
that result either.  But I think org-show-entry probably should behave
this way to be consistent with outline-show-entry.

>>> Which part of this should be tweaked to achieve the desired effect?
>>
>> Perhaps helm could call org-show-children after it calls org-show-entry.
>
> Okay, cool. I guess my main question was: should this be fixed in helm,
> or in org? I'll try clobbering the helm functions for a while and see
> how that goes, then raise this on the helm list.

Hmm, for the reason I gave above, I don't think org-show-entry should
change, but perhaps there should be a separate function that does

(org-show-entry)
(org-with-limited-levels (org-show-children))

which is what org-cycle does for the second state listed in its
docstring.  Or maybe there is a better way to accomplish this that I
don't know about.

-- 
Kyle

Re: [O] Bug in clocktable report with formula %

[Andreas Mueller]

Hello

I just noticed with updated org (org-20170124), although days are no
longer ignored, the percentage calculation is still wrong.

It looks to me like the problem is that org-effort-durations calculates
minutes in a day with 8 hours per day (I assume the idea was to only
plan for 8 hour workdays).

Changing org-effort-durations to calculate with 24 hour days gives the
correct result of 93% / 7%.

Thanks & best regards,
Andreas


Nicolas Goaziou wrote:
> Hello,
> 
> Andreas Mueller  writes:
> 
>> I think I may have found a bug in the clocktable report: When using
>> :formula %, it seems days are ignored in time percentage calculation.
>>
>> I have attached a simple test.org which demonstrates this.
>>
>> Emacs version: 24.5.1
>> Org version: Org mode version 9.0.2 (9.0.2-10-g820d1e-elpa @ 
>> ~/.emacs.d/elpa/org-20161223/)
>>
>> Thanks & best regards,
>> Andreas
>>
>> * Foo
>>   CLOCK: [2016-12-27 Wed 13:09]--[2016-12-28 Wed 15:09] => 26:00
>> * Bar
>>   CLOCK: [2016-12-28 Wed 13:09]--[2016-12-28 Wed 15:09] =>  2:00
>>
>> * Report
>> #+BEGIN: clocktable :maxlevel 2 :scope file :formula %
>> #+CAPTION: Clock summary at [2016-12-28 Wed 15:10]
>> | Headline | Time  |   | % |
>> |--+---+---+---|
>> | *Total time* | *1d 4:00* |   | 100.0 |
>> |--+---+---+---|
>> | Foo  | 1d 2:00   |   |  50.0 |
>> | Bar  | 2:00  |   |  50.0 |
>> #+TBLFM: $4='(org-clock-time% @2$2 $2..$3);%.1f
>> #+END:
> 
> Fixed. Thank you.
> 
> Regards,
> 



test.org
Description: Lotus Organizer


signature.asc
Description: Digital signature

Re: [O] Behavior of `org-show-entry'

[Eric Abrahamsen]

Kyle Meyer  writes:

> Eric Abrahamsen  writes:
>
>> I do a lot of my Org navigation with `helm-org-in-buffer-headings' and
>> `helm-org-agenda-files-headings', which prompt you for an org heading,
>> then take you there.
>>
>> I'm always annoyed that, once you're at the heading, it leaves it in
>> a half-open state where you can see the immediate text of the target
>> entry, but all of its child entries are replaced by an ellipses.
>>
>> * Target Heading
>>   Drawers and text
>>   ... # ellipses instead of child headings
>> * Next Heading
>>
>> You then have to hit  twice to see the children.
>>
>> The helm commands end by calling `org-show-entry', which first does
>> this:
>>
>> (outline-flag-region
>>  (max (point-min) (1- (point)))
>>  (save-excursion
>>(if (re-search-forward
>>  (concat "[\r\n]\\(" org-outline-regexp "\\)") nil t)
>>(match-beginning 1)
>>  (point-max)))
>>   nil)
>>
>> Which leaves the heading in the state described above, and then does
>> this:
>>
>> (org-cycle-hide-drawers 'children)
>>
>> Which has no effect.
>>
>> I'm not really sure what the purpose of `outline-flag-region' is, but
>> I'm pretty sure this isn't the desired effect.
>
> Based on how org-show-entry calls it, outline-flag-region shows the text
> from the current heading to the next.  So it seems to behave as
> documented: "[s]how the body directly following this heading".

Okay, but I still don't see how this would ever be the desired result.
You can't get to *any* next visibility state without first wasting a
.

>> The call to `org-cycle-hide-drawers' should reveal children, isn't
>> that right?
>
> The purpose isn't to reveal the child headings (I don't understand why
> the argument is called "children"), but to hide the drawers.

Weird! But thank you for doing the thinking I was apparently too lazy to
do :)

[...]

>> Which part of this should be tweaked to achieve the desired effect?
>
> Perhaps helm could call org-show-children after it calls org-show-entry.

Okay, cool. I guess my main question was: should this be fixed in helm,
or in org? I'll try clobbering the helm functions for a while and see
how that goes, then raise this on the helm list.

Thanks for your help,
Eric

Re: [O] Behavior of `org-show-entry'

[Kyle Meyer]

Eric Abrahamsen  writes:

> I do a lot of my Org navigation with `helm-org-in-buffer-headings' and
> `helm-org-agenda-files-headings', which prompt you for an org heading,
> then take you there.
>
> I'm always annoyed that, once you're at the heading, it leaves it in
> a half-open state where you can see the immediate text of the target
> entry, but all of its child entries are replaced by an ellipses.
>
> * Target Heading
>   Drawers and text
>   ... # ellipses instead of child headings
> * Next Heading
>
> You then have to hit  twice to see the children.
>
> The helm commands end by calling `org-show-entry', which first does
> this:
>
> (outline-flag-region
>  (max (point-min) (1- (point)))
>  (save-excursion
>(if (re-search-forward
>   (concat "[\r\n]\\(" org-outline-regexp "\\)") nil t)
>(match-beginning 1)
>  (point-max)))
>   nil)
>
> Which leaves the heading in the state described above, and then does
> this:
>
> (org-cycle-hide-drawers 'children)
>
> Which has no effect.
>
> I'm not really sure what the purpose of `outline-flag-region' is, but
> I'm pretty sure this isn't the desired effect.

Based on how org-show-entry calls it, outline-flag-region shows the text
from the current heading to the next.  So it seems to behave as
documented: "[s]how the body directly following this heading".

> The call to `org-cycle-hide-drawers' should reveal children, isn't
> that right?

The purpose isn't to reveal the child headings (I don't understand why
the argument is called "children"), but to hide the drawers.

Without the org-cycle-hide-drawers call, org-show-entry would expand

* TODO blah...

to

* TODO blah
SCHEDULED: <2017-02-12 Sun .+1w>
:PROPERTIES:
:LAST_REPEAT: [2017-02-05 Sun 16:31]
:END:
:LOGBOOK:
- State "DONE"   from "TODO"   [2017-02-05 Sun 16:31]
:END:

instead of

* TODO blah
SCHEDULED: <2017-02-12 Sun .+1w>
:PROPERTIES:...
:LOGBOOK:...

> Which part of this should be tweaked to achieve the desired effect?

Perhaps helm could call org-show-children after it calls org-show-entry.

-- 
Kyle

Re: [O] Bug: org-agenda-only-exact-dates [9.0.4 (9.0.4-elpa @ c:/Users/atamulis/.emacs.d/elpa/org-20170124/)]

[Tamulis, Andrius]

I had not read the docstring, but now I have, and I interpret it 
differently than you did. As, it seems, did the people who coded it. I 
want a zero value for org-deadline-warning-days, as I want no warnings 
of future deadlines. But I also do not want notification of deadlines 
that are past due, and that's not what org-deadline-warning-days is for.


Andrius

On 2017-02-04 13:58, Nicolas Goaziou wrote:

"Tamulis, Andrius"  writes:


The two variables you mention above fix almost everything for me - but
is there a "org-deadline-past-days" variable? Something that I could
set so that past due deadlines not be mentioned? Or may I suggest that
"org-agenda-todo-ignore-deadlines" have a value like "past", but one
that ignores deadlines that are in the past, but include those for
today.

Have you tried to set this variable to -1? According to the docstring,
it should do what you want. I didn't test it, tho.

Regards,

Re: [O] Help checking orgcard.pdf

[Kyle Meyer]

Kaushal Modi  writes:

> Thanks. Please push that for me.

OK, will do.  I'll wait a day or two for comments on other sections and
apply your patch when I commit those changes.

-- 
Kyle

Re: [O] Help checking orgcard.pdf

[Kaushal Modi]

Thanks. Please push that for me.

Can only do http push from my machine (work), external ssh is blocked.

I some point, I will need to figure out a push mechanism from my phone.

On Sun, Feb 5, 2017, 3:53 PM Kyle Meyer  wrote:

> Kaushal Modi  writes:
>
> > Hi Kyle,
> >
> > I had few fixes in my version of orgcard.tex. I had reviewed the bindings
> > till the Tables section last November.
> >
> > I have attached the patch for review.
>
> Thanks!  Looks good.
>
> --
> Kyle
>
-- 

Kaushal Modi

Re: [O] Help checking orgcard.pdf

[Kyle Meyer]

Kaushal Modi  writes:

> Hi Kyle,
>
> I had few fixes in my version of orgcard.tex. I had reviewed the bindings
> till the Tables section last November.
>
> I have attached the patch for review.

Thanks!  Looks good.

-- 
Kyle

Re: [O] Help checking orgcard.pdf

[Kaushal Modi]

Hi Kyle,

I had few fixes in my version of orgcard.tex. I had reviewed the bindings
till the Tables section last November.

I have attached the patch for review.

On Sun, Feb 5, 2017 at 12:05 PM Kyle Meyer  wrote:

> Hello,
>
> On the maint branch, doc/orgcard.tex lists the Org version as 8.2.  I'd
> like to bump this to 9.
>
> It'd be helpful if a few people could look at a topic or two that they
> are familiar with and report back about whether things look up-to-date.
> The card on the website [*] is still stuck at 7.8.11, so I've attached
> one built from the maint branch.
>
> Thanks.
>
> [*] http://orgmode.org/orgcard.pdf
>
>
> --
> Kyle
>
-- 

Kaushal Modi


0001-Update-few-bindings-descriptions-based-on-org-9.0.4.patch
Description: Binary data

[O] Behavior of `org-show-entry'

[Eric Abrahamsen]

I do a lot of my Org navigation with `helm-org-in-buffer-headings' and
`helm-org-agenda-files-headings', which prompt you for an org heading,
then take you there.

I'm always annoyed that, once you're at the heading, it leaves it in
a half-open state where you can see the immediate text of the target
entry, but all of its child entries are replaced by an ellipses.

* Target Heading
  Drawers and text
  ... # ellipses instead of child headings
* Next Heading

You then have to hit  twice to see the children.

The helm commands end by calling `org-show-entry', which first does
this:

(outline-flag-region
 (max (point-min) (1- (point)))
 (save-excursion
   (if (re-search-forward
(concat "[\r\n]\\(" org-outline-regexp "\\)") nil t)
   (match-beginning 1)
 (point-max)))
  nil)

Which leaves the heading in the state described above, and then does
this:

(org-cycle-hide-drawers 'children)

Which has no effect.

I'm not really sure what the purpose of `outline-flag-region' is, but
I'm pretty sure this isn't the desired effect. The call to
`org-cycle-hide-drawers' should reveal children, isn't that right?

Which part of this should be tweaked to achieve the desired effect?

Thanks!
Eric

Re: [O] Sync up the org in emacs master to org maint branch?

[David Engster]

Edward John Steere writes:
>> It's not like packages communicate with Emacs over a well
>> defined RESTful interface. In other words: CEDET and Gnus are not
>> loosely coupled, quite the opposite: they are extremely dependend on
>> many obscure Emacs internals (not sure about Org).
>
> Shouldn't we be trying to avoid this situation?  It's sure to come back
> and bite us in the future.  If we continue to develop a package
> (wherever it ends up being developed) which is so tightly coupled that
> any kind of re factoring in core becomes a nightmare, because we have to
> consider the umpteen ways in which it'll break the package, then surely
> that's a bad methodology to continue?

I don't know what you have in mind. All I can say is: CEDET couldn't do
what it does if we'd restrict ourselves to some subset of Emacs.

>> As a consequence, we and also the Gnus guys decided to not do
>> separate releases anymore.  We used to provide CEDET for different
>> Emacs versions, and it was a *huge* amount of work. I had a buildbot
>> running with 7 or 8 Emacs versions to run the test suite, and things
>> broke pretty regularly.  Now you might say: fine, only release a
>> package for current master. But let's say we put CEDET into
>> ELPA. Emacs 26 gets released, and work on Emacs 27 starts. Now there
>> are changes happening in Emacs 27 that require changes in CEDET,
>> which make it incompatible with Emacs 26. So you have to create two
>> packages: one for 26, one for 27? Not only is this confusing, but it
>> most definitely increases my workload.
>
> I feel like this problem isn't intractable.

I didn't say it's intractable. I just said it means more work for me.

> We can mark some state of CEDET as being stable under the various
> versions of Emacs (because it was at the time) and then only support
> the current release for the latest package.  This would most likely
> require changes to package to ensure that you get an appropriate
> version of the package when you download it.

As I said: we did that. It was a huge amount of work. Please understand
where I'm coming from: if you look through the CEDET history, you will
see that in the past few years I almost exclusively did infrastructure
work and no real coding. All I can say is: *I* won't do this anymore,
and I don't want to be part in something which will increase grunt
work. We did not make this decision lightly. But with the amount of
developers we have, I'm convinced it's the right thing to do.

> Consider the problem which our users currently face.  The built in CEDET
> is miles behind and missing very important bug fixes and features.  The
> upstream CEDET can be a real pain to setup, but it has the latest
> features.  This is not a good place to be.  If we merge CEDET in and
> only release it with the realeses of Emacs then we are heading for a
> state where you only get the new features and bug fixes every time Emacs
> is realesed, i.e. our users might have to wait up to two years to have
> something fixed.  This is also a bad place to be.

Bug fixes can go with point release, which we should have every
year. But yes, if you want the latest, greatest and buggiest, you'll
have to use Emacs master. But that goes for a lot of Emacs features, so
I don't see why it's particularly bad for CEDET.

>>> We can arrange things so that a Git clone of Emacs includes pulling the
>>> submodules (or trees, or ELPA.git, or what not) that are considered part of
>>> "main Emacs development", including some of those batteries. I see this all 
>>> as
>>> a process issue, and that "living in one Git repository" has just been an
>>> implementation strategy to satisfy that process.
>>
>> Obviously, I'm very skeptical towards such an approach. Our tooling
>> around Emacs development is already very intricate and only works
>> because a few people work quietly behind the scenes to keep this all
>> running. Introducing even more complexity through
>> submodules/subtrees/whatever will do the opposite of what you want to
>> achieve: it creates more work for those few people who manage the Emacs
>> infrastructure. But I'd love to hear what for instance Glenn and Paul
>> think about this.
>
> I'm interested in exploring more with regards to how the subtree
> approach would work.  In particular how it would impact the Makefiles
> and build process.  I don't think that introducing features like this
> necessarily increases the burden of maintaining our tooling.  If we get
> it right it could reduce it.

Well, we cannot really discuss this since there's no real plan how this
all should work. I can only speak from experience.

> I think that it's a worthwhile goal to make core smaller.  It may not be
> a gigantic enterprise system with tens of thousands of source files,
> like some of us are accustomed to working on, but I think that it
> becomes easier to reason about the features and behaviour of core when
> it's smaller.

How does CEDET, Gnus and Org affect the rest of Emacs? They 

Re: [O] Sync up the org in emacs master to org maint branch?

[Eli Zaretskii]

> From: Edward John Steere 
> Date: Sun, 05 Feb 2017 11:03:31 +0200
> Cc: Bastien Guerry , Emacs developers ,
>   Phillip Lord ,
>   emacs-org list ,
>   Kaushal Modi 
> 
> > It's not like packages communicate with Emacs over a well
> > defined RESTful interface. In other words: CEDET and Gnus are not
> > loosely coupled, quite the opposite: they are extremely dependend on
> > many obscure Emacs internals (not sure about Org).
> 
> Shouldn't we be trying to avoid this situation?  It's sure to come back
> and bite us in the future.  If we continue to develop a package
> (wherever it ends up being developed) which is so tightly coupled that
> any kind of re factoring in core becomes a nightmare, because we have to
> consider the umpteen ways in which it'll break the package, then surely
> that's a bad methodology to continue?  (I'm not suggesting that we
> rewrite it to make it more loosely coupled, just that it seems like a
> bad idea to continue allowing this going forward.)

How would you go about not allowing this to go forward?  I don't
think I see any practical way to do that; do you?

IMO, this is up to the package developers: if they want to depend less
on the Emacs internals, and thus be more loosely coupled with a
particular Emacs version, they will need to invest the extra effort
for that, e.g., by providing some compatibility shims.

IOW, this isn't an issue that can be solved once and for all by the
way we develop the core or the packages, or by the way we integrate
packages with core, the solution is on a different level.

> > As a consequence, we
> > and also the Gnus guys decided to not do separate releases anymore.  We
> > used to provide CEDET for different Emacs versions, and it was a *huge*
> > amount of work. I had a buildbot running with 7 or 8 Emacs versions to
> > run the test suite, and things broke pretty regularly.
> > Now you might say: fine, only release a package for current master. But
> > let's say we put CEDET into ELPA. Emacs 26 gets released, and work on
> > Emacs 27 starts. Now there are changes happening in Emacs 27 that
> > require changes in CEDET, which make it incompatible with Emacs 26. So
> > you have to create two packages: one for 26, one for 27? Not only is
> > this confusing, but it most definitely increases my workload.
> 
> I feel like this problem isn't intractable.  We can mark some state of
> CEDET as being stable under the various versions of Emacs (because it
> was at the time) and then only support the current release for the
> latest package.  This would most likely require changes to package to
> ensure that you get an appropriate version of the package when you
> download it.

IF (and its a big "if") package developers want to be able to target
more than the single Emacs version on a single branch of the Emacs
repo, then they will need to provide at least 3 branches:

  . "development" branch that tracks the Emacs master branch and
introduces exciting new features
  . "bugfix" branch that tracks the Emacs release branch without
adding any new features
  . "stable" branch that is compatible with the Emacs release branch,
but also introduces some new features, the ones that don't need
core developments available only on the Emacs master branch

I envision that some packages will want the above (or maybe even a
more elaborate scheme), because they can afford that, and because
their users expect that.  These are mostly those packages whose
developers welcome the move to put more of Emacs on ELPA.  Other
packages, and I guess CEDET is one of them, will not want to do this,
because it adds too much work to an already complicated and
time-consuming job.

IOW, once again the solution is not part of the way we develop the
core or integrate non-core packages, it's elsewhere.

Bottom line, I think people are bothered by aspects of the "move to
ELPA" process that are not supposed to be affected by that move in any
way.  They are aspects that need to be resolved on entirely different
levels, and the resolution is up to the package maintainers.  That
includes a possible decision of the developers that some package will
not move to ELPA; I don't think that if a package developers say they
want to stay in emacs.git, they will be told to get out regardless.

Re: [O] Allowing multiple date trees in a single file

[Carsten Dominik]

Hi Nicolas,

thank you for taking the time to look at the proposed changes in detail.
My replies and comments are below.

On Sat, Feb 4, 2017 at 1:48 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Carsten Dominik  writes:
>
> > Attached is a patch that does the following:
> >
> > It consolidates all four different org-capture target types that have to
> do
> > with
> > date/week trees into a single one, called `file+olp+datetree'.  This
> target
> > allows for an optional outline path specification to tell capture to
> build
> > the
> > datetree under a specific headline.  To switch to a week tree, or to
> force
> > a date prompt is now the matter of setting one of the properties in the
> > org-capture-template variable.
>
> It sounds good. Thank you.
>

Allright.


>
> > Everything works transparently, so users can update the way they
> > write their datetree captures, but they don't have to - the old syntax
> > remains
> > supported and will automatically switched when one uses customize to
> change
> > the variable.
>
> I am a bit worried by this compatibility layer. I mean, it is good to
> preserve compatibility with old templates, but it ought to be an
> ephemeral solution. I.e., no more
> `org-table--error-on-old-row-references' lingering around for ages.
>
> We could, for example, generate a deprecation warning when old templates
> are used. Then we will be able to remove this unnecessary piece of code
> in next major release.
>

We do disagree here a bit.  This little bit of extra work just keeps the
existing templates working.  We do not introduce a really different
structure of the org-capture-templates.  Rather, the code introduces a new
target type, and it makes some older target types be implemented as special
versions of the new ones.  The old targets are no longer in the manual, any
customize user will be switched automatically.  What remains is a small bit
of code that makes sure that the setup of user who might have been using
that for a long time continues to work.

In my eyes, this is worth it.  Breaking something in a new version is no
big deal for people who use Org regularly, but I am sure there are a lot of
users out there who have not changed their setup for a long time, have not
followed the discussions here and would be frustrated if their setup breaks
after getting a new version of Emacs, for example.  So we can shoot a
warning, but I would vote for just keeping this piece of code indefinitely.


>
> See for example the end of `org-open-file', although it is a bit more
> drastic (it raises an error, not a warning).
>
> > After a bit more testing, I'd like to apply this patch.  Please let me
> know
> > if you agree. And additional testers would be useful.  Anyone?  Make sure
> > to backup your capture templates if something goes wrong.
>
> Some comments follow.
>
> > -@item (file+weektree+prompt "path/to/file")
> > -Will create a heading in a week tree, but will prompt for the date.
> > +one matched.}.  If the optional outline path is given, the tree will be
> built
> > +under the node it is pointing to. Check out the @code{:time-prompt} and
>
> There's a missing space above.
>

I will fix that in the next patch.


>
> > +(defun org-capture-upgrade-templates (templates)
> > +  "Update the template list to the new format.
> > +The new format unifies all the date/week tree targets into one that
> > +also allows for an optional outline path to specify a target."
> > +  (let (target props)
> > +(mapcar
> > + (lambda (ee)
> > +   (setq target (car (nth 3 ee)))
> > +   (when (memq target '(file+datetree file+datetree+prompt
> > +   file+weektree
> file+weektree+prompt))
> > +  (setq target (symbol-name target) props nil)
> > +  (if (string-match "prompt" target) (setq props '(:time-prompt t)))
> > +  (if (string-match "week" target)
> > +  (setq props (append '(:tree-type week) props)))
> > +  (setcar (nth 3 ee) 'file+olp+datetree)
> > +  (setcdr (nthcdr 4 ee) (append props (nthcdr 5 ee
> > +   ee)
> > + templates)))
>
> I suggest the following. Less `setq', `setcar', `setcdr' makes Org
> a better place.
>
> (defun org-capture-upgrade-templates (templates)
>   "Update the template list to the new format.
> TEMPLATES is a template list, as in `org-capture-templates'. The
> new format unifies all the date/week tree targets into one that
> also allows for an optional outline path to specify a target."
>   (mapcar
>(lambda (template)
>  (pcase template
>;; Match templates with an obsolete "tree" target type. Replace
>;; it with common `file+olp-datetree'.  Add new properties
>;; (i.e., `:time-prompt' and `:tree-type') if needed.
>(`(,key ,desc ,type (file+datetree . ,path) ,template . ,props)
> `(,key ,desc ,type (file+olp+datetree ,@path) ,@props))
>(`(,key ,desc ,type (file+datetree+prompt . ,path) ,template 

Re: [O] [PATCH] ox-bibtex.el: take key with spaces or non-alphabetic characters into account

[Nicolas Goaziou]

Hello,

Sebastien Le Maguer  writes:

> * ox-bibtex.el (org-bibtex-process-bib-files)
>  solve a bug in which ox-bibtex was not considering enterily keys like 
> "Author et al., 1999" as valid.

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou