date:20171205

Kaushal Modi  writes:

> Thank you! It just made another commit and it got published
> instantly.

Great, thanks for confirming.

-- 
 Bastien

Re: [O] 27.0.50;Missing requirement in org-gnus.el

Kyle Meyer  writes:

> Bastien Guerry  writes:
>
>> I've just released 9.1.4 which fixes this bug, this minor release can
>> be merged into Emacs.
>
> Thanks, Bastien.  Rasmus, the emacs-sync branch is ready.

Wow, that was fast.  Thanks a lot Kyle!

-- 
 Bastien

Re: [O] org-depend: TRIGGER XYZ(KEYWORD) not working

2017-12-05 Thread Adrian Bradd

Hi Karl,

This is because I removed the wrong progress indicator from my
> examples before posting. You have to change all "[0/2]" with "[%]"
> and then you see the issue I described. It seems to be the case that
> [/] do work whereas [%] do cause the described malfunctional
> behaviour. I was using both and did remove the wrong one.


I have found the issue, but haven't had time to patch it. It actually does
happen with both [%] and [/].

org-todo is using a point to pass the beginning of the heading to
org-depend instead of a marker. As such, when characters are added to the
statistics in the parent heading the point shifts up to the line above the
heading and when (org-entry-get pos "TRIGGER") runs it searches the heading
above it, which is why the trigger works correctly if you populate the
parent heading property.

change-plist looks llike it is used in a few other functions as well. I'll
have to see if using a marker breaks them.

Cheers,

Adrian

[O] Bug: org-files-list duplicate files [9.1.3 (9.1.3-29-g037db0-elpa @ ~/.emacs.d/elpa/org-20171204/)]

2017-12-05 Thread Renato Ferreira

Hello,

Investigating an issue I was having with (org-resolve-clocks) that i would
need to resolve the same clock twice, i believe i stumbled upon the
following bug on (org-files-list) (used by (org-resolve-clocks)):

It gets a list from (org-agenda-files) and pushes the open org
buffers found through (buffer-list), but i believe it _incorrectly_ uses
(cl-pushnew) since it ultimately uses memql (which compares with eql) to
check existence of the buffer file name (a string) with the
(org-agenda-files) list (of strings), returning duplicate items on lists
since compared strings are not the same lisp objects.

Advising (org-files-list) with (delete-dups) is a workaround i'm using but
(org-files-list) needs to be changed to use member instead of memql.

Thank you very much.

Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.19)
 of 2017-09-16
Package: Org mode version 9.1.3 (9.1.3-29-g037db0-elpa @ 
~/.emacs.d/elpa/org-20171204/)

-- 
Att.,
Renato Ferreira

Re: [O] org-timeline documentation

2017-12-05 Thread Kyle Meyer

Nicolas Goaziou  writes:

> Ilya Shlyakhter  writes:
>
>> The org-timeline documentation at
>> http://orgmode.org/manual/Timeline.html
>> seems no longer correct?
>
> The section no longer belongs to the manual.

Right, but you already removed it in e46676bd1 (org.texi: Remove
references to Timeline view, 2017-01-09).  I can't find "Timeline"
listed at .  Perhaps the site has retained
an unlinked, stale html file?

-- 
Kyle

Re: [O] org-timeline documentation

Hello,

Ilya Shlyakhter  writes:

> The org-timeline documentation at
> http://orgmode.org/manual/Timeline.html
> seems no longer correct?

The section no longer belongs to the manual.

> (also, I think it's unfortunate that the timeline agenda mode was
> removed -- I found it quite useful.)

I think the regular agenda can provide equivalent features.

Regards,

-- 
Nicolas Goaziou

Re: [O] [patch] structure snippet completions

Hello,

Rasmus  writes:

> +@cindex Tempo
> +@cindex Template expansion
> +@cindex template insertion
> +@cindex insertion, of templates
> +@vindex org-tempo-keywords-alist
> +@vindex org-structure-template-alist
> +Org Tempo expands snippets to structures defined in
> +@c @code{org-structure-template-alist} and @code{org-tempo-keywords-alist}.  
> For
> +@c example, @code{org-tempo} expands @kbd{< s @key{TAB}} to a code block.

It looks like a typo, but the two lines above are commented.

Also, would it make sense to add a few tests?

Regards,

-- 
Nicolas Goaziou

Re: [O] [patch] structure snippet completions

2017-12-05 Thread Eric Abrahamsen

Rasmus  writes:

