Re: [O] [Orgmode] Slow speed of week and month views

[Adam Porter]

Thanks for your comments, John, that is very interesting.  I'll have to
check out your db code.

I'll drop a penny in the bucket with this:

http://github.com/alphapapa/org-agenda-ng

I spent a few hours trying an alternative approach that uses
org-element-parse-buffer to parse each file, then operates on the parse
tree it produces.  I was hoping it might have a chance to be an
improvement, but unfortunately it's not: org-element-parse-buffer is
very slow in comparison to the existing agenda code, and it eats up
almost all the time spent building the (very primitive) agenda views.

So, I think all we need is for someone to write a version of
org-element-parse-buffer in C or CL or whatever their favorite language
that compiles to a fast binary may be.  Then we can read that into Emacs
and operate on the resulting tree quickly.  Yep, that's ALL we
need... ;)

Seriously, though, it would be amazing if the new library support in
Emacs could be used to interface with a fast Org parser that provided
the same output as org-element-parse-buffer.  Maybe it could even be
added to Emacs core, as the Org file format doesn't change much.

All that's way over my head, I'm afraid.  Would some kind of bounty work
for a project like this?  I'd be willing to contribute a few dollars and
some testing.  :) 

I also gave a cursory look at profiling org-element-parse-buffer, but I
don't think Nicolas left any low-hanging fruit there.  But I'm not
experienced with profiling code like that, so don't take my word for
it.  :)

[O] [PATCH] Fix ox-md remote image links export

[Jay Kamat]

Hi!

I discovered a bug in the ox-md exporter and have created a patch to fix it:

