Re: [O] CV in orgmode for export to pdf (and html?)
Myles English mylesengl...@gmail.com writes: Myles English writes: Nicolas Goaziou writes: One option could be to define a specialized latex back-end dedicated to moderncv class, much like ox-koma-letter.el does for scrlttr2. I did actually make a start on this, I'll dig it out and put it somewhere accessible, soon. ..and here it is: https://github.com/mylese/ox-cv This looks very nice - thanks. Rainer It kind of works, I haven't tried it with org more recent than about July. I'll be trying to develop it further myself but would welcome a lot of input from others. Alternatively, if someone wants to take it over completely, that would be fine too. Myles -- Rainer M. Krug email: Raineratkrugsdotde PGP: 0x0F52F982 pgpgwRb2DIvl8.pgp Description: PGP signature
Re: [O] [ Bug] tsia-{up, down} sorting strategy not working for tags search agendas
Subhan Michael Tindall wrote:
I have the following agendas (among others) defined:
(x Last worked ((alltodo ( (org-agenda-sticky nil)
(org-agenda-sorting-strategy (quote (tsia-up
todo-state-down)))
(y Last worked2 ((tags LastWorked={.+} (
(org-agenda-sticky nil)
(org-agenda-sorting-strategy (quote (tsia-up
todo-state-down)))
I have a property defined in headlines that have been worked on:
:PROPERTIES:
:LastWorked: [2014-09-02 Tue 16:02]
:END:
TODOs etc that have not been worked yet don't have this property.
The top search (x) creates an agenda with items with a LastWorked property
sorted with the least recent first, down to most recent, followed by any items
with the LastWorked property unset sorted by todo-state.
The bottom search (y) creates an agenda with only items with LastWorked
property set (which I want) but completely ignores the tsia-up sorting
strategy
and sorts only by todo-state.
I have confirmed that org-agenda-sorting-strategy-selected is correct in both
cases.
The only difference is the agenda type (tags vs alltodo)
Any ideas where to look for this ?
I guess it's directly linked to a problem I reported last
September. This is indeed annoying...
See issue #29 on http://orgmode.org/worg/org-issues.html (and see the
pointed thread).
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [Bug?] Results of code block printed in wrong place
Hello Nicolas, On Mo, 2014-09-22 at 17:29 +0200, Nicolas Goaziou wrote: FWIW, I cannot reproduce it. This was quite painful to isolate, but I’ve now identified a minimal configuration which should trigger this bug. ── ;; BEGIN minimal.el (add-to-list 'load-path (expand-file-name ~/.emacs.d/elpa/org-20140922)) ;; Example needs sh; might also trigger with other langs. (org-babel-do-load-languages 'org-babel-load-languages '((sh .t))) (fset 'yes-or-no-p 'y-or-n-p) (defun my-org-mode-hook () (follow-mode)) (add-hook 'org-mode-hook 'my-org-mode-hook) ;; END minimal.el ── This seems rather bizarre. Both follow-mode and the y-or-n-p alias work in isolation, but when both are used at the same time, I observe the bug initially described. Can you confirm this? Best regards, Tobias
Re: [O] autosave in org-src buffer only works ones
Hi, is it possible that these function cause the buffer automatically scrolling when saving? When I save My buffer jumps/scrolls up so that my cursor is on the last row on my screen. Greets 2014-09-11 23:55 GMT+02:00 Adriaan Sticker adriaan.stic...@gmail.com: Cool, thanks! 2014-09-11 18:28 GMT+02:00 Nicolas Goaziou m...@nicolasgoaziou.fr: Hello, Adriaan Sticker adriaan.stic...@gmail.com writes: I've the following in my init.el (setq org-edit-src-auto-save-idle-delay 5) If I open in my org file a R code block with C-c ', edit into the opened org-src buffer with the ESS major mode activated and wait for 5s, I can see autosave kicking in and my org buffer gets updated with my new code. But when I keep editing it doesn't save anymore. So it only save ones after the first 5s when the org-src got openend and then it stops. This should now be fixed. Thank you for reporting it. Regards, -- Nicolas Goaziou
Re: [O] Struggling with new exporter
Nicolas Goaziou m...@nicolasgoaziou.fr writes: [...] `org-html-publish-to-html' is not meant to be called directly, but rather used in a project definition as a :publishing-function value. Speaking of which, why don't you simply create a proper project-alist and call `org-publish' on it (interactively or not)? Okay, I've done it this way. Took a bit of fiddling since I need the project-alist to work in different configurations (i.e. interactively, in batch and in batch on a CI machine). Also, the timestamp stuff confused me -- org was skipping publication, even though the output file had been deleted. This part... #+BIND: org-latex-custom-lang-environments ((clojure tawny)) #+BIND: org-latex-listings t isn't working at the moment. Source listings are coming out in verbatim. Can I set this in the project-alist. From looking at org-latex-src-block it would appear not. Phil
Re: [O] CV in orgmode for export to pdf (and html?
Rainer M Krug rai...@krugs.de writes: Thanks for the summary Rainer. I think that org could be a perfect environment for building CVs if one could come up with an HOWTO and many examples how to do it - and I think this is going into the right direction. I think the right approach is cooking up a reasonable way to represent CVs and make an ox-cv with a customized interface (like ox-koma-letter where ordering of blocks can also be changed on-the-go) and provide some nice default themes. It should either build on an established LaTeX cv package or just KOMA-Script like Xavier's CV (and mine). I didn't check the ox-cv.el that was posted carefully. That being said, I don't have much time for this right now. It would be nicer to handle something like a CV in org than LaTeX. Cheers, Rasmus -- Evidence suggests Snowden used a powerful tool called monospaced fonts
Re: [O] Bug: LaTeX export produces no output; clobbering keybindings [8.2.7c(8.2.7c-64-g01f736-elpa@/home/tbg/.emacs.d/elpa/org-20140915/)]
On Wed, 17 Sep 2014 09:29:48 +, Tobias Getzner wrote: On Wed, 17 Sep 2014 08:27:21 +, Tobias Getzner wrote: When using LaTeX-based export targets that produce a .tex file as output (export to LaTeX file, PDF, PDF and open), I receive the message «Buffer foo.tex modified; kill anyway?». Irrespective of whether I answer y/n, no .tex file is produced, and «latexmk» fails with «no such file». Both after issuing the file-producing exports, and when issuing exports to buffer only (export to LaTeX buffer), the keybindings in the original org-mode buffer become garbled; e. g., issuing another «C-c C-e» after attempting a LaTeX export no longer invokes the export menu, but is now bound to the command «LaTeX-enviroment». I seem to have located the trigger. Inter alia, my TeX-mode-hook invokes «(TeX-source-correlate-mode)» which sets a variable so that synctex files are generated when running AucTeX commands. When this command is removed, exporting to .tex files appears to work again and the keybindings remain unchanged after export. Is this a bug, or is some configuration required to make org-mode not trip over the TeX-mode hook? This behavior seems to be related to [1] in that it only triggers when follow-mode is used. I’ve noticed I can keep my TeX-mode-hook unchanged if I disable follow-mode. I contrast to [1], no interaction with aliasing yes-or-no-p to y-or-n-p seemed to be present, though. [1] http://article.gmane.org/gmane.emacs.orgmode/91006
Re: [O] CV in orgmode for export to pdf (and html?
Rasmus ras...@gmx.us writes: Hi, Rainer M Krug rai...@krugs.de writes: Thanks for the summary Rainer. Hope I didn't forget anything... I think that org could be a perfect environment for building CVs if one could come up with an HOWTO and many examples how to do it - and I think this is going into the right direction. I think the right approach is cooking up a reasonable way to represent CVs and make an ox-cv with a customized interface (like ox-koma-letter where ordering of blocks can also be changed on-the-go) and provide some nice default themes. It should either build on an established LaTeX cv package or just KOMA-Script like Xavier's CV (and mine). I didn't check the ox-cv.el that was posted carefully. Yes - this might be the most org-ish approach, and the most stable (over time). That being said, I don't have much time for this right now. Isn't there a worg / org page, where these ideas are collected (TODO? Feature Requests, ...)? I fear that this becomes forgotten again (including myself!), as CVs are not something one uses regularly... I unfortunately have not the elisp knowledge to contribute much here. It would be nicer to handle something like a CV in org than LaTeX. I completely agree with you - I have it at the moment in LyX, but I am fixing issues each time I need a CV. Cheers, Rainer Cheers, Rasmus -- Rainer M. Krug PGP: 0x0F52F982 pgpy7v8eB7geD.pgp Description: PGP signature
Re: [O] [bug?] org-copy-face doesn’t add faces to org-faces customize group
Hi Aaron, Aaron Ecay wrote: 2014ko abuztuak 29an, Sebastien Vauban-ek idatzi zuen: I think it's related to an Emacs bug (#16440) which I reported on the Org mailing list in February. I don’t completely understand what is going on in that bug report. My proposal is to convert org-copy-face to defface. I think this is the right thing (TM). I can’t tell if this would fix your problem or not, but if it’s exclusive to the faces I listed in my previous email the answer is probably “yes.” From what I can see, yes, the faces which are wrongly displayed (before re-applying the theme) match the ones defined by `org-copy-face'. So, this seems the right way to go. Best regards, Seb -- Sebastien Vauban
Re: [O] [Bug?] Results of code block printed in wrong place
On Tue, 23 Sep 2014 10:22:45 +0200, Tobias Getzner wrote: This was quite painful to isolate, but I’ve now identified a minimal configuration which should trigger this bug. ── ;; BEGIN minimal.el (add-to-list 'load-path (expand-file-name ~/.emacs.d/elpa/org-20140922)) ;; Example needs sh; might also trigger with other langs. (org-babel-do-load-languages 'org-babel-load-languages '((sh .t))) (fset 'yes-or-no-p 'y-or-n-p) (defun my-org-mode-hook () (follow-mode)) (add-hook 'org-mode-hook 'my-org-mode-hook) ;; END minimal.el ── This seems rather bizarre. Both follow-mode and the y-or-n-p alias work in isolation, but when both are used at the same time, I observe the bug initially described. I’ve found this bug might be related to [1], where org-mode seems to trip when both follow-mode and TeX-source-correlate-mode are active. [1] does not seem to interact with aliasing yes-or-no-p, though. [1] http://article.gmane.org/gmane.emacs.orgmode/91009
Re: [O] org-element-at-point fails in programming-modes
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Thorsten Jolitz tjol...@gmail.com writes: Ok, thanks, that sounds promising. OTOH, is the use of \\S- really mandatory, No, it isn't. couldn't a more robust construct be used, either something like this (untested) regexp: , | [^[:space:]\\n]+ ` AFAIK, [:space:] is not compatible with XEmacs. It could be [^ \r\t\n]+, but even this could be too broad (e.g., #+BEGIN_...). We could also limit block names to alphanumeric characters and a bunch of symbols. I noticed this issue again when calling `org-element-at-point` with point before the stars in , | ** [#A] whatsup :mytag:it: | hello world ` in an emacs-lisp-mode buffer - it results in: , | (paragraph (:begin 193 :end 246 :contents-begin 206 :contents-end 245 | :post-blank 1 :post-affiliated 206 ...)) ` so it kind-of works outside org major-mode, but not correctly due to character-class problem in the regexp(s). PS My org-mode is up to date #+BEGIN_SRC emacs-lisp (call-interactively 'org-version) #+END_SRC #+results: : Org-mode version 8.3beta (release_8.3beta-277-g698705 @ /usr/share/emacs/24.3/lisp/org/lisp/) -- cheers, Thorsten
[O] [BUG] void-variable `org-planning-line-re'
Hi List, seems it was renamed to ,[ C-h v org-planning-or-clock-line-re RET ] | org-planning-or-clock-line-re is a variable defined in `org.el'. | Its value is [...] | Documentation: | Matches a line with planning info. | Matched keyword is in group 1. ` Calling 'org-element-at-point on #+BEGIN_ORG #+NAME: foo #+END_ORG = , | Debugger entered--Lisp error: (void-variable org-planning-line-re) | org-element--current-element(163 element planning nil) | [...] | org-element--parse-to(16) | org-element-at-point() | eval((org-element-at-point) nil) | eval-expression((org-element-at-point) nil) | call-interactively(eval-expression nil nil) ` PS #+BEGIN_SRC emacs-lisp (call-interactively 'org-version) #+END_SRC #+results: : Org-mode version 8.3beta (release_8.3beta-277-g698705 @ /usr/share/emacs/24.3/lisp/org/lisp/) -- cheers, Thorsten
Re: [O] [BUG] void-variable `org-planning-line-re'
Thorsten Jolitz tjol...@gmail.com writes: sorry for the noise, and Emacs restart fixed the issue. Hi List, seems it was renamed to ,[ C-h v org-planning-or-clock-line-re RET ] | org-planning-or-clock-line-re is a variable defined in `org.el'. | Its value is [...] | Documentation: | Matches a line with planning info. | Matched keyword is in group 1. ` Calling 'org-element-at-point on #+BEGIN_ORG #+NAME: foo #+END_ORG = , | Debugger entered--Lisp error: (void-variable org-planning-line-re) | org-element--current-element(163 element planning nil) | [...] | org-element--parse-to(16) | org-element-at-point() | eval((org-element-at-point) nil) | eval-expression((org-element-at-point) nil) | call-interactively(eval-expression nil nil) ` PS #+BEGIN_SRC emacs-lisp (call-interactively 'org-version) #+END_SRC #+results: : Org-mode version 8.3beta (release_8.3beta-277-g698705 @ /usr/share/emacs/24.3/lisp/org/lisp/) -- cheers, Thorsten
[O] [BUG] Mark-up handling chokes on unicode whitespace
When mark-up such as =monospace=, /italic/, etc. is preceded by a non-8bit whitespace, e. g., «narrow no-break space» (U+202F) or «no-break space» (U+00A0), org-mode will not recognize the mark-up content correctly; i. e., this content will fail to be syntax-highlighted, and the mark-up syntax will be exported in verbatim by the exporter. Best regards, Tobias
[O] [patchattached] Store link to url of eww
Hello all, since eww comes bundled with Emacs nowadays it feels natural to be able store a link to the current url of an eww buffer. This functionality has already been in place for w3m for a while. Find a respective patch attached. I hope the fact that the patch is attached is acceptable as well as the patch itself. Best wishes, Marco -- http://www.wahlzone.de PGP: 0x0A3AE6F2 From a4ead864a14931ef2a8dd43719fb6ee90861d346 Mon Sep 17 00:00:00 2001 From: Marco Wahl marcowahls...@gmail.com Date: Tue, 23 Sep 2014 09:46:34 +0200 Subject: [PATCH] org-eww: Org-module to store url from eww * contrib/lisp/org-eww.el: New file * contrib/lisp/org-eww.el(org-eww-store-link): Hook to store a link. * contrib/README: Added a line for the org-eww. * lisp/org.el (org-modules): Add org-eww to the pool of org-modules. The hook gets hooked in the module. The file is more or less a fraction of the org-w3m module with 'w3m' replaced by 'eww'. TINYCHANGE --- contrib/README | 1 + contrib/lisp/org-eww.el | 54 + lisp/org.el | 1 + 3 files changed, 56 insertions(+) create mode 100644 contrib/lisp/org-eww.el diff --git a/contrib/README b/contrib/README index e92da14..7bffeee 100644 --- a/contrib/README +++ b/contrib/README @@ -29,6 +29,7 @@ org-element.el --- Parser and applications for Org syntax org-elisp-symbol.el --- Org links to emacs-lisp symbols org-eval-light.el--- Evaluate in-buffer code on demand org-eval.el --- The lisp tag, adapted from Muse +org-eww.el --- Store link to url of eww org-expiry.el--- Expiry mechanism for Org entries org-export-generic.el--- Export framework for configurable backends org-git-link.el --- Provide org links to specific file version diff --git a/contrib/lisp/org-eww.el b/contrib/lisp/org-eww.el new file mode 100644 index 000..c25057d --- /dev/null +++ b/contrib/lisp/org-eww.el @@ -0,0 +1,54 @@ +;;; org-eww.el --- Storing link in eww-mode for Org-mode + +;; Copyright (C) 2014 Free Software Foundation, Inc. + +;; Author: Marco Wahl marcowahlsoftagmailcom +;; Keywords: link, eww +;; Homepage: http://orgmode.org +;; +;; This file is not part of GNU Emacs. +;; +;; This program is free software: you can redistribute it and/or modify +;; it under the terms of the GNU General Public License as published by +;; the Free Software Foundation, either version 3 of the License, or +;; (at your option) any later version. + +;; This program is distributed in the hope that it will be useful, +;; but WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +;; GNU General Public License for more details. + +;; You should have received a copy of the GNU General Public License +;; along with GNU Emacs. If not, see http://www.gnu.org/licenses/. + + +;;; Commentary: + +;; When this module is active `org-store-link' (often on key C-c l) in +;; a eww buffer stores a link to the current url of the eww buffer. + +;; `org-eww-store-link' below is almost the same as +;; `org-w3m-store-link' of the org-w3m module. + +;; Hint: There are further features in module org-w3m which might be +;; interesting for org-eww also. + + +;;; Code: + +(require 'org) + +(add-hook 'org-store-link-functions 'org-eww-store-link) +(defun org-eww-store-link () + Store a link to the url of a eww buffer. + (when (eq major-mode 'eww-mode) +(org-store-link-props + :type eww + :link eww-current-url + :url (url-view-url t) + :description (or eww-current-title eww-current-url + + +(provide 'org-eww) + +;;; org-eww.el ends here diff --git a/lisp/org.el b/lisp/org.el index b09e72d..0bf91d3 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -640,6 +640,7 @@ For export specific modules, see also `org-export-backends'. (const :tag C eshell Support for links to working directories in eshell org-eshell) (const :tag C eval-light:Evaluate inbuffer-code on demand org-eval-light) (const :tag C eval: Include command output as text org-eval) + (const :tag C eww: Store link to url of eww org-eww) (const :tag C expiry:Expiry mechanism for Org-mode entries org-expiry) (const :tag C favtable: Lookup table of favorite references and links org-favtable) (const :tag C git-link: Provide org links to specific file version org-git-link) -- 2.1.0
Re: [O] Managing articles in orgmode and collaboration
Jorge A. Alfaro-Murillo wrote: Perhaps I am biased because I learned LaTeX and BibTeX before Org, but I think that for references BibTeX (plus a little bit of emacs configuration) has everything I could need. I guess if you are more used to Org, it might be worth to invest time and come up with a org-based solution. Please keep us posted, I find this a very interesting thread. This is an update about my experiments so far. Please comment! This is my current setup: All the articles (mostly PDF files) are kept in one directory. There’s also an index.org file in there with headlines like this --8---cut here---start-8--- ** [[file:vazifeh13-electromagnetic_response_weyl.pdf][Electromagnetic Response of Weyl Semimetals]] :PROPERTIES: :TITLE:Electromagnetic Response of Weyl Semimetals :BTYPE:article :ID: vazifeh13-electromagnetic_response_weyl :AUTHOR: Vazifeh, M. M. and Franz, M. :JOURNAL: Phys. Rev. Lett. (…) :END: Some comments/notes with links and in-line formulas. --8---cut here---end---8--- These entries are created by org-bibtex-yank, Emacs’ bibtex is configured to generate the unique IDs (authorYY-three_first_words should be sufficiently unique in practice). This setup works pretty well: - Adding new articles is easy (there's still ample room for improvement). - Opening associated the associated article files and other links works well. - It’s easy to add notes (with in-line maths!) and do simple searches. - Linking from and to other org files (agenda, project-specific notes) is possible. - Additional attachment files (e.g. whiteboard photos from a discussion) can added with org-attach. - org-bibtex provides support to put entries into project-specific bibtex files (org-bibtex-export-to-kill-ring). - Thanks to the non-random unique IDs, it’s possible to jump to articles in the library from references in latex files, even if the key scheme in the latex file differs from the one used in index.org. But not all is good: - Scaling: Some simple tests seem to indicate that org mode becomes too sluggish with files of about 50k lines. This is a dimension that could be easily reached over 10 years if the file grows by 20 lines per day on average. This is not a problem in the beginning, but if the scheme does not scale to a few thousand entries, this renders the whole idea way less interesting. - More advanced searching is lacking: AFAIK org mode currently does not support searching for articles of a given author that also contain a given keyword in the notes. Any insights about these two problems? Perhaps the scaling could be managed by splitting index.org into several files (by year for example). But how to search then? It's probably not a good idea to add all the bibliography org-files into the agenda. (Is there a way to have a secondary list of agenda files?) Perhaps the solution for both problems would be to write a fast commandline query tool for such org-databases? The tool could even use a fast cache if necessary.
Re: [O] TODO items in lists (not headings)
On Thu, Sep 18, 2014 at 2:49 PM, Gary Oberbrunner ga...@oberbrunner.com wrote: On Thu, Sep 18, 2014 at 12:23 PM, Subhan Michael Tindall subh...@familycareinc.org wrote: Lists are very explicitly not intended to contain TODO items. Checkboxes provide a bit of this functionality, sort of a ‘TODO lite’ ... The problem is that list items/checkbox items are NOT headlines, and all the TODO code etc. is tied to headlines. I haven’t looked at the code but I suspect an extensive rewrite to integrate it with the rest of the headline code. Not as much if it’s kept as an isolated extension. I suspected as much. Although having TODOs in lists would be awesome, checkboxes will do for me now. One more followup on this: it turns out I don't need to use plain lists nearly as often as I had thought! I didn't understand that org-mode export automatically makes headers greater than N into lists (at least with the H:N option). So in many cases I can actually use headers (including TODOs) and get all the benefits there (including not just TODOs but attributes and so on) while still having my exported document look like bulleted lists. Org-mode ftw! -- Gary
[O] Keeping metadata/notes about files and directories
Dear all, I just wrote under the subject “Re: Managing articles in org mode and collaboration”. This posting puts the other one in a broader context. While thinking about organizing articles, I asked myself: Wouldn’t it be useful to keep metadata/notes about *various* kinds of files/sub-directories/projects inside org-mode (or something similar)? One example is a collection of programming projects. Just like for articles, it would be useful to add notes and metadata to each project. The same is true for many other archive-like collections of things that grow over time. The same problems appear as described in the other posting (namely scaling and searching). I know that there have been discussions about this in the past, and I know that there’s org-annotate-file. Is there anyone who uses a scheme like this (for 1000 items, say) in practice? Christoph
Re: [O] Managing articles in orgmode and collaboration
Christoph Groth writes: But not all is good: - Scaling: Some simple tests seem to indicate that org mode becomes too sluggish with files of about 50k lines. This is a dimension that could be easily reached over 10 years if the file grows by 20 lines per day on average. This is not a problem in the beginning, but if the scheme does not scale to a few thousand entries, this renders the whole idea way less interesting. - More advanced searching is lacking: AFAIK org mode currently does not support searching for articles of a given author that also contain a given keyword in the notes. Any insights about these two problems? Perhaps the scaling could be managed by splitting index.org into several files (by year for example). But how to search then? It's probably not a good idea to add all the bibliography org-files into the agenda. (Is there a way to have a secondary list of agenda files?) Perhaps the solution for both problems would be to write a fast commandline query tool for such org-databases? The tool could even use a fast cache if necessary. BibTeX provides bibtex-search-entries (in a bib file it is bound to C-c C-a), which searches for entries with a certain field matching a regexp. Perhaps you want to take advantage of that function to direct your org searches to bib files and back. Check also bibtex-files and bibtex-search-entry-globally, since you would then be able to split the org files and export into several bib files if a single bib file proves too much. My current articles.bib is about 14k lines, and it is not sluggish at all, but I will have to wait a couple of years until I tell you if a 50k one would be. Best, -- Jorge.
Re: [O] [ Bug] tsia-{up, down} sorting strategy not working for tags search agendas
-Original Message-
From: emacs-orgmode-bounces+subhant=familycareinc@gnu.org
[mailto:emacs-orgmode-bounces+subhant=familycareinc@gnu.org] On
Behalf Of Sebastien Vauban
Sent: Tuesday, September 23, 2014 12:57 AM
To: emacs-orgmode@gnu.org
Subject: Re: [O] [ Bug] tsia-{up, down} sorting strategy not working for tags
search agendas
Subhan Michael Tindall wrote:
I have the following agendas (among others) defined:
(x Last worked ((alltodo ( (org-agenda-sticky nil)
(org-agenda-sorting-strategy (quote (tsia-up
todo-state-down))) (y Last worked2 ((tags LastWorked={.+} (
(org-agenda-sticky nil)
(org-agenda-sorting-strategy (quote (tsia-up
todo-state-down)))
I have a property defined in headlines that have been worked on:
:PROPERTIES:
:LastWorked: [2014-09-02 Tue 16:02]
:END:
TODOs etc that have not been worked yet don't have this property.
The top search (x) creates an agenda with items with a LastWorked
property sorted with the least recent first, down to most recent,
followed by any items with the LastWorked property unset sorted by todo-
state.
The bottom search (y) creates an agenda with only items with
LastWorked property set (which I want) but completely ignores the
tsia-up sorting strategy and sorts only by todo-state.
I have confirmed that org-agenda-sorting-strategy-selected is correct in
both cases.
The only difference is the agenda type (tags vs alltodo)
Any ideas where to look for this ?
I guess it's directly linked to a problem I reported last September. This is
indeed annoying...
See issue #29 on http://orgmode.org/worg/org-issues.html (and see the
pointed thread).
Best regards,
Seb
--
Sebastien Vauban
Indeed, it does appear to be the same issue. I assuming no progress on fixing
it?
I guess that leaves me with two workarounds (suitable for my purposes anyway):
Use the alltodo search type and either
A) write a customized skip function to exclude any entries without a
'LastWorked' property entry
Or
B) write a customized sort so that empty entries sort to the bottom, not the
top (possibly in both directions IE
ABCDE for tsia-up, DCBAE for tsia-down
Either of these will get me what I want. I'm a reasonably competent
programmer, a minimal elisper, and have almost no familiarity with the org
code. Any suggestions on which of these would be easier or more
straightforward?
I did take a look through the code to see if I could sort this out myself, but
couldn't really make heads or tails of it.
This message is intended for the sole use of the individual and entity to which
it is addressed and may contain information that is privileged, confidential
and exempt from disclosure under applicable law. If you are not the intended
addressee, nor authorized to receive for the intended addressee, you are hereby
notified that you may not use, copy, disclose or distribute to anyone the
message or any information contained in the message. If you have received this
message in error, please immediately advise the sender by reply email and
delete the message. Thank you.
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Aaron may I trouble you to add a flag so that if such errors occur then the export fails? From my perspective, if the document doesn't compile, then nothing should succeed. Compile includes export from my perspective. On Mon, Sep 22, 2014 at 10:25 PM, Aaron Ecay aarone...@gmail.com wrote: Hi Nicolas, 2014ko irailak 19an, Nicolas Goaziou-ek idatzi zuen: Certainly not a message, due to asynchronous export. Very good point. 2. Since this is a feature that many backends will want to use, should we introduce a new “abstract” backend from which other backends can inherit, which incorporates this feature, and others like it in the future? The idea would be similar to prog-mode in emacs, the major mode from which programming-language modes can derive. The alternative is adding the (macro . org-export-macro-warn) entry manually to all the relevant backends, and relying on future backend authors to do the same. 3. Should this even be implemented as part of the backend’s translate-alist, or at a lower level? Don't bother with export back-ends, they never get to see macros, which are expanded very early in the export process. This explains, for example, why there is no `macro' translator. Um...but the patch I sent works precisely by defining a macro translator, which does get called for any unexpanded (because undefined) macros. I guess you’re saying the code ought to block this at a lower/earlier level. You have two options. Either report an error, as you suggested, or insert an obnoxious message in the output, e.g., UNKNOWN MACRO, à la DEFINITION NOT FOUND. for footnote definitions. In any case, this should happen in org-macro.el, not in the export framework. I think error is better than obnoxious message, because it’s possible for the latter to slip through into a “production” document. (We ought to proofread our documents carefully, of course...but no one’s perfect). One issue is that the exporter does two macro expansion passes – one for garden-variety macros, and the second for author, date, email, and title. So, we can’t make the macro expansion unconditionally barf on undefined macros (since for the first pass e.g. author is undefined). I see three options: 1. explicitly whitelist the few “blessed” macros like author, and error on any other undefined macro 2. add an optional “final” arg to org-macro-replace-all, which will activate the undefined checking only if non-nil, and pass this flag in the exporter’s second (and last) call to org-macro-replace-all 3. in ‘org-export-as’, manually walk the parse tree after expanding macros, and make sure no 'macro type objects are left WDYT? -- Aaron Ecay -- Grant Rettke g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] [BUG] Mark-up handling chokes on unicode whitespace
Hi Tobias, 2014ko irailak 23an, Tobias Getzner-ek idatzi zuen: When mark-up such as =monospace=, /italic/, etc. is preceded by a non-8bit whitespace, e. g., «narrow no-break space» (U+202F) or «no-break space» (U+00A0), org-mode will not recognize the mark-up content correctly; i. e., this content will fail to be syntax-highlighted, and the mark-up syntax will be exported in verbatim by the exporter. You will need to change the variable org-emphasis-regexp-components; see the documentation thereof. -- Aaron Ecay
Re: [O] [patchattached] Store link to url of eww
Hi Marco, Thanks for your patch. TINYCHANGES can only be smaller than 15 lines, though, and your patch has more than that (even if we discount boilerplate like the license notice). So you should probably do the copyright assignment which is described at http://orgmode.org/worg/org-contribute.html#sec-2. -- Aaron Ecay
[O] How to utilize the vc package inside of the edit source block buffer?
Good afternoon, The ability to org-edit-special inside of source block is truly priceless. There is a delightful workflow to be found with approach. It has got me spending more and more time in the edit buffer though, wanting to utilize vc-next-action to initiate a commit. This is not possible because the buffer is not associated with a file. Is there some way to get tell Emacs to execute the action on the source buffer from which the source edit block buffer originated? My apologies as I have not been able to locate the post where this topic was originally discussed. Kind regards, -- Grant Rettke g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
Re: [O] [patchattached] Store link to url of eww
Hi again, 2014ko irailak 23an, Aaron Ecay-ek idatzi zuen: Hi Marco, Thanks for your patch. TINYCHANGES can only be smaller than 15 lines, though, and your patch has more than that (even if we discount boilerplate like the license notice). So you should probably do the copyright assignment which is described at http://orgmode.org/worg/org-contribute.html#sec-2. I should have said: the copyright assignment isn’t strictly needed for code in contrib. But since this module is an interface between two emacs built-in modules, it is a good candidate for moving to core eventually, where the copyright assignment would be needed. So, I didn’t mean to imply that the copyright assignment would be a hard condition on merging your patch, but IMO it would be helpful. -- Aaron Ecay
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Hi Grant, 2014ko irailak 23an, Grant Rettke-ek idatzi zuen: Aaron may I trouble you to add a flag so that if such errors occur then the export fails? From my perspective, if the document doesn't compile, then nothing should succeed. Compile includes export from my perspective. Indeed, that’s the direction that the next iteration of this patch will move, motivated by your and Nicolas’s comments. Thanks, -- Aaron Ecay
Re: [O] [bug?] org-copy-face doesn’t add faces to org-faces customize group
Hi Seb, 2014ko irailak 23an, Sebastien Vauban-ek idatzi zuen: Hi Aaron, Aaron Ecay wrote: 2014ko abuztuak 29an, Sebastien Vauban-ek idatzi zuen: I think it's related to an Emacs bug (#16440) which I reported on the Org mailing list in February. I don’t completely understand what is going on in that bug report. My proposal is to convert org-copy-face to defface. I think this is the right thing (TM). I can’t tell if this would fix your problem or not, but if it’s exclusive to the faces I listed in my previous email the answer is probably “yes.” From what I can see, yes, the faces which are wrongly displayed (before re-applying the theme) match the ones defined by `org-copy-face'. So, this seems the right way to go. OK, thanks for the followup. I’m attaching the patch to this email. If I don’t hear any further feedback, I’ll commit it to master in a few days. From 128726a88ca2ec2232071cd9a6d7869df01fd953 Mon Sep 17 00:00:00 2001 From: Aaron Ecay aarone...@gmail.com Date: Tue, 23 Sep 2014 13:21:22 -0400 Subject: [PATCH] org-faces: remove org-copy-face MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * lisp/org-faces.el (org-copy-face): Remove function. (org-checkbox-statistics-todo, org-checkbox-statistics-done) (org-block-begin-line, org-block-end-line, org-quote) (org-verse, org-agenda-date, org-agenda-date-today) (org-agenda-clocking, org-agenda-date-weekend) (org-agenda-current-time, org-mode-line-clock) (org-mode-line-clock-overrun): Convert to `defface' from `org-copy-face'. The ‘org-copy-face’ function didn’t properly deal with face customizations and color themes. --- lisp/org-faces.el | 96 +++ 1 file changed, 54 insertions(+), 42 deletions(-) diff --git a/lisp/org-faces.el b/lisp/org-faces.el index 6e62ad0..36f810e 100644 --- a/lisp/org-faces.el +++ b/lisp/org-faces.el @@ -31,19 +31,6 @@ (require 'org-macs) (require 'org-compat) -(defun org-copy-face (old-face new-face docstring rest attributes) - (unless (facep new-face) -(if (fboundp 'set-face-attribute) - (progn - (make-face new-face) - (set-face-attribute new-face nil :inherit old-face) - (apply 'set-face-attribute new-face nil attributes) - (set-face-doc-string new-face docstring)) - (copy-face old-face new-face) - (if (fboundp 'set-face-doc-string) - (set-face-doc-string new-face docstring) -(put 'org-copy-face 'lisp-indent-function 2) - (when (featurep 'xemacs) (put 'mode-line 'face-alias 'modeline)) @@ -427,12 +414,15 @@ determines if it is a foreground or a background color. Face for checkboxes. :group 'org-faces) +(defface org-checkbox-statistics-todo + '((t (:inherit org-todo))) + Face used for unfinished checkbox statistics. + :group 'org-faces) -(org-copy-face 'org-todo 'org-checkbox-statistics-todo - Face used for unfinished checkbox statistics.) - -(org-copy-face 'org-done 'org-checkbox-statistics-done - Face used for finished checkbox statistics.) +(defface org-checkbox-statistics-done + '((t (:inherit org-done))) + Face used for finished checkbox statistics. + :group 'org-faces) (defcustom org-tag-faces nil Faces for specific tags. @@ -537,11 +527,15 @@ follows a #+DATE:, #+AUTHOR: or #+EMAIL: keyword. :group 'org-faces :version 22.1) -(org-copy-face 'org-meta-line 'org-block-begin-line - Face used for the line delimiting the begin of source blocks.) +(defface org-block-begin-line + '((t (:inherit org-meta-line))) + Face used for the line delimiting the begin of source blocks. + :group 'org-faces) -(org-copy-face 'org-meta-line 'org-block-end-line - Face used for the line delimiting the end of source blocks.) +(defface org-block-end-line + '((t (:inherit org-block-begin-line))) + Face used for the line delimiting the end of source blocks. + :group 'org-faces) (defface org-verbatim (org-compatible-face 'shadow @@ -557,10 +551,15 @@ follows a #+DATE:, #+AUTHOR: or #+EMAIL: keyword. :group 'org-faces :version 22.1) -(org-copy-face 'org-block 'org-quote - Face for #+BEGIN_QUOTE ... #+END_QUOTE blocks.) -(org-copy-face 'org-block 'org-verse - Face for #+BEGIN_VERSE ... #+END_VERSE blocks.) +(defface org-quote + '((t (:inherit org-block))) + Face for #+BEGIN_QUOTE ... #+END_QUOTE blocks. + :group 'org-faces) + +(defface org-verse + '((t (:inherit org-block))) + Face for #+BEGIN_VERSE ... #+END_VERSE blocks. + :group 'org-faces) (defcustom org-fontify-quote-and-verse-blocks nil Non-nil means, add a special face to #+begin_quote and #+begin_verse block. @@ -597,21 +596,28 @@ content of these blocks will still be treated as Org syntax. Face used in agenda for captions and dates. :group 'org-faces) -(org-copy-face 'org-agenda-structure 'org-agenda-date - Face used in agenda for normal days.) +(defface org-agenda-date + '((t (:inherit org-agenda-structure))) + Face used in agenda for normal days. +
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
While I expect that there's no code overlap with macro expansion, I asked about similar stop on unresolved content behavior with respect to links here: http://article.gmane.org/gmane.emacs.orgmode/90010/ That discussion died off so I thought I'd bring up the topic again here. Would it be possible to cause export to stop (configurably, as discussed) when a link can't be resolved instead of just applying a special format (i.e. org-latex-link-with-unknown-path-format) On Tue, Sep 23, 2014 at 1:18 PM, Aaron Ecay aarone...@gmail.com wrote: Hi Grant, 2014ko irailak 23an, Grant Rettke-ek idatzi zuen: Aaron may I trouble you to add a flag so that if such errors occur then the export fails? From my perspective, if the document doesn't compile, then nothing should succeed. Compile includes export from my perspective. Indeed, that’s the direction that the next iteration of this patch will move, motivated by your and Nicolas’s comments. Thanks, -- Aaron Ecay
Re: [O] resizing windows from an org buffer, reqest for org-shiftcontrolcursor-final-hook
Hi Bradley, 2014ko irailak 16an, Brady Trainor-ek idatzi zuen: I have (global-set-key (kbd S-C-left) 'shrink-window-horizontally) (global-set-key (kbd S-C-right) 'enlarge-window-horizontally) (global-set-key (kbd S-C-down) 'shrink-window) (global-set-key (kbd S-C-up) 'enlarge-window) in my init file, as suggested at http://www.emacswiki.org/emacs-en/WindowResize. However, when I am in an org file, the binding fails. I had hoped that (setq org-support-shift-select t) would fix this, but it only seems to want to allow selection. A solution might be similar to the one ;; quick keys for switching windows (windmove-default-keybindings) ;; fix windmove in org-mode (add-hook 'org-shiftup-final-hook 'windmove-up) (add-hook 'org-shiftleft-final-hook 'windmove-left) (add-hook 'org-shiftdown-final-hook 'windmove-down) (add-hook 'org-shiftright-final-hook 'windmove-right) as suggested at http://orgmode.org/manual/Conflicts.html. Looking at the code in org.el, it seems org-shiftcontrolup and the like were not so lucky to get such a final-hook. Can this be added? I am currently using package.el org-mode, so I may not immediately get to try it out, but would look forward to adding it to my workflow soon. Rather than adding a hook to these functions, perhaps we should add another branch to their conditionals which tries (lookup-key global-map (this-command-keys)), and calls that function if it exists. The error would be raised as before if there is no binding for the key in global-map. How’s your elisp? Would you feel up to trying to create such a patch? -- Aaron Ecay
Re: [O] [BUG] Mark-up handling chokes on unicode whitespace
Hello Aaron! On Tue, 23 Sep 2014 13:03:06 -0400, Aaron Ecay wrote: 2014ko irailak 23an, Tobias Getzner-ek idatzi zuen: When mark-up such as =monospace=, /italic/, etc. is preceded by a non-8bit whitespace, e. g., «narrow no-break space» (U+202F) or «no-break space» (U+00A0), org-mode will not recognize the mark-up content correctly You will need to change the variable org-emphasis-regexp-components; see the documentation thereof. Thank you very much! This seems to do it. Might I suggest amending unicode whitespace to the default? That variable seems a bit opaque and I might probably never have discovered it on my own; it also appears as if one has to ensure that this is set before org- mode is «required», and one cannot easily just extend the default without also setting the rest. For type-setting purposes, at least the class of non-breaking whitespace is very useful. At first I thought it might be easy to cleanly solve such problems by using the whitespace character class throughout, but to my chagrin it seems that at least «search-forward-regexp» will only match 8-bit whitespace this way, so I suppose Emacs regex isn’t aware of non-ASCII whitespace? :'| Best, Tobias
Re: [O] Call speed-commands with prefix-arg?
Hi Thorsten, 2014ko irailak 18an, Thorsten Jolitz-ek idatzi zuen: Hi List, is there a way to call Org speed-commands [fn:1] with a prefix-arg? Does not work for me ... The attached patch should allow this. You can use C-u N X or C-N X (where N is some digits and X a speed command key). I’ll commit it to master in a few days (along with an entry in ORG-NEWS), unless there is any feedback. It might be cool to also allow digits 0-9 and hyphen (for minus) to work as prefix args when in speed command position. But that’s more complicated. From f4abc5c57764fc36d7405be6b6c2f5cd63396d8d Mon Sep 17 00:00:00 2001 From: Aaron Ecay aarone...@gmail.com Date: Tue, 23 Sep 2014 13:54:47 -0400 Subject: [PATCH] allow speed commands to have prefix args * lisp/org.el (org-self-insert-command): Allow speed commands to be invoked with prefix args. --- lisp/org.el | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index b09e72d..9815eb4 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -19693,9 +19693,11 @@ overwritten, and the table is not marked as requiring realignment. (org-check-before-invisible-edit 'insert) (cond ((and org-use-speed-commands - (setq org-speed-command - (run-hook-with-args-until-success - 'org-speed-command-hook (this-command-keys + (let ((kv (this-command-keys-vector))) + (setq org-speed-command + (run-hook-with-args-until-success + 'org-speed-command-hook + (make-string 1 (aref kv (1- (length kv (cond ((commandp org-speed-command) (setq this-command org-speed-command) -- 2.1.0 -- Aaron Ecay
Re: [O] [bug?] org-copy-face doesn’t add faces to org-faces customize group
Hi Aaron, Aaron Ecay wrote: 2014ko irailak 23an, Sebastien Vauban-ek idatzi zuen: Aaron Ecay wrote: 2014ko abuztuak 29an, Sebastien Vauban-ek idatzi zuen: I think it's related to an Emacs bug (#16440) which I reported on the Org mailing list in February. I don’t completely understand what is going on in that bug report. My proposal is to convert org-copy-face to defface. I think this is the right thing (TM). I can’t tell if this would fix your problem or not, but if it’s exclusive to the faces I listed in my previous email the answer is probably “yes.” From what I can see, yes, the faces which are wrongly displayed (before re-applying the theme) match the ones defined by `org-copy-face'. So, this seems the right way to go. OK, thanks for the followup. I’m attaching the patch to this email. If I don’t hear any further feedback, I’ll commit it to master in a few days. I'd say: commit it now, so that it really gets to a broad audience. Anyway, would there be problems, they would be very, very limited: face problems, that's all! Best regards, Seb -- Sebastien Vauban
Re: [O] [BUG] Mark-up handling chokes on unicode whitespace
Hi Tobias, 2014ko irailak 23an, Tobias Getzner-ek idatzi zuen: Hello Aaron! On Tue, 23 Sep 2014 13:03:06 -0400, Aaron Ecay wrote: You will need to change the variable org-emphasis-regexp-components; see the documentation thereof. Thank you very much! This seems to do it. Might I suggest amending unicode whitespace to the default? That variable seems a bit opaque and I might probably never have discovered it on my own; it also appears as if one has to ensure that this is set before org- mode is «required», and one cannot easily just extend the default without also setting the rest. For type-setting purposes, at least the class of non-breaking whitespace is very useful. org-emphasis-regexp-components is known to be a wart. You can search for posts on the mailing list. Some people are trying to figure out how to get rid of it. (You can search in particular for Nicolas Goaziou’s posts...) Here’s one thread where you can see the lay of the land: http://mid.gmane.org/87zjl6ktu2@gmail.com. All that to say, the longer-term solution is to figure out some radically different approach. In the meantime though, if you can provide a list of characters (by unicode name and/or code point) that you think should be added to that variable, someone might be able to add them. (I probably would not make such a change on my own, but would wait for feedback from Nicolas, Bastien, or one of the other maintainer-esque figures on the list). On the other hand, they might say “making such a change in org’s core is just restacking the deck chairs on the Titanic,” which would also be a reasonable position for them to take IMO. At first I thought it might be easy to cleanly solve such problems by using the whitespace character class throughout, but to my chagrin it seems that at least «search-forward-regexp» will only match 8-bit whitespace this way, so I suppose Emacs regex isn’t aware of non-ASCII whitespace? :'| I don’t really know anything about this...it’s unfortunate if true though. -- Aaron Ecay
[O] Download of constants.el not working
Hello (), I can't download constants.el from https://staff.fnwi.uva.nl/c.dominik/Tools/constants/index.html would you mind to post a copy or another link? Thanks Dieter -- Best wishes H. Dieter Wilhelm Darmstadt, Germany
Re: [O] How to utilize the vc package inside of the edit source block buffer?
Hi Grant, 2014ko irailak 23an, Grant Rettke-ek idatzi zuen: Good afternoon, The ability to org-edit-special inside of source block is truly priceless. There is a delightful workflow to be found with approach. It has got me spending more and more time in the edit buffer though, wanting to utilize vc-next-action to initiate a commit. This is not possible because the buffer is not associated with a file. Is there some way to get tell Emacs to execute the action on the source buffer from which the source edit block buffer originated? One approach might be to advise the vc commands like (pseudocode): (defadvice vc-foo (around org-src activate) (when (in-src-edit-p) (org-edit-src-exit)) ad-do-it) -- Aaron Ecay
Re: [O] [Bug?] Results of code block printed in wrong place
Hi Tobias, I can reproduce this. 2014ko irailak 23an, Tobias Getzner-ek idatzi zuen: Hello Nicolas, On Mo, 2014-09-22 at 17:29 +0200, Nicolas Goaziou wrote: FWIW, I cannot reproduce it. This was quite painful to isolate, but I’ve now identified a minimal configuration which should trigger this bug. ── ;; BEGIN minimal.el (add-to-list 'load-path (expand-file-name ~/.emacs.d/elpa/org-20140922)) ;; Example needs sh; might also trigger with other langs. (org-babel-do-load-languages 'org-babel-load-languages '((sh .t))) (fset 'yes-or-no-p 'y-or-n-p) (defun my-org-mode-hook () (follow-mode)) (add-hook 'org-mode-hook 'my-org-mode-hook) ;; END minimal.el ── The file: = * heading 1 #+BEGIN_SRC sh :eval never echo baz #+END_SRC * heading 2 #+BEGIN_SRC sh :exports results echo quux #+END_SRC = I get #+results: quux in the original buffer, not the export buffer (so that quux is not present in the output of export.) This seems rather bizarre. Both follow-mode and the y-or-n-p alias work in isolation, but when both are used at the same time, I observe the bug initially described. Can you confirm this? What a fun puzzle! Babel uses yes-or-no-p to confirm evaluation of the code block on export. yes-or-no-p is implemented in C whereas y-or-n-p is in elisp, so it must be the case that the lisp code allows some hook to run, which follow-mode uses to futz with which buffer/window is current, confusing org-mode. The C implementation I guess doesn’t run the same hook. Sounds like the best advice for the moment is “don’t use follow-mode with org”. Maybe it’s worth adding to the section on package conflicts in the manual? -- Aaron Ecay
Re: [O] How to utilize the vc package inside of the edit source block buffer?
Hello, On 23 September 2014 14:19, Aaron Ecay aarone...@gmail.com wrote: Hi Grant, 2014ko irailak 23an, Grant Rettke-ek idatzi zuen: Good afternoon, The ability to org-edit-special inside of source block is truly priceless. There is a delightful workflow to be found with approach. It has got me spending more and more time in the edit buffer though, wanting to utilize vc-next-action to initiate a commit. This is not possible because the buffer is not associated with a file. Is there some way to get tell Emacs to execute the action on the source buffer from which the source edit block buffer originated? One approach might be to advise the vc commands like (pseudocode): (defadvice vc-foo (around org-src activate) (when (in-src-edit-p) (org-edit-src-exit)) ad-do-it) The following would work as a wrapper: (defun test-buffer () (interactive) (when org-edit-src-from-org-mode (let ((buffer (marker-buffer org-edit-src-beg-marker))) (with-current-buffer buffer (message %s is current for file: %s (current-buffer) (buffer-file-name)) Replace (message ...) with `vc-next-action` or use the above as advice [adjusting from (when..) to (if..)]. Regards, Jonathan -- Aaron Ecay
Re: [O] Call speed-commands with prefix-arg?
Aaron Ecay aarone...@gmail.com writes: Hi Aaron, 2014ko irailak 18an, Thorsten Jolitz-ek idatzi zuen: Hi List, is there a way to call Org speed-commands [fn:1] with a prefix-arg? Does not work for me ... The attached patch should allow this. You can use C-u N X or C-N X (where N is some digits and X a speed command key). I’ll commit it to master in a few days (along with an entry in ORG-NEWS), unless there is any feedback. well, here is some positive feedback - thanks for tackling this! I tried to port this to outshine.el right away, but can't make it to work. But this might well be due to the fact that I'm on the console, no X11. When I do C-u 4 t (with t for todo in the outshine speed cmds) I simply get: , | ;; ** DONE err ` Since outshine-self-insert-command is a one-to-one copy of org-self-insert-command, I guess if the patch works for you, it must be a console problem that I have. Does your patch work for you on the console too? It might be cool to also allow digits 0-9 and hyphen (for minus) to work as prefix args when in speed command position. But that’s more complicated. From f4abc5c57764fc36d7405be6b6c2f5cd63396d8d Mon Sep 17 00:00:00 2001 From: Aaron Ecay aarone...@gmail.com Date: Tue, 23 Sep 2014 13:54:47 -0400 Subject: [PATCH] allow speed commands to have prefix args * lisp/org.el (org-self-insert-command): Allow speed commands to be invoked with prefix args. --- lisp/org.el | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index b09e72d..9815eb4 100755 --- a/lisp/org.el +++ b/lisp/org.el @@ -19693,9 +19693,11 @@ overwritten, and the table is not marked as requiring realignment. (org-check-before-invisible-edit 'insert) (cond ((and org-use-speed-commands - (setq org-speed-command -(run-hook-with-args-until-success - 'org-speed-command-hook (this-command-keys + (let ((kv (this-command-keys-vector))) +(setq org-speed-command + (run-hook-with-args-until-success + 'org-speed-command-hook + (make-string 1 (aref kv (1- (length kv (cond ((commandp org-speed-command) (setq this-command org-speed-command) -- 2.1.0 -- cheers, Thorsten
Re: [O] [RFC] [PATCH] ox-latex: support :float no with caption for minted listings
Hello, Aaron Ecay aarone...@gmail.com writes: Thanks for all your feedback. The patch is now applied on master. Thank you. I’m confused about how ‘org-latex--wrap-label’ works. It tries to put \label commands outside of floats. That will yield links that jump to the preceding section, not the specific point in the document where the \label command occurs. Probably this command should insert \phantomsection before the \label, so that resultant links jump to the right point. (I’ll make this change if no one objects.) I have no objection. Merging the functions might only be worth doing if there were any more places where \captionof needed to be used. That's the intent, yes. It would be a waste not to use a package now residing in the default list. Among the transcoders where `org-latex--wrap-label' is used, some could probably benefit from a non-float caption, if requested by the user. Regards, -- Nicolas Goaziou
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Hello, Aaron Ecay aarone...@gmail.com writes: Um...but the patch I sent works precisely by defining a macro translator, which does get called for any unexpanded (because undefined) macros. Macros are not expected to be seen by export back-ends. It happens when a macro is undefined, but this is not a reliable feature. I guess you’re saying the code ought to block this at a lower/earlier level. Yes, at org-macro.el level. I think error is better than obnoxious message, because it’s possible for the latter to slip through into a “production” document. (We ought to proofread our documents carefully, of course...but no one’s perfect). Sounds good. One issue is that the exporter does two macro expansion passes – one for garden-variety macros, and the second for author, date, email, and title. So, we can’t make the macro expansion unconditionally barf on undefined macros (since for the first pass e.g. author is undefined). I see three options: 1. explicitly whitelist the few “blessed” macros like author, and error on any other undefined macro 2. add an optional “final” arg to org-macro-replace-all, which will activate the undefined checking only if non-nil, and pass this flag in the exporter’s second (and last) call to org-macro-replace-all 3. in ‘org-export-as’, manually walk the parse tree after expanding macros, and make sure no 'macro type objects are left WDYT? I have no strong opinion here but I lean towards option 2 as the error stays internal to org-macro.el and is only triggered with an optional argument. It also doesn't require to hardcode special macro names. Regards, -- Nicolas Goaziou
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Hi, Aaron Ecay aarone...@gmail.com writes: You have two options. Either report an error, as you suggested, or insert an obnoxious message in the output, e.g., UNKNOWN MACRO, à la DEFINITION NOT FOUND. for footnote definitions. In any case, this should happen in org-macro.el, not in the export framework. This is pretty annoying for footnotes. I think error is better than obnoxious message, because it’s possible for the latter to slip through into a “production” document. (We ought to proofread our documents carefully, of course...but no one’s perfect). I think an error is correct, but the message should be informative, e.g. macro MACRO undefined at LINE. —Rasmus -- Summon the Mothership!
Re: [O] Keeping metadata/notes about files and directories
See the custom commands for the agenda in the manual. You can create a command to do a search in specific files. The framework would be splitting your big org file into multiple files and creating a custom search that search only in those particular files. Of course you would need to change this custom command definition if you add more files, but with the idea of using one file per year from the other thread that means updating the custom command only once an year. I didn't test this so see how searching in all of these files scale when compared to searching in one big file, but I imagine it would be faster. -- Darlan Cavalcante Moreira Christoph Groth writes: Dear all, I just wrote under the subject “Re: Managing articles in org mode and collaboration”. This posting puts the other one in a broader context. While thinking about organizing articles, I asked myself: Wouldn’t it be useful to keep metadata/notes about *various* kinds of files/sub-directories/projects inside org-mode (or something similar)? One example is a collection of programming projects. Just like for articles, it would be useful to add notes and metadata to each project. The same is true for many other archive-like collections of things that grow over time. The same problems appear as described in the other posting (namely scaling and searching). I know that there have been discussions about this in the past, and I know that there’s org-annotate-file. Is there anyone who uses a scheme like this (for 1000 items, say) in practice? Christoph
Re: [O] Call speed-commands with prefix-arg?
Hi Thorsten, 2014ko irailak 23an, Thorsten Jolitz-ek idatzi zuen: well, here is some positive feedback - thanks for tackling this! I tried to port this to outshine.el right away, but can't make it to work. But this might well be due to the fact that I'm on the console, no X11. When I do C-u 4 t (with t for todo in the outshine speed cmds) I simply get: , | ;; ** DONE err ` Since outshine-self-insert-command is a one-to-one copy of org-self-insert-command, I guess if the patch works for you, it must be a console problem that I have. Does your patch work for you on the console too? It seems to, yes. Can you test org mode (not outshine) in the console, and verify that the original patch works for you there? If it doesn’t, that needs to be resolved before the patch can be merged. Thanks, -- Aaron Ecay
Re: [O] Download of constants.el not working
Hi Dieter, The link on the page you linked to is broken, but if you manually change the URL to the following it works: https://staff.fnwi.uva.nl/c.dominik/Tools/constants/constants.el -- Aaron Ecay
Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Hello, Jacob Gerlach jacobgerl...@gmail.com writes: While I expect that there's no code overlap with macro expansion, I asked about similar stop on unresolved content behavior with respect to links here: http://article.gmane.org/gmane.emacs.orgmode/90010/ That discussion died off so I thought I'd bring up the topic again here. Would it be possible to cause export to stop (configurably, as discussed) when a link can't be resolved instead of just applying a special format (i.e. org-latex-link-with-unknown-path-format) I have no objection to return an error when a fuzzy link, and id link or a custom id link cannot be matched. However, I do not like the idea of configurability as it would make the code a bit more complex for little gain. Regards, -- Nicolas Goaziou
Re: [O] org-element-at-point fails in programming-modes
Hello, Thorsten Jolitz tjol...@gmail.com writes: I noticed this issue again when calling `org-element-at-point` with point before the stars in , | ** [#A] whatsup :mytag:it: | hello world ` in an emacs-lisp-mode buffer - it results in: , | (paragraph (:begin 193 :end 246 :contents-begin 206 :contents-end 245 | :post-blank 1 :post-affiliated 206 ...)) ` so it kind-of works outside org major-mode, but not correctly due to character-class problem in the regexp(s). Again, `org-element-at-point' is not meant to be used outside of an Org buffer. You can improve the situation by changing regexps, but you will get bitten sooner or later. Regards, -- Nicolas Goaziou
Re: [O] Struggling with new exporter
Hello, phillip.l...@newcastle.ac.uk (Phillip Lord) writes: Okay, I've done it this way. Took a bit of fiddling since I need the project-alist to work in different configurations (i.e. interactively, in batch and in batch on a CI machine). Also, the timestamp stuff confused me -- org was skipping publication, even though the output file had been deleted. You can force re-pulication. This part... #+BIND: org-latex-custom-lang-environments ((clojure tawny)) #+BIND: org-latex-listings t isn't working at the moment. Source listings are coming out in verbatim. Can I set this in the project-alist. From looking at org-latex-src-block it would appear not. On the development branch, you can add :latex-listings t property in your project definition. In maint branch, you may dynamically bind `org-latex-listings' around project publishing function call. Regards, -- Nicolas Goaziou
Re: [O] Call speed-commands with prefix-arg?
Aaron Ecay aarone...@gmail.com writes: Hi Thorsten, 2014ko irailak 23an, Thorsten Jolitz-ek idatzi zuen: well, here is some positive feedback - thanks for tackling this! I tried to port this to outshine.el right away, but can't make it to work. But this might well be due to the fact that I'm on the console, no X11. When I do C-u 4 t (with t for todo in the outshine speed cmds) I simply get: , | ;; ** DONE err ` Since outshine-self-insert-command is a one-to-one copy of org-self-insert-command, I guess if the patch works for you, it must be a console problem that I have. Does your patch work for you on the console too? It seems to, yes. Can you test org mode (not outshine) in the console, and verify that the original patch works for you there? If it doesn’t, that needs to be resolved before the patch can be merged. I get 3 different results trying speed-command ':' with prefix: 1. in Org, when edebugging 'org-set-tags-command', C-u : and C-u 4 : both result in speed-command , | Result: [32] | | Result: 1 (#o1, #x1, ?\C-a) | | Result: 0 (#o0, #x0, ?\C-@) | | Result: 32 (#o40, #x20, ? ) | | Result: | | Result: org-display-outline-path ` 2. when not edebugging, C-u 4 : seems to work in both Org and Outshine - All tags realigned to column 0 3. when doing C-u 4 t in outshine, with ,[ C-h f outshine-todo RET ] | outshine-todo is an interactive Lisp function in `outshine.el'. | | It is bound to M-# M-t. | | (outshine-todo optional ARG) | | Call outorg to trigger `org-todo'. ` , | User-defined Speed commands | === | t outshine-todo ` I get: , | ;; * ELISP SCRATCH ` strange ... -- cheers, Thorsten
Re: [O] Call speed-commands with prefix-arg?
Hi Thorsten, 2014ko irailak 23an, Thorsten Jolitz-ek idatzi zuen: I get 3 different results trying speed-command ':' with prefix: 1. in Org, when edebugging 'org-set-tags-command', C-u : and C-u 4 : both result in speed-command That’s because of the use of last-command-keys-vector, which will get overwritten in edebug (the “ ” is the space that you used to step through the function...) , | Result: [32] | | Result: 1 (#o1, #x1, ?\C-a) | | Result: 0 (#o0, #x0, ?\C-@) | | Result: 32 (#o40, #x20, ? ) | | Result: | | Result: org-display-outline-path ` 2. when not edebugging, C-u 4 : seems to work in both Org and Outshine - All tags realigned to column 0 Good. :) 3. when doing C-u 4 t in outshine, with ,[ C-h f outshine-todo RET ] | outshine-todo is an interactive Lisp function in `outshine.el'. | | It is bound to M-# M-t. | | (outshine-todo optional ARG) | | Call outorg to trigger `org-todo'. ` , | User-defined Speed commands | === | t outshine-todo ` I get: , | ;; * ELISP SCRATCH ` strange ... Sounds like maybe the patch is not too well integrated into outshine. I get expected behavior under these conditions in org. -- Aaron Ecay PhD candidate, Linguistics University of Pennsylvania
Re: [O] resizing windows from an org buffer, reqest for org-shiftcontrolcursor-final-hook
Aaron Ecay aarone...@gmail.com writes: Hi Bradley, 2014ko irailak 16an, Brady Trainor-ek idatzi zuen: I have (global-set-key (kbd S-C-left) 'shrink-window-horizontally) (global-set-key (kbd S-C-right) 'enlarge-window-horizontally) (global-set-key (kbd S-C-down) 'shrink-window) (global-set-key (kbd S-C-up) 'enlarge-window) in my init file, as suggested at http://www.emacswiki.org/emacs-en/WindowResize. However, when I am in an org file, the binding fails. I had hoped that (setq org-support-shift-select t) would fix this, but it only seems to want to allow selection. A solution might be similar to the one ... How’s your elisp? Would you feel up to trying to create such a patch? My elisp is not such that I can stop looking for work to tackle this. (Negligible programming experience.) Though, I might certainly find other excuses once I find gainful employment ;) Brady
Re: [O] [patch, ox] #+INCLUDE resolves links
Hi,
Okay, I hope I got a better patch here. I do — for sure — present
another dreadfully long email! Let's start.
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
#+INCLUDE: file.org::#custom_id :noheadline :lines 3-
Is it `:only-contents' or `:no-headline'? Also :kwd1 :kbd2 value is
usually a shortcut for :kwd1 nil :kbd2 value (at least in export
attributes). Your example is thus confusing, you should include the
expected value.
#+INCLUDE: file.org::#custom_id :only-contents t :lines 3-
Well it's only-contents now. Why? It's more precise in terms of the
org-element terminology and it makes more sense when you include, say,
a table.
+elements.}. If the keyword @code{:only-contents} is used, only the
contents
+of the element in included. For headlines, drawers and properties
^^
+assumed to be in Org mode format and will be processed normally.
File-links
+will be interpret as well:
^
Sorry about that. Fixed.
;;; ox.el --- Generic Export Engine for Org Mode
-
;; Copyright (C) 2012-2014 Free Software Foundation, Inc.
You can remove this chunk.
As above. [I should somehow disable whitespace cleanup when in source repos].
+ (only-contents
+ (and (string-match
+ :\\(only-?contents?[[:space:]]*\\(?:'t\\|true\\|yes\\)?\\)
value)
This should be :only-contents t or :only-contents nil.
:only-contents alone can be tolerated as a shortcut for
:only-contents nil, but that's all.
Okay, I hope I got it now. It's a rather forgiving regexp in terms of
mistakes. Is that OK?
+ (prog1 t
+ (setq value (replace-match nil nil value)
Since `replace-match' cannot return nil here, you can remove
I did it in another way in the new patch now since to allow for nil
values.
(prog1 t ...)
wrapper. If you insist on ONLY-CONTENTS being t, then
No, it's changed.
+ (org-export--prepare-file-contents file location only-contents
lines
Couldn't location, only-contents and lines be merged into a single
argument? At the moment, you are either short-circuiting or breaking
guard against circular inclusions (which relies on a combination of
file-name and lines).
I try to do that now. So the arguments of
`org-export--prepare-file-contents' are now unchanged compared to
master.
Note that lonely property drawers are now unconditionally discard if
they are in the beginning of the buffer — including just after an
initial drawer.
IOW, each include keyword could be defined as a triplet of file name,
beginning and ending global positions. You could implement a helper
function to translate FILE LOCATION and ONLY-CONTENTS into this
triplet,
which would then be passed to `org-export--prepare-file-contents'.
I just pass a string of line numbers like before.
-(defun org-export--prepare-file-contents (file optional lines ind minlevel
id)
+(defun org-export--prepare-file-contents (file optional location
only-contents lines ind minlevel id)
Prepare the contents of FILE for inclusion and return them as a string.
+When optional argument LOCATION is a string the matching element
+identified using `org-link-search' is returned. Note that
+`org-link-search-must-match-exact-headline' is locally set to
+non-nil. When ONLY-CONTENTS is non-nil only the contents of the
+matched element in included. If LOCATION is a headline and
+ONLY-CONTENTS is non-nil, drawers and property-drawers
+immediately following the first headline are also removed.
+
When optional argument LINES is a string specifying a range of
lines, include only those lines.
@@ -3420,6 +3437,26 @@ This is useful to avoid conflicts when more than one
Org file
with footnotes is included in a document.
(with-temp-buffer
(insert-file-contents file)
+(org-mode)
You cannot enforce `org-mode' as the current major mode since you can
include other file types.
+(when location
+ (condition-case err
+ ;; enforce consistency in search.
+ (let ((org-link-search-must-match-exact-headline t))
+(org-link-search location))
+;; helpful error messages
+ (error (error (format %s for %s::%s
+ (error-message-string err) file location
+ (narrow-to-region
+ (org-element-property
+ (if only-contents :contents-begin :begin) (org-element-at-point))
+ (org-element-property (if only-contents :contents-end :end)
(org-element-at-point)))
+ ;; get rid of drawers and properties
+ (when only-contents
+ (let ((element (org-element-at-point)))
+ (while (member (org-element-type element) '(drawer
property-drawer))
+ (delete-region (org-element-property :begin element)
+ (org-element-property :end element))
+ (setq element (org-element-at-point))
This could be handled when building the triplet. However, please do
not
skip drawers (property drawers are fine), as you cannot tell what the
contents are.
OK.
(when lines
(let* ((lines (split-string
Re: [O] [patchattached] Store link to url of eww
Aaron Ecay aarone...@gmail.com writes: Hi Marco, Thanks for your patch. TINYCHANGES can only be smaller than 15 lines, though, and your patch has more than that (even if we discount boilerplate like the license notice). So you should probably do the copyright assignment which is described at http://orgmode.org/worg/org-contribute.html#sec-2. I think he did: Patch: From: Marco Wahl marcowahls...@gmail.com Worg: 14. Marco Wahl Marco, you don't need to write TINYCHANGE if you have done the paperwork. —Rasmus -- Dobbelt-A
Re: [O] [patchattached] Store link to url of eww
Hi Rasmus, 2014ko irailak 23an, Rasmus-ek idatzi zuen: I think he did: Patch: From: Marco Wahl marcowahls...@gmail.com Worg: 14. Marco Wahl ...that’s in the section for tinychange contributors without papers on file though. -- Aaron Ecay
[O] ob-R, about :results value verbatim drawer
When I run follow code, it just work: #+begin_comment #+BEGIN_SRC R :results value verbatim drawer data - list(a=[[./test1.org]],b=[[./test2.org]],c=[[./test3.org]]) c(data$a,data$b,data$c) #+END_SRC #+RESULTS: :RESULTS: [[./test1.org]] [[./test2.org]] [[./test3.org]] :END: but when I add a #+PROPERTY, it show error like below, how to deal with it ? thanks ... #+PROPERTY: header-args:R :colnames yes :rownames no :exports both #+BEGIN_SRC R :results value verbatim drawer data - list(a=[[./test1.org]],b=[[./test2.org]],c=[[./test3.org]]) c(data$a,data$b,data$c) #+END_SRC executing R code block... Wrote /tmp/babel-1984743i/ob-input-198472lB org-babel-R-evaluate-external-process: Wrong type argument: listp, x [[./test1.org]] [[./test2.org]] [[./test3.org]]
Re: [O] error exporting with reference to table in another file
Hi John, 2014ko irailak 20an, John Kitchin-ek idatzi zuen: Hi all, I have this ina n org-file: #+NAME: anatase-tio2-elisp #+BEGIN_SRC emacs-lisp :var data=supporting-information.org:TiO2-data (remove-if-not (lambda (x) (string= anatase (nth 1 x))) data) #+END_SRC #+RESULTS: anatase-tio2-elisp | TiO$_2$ | anatase | LDA| -2802.73 | 33.62 | 187.4 | | TiO$_2$ | anatase | AM05 | -2741.12 | 34.33 | 178.26 | | TiO$_2$ | anatase | PBEsol | -2763.61 | 34.25 | 178.71 | | TiO$_2$ | anatase | PBE| -2781.16 | 35.13 | 171.42 | The code works fine, but when I try to export to a pdf or html I get errors like: org-babel-exp processing... [2 times] org-babel-ref-resolve: Reference 'TiO2-data' not found in this buffer Here is my org-version: Org-mode version 8.2.7c (8.2.7c-25-g1faeb4-elpa @ /Users/jkitchin/Dropbox/kitchingroup/jmax/elpa/org-20140811/) FWIW I cannot reproduce this in emacs -Q, even with the same commit checked out. I’m attaching to this message the test files I used, in case anyone else wants to try. I did (setq org-confirm-babel-evaluate nil) before doing the export. #+NAME: anatase-tio2-elisp #+BEGIN_SRC emacs-lisp :var data=supporting-information.org:TiO2-data :exports both data #+END_SRC #+RESULTS: anatase-tio2-elisp | TiO$_2$ | anatase | LDA| -2802.73 | 33.62 | 187.4 | | TiO$_2$ | anatase | AM05 | -2741.12 | 34.33 | 178.26 | | TiO$_2$ | anatase | PBEsol | -2763.61 | 34.25 | 178.71 | | TiO$_2$ | anatase | PBE| -2781.16 | 35.13 | 171.42 | #+name: TiO2-data | TiO$_2$ | anatase | LDA| -2802.73 | 33.62 | 187.4 | | TiO$_2$ | anatase | AM05 | -2741.12 | 34.33 | 178.26 | | TiO$_2$ | anatase | PBEsol | -2763.61 | 34.25 | 178.71 | | TiO$_2$ | anatase | PBE| -2781.16 | 35.13 | 171.42 | -- Aaron Ecay
Re: [O] ob-R, about :results value verbatim drawer
Hi Feng, 2014ko irailak 23an, Feng Shu-ek idatzi zuen: but when I add a #+PROPERTY, it show error like below, how to deal with it ? thanks ... #+PROPERTY: header-args:R :colnames yes :rownames no :exports both #+BEGIN_SRC R :results value verbatim drawer data - list(a=[[./test1.org]],b=[[./test2.org]],c=[[./test3.org]]) c(data$a,data$b,data$c) #+END_SRC executing R code block... Wrote /tmp/babel-1984743i/ob-input-198472lB org-babel-R-evaluate-external-process: Wrong type argument: listp, x [[./test1.org]] [[./test2.org]] [[./test3.org]] The simple answer is don’t add the #+property line. In particular, the :colnames yes setting doesn’t play well with your code block. If you must have the #+property line for other reasons, override the global setting of :colnames yes with :colnames no on the source block. -- Aaron Ecay
