Re: [O] generating org headings from a source block

[Matt Price]

On Mon, Nov 9, 2015 at 4:57 PM, Nick Dokos  wrote:

> Matt Price  writes:
>
> > I would like to be able to insert into an org-buffer the text extracted
> from a pdf file. PDF-Tools (
> > https://github.com/politza/pdf-tools/) provides some excellent tools
> for doing this.  I've written
> > (well, msotly stolen) a defun that finds all my highlights and returns
> them in the form of an org
> > heading:
> >
> > (defun pdf-annot-export-as-org-heading (pdfpath)
> >   ...)
> > -
> >
> > I'm sure it is very clumsy, but it sort of works.  I would like to be
> able to call this function from a
> > source block:
> >
> > #+BEGIN_SRC elisp
> > (pdf-annot-export-as-org-heading
> "/home/matt/HackingHistory/readings/latour-pandoras-hope.pdf")
> > (pdf-annot-export-as-org-heading
> "/home/matt/HackingHistory/readings/historical-authority-hampton.pdf")
> > #+END_SRC
> >
> > The results are close to, but not precisely, what I want:
> >
> > #+RESULTS:
> > #+begin_example
> > ** historical-authority-hampton
> >
> >
>  
> ([[file:///home/matt/HackingHistory/readings/historical-authority-hampton.pdf]
> > [historical-authority-hampton]], 1)
> >
> > In the Tudor palace at Hampton Court, there is a
> > ...
> > #+end_example
> >
> > (a) I only get the last command, because I guess :results value only
> reports the final returned value.
> > But :results output gets me nothing.  What should I be doing?
>
> Have two source blocks? Or use :results output and output the string with
> (princ string)?
>

I ended up with this.  It's not so bad, Though I use it enough that I
should probably just define another function. Also, I'm interested in how 2
source blocks would have worked...

#+BEGIN_SRC elisp :results output raw
  (let ((sources '(

"/home/matt/HackingHistory/readings/Troper-becoming-immigrant-city.pdf"
"/home/matt/HackingHistory/readings/historical-authority-hampton.pdf"))
(output ""))
(dolist (thispdf sources)
  (message "this pdf is: %s" thispdf)
  (setq output (concat output (pdf-annot-markups-as-org-text thispdf

(princ output))
#+END_SRC


>
> > (b) the whole output is wrapped in an example block, which I don't
> want.  Can I do something to fix
> > this?
>
> Maybe :results value raw  or :results value verbatim - untested. I can
> never remember the right combo off the top of my head.
>

:results value raw works -- thank you!

>
> > also, (c): I'd rather set the level of the org heading based on context.
> Can I do that when I call from
> > a source block? Should I maybe be doing this some other way (e.g., jsut
> write an interactive function
> > and call it with M-x? But I like being able to assemble all the readings
> at one go, if possible.
> >
>
> Pass the level as a parameter?
>

Can I pass the level of the current heading as a parameter, e.g.:
 #+BEGIN_SRC elisp :results output raw :var level=(1+ CURRENT-ORG-LEVEL)

where obviously CURRENT-ORG-LEVEL is some function I don't know how to
access?

Many thanks for your help, Nick!

>
> --
> Nick
>
>
>
>
>

Re: [O] [PATCH] ox-extra.el: Fix filtering of latex header blocks

[Aaron Ecay]

Hi Sebastian,

Thanks for the patch.  In addition to Kyle’s comments:

2015ko urriak 9an, Sebastian Christ-ek idatzi zuen:
> 
> Hi group,
> 
> I'd like to provide a patch to
> ox-extra.el. `org-latex-header-blocks-filter' still calls
> `org-edit-src-find-region-and-lang' and raises therefore an undefined
> function error.
> 
> Best wishes,
> Sebastian
> 
> From 34b76e06bda5739e433c95b451915c8b804a1733 Mon Sep 17 00:00:00 2001
> From: Sebastian Christ 
> Date: Fri, 9 Oct 2015 17:37:39 +0200
> Subject: [PATCH] ox-extra.el: Fix filtering of latex header blocks
> 
> * ox-extra.el (org-latex-header-blocks-filter): Use `org-element' API to
>   find begin and end of latex header blocks.
> 
> `org-latex-header-blocks-filter' still called
> `org-edit-src-find-region-and-lang' and raised an undefined function
> error because the funtion was removed from org-mode. This is fixed by 
> determining the
> begin and end of the latex block via `org-element'.
> ---
>  contrib/lisp/ox-extra.el | 28 
>  1 file changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/contrib/lisp/ox-extra.el b/contrib/lisp/ox-extra.el
> index e6d45cc..bb838fc 100644
> --- a/contrib/lisp/ox-extra.el
> +++ b/contrib/lisp/ox-extra.el
> @@ -71,18 +71,22 @@
>  (org-element-property :end block)
>  (org-element-property :post-affiliated block)))
>(mapc (lambda (pos)
> -   (goto-char (nth 2 pos))
> -   (destructuring-bind
> -   (beg end  ignore)
> -   (org-edit-src-find-region-and-lang)
> - (let ((contents-lines (split-string
> -(buffer-substring-no-properties beg end)
> -"\n")))
> -   (delete-region (nth 0 pos) (nth 1 pos))
> -   (dolist (line contents-lines)
> - (insert (concat "#+latex_header: "
> - (replace-regexp-in-string "\\` *" "" line)
> - "\n"))
> +  (let* ((beg (third pos))
> + (end (second pos))
> + (post-affiliated (first pos))
> + (contents-lines
> +  (cdr (butlast
> +(split-string
> + (buffer-substring-no-properties post-affiliated
> + end)
> + "\n")
> +2

Here I think you should use (org-element-property :value X) to get the
contents-lines.  This means that it should be added to the list that’s
constructed from :begin, :end, and :post-affiliated higher up.  (And
then I think :post-affiliated can be dropped from that list.)

I’m not sure why I didn’t do it that way in the first place, actually.

-- 
Aaron Ecay

Re: [O] generating org headings from a source block

[Nick Dokos]

Matt Price  writes:

> > also, (c): I'd rather set the level of the org heading based on 
> context. Can I do that when I call
> from
> > a source block? Should I maybe be doing this some other way (e.g., jsut 
> write an interactive
> function
> > and call it with M-x? But I like being able to assemble all the 
> readings at one go, if possible. 
> >
>
> Pass the level as a parameter?
>
> Can I pass the level of the current heading as a parameter, e.g.:
>  
>
> where obviously CURRENT-ORG-LEVEL is some function I don't know how to access?
>

You can at the very least set the level manually:

#+BEGIN_SRC elisp :results output raw :var level=3
...

by just eyeballing where the source block is in your file.
I think that's easy and does not require any programming.
You just have to remember to change the level when you cut
and paste the code block to other places.

There is org-current-level though if you want to go that way.

--
Nick

Re: [O] org-lint does not finish on some org-mode buffer

[Karl Voit]

* Gregor Zattler  wrote:
>
> I run org-lint on one of my org-mode buffers -- 13015 lines with
> ~2000 CLOCK: lines -- and it did not finish within 1 1/2 hours.

Independent to your resolved issue: on my Org-mode files with 30,000
to 40,000 lines of Org-mode my computer took up to 12 hours to
finish org-lint.

Interesting fact: after finishing and saving the results, GNU/Emacs
runs into an endless-loop when I try to exit Emacs.

If this is of any interest, I can re-run org-lint over night and
post the stack trace of C-g.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: [O] [PATCH] ox-extra.el: Fix filtering of latex header blocks

[Kyle Meyer]

Sebastian Christ  writes:

[...]

>   >> +  (let* ((beg (third pos))
>   >> + (end (second pos))
>   >> + (post-affiliated (first pos))
>   Kyle>
>   Kyle> Hmm, the pos items are constructed as
>   Kyle>
>   Kyle> (list (org-element-property :begin block)
>   Kyle>   (org-element-property :end block)
>   Kyle>   (org-element-property :post-affiliated block)))
>   Kyle>
>   Kyle> so shouldn't beg be the first element and post-affiliated the third?
>
> I thought it would be better to change as little as
> possible. Rearranging the list is obviously the cleaner solution. I'll
> change that.

Sorry, my question wasn't clear.  I wasn't concerned about arrangement,
but about whether you're accessing the correct element of the list.  If
the list is constructed as (:begin :end :post-affiliated), why does your
let-binding above take the third element as beg and the first element as
post-affiliated?

--
Kyle

Re: [O] generating org headings from a source block

[Matt Price]

On Tue, Nov 10, 2015 at 11:16 AM, Nick Dokos  wrote:

>
> > Pass the level as a parameter?
> >
> > Can I pass the level of the current heading as a parameter, e.g.:
> >
> > where obviously CURRENT-ORG-LEVEL is some function I don't know how to
> access?
> >
>
> You can at the very least set the level manually:
>
> #+BEGIN_SRC elisp :results output raw :var level=3
> ...
>
> by just eyeballing where the source block is in your file.
> I think that's easy and does not require any programming.
> You just have to remember to change the level when you cut
> and paste the code block to other places.
>
> There is org-current-level though if you want to go that way.
>
> :var level=(1+ (org-current-level))
works great.  Thank you Nick!

Re: [O] Allowing loose ordering in Org files

[Matt Lundin]

John Wiegley  writes:

>> Aaron Ecay  writes:
>
>> Adding knobs to this parser increases the burden of those who have to build
>> and maintain it.
>
> Thank you for your reply, Aaron, I found it most illuminating.
>
> If the answer from the maintainers is "It's more work than we want to
> do", that's completely acceptable. I've been operating under the
> premise that it wouldn't be difficult to add such an option (just the
> hook, mind you, not the functionality behind it).

After looking quickly at the code, my impression is that without
substantial refactoring, a hook/variable pointing to an alternate "find
property drawer" function is not a very clean option, since org makes
the assumption in several places that the property drawer comes
immediately after the planning info. See, for instance,
org-insert-drawer, org-end-of-meta-data, org-get-property-block.

If you were to hack something on your own, I suppose your could
rewrite/advise org-get-property-block, but I have no idea what else that
would break.

> If my request is fulfilled, I would expect that changing the "find
> properties function" would imply that one's Org file is no longer
> usable by secondary interpreters. I.e., "If you change this, you do so
> at your own risk".
[ ... quoted from another email ] 

I would vote against creating a hook or variable that comes with a
warning "change this at your own risk." I am concerned about the
precedent this would set. This seems to me what defadvice is for. Would
this really be a simpler option than posting a hack on emacswiki or
github? After all, anyone customizing the variable would still have to
grab the custom function from github, etc.

IMO, to add a customization option that might (and probably will) break
other parts of org mode threatens to add complexity to the maintenance
of org, since it might create a base of users who are relying on a
"semi-officially supported hack" rather than the official parsing logic
supported by org. Despite the disclaimer, maintainers will still be
forced to keep the possibility of this customization in mind when
rewriting functions that parse org syntax. And even if a user accepts
the full risk of the customization, it is still possible that he/she
might accidentally report a bug to the mailing list when something
breaks (not realizing it is related to the customization).

In short, if we allow for an alternative parsing logic, I think it
should be one that is officially supported/maintained.

Best,
Matt

Re: [O] Allowing loose ordering in Org files

[Nicolas Goaziou]

Hello,

Thomas S. Dye  writes:

> Is the hook he is requesting a difficult thing to implement?  Would it
> be possible to describe the customization variable in a "Super User"
> section that is clearly not for the faint at heart?
>
> I'm not suggesting anyone should implement a hook or create a
> customization variable, I'm just curious (and unable to figure out
> answers on my own).

I really don't like the idea of making Org /syntax/ customizable, would
it be with the help of a hook or a variable.

Regards,

-- 
Nicolas Goaziou

Re: [O] Allowing loose ordering in Org files

[Matt Lundin]

John Wiegley  writes:

> There is another vector to consider, and a far more nebulous one: How does it
> impact Org's "luft"? That is, the feeling of ease and comfort Org conveys in
> its use.

FWIW, I personally have found org both faster and much more reliable
thanks to Nicolas' heroic work to tighten up org syntax. Org files open
faster, the agenda parses faster, the exporter is orders of magnitude
more consistent, org babel blocks behave as expected, etc. And the user
interaction has far fewer glitches than I experienced before the change.
For instance, for years, org mode functions on my machine often inserted
property drawers inside of property drawers or inserted multiple
property drawers in a single entry. In my experience, the changes to the
parser have made all this much more robust and predictable.

So for me, the increasing robustness of org mode makes it feel easier,
more pleasant to use.

> There are many highly functional alternatives to Org that I've tried
> and rejected because they lack the easy grace of Org. That grace is
> why I've been able to stick with it after almost 9,000 handled tasks.
> Any perception of "inertia" in a tasking system causes me to
> psychologically avoid it, even if I have no rational basis for that
> aversion.
>
> I sincerely hope that those with high technical motives will keep in mind the
> usability of Org beyond purely technical considerations. It should say
> something that a long-time user is unhappy with the way Org "feels" in 8.3.

I'm not sure "purely technical" is fair characterization of the reasons
for the syntax changes. As I understand it, the chief reason that org
syntax needed a cleanup is because of the massive amount of
functionality that org mode acquired over the years. Ensuring all this
worked smoothly and robustly for users required a more regular,
predictable syntax. So user experience was key to the changes as well.

Best,
Matt

Re: [O] Allowing loose ordering in Org files

[Thomas S . Dye]

Nicolas Goaziou  writes:

> Hello,
>
> Thomas S. Dye  writes:
>
>> Is the hook he is requesting a difficult thing to implement?  Would it
>> be possible to describe the customization variable in a "Super User"
>> section that is clearly not for the faint at heart?
>>
>> I'm not suggesting anyone should implement a hook or create a
>> customization variable, I'm just curious (and unable to figure out
>> answers on my own).
>
> I really don't like the idea of making Org /syntax/ customizable, would
> it be with the help of a hook or a variable.

OK.  IIUC, John's options if he wants to continue using Org mode are to
run org-repair-property-drawers, craft a defadvice to change how
property drawers are identified, or use 8.2.

I've found org-lint helpful in keeping old Org mode files functional,
but my files are much less structured than John's seem to be.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [O] Using link abbrevations for EXPORT_FILE_NAME ?

[Nicolas Goaziou]

AW  writes:

> Background: I'm using orgmode on different platforms, Windows and Linux. So I 
> (being very proud of that!) wrote an if-clause:
>
> (setq org-link-abbrev-alist
>(if (eq system-type 'windows-nt)
>   '(("foopath" . "//Sbs2011/ra2000/Bilder/2010/271-2011/%s")
> )
>   '(("foopath" . "/home/AW/some/path/2011-271-project/%s")))
>
>
>
> So on Windows foopath becomes the first path, and on Linux the second and all 
> my links in the orgmode files work on both platforms.
>
> A cheap solution for EXPORT_FILE_NAME: just have two lines and comment out 
> the 
> wrong one!
>
> -
> * Subtree to be exported
> :PROPERTIES:
> # :EXPORT_FILE_NAME: //Sbs2011/ra2000/Bilder/2010/271-2011/filename
> :EXPORT_FILE_NAME: /home/AW/some/path/2011-271-project/filename
> :EXPORT_TITLE:
> :END:
>
> foo
>
> -
>
> But comment seems not to work inside properties.
>
> However, :EXPORT_FILE_DIRECTORY: would only improve _my_ situation, if I 
> could 
> make it dependend on a condition.

At this point, I suggest to write your own `org-export-subtree-to'
function. You can have a look at, e.g., `org-html-export-to-html' and
override the call to `org-export-output-file-name'.

Elisp should provide the flexibility Org cannot offer.


Regards,

Re: [O] [PATCH] org-babel-execute-src-block-region

[Carlos Henrique Machado S Esteves]

Hello Chuck,

Thank you for the feedback.

> You might want to check that point and mark are both inside the src
block. Otherwise, the results are unpredictable.
You are right, I've updated the patch.

> ess-mode, python-mode, sh-mode and octave-mode already provide this
capability (and a lot more) for R, python, shell scripts, octave/matlab and
some other languages from the edit buffer.
I understand that. My idea is to avoid the need to C-c ' back and forth.
Actually that's a problem I have with org-babel; I usually find myself
coding inside the src block and losing many of the major mode
functionalities; switching to the edit buffer often seem too much of a
hassle. Any tips about how to get more major-mode functionalities inside
the src-block? Or should I develop the muscle memory to switch back and
forth to the edit buffer all the time?

> `org-babel-demarcate-block' gives the user the ability to break up src
blocks into smaller pieces so they can be run independently.
Thanks for pointing that; I didn't know about `org-babel-demarcate-block'.

Best,

Carlos

2015-11-02 13:19 GMT-05:00 Charles C. Berry :

> On Sun, 1 Nov 2015, Carlos Henrique Machado S Esteves wrote:
>
> Hello, I find it useful to be able to execute only a region of a source
>> code block, so I've implemented a new function for that. I've tested it
>> with MATLAB and Python, but it should work for any mode, since it calls
>> org-babel-execute-src-block.
>>
>>
> You might want to check that point and mark are both inside the src block.
> Otherwise, the results are unpredictable.
>
> Also note that:
>
> ess-mode, python-mode, sh-mode and octave-mode already provide this
> capability (and a lot more) for R, python, shell scripts, octave/matlab and
> some other languages from the edit buffer.
>
> `org-babel-demarcate-block' gives the user the ability to break up src
> blocks into smaller pieces so they can be run independently.
>
> Best,
>
> Chuck
>
>
From b677ad4416d9e8dd564a46fcb4136cf6f5a90b29 Mon Sep 17 00:00:00 2001
From: Carlos HMS Esteves 
Date: Sun, 1 Nov 2015 20:52:26 -0500
Subject: [PATCH] ob-core.el: Allow execution of region of source code block

* ob-core.el (org-babel-execute-src-block-region): Execute only active region of
the current source block.  Same as `org-babel-execute-src-block', but
use only the active region instead of the whole block.

TINYCHANGE
---
 lisp/ob-core.el | 28 
 1 file changed, 28 insertions(+)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index b8ea12d..a2ef6c1 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -739,6 +739,34 @@ block."
 	  (setq call-process-region
 		'org-babel-call-process-region-original)
 
+(defun org-babel-execute-src-block-region (beg end)
+  "Execute region in the current source code block.
+`org-babel-execure-src-block' is called; the only change is that
+only the active region is sent, instead of the whole block."
+  (interactive "r")
+  (if (org-babel-is-region-within-src-block beg end)
+  (let ((info (org-babel-get-src-block-info)))
+	(setcar (nthcdr 1 info) (buffer-substring beg end))
+	(org-babel-execute-src-block nil info))
+(message "Region not in src-block!")))
+
+(defun org-babel-is-region-within-src-block (beg end)
+  "Check if region is within a single src-block.
+Block header and footer are ignored, so we are checking for the
+source code only.
+Used by `org-babel-execute-src-block-region' to check if region
+is executable."
+  (save-excursion
+(eq
+ (progn
+   (goto-char beg)
+   (forward-line -1)
+   (org-babel-where-is-src-block-head))
+ (progn
+   (goto-char end)
+   (forward-line 1)
+   (org-babel-where-is-src-block-head)
+
 (defun org-babel-expand-body:generic (body params  var-lines)
   "Expand BODY with PARAMS.
 Expand a block of code with org-babel according to its header
-- 
2.1.4

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Achim Gratz  writes:

> If you don't use properties then it doesn't affect you at all. If you do,
> then… well, I personally simply don't care. Just like there's several style
> guides for writing C; as long as these are applied consistently I can live
> with most of them and put the braces and indents the way they prescribe.

In my regimen, every single entry has a PROPERTIES drawer, since I tag each
one with ID and CREATED, for future reference. Most items are SCHEDULED as
well. So when I open up a headline to look at the contents, I see:

* Head
SCHEDULED
text
:PROPERTIES:...

It's a trivial thing, but I'd rather not scan past two lines to start reading
my entry.

What a lot of people want is trivial, and only relevant to them, but part of
the Emacs philosophy is to give them the freedom to customize their
environment the way they want it to work, rather than decide for them what is
the "right way".

I won't argue for this anymore, if it really does incur work for you that only
benefits me and a few others. I suppose that I'm still writing these e-mails
because I want to inject some sensitivity about these matters into your future
decisions, so you don't take away such flexibility again lightly.

> So write the advise and move on? If you weren't so heavily invested in what
> you perceive as "the right style" you quite likely wouldn't care, or would
> you?

I'm invested in the spirit of the project, since I've been using it for a very
long time, and continue to recommend it to many people as an amazing tool for
self-organization. The more it becomes something I have to hack to like, the
less I feel like putting my heart into it.

I *care*, which is maybe both a blessing and a curse. It is the origin of my
creative contributions, but also the cause of these annoying threads. I'd
rather work with you guys than against you; but there are some sacred cows
that moan plaintively, when a sharp parenthesis is drawn across their throats.

Yours,
  John

Re: [O] Allowing loose ordering in Org files

[Achim Gratz]

John Wiegley writes:
> If the answer from the maintainers is "It's more work than we want to do",
> that's completely acceptable. I've been operating under the premise that it
> wouldn't be difficult to add such an option (just the hook, mind you, not the
> functionality behind it).

To answer your question from another post: If we add a hook, but not the
functionality behind it, then we are going to advertise something we
don't recommend to do on grounds that a random user might very well not
comprehend.  If we do add the functionality we might be better off with
an option rather than a hook, but then we incur the debt of having to
support it both in the syntax and the implementation.  That was the
reason I asked you about simply advising some function.  It doesn't
advertise some option that then isn't implemented and if someone really
cares about that functionality we can still show (even on Worg) how to
do it.  But not in the Org manual or as an official option.

[There was a precedent to this with Org 7 where you could go in and
change what Org considered a headline.  When this was changed we've had
similar discussions and I expect this one to take the same route to be
honest.]

> There is another vector to consider, and a far more nebulous one: How does it
> impact Org's "luft"? That is, the feeling of ease and comfort Org conveys in
> its use.

If you don't use properties then it doesn't affect you at all.  If you
do, then… well, I personally simply don't care.  Just like there's
several style guides for writing C; as long as these are applied
consistently I can live with most of them and put the braces and indents
the way they prescribe.

> There are many highly functional alternatives to Org that I've tried and
> rejected because they lack the easy grace of Org. That grace is why I've been
> able to stick with it after almost 9,000 handled tasks. Any perception of
> "inertia" in a tasking system causes me to psychologically avoid it, even if I
> have no rational basis for that aversion.
>
> I sincerely hope that those with high technical motives will keep in mind the
> usability of Org beyond purely technical considerations. It should say
> something that a long-time user is unhappy with the way Org "feels" in 8.3.

So write the advise and move on?  If you weren't so heavily invested in
what you perceive as "the right style" you quite likely wouldn't care,
or would you?


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

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Nicolas Goaziou  writes:

> I really don't like the idea of making Org /syntax/ customizable, would it
> be with the help of a hook or a variable.

>From what I've seen so far, several users want regularity of syntax to decide
formatting, and several users want user preference to decide formatting. There
do seem to be larger costs for letting the user decide; but there are also
costs to not letting the user decide, that I feel are not being appreciated.

The reason I'm sticking on this point is because it also relates to our future
road map. If Org continues to do this -- to trade flexibility of formatting
for regularity of parsing -- it might continue to alienate some of us.

John

Re: [O] Allowing loose ordering in Org files

[Matt Lundin]

Matt Lundin  writes:

> John Wiegley  writes:
>
>>> Nicolas Goaziou  writes:
>>
>>> I really don't like the idea of making Org /syntax/ customizable, would it
>>> be with the help of a hook or a variable.
>>
>> From what I've seen so far, several users want regularity of syntax to
>> decide formatting, and several users want user preference to decide
>> formatting. There do seem to be larger costs for letting the user
>> decide; but there are also costs to not letting the user decide, that
>> I feel are not being appreciated.
>
> Could you please be more specific about what the problem is? Apart from
> the location of properties, are there other forms of flexible formatting
> that have been lost in recent releases? And what specifically is the
> problem with a required property drawer location? Is it aesthetic?
> Functional?
>

Please disregard this bit. Just saw your reply to Achim.

Matt

Re: [O] Allowing loose ordering in Org files

[Matt Lundin]

John Wiegley  writes:

>> Nicolas Goaziou  writes:
>
>> I really don't like the idea of making Org /syntax/ customizable, would it
>> be with the help of a hook or a variable.
>
> From what I've seen so far, several users want regularity of syntax to
> decide formatting, and several users want user preference to decide
> formatting. There do seem to be larger costs for letting the user
> decide; but there are also costs to not letting the user decide, that
> I feel are not being appreciated.

Could you please be more specific about what the problem is? Apart from
the location of properties, are there other forms of flexible formatting
that have been lost in recent releases? And what specifically is the
problem with a required property drawer location? Is it aesthetic?
Functional?

> The reason I'm sticking on this point is because it also relates to our future
> road map. If Org continues to do this -- to trade flexibility of formatting
> for regularity of parsing -- it might continue to alienate some of us.

I don't think this is a fair description of the direction org-mode has
been taking. I think org-mode has has unparalleled flexibility. If
anything, that flexibility has grown over the past few years. E.g., I
can enter any number of drawers, tables, lists, code blocks, links,
footnotes, etc. in a single entry. And I can export all of that data
reliable to a growing number of formats.

But when it comes to meta-data, I think it has been helpful to tighten
up the syntax. After all, org-mode has always required many types of
fixed formatting/syntax. For instance, one can't just put tags anywhere
in the body of an entry. Nor can one use arbitrary symbols to designate
headline levels. Nor can on put TODO keywords anywhere (despite frequent
requests for such functionality).

Since org-mode recognizes only one property drawer per entry, it makes
sense (for clarity, simplicity, efficiency, etc.) to require that this
special key:value metadata be "attached" to the headline (like tags,
TODOs, etc.).

Matt

Re: [O] Allowing loose ordering in Org files

[Achim Gratz]

John Wiegley writes:
> In my regimen, every single entry has a PROPERTIES drawer, since I tag each
> one with ID and CREATED, for future reference. Most items are SCHEDULED as
> well. So when I open up a headline to look at the contents, I see:
>
> * Head
> SCHEDULED
> text
> :PROPERTIES:...
>
> It's a trivial thing, but I'd rather not scan past two lines to start reading
> my entry.

So isn't your request rather to hide the properties drawer better by
default?  You were _only_ talking about the UX in this whole thread and
that might be a lot easier to adapt while not changing the way Org
syntax is defined.

There were lots of bugs to be fixed with properties and properties
inheritance and I dabbled in that endeavour, which makes me more
cautious about wading in and changing it yet again.  Knowing where to
find the properties quickly is key to this not falling apart again,
IMHO.  Even then, due to inheritance properties are probably the most
complex thing to wrap your head around in Org aside from Babel.

[…]
> I *care*, which is maybe both a blessing and a curse. It is the origin of my
> creative contributions, but also the cause of these annoying threads. I'd
> rather work with you guys than against you; but there are some sacred cows
> that moan plaintively, when a sharp parenthesis is drawn across their throats.

As I said above, the solution may well be different than both what you
want to keep and what Org offers now.  I don't find that thread
particularly annoying, btw.


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

Re: [O] filetags, noexport

[Nicolas Goaziou]

Hello,

Michael Welle  writes:

> I added '#+FILETAGS: noexport' (I tried :noexport: as well) to the top
> of an org file. The intention is that nothing from this file should get
> exported. But that doesn't work. An agenda query for the noexport tag
> finds all headlines of this file, so the tagging seems to work. What do
> I miss here?

Nothing. This is fixed in master. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] org-lint does not finish on some org-mode buffer

[Nicolas Goaziou]

Hello,

Karl Voit  writes:

> Independent to your resolved issue: on my Org-mode files with 30,000
> to 40,000 lines of Org-mode my computer took up to 12 hours to
> finish org-lint.
>
> Interesting fact: after finishing and saving the results, GNU/Emacs
> runs into an endless-loop when I try to exit Emacs.
>
> If this is of any interest, I can re-run org-lint over night and
> post the stack trace of C-g.

It is. C-g with `toggle-debug-on-quit' would be interesting. Also, you
could bisect your document to check if is really coming from its sheer
size or from particular structure in it.

Thank you.


Regards,

-- 
Nicolas Goaziou

Re: [O] Allowing loose ordering in Org files

[John Wiegley]

> Achim Gratz  writes:

> So isn't your request rather to hide the properties drawer better by
> default? You were _only_ talking about the UX in this whole thread and that
> might be a lot easier to adapt while not changing the way Org syntax is
> defined.

Good call, Achim! I became too focused on the problem, and missed the real
point.

> As I said above, the solution may well be different than both what you want
> to keep and what Org offers now. I don't find that thread particularly
> annoying, btw.

Thanks.

John

Re: [O] org export customization: why do #+EXCLUDE_TAGS: settings have no effect?

[Nicolas Goaziou]

Hello,

Martin Steffen  writes:

> Now: when I want to /customize/ that in the org-file itself, it seems that's
> done by doing something like
>
>
> #+EXCLUDE_TAGS: private

[...]

> Anyhow: having such a specification in the org-file seems to have /no
> effect/, even if I "refresh" the org-file, nor does it work when I visit the
> file for the first time. It seems simply not to affect the said variable
> "org-export-exclude-tags"

I cannot reproduce your issue. With the following buffer

  #+EXCLUDE_TAGS: private
  * H1 :private:
  * H2

I get

  1 H2
  

when I export to, e.g., UTF-8.


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] org-babel-execute-src-block-region

[Nicolas Goaziou]

Hello,

Carlos Henrique Machado S Esteves  writes:

> You are right, I've updated the patch.

Thank you. Some comments follow.

> * ob-core.el (org-babel-execute-src-block-region): Execute only active region 
> of
> the current source block.  Same as `org-babel-execute-src-block', but
> use only the active region instead of the whole block.

It should be:

* ob-core.el (org-babel-execute-src-block-region,
  org-babel-is-region-within-src-block): New functions.

Note that you may want to rename the latter
`org-babel--region-within-src-block-p' since it is an internal
predicate.

> +(defun org-babel-execute-src-block-region (beg end)
> +  "Execute region in the current source code block.
> +`org-babel-execure-src-block' is called; the only change is that
> +only the active region is sent, instead of the whole block."

You need to reference BEG and END arguments. It could be as simple as

  "BEG and END mark the limit of the region."

> +  (interactive "r")
> +  (if (org-babel-is-region-within-src-block beg end)
> +  (let ((info (org-babel-get-src-block-info)))
> + (setcar (nthcdr 1 info) (buffer-substring beg end))

Nitpick time:

  (setf (nth 1 info) (buffer-substring beg end))

is clearer, IMO.

> + (org-babel-execute-src-block nil info))
> +(message "Region not in src-block!")))

Isn't it a user error instead? In this case, please remove exclamation
mark the end of the message.

> +(defun org-babel-is-region-within-src-block (beg end)
> +  "Check if region is within a single src-block.

Non-nil if region is within the code part of a source block.

> +Block header and footer are ignored, so we are checking for the
> +source code only.
> +Used by `org-babel-execute-src-block-region' to check if region
> +is executable."
> +  (save-excursion
> +(eq
> + (progn
> +   (goto-char beg)
> +   (forward-line -1)
> +   (org-babel-where-is-src-block-head))
> + (progn
> +   (goto-char end)
> +   (forward-line 1)
> +   (org-babel-where-is-src-block-head)

I think the following is more efficient (untested, though)

  (org-with-wide-buffer
   (goto-char beg)
   (let ((case-fold-search t)
 (element (org-element-at-point)))
 (and (eq (org-element-type element) 'src-block)
  (> (line-beginning-position)
 (org-element-property :post-affiliated element))
  (> (progn (goto-char (org-element-property :end element))
(skip-chars-backward " \t\n")
(line-beginning-position))
 end

Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH 7/8] ox-taskjuggler.el: allow 'priority' to be a directly-specified integer

[Kosyrev Serge]

Aaron Ecay  writes:
> 2015ko azaroak 8an, Kosyrev Serge-ek idatzi zuen:
>> 
>> * ox-taskjuggler.el (org-taskjuggler--build-task):  fix priority 
>> specification
>> by allowing it to be directly passed down, in case it parses as an integer.
>> ---
>>  contrib/lisp/ox-taskjuggler.el | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>> 
>> diff --git a/contrib/lisp/ox-taskjuggler.el b/contrib/lisp/ox-taskjuggler.el
>> index 44ffeb6..d49db62 100644
>> --- a/contrib/lisp/ox-taskjuggler.el
>> +++ b/contrib/lisp/ox-taskjuggler.el
>> @@ -875,10 +875,16 @@ a unique id will be associated to it."
>> (org-taskjuggler-get-end task))
>>(org-element-property :PERIOD task)
>>   (priority
>> -  (let ((pri (org-element-property :priority task)))
>> +  (let ((pri (org-element-property :PRIORITY task)))
>>  (and pri
>> - (max 1 (/ (* 1000 (- org-lowest-priority pri))
>> -   (- org-lowest-priority 
>> org-highest-priority)))
>> +;; The exported task priority can be either specified
>> +;; via the Org priority mechahism (which is currently 
>> broken),
>
> Can you say more about what breakage you mean?  Is it something that can
> be easily fixed?

Perhaps I was unclear in this message -- it's not the Org's priority
mechanism that is broken, it's the way ox-taskjuggler uses it that is.

Org specifies priorities via a list of enums, whereas TJ expects an
integer in the range 0-1000.

The quoted little piece of math in ox-taskjuggler tried to provide a
mapping, but failed and I couldn't figure out how to make it work --
mainly because I couldn't understand how it was /supposed/ to work.

Hence I made a shortcut.

-- 
с уважениeм / respectfully,
Косырев Сергей

Re: [O] [PATCH] ox-extra.el: Fix filtering of latex header blocks

[Sebastian Christ]

> On Mon, 09 Nov 2015 01:30:23 -0500, Kyle Meyer  said:
  >> * ox-extra.el (org-latex-header-blocks-filter): Use `org-element' API to
  >> find begin and end of latex header blocks.
  Kyle> 
  Kyle> s|ox-extra.el|contrib/lisp/ox-extra.el|
  Kyle> s/begin/beginning/
  Kyle> 

Thanks. I'll change that.

  >> (mapc (lambda (pos)
  >> -(goto-char (nth 2 pos))
  >> -(destructuring-bind
  >> -(beg end  ignore)
  >> -(org-edit-src-find-region-and-lang)
  >> -  (let ((contents-lines (split-string
  >> - (buffer-substring-no-properties beg end)
  >> - "\n")))
  >> -(delete-region (nth 0 pos) (nth 1 pos))
  >> -(dolist (line contents-lines)
  >> -  (insert (concat "#+latex_header: "
  >> -  (replace-regexp-in-string "\\` *" "" line)
  >> -  "\n"))
  >> +  (let* ((beg (third pos))
  >> + (end (second pos))
  >> + (post-affiliated (first pos))
  Kyle> 
  Kyle> Hmm, the pos items are constructed as
  Kyle> 
  Kyle> (list (org-element-property :begin block)
  Kyle>   (org-element-property :end block)
  Kyle>   (org-element-property :post-affiliated block)))
  Kyle> 
  Kyle> so shouldn't beg be the first element and post-affiliated the third?

I thought it would be better to change as little as
possible. Rearranging the list is obviously the cleaner solution. I'll
change that.

Thanks for the review.

-Sebastian

Re: [O] [PATCH] ox-taskjuggler.el: allow direct 'depends' specification

[Kosyrev Serge]

Aaron Ecay  writes:
> Hi Kosyrev,
>> @@ -301,7 +301,7 @@ but before any resource and task declarations."
>>:type '(string :tag "Preamble"))
>>  
>>  (defcustom org-taskjuggler-valid-task-attributes
>
> Is this an open-ended list that an average user could meaningfully add
> to?  If not, perhaps it should be a defconst.  (I don’t know anything
> about the taskjuggler format, so I’m sure whatever decision you make
> will be OK.)

Generally speaking, TaskJuggler own "attributes" and "properties" are
very numerous.  Suffice to point to the documentation:

  http://taskjuggler.org/tj3/manual/

Org is only able to provide a very limited amount of those, and the
approach it takes is by white-listing the properties that ought to
"pass through" from Org to TJP files.

So, naturally, whenever one faces a limitation in ox-taskjuggler,
the desire to extend the list arises.

I'm not sure how this relates to an average user, to be honest,
and whether I've at all helped with your question..

How do we proceed?

-- 
с уважениeм / respectfully,
Косырев Сергей

Re: [O] [PATCH 7/8] ox-taskjuggler.el: allow 'priority' to be a directly-specified integer

[Aaron Ecay]

Hi Kosyrev,

2015ko azaroak 10an, Kosyrev Serge-ek idatzi zuen:
> Perhaps I was unclear in this message -- it's not the Org's priority
> mechanism that is broken, it's the way ox-taskjuggler uses it that is.
> 
> Org specifies priorities via a list of enums, whereas TJ expects an
> integer in the range 0-1000.
> 
> The quoted little piece of math in ox-taskjuggler tried to provide a
> mapping, but failed and I couldn't figure out how to make it work --
> mainly because I couldn't understand how it was /supposed/ to work.

Org priorities are expressed as single characters (conventionally
uppercase Latin letters).  These map to ASCII/Unicode code points
(i.e. integers).  The code interpolates these values linearly between
0 and 1000.  By default org has three priorities A, B, and C; these
map to 1000, 500, and 0 respectively.  Five priorities A through E
would map to 1000, 750, 500, 250, and 0.  Etc.

The letter/integer substitution is a bit opaque.  So is the fact that
org-lowest-priority (by default the ASCII codepoint for ‘C’ = 67) is a
larger integer than org-highest-priority (ASCII ‘A’ = 65), despite what
the names suggest.

Does that help any?

-- 
Aaron Ecay

Re: [O] Using orgstruct-mode (or just org-cycle) in emacs-lisp-mode

[Rasmus]

Hi Jonas,

Jonas Bernoulli  writes:

> Well currently I am just using `org-cycle' + `outline-minor-mode', which
> works well enough for now.  But eventually I would like to also start
> using Org's navigational commands.  Unfortunately `orgstruct-mode' only
> supports org-like headings (;; * heading\n;; ** subheadng) and not
> standard Emacs headings (;;; heading\n subheading).  I hope someone
> teaches `orgstruct-mode' to support the latter too.  Otherwise I will
> probably give `outshine' another chance.

My init file is structured like this, and I mainly use org-cycle as well.
Note that there’s an outstanding bug related to orgstruct and
org-show-children (as I remember).

 ;;* TEXT MODES
 ;;** AUCTeX
 ;;   ...
 ;;** Reftex
 ;;   ...
 ;;* PROG MODES
 ;;  ...
 ;;** Magit
 ;;...
 ;;...

 ;; Local Variables:
 ;; outline-regexp: ";;\\*+\\|\\`"
 ;; orgstruct-heading-prefix-regexp: ";;\\*+\\|\\`"
 ;; eval: (when after-init-time (orgstruct-mode) (org-global-cycle 3))
 ;; End:

Rasmus

-- 
Vote for Dick Taid in an election near you!

Re: [O] Allowing loose ordering in Org files (Was: bug in org-habits)

[Stelian Iancu]

On 10/11/15 02:40, Aaron Ecay wrote:


I think it’s more illuminating to think of it in terms of org as a tool:
have the changes made it more difficult for you to accomplish your goals
with org?  Has something that was previously possible become impossible?
Has something that was previously easy gotten harder?  If the answer to
one of these questions is yes, then we can think of ways to solve the
difficulties.


For me personally this change in particular has made me confused about 
the behavior in 8.3 versus 8.2. Since I don't have a huge backlog and 
workflow with org, I can adjust to this new way if I need to. However, 
like John, I would like the possibility of customizing this behavior 
somehow.


S.

Re: [O] org export customization: why do #+EXCLUDE_TAGS: settings have no effect?

[Martin Steffen]

Thanks,


For your small example (exporting to latex) I get

\begin{itemize}
\item H1 :private:
\item H2
\end{itemize}

(apart from the preamble etc).  What is also weird: If I add the
``standard'' vanilla template (via C-c C-e # beamer), then

- 1) some option settings like H:2  vs H:3 /are/ working.
- 2) variable org-export-headline-levels does not change


By "working" I mean: if I change the #+OPTIONS: H:2 to H:3, refresh the
emacs-buffer wrt. org's settings, and export the output (concretetely I
did beamer/latex). Now changing the section-level head /does change/ the
beamer-latex output the way I'd expect (i.e., it influences the
sectioning level).

What is strange though: the emacs-variable org-export-headline-levels
does not change when doing that, expect that I would have expected that
refreshing the buffer would do exactly that: update that variable and
thereby influencing the sectioning-levels:

-
org-export-headline-levels is a variable defined in `ox.el'.
Its value is 3
...
This option can also be set with the OPTIONS keyword,
e.g. "H:2".
-


I did not to comprehensive experiments which #+OPTIONS work or work
strangely, I just noticed that H:3 etc ``work'' (but I don't know why),
whereas the #EXCLUDE_TAGS do ``not work'' when refreshing the
buffer. For instance in that simple example you provided.

Martin





> "Nicolas" == Nicolas Goaziou  writes:

Nicolas> Hello,

Nicolas> Martin Steffen  writes:

>> Now: when I want to /customize/ that in the org-file itself, it
>> seems that's done by doing something like
>> 
>> 
>> #+EXCLUDE_TAGS: private

Nicolas> [...]

>> Anyhow: having such a specification in the org-file seems to have
>> /no effect/, even if I "refresh" the org-file, nor does it work
>> when I visit the file for the first time. It seems simply not to
>> affect the said variable "org-export-exclude-tags"

Nicolas> I cannot reproduce your issue. With the following buffer

Nicolas>   #+EXCLUDE_TAGS: private * H1 :private: * H2

Nicolas> I get

Nicolas>   1 H2 

Nicolas> when I export to, e.g., UTF-8.


Nicolas> Regards,

Nicolas> -- Nicolas Goaziou

Re: [O] [PATCH] ox-taskjuggler.el: allow direct 'depends' specification

[Aaron Ecay]

Hi Kosyrev,

2015ko azaroak 10an, Kosyrev Serge-ek idatzi zuen:
> 
> Generally speaking, TaskJuggler own "attributes" and "properties" are
> very numerous.  Suffice to point to the documentation:
> 
>   http://taskjuggler.org/tj3/manual/
> 
> Org is only able to provide a very limited amount of those, and the
> approach it takes is by white-listing the properties that ought to
> "pass through" from Org to TJP files.
> 
> So, naturally, whenever one faces a limitation in ox-taskjuggler,
> the desire to extend the list arises.
> 
> I'm not sure how this relates to an average user, to be honest,
> and whether I've at all helped with your question..
> 
> How do we proceed?

The difference between a defvar and a defcustom is whether the variable
shows up in M-x customize.  Customize often serves as the first port of
call for users discovering the features of a library.  So the question
is, will presenting users with such a list in the customize interface
empower them to have better taskjuggler export?  Or will it be too
intimidating?  It’s a subjective decision, I was just wondering whether
you had considered it.

Either way, it would be good to put the documentation link you gave into
the docstring, as a pointer to the allowed values of the variable.

Does that make sense?

-- 
Aaron Ecay

[O] Bug: bold text followed by footnote not bold

[Manuel Koell]

I just encountered following behaviour:

*foo bar*[fn:1] will export as *foo bar*1 (not bold, with stars)

*foo bar* [fn:2] will export as foo bar 1 (bold, but you've to use a space
between bold text and marker)

I may be wrong, but I thought a footnote marker will follow immediately
after the word ends. Both examples exported to html.

Re: [O] Spreadsheet error: invalid reference when using @> in range

[Nicolas Goaziou]

Hello,

Karl Voit  writes:

> | | 20 | 21 | 22 | 23 | 24 |
> | | :=vsum(@3..@>) |||||
> |-+++++|
> | ||||||
> |-+++++|
> | |  1 |  1 |||  1 |
> | Foo |  2 |||||
> | Bar |||  2 |  3 ||
> |-+++++|
> | ||||||
> |-+++++|
> | Bar ||  4 |  1 |||
> | Foo |||  2 ||  2 |
> | Bar |||  3 |  5 ||
> | Foo ||  1 |||  5 |
> |-+++++|
>
> I got: Spreadsheet error: invalid reference "vsum(@3..@>)" when I
> try to apply the formula.

I cannot reproduce the problem.
>
> Also tried and also failed with same message:
> vsum(@3$2..@>$2)
> vsum(@I$2..@>$2)
> vsum(@I+1$2..@>$2)

Same here.

> Bonus question: when I want to apply the formula to @2$2 and *all*
> table elements rights of it until the last column, is there a way to
> define this without having five separate formula?

  @2$2..@2$>=vsum(@3..@>)


Regards,

-- 
Nicolas Goaziou

Re: [O] [PATCH] org-babel-execute-src-block-region

[Xebar Saram]

Hi

I actually find it annoying in ESS to keep pressing C-c ' each time i want
to eval a single line of code in a code block. if this could work for R
code this would be fantastic for me

thx

Z

On Tue, Nov 10, 2015 at 8:19 PM, Carlos Henrique Machado S Esteves <
ch.machado.este...@gmail.com> wrote:

> Hello Chuck,
>
> Thank you for the feedback.
>
> > You might want to check that point and mark are both inside the src
> block. Otherwise, the results are unpredictable.
> You are right, I've updated the patch.
>
> > ess-mode, python-mode, sh-mode and octave-mode already provide this
> capability (and a lot more) for R, python, shell scripts, octave/matlab and
> some other languages from the edit buffer.
> I understand that. My idea is to avoid the need to C-c ' back and forth.
> Actually that's a problem I have with org-babel; I usually find myself
> coding inside the src block and losing many of the major mode
> functionalities; switching to the edit buffer often seem too much of a
> hassle. Any tips about how to get more major-mode functionalities inside
> the src-block? Or should I develop the muscle memory to switch back and
> forth to the edit buffer all the time?
>
> > `org-babel-demarcate-block' gives the user the ability to break up src
> blocks into smaller pieces so they can be run independently.
> Thanks for pointing that; I didn't know about `org-babel-demarcate-block'.
>
> Best,
>
> Carlos
>
> 2015-11-02 13:19 GMT-05:00 Charles C. Berry :
>
>> On Sun, 1 Nov 2015, Carlos Henrique Machado S Esteves wrote:
>>
>> Hello, I find it useful to be able to execute only a region of a source
>>> code block, so I've implemented a new function for that. I've tested it
>>> with MATLAB and Python, but it should work for any mode, since it calls
>>> org-babel-execute-src-block.
>>>
>>>
>> You might want to check that point and mark are both inside the src
>> block. Otherwise, the results are unpredictable.
>>
>> Also note that:
>>
>> ess-mode, python-mode, sh-mode and octave-mode already provide this
>> capability (and a lot more) for R, python, shell scripts, octave/matlab and
>> some other languages from the edit buffer.
>>
>> `org-babel-demarcate-block' gives the user the ability to break up src
>> blocks into smaller pieces so they can be run independently.
>>
>> Best,
>>
>> Chuck
>>
>>
>