Re: [O] "Capture"-like browser plugin?
On 7/23/15, Daniele Pizzolli wrote: > https://addons.mozilla.org/it/firefox/addon/org-mode-capture/ > > The latest version convert html links to org-links (disclaimer: it is my > little contribution). this extension is wonderful. all you have to do is install it and then do what you want with it in elisp. i use it with iceweasel 40.0.3 (rebranded firefox). however, it (or org-protocol) is very flaky. it works half of the time, but sometimes it will do nothing and say "No server buffers remain to edit" and sometimes it will capture the link but not the selection. it will also sometimes capture something else you copied, which does not appear on the page whose link gets capture. GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) of 2015-01-11 on maritornes, modified by Debian org 8.3 (progn (add-to-list 'org-capture-templates `("L" "Protocol Link" entry (file+headline ,(concat org-directory "/executive--a.org") "xyzzy-remember") ;; \nkill %c\nselect %x ;; %:initial is like %i in org-protocol "* [[%:link][%:description]]\n%(alpha-org-protocol-region \"%i\")" :prepend t :immediate-finish t ;; ensure it worked ;; just remember to go to prev buffer for where you were :jump-to-captured t)) nil) (defun alpha-org-protocol-region (string) (if (= 0 (length string)) "" (concat string " --"))) thanks. samuel
Re: [O] Spreadsheet - issue with remote reference to named column
Hello, Daniel Gerber writes: > The docs say that the REF argument to remote can be "@3$3 or $somename, > valid in the referenced table". So, adapting the tutorial, the last > column here should get the same values as the second one, right? > > > | currency | rate (@r$c ref) | rate (named ref) | > |--+-+--| > | eur | 1 | nil | > | usd |0.77 | nil | > | sek |0.12 | nil | > | sek |0.12 | nil | > | sek |0.12 | nil | > | nok |0.14 | nil | > | | nil | | > #+TBLFM: $2='(org-lookup-first $1 '(remote(rates,@2$2..@>$2)) > '(remote(rates,@2$3..@>$3)))::$3='(org-lookup-first $1 > '(remote(rates,$abbr)) '(remote(rates,$euros))) > > > #+TBLNAME: rates > | ! | abbr | euros | > |---+--+---| > | | eur | 1 | > | | nok | 0.14 | > | | sek | 0.12 | > | | usd | 0.77 | Actually, wrong. $abbr (respectively $euros) in this case is equivalent to $2 (respectively $3). So your formula becomes $3='(org-lookup-first $1 '(remote(rates,$2)) '(remote(rates,$3))) However, $2, or $3, are not valid range references so you do not get vector of values. However, the following should work as expected '(org-lookup-first $1 '(remote(rates,@2$abbr..@>$abbr)) '(remote(rates,@2$euros..@>$euros))) Regards, -- Nicolas Goaziou
Re: [O] Using the file as 1st level headline
Hi Eric Eric S Fraga writes: > On Wednesday, 16 Sep 2015 at 18:49, Sven Bretfeld wrote: >> Is it possible to have a file header which is counted as a first level >> headline? > > I am not sure how this relates to the rest of your email. Can you > please expand on this? I should have been more clear. The problem is the project definition. It will become clear below. >> Now, I'm using org to write scientific books and articles. Therefore, >> I want to use 1st level headlines as section titles for LaTeX export. >> Of course, not every section is an individual project---the article in >> total is the project and its doable steps are defined by inline tasks. >> So, what I want to do is something like this: > > Have you actually tried what you wrote? What happens? If I do it that way, each inline-task is treated as a standalone task, not as subtask of a larger project. One of the strengths of Bernt Hansen's setup is the possibility to narrow down the agenda to a specific project and have only its next steps and other subtasks displayed. A project is defined as a headline with TODO keyword which has at least one sublevel headline also containing a TODO keyword. An inline-task inside a standard article structure has no higher level task which would count as the project subsuming the inline-tasks as subtasks. At the moment I'm using this solution: * TODO Introduction Text. * NEXT Something 1 * END * TODO Chapter 1 Text. TODO Something 2 END But this makes "Introduction" and "Chapter 1" individual projects and assigns a single subtask to each named "Something 1" and "Something 2". For a book this can easily sum up to 20 different "projects" (i.e. chapters) which mess up the agenda-view and the work-flow. What would work is: * TODO Write book on XY ** Introduction Text. * NEXT Something 1 * END ** Chapter 1 Text. TODO Something 2 END But this collides with the export, as it turns the chapters into subchapters. So "Introduction" would be 1.1 instead of 1. Furthermore, this is confusing while working on the file. Therefore I was asking if it's possible to assign a TODO keyword to the file itself via a header which would, then, play the role of the project definition subsuming the inline-tasks as subtasks. The only other way would be a redefinition of what a project is. But my lisp knowledge is by far overstrained with this. Basically I'm happy with the TODO-subTODO approach. So it must be a complimentary definition saying basically: "All TODO lines in file xy.org are treated as subtasks to the project `Write book on XY'". > Is the issue, in your case, that the noexport tag on the inlinetasks is > ignored? If so, you could simply define the org-latex-format-inlinetask > function I have above to do nothing? No, that's not the problem. I, too, include them in the export when I need them printed. Sorry, I should have been more clear in the first mail. Thanks for help, Sven -- Sven Bretfeld Department of Philosophy and Religious Studies NTNU Trondheim
[O] [org-plot/gnuplot] Plotting candlestick plots
Hello list, I am trying to plot some candlesticks through org-plot/gnuplot, but I fail. It seems that org-plot/gnuplot supports a list of numbers in deps, i.e., deps:(2 3 4) and then creates a string of the form: 'test.dat' using X with lines where X is first 2 then 3 and finally 4 for deps:(2 3 4) To plot candlesticks though, gnuplot expects a line of the form: 'test'.dat' using 1:3:2:6:5:xticlabels(7) with candlesticks whiskerbars I thought that maybe setting deps to ("1:3:2:6:5") could give me the result I wanted, but I was wrong. I have traced the problem to be in org-plot/gnuplot-script, specifically in the following code segment: --8<---cut here---start->8--- (2d (dotimes (col num-cols) (unless (and (eq type '2d) (or (and ind (equal (1+ col) ind)) (and deps (not (member (1+ col) deps) (setf plot-lines (cons (format plot-str data-file (or (and ind (> ind 0) (not text-ind) (format "%d:" ind)) "") (1+ col) (if text-ind (format ":xticlabel(%d)" ind) "") with (or (nth col col-labels) (format "%d" (1+ col plot-lines) --8<---cut here---end--->8--- This code-segment essentially goes through the columns in the data file and checks for each of them if it is contained in `deps`, if so it proceeds with creating a line of the form: 'test.dat' using X... I believe an easy fix would be to unconditionally go through deps and create a line of the form: 'test.dat' using X... where X is the corresponding element of deps. I tried to hack it, but didn't have much success, any help is welcome. Kind regards, Foivos -- WWW: foivos.zakkak.net PGP: 7B40 69D9 29BA AE91 C0B3 220A 0846 BFD1 03F0 4EA1 signature.asc Description: PGP signature
Re: [O] Agenda Tag filtering - has the behaviour changed?
Nicolas Goaziou writes: > Hello, > > Robert Klein writes: > >> Looking through the commit messages this may come from commit >> 6c6ae990c10dbe7f96b24fccf840fe9f6d81a3b8 > > Indeed. It seems related to this NEWS entry > > *** Minor refactoring of ~org-agenda-filter-by-tag~ > Now uses the argument arg and optional argument exclude instead of > strip and narrow. ARG because the argument has multiple purposes and > makes more sense than strip now. The term narrowing is changed to > exclude. > > The main purpose is for the function to make more logical sense when > filtering on tags now when tags can be structured in hierarchies. Thanks both. So was this an intended usability change? I can probably live with it - I just need to retrain my fingers -- but it does take longer to achieve the result I want now since I have to clear the agenda tags before selecting a new filter and wait for the agenda update each time (my agenda has lots of entries). The old behaviour was faster to use. I haven't done anything with hierarchical tags yet. Regards, Bernt
Re: [O] org-read-date wrong for dates before 1970 ?
On Thursday, 17 Sep 2015 at 11:18, Martin Kaffanke wrote: [...] > So there a (german, and english - the last one) formated time is > translated correct for dates after 1970, but its wrong before that. This is a known issue: Unix was born in 1969 and time did not exist before ;-) It's the equivalent of the big bang. More seriously, the data structure used to indicate time and date in Unix is 0 sometime in 1969 and runs out in 2037 (due to 32 bit integer arithmetic), at least as far as org is concerned. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.1-234-g8c85c9
Re: [O] org-read-date wrong for dates before 1970 ?
Nicolas Goaziou writes: > Hello, > > Martin Kaffanke writes: > >> So there a (german, and english - the last one) formated time is >> translated correct for dates after 1970, but its wrong before that. >> >> How can we fix that? > > See org-read-date-force-compatible-dates. Thanks, that's the important hint. Even if I think this solution is for stability by having less functionality. So maybe there should be found a stable solution with full functionality? Thanks, Martin
Re: [O] Using the file as 1st level headline
On Wednesday, 16 Sep 2015 at 18:49, Sven Bretfeld wrote: > Hi all > > Is it possible to have a file header which is counted as a first level > headline? I am not sure how this relates to the rest of your email. Can you please expand on this? [...] > Now, I'm using org to write scientific books and articles. Therefore, > I want to use 1st level headlines as section titles for LaTeX export. > Of course, not every section is an individual project---the article in > total is the project and its doable steps are defined by inline tasks. > So, what I want to do is something like this: Have you actually tried what you wrote? What happens? This approach is basically what I use: inline tasks for the TODO elements but the rest of the structure is the paper with top level headings as sections etc. However, I note that my approach is different in that I don't hide the inline tasks when generating the article. I actually export my inline tasks using the following: #+begin_src emacs-lisp (defun org-latex-format-inlinetask (todo type priority name tags contents info) "Format an inline task element for LaTeX export." (let ((theinlinetask (concat todo " " name ": " contents))) (format "\\footnote{%s}\\marginpar{\\fbox{\\tiny\\thefootnote. %s}}" theinlinetask todo))) (setq org-latex-format-inlinetask-function 'org-latex-format-inlinetask) #+end_src Is the issue, in your case, that the noexport tag on the inlinetasks is ignored? If so, you could simply define the org-latex-format-inlinetask function I have above to do nothing? -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.1-234-g8c85c9
Re: [O] [patch] Add footnote when exporting links in LaTeX
On Thursday, 17 Sep 2015 at 00:36, Rasmus wrote: > Lars Tveito writes: >> When exporting to LaTeX, links are exported using \href. These are >> completely invisible if the document is printed out. I consider this a >> problem. [...] >> I think a good solution is to add a footnote with the link, in addition >> to the \href. I've added a patch with this (tiny) change. > > We shouldn't hardcode this behavior. Indeed we should not! I use LaTeX (beamer) to create slides which have links I can click on during lectures. I would hate having footnotes for all of these... However, I can see the validity of Lars's use case so it would be nice to have an option for this. My approach is to put the link in a footnote directly and not in the text if it's a document I intend to print... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.1-234-g8c85c9
Re: [O] org-read-date wrong for dates before 1970 ?
Hello, Martin Kaffanke writes: > I'm doing in *scratch* the following (with C-j at the end of the line): > > (org-insert-time-stamp (org-read-date nil 'totime "8. März 2012")) > <2012-10-08 Mon>"<2012-10-08 Mon>" > > (org-insert-time-stamp (org-read-date nil 'totime "8. März 1952")) > <1970-10-08 Don>"<1970-10-08 Don>" > > (org-insert-time-stamp (org-read-date nil 'totime "1952-03-08")) > <1970-03-08 Son>"<1970-03-08 Son>" > > So there a (german, and english - the last one) formated time is > translated correct for dates after 1970, but its wrong before that. > > How can we fix that? See org-read-date-force-compatible-dates. Regards, -- Nicolas Goaziou
[O] org-read-date wrong for dates before 1970 ?
Hi there, I'm doing in *scratch* the following (with C-j at the end of the line): (org-insert-time-stamp (org-read-date nil 'totime "8. März 2012")) <2012-10-08 Mon>"<2012-10-08 Mon>" (org-insert-time-stamp (org-read-date nil 'totime "8. März 1952")) <1970-10-08 Don>"<1970-10-08 Don>" (org-insert-time-stamp (org-read-date nil 'totime "1952-03-08")) <1970-03-08 Son>"<1970-03-08 Son>" So there a (german, and english - the last one) formated time is translated correct for dates after 1970, but its wrong before that. How can we fix that? (this code is used in the google-contacts-to-org-contacts functions from the google-contacts package) Thanks, Martin
Re: [O] 2 issues with Include function
Thanks, I will try to see if there is something in my config causing the issue. All best, Leonard On 17 September 2015 at 08:26, Nicolas Goaziou wrote: > Hello, > > Leonard Randall writes: > > > I noticed 2 more issues with the include function on latex export. > > I cannot reproduce any of these. Could you upgrade Org and try again? > > > The first, is that when I make an id link between 2 included files, > > the exporter gives the section associated with the linked header the > > same label as the header where the link is located. So for instance if > > I include two files which include the following contents. > > > > --- Included File 1 --- > > * Headline 4 > > I develop this point in [[id:beb44a5e-fc8b-4597-8dc1-0fb0a6d3a346]]. > > --- --- > > --- Included File 2 > > ** Headline 6.2 > > :PROPERTIES: > > :ID: beb44a5e-fc8b-4597-8dc1-0fb0a6d3a346 > > :END: > > --- --- > > > > Headline 4 and Headline 6.2 will be given the same label, and so the link > > will point to headline 4, instead of Headline 6.2. > > I get > > \section{Headline 4} > \label{sec:orgheadline2} > I develop this point in \ref{sec:orgheadline1}. > \section{Headline 6.2} > \label{sec:orgheadline1} > > > The second problem is that if the include function is narrowed to a > > specific headline using a custom id, and there are footnotes defined at > the > > very bottom of that headline, the final footnote in the section will not > > have a closing bracket. > > > > If I have the following master file and included file. > > > > --- Master file --- > > #+INCLUDE: "./1WorkingDraft.org::#Chapter1" > > --- --- > > > > --- 1WorkingDraft.org --- > > * Chapter 1 Title > > :PROPERTIES: > > :CUSTOM_ID: Chapter1 > > :END: > > Here is a some text with a footnote[fn:1]. Here is some more text. > > ... > > [fn:1] Here is the definition. > > > > * Other heading or end of file > > --- --- > > I get latex export that includes something like this. > > > > --- > > \chapter{Chapter 1 Title} > > \label{sec:orgheadline11} > > Here is some text with a footnote \footnote{Here is the definition..Here > is > > some more text. > > ... > > \end document > > I get > > \section{Chapter 1 Title} > \label{sec:orgheadline1} > Here is a some text with a footnote\footnote{Here is the definition.}. > Here is some more text. > \ldots{} > > > Regards, > > -- > Nicolas Goaziou >
Re: [O] 2 issues with Include function
Hello, Leonard Randall writes: > I noticed 2 more issues with the include function on latex export. I cannot reproduce any of these. Could you upgrade Org and try again? > The first, is that when I make an id link between 2 included files, > the exporter gives the section associated with the linked header the > same label as the header where the link is located. So for instance if > I include two files which include the following contents. > > --- Included File 1 --- > * Headline 4 > I develop this point in [[id:beb44a5e-fc8b-4597-8dc1-0fb0a6d3a346]]. > --- --- > --- Included File 2 > ** Headline 6.2 > :PROPERTIES: > :ID: beb44a5e-fc8b-4597-8dc1-0fb0a6d3a346 > :END: > --- --- > > Headline 4 and Headline 6.2 will be given the same label, and so the link > will point to headline 4, instead of Headline 6.2. I get \section{Headline 4} \label{sec:orgheadline2} I develop this point in \ref{sec:orgheadline1}. \section{Headline 6.2} \label{sec:orgheadline1} > The second problem is that if the include function is narrowed to a > specific headline using a custom id, and there are footnotes defined at the > very bottom of that headline, the final footnote in the section will not > have a closing bracket. > > If I have the following master file and included file. > > --- Master file --- > #+INCLUDE: "./1WorkingDraft.org::#Chapter1" > --- --- > > --- 1WorkingDraft.org --- > * Chapter 1 Title > :PROPERTIES: > :CUSTOM_ID: Chapter1 > :END: > Here is a some text with a footnote[fn:1]. Here is some more text. > ... > [fn:1] Here is the definition. > > * Other heading or end of file > --- --- > I get latex export that includes something like this. > > --- > \chapter{Chapter 1 Title} > \label{sec:orgheadline11} > Here is some text with a footnote \footnote{Here is the definition..Here is > some more text. > ... > \end document I get \section{Chapter 1 Title} \label{sec:orgheadline1} Here is a some text with a footnote\footnote{Here is the definition.}. Here is some more text. \ldots{} Regards, -- Nicolas Goaziou
Re: [O] Bug: LaTeX export #+NAME failing [8.3.1 (release_8.3.1-123-g823cad @ /home/amdavis/src/org-mode/lisp/)]
Andrew Davis writes: > Could you just briefly let me know why this is a feature? I am > assuming that this is so that org references are unique should you > accidentally reuse a label? The main reason is that it puts much less restrictions on the name of internal links and is more portable across back-ends. Regards,
Re: [O] Agenda Tag filtering - has the behaviour changed?
Hello, Robert Klein writes: > Looking through the commit messages this may come from commit > 6c6ae990c10dbe7f96b24fccf840fe9f6d81a3b8 Indeed. It seems related to this NEWS entry *** Minor refactoring of ~org-agenda-filter-by-tag~ Now uses the argument arg and optional argument exclude instead of strip and narrow. ARG because the argument has multiple purposes and makes more sense than strip now. The term narrowing is changed to exclude. The main purpose is for the function to make more logical sense when filtering on tags now when tags can be structured in hierarchies. Regards, -- Nicolas Goaziou