> Eric Abrahamsen  writes:
>
>> Rasmus  writes:
>>
>>> Hi,
>>>
>>> The attached patch adds expansions of ">> would like to include this in the next version of Org in anticipation of
>>> the changes to the template system.
>>
>> Cool! We were talking about shifting the alist keys to strings, do we
>> want to do that all at once, in both places, or let this land first?
>
> I’m indifferent.  If you make a shift to strings in the part of the code
> you know I can alter this code. 

On second thought, maybe it would be better to put this in first. A
separate change could do string keys, and also make some of the other
changes people have been asking for (different keybinding, etc), all at
once.

[O] ox-publish export subtree scopes? (Was: org to static site?)

2017-12-05 Thread Kaushal Modi

On Tue, Dec 5, 2017 at 7:31 AM Rasmus wrote:

> If you have any suggestions on how to improve ox-publish to better suit
> please share them.
>

Hello Rasmus,

I'd like to make the ox-publish based exporting working for my ox-hugo[1]
package but so far have been unsuccessful.

The main reason is that org-foo-publish-to-bar functions take only plist,
filename and pub-dir as args. I miss the ability to first pick a subtree
scope from the specific Org file and then export only that. Is something
like that already possible which I am missing?

In addition, when given a file name, I need to auto-decide (i) if I need to
cycle through "valid" subtrees (see more about that below) and export those
subtrees,or (ii) export the whole Org file if #+TITLE is present.

So I ended up with org-hugo-export-wim-to-md[2] ("wim" stands for What I
Mean). Below is a snippet from its doc string:

