[O] [PATCH] small fix for org-log-beginning

[Eric Abrahamsen]

I'm still slowly chewing on making more use of log items, and found a
small bug in org-log-beginning. It contains a partial re-implementation
of something we already have a function for: org-log-into-drawer. It was
causing me occasional bugs, but I only just looked into it.

I'm not sure the commit message makes a whole lot of sense, but...

Eric


>From ac1a4eb4b153f18d8766fdbe6ba4e2168f80ec16 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Sun, 14 Dec 2014 14:38:34 +0800
Subject: [PATCH] Use org-log-into-drawer in org-log-beginning

* lisp/org.el (org-log-beginning): Use existing function for
  discovering the log specification.
---
 lisp/org.el | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index bed5cb9..4aa7988 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13609,8 +13609,7 @@ narrowing."
  (forward-line))
(if (org-at-heading-p) (point)
  (let ((end (save-excursion (outline-next-heading) (point)))
-	   (drawer (cond ((stringp org-log-into-drawer) org-log-into-drawer)
-			 (org-log-into-drawer "LOGBOOK"
+	   (drawer (org-log-into-drawer)))
(cond
 	(drawer
 	 (let ((regexp (concat "^[ \t]*:" (regexp-quote drawer) ":[ \t]*$"))
-- 
2.1.3

[O] Tangling does not detect src blocks with capital BEGIN_SRC/END_SRC when case-fold-search nil

[Christopher Genovese]

When tangling a file whose source code blocks have capitalized BEGIN_SRC and
END_SRC (as produced by 

Re: [O] Patch to implement sorting Org tables by IP address

[Jon Snader]

> On Dec 13, 2014, at 5:07 PM, Nicolas Goaziou  wrote:

> I don't think it needs to vary. As I suggested already, we can use cells
> contents (in the appropriate column) as trimmed strings. So, it could be
> built-in.
> 
> Do you see any downside to it?

Well, I’m just going by what happens now. In org-do-sort, each of the sort 
options sets a different extraction function. For example, if you want a 
numeric sort, the extraction function calls string-to-number, while if you want 
an alphabetic sort it calls org-sort-remove-invisible. Really, this doesn’t 
matter because I was merely commenting on why (prompt . comparison) isn’t 
enough. Of course, you could roll any special extraction functionality into the 
comparison but I don’t really like that.

Anyway, what I was suggesting in my last post was that we duplicate the 
functionality of org-sort-list. There, if you’re calling it programmatically 
you specify getkey-func and compare-func. If you call it interactively, it asks 
you for the extraction function (which must return a string or number) and it 
tests it to see which comparison function to use. I like this approach because 
it makes org-sort-list and org-table-sort-lines work the same way. What’s not 
to like?



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] Patch to implement sorting Org tables by IP address

[Nicolas Goaziou]

Jon Snader  writes:

> The extraction function varies with the type of sort so it has to be
> specified one way or the other.

I don't think it needs to vary. As I suggested already, we can use cells
contents (in the appropriate column) as trimmed strings. So, it could be
built-in.

Do you see any downside to it?


Regards,

Re: [O] Bug: Markdown export fails linking footnotes correctly [8.2.10 (8.2.10-elpa @ /home/wasa/.emacs.d/elpa/org-20141020/)]

[Nicolas Goaziou]

Hello,

Vasilij Schneidermann  writes:

> I'm using the footnote facility in an org document expecting an exported
> Markdown document to provide hyperlinks between the reference and the
> footnote.  Here's some sample Markdown text:
>
> Lots of text[fn:1]. Even more text
>
> [fn:1] Lies.
>
> I expect it to be converted to the following:
>
> Lots of text1. 
> Even more text
>
> 
> Footnotes: 
> 
>
>  href="#fnr.1">1 Lies.
>
>
> 
> 
>
> Instead I get the following:
>
> Lots of text. Even more text
>
> 
> Footnotes: 
> 
>
>  href="#fnr.1">1 Lies.
>
>
> 
> 
>
> The difference should be clear, I expect to get a hyperlink with a
> superscript reference number pointing to the relevant footnote, instead
> I get neither a link nor a reference.  It's completely missing in the
> actual output.

This should be fixed. Thank you for reporting it.


Regards,

-- 
Nicolas Goaziou

Re: [O] LaTeX fragments to deal with character {

[Rasmus]

Hi Kevin,

> Org-mode version 6.33x

O-o-okay.  The current stable version is 8.2 and the export framework
changed in v8.  If possible, you should upgrade.

"kevin.lemorzadec"  writes:

> I am trying to do a latex loop in org mode. When I use the latex syntax
> directly, the character "{" are exported as"\{" as in case 1 below. If I
> use ‘\(...\)’ it does keep the "{" characters but the ‘\(...\)' stays in
> the .tex created (case 2 below) giving me an error when I try to generate
> the pdf.
> Is there an other was to export the "{" characters?

I don't remember if this works in Org6 and it's not available to me.

Try:

#+LATEX: loop line 1
#+LATEX: loop line 2
#+LATEX: loop line 3

Or

#+begin_latex
My loop {}
#+end_latex

Let's hope one of those works in Org6.

—Rasmus

-- 
Vote for proprietary math!

Re: [O] [bug, patch, ox] INCLUDE and footnotes

[Rasmus]

Hi,

Attached is a patch that enables footnotes in INCLUDEd documents when
using :lines and friends.  It stores the footnotes in a hash-table
initialized in `org-export-expand-include-keyword' and updated via
`org-export--prepare-file-contents'.  The footnotes are then inserted when
all include keywords are expanded.

At the moment only footnotes from INCLUDEs with :lines-like arguments will
be picket up here.  But I think it might be nice to also use this
functionality with footnotes when whole documents are included, and not
include the footnote section directly from these documents.  Though I
expect the to be accused of worm-nurturing, do consider this curious example:

 $> cat t{1,0*}.org
 #+TITLE: This is t1.org 
 #+INCLUDE: "/tmp/t00.org"
 #+INCLUDE: "/tmp/t01.org"

 # This is t00.org
 Footnotes[fn:1], [fn:test] and [fn:inline:anonymous footnote].
 * Footnotes

 [fn:1] Footnote 1
 [fn:test] Footnote "test"
 
 # t01.org
 Footnotes[fn:1], [fn:test] and [fn:inline:anonymous footnote].
 * Footnotes

 [fn:1] Footnote 1
 [fn:test] Footnote "test"

ox will in fact interpret t1.org as:

#+TITLE: This is t1.org
Footnotes[fn:1-1], [fn:1-test] and [fn:1-inline:anonymous footnote].

[fn:1-1] Footnote 1

[fn:1-test] Footnote "test"
Footnotes[fn:2-1], [fn:2-test] and [fn:2-inline:anonymous footnote].

So I see three approaches:
   1. let the user shoot himself in the foot
   2. fix the "bug" (IMO) that is that
  #+INCLUDE: "/tmp/t00.org"
  #+INCLUDE: "/tmp/t01.org"
  Is "read" as
  #+INCLUDE: "/tmp/t00.org" :minlevel N
  #+INCLUDE: "/tmp/t01.org" :minlevel N+1
  The easiest way I can think of would be to do a pre-scan of the
  buffer to see if there exists any instances where include is only
  separated by whitespace in which case they should have the same
  level.
   3. Fix the particular nastiness above by removing footnote sections and
  reinserting them using the mechanism of this patch.

—Rasmus

-- 
A page of history is worth a volume of logic
>From 04726b6e5915fc47f3ecc261f9c7d9dfb2b44f56 Mon Sep 17 00:00:00 2001
From: rasmus 
Date: Tue, 9 Dec 2014 12:40:52 +0100
Subject: [PATCH] ox.el: Fix footnote-bug in #+INCLUDE-keyword

* ox.el (org-export--prepare-file-contents): Preserve footnotes
when using the LINES argument.  New optional argument FOOTNOTES.
 (org-export-expand-include-keyword): New optional argument
 FOOTNOTES.
* test-ox.el: Add test for INCLUDE with :lines and footnotes.
* ORG-NEWS: Update.
---
 etc/ORG-NEWS|  3 +-
 lisp/ox.el  | 94 +++--
 testing/lisp/test-ox.el | 25 +
 3 files changed, 95 insertions(+), 27 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index f719886..f831c60 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -103,7 +103,8 @@ The content of the included file can now be optionally marked up, for
 instance as HTML.  See the documentation for details.
 *** File links with =#+INCLUDE= keyword
 Objects can be extracted via =#+INCLUDE= using file links.  It is
-possible to include only the contents of the object.  See manual for
+possible to include only the contents of the object.  Further,
+footnotes are now supported when using =#+INCLUDE=.  See manual for
 more information.
 *** Additional =:hline= processing to ob-shell
 If the argument =:hlines yes= is present in a babel call, an optional
diff --git a/lisp/ox.el b/lisp/ox.el
index 9d9e794..975f178 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -3052,16 +3052,18 @@ locally for the subtree through node properties."
 		   (car key)
 		   (if (org-string-nw-p val) (format " %s" val) ""
 
-(defun org-export-expand-include-keyword (&optional included dir)
+(defun org-export-expand-include-keyword (&optional included dir footnotes)
   "Expand every include keyword in buffer.
 Optional argument INCLUDED is a list of included file names along
 with their line restriction, when appropriate.  It is used to
 avoid infinite recursion.  Optional argument DIR is the current
 working directory.  It is used to properly resolve relative
-paths."
+paths.  Optional argument FOOTNOTES is a hash-table used for
+storing and resolving footnotes.  It is created automatically."
   (let ((case-fold-search t)
 	(file-prefix (make-hash-table :test #'equal))
-	(current-prefix 0))
+	(current-prefix 0)
+	(footnotes (or footnotes (make-hash-table :test 'equal
 (goto-char (point-min))
 (while (re-search-forward "^[ \t]*#\\+INCLUDE:" nil t)
   (let ((element (save-match-data (org-element-at-point
@@ -3155,14 +3157,27 @@ paths."
 			   file location only-contents lines)
 			lines)))
 		 (org-mode)
-		 (insert
-		  (org-export--prepare-file-contents
-		   file lines ind minlevel
-		   (or (gethash file file-prefix)
-			   (puthash file (incf current-prefix) file-prefix)
+

[O] LaTeX fragments to deal with character {

[kevin.lemorzadec]

Hi,
I am trying to do a latex loop in org mode. When I use the latex syntax
directly, the character "{" are exported as"\{" as in case 1 below. If I
use ‘\(...\)’ it does keep the "{" characters but the ‘\(...\)' stays in
the .tex created (case 2 below) giving me an error when I try to generate
the pdf.
Is there an other was to export the "{" characters?

Org-mode version 6.33x

-
case 1
.org file:
\foreach \n in {Temp,DO,Sal}{\foreach \m in
{Temp,DO,Sal}{
\n \m \par
}}

.tex file:
\foreach \n in \{Temp,DO,Sal\}{\foreach \m in
\{Temp,DO,Sal\}\{
\n \m \par
}\}

-
case 2
.org file:
\(\foreach \n in {Temp,DO,Sal}{\foreach \m in
{Temp,DO,Sal}{
\n \m \par
}}\)

.tex file:
\(\foreach \n in {Temp,DO,Sal}{\foreach \m in
{Temp,DO,Sal}{
\n \m \par
}}\)



-- 
Kevin

[O] Bug: Markdown export fails linking footnotes correctly [8.2.10 (8.2.10-elpa @ /home/wasa/.emacs.d/elpa/org-20141020/)]

[Vasilij Schneidermann]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


I'm using the footnote facility in an org document expecting an exported
Markdown document to provide hyperlinks between the reference and the
footnote.  Here's some sample Markdown text:

Lots of text[fn:1]. Even more text

[fn:1] Lies.

I expect it to be converted to the following:

Lots of text1. 
Even more text


Footnotes: 


1 Lies.





Instead I get the following:

Lots of text. Even more text


Footnotes: 


1 Lies.





The difference should be clear, I expect to get a hyperlink with a
superscript reference number pointing to the relevant footnote, instead
I get neither a link nor a reference.  It's completely missing in the
actual output.

Emacs  : GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.3)
 of 2014-10-21 on bitzer.hoetzel.info
Package: Org-mode version 8.2.10 (8.2.10-elpa @ 
/home/wasa/.emacs.d/elpa/org-20141020/)

[O] Bug: Markdown export fails linking footnotes correctly [8.2.10 (8.2.10-elpa @ /home/wasa/.emacs.d/elpa/org-20141020/)]

[Vasilij Schneidermann]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


I'm using the footnote facility in an org document expecting an exported
Markdown document to provide hyperlinks between the reference and the
footnote.  Here's some sample Markdown text:

Lots of text[fn:1]. Even more text

[fn:1] Lies.

I expect it to be converted to the following:

Lots of text1. 
Even more text


Footnotes: 


1 Lies.





Instead I get the following:

Lots of text. Even more text


Footnotes: 


1 Lies.





The difference should be clear, I expect to get a hyperlink with a
superscript reference number pointing to the relevant footnote, instead
I get neither a link nor a reference.  It's completely missing in the
actual output.

Emacs  : GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.3)
 of 2014-10-21 on bitzer.hoetzel.info
Package: Org-mode version 8.2.10 (8.2.10-elpa @ 
/home/wasa/.emacs.d/elpa/org-20141020/)

[O] Bug: Markdown export fails linking footnotes correctly [8.2.10 (8.2.10-elpa @ /home/wasa/.emacs.d/elpa/org-20141020/)]

[webspider]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.


I'm using the footnote facility in an org document expecting an exported
Markdown document to provide hyperlinks between the reference and the
footnote.  Here's some sample Markdown text:

Lots of text[fn:1]. Even more text

[fn:1] Lies.

I expect it to be converted to the following:

Lots of text1. 
Even more text


Footnotes: 


1 Lies.





Instead I get the following:

Lots of text. Even more text


Footnotes: 


1 Lies.





The difference should be clear, I expect to get a hyperlink with a
superscript reference number pointing to the relevant footnote, instead
I get neither a link nor a reference.  It's completely missing in the
actual output.

Emacs  : GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.3)
 of 2014-10-21 on bitzer.hoetzel.info
Package: Org-mode version 8.2.10 (8.2.10-elpa @ 
/home/wasa/.emacs.d/elpa/org-20141020/)

Re: [O] Evaluating R source code line by line

[Aaron Ecay]

Hi Vikas,

2014ko abenudak 13an, Vikas Rawal-ek idatzi zuen:
> 
> On 13-Dec-2014, at 3:42 pm, Daniele Pizzolli  wrote:
>> Look at:
>> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html
>> 
>> Use ESS to step through evaluation line-by-line
>> 
>> Use C-c ' to visit the edit buffer for your code block
>> Use ess-eval-line-and-step to evaluate each line in turn
>> 
>> ess-eval-line-and-step is usually bound to C-c C-n
> 
> I know this and use it. But since my code evaluation is quite resource
> intensive, when I later evaluate the code using C-c C-c to insert
> results in my org buffer, it would be useful to see how far it is
> progressing.

See the thread beginning at
.  I’m not sure this
feature is actually workable, however, even aside from the performance
issues alluded to in that thread.  There are various methods that babel
uses to evaluate R code, not all of which are amenable to line-by-line
echoing.  In the future, I think babel should move towards an approach
which separates the code actually evaluated in R from the contents of
the code block further.  (See my patch at
 for an example of what I
mean).  This will make line-by-line echoing confusing (since what would
be echoed has little relation to the actual code).

If enough people really want it, the let-binding around ess-eval-visibly-p
in ob-R.el can be removed, but IMO there should be an understanding that:
1) This won’t make all evaluation echo line-by-line.
2) Preserving line-by-line echoing mustn’t be allowed to block the
   evolution of other features that are incompatible with it.

For your use case, I would suggest adding print() calls in strategic
places in your long-running code, which will appear in the R buffer to
let you know how it’s progressing.

-- 
Aaron Ecay

Re: [O] Patch to implement sorting Org tables by IP address

[Jon Snader]

> On Dec 13, 2014, at 11:01 AM, Nicolas Goaziou  wrote:

> `org-do-sort' is an internal function, which isn't meant to be used
> publicly. It really should be named `org-table--do-sort' and be moved
> within "org-table.el". OTOH, we can extend `org-table-sort-lines' to
> allow custom sorting function as a parameter.

I like the idea of providing optional parameters to org-table-sort-lines.

The extraction function varies with the type of sort so it has to be specified 
one way or the other. In org-sort-list, that’s what the getkey-func parameter 
supplies. Thus if we wanted an alist we’d need to provide it too. If you want 
simplicity, how about this: Add ?f ?F and two optional parameters for 
getkey-func and compare-func to org-table-sort-lines. Then add optional 
parameters to org-do-sort for the getkey-func and compare-func functions. If 
the sort type is ?f or ?F org-do-sort would use getkey-func and compare-func 
instead of the built-in functions.

This would make org-table-sort-lines behave the same way that org-sort-list 
does. Then I could solve my original problem by writing a local function that 
calls org-table-sort-lines with the ?f or ?F sort type and appropriate 
extraction and compare functions.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] table formula help...

[Michael Brand]

Hi Thierry

On Fri, Dec 12, 2014 at 10:04 PM, Thierry Banel  wrote:
> Le 12/12/2014 18:15, Michael Brand a écrit :
> Seems doable.
> Would tie the spreadsheet and orgaggregate seamlessly.
> Very appealing!
>
> Are you willing to help me implement those steps?

Where necessary I try to help.

I would break it down to these commits and take a larger break
after 3):

1) Prepare for Calc syntax: Adapt the "(case fun [...]" of
   orgtbl-aggregate-apply-calc-*-function to move from :cols "sum(x)"
   etc. to :cols "vsum(x)" etc.

   #+BEGIN: aggregate :table test :cols ("Item" "vsum(x)")
   | Item | vsum(x) |
   |--+-|

2) Add a separate target column header: The "=" is only a suggestion
   how to separate the target column header from the formula.

   #+BEGIN: aggregate :table test :cols ("Item" "Header = vsum(x)")
   | Item | Header |
   |--+|

3) Unleash complete Calc syntax: Make use of (org-table-make-reference
   with KEEP-EMPTY and NUMBERS constantly nil and use calc-eval

   #+BEGIN: aggregate :table test :cols ("Item" "Header = 2 * vsum(x)
+ 3 * vmean(y)")
   | Item | Header |
   |--+|

4) Add the mode strings "E" and "N": Parse and pass them to KEEP-EMPTY
   and NUMBERS of org-table-make-reference.

   #+BEGIN: aggregate :table test :cols ("Item" "Header = 2 * vsum(x)
+ 3 * vmean(y); EN")
   | Item | Header |
   |--+|

5) Someday add more mode strings.

Michael

Re: [O] [RFC/PATCH] Fixes for org-timer

[Achim Gratz]

Nicolas Goaziou writes:
>> The new tests don't work on Emacs23, mainly due to the use of cl-letf.
>
> I fixed the `cl-letf' issue, thank you. Is there anything else to do?

Not with respect to this change, the tests are now all passing.

However, Emacs master seems to have changed the signature for
call-process-shell-command, so Org might need to work around this with a
new compatibility macro.

In toplevel form:
org-clock.el:1094:13:Warning: call-process-shell-command called with 6
arguments, but accepts only 1-4



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [O] [RFC/PATCH] Fixes for org-timer

[Nicolas Goaziou]

Hello,

Achim Gratz  writes:

> The new tests don't work on Emacs23, mainly due to the use of cl-letf.

I fixed the `cl-letf' issue, thank you. Is there anything else to do?

Regards,

-- 
Nicolas Goaziou

Re: [O] Patch to implement sorting Org tables by IP address

[Nicolas Goaziou]

Jon Snader  writes:

> The problem with that solution is that the user has to answer the
> additional prompts every time he calls org-table-sort-lines with
> a custom sort. Imagine, for example, a networking researcher who often
> builds tables that he or she wants to sort by IP address (or any other
> special format). Why should the researcher have to answer additional
> prompts every time a table needs to be sorted?

He doesn't need to. He could write his own sorting function, and bind it
to a key.

> What if a user wants to call org-do-sort from Elisp? We’d have to add
> additional parameters for the custom sort functions.

`org-do-sort' is an internal function, which isn't meant to be used
publicly. It really should be named `org-table--do-sort' and be moved
within "org-table.el". OTOH, we can extend `org-table-sort-lines' to
allow custom sorting function as a parameter.

> The solution I’m suggesting will simplify org-do-sort, make it easily
> expandable, and allow programmatic calls to it.

I disagree. It makes `org-do-sort'/`org-table-sort-line' more powerful,
but certainly not simpler. I'm pretty sure that anyone able to provide
an alist like you suggest is able to write his own sorting function
anyway. IOW, no one really gains any power in the process.

> It doesn’t really make it easier for the user because the extraction
> and compare functions will still have to be written (at least in most
> cases I can think of).

Extraction function is standard, AFAICT. Your solution doesn't solve
second point either.

> As for org-sort-list, it too would benefit from being table driven for
> the same reason that org-do-sort would: it enables users to define
> custom sorts. If we agree on this approach, I’ll submit another patch
> for org-sort-list.

As pointed out earlier, my concern is about simplicity.

What about simplifying your proposal so that associations are

  (prompt-char . compare-function)

Extraction function would be always the same: the contents of the cell,
as a string, and prompt would be hard-coded for default compare
functions?


Regards,

Re: [O] Patch to implement sorting Org tables by IP address

[Jon Snader]

> On Dec 13, 2014, at 9:29 AM, Nicolas Goaziou  wrote:

> I think my proposal is simpler: add ?f and ?F to built-in options, in
> which case user is prompted for a custom sorting function (in your case,
> `org-ip-lessp'). It is also more consistent with `org-sort-list’.

The problem with that solution is that the user has to answer the additional 
prompts every time he calls org-table-sort-lines with a custom sort. Imagine, 
for example, a networking researcher who often builds tables that he or she 
wants to sort by IP address (or any other special format). Why should the 
researcher have to answer additional prompts every time a table needs to be 
sorted? What if a user wants to call org-do-sort from Elisp? We’d have to add 
additional parameters for the custom sort functions.

The solution I’m suggesting will simplify org-do-sort, make it easily 
expandable, and allow programmatic calls to it. It is, it seems to me, 
consistent with how Emacs does things: add to little Elisp to expand a 
functionality to cover an additional case. As things stand now, it’s not 
possible for me to add an IP sort locally. Your solution does provide that, 
after a fashion, but at the cost of having to enter additional information each 
time I call the sort. It doesn’t really make it easier for the user because the 
extraction and compare functions will still have to be written (at least in 
most cases I can think of).

As for org-sort-list, it too would benefit from being table driven for the same 
reason that org-do-sort would: it enables users to define custom sorts. If we 
agree on this approach, I’ll submit another patch for org-sort-list.

> Also, IMO, IP address sort should not be built-in, and needs not with
> the proposal above.

I don’t care overmuch if the IP address sort is built in (although others might 
appreciate the functionality) only that I have a way of adding it locally.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] Patch to implement sorting Org tables by IP address

[Nicolas Goaziou]

Jon Snader  writes:

> My idea for making it table driven is to add an alist whose elements look 
> something like
>
> (prompt-char prompt extraction-function compare-function 
> reverse-compare-function with-case-extraction-function)
>
> The alist would be initialized with the built-in options (including
> the IP address sort) but a user could call add-to-list to add a custom
> sort to his or her environment.

I think my proposal is simpler: add ?f and ?F to built-in options, in
which case user is prompted for a custom sorting function (in your case,
`org-ip-lessp'). It is also more consistent with `org-sort-list'.

Also, IMO, IP address sort should not be built-in, and needs not with
the proposal above.

Regards,

Re: [O] [PATCH] Selectively archive by timestamp

[Nicolas Goaziou]

Hello,

Toby Cubitt  writes:

> Did this patch get lost in the noise?

Probably.

> It's a fairly straightforward one, which simply adds a useful new
> archiving function without touching much else.
>
> Archiving by date seems such an obvious omission from the existing
> archiving commands, I wouldn't have thought this patch was too
> controversial. (Unless someone doesn't like the choice of keybinding, in
> which case by all means change it!)

Looks good. Could you send it again so I can apply it?

Regards,

-- 
Nicolas Goaziou

Re: [O] Patch to implement sorting Org tables by IP address

[Jon Snader]

> On Dec 12, 2014, at 5:58 PM, Nicolas Goaziou  wrote:

> However I think the feature implemented is too specific. Instead,
> `org-do-sort' could provide a way to pass an arbitrary predicate,
> like ?f and ?F in `org-sort-list'.
> 
> WDYT?

Actually, when I originally looked at org-do-sort, my first thought was that it 
should be table driven. But this is my first patch and I’m the new kid so I 
didn’t want to come in and start tearing down walls.

My idea for making it table driven is to add an alist whose elements look 
something like

(prompt-char prompt extraction-function compare-function 
reverse-compare-function with-case-extraction-function)

The alist would be initialized with the built-in options (including the IP 
address sort) but a user could call add-to-list to add a custom sort to his or 
her environment.

If the list agrees, I will resubmit the patch implementing what I’ve described. 
As a procedural matter, should I submit it to this thread or add a new one?



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] doc patch: move footnote in external links

[Nicolas Goaziou]

Alan Schmitt  writes:

> So you are correct the footnote applies to the text search. However, I
> think is also applies to the headline search (as suggested by the second
> line of the snippet). In other words, if I search for
>
>   file:projects.org::*Headline
>
> with `org-link-search-must-match-exact-headline' set to
> 'query-to-create, then I will be asked to create a headline. 
>
> Should I add a footnote to that effect?

Sure. While you're at it, it should be @code{query-to-create}, not
@code{'query-to-create}.

Also, `org-link-search-must-match-exact-headline' docstring could be
improved: "When nil, the link..." doesn't apply to "*headline" type
paths.

Thanks.

Re: [O] demoting a heading inserts spaces in column-0 text

[Nicolas Goaziou]

Daniel Clemente  writes:

>   No need to teach the user the differences of a :CLOCK: vs
>   a :PROPERTIES: or drawer vs. metadata.

The difference is important, e.g., wrt export.

> Users who type can do a simpler distinction:
>   1. things you type yourself
>   2. things that appear/change/disappear after invoking org functions
>   (C-something, S-something, M-something). E.g.: the words SCHEDULED,
>   TODO, CLOCK, PROPERTIES, EFFORT, checkboxes [ ], timestamps, … 
>
>   I speak for myself, but I expect class 1 not to be changed by org,
> and class 2 to be handled only by org (I can always edit manually, but
> I shouldn't need to do it). I know that you can actually type
> everything in class 2, but you shouldn't NEED to.
>   Any other opinions are welcome.

You are free to make any distinction you want. Unfortunately, Org does
a different one. In particular, as you noticed, there are some areas
where things are not as clear. For example, Org cannot be sure that
a given drawer wasn't inserted manually, so altering its indentation may
or may not be a good choice.

>   Indentation is for me as important as the other letters I type. I don't 
> want it changed.
>   It's a personal preference. Emacs respects it to great extents.

I understand. Simply set `org-adapt-indentation' to nil.

>   Maybe I should clarify that I see the text inside my org files as
> a tree of knowledge. The position inside the tree of a particular item
> does not affect how I write the text (e.g. how many indentation
> spaces). I can move nodes freely from one place to another and I have
> no indentations to fix. „Tree structure“ and „item content“ are
> disconnected.
>   If you really need other sources, you can see how tree operations in
> other contexts don't modify the contents of each node:
> http://pythonhosted.org/ete2/tutorial/tutorial_trees.html#concatenating-trees
>   I wouldn't want titles, clocks, IDs, indentations, properties, priorities 
> etc. changed when the tree structure changes.
>   Maybe other people think the same; you can survey the list.

So, what's wrong with `org-adapt-indentation' set to nil?

>   The only one: indentation is added:
>
>
> After demoting, it changes from this:
>
>  some
> :CLOCK:
> CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
> :END:
> Text
>
>
>
>   to this:
>   
> * some
>  :CLOCK:
>  CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
>  :END:
>  Text

See above.

>   That's similar to a not-so-bad old behaviour. But it's still a bit better 
> (it avoids the problem described in 
> http://permalink.gmane.org/gmane.emacs.orgmode/92450)

The problem described there is different: the OP wants some changes when
tree structure is modified (e.g., planning info moved). You claim to
want no change at all, which is easier, and already implemented.

>> AFAICT, you erroneously think regular drawers are an Org internal
>> artifact whereas they are really meant for users. They should be
>> indented like their contents, no like planning info.
>
>   I do the typed-by-me/not-typed-by-me distinction.

See above.

> Ok, make it:
>
> 2. With org-adapt-indentation = 'partial, new lines added by org
> (:CLOCK: drawer, CLOCK lines etc) are indented at the same level as
> the element above.

This is better, but there is still the hack about text at column 0.

Also, this only makes sense if these lines are also moved when headline
is promoted or demoted. But, then, contents will change along with tree,
which you don't like, and it could break section structure (some lines
being moved and not others), which cannot happen currently.

Another option would be to have another option to indent only planning
info, properties drawer, and every drawer located right after it, à la
`org-log-state-notes-insert-after-drawers'. At least, it couldn't break
structure.


Regards,

Re: [O] demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

El Sat, 13 Dec 2014 12:33:16 +0100 Nicolas Goaziou va escriure:
> >   But these are technical details, not relevant to a non-programmer.
> 
> Which basically means nothing, because everything ultimately boils down
> to technical details.
> 

  That's always true. But UIs still need to be simple.
  No need to teach the user the differences of a :CLOCK: vs a :PROPERTIES: or 
drawer vs. metadata. Users who type can do a simpler distinction:
  1. things you type yourself
  2. things that appear/change/disappear after invoking org functions 
(C-something, S-something, M-something). E.g.: the words SCHEDULED, TODO, 
CLOCK, PROPERTIES, EFFORT, checkboxes [ ], timestamps, …

  I speak for myself, but I expect class 1 not to be changed by org, and class 
2 to be handled only by org (I can always edit manually, but I shouldn't need 
to do it). I know that you can actually type everything in class 2, but you 
shouldn't NEED to.  
  Any other opinions are welcome.


> > - he writes a new tree and some text inside
> > - he clocks in
> > - he demotes the tree (shift+right) because he wants to change the tree 
> > structure. Result: his text also is modified
> 
> FUD. Neither the text nor its structure are modified. Only indentation
> is. How it is done is explained in `org-adapt-indentation' docstring.
> 

  Indentation is for me as important as the other letters I type. I don't want 
it changed.
  It's a personal preference. Emacs respects it to great extents.


> > because in a logical tree of nodes, demoting does not mean „shift
> > contents“.
> 
> Huh? "Citation needed".

  Maybe I should clarify that I see the text inside my org files as a tree of 
knowledge. The position inside the tree of a particular item does not affect 
how I write the text (e.g. how many indentation spaces). I can move nodes 
freely from one place to another and I have no indentations to fix. „Tree 
structure“ and „item content“ are disconnected.
  If you really need other sources, you can see how tree operations in other 
contexts don't modify the contents of each node: 
http://pythonhosted.org/ete2/tutorial/tutorial_trees.html#concatenating-trees
  I wouldn't want titles, clocks, IDs, indentations, properties, priorities 
etc. changed when the tree structure changes.
  Maybe other people think the same; you can survey the list.
  

> >   I also lose controllability because I have no way to rearrange nodes
> >   without side effects.
> 
> We might fix them. What are exactly these side-effects?
> 
  The only one: indentation is added:


After demoting, it changes from this:

 some
:CLOCK:
CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
:END:
Text



  to this:
  
* some
 :CLOCK:
 CLOCK: [2013-11-12 Sel 10:45]--[2013-11-12 Sel 11:40] =>  0:55
 :END:
 Text


This will happen in all subtrees.


> >   I suggest:
> >
> > 1. New default for org-adapt-indentation = 'partial, which shifts
> > every line until the first line which starts at column 0. This may not
> > shift all drawers in complex cases where you have them in the bottom
> > of the tree; therefore it's called partial.
> 
> I'm not really against it, but this is really hackish and probably
> surprising.

  That's similar to a not-so-bad old behaviour. But it's still a bit better (it 
avoids the problem described in 
http://permalink.gmane.org/gmane.emacs.orgmode/92450)


> AFAICT, you erroneously think regular drawers are an Org internal
> artifact whereas they are really meant for users. They should be
> indented like their contents, no like planning info.

  I do the typed-by-me/not-typed-by-me distinction.
 
> 
> > 2. With org-adapt-indentation = 'partial, new lines added by org
> > (:CLOCK: drawer, CLOCK lines etc) appear at the same column as the
> > heading, not at column 0
> 
> This would be plain wrong. Indentation is relative to the element above.
> Heading indentation is but the fallback value.
> 

Ok, make it:

2. With org-adapt-indentation = 'partial, new lines added by org
(:CLOCK: drawer, CLOCK lines etc) are indented at the same level as the element 
above.



--
Daniel

Re: [O] Evaluating R source code line by line

[Vikas Rawal]

On 13-Dec-2014, at 3:42 pm, Daniele Pizzolli  wrote:
> Look at:
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html
> 
>  Use ESS to step through evaluation line-by-line
> 
>Use C-c ' to visit the edit buffer for your code block
>Use ess-eval-line-and-step to evaluate each line in turn
> 
> ess-eval-line-and-step is usually bound to C-c C-n

I know this and use it. But since my code evaluation is quite resource 
intensive, when I later evaluate the code using C-c C-c to insert results in my 
org buffer, it would be useful to see how far it is progressing.

Vikas

Re: [O] /emsp in clock tables

[Joost Helberg]

Nicolas et al,

I'm sure the choice for \emsp was a valid one. \emsp is not the bug, it
triggers a bug in the alignment routine which screws up somehow. If
alignment takes place after displaying the blanks, things turn out OK. I
tried to install a custom formatter (Cutomizable: Org Clock Clocktable
Formatter): 

 (defun my-formatter( ipos tables params )
   (progn
 (org-clocktable-write-default ipos tables params)
 (forward-line 2)
 (org-table-align)
 )
   )

But this didn't help. Going inside the table and hitting C-c C-c helps,
but is a bit cumbersome.

Somehow moving the aligning to another place in the process should fix
this. I wasn't able to make this work.

regards,

Joost

> "Nicolas" == Nicolas Goaziou  writes:
 > From: Nicolas Goaziou 
 > To: J. David Boyd 
 > Cc: emacs-orgmode@gnu.org
 > Subject: Re: [O] /emsp in clock tables
 > Date: 2014-12-13T00:05:06+0100

 > dbo...@mmm.com (J. David Boyd) writes:

 >> Now I get lines like:
 >> 
 >> | Tasks  | 1:18   |  |  |  |
 >> | \__ Infrastructure || 0:31 |  |  |
 >> | \ WAITING Email||  | 0:07 |  |
 >> | \__ WAITING - respond to Bill  ||  |  | 0:01 |
 >> | \ WAITING Research - Gnus  ||  | 0:14 |  |
 >> | \ WAITING Research - Web   ||  | 0:04 |  |
 >> 
 >> which is exactly what I wanted.
 >> 
 >> I read the linked message above from Buddy Butterfly. Was the problem only 
 >> for
 >> latext exporting?  I personally look at the screen more than export...

 > The problem is that "\___" appears in any export output, not only LaTeX.

 > Another option could be to use dots. At least, they wouldn't be as ugly
 > as "\___" in output, and keep clocktable readable in the buffer.

 > Regards,


-- 
Snow B.V.

Re: [O] doc patch: move footnote in external links

[Alan Schmitt]

Hello,

On 2014-12-12 18:29, Nicolas Goaziou  writes:

> Hello,
>
> Alan Schmitt  writes:
>
>> I think the footnote in
>> http://orgmode.org/manual/External-links.html#fn-1 is in the wrong
>> place, it should be on the next line.
>>
>> Here is a patch to fix it. If you prefer I can push it directly
>> myself.
>
> I think the current documentation is correct. Only
>
>  file:projects.org::some words
>
> can trigger a text search. OTOH
>
>   file:projects.org::*Headline
>
> is always an exact match against headlines in the file.

I've re-read the code, and I think this is partially correct. The only
place the `org-link-search-must-match-exact-headline' is used is below,
in a big conditional in `org-link-search'. The clauses before are used
to check special cases.

#+begin_src emacs-lisp
 ((and (derived-mode-p 'org-mode) org-link-search-must-match-exact-headline)
  (and (equal (string-to-char s) ?*) (setq s (substring s 1)))
  (goto-char (point-min))
  (cond
   ((let (case-fold-search)
  (re-search-forward (format org-complex-heading-regexp-format
 (regexp-quote s))
 nil t))
;; OK, found a match
(setq type 'dedicated)
(goto-char (match-beginning 0)))
   ((and (not org-link-search-inhibit-query)
 (eq org-link-search-must-match-exact-headline 'query-to-create)
 (y-or-n-p "No match - create this as a new heading? "))
(goto-char (point-max))
(or (bolp) (newline))
(insert "* " s "\n")
(beginning-of-line 0))
   (t
(goto-char pos)
(error "No match"
#+end_src

So you are correct the footnote applies to the text search. However, I
think is also applies to the headline search (as suggested by the second
line of the snippet). In other words, if I search for

  file:projects.org::*Headline

with `org-link-search-must-match-exact-headline' set to
'query-to-create, then I will be asked to create a headline. 

Should I add a footnote to that effect?

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature

Re: [O] can I refile or archive from the agenda without rebuilding?

[Alan Schmitt]

On 2014-12-12 12:01, Kyle Meyer  writes:

> Alan Schmitt  wrote:
>> My agenda is fairly big, and it takes a few minutes to generate it.
>
> Wow.

I meant seconds (about 20 seconds). But is feels like minutes ;)

>> When I need to refile many items to different places (so bulk edit is
>> not an option), it slows me down quite a bit. Is there an option to
>> prevent rebuilding the agenda after archiving or refiling?
>
> org-agenda-refile takes a NO-UPDATE argument.  To set this
> interactively, you could advise org-agenda-refile (or wrap it in another
> command).

This is a great suggestion, thanks! It works perfectly.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7


signature.asc
Description: PGP signature

Re: [O] demoting a heading inserts spaces in column-0 text

[Nicolas Goaziou]

Daniel Clemente  writes:

>   But these are technical details, not relevant to a non-programmer.

Which basically means nothing, because everything ultimately boils down
to technical details.

> What a new user sees with the default settings as of today is:

Aren't you confusing your expectations and new users'?

> - he writes a new tree and some text inside
> - he clocks in
> - he demotes the tree (shift+right) because he wants to change the tree 
> structure. Result: his text also is modified

FUD. Neither the text nor its structure are modified. Only indentation
is. How it is done is explained in `org-adapt-indentation' docstring.

>   This breaks user's expectations. At least it breaks my expectations,

There we are.

> because in a logical tree of nodes, demoting does not mean „shift
> contents“.

Huh? "Citation needed".

> And I thought org was supposed not to break my content.

It also kills kittens, in the background.

>   I also lose controllability because I have no way to rearrange nodes
>   without side effects.

We might fix them. What are exactly these side-effects?

>   I suggest:
>
> 1. New default for org-adapt-indentation = 'partial, which shifts
> every line until the first line which starts at column 0. This may not
> shift all drawers in complex cases where you have them in the bottom
> of the tree; therefore it's called partial.

I'm not really against it, but this is really hackish and probably
surprising.

AFAICT, you erroneously think regular drawers are an Org internal
artifact whereas they are really meant for users. They should be
indented like their contents, no like planning info.

In any case, I'd favor a solution that takes into consideration the real
structure of the section.

> This is handling the most common cases.

Let's focus on your use case instead of a "most common case" we both
know very little about.

> 2. With org-adapt-indentation = 'partial, new lines added by org
> (:CLOCK: drawer, CLOCK lines etc) appear at the same column as the
> heading, not at column 0

This would be plain wrong. Indentation is relative to the element above.
Heading indentation is but the fallback value.


Regards,

Re: [O] demoting a heading inserts spaces in column-0 text

[Daniel Clemente]

El Fri, 12 Dec 2014 19:25:25 +0100 Nicolas Goaziou va escriure:
> 
> >   Of course everything's text, but if there's no distinction between
> > drawers/headers and text, that's the problem. Those headers are metadata
> > written and managed by org and must follow some rules,
> 
> This is incorrect.
> 
> :CLOCK: or :LOGBOOK: or whatever the value of `org-clock-into-drawer'
> is, are regular drawers conveniently provided to collect clocks and
> allow to hide them away. They have no special meaning in Org, and may
> not even exist (i.e., when `org-clock-into-drawer' is nil). There is no
> reason to treat them specially.
> 
> OTOH, clocks themselves are pure metadata. They could be indented
> specifically, but since they are allowed anywhere in a section, it might
> be dangerous to do so (e.g. it could break a list). Actually, this is
> true for anything that need to appear at the very beginning of the
> section, i.e., anything but planning info and properties drawers.
>
> > […]
> This is also wrong. PROPERTIES drawer, which is metadata, has to be
> moved before anything else in the section (with the exception of
> planning info). This has nothing to do with CLOCK drawers, which are not
> even considered in the process.
> 
> >   So, I think org should detect its own syntax (:CLOCK: ... :END: etc.), and
> > do automatic changes only to its own syntax, not to text typed by the user
> > unless the user asks for it.
> 
> Again, :CLOCK:...:END: is user's decision, not Org's. So are all
> drawers, but, of course, PROPERTIES. The latter is the exception, not
> the rule.

  But these are technical details, not relevant to a non-programmer. What a new 
user sees with the default settings as of today is:
- he writes a new tree and some text inside
- he clocks in
- he demotes the tree (shift+right) because he wants to change the tree 
structure. Result: his text also is modified
  This breaks user's expectations. At least it breaks my expectations, because 
in a logical tree of nodes, demoting does not mean „shift contents“. And I 
thought org was supposed not to break my content.
  I also lose controllability because I have no way to rearrange nodes without 
side effects.
  
  I suggest:

1. New default for org-adapt-indentation = 'partial, which shifts every line 
until the first line which starts at column 0. This may not shift all drawers 
in complex cases where you have them in the bottom of the tree; therefore it's 
called partial. This is handling the most common cases. And in case you had 
indentation in all lines, all lines will be shifted.

2. With org-adapt-indentation = 'partial, new lines added by org (:CLOCK: 
drawer, CLOCK lines etc) appear at the same column as the heading, not at 
column 0

3. The other options stay the same: org-adapt-indentation=t means everything 
will be shifted, org-adapt-indentation=nil means nothing will be shifted (new 
text starts at column 0)



-- Daniel

Re: [O] Evaluating R source code line by line

[Daniele Pizzolli]

Hello,

Vikas Rawal writes:

> I have an R source code blocks called with the ":results value”
> option. I evaluate the code with C-c. When I do that, in my R session
> buffer, I get to see several + + + until the final value is obtained,
> and then the final value is shown, and inserted in my Org buffer.
>
> I was wondering if there is an option somewhere that will allow me to
> instead see how each line in my R source code is evaluated. That is,
> the R session buffer should show each line being evaluated, and then
> show the final value as usual.

Look at:
http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html

  Use ESS to step through evaluation line-by-line

Use C-c ' to visit the edit buffer for your code block
Use ess-eval-line-and-step to evaluate each line in turn
 
ess-eval-line-and-step is usually bound to C-c C-n

I guess that is possible to use the same R session by configuring the
session arguments and/or the ESS settings but I have not done it yet.

If you do not have ESS you can try a more lightweight solution with
isend-mode.

Best,
Daniele

Re: [O] Emulating list functionality from traditional GUI editors

[Calvin Young]

No problem, I've gone ahead and packaged my changes here:
https://github.com/calvinwyoung/org-autolist
I'll also submit this to melpa to make it easier to install.

I'd love hear how other Org'ers on this list feel about it. If folks find
it useful, I'd be happy to publish it on Worg as well.

Best,
Calvin

On Fri, Dec 12, 2014 at 12:37 AM, Sebastien Vauban 
wrote:
>
> Calvin Young wrote:
> > Makes sense! Just wanted to see how others felt about this :)
> >
> > Anyway thanks for the consideration, and for the tip
> > about org-element-at-point -- really did make this trivial to implement.
>
> Once your customizations are done, it would be nice if you'd publish
> them on Worg, for future Org'ers who share your editing habits.
>
> Best regards,
>   Seb
>
> --
> Sebastien Vauban
>
>
>

Re: [O] [RFC/PATCH] Fixes for org-timer

[Achim Gratz]

Nicolas Goaziou writes:
> Applied (with a minor change in `org-timer--get-timer-title'). Thank you.

The new tests don't work on Emacs23, mainly due to the use of cl-letf.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs