Re: [O] wrong-type-argument listp when filtering agenda on `work' tag
Hello,
Nicolas Goaziou wrote:
> Sebastien Vauban writes:
>
>> In the agenda view, when filtering for the tasks marked `work' (through
>> `/ w') [1], I get the following error:
>>
>> Debugger entered--Lisp error: (wrong-type-argument listp
>> #("{\\<\\(?:work\\)\\>}" 0 16 (grouptag t)))
>
> This should already be fixed. Please update if you can.
I confirm it is. Thanks!
Best regards,
Seb
--
Sebastien Vauban
Re: [O] [RFC] Change property drawer syntax
Hello, Sebastien Vauban writes: > One question, now that this syntax is stabilized, can the following > long-standing bug be fixed: sometimes the SCHEDULED line (or DEADLINE, > or ...) is moved synchronously with the heading when promoting/demoting, > sometimes not. > > I found in which cases it does and when it does not: it depends on the > presence of text in the entry. > > So, for example: > > --8<---cut here---start->8--- > * The SCHED will be moved > SCHEDULED: <2011-08-18 Thu> > > * This one won't be moved along with the heading > SCHEDULED: <2011-08-18 Thu> > > Because of this text here... > --8<---cut here---end--->8--- > > becomes, when *demoted*: > > --8<---cut here---start->8--- > * New section > > ** The SCHED will be moved >SCHEDULED: <2011-08-18 Thu> > > ** This one won't be moved along with the heading > SCHEDULED: <2011-08-18 Thu> > > Because of this text here... > --8<---cut here---end--->8--- > > This had been fixed by Bastien in August 2011, but the fix had reverted > afterward. I pushed a change that should make indentation shift hopefully smarter. Thank you for reminding me about this. Regards, -- Nicolas Goaziou
Re: [O] better interaction with gnuplot-mode
On 11/04/2014 10:33 AM, Nicolas Goaziou wrote: > Mario Frasca writes: > >> being the comment in the subject field of an email, it can't be a >> multiline comment, can it? > > First line is a summary and cannot exceed 72 (or is it 68? I cannot > remember) characters. You need to start with a capital but do not end > with a period. the output of the script I used to produce the patch was an email, the ones I included. and my comment went into the subject of the email. I'm afraid I still don't see how to specify a multi-line comment in the subject of an email. but we are circumventing it here, so let's see if I manage to respect the orgmode rules... - Reset gnuplot process instead of killing it TINYCHANGE. org-plot.el (org-plot/gnuplot): Without this patch, the gnuplot process associated to the gnuplot buffer is killed before each batch of instructions from orgmode to gnuplot. With or without this patch, orgmode sends a reset instruction to the gnuplot process as first instruction. - Correction in callback registration TINYCHANGE org-plot.el (org-plot/gnuplot): The data-file variable is not in the scope of the callback, one needs to grab its value while registering the callback. With this patch the timer is set as soon as the file is created. Without this patch the timer is set at the end of a let-block, if anything goes wrong in the let-block before the timer is set, the file will not be removed. - signature.asc Description: OpenPGP digital signature
Re: [O] Extremely slow org-table operations
>> > I learned that the hard way when I had one table - four columns, three >> > simple >> > addition formulas with about 1,000 entries. It seemed an eternity before >> > the >> > addition was completed. >> >> I guess the "entries" here mean the table rows right? Please confirm. >> > You are correct; I should have said rows. In my file there were 1000 (+/-) > rows and each row had up to three "entries", not including the description > in the first row. > For instance (without any formulas) in the following row I entered each > amount in columns 2,3 & 4. > > | this was a transaction | 100.00 | 200.00 | 300.00| > > So I considered this three entries. So actually there were 3,000 (+/-) > entries. OK, now I see. Charlie's problem is actually completed different from this problem. So what Carsten Dominik mentioned doesn't apply. This is because in Charlie's case there are 1000 rows in a table, whereas mine has only two rows. Since my formula only calculates two rows, and calculating the table doesn't involve data input from anywhere else, it really doesn't make sens that it has to be slow. Needlessly to say that `org-mode' is fantastic, but with this issue, I have to say that `org-mode' is unhealthy. Therefore, I really hope this issue gets addressed. Please let me know what I can do to help. Thanks in advance, York On Fri, Oct 31, 2014 at 3:12 PM, Charles Millar wrote: > Hi York, > > York Zhao wrote: >> >> @Charlie Millar: >> >> > IIRC Carsten Dominik made the following observation: org tables are >> > extremely >> > slow if they are used as workbooks/spreadsheets and there are many >> > entries >> > (many is undefined). >> >> Thanks for the information, could you please clarify what "entry" means? >> Does it >> mean org headline, or a row in an org-table? >> >> > I learned that the hard way when I had one table - four columns, three >> > simple >> > addition formulas with about 1,000 entries. It seemed an eternity before >> > the >> > addition was completed. >> >> I guess the "entries" here mean the table rows right? Please confirm. >> > You are correct; I should have said rows. In my file there were 1000 (+/-) > rows and each row had up to three "entries", not including the description > in the first row. > For instance (without any formulas) in the following row I entered each > amount in columns 2,3 & 4. > > | this was a transaction | 100.00 | 200.00 | 300.00| > > So I considered this three entries. So actually there were 3,000 (+/-) > entries. > > Charlie
Re: [O] Org and ledger
On Friday, 7 Nov 2014 at 19:53, Sharon Kimble wrote: [...] > having a play with it over the weekend. And I reckon that I will be > keeping my own instruction docs which might be able to be used to setup > another tutorial later on, but lets try walking before running > though! :) > > Sharon. Sharon, I'm online now. You can find the org tutorial for ledger with a simple example at http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-ledger.html -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-475-g25d50e
[O] fontification of comment blocks (or any other kind of block)
It seems that there is nothing in place to allow the text inside blocks like: #+BEGIN_COMMENT ... #+END_COMMENT from having its face customized. It is possible to do this with quote and verse blocks, only not comment blocks. Would it be sensible to have a "default" block face which applies to *any* block of the form #+BEGIN_FOO ... #+END_FOO as long as it doesn't have a more specific face associated with it?
Re: [O] odt export of subtree: set/suppress the date in the export
> Christian Moe : > Does setting the subtree's :EXPORT_DATE: property to the date of the > meeting do what you're looking for? Nope. Still outputs the date of the export. And since writing the posting I've discovered another annoying property of the date: it will switch to the current date at any time of saving of the odt document (eg. when doing a "Save as PDF"). So I think what I want is to zap that date stamp alltogether, to save me from having to delete it in the odt file before creating a PDF from it.
Re: [O] org links and outshine
On 2014-11-07 11:16, Thorsten Jolitz writes: >> I'll seize this opportunity to ask about this: I have my emacs init file >> in outshine syntax, and inside it there are several links (to info >> pages, to gnus messages, and so on). They look great and can be acted >> upon in org mode, but not so great in lisp mode. Could it be possible >> for outshine to nicely display these links? > > nice display of links is done with overlays in Org-mode, see e. > > #+BEGIN_SRC emacs-lisp > (defun org-toggle-link-display () > "Toggle the literal or descriptive display of links." > (interactive) > (if org-descriptive-links > (progn (org-remove-from-invisibility-spec '(org-link)) >(org-restart-font-lock) >(setq org-descriptive-links nil)) > (progn (add-to-invisibility-spec '(org-link)) > (org-restart-font-lock) > (setq org-descriptive-links t > #+END_SRC > > and it might be easy to port this to outshine, unfortunately I have _no_ > time right now, maybe you could have a look yourself (patches very > welcome). I'm not overloaded by time either, but if I find some to look into it I'll report of the list. Thanks, Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 signature.asc Description: PGP signature
Re: [O] issues with non-bracketed links in org 8.3
Christopher Dannheim writes:
> the variable org-link does contain 'textcite' (as well as all other bibtex
> and biblatex link types defined by org-ref/reftex).
>
> org-link-types is a variable defined in `org.el'.
> Its value is
> ("http" ... "citep*" "citealt" "citealt*" "citealp" "citealp*" "citenum"
> "citetext" "citeauthor" "citeauthor*" "citeyear" "citeyear*" "Citet"
> "Citep" "Citealt" "Citealp" "Citeauthor" "Cite" "parencite" "Parencite"
> "footcite" "footcitetext" "textcite" "Textcite" ... "rmail")
OK. So what happens if you put point on you defective link, and eval
M-: (org-element-context)
Then
M-x org-reload M-: (org-element-context)
Regards,
Re: [O] Extremely slow org-table operations
York Zhao writes: > Needlessly to say that `org-mode' is fantastic, but with this issue, I have to > say that `org-mode' is unhealthy. Therefore, I really hope this issue gets > addressed. Please let me know what I can do to help. With your initial file, benchmarking a C-c C-c on the last table, I get: Elapsed time: 2.129800s This is not fast, but nothing unbearable either. The same on the first table gives Elapsed time: 1.195026s As I said in this thread, the additional cost comes from the use of `org-current-line' in "org-table.el". Regards,
Re: [O] better interaction with gnuplot-mode
Mario Frasca writes: > but we are circumventing it here, so let's see if I manage to respect > the orgmode rules... Almost. TINYCHANGE should appear at the end of the commit message. Also, sentences need to be separated by two spaces. Anyway, I pushed your patches. Thanks for your work. Regards,
Re: [O] Inline code :results replace not working
Hello,
mcg writes:
> I use inline code for simple calculations to insert numeric results into
> text apart from "normal" code blocks for more complex calculations and
> graphics (all in R).
>
>
> The :results replace option is not working for inline code, even if I
> explicitly set it in the code block. So I get
>
> #+PROPERTY: session *R*
>
> #+begin_src R :results replace value
> 2+3
> #+end_src
>
> #+RESULTS:
> : 5
>
> src_R[:results replace value]{2+3} =5= =5= =5= =5= =5= =5=
>
> I would really like to have numeric outcome in the buffer (not only
> minibuffer upon evaluation) but also evaluate the whole buffer when
> exporting to have everything updated.
>
> What is the problem here? For now I would have to
> - evaluate only on export and keep :results silent
> - evaluate all manually - meaning I get repeated results if I call
> org-evaluate buffer
:results replace is not implemented (yet?) for inline source blocks. See
"ob-core.el", line 2139 (in master branch).
Regards,
--
Nicolas Goaziou
Re: [O] issues with non-bracketed links in org 8.3
org-element-context yields:
(paragraph (:begin 6145 :end 6166 :contents-begin 6145 :contents-end 6165
:post-blank 1 :post-affiliated 6145 ...))
After relaoding org:
(link (:type "textcite" :path "Hobart2003" :raw-link "textcite:Hobart2003"
:application nil :search-option nil :begin 6145 ...))
and the link is working again! Why is that the case? I get org with git
pull and then make autoloads, is that the problem?
Thank you for your help,
Christopher.
On Sat, Nov 8, 2014 at 8:08 PM, Nicolas Goaziou
wrote:
> Christopher Dannheim writes:
>
> > the variable org-link does contain 'textcite' (as well as all other
> bibtex
> > and biblatex link types defined by org-ref/reftex).
> >
> > org-link-types is a variable defined in `org.el'.
> > Its value is
> > ("http" ... "citep*" "citealt" "citealt*" "citealp" "citealp*" "citenum"
> > "citetext" "citeauthor" "citeauthor*" "citeyear" "citeyear*" "Citet"
> > "Citep" "Citealt" "Citealp" "Citeauthor" "Cite" "parencite" "Parencite"
> > "footcite" "footcitetext" "textcite" "Textcite" ... "rmail")
>
> OK. So what happens if you put point on you defective link, and eval
>
> M-: (org-element-context)
>
> Then
>
> M-x org-reload M-: (org-element-context)
>
>
> Regards,
>
Re: [O] How to differentiate between lists in HTML export
On 2014-11-05, at 08:43, Nicolas Goaziou wrote: > Hello, > > Marcin Borkowski writes: > >> as I've said some time ago, I'm working on a custom exporter. What I'd >> like to achieve is differentiating between lists – essentially, I'd like >> a list to translate to something like this: >> >> >> Item 1 >> Item 2 >> >> >> Is there any support for this kind of stuff in the exporter framework or >> should I code it myself? (It should be rather easy – e.g. have a global >> variable keeping track of the number of unordered lists so far.) > > See `org-export-get-ordinal'. Thanks, but this is not really what I'd like to have: the strings generated by org-export-get-ordinal are /not/ unique throughout the file (they seem to be unique within one level of hierarchy). Any other suggestions? > Regards, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] Org and ledger
> Well, ledger and hledger are different tools that use the same (very > similar) data files. The invocation of each is different. org supports > ledger out of the box but not hledger. > I prefer beancount (very similar to ledger but stricter): beancount supports org out of the box! My beancount file is an org file (with structure, tasks, priorities, agenda, etc. except :CLOCK:) and it parses correctly as a ledger. So I don't use beancount support in org, but the reverse. It also includes Emacs mode, fontification, autocomplete, … http://furius.ca/beancount/
[O] 'remembering' not quite working right.
I am able to 'remember' text with highlighting the text required, and copying it to the clipboard, and then "C-c r" remembers it, and shows in its popup buffer that I need to "C-c C-c" to copy/move it to my remember storage file. Except, the last bit doesn't work for me, instead it calls the "Tag" command which opens "Tag: " in the mini-buffer which just sits and waits for some response. When I 'remember' something, this shows in its buffer - --8<---cut here---start->8--- # C-c C-c "~/.emacs.d/org/remember.org" -> "* Interesting" # C-u C-c C-c like C-c C-c, and immediately visit note at target location # C-0 C-c C-c "???" -> "* ???" # C-1 C-c C-c to select file and header location interactively. # C-2 C-c C-c as child (C-3: as sibling) of the currently clocked item # To switch templates, use `M-x org-remember'. To abort use `C-c C-k'. --8<---cut here---end--->8--- How then can I get it working right please? Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots TGmeds = http://www.tgmeds.org.uk Debian testing, fluxbox 1.3.5, emacs 24.4.1.0 signature.asc Description: PGP signature
Re: [O] odt export of subtree: set/suppress the date in the export
I cannot reproduce either problem, though I seem to remember some difficulty with changing date fields in the past. What Org version are you using? You can turn the use of date fields in LibreOffice on or off with org-odt-use-date-fields. With date fields set to t: - Setting :EXPORT_DATE: in the subtree and exporting the subtree results in an ODT export with that date in the header, not today's date. - Inspecting the date field shows that the date is "fixed". (In LibreOffice, right-click the date and select "Fields" from the popup menu.) - Indeed, the date remains unchanged when I do "Update all" or export to PDF from LibreOffice does indeed keep the same date. Yours, Christian Steinar Bang writes: >> Christian Moe : > >> Does setting the subtree's :EXPORT_DATE: property to the date of the >> meeting do what you're looking for? > > Nope. Still outputs the date of the export. > > And since writing the posting I've discovered another annoying property > of the date: it will switch to the current date at any time of saving of > the odt document (eg. when doing a "Save as PDF"). > > So I think what I want is to zap that date stamp alltogether, to save me > from having to delete it in the odt file before creating a PDF from it.