=
- If the current subtree has the \"EXPORT_FILE_NAME\" property, export
that subtree.
- If the current subtree doesn't have that property, but one of its
parent subtrees has, then export from that subtree's scope.
- If none of the subtrees have that property (or if there are no Org
subtrees at all), but the Org #+TITLE keyword is present,
export the whole Org file as a post with that title (calls
`org-hugo-export-to-md' with its SUBTREEP argument set to nil).

- If ALL-SUBTREES is non-nil, export all valid Hugo post subtrees
\(that have the \"EXPORT_FILE_NAME\" property) in the current file
to multiple Markdown posts.
- If ALL-SUBTREES is non-nil, and again if none of the subtrees have
that property (or if there are no Org subtrees), but the Org #+TITLE
keyword is present, export the whole Org file.

- If the file neither has valid Hugo post subtrees, nor has the
#+TITLE present, throw a user error. If NOERROR is non-nil, use
`message' to display the error message instead of signaling a user
error.
=

And I use a Makefile[3] to find all Org files in the current directly and
call the above function, which then does the right thing as explained in
the conditions above.

Is there any way to call org-publish to export either the entire file or
cycle through the file and export the subtrees matching a predicate?

[1]: https://github.com/kaushalmodi/ox-hugo
[2]:
https://github.com/kaushalmodi/ox-hugo/blob/832a5d7424013f60b77354ec28613440afac0269/ox-hugo.el#L2424-L2448
[3]: https://github.com/kaushalmodi/ox-hugo/blob/master/Makefile
--

Kaushal Modi

Re: [O] 27.0.50;Missing requirement in org-gnus.el

2017-12-05 Thread Kyle Meyer

Bastien Guerry  writes:

> I've just released 9.1.4 which fixes this bug, this minor release can
> be merged into Emacs.

Thanks, Bastien.  Rasmus, the emacs-sync branch is ready.

-- 
Kyle

[O] org-timeline documentation

2017-12-05 Thread Ilya Shlyakhter

The org-timeline documentation at
http://orgmode.org/manual/Timeline.html
seems no longer correct?

(also, I think it's unfortunate that the timeline agenda mode was
removed -- I found it quite useful.)

Re: [O] Issue with org git repo and/or worg?

2017-12-05 Thread Kaushal Modi

On Tue, Dec 5, 2017 at 11:44 AM Bastien Guerry  wrote:

> I've fix something in the Worg publishing configuration, can you
> check again, maybe by making a test commit?
>

Thank you! It just made another commit and it got published instantly.
-- 

Kaushal Modi

[O] org-collector - Date-based conditions

2017-12-05 Thread Gonzalo Camarillo

Hi,

I am using org-collector to generate agenda views. For example, the
following block includes all items whose TODO keyword is "WAITING":

#+BEGIN: propview :conds ((string= TODO "WAITING")) :cols (ITEM EFFORT)

#+END:

I would like to add an additional condition based on the SCHEDULED
property of items. I would like to list all items whose SCHEDULED
property is less (earlier) or equal than today. How can I write such a
condition?

To do the above using org-agenda-custom-commands, I use the following:

  tags "TODO=\"WAITING\"+SCHEDULED<=\"\""

I would like to do the same using org-collector instead.


Additionally, how can I write a condition to select items without a TODO
keyword? I try (string= TODO "") but it does not seem to work.

Thanks,

Gonzalo

Re: [O] Issue with org git repo and/or worg?

Hi Kaushal,

> Shouldn't that commit update this page: http://orgmode.org/worg/
> org-blog-wiki.html ? But it hasn't been updated. 
>
> That page hasn't yet updated.

I've fix something in the Worg publishing configuration, can you
check again, maybe by making a test commit?

Thanks!

-- 
 Bastien

[O] Release 9.1.4

Hi all,

Org 9.1.4, a bugfix release, is out.

Enjoy!

-- 
 Bastien

Re: [O] org to static site?

2017-12-05 Thread myglc2

On 12/05/2017 at 13:30 Rasmus writes:

> myg...@gmail.com writes:
>
>> On 12/01/2017 at 18:19 Adonay Felipe Nogueira writes:
>>
>>> The best approach for me is also to use something such as org-publish,
>>> and a simple static site server such as GNU Serveez.
>>
>> Have you used org-publish in earnest?  I settled on the approach used in
>> https://github.com/myglc2/emacsite only after trying out org-publish
>> extensively.  I needed source and generated content to sit together in
>> the working tree of complex multi-level reproducible research projects
>> and to be transparently revision controlled and hosted on the
>> organization's Github Entreprise server.
>
> I am happy that you found a method that works for you.
>
> As a contrasting point, I don’t see why you couldn’t do that with
> ox-publish.el in addition to maybe Make.
>
> Based on your description, I’d copy source files using
> org-publish-attachment to a publish dir and compiled files to the same dir
> via different projects in org-publish-project-alist.

Yes, this works and I this before switching to the emacsite approach.

[...]

> If you have any suggestions on how to improve ox-publish to better suit
> please share them.

Does org-publish now support making the publishing directory coincide
with the project directory? If not, this is the suggestion.

Re: [O] 27.0.50;Missing requirement in org-gnus.el

Hi Nicolas and Rasmus,

Nicolas Goaziou  writes:

> It would be great. Org 9.1.3 contains a nasty fontification bug. We
> certainly don't want that in Emacs 26.1.

I've just released 9.1.4 which fixes this bug, this minor release can
be merged into Emacs.

Thanks,

-- 
 Bastien

Re: [O] 27.0.50;Missing requirement in org-gnus.el

2017-12-05 Thread Kaushal Modi

On Tue, Dec 5, 2017 at 7:17 AM Rasmus  wrote:

> Should we prepare another v9.1 bugfix release for the next version of
> Emacs?
>

*Neki aur pooch pooch *

It's an idiom in Hindi language which sort of translates[1] to "Why ask
before doing a good deed?". I tried to find something equivalent in English
but couldn't :)

[1]: https://www.google.com/search?q=neki+aur+pooch+pooch
-- 

Kaushal Modi

[O] bug#28263: 24.5; Org: `C-c LETTER' keys

2017-12-05 Thread Drew Adams

> >> Org's manual suggests to bind `org-agenda' to `C-c a', 
> >> but doesn't bind it by default.
> >
> > I'm not even sure that's a great idea.  I think not.
> >
> > I suppose it's "legit", as the user, not the Org code,
> > would be making the binding.  But in my libraries I 
> > provide binding suggestions only for keys that are not 
> > reserved for use by users.
> >
> > If a commonly used Emacs library (Org is the best example
> > of that) suggests to users that they bind `C-c a' to 
> > something then that key becomes pretty much, in effect,
> > lost as a key reserved for user customization.
> >
> > IOW, if 90% of Emacs users follow that suggestion then there 
> > is little difference between that situation and the situation 
> > of Org binding `C-c a' by default.
> >
> > My vote would be that Org should not do this.  Just one 
> > opinion.
> 
> I understand your concern. However, Org tries to be as neutral
> as possible with this. Quoting the manual:
> 
>  The manual suggests a few global key bindings, in particular 
>  @kbd{C-c a} for @code{org-agenda} and @kbd{C-c c} for 
>  @code{org-capture}.  These are only suggestions, but the rest 
>  of the manual assumes that these key bindings are in place in 
>  order to list commands by key access.

That's even worse, IMHO.  And hardly "as neutral as possible".

Why should the manual list commands by key access that Org
does _not_ bind to keys?  What's wrong with listing the
commands by name?  That's what Emacs does in its doc.

My suggestion would be to bind keys in Org keymaps only,
and leave it at that.

The manual should definitely not present key bindings that
are  not made by Org, tossing out an introductory comment
that they are shown only to "clarify bindings shown" or to
prevent having to show command names or whatever.

That approach is a bit backhanded, and it really flies
against the spirit of (really!) reserving C-c LETTER keys
for users.

> As explained here, this "suggestion" is only necessary
> to clarify key bindings in the manual.

Clarify key bindings in the manual?  Why are those key
bindings in the manual?  Describe the commands, not
(formally, supposedly) fictitious key bindings for them.

Either it is _important_ for Org to bind those commands
to keys or it's not.  If it is, then Org should find keys
that are not reserved for users.

As I said:

 > > provide binding suggestions only for keys that are
 > > not reserved for use by users

If it is not important for Org itself to bind such keys,
then no such "fictitious" global keys should be presented
in the manual.

> `org-agenda' and `org-capture' bindings are
> really prefixes for many other commands. Having to write, e.g.,
> "the prefix you chose for `org-agenda' then #" instead of
> "C-c a #" would be a lot more verbose, and ultimately, cripple 
> documentation.

My response to that: suck it up, or find a better way
to describe it.

You can perfectly well say "PK #", where PK is a
prefix key bound to `org-agenda'.  Or you can use,
for illustration purposes, a key such as .
(But using  or C-c a is no better than using
PK or whatever - you still need to say something like
"Supposing that  is a prefix key bound to
`org-agenda'...").

And why do you need to refer to a key at all, instead
of referring to the command?  As I say, if it is so
important that the command be bound to a key then
bind it - but to a key that is not reserved for users.

Don't ask users to bind their keys to provide something
that you think Org really needs.  If it needs keys for
this then bind keys for it.  If it does not then
hands-off, and just speak about the commands.  That's
what other Emacs doc does.

This is the wrong thing to do, IMO:

 The four Org commands 'org-store-link', 'org-capture',
 'org-agenda', and 'org-iswitchb' should be accessible 
 through global keys (i.e., anywhere in Emacs, not just
 in Org buffers).  Here are suggested bindings for these 
 keys, please modify the keys to your own liking.

 (global-set-key "\C-cl" 'org-store-link)
 (global-set-key "\C-ca" 'org-agenda)
 (global-set-key "\C-cc" 'org-capture)
 (global-set-key "\C-cb" 'org-iswitchb)

If those commands "should" be on global keys then
_Org should bind them to global keys_.  And those
global keys should _not_ be keys reserved for users.

This looks like a shame-faced way of getting around
the prohibition of libraries binding such keys
globally.  Especially for a library such as Org,
which is very widely used.

My suggestion would be to propose, to emacs-devel,
to bind 4 keys globally for those Org commands -
if you really feel they "should" be bound globally.
IOW, stick up for what you believe.  And if it is
decided to bind those commands you can be sure that
the keys decided on then will not be keys reserved
for users.

> I think the current state is quite fair.

I disagree.  It's a shame.  (FWIW.)  Emacs "should"
do better.

Just one opinion.

Re: [O] 27.0.50;Missing requirement in org-gnus.el

Hello,

Rasmus  writes:

> Should we prepare another v9.1 bugfix release for the next version of
> Emacs?

It would be great. Org 9.1.3 contains a nasty fontification bug. We
certainly don't want that in Emacs 26.1.

Regards,

-- 
Nicolas Goaziou

Re: [O] org to static site?

myg...@gmail.com writes:

> On 12/01/2017 at 18:19 Adonay Felipe Nogueira writes:
>
>> The best approach for me is also to use something such as org-publish,
>> and a simple static site server such as GNU Serveez.
>
> Have you used org-publish in earnest?  I settled on the approach used in
> https://github.com/myglc2/emacsite only after trying out org-publish
> extensively.  I needed source and generated content to sit together in
> the working tree of complex multi-level reproducible research projects
> and to be transparently revision controlled and hosted on the
> organization's Github Entreprise server.

I am happy that you found a method that works for you.

As a contrasting point, I don’t see why you couldn’t do that with
ox-publish.el in addition to maybe Make.

Based on your description, I’d copy source files using
org-publish-attachment to a publish dir and compiled files to the same dir
via different projects in org-publish-project-alist.  I don’t know how
github works re CI, but with Gitlab you’d then mark the publish folder as
an artifact folder that would be published.  For each commit you’d then
have a zip and a website with source and compiled data / code.

If you have any suggestions on how to improve ox-publish to better suit
please share them.

> After studying both approaches I found the emacsite approach to work
> better than org-publish. Just to be clear, emacsite does not require
> GitHub. You can equally well serve the site from the development tree,
> or you can publish by doing git push to non bare git repos hosted on web
> servers. In this way emacsite effectively automates site publishing
> using make and git which I found to be more reliable than org-publish.

For publishing something to the web I’d personally use CI or just cp.
You could use git using :publishing-function or maybe
:publishing-directory if tramp somehow supports git. 

Rasmus

-- 
Tack, ni svenska vakttorn. Med plutonium tvingar vi dansken på knä!

Re: [O] 27.0.50;Missing requirement in org-gnus.el


Nicolas Goaziou  writes:

> Glenn Morris  writes:
>
>> Speaking for the version in Emacs, apart from org-gnus the warnings are:
>>
>> In end of data:
>> org-irc.el:255:1:Warning: the following functions are not known to be 
>> defined:
>> erc-save-buffer-in-logs, erc-logging-enabled
>
> Fixed. Thank you.

Should we prepare another v9.1 bugfix release for the next version of
Emacs?

Rasmus

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

[O] bug#27711: bug#27711: 25.2; org-feed gets old news as new from some feeds

2017-12-05 Thread Adonay Felipe Nogueira

Thank you very much for the fix. ;)

I can't test it right now, but I will do so in the future.

Have a nice day! ;)

2017-12-04T22:22:13+0100 Nicolas Goaziou wrote:
> Hello,
>
>
> Fixed. Thank you.
>
> Regards,

[O] bug#28263: 24.5; Org: `C-c LETTER' keys

Hello,

Drew Adams  writes:

>> > Dunno whether there are actual bindings in Org that correspond to these
>> > occurrences in the source code of `C-c' followed by a letter.  Might be
>> > worth checking.  (Bindings of `C-c' followed by a letter are reserved
>> > for users.)  Possibly these are just vestigial doc indications, which
>> > could be corrected/updated.
>> 
>> Org's manual suggests to bind `org-agenda' to `C-c a', but doesn't bind
>> it by default.
>
> I'm not even sure that's a great idea.  I think not.
>
> I suppose it's "legit", as the user, not the Org code, would be
> making the binding.  But in my libraries I provide binding
> suggestions only for keys that are not reserved for use by users.
>
> If a commonly used Emacs library (Org is the best example of that)
> suggests to users that they bind `C-c a' to something then that
> key becomes pretty much, in effect, lost as a key reserved for
> user customization.
>
> IOW, if 90% of Emacs users follow that suggestion then there is
> little difference between that situation and the situation of
> Org binding `C-c a' by default.
>
> My vote would be that Org should not do this.  Just one opinion.

I understand your concern. However, Org tries to be as neutral as
possible with this. Quoting the manual:

The manual suggests a few global key bindings, in particular @kbd{C-c a} for
@code{org-agenda} and @kbd{C-c c} for @code{org-capture}.  These are only
suggestions, but the rest of the manual assumes that these key bindings are 
in
place in order to list commands by key access.

As explained here, this "suggestion" is only necessary to clarify key
bindings in the manual. `org-agenda' and `org-capture' bindings are
really prefixes for many other commands. Having to write, e.g., "the
prefix you chose for `org-agenda' then #" instead of "C-c a #" would be
a lot more verbose, and ultimately, cripple documentation.

I think the current state is quite fair.

Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] [patch] structure snippet completions

Eric Abrahamsen  writes:

> Rasmus  writes:
>
>> Hi,
>>
>> The attached patch adds expansions of "> would like to include this in the next version of Org in anticipation of
>> the changes to the template system.
>
> Cool! We were talking about shifting the alist keys to strings, do we
> want to do that all at once, in both places, or let this land first?

I’m indifferent.  If you make a shift to strings in the part of the code
you know I can alter this code. 

>>> +(mapcar 'org-tempo-add-block org-structure-template-alist)
>>
>> #'org-tempo-add-block
>>
>>> +(mapcar 'org-tempo-add-keyword org-tempo-keywords-alist)))
>
> And `mapc'!

Fair enough.

Rasmus

-- 
This space is left intentionally blank

Re: [O] [patch] structure snippet completions