[O] refile too slow

[Samuel Wales]

recent maint, but been a problem for a few mo.

refile hits a wall.  depends on number of headers.

i think delete-dups is suspicious here.  is its only purpose to
eliminate the existing
header?

   - org-refile47808  91%
 - org-refile-get-location  47780  91%
  - org-refile-get-targets  44120  84%
 delete-dups36613  70%
 match-string-no-properties   548   1%

-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.



-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

Re: [O] Insert heading above current one

[Luciano Passuello]

On Sat, Sep 30, 2017 at 5:21 PM, Nicolas Goaziou  wrote:
> M-RET and C-RET/C-u M-RET are
> different beasts, just don't expect them to behave exactly the same.

And then you hit exactly the heart of our discussion right there.
Im my line of reasoning, org-insert-heading and
org-insert-heading-respect-content should behave exactly the same,
except for the fact that org-insert-heading-respect-content should,
well, respect the content; Other than that, they should be 100%
symmetric.

> I stand on my ground: current behaviour is better.
Given we're not striving for behavior symmetry, I can see your point.

Regards,

Re: [O] function for inserting a block

[Eric Abrahamsen]

Nicolas Goaziou  writes:


[...]

> C-c C-x t is free, tho.

Oops, I think that's what I meant to type. Here's the latest version of
the patch -- I removed the bit fooling with the location of point at the
end, as it seemed simpler was better. How's this look?

Eric

>From b8636d918e9ff79cac320003361c5a16846f156c Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Sat, 30 Sep 2017 13:23:05 -0700
Subject: [PATCH] New function org-insert-structure-template

* lisp/org.el (org-insert-structure-template): New function for
  wrapping region (or element at point) in a begin/end block.
* etc/ORG-NEWS: Mention in news.
* doc/org.texi (Structure of code blocks, Easy templates): And in
  manual.
---
 doc/org.texi | 21 +++--
 etc/ORG-NEWS |  5 +
 lisp/org.el  | 25 +
 3 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 1c79d8330..2274e584a 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -15215,12 +15215,14 @@ A @samp{src} block conforms to this structure:
 #+END_SRC
 @end example
 
-Org mode's templates system (@pxref{Easy templates}) speeds up creating
-@samp{src} code blocks with just three keystrokes.  Do not be put-off by
-having to remember the source block syntax.  Org also works with other
-completion systems in Emacs, some of which predate Org and have custom
-domain-specific languages for defining templates.  Regular use of templates
-reduces errors, increases accuracy, and maintains consistency.
+Do not be put off by having to remember the source block syntax.  Org mode
+offers two ways of speeding up the creation of @samp{src} code blocks: a
+templates system that can create a new block with just three keystrokes, and
+a command for wrapping existing text in a block (@pxref{Easy templates}).
+Org also works with other completion systems in Emacs, some of which predate
+Org and have custom domain-specific languages for defining templates.
+Regular use of templates reduces errors, increases accuracy, and maintains
+consistency.
 
 @cindex source code, inline
 An inline code block conforms to this structure:
@@ -17391,6 +17393,13 @@ Org comes with these pre-defined easy templates:
 More templates can added by customizing the variable
 @code{org-structure-template-alist}, whose docstring has additional details.
 
+@findex org-insert-structure-template
+Easy templates are ideal when writing new content, but sometimes it is
+necessary to mark up existing content.  For these cases, Org provides the
+function @code{org-insert-structure-template}, which prompts for a block
+type, and wraps either the active region or the current Org element in that
+block.  This command is bound to @kbd{C-c C-x t} by default.
+
 @node Speed keys
 @section Speed keys
 @cindex speed keys
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 7c69efa89..1a3aa9e92 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -105,6 +105,11 @@ you should expect to see something like:
   ,#+STARTUP: shrink
 #+END_EXAMPLE
 
+** New Functions
+*** ~org-insert-structure-template~
+
+This function can be used to wrap existing text of Org elements in
+a #+BEGIN_FOO/#+END_FOO block.  Bound to C-c C-x t by default.
 ** Miscellaneous
 
 *** ~org-publish-resolve-external-link~ accepts a new optional argument.