Previously, this image link:
[[https://git-scm.com/images/l...@2x.png]]

would export to:
![img](//git-scm.com/images/l...@2x.png)

which is an invalid markdown image, and won't display properly in
browsers and other places.

A workaround (which I have been using extremely heavily), is:
[[file:https://git-scm.com/images/l...@2x.png]]

which exports to
![img](https://git-scm.com/images/l...@2x.png)

Which is the proper (unbroken) image link.

I have attached a patch which fixes the first example, so it exports
the same link as the workaround (and is no longer broken).

One of my concerns with the attached patch is whether there's a better
way to determine if a link is 'remote'. Maybe I should make a constant
in the file listing 'remote' types and use that everywhere.
I'm also not sure if I broke any other type of image link (but the
simple local case seems to work fine).

My papers are currently being processed, but I thought I would post
this patch early to get feedback, since ideally I would like this bug
to be fixed as soon as possible :). Hopefully they'll be done before
the review is completed.

Let me know if you see anything wrong, and thanks again for hacking org mode :D.

-Jay
From b4768baf2c6ea234c92f24540ed927cf8473e999 Mon Sep 17 00:00:00 2001
From: Jay Kamat 
Date: Sat, 5 Aug 2017 19:14:44 -0700
Subject: [PATCH] ox-md.el: Fix exporting of remote image links

* lisp/ox-md.el (org-md-link): Check if a link is a remote, and if so,
  use the raw-link property of the link, rather than the path.

A workaround for this bug is to do this:
[[file:http://orgmode.org/img/org-mode-unicorn-logo.png]]

This commit lets the workaround continue working, while the proper method:
[[http://orgmode.org/img/org-mode-unicorn-logo.png]]
is fixed.
---
 lisp/ox-md.el | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-md.el b/lisp/ox-md.el
index 08e3852823..a4e1d6749b 100644
--- a/lisp/ox-md.el
+++ b/lisp/ox-md.el
@@ -430,8 +430,14 @@ a communication channel."
 	   (format "[%s](#%s)"
 		   description
 		   (org-export-get-reference destination info
+ ;; Generate a md image link
  ((org-export-inline-image-p link org-html-inline-image-rules)
-  (let ((path (let ((raw-path (org-element-property :path link)))
+   ;; Get the path and caption to insert into the image
+   (let ((path (let ((raw-path
+			   ;; types of links which we just use the raw link
+			   (if (member type '("http" "https" "ftp"))
+			 (org-element-property :raw-link link)
+			 (org-element-property :path link
 		(if (not (file-name-absolute-p raw-path)) raw-path
 		  (expand-file-name raw-path
 	(caption (org-export-data
-- 
2.11.0

Re: [O] [Orgmode] Slow speed of week and month views

[Tim Cross]

I think the only viable first step is the profiling.

One of the main reasons I like org-mode is that all the data is just
text in files and it does not have any dependencies on other external
systems apart for publishing/exporting.

While there may be a need for external utilities to improve performance
for large/complex org files, this should be the last resort. The more
org relies on external packages, the more complex things become for
maintaining support on multiple platforms.

The first step is profiling so that we really understand where the
bottlenecks are. It may be these can only be resolved in some cases
using sqlite/mongodb/something-else, but I'm not sure if we know that
yet.

Tim

John Kitchin writes:

> I can think of two possibilities for a future approach (besides a deep dive
> on profiling the current elisp to improve the speed there). They both
> involve some substantial coding though, and would probably add
> dependencies. I am curious what anyone things about these, or if there are
> other ideas.
>
> One is to use the new dynamic module capability to write an org parser in
> C, or a dedicated agenda function, which would presumably be faster than in
> elisp.  This seems hard, and for me would certainly be a multiyear project
> I am sure! The downside of this is the need to compile the module. I don't
> know how easy it would be to make this work across platforms with the
> relatively easy install org-mode currently has. This could have a side
> benefit though of a c-lib that could be used by others to expand where
> org-mode is used.
>
> The other way that might work is to rely more heavily on a cached version
> of the files, perhaps in a different format than elisp, that is faster to
> work with. The approach I have explored in this is to index org files into
> a sqlite database. The idea then would be to generate the agenda from a sql
> query. I use something like this already to "find stuff in orgmode
> anywhere". One of the reasons I wrote this is the org-agenda list of files
> isn't practical for me because my files are so scattered on my file system.
> I had a need to be able to find TODOs in research projects in a pretty wide
> range of locations.
>
> The code I use is at
> https://github.com/jkitchin/scimax/blob/master/org-db.el, and from one
> database I can find headlines, contacts, locations, TODO headlines across
> my file system, all the files that contain a particular link, and my own
> recent org files. This approach relies on emacsql, and a set of hook
> functions to update the database whenever a file is changed. It is not
> robust, e.g. the file could be out of sync with the db if it is modified
> outside emacs, but this works well enough for me so far. Updated files get
> reindexed whenever emacs is idle. It was a compromise on walking the file
> system all the time or daily, or trying to use inotify and you can always
> run a command to prune/sync all the files any time you want.
>
> sqlite is ok, but with emacsql you cannot put strings in it directly (at
> least when I wrote the org-db code), which has limited it for full-text
> search so far. Also with text, the db got up to about 0.5 GB in size, and
> started slowing down. So it doesn't have text in it for now. It has all the
> other limitations of sqlite too, limited support for locking, single
> process
>
> I am moderately motivated to switch from sqlite to MongoDB, but the support
> for Mongo in emacs is pretty crummy (I tried writing a few traditional
> interfaces, but the performance was not that good, and limited since Mongo
> uses bson, and it is just not the same as json!). Why Mongo? Mostly because
> the Mongo query language is basically json and easy to generate in Emacs,
> unlike sql. Also, it is flexible and easy to adapt to new things, e.g.
> indexing src-blocks or tables or whatever org-element you want. (And I want
> to use Mongo for something else too ;). Obviously these all add
> dependencies, and might not be suitable for the core org-mode distribution.
> But I do think it is important to think about ways to scale org-mode while
> maintaining compatibility with the core.
>
> The main point of the database was to get a query language, persistence and
> good performance. I have also used caches to speed up using bibtex files,
> and my org-contacts with reasonable performance. These have been all elisp,
> with no additional dependencies. Maybe one could do something similar to
> keep an agenda cache that is persistent and updated via hook functions.
>
> Thoughts?
>
> John
>
> ---
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
> On Sat, Aug 5, 2017 at 5:09 PM, Karl Voit  wrote:
>
>> Thanks for the insight!
>>
>> * Adam Porter  wrote:
>> >
>> > But doing that would, 

Re: [O] [PATCH] ob-vala.el: Add Vala support to Babel

[Nicolas Goaziou]

Hello,

Christian Garbs  writes:

> Byte-compiling works and gave me 5 warnings about unused variables and
> arguments which I could fix in different ways.

Note that the usual solution to get rid of unused arguments is to prefix
their name with "_".

> Currently I run into a problem with the test case:  I have created an
> org file containing some Vala code and an .el file with some tests,

It would be better to have all tests and data self contained in the same
".el" file, IMO.

> but the dependency check at the top of the test always fails:
>
> | (unless (featurep 'ob-vala)
> |   (signal 'missing-test-dependency "Support for Vala code blocks"))
>
> Removing the test results in errors.
>
> When I replace those two lines with
>
> | (require 'ob-vala)
>
> the tests run as expected, eg. they fail when I deliberately provoke
> an error and succeed otherwise.
>
> I think this is a dependency or build problem, but I don't know what
> exactly goes wrong or how to fix it.  I have searched the whole source
> for 'ob-C and 'ob-fortran to see how those tests and modules differ
> from 'ob-vala, but this yielded no result.
>
> My guess: It is something totally basic and trivial.
> Any ideas?

I don't see any problem. The tests are meant to run if user has loaded
"ob-vala", but the test suite shouldn't load that library on user's
behalf.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Wrong type argument: integer-or-marker-p, nil on refile

[Nicolas Goaziou]

Hello,

Michaël Cadilhac  writes:

> Hi there everyone;
>
> Here's the ECM.
>
> init.el:
> (require 'org)
> (setq org-refile-use-outline-path (quote file))
>
> Now open an Org file, say foo.org, and type C-u C-c C-w foo.org/ RET
> At org.el:11832, pos is nil.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] org-capture.el: Document what the time stamp is in capture templates

[Nicolas Goaziou]

Hello,

Michaël Cadilhac  writes:

> Subject: [PATCH] org-capture.el: Document what the time stamp is in capture
>  templates
>
> * lisp/org-capture.el (org-capture-templates): Make explicit that the time
> stamp aware %-escapes are influenced by `org-capture-use-agenda-date'.

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Shrink columns dynamically

[Nicolas Goaziou]

Hello,

Adam Porter  writes:

> My only feedback here is that maybe the startup keywords would be more
> descriptive if they were something like "table-shrink" or
> "column-shrink".  I could imagine some new Org users conflating "folded"
> and "shrink" until they have used a more advanced feature like table
> column width cookies.  :)

I understand, but tables already use "align" and "noalign". I just
followed the trend.


Regards,

-- 
Nicolas Goaziou

Re: [O] ox-ipynb in a new repo

[Fabrice Popineau]

Thanks a lot for this piece of work! Very useful (at least to me).

Fabrice

2017-08-05 23:35 GMT+02:00 John Kitchin :

> Hi everyone,
>
> I moved my ipynb exporter to a new repo at https://github.com/
> jkitchin/ox-ipynb. I am planning to submit it to MELPA in the next week
> or two. If anyone is interested in checking it out, it would be helpful to
> spot issues prior to MELPA release!
>
> The TL;DR version is this adds an org export backend to make Jupyter
> notebooks in IPython and R.
>
> John
>
> ---
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>


-- 
Fabrice Popineau
-
SUPELEC
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
--

Re: [O] [RFC] Shrink columns dynamically

[Nicolas Goaziou]

Hello,

Eric S Fraga  writes:

> Thanks Nicolas.  Sounds very nice, matching at least my use cases quite
> well.  I'll give this a try soon and will get back to you.

For the record, I updated the "hide-table-column" branch again.

`org-table-toggle-column-width' is now bound to "C-c TAB". I removed
"noshrink" STARTUP keyword, which wasn't useful. I also introduced an
honest test coverage.

Still no documentation, though.

Feedback welcome.

Regards,

-- 
Nicolas Goaziou

Re: [O] Slow speed of week and month views

[Nicolas Goaziou]

Hello,

Karl Voit  writes:

> My daily agenda takes twenty seconds, my weekly approximately a
> minute and generating a monthly agenda is something I can only do
> when I plan to leave the computer for a longer break.
>
> Org-mode does not scale well, I'm afraid.
>
> Repeatedly going through all agenda files does not seem to be a very
> reasonable design choice for the general use-case. I would like to
> see an alternative approach for the future of Org-mode.

Well, we would at least need to profiling report as a starting point.
Could you provide one?

Regards,

-- 
Nicolas Goaziou

Re: [O] Slow speed of week and month views

[Nicolas Goaziou]

Hello,

John Kitchin  writes:

> I can think of two possibilities for a future approach (besides a deep dive
> on profiling the current elisp to improve the speed there). They both
> involve some substantial coding though, and would probably add
> dependencies. I am curious what anyone things about these, or if there are
> other ideas.

These are interesting ideas, but I'd rather have a deep dive on
profiling the current Elisp.

> The main point of the database was to get a query language, persistence and
> good performance. I have also used caches to speed up using bibtex files,
> and my org-contacts with reasonable performance. These have been all elisp,
> with no additional dependencies. Maybe one could do something similar to
> keep an agenda cache that is persistent and updated via hook
> functions.

If an agenda cache is required, it can be very simple. Associate entries
to agenda files. Whenever a file is modified, drop all the entries. No
need to refresh it IMO. I doubt many agenda files are modified between
two agenda calls.

Regards,

-- 
Nicolas Goaziou

Re: [O] org-agenda time grid broken ?

[Nicolas Goaziou]

Hello,

Julien Cubizolles  writes:

> Did I miss an important change to the way org-agenda-files is to be
> used ?

It is probably related to the change in `org-agenda-time-grid'. See new
docstring.


Regards,

-- 
Nicolas Goaziou

Re: [O] [Orgmode] Slow speed of week and month views

[John Kitchin]

I can think of two possibilities for a future approach (besides a deep dive
on profiling the current elisp to improve the speed there). They both
involve some substantial coding though, and would probably add
dependencies. I am curious what anyone things about these, or if there are
other ideas.

One is to use the new dynamic module capability to write an org parser in
C, or a dedicated agenda function, which would presumably be faster than in
elisp.  This seems hard, and for me would certainly be a multiyear project
I am sure! The downside of this is the need to compile the module. I don't
know how easy it would be to make this work across platforms with the
relatively easy install org-mode currently has. This could have a side
benefit though of a c-lib that could be used by others to expand where
org-mode is used.

The other way that might work is to rely more heavily on a cached version
of the files, perhaps in a different format than elisp, that is faster to
work with. The approach I have explored in this is to index org files into
a sqlite database. The idea then would be to generate the agenda from a sql
query. I use something like this already to "find stuff in orgmode
anywhere". One of the reasons I wrote this is the org-agenda list of files
isn't practical for me because my files are so scattered on my file system.
I had a need to be able to find TODOs in research projects in a pretty wide
range of locations.

The code I use is at
https://github.com/jkitchin/scimax/blob/master/org-db.el, and from one
database I can find headlines, contacts, locations, TODO headlines across
my file system, all the files that contain a particular link, and my own
recent org files. This approach relies on emacsql, and a set of hook
functions to update the database whenever a file is changed. It is not
robust, e.g. the file could be out of sync with the db if it is modified
outside emacs, but this works well enough for me so far. Updated files get
reindexed whenever emacs is idle. It was a compromise on walking the file
system all the time or daily, or trying to use inotify and you can always
run a command to prune/sync all the files any time you want.

sqlite is ok, but with emacsql you cannot put strings in it directly (at
least when I wrote the org-db code), which has limited it for full-text
search so far. Also with text, the db got up to about 0.5 GB in size, and
started slowing down. So it doesn't have text in it for now. It has all the
other limitations of sqlite too, limited support for locking, single
process

I am moderately motivated to switch from sqlite to MongoDB, but the support
for Mongo in emacs is pretty crummy (I tried writing a few traditional
interfaces, but the performance was not that good, and limited since Mongo
uses bson, and it is just not the same as json!). Why Mongo? Mostly because
the Mongo query language is basically json and easy to generate in Emacs,
unlike sql. Also, it is flexible and easy to adapt to new things, e.g.
indexing src-blocks or tables or whatever org-element you want. (And I want
to use Mongo for something else too ;). Obviously these all add
dependencies, and might not be suitable for the core org-mode distribution.
But I do think it is important to think about ways to scale org-mode while
maintaining compatibility with the core.

The main point of the database was to get a query language, persistence and
good performance. I have also used caches to speed up using bibtex files,
and my org-contacts with reasonable performance. These have been all elisp,
with no additional dependencies. Maybe one could do something similar to
keep an agenda cache that is persistent and updated via hook functions.

Thoughts?

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu


On Sat, Aug 5, 2017 at 5:09 PM, Karl Voit  wrote:

> Thanks for the insight!
>
> * Adam Porter  wrote:
> >
> > But doing that would, as Carsten said, require rewriting a lot of code.
> > Essentially you'd be creating a new agenda system, so you'd have to
> > reimplement a lot of existing code.  You could do it in parallel, rather
> > than replacing existing code, so you wouldn't have to break the existing
> > agenda system.  But I don't think there's any way to shortcut writing
> > the new system.  I don't think there's any "low hanging fruit."
>
> My daily agenda takes twenty seconds, my weekly approximately a
> minute and generating a monthly agenda is something I can only do
> when I plan to leave the computer for a longer break.
>
> Org-mode does not scale well, I'm afraid.
>
> Repeatedly going through all agenda files does not seem to be a very
> reasonable design choice for the general use-case. I would like to
> see an alternative approach for the future of Org-mode.
>
> --
> get 

[O] ox-ipynb in a new repo

[John Kitchin]

Hi everyone,

I moved my ipynb exporter to a new repo at
https://github.com/jkitchin/ox-ipynb. I am planning to submit it to MELPA
in the next week or two. If anyone is interested in checking it out, it
would be helpful to spot issues prior to MELPA release!

The TL;DR version is this adds an org export backend to make Jupyter
notebooks in IPython and R.

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

[O] org-agenda time grid broken ?

[Julien Cubizolles]

I noticed today (I hadn't used it in a long time) that the today and/or
time-grid view in the agenda seems broken.

With emacs -Q running Org mode version 9.0.9 (release_9.0.9 @ 
/usr/share/emacs/26.0.50/lisp/org/)

(setq org-agenda-files '("~/tmp/test-org/todo.org"))

todo.org
--8<---cut here---start->8---
# -*- coding: utf-8 -*-
* Beach
<2017-08-05 sam. 14:00-15:00>
--8<---cut here---end--->8---

org-agenda gives, as expected:
--8<---cut here---start->8---
Week-agenda (W31):
Monday 31 July 2017 W31
Tuesday 1 August 2017
Wednesday   2 August 2017
Thursday3 August 2017
Friday  4 August 2017
Saturday5 August 2017
   8:00.. 
  10:00.. 
  12:00.. 
  todo:   14:00-15:00 Beach
  14:00.. 
  16:00.. 
  18:00.. 
  20:00.. 
  23:17.. now - - - - - - - - - - - - - - - - - - - - - - - - -
Sunday  6 August 2017
--8<---cut here---end--->8---

However, with Org mode version 9.0.9 (release_9.0.9 @ 
/home/wilk/git-repositories/org-mode/lisp/)

the info for today are missing: org-agenda gives (notice Saturday is missing)

--8<---cut here---start->8---
Week-agenda (W31):
Monday 31 July 2017 W31
Tuesday 1 August 2017
Wednesday   2 August 2017
Thursday3 August 2017
Friday  4 August 2017
--8<---cut here---end--->8---

and attempting to switch to the day view gives the following message

--8<---cut here---start->8---
org-agenda-check-type: No Org agenda currently displayed
--8<---cut here---end--->8---

Did I miss an important change to the way org-agenda-files is to be
used ?

Julien.

Re: [O] Determine min/max values in a table

[Karl Voit]

* Adam Porter  wrote:
> Thierry Banel  writes:
>
>> Alternatively you have the orgtbl-aggregate package available on Melpa.
>>
>> #+BEGIN: aggregate :table "myvalues" :cols "min(Values) max(Values)
>> mean(Values)"
>>
>> | min(Values) | max(Values) | mean(Values) |
>> |-+-+--|
>> |   2 |   7 |  4.5 |
>
> Wow, that's very cool!  Had no idea about that package.

Although I do have the package installed, I did not think about
min/max/mean of it ;-)

> Karl, if that doesn't work for you, you might look at the
> org-table-to-lisp function.  Here's an example of a function that uses
> it to sum columns in the current region:

Thanks for the code I copied to my knowledge base.

For now, vmin/vmax did the trick and I also refreshed my knowledge
of orgtbl-aggregate.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: [O] Getting ox-taskjuggler on MELPA

[Simon Guest]

Hi Adam,

Ah, didn't spot that! Thanks for the hint.

Cheers, Simon

On 5/08/2017 10:51 PM, "Adam Porter"  wrote:

> Simon Guest  writes:
>
> > I am a user of ox-taskjuggler. Since I am currently running the
> > version of org mode bundled with Emacs, this doesn't include the
> > contrib stuff like ox-taskjuggler. So currently I have had to grab a
> > copy of ox-taskjuggler.el manually, and stick it on my load path,
> > manually.
> >
> > Since all my other Emacs packages are loaded from MELPA et al, I would
> > like to do the same with ox-taskjuggler.
> >
> > It would seem to be somewhat rude of me simply to submit
> > ox-taskjuggler to MELPA since I am neither the author nor the
> > maintainer. Which is why I am asking here.
>
> Hi Simon,
>
> Actually all you need to do is install the org-plus-contrib package from
> ELPA, which includes contrib.  Then you'll get the latest release of
> Org, too.  ;)
>
>
>

Re: [O] [Orgmode] Slow speed of week and month views

[Karl Voit]

Thanks for the insight!

* Adam Porter  wrote:
>
> But doing that would, as Carsten said, require rewriting a lot of code.
> Essentially you'd be creating a new agenda system, so you'd have to
> reimplement a lot of existing code.  You could do it in parallel, rather
> than replacing existing code, so you wouldn't have to break the existing
> agenda system.  But I don't think there's any way to shortcut writing
> the new system.  I don't think there's any "low hanging fruit."

My daily agenda takes twenty seconds, my weekly approximately a
minute and generating a monthly agenda is something I can only do
when I plan to leave the computer for a longer break.

Org-mode does not scale well, I'm afraid.

Repeatedly going through all agenda files does not seem to be a very
reasonable design choice for the general use-case. I would like to
see an alternative approach for the future of Org-mode.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: [O] [PATCH] ob-vala.el: Add Vala support to Babel

[Christian Garbs]

Hi!

On Thu, Aug 03, 2017 at 12:49:44PM +0200, Nicolas Goaziou wrote:
> Christian Garbs  writes:

> > Regarding the lexical-binding:  How can I check if byte-compiling is
> > successful?
> 
> M-x emacs-lisp-byte-compile

Byte-compiling works and gave me 5 warnings about unused variables and
arguments which I could fix in different ways.

Currently I run into a problem with the test case:  I have created an
org file containing some Vala code and an .el file with some tests,
but the dependency check at the top of the test always fails:

| (unless (featurep 'ob-vala)
|   (signal 'missing-test-dependency "Support for Vala code blocks"))

Removing the test results in errors.

When I replace those two lines with

| (require 'ob-vala)

the tests run as expected, eg. they fail when I deliberately provoke
an error and succeed otherwise.

I think this is a dependency or build problem, but I don't know what
exactly goes wrong or how to fix it.  I have searched the whole source
for 'ob-C and 'ob-fortran to see how those tests and modules differ
from 'ob-vala, but this yielded no result.

My guess: It is something totally basic and trivial.
Any ideas?

Regards
Christian
-- 
Christian.Garbshttps://www.cgarbs.de

To iterate is human, to recurse divine.  (L. Peter Deutsch)

Re: [O] setting local variables

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> For example, the below looks like something you'd find in an Emacs
>> manual.
>>
>> #+BEGIN_SRC texinfo
>>   @table @kbd
>>   @item C-x C-f
>>   @kindex C-x C-f
>>   @findex find-file
>>   Visit a file (@code{find-file}).
>>   @item C-x C-r
>>   @kindex C-x C-r
>>   @findex find-file-read-only
>>   Visit a file for viewing, without allowing changes to it
>>   (@code{find-file-read-only}).
>>   @end table
>> #+END_SRC
>
> [...]
>
>> But the items are exported incorrectly, with each list item in its own
>> itemize environment. How would I get something closer to the texinfo
>> output above?
>
>   #+attr_texinfo: :indic @kbd
>   - C-x C-f :: 
>
>#+kindex: C-x C-f
>Visit a file (~find-file~).
>
>
>   - C-x C-r ::
>
>#+kindex: C-x C-r
>#+findex: find-file-read-only
>
>Visit a file for viewing, without allowing changes to it
>(~find-file-read-only~).

Thank you!
Eric

Re: [O] Bug: org-clock-sum-current-item/org-clock-get-sum-start not respecting LAST_REPEAT [9.0.9 (release_9.0.9-697-gb0776e @ /usr/local/share/emacs/site-lisp/org/)]

[Nicolas Goaziou]

Hello,

Josh Moller-Mara  writes:

> Recently I've found that clocking in to a repeating task is giving me an
> incorrect "task time since last repeat". Normally, when I clock into a task,
> mark it as done, and clock in again, I expect the starting clock time to
> be 0. In this example:
>
> * TODO Stuff
>   SCHEDULED: <2017-08-04 Fri +1d>
>   :PROPERTIES:
>   :LAST_REPEAT: [2017-07-12 Wed 20:02]
>   :END:
>   :LOGBOOK:
>   - State "DONE"   from "TODO"   [2017-07-12 Wed 20:02]
>   CLOCK: [2017-07-12 Wed 19:54]--[2017-07-12 Wed 20:02] =>  0:08
>   - State "DONE"   from "TODO"   [2017-07-08 Sat 19:14]
>   CLOCK: [2017-07-08 Sat 18:49]--[2017-07-08 Sat 19:14] =>  0:25
>   - State "DONE"   from "TODO"   [2017-06-05 Mon 15:14]
>   CLOCK: [2017-06-05 Mon 14:48]--[2017-06-05 Mon 15:14] =>  0:26
>   :END:
>
> clocking in reports that I've spent 8 minutes on the item already, even
> though that happened before the LAST_REPEAT. When looking at
> (org-clock-sum-current-item (org-clock-get-sum-start))
> I'm getting "8" when I should get "0".
>
> This change seems to have started happening after commit 112c5ba47,
> which changed org-clock-sum to do something different with daylights
> savings.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

[O] [PATCH] org-capture.el: Document what the time stamp is in capture templates

[Michaël Cadilhac]

On 5 August 2017 at 12:46, Adam Porter  wrote:

> If you could send a TINYCHANGE patch to the docstring, I'm sure Nicolas
> would be grateful!  :)

Sure thing!

M.
From 7c8569f6bf694bb45ac5334c3bcb13e54e0d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C3=ABl=20Cadilhac?= 
Date: Sat, 5 Aug 2017 14:53:29 +0200
Subject: [PATCH] org-capture.el: Document what the time stamp is in capture
 templates

* lisp/org-capture.el (org-capture-templates): Make explicit that the time
stamp aware %-escapes are influenced by `org-capture-use-agenda-date'.

TINYCHANGE
---
 lisp/org-capture.el | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 5675de375..627522a26 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -273,8 +273,10 @@ be replaced with content and expanded:
   happens after expanding non-interactive %-escapes, those can
   be used to fill the expression.
   %<...>  The result of format-time-string on the ... format specification.
-  %t  Time stamp, date only.
-  %T  Time stamp with date and time.
+  %t  Time stamp, date only.  The time stamp is the current time,
+  except when called from agendas with `\\[org-agenda-capture]' or
+  with `org-capture-use-agenda-date' set.
+  %T  Time stamp as above, with date and time.
   %u, %U  Like the above, but inactive time stamps.
   %i  Initial content, copied from the active region.  If %i is
   indented, the entire inserted text will be indented as well.
@@ -292,7 +294,8 @@ be replaced with content and expanded:
   %^g Prompt for tags, with completion on tags in target file.
   %^G Prompt for tags, with completion on all tags in all agenda files.
   %^t Like %t, but prompt for date.  Similarly %^T, %^u, %^U.
-  You may define a prompt like: %^{Please specify birthday}t
+  You may define a prompt like: %^{Please specify birthday}t.
+  The default date is that of %t, see above.
   %^C Interactive selection of which kill or clip to use.
   %^L Like %^C, but insert as link.
   %^{prop}p   Prompt the user for a value for property `prop'.
-- 
2.13.3

Re: [O] Getting ox-taskjuggler on MELPA

[Adam Porter]

Simon Guest  writes:

> I am a user of ox-taskjuggler. Since I am currently running the
> version of org mode bundled with Emacs, this doesn't include the
> contrib stuff like ox-taskjuggler. So currently I have had to grab a
> copy of ox-taskjuggler.el manually, and stick it on my load path,
> manually.
>
> Since all my other Emacs packages are loaded from MELPA et al, I would
> like to do the same with ox-taskjuggler.
>
> It would seem to be somewhat rude of me simply to submit
> ox-taskjuggler to MELPA since I am neither the author nor the
> maintainer. Which is why I am asking here.

Hi Simon,

Actually all you need to do is install the org-plus-contrib package from
ELPA, which includes contrib.  Then you'll get the latest release of
Org, too.  ;)

Re: [O] Time stamped TODOs with current-time from everywhere.

[Adam Porter]

Michaël Cadilhac  writes:

> Thanks for your expertise Adam.  

Glad I could help, but I think you did the sleuthing here.  ;)

> It seems indeed that org-agenda-capture (or equivalently, setting
> org-capture-use-agenda-date) affects the default date at all stages,
> i.e., for %u and for the default value of %^t.  This is done through
> setting org-overriding-default-time.  I don't think there's any reason
> to change this behavior, but it may be worth adding that info in
> org-capture-template's docstring.  At the moment, it only says "time
> stamp".

If you could send a TINYCHANGE patch to the docstring, I'm sure Nicolas
would be grateful!  :)

Re: [O] Time stamped TODOs with current-time from everywhere.

[Michaël Cadilhac]

On 5 August 2017 at 04:27, Adam Porter  wrote:
> Michaël Cadilhac  writes:
>
>> However, suppose I'm in Calfw; I jump to some date, hit SPACE and I'm
>> now in Org-Agenda mode, ready to hit k to capture (because Calfw-Org
>> does not offer this directly).  Now I expect %U to still be the
>> current time stamp, and %^t to be prefilled with the date of the
>> Agenda.  It so happens that *both* time stamps are the one of the
>> Agenda.  Is this tweakable so that %U is always (current-time)?
>
> I'm not sure if that's a bug, since it seems like %^t should always
> prompt, or if it's intended that the agenda date fulfill the prompt.
> But either way, you should be able to use a %(sexp) form in the capture
> template to insert the current date.

Thanks for your expertise Adam.  It seems indeed that
org-agenda-capture (or equivalently, setting
org-capture-use-agenda-date) affects the default date at all stages,
i.e., for %u and for the default value of %^t.  This is done through
setting org-overriding-default-time.  I don't think there's any reason
to change this behavior, but it may be worth adding that info in
org-capture-template's docstring.  At the moment, it only says "time
stamp".

Cheers;
M.

Re: [O] [PATCH] org.el: Allow tags without keys in customization

[Nicolas Goaziou]

Hello,

Allen Li  writes:

> * lisp/org.el (org-tag-alist, org-tag-persistent-alist):
> Add non-keyed tag type.

Thank you.  For some reason, I'm not able to apply your patch on "maint"
branch. Could you rebase it on top of that branch and send it again?

Regards,

-- 
Nicolas Goaziou

Re: [O] org-store-agenda-views duplicate entries in .ics format

[Nicolas Goaziou]

Hello,

Nicolae Cindea  writes:

> I think there is a bug in org-2017073: when I store the agenda-view in
> .ics format, all the entries which span on multiple days are
> duplicated -- for each day there is a new event in the .ics file.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] setting local variables

[Nicolas Goaziou]

Hello,

Eric Abrahamsen  writes:

> For example, the below looks like something you'd find in an Emacs
> manual.
>
> #+BEGIN_SRC texinfo
>   @table @kbd
>   @item C-x C-f
>   @kindex C-x C-f
>   @findex find-file
>   Visit a file (@code{find-file}).
>   @item C-x C-r
>   @kindex C-x C-r
>   @findex find-file-read-only
>   Visit a file for viewing, without allowing changes to it
>   (@code{find-file-read-only}).
>   @end table
> #+END_SRC

[...]

> But the items are exported incorrectly, with each list item in its own
> itemize environment. How would I get something closer to the texinfo
> output above?

  #+attr_texinfo: :indic @kbd
  - C-x C-f :: 

   #+kindex: C-x C-f
   Visit a file (~find-file~).

  - C-x C-r ::

   #+kindex: C-x C-r
   #+findex: find-file-read-only
   Visit a file for viewing, without allowing changes to it
   (~find-file-read-only~).


Regards,

-- 
Nicolas Goaziou

[O] orgtbl-mode --> orgsrc-mode, orgtbl-insert-table-or-matrix--> orgsrc-execute-block

[Uwe Brauer]

Hi

I like orgtbl-mode and orgtbl-insert-table-or-matrix in latex files a
lot, since they simplify considerably the construction of tables and
matrixes.

I am looking for a similar functionality for src-code-blocks.

The idea is to insert, surrounded by a comment environment,
src-code-blocks, to execute them via org-babel and to insert the results
into the latex file, very similar to what orgtbl-insert-table-or-matrix
does.
Something like this

% BEGIN RECEIVE ORGSCR this
% END RECEIVE ORGSRC this
\begin{comment}
#+ORGTBL: SEND this orgsrc-to-latex  
|/|<>|
| |4 |
#+begin_src matlab  
X=[1,2,3,4,5,6,7];
res=mean(X)
#+end_src
\end{comment}

resulting in

% BEGIN RECEIVE ORGSCR this
res=3.5
% END RECEIVE ORGSRC this
\begin{comment}
#+ORGTBL: SEND this orgsrc-to-latex  
|/|<>|
| |4 |
#+begin_src matlab  
X=[1,2,3,4,5,6,7];
res=mean(X)
#+end_src
\end{comment}



Does such a functionality already exist?

Thanks

Uwe Brauer 

[O] Getting ox-taskjuggler on MELPA

[Simon Guest]

Dear Org People,

I am a user of ox-taskjuggler.  Since I am currently running the version of
org mode bundled with Emacs, this doesn't include the contrib stuff like
ox-taskjuggler. So currently I have had to grab a copy of ox-taskjuggler.el
manually, and stick it on my load path, manually.

Since all my other Emacs packages are loaded from MELPA et al, I would like
to do the same with ox-taskjuggler.

It would seem to be somewhat rude of me simply to submit ox-taskjuggler to
MELPA since I am neither the author nor the maintainer.  Which is why I am
asking here.

What is the protocol for this?

cheers,
Simon

[O] org-store-agenda-views duplicate entries in .ics format

[Nicolae Cindea]

Hello,

I think there is a bug in org-2017073: when I store the agenda-view in .ics 
format, all the entries which span on multiple days are duplicated -- for each 
day there is a new event in the .ics file. 

Thanks,
Nicolae.

[O] Bug: org-clock-sum-current-item/org-clock-get-sum-start not respecting LAST_REPEAT [9.0.9 (release_9.0.9-697-gb0776e @ /usr/local/share/emacs/site-lisp/org/)]

[Josh Moller-Mara]

Hey there,

Recently I've found that clocking in to a repeating task is giving me an
incorrect "task time since last repeat". Normally, when I clock into a task,
mark it as done, and clock in again, I expect the starting clock time to
be 0. In this example:

* TODO Stuff
  SCHEDULED: <2017-08-04 Fri +1d>
  :PROPERTIES:
  :LAST_REPEAT: [2017-07-12 Wed 20:02]
  :END:
  :LOGBOOK:
  - State "DONE"   from "TODO"   [2017-07-12 Wed 20:02]
  CLOCK: [2017-07-12 Wed 19:54]--[2017-07-12 Wed 20:02] =>  0:08
  - State "DONE"   from "TODO"   [2017-07-08 Sat 19:14]
  CLOCK: [2017-07-08 Sat 18:49]--[2017-07-08 Sat 19:14] =>  0:25
  - State "DONE"   from "TODO"   [2017-06-05 Mon 15:14]
  CLOCK: [2017-06-05 Mon 14:48]--[2017-06-05 Mon 15:14] =>  0:26
  :END:

clocking in reports that I've spent 8 minutes on the item already, even
though that happened before the LAST_REPEAT. When looking at
(org-clock-sum-current-item (org-clock-get-sum-start))
I'm getting "8" when I should get "0".

This change seems to have started happening after commit 112c5ba47,
which changed org-clock-sum to do something different with daylights
savings.

I'm currently using
Emacs  : GNU Emacs 26.0.50.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.5)
 of 2017-01-18
Package: Org mode version 9.0.9 (release_9.0.9-697-gb0776e @ 
/usr/local/share/emacs/site-lisp/org/)

Best,
Josh