Re: [O] org-agenda time grid broken ?
Nicolas Goaziou writes: > 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. I've looked into it but the example I provided is run from emacs -Q and no change to the default value of org-agenda-time-grid, set to ((daily today require-timed) (800 1000 1200 1400 1600 1800 2000) ".." "") Also, I noticed two other things: * when I'm using org from the git repo, a call to org-agenda throws this error: --8<---cut here---start->8--- org-agenda-format-item: Symbol’s function definition is void: org-duration-to-minutes --8<---cut here---end--->8--- * I'm using --8<---cut here---start->8--- (add-to-list 'load-path "~/git-repositories/org-mode/lisp") (add-to-list 'load-path "~/git-repositories/org-mode/contrib/lisp") --8<---cut here---end--->8--- to choose the git version of org-mode. If I run org-reload immediately afterwards (which I didn't use to do up to now), the error disappears, at least with the minimalist example from my previous post. Julien.
Re: [O] [Orgmode] Slow speed of week and month views
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
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
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, as Carsten said, require rewriting a lot of
Re: [O] [PATCH] ob-vala.el: Add Vala support to Babel
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
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
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
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
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
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
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
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 ?
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
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 mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|
[O] ox-ipynb in a new repo
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 ?
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
* 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
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
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
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
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/)]
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
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
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.
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.
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
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
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
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
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
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
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/)]
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