diff --git a/lisp/org.el b/lisp/org.el
index 1ffea80fe..fe7bfd1c5 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12199,6 +12199,30 @@ expands them."
 (insert rpl)
 (when (re-search-backward "\\?" start t) (delete-char 1
 
+(defun org-insert-structure-template (type)
+  "Insert a block structure of the type #+BEGIN_FOO/#+END_FOO.
+Prompts for a block type, and inserts the block.  With an active
+region, wrap the region in the block."
+  (interactive "sBlock type: ")
+  (unless (use-region-p)
+(org-mark-element))
+  (let ((s (copy-marker (min (point) (mark
+	(e (copy-marker (max (point) (mark)
+(when (string-equal (downcase type) "example")
+  (org-escape-code-in-region s e))
+(goto-char s)
+(beginning-of-line)
+(insert (format "#+BEGIN_%s" type))
+(newline-and-indent)
+(goto-char e)
+(unless (bolp)
+  (end-of-line)
+  (newline-and-indent))
+(insert (format "#+END_%s" type))
+(newline-and-indent)
+(set-marker s nil)
+(set-marker e nil
+
  TODO, DEADLINE, Comments
 
 (defun org-toggle-comment ()
@@ -19660,6 +19684,7 @@ COMMANDS is a list of alternating OLDDEF NEWDEF command names."
 (org-defkey org-mode-map "\C-c\C-xE"'org-inc-effort)
 (org-defkey org-mode-map "\C-c\C-xo"'org-toggle-ordered-property)
 (org-defkey org-mode-map "\C-c\C-xi"'org-columns-insert-dblock)
+(org-defkey org-mode-map "\C-c\C-xt"'org-insert-structure-template)
 (org-defkey org-mode-map [(control ?c) (control ?x) ?\;] 'org-timer-set-timer)
 
 (org-defkey org-mode-map "\C-c\C-x."'org-timer)
-- 
2.14.2

Re: [O] Insert heading above current one

[Nicolas Goaziou]

Luciano Passuello  writes:

> Isn't that consistent with the regular org-insert-heading (M-RET)?
> When cursor is in the beginning of a headline, there's no way to
> create a heading below that line (using standard M-RET). It will
> always create it above. So, having the cursor in the beginning of the
> line overrides the standard behavior. Unless we move the cursor
> somewhere else, that feature is also lost.

Sorry, but this makes no sense. You want to insert a headline above
current one? Use M-RET. You want it below current headline? Use C-RET.
You have the best of both worlds, any behaviour is still available to
your fingertips.

> I see no reason why C-RET should behave differently, even if only for
> consistency reasons.

I do see reasons, and I explained them. M-RET and C-RET/C-u M-RET are
different beasts, just don't expect them to behave exactly the same.

I stand on my ground: current behaviour is better.

Regards,

Re: [O] Insert heading above current one

[Luciano Passuello]

Hello,

On Sat, Sep 30, 2017 at 4:29 AM, Nicolas Goaziou  wrote:
> OTOH, if we force the previous behaviour, as you suggest, there is no
> way to insert a new headline after the current subtree when point is at
> the beginning of a headline. A feature is lost.

Isn't that consistent with the regular org-insert-heading (M-RET)?
When cursor is in the beginning of a headline, there's no way to
create a heading below that line (using standard M-RET). It will
always create it above. So, having the cursor in the beginning of the
line overrides the standard behavior. Unless we move the cursor
somewhere else, that feature is also lost.

I see no reason why C-RET should behave differently, even if only for
consistency reasons.

> And I agree it should be deprecated. If there is no objection, I'll
> remove it.

I'm too much of a n00b to foresee all consequences of such
deprecation, so I prefer not to give my opinion here.
Doing a quick search on "org-insert-heading-respect-content t" I see
some people do find value in it.

Regards,
Luciano.

Re: [O] [ANN] Agenda speed up

[Matt Lundin]

Matt Lundin  writes:
>
> Here is a quick comparison of the top elp-results using a couple of commands:

I'm including the full elp results for reference. These were run with my
org agenda files and with customizations that I don't have time to
isolate at the moment. I'll try to provide a report with a minimal
config soon. The attached files contain profiling for the two commands
reported in my previous email.

(org-todo-list "TODO")

(org-agenda-list)

Best,
Matt

org-todo-list 1   
0.954759710.95475971
org-agenda-prepare1   
0.425165363   0.425165363
org-agenda-prepare-buffers1   
0.394949431   0.394949431
org-agenda-get-day-entries63  
0.2680520310  0.0042547941
org-agenda-get-todos  63  
0.262784373   0.0041711805
org-agenda-finalize-entries   1   
0.202006798   0.202006798
org-get-tags-at   454 
0.200070026   0.0004406828
org-agenda-highlight-todo 227 
0.1841641769  0.0008112959
org-back-to-heading   1207
0.1734143220  0.0001436738
org-refresh-category-properties   63  
0.1109007029  0.0017603286
org-refresh-properties126 
0.0968679490  0.0007687932
org-set-regexps-and-options   63  
0.0660081399  0.0010477482
org--setup-collect-keywords   63  
0.061246143   0.000972161
org-refresh-effort-properties 63  
0.055947762   0.0008880597
org-refresh-stats-properties  63  
0.049975411   0.0007932604
org-agenda-finalize   1   
0.048449583   0.048449583
org-element-at-point  126 
0.0278754009  0.0002212333
org-element--parse-to 126 
0.0237195620  0.0001882504
org-get-priority  227 
0.0201254490  8.865...e-05
org-agenda-files  3   
0.0190556840  0.0063518946
org-element--current-element  189 
0.0178631470  9.451...e-05
org-up-heading-safe   398 
0.016063253   4.035...e-05
org-agenda-format-item227 
0.014556003   6.412...e-05
org-entries-lessp 859 
0.0112956840  1.314...e-05
org-agenda-align-tags 1   
0.010916710.01091671
org-agenda-mode   1   
0.009271944   0.009271944
org-get-property-block74  
0.0081775990  0.0001105080
org-outline-level 799 
0.0073207199  9.162...e-06
org-get-todo-state238 
0.005509511   2.314...e-05
org-entry-get 36  
0.0054365299  0.0001510147
org-element-keyword-parser189 
0.0054290560  2.872...e-05
org-at-property-p 38  
0.005193692   0.0001366761
org--property-local-values36  
0.0049136239  0.0001364895
org-agenda-skip   237 
0.0048559309  2.048...e-05
org-add-props 832 
0.0047682290  5.731...e-06
org-agenda-check-for-timestamp-as-reason-to-ignore-todo-item  237 
0.004598511.940...e-05
org-check-agenda-file 126 
0.0042163329  3.346...e-05
org-inlinetask-in-task-p  74  
0.003895827   5.264...e-05
org-get-agenda-file-buffer126 
0.0033892649  2.689...e-05
org-split-string  686 
0.0033632589  4.902...e-06
org-get-limited-outline-regexp641 
0.0033366020  5.205...e-06
org-activate-links9   
0.003008839   0.0003343154
org-remove-uninherited-tags   260 
0.0029396989  1.130...e-05
org-find-base-buffer-visiting 126 
0.0028278890  2.244...e-05
org-refresh-property

Re: [O] [ANN] Agenda speed up

[Matt Lundin]

Nicolas Goaziou  writes:

> Hello,
>
> Samuel Wales  writes:
>
>> have not beena ble to respons for health reasons.  i have rsposne
>> partly done.  i think result is slightly slower but seems tob e
>> correct if you count recent maint as correct.
>
> It can be slightly slower if you start with a cold cache and never
> re-use it, e.g., when you display only a single day and the most
> important agenda files were modified since last agenda display.

I am finding that the branch is still much slower than the current
master even when no agenda files have changed (i.e., when running
org-agenda-redo in an existing agenda buffer without changing anything).
This is true even when I set org-element-use-cache to t.

> OTOH, displaying, e.g., a whole week, month, year should be a lot
> faster.

Is this an unavoidable trade-off? Since I am constantly refreshing
single day agenda buffers and todo lists, I would much prefer a faster
single day display to a faster week or month display.

Matt

Re: [O] [ANN] Agenda speed up

[Matt Lundin]

Nicolas Goaziou  writes:

> If there is no more feedback nor objection, I'll merge the branch in
> master before the end of the week.
>
> Until then, the changes are still available in wip-agenda-speedup branch
> for review.

Thanks for the heads up. I just had a chance to test the
wip-agenda-speedup branch and find that it significantly slows down the
creation of agenda buffers with my agenda files and custom commands.

I think I have a fairly standard setup (some customizations, additional
features such as habits). I'll do some testing with minimal examples to
see if I can find out why the new branch is so much slower in my case.
In the meantime, I'd like to that the branch *not* be merged until we
are sure that it is actually faster for the majority of use cases.

Here is a quick comparison of the top elp-results using a couple of commands:

(org-todo-list "TODO")

master:
--8<---cut here---start->8---
org-todo-list 1   
0.954759710.95475971
org-agenda-prepare1   
0.425165363   0.425165363
org-agenda-prepare-buffers1   
0.394949431   0.394949431
org-agenda-get-day-entries63  
0.2680520310  0.0042547941
org-agenda-get-todos  63  
0.262784373   0.0041711805
org-agenda-finalize-entries   1   
0.202006798   0.202006798
org-get-tags-at   454 
0.200070026   0.0004406828
org-agenda-highlight-todo 227 
0.1841641769  0.0008112959
org-back-to-heading   1207
0.1734143220  0.0001436738
--8<---cut here---end--->8---

wip-agenda-speedup:
--8<---cut here---start->8---
org-todo-list 1   
1.402434591   1.402434591
org-agenda-day-entries63  
0.4656588689  0.0073914106
org-agenda--entry-from-todo   2217
0.4304873449  0.0001941756
org-agenda-prepare1   
0.387713298   0.387713298
org-agenda-prepare-buffers1   
0.378589420.37858942
org-agenda--file-data 63  
0.2997486200  0.0047579146
org-entry-get 1402
0.2108398869  0.0001503850
org-entry-properties  1366
0.1953800049  0.0001430307
org-agenda-finalize-entries   1   
0.191974038   0.191974038
org-agenda-check-for-timestamp-as-reason-to-ignore-todo-item  237 
0.1819146310  0.0007675722
org-agenda-highlight-todo 227 
0.1735402220  0.0007644943
org-agenda--todo-data 7   
0.1687917040  0.0241131005
org-back-to-heading   2336
0.1648271410  7.055...e-05
--8<---cut here---end--->8---

(org-agenda-list)

master:
--8<---cut here---start->8---
org-agenda-list   1   
1.036426005   1.036426005
org-agenda-prepare1   
0.596309830.59630983
org-agenda-prepare-buffers1   
0.584742966   0.584742966
org-agenda-get-day-entries63  
0.388804281   0.0061714965
org-agenda-get-scheduled  63  
0.287089758   0.0045569802
org-refresh-category-properties   63  
0.280568592   0.0044534697
org-habit-parse-todo  30  
0.178230735   0.0059410245
org-time-string-to-time   219 
0.162822094   0.0007434798
--8<---cut here---end--->8---

wip-agenda-speedup:
--8<---cut here---start->8---
org-agenda-list   1   
1.377235021.37723502
org-agenda-prepare1   
0.594557456   0.594557456
org-agenda-prepare-buffers1   
0.582119253   0.582119253
org-agenda--all-filtered-data 1   
0.307176728   0.307176728
org-agenda--file-data 63  
0.279614084   0.0044383187
org-agenda-day-entries 

Re: [O] Heads up: mobileOrg has stopped working with Dropbox

[Rob Davenport]

Yes, I see it now too.  It was noted as an issue on the mobileorg-android
github site here over a month ago:
https://github.com/matburt/mobileorg-android/issues/501

It looks like Dropbox shut down handling their v1 API and it would take
updating mobileorg-android (and the iOS one) to the new v2.  I looked at it
a bit but it would take a while to understand the changes needed to try to
make them.  I was hoping the author would be able to do something but
nothing so far.  I believe Dropbox announced this would be happening many
months ago (a year?) so it's not like there was no warning.

If you've got ssh working then you're probably OK.  I don't have a ssh
server to use so I may try to look into it again if I get time, but I still
hope the author will be able to do something about it as I'm sure they
could do it much faster.

On Sat, Sep 30, 2017 at 10:44 AM, Eric S Fraga  wrote:

> Hello all,
>
> Dropbox seems to have changed their system in some way and mobileorg has
> stopped working for me.  Has anybody else experienced the same?  Dropbox
> did pop up a less than informative message on my phone saying that
> the support for access by 3rd party apps had changed with effect from 28
> September 2017 (which coincides with mobileorg ceasing to work...).
>
> I've changed to using ssh which is probably a better route but thought
> I'd highlight this.
>
> Thanks,
> eric
>
> --
> : Eric S Fraga via Emacs 27.0.50, Org release_9.1.1-78-gfbf47c
>
>

[O] Heads up: mobileOrg has stopped working with Dropbox

[Eric S Fraga]

Hello all,

Dropbox seems to have changed their system in some way and mobileorg has
stopped working for me.  Has anybody else experienced the same?  Dropbox
did pop up a less than informative message on my phone saying that
the support for access by 3rd party apps had changed with effect from 28
September 2017 (which coincides with mobileorg ceasing to work...).

I've changed to using ssh which is probably a better route but thought
I'd highlight this.

Thanks,
eric

-- 
: Eric S Fraga via Emacs 27.0.50, Org release_9.1.1-78-gfbf47c

Re: [O] Trying to get chart from table working

[Eric S Fraga]

On Friday, 29 Sep 2017 at 17:32, Peter Davis wrote:
> I'm sorry to belabor this, but I could use some help. I'd be willing to
> pay a modest consulting fee, but I'm trying to solve a problem in a
> timely way, as it would help me with healthcare decisions.
>
> Basically, I want to plot a time series graph showing my PSA (prostate
> specific antigen) over time. The PSA is measured at irregular intervals,
> and has been for over 4 years (and hopefully will continue for many more
> years.) That should be a simple enough graph. I've already got a
> javascript d3 example that does this, but I'd like to embed it in a
> document, and to be able to generate PDF.

This part is relatively straightforward.  Using your data example, you
can do the following:

* table
#+name: measurements
|   Date | PSA | |
|+-+-|
| 2017-08-11 | 185 | |
| 2017-08-21 | | #ffdd99 |
| 2017-09-19 | 854 | #ffdd99 |

#+begin_src gnuplot :var data=measurements :file timeseries.pdf :results file
  set xdata time
  set timefmt "%Y-%m-%d"
  set xrange ["2017-08-01":"2017-10-01"]
  unset key
  plot data using 1:2 with histeps
#+end_src

#+results:
[[file:timeseries.pdf]]

The colouring bit is harder and I don't know whether it's possible or
not.  I suggest you look at examples on the web, e.g.

http://gnuplot.sourceforge.net/demo/

to see if anything fits what you are trying to do.

HTH,
eric

-- 
: Eric S Fraga via Emacs 27.0.50, Org release_9.1.1-78-gfbf47c


signature.asc
Description: PGP signature

Re: [O] Allow more export options to be controlled per-subtree

[Kaushal Modi]

On Sat, Sep 30, 2017, 1:44 AM Amos Bird  wrote:

> Hi Kaushal,
>
> I did, it only works if I export the subtree instead of the whole buffer.
>
Yes, then I misunderstood. I thought you were trying to export just the
subtree. The EXPORT_* subtree properties apply only when you are exporting
that subtree.

Then it looks like, wrapping the table cell content in ~ is the only way.
-- 

Kaushal Modi

Re: [O] Insert heading above current one

[Rasmus]

Hi,

Nicolas Goaziou  writes:

>>> Looks like this was an intended change:
>>> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=2b03e945a19701194e510791a96006c5eee9edc6
>>>
>>> Related discussion:
>>> http://lists.gnu.org/archive/html/emacs-orgmode/2016-10/msg00080.html
>>>
>>> PS: The commit message includes gmane.org links which are now dead. I
>>> think we should reference lists.gnu.org links (like above) for longevity
>>> of references.
>
> This is already the case. Latest commit message include links to
> lists.gnu.org.

Aside:

Is there any way to have list.gnus.org links shown directly in Gnus?  I
have Gmane links under the "Archived-At" header (presumably because I use
Gmane NNTP).

Rasmus

-- 
And I faced endless streams of vendor-approved Ikea furniture. . .

Re: [O] [ANN] Agenda speed up

[Nicolas Goaziou]

Hello,

Samuel Wales  writes:

> have not beena ble to respons for health reasons.  i have rsposne
> partly done.  i think result is slightly slower but seems tob e
> correct if you count recent maint as correct.

It can be slightly slower if you start with a cold cache and never
re-use it, e.g., when you display only a single day and the most
important agenda files were modified since last agenda display.

OTOH, displaying, e.g., a whole week, month, year should be a lot
faster.

In any case, an ELP report is necessary to detect any abnormality.

Regards,

-- 
Nicolas Goaziou

Re: [O] Disable fontification when exporting tables

[Amos Bird]

#+OPTIONS: latex:t toc:nil H:3

Thanks!

Nicolas Goaziou  writes:

> Amos Bird  writes:
>
>> | QueryID | SQL Text 
>>  
>>   | Query Time (Seconds) | Query Time Hot (Seconds) |
>> |-+-+--+--|
>> | Q0  | SELECT avg(c1) from (select Year, Month, count(*) as c1 from 
>> ontime group by Year, Month);
>>   | 1.27 | 0.13 |
>> | Q1  | SELECT DayOfWeek, count(*) AS c FROM ontime WHERE Year >= 2000 
>> AND Year <= 2008 GROUP BY DayOfWeek ORDER BY c DESC; 
>> | 1.23 | 0.21 |
>> | Q2  | SELECT DayOfWeek, count(*) AS c FROM ontime WHERE DepDelay>10 
>> AND Year >= 2000 AND Year <= 2008 GROUP BY DayOfWeek ORDER BY c DESC;
>>  |  1.4 | 0.25 |
>> | Q3  | SELECT Origin, count(*) AS c FROM ontime WHERE DepDelay>10 AND 
>> Year >= 2000 AND Year <= 2008 GROUP BY Origin ORDER BY c DESC LIMIT 10;  
>> |  5.2 | 0.29 |
>> | Q4  | SELECT Carrier, count(*) FROM ontime WHERE DepDelay>10  AND Year 
>> = 2007 GROUP BY Carrier ORDER BY count(*) DESC;  
>>   |  1.0 | 0.09 |
>> | Q5  | SELECT Carrier, avg(DepDelay > 10) * 1000 AS c3 FROM ontime 
>> WHERE Year = 2007 GROUP BY Carrier ORDER BY Carrier; 
>>| 0.12 | 0.04 |
>> | Q6  | SELECT Carrier, avg(DepDelay > 10) * 1000 AS c3 FROM ontime 
>> WHERE Year >= 2000 AND Year <= 2008 GROUP BY Carrier ORDER BY Carrier;   
>>| 0.42 | 0.26 |
>>
>> that is, it contains = characters which breaks the verbatim markup.
>
> Then use `code' markup:
>
>   ~SELECT Carrier, avg(DepDelay > 10) * 1000 AS c3 FROM ontime WHERE Year >= 
> 2000 AND Year <= 2008 GROUP BY Carrier ORDER BY Carrier;~
>
> which is more appropriate than `verbatim' for SQL code anyway.
>
>> Is there a way to specify the whole column to be verbatim?
>
> No, there isn't.
>
> Regards,


--
Amos Bird
amosb...@gmail.com

Re: [O] Disable fontification when exporting tables

[Nicolas Goaziou]

Amos Bird  writes:

> | QueryID | SQL Text  
>   
> | Query Time (Seconds) | Query Time Hot (Seconds) |
> |-+-+--+--|
> | Q0  | SELECT avg(c1) from (select Year, Month, count(*) as c1 from 
> ontime group by Year, Month); 
>  | 1.27 | 0.13 |
> | Q1  | SELECT DayOfWeek, count(*) AS c FROM ontime WHERE Year >= 2000 
> AND Year <= 2008 GROUP BY DayOfWeek ORDER BY c DESC;  
>| 1.23 | 0.21 |
> | Q2  | SELECT DayOfWeek, count(*) AS c FROM ontime WHERE DepDelay>10 AND 
> Year >= 2000 AND Year <= 2008 GROUP BY DayOfWeek ORDER BY c DESC; 
> |  1.4 | 0.25 |
> | Q3  | SELECT Origin, count(*) AS c FROM ontime WHERE DepDelay>10 AND 
> Year >= 2000 AND Year <= 2008 GROUP BY Origin ORDER BY c DESC LIMIT 10;   
>|  5.2 | 0.29 |
> | Q4  | SELECT Carrier, count(*) FROM ontime WHERE DepDelay>10  AND Year 
> = 2007 GROUP BY Carrier ORDER BY count(*) DESC;   
>  |  1.0 | 0.09 |
> | Q5  | SELECT Carrier, avg(DepDelay > 10) * 1000 AS c3 FROM ontime WHERE 
> Year = 2007 GROUP BY Carrier ORDER BY Carrier;
> | 0.12 | 0.04 |
> | Q6  | SELECT Carrier, avg(DepDelay > 10) * 1000 AS c3 FROM ontime WHERE 
> Year >= 2000 AND Year <= 2008 GROUP BY Carrier ORDER BY Carrier;  
> | 0.42 | 0.26 |
>
> that is, it contains = characters which breaks the verbatim markup.

Then use `code' markup:

  ~SELECT Carrier, avg(DepDelay > 10) * 1000 AS c3 FROM ontime WHERE Year >= 
2000 AND Year <= 2008 GROUP BY Carrier ORDER BY Carrier;~

which is more appropriate than `verbatim' for SQL code anyway.

> Is there a way to specify the whole column to be verbatim?

No, there isn't.

Regards,

Re: [O] org-plot.el bugfix/patch

[Nicolas Goaziou]

Hello,

"Joe Bloggs"  writes:

> The grid examples in org-plot.el

I assume you mean grid examples in "org-plot.org" from Worg?

> don't work for me
> because the org-plot sets datafile separator to "\t",
> so gnuplot can't read the data file properly.
> Leaving datafile separator at its default value
> (whitespace) fixes the problem.

Why not fixing Worg file instead?

>  ;; Unless specified otherwise, values are TAB separated.
>  (unless (string-match-p "^set datafile separator" script)
> -  (funcall ats "set datafile separator \"\\t\""))
> +  (funcall ats "set datafile separator"))

This seems to contradict the comment above, hence my question about
where the fix should happen.

WDYT?

Regards,

-- 
Nicolas Goaziou

Re: [O] Disable fontification when exporting tables

[Amos Bird]

#+OPTIONS: latex:t toc:nil H:3

Hi,

> However, you could add verbatim markup
>
> =SELECT cab_type, count(*) FROM trips_log GROUP BY cab_type;=
>
> but, again, since I don't know exactly what the issue is, I may be wide
> of the mark.

Well, this solves my issue :).

But I also have a table like this :
#+BEGIN_EXAMPLE
   | QueryID | SQL Text 

   | Query Time (Seconds) | Query Time Hot (Seconds) |
   
|-+-+--+--|
   | Q0  | SELECT avg(c1) from (select Year, Month, count(*) as c1 from 
ontime group by Year, Month);   
   | 1.27 | 0.13 |
   | Q1  | SELECT DayOfWeek, count(*) AS c FROM ontime WHERE Year >= 2000 
AND Year <= 2008 GROUP BY DayOfWeek ORDER BY c DESC;
 | 1.23 | 0.21 |
   | Q2  | SELECT DayOfWeek, count(*) AS c FROM ontime WHERE DepDelay>10 
AND Year >= 2000 AND Year <= 2008 GROUP BY DayOfWeek ORDER BY c DESC;   
  |  1.4 | 0.25 |
   | Q3  | SELECT Origin, count(*) AS c FROM ontime WHERE DepDelay>10 AND 
Year >= 2000 AND Year <= 2008 GROUP BY Origin ORDER BY c DESC LIMIT 10; 
 |  5.2 | 0.29 |
   | Q4  | SELECT Carrier, count(*) FROM ontime WHERE DepDelay>10  AND Year 
= 2007 GROUP BY Carrier ORDER BY count(*) DESC; 
   |  1.0 | 0.09 |
   | Q5  | SELECT Carrier, avg(DepDelay > 10) * 1000 AS c3 FROM ontime 
WHERE Year = 2007 GROUP BY Carrier ORDER BY Carrier;
| 0.12 | 0.04 |
   | Q6  | SELECT Carrier, avg(DepDelay > 10) * 1000 AS c3 FROM ontime 
WHERE Year >= 2000 AND Year <= 2008 GROUP BY Carrier ORDER BY Carrier;  
| 0.42 | 0.26 |
#+END_EXAMPLE

that is, it contains = characters which breaks the verbatim markup.

Is there a way to specify the whole column to be verbatim?

regards,

Nicolas Goaziou  writes:

> Hello,
>
> Amos Bird  writes:
>
>>> - what are you trying to export?
>>
>> an Org table like this:
>>
>>
>> | QueryID | SQL Text 
>>  
>> | Query Time (Seconds) | Query 
>> Time Hot (Seconds) |
>> |-+---+--+--|
>> | Q0  | SELECT cab_type, count(*) FROM trips_log GROUP BY cab_type;  
>>  
>> |10.14 | 
>>11.57 |
>> | Q1  | SELECT passenger_count, avg(total_amount) FROM trips_log GROUP 
>> BY passenger_count;  
>>   |12.00 |   
>>   6.27 |
>> | Q2  | SELECT passenger_count, toYear(pickup_datetime) AS year, 
>> count(*) FROM trips_log GROUP BY passenger_count, year;  
>> |10.45 | 
>> 7.23 |
>> | Q3  | SELECT passenger_count, toYear(pickup_datetime) AS year, 
>> round(trip_distance) AS distance, count(*) FROM trips_log GROUP BY 
>> passenger_count, year, distance ORDER BY year, count(*) DESC; |  
>>   13.03 |10.80 |
>
> OK.
>
>>> - to what back-end?
>>
>> ODT and HTML
>
> OK.
>
>>> - what is the exact problem?
>>
>> I'd like to export this table with *:nil ^:nil options while exporting other 
>> subtrees with *:t ^:t.
>
> This is not my question. You are explaining me how you are trying to
> proceed. I want to know what it the problem you are trying to solve.
>
> Anyway, it seems you are conflating fontification in the Org buffer and
> export. I guess there is no issue related to export in this thread.
>
>> I tried surrounding the table with example block and src block but
>> both look bad after exportation.
>
> Of course. I didn't know you were exporting an Org table.
>
> However, you could add verbatim markup
>
>   =SELECT cab_type, count(*) FROM trips_log GROUP BY cab_type;=
>
> but, again, since I don't know exactly what the issue is, I may be wide
> of the 

Re: [O] Disable fontification when exporting tables

[Nicolas Goaziou]

Hello,

Amos Bird  writes:

>> - what are you trying to export?
>
> an Org table like this:
>
>
> | QueryID | SQL Text  
>   
>   | Query Time (Seconds) | Query Time 
> Hot (Seconds) |
> |-+---+--+--|
> | Q0  | SELECT cab_type, count(*) FROM trips_log GROUP BY cab_type;   
>   
>   |10.14 |
> 11.57 |
> | Q1  | SELECT passenger_count, avg(total_amount) FROM trips_log GROUP BY 
> passenger_count;  
>   |12.00 |
>  6.27 |
> | Q2  | SELECT passenger_count, toYear(pickup_datetime) AS year, count(*) 
> FROM trips_log GROUP BY passenger_count, year;
>   |10.45 |
>  7.23 |
> | Q3  | SELECT passenger_count, toYear(pickup_datetime) AS year, 
> round(trip_distance) AS distance, count(*) FROM trips_log GROUP BY 
> passenger_count, year, distance ORDER BY year, count(*) DESC; |   
>  13.03 |10.80 |

OK.

>> - to what back-end?
>
> ODT and HTML

OK.

>> - what is the exact problem?
>
> I'd like to export this table with *:nil ^:nil options while exporting other 
> subtrees with *:t ^:t.

This is not my question. You are explaining me how you are trying to
proceed. I want to know what it the problem you are trying to solve.

Anyway, it seems you are conflating fontification in the Org buffer and
export. I guess there is no issue related to export in this thread.

> I tried surrounding the table with example block and src block but
> both look bad after exportation.

Of course. I didn't know you were exporting an Org table.

However, you could add verbatim markup

  =SELECT cab_type, count(*) FROM trips_log GROUP BY cab_type;=

but, again, since I don't know exactly what the issue is, I may be wide
of the mark.

> characters when exporting.

I never suggested that.

> I also tried changing _ to \under{} and * to \asc{} but it doesn't look well 
> in the Org buffer.
>
> I did turn on org-toggle-pretty-entities but it changes the appearance
> of other subtrees which I don't want to.

Maybe Org mode is not the appropriate mode for the task?

Regards,

-- 
Nicolas Goaziou

Re: [O] Insert heading above current one

[Nicolas Goaziou]

Hello,

Luciano Passuello  writes:

> I also think the earlier behavior made more sense.

Then we have to agree to disagree, I guess.

> The variable
> org-insert-heading-respect-content (or the universal argument)
> controls how a new headline is inserted BELOW the current header
> (either add immediately after the current line or down below). I don't
> see how this variable should alter the behavior of adding a heading
> ABOVE the current header (ie. "respecting content" or not has no
> effect here, above is always above).

Quoting `org-insert-heading-respect-content':

  Non-nil means insert new headings after the current subtree.

I see no exception there. Consequently, both C-u M-RET and C-RET insert
new heading after the current subtree. If you want to insert it before
current header, use M-RET. There is no feature lost. 

OTOH, if we force the previous behaviour, as you suggest, there is no
way to insert a new headline after the current subtree when point is at
the beginning of a headline. A feature is lost.

> You have a good point. Looking this way, the
> org-insert-heading-respect-content variable is indeed of little use.
> But since the variable does exist (even though perhaps it should be
> deprecated?), it should behave correctly.

It does behave correctly, since it obeys its docstring. 

And I agree it should be deprecated. If there is no objection, I'll
remove it.


Regards,

-- 
Nicolas Goaziou