[O] pcomplete error inside of headline asterisks when typing asterisk

2018-10-10 Thread stardiviner


When I create a new headline with =[Alt-Enter]= Under a headline. It looks like 
this:

#+begin_src org
,** headline 1
,** headline 2
#+end_src

Then I move point between two asterisks of headline 2. Then I type * again. It 
report
following error:

#+begin_example
Debugger entered--Lisp error: (args-out-of-range "" 1 nil)
  substring("" 1)
  (pcomplete--here (function (lambda nil (save-excursion (goto-char 
(point-min)) (let (tbl) (let ((case-fold-search nil)) (while (re-search-forward 
org-todo-line-regexp nil t) (setq tbl (cons (org-make-org-heading-search-string 
(match-string-no-properties 3)) tbl (pcomplete-uniquify-list tbl) 
(substring pcomplete-stub 1) nil nil)
  (while (pcomplete--here (function (lambda nil (save-excursion (goto-char 
(point-min)) (let (tbl) (let ((case-fold-search nil)) (while (re-search-forward 
org-todo-line-regexp nil t) (setq tbl (cons (org-make-org-heading-search-string 
(match-string-no-properties 3)) tbl (pcomplete-uniquify-list tbl) 
(substring pcomplete-stub 1) nil nil))
  pcomplete/org-mode/searchhead()
  pcomplete-completions()
  pcomplete-completions-at-point()
  completion--capf-wrapper(pcomplete-completions-at-point optimist)
  run-hook-wrapped(completion--capf-wrapper pcomplete-completions-at-point 
optimist)
  company--capf-data-real()
  company--capf-data()
  company-capf(prefix)
  apply(company-capf prefix)
  company-call-backend-raw(prefix)
  apply(company-call-backend-raw prefix)
  company--force-sync(company-call-backend-raw (prefix) company-capf)
  company-call-backend(prefix)
  company--begin-new()
  company--perform()
  company-auto-begin()
  company-idle-begin(# # 182 2857)
  apply(company-idle-begin (# # 182 
2857))
  timer-event-handler([t 23486 42991 304203 nil company-idle-begin (# # 182 2857) nil 151000])
#+end_example

-- 
[ stardiviner ] don't need to convince with trends.
   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  



Re: [O] Order of tangled blocks reversed?

2018-10-10 Thread Kaushal Modi
On Wed, Oct 10, 2018 at 6:05 PM Nicolas Goaziou  wrote:
> It is. Fixed. Thank you.

Awesome! Thank you!



Re: [O] Order of tangled blocks reversed?

2018-10-10 Thread Nicolas Goaziou
Hello,

Kaushal Modi  writes:

> I was playing with Org Tangle header-args inheritance and came up with
> this example:
>
> =
>
> #+property: header-args :tangle yes
>
> At Org level 0.
>
> * Heading 1
> :PROPERTIES:
> :header-args: :tangle foo.el
> :END:
> At Org level 1.
>
> #+name: block1
> #+begin_src emacs-lisp
>
> (message "this will be tangled to property_drawer2.el")
> #+end_src
> ** Heading 1.1
> :PROPERTIES:
> :header-args:emacs-lisp: :tangle no
> :END:
> At Org level 2.
>
> Only the emacs-lisp block will *not* be tangled from this subtree.
>
> #+name: block2
> #+begin_src emacs-lisp
>
> (message "this block will *not* be tangled")
> #+end_src
>
> But the below Nim block will tangle fine (though incorrectly to the
> foo.el file!).

It isn't incorrect. You specified "foo.el". Use ":tangle yes" if you
want to let Org decide about the extension.

> Though, the below /block3/ appears *above* /block1/ in
> the tangled file foo.el.
>
> #+name: block3
> #+begin_src nim
>
> echo "this block will be tangled to property_drawer2.nim"
> #+end_src
> =
>
> Tangling this (C-c C-v t) gives this foo.el file:
>
> =
> echo "this block will be tangled to property_drawer2.nim"
>
> (message "this will be tangled to property_drawer2.el")
> =
>
> Ignoring that Nim code gets inserted into the Emacs-Lisp file because
> of incorrect :tangle header-args under Heading 1, why is the block3
> code appearing above block1?
>
> Is this a bug?


It is. Fixed. Thank you.


Regards,

-- 
Nicolas Goaziou



Re: [O] exporting to latex and docx not honouring carriage returns to tabbing

2018-10-10 Thread Tim Cross


Eric S Fraga  writes:

> On Wednesday, 10 Oct 2018 at 08:31, Tim Cross wrote:
>
> [...]
[...]
>
>
> And I highly recommend the koma-script classes as opposed to the default 
> LaTeX ones.  For Sharon, the scrreprt class may be what you want.

Yes, koma-script has been my default as well for some time now. I also
use the hitec style, which seems to go down well with the 'tech' crowd.

Around 80% of the time, people look at my documents and are blown away
because of how good they look (content, unfortunately, can vary
significantly!). The only time things become problematic is when a
decision is made to work on a document collaboratively and they want to
use 'track changes'. At this point, I try to convince them to just work
in plain text or org files and I take on the responsibility of
incorporating their changes. This works OK provided they are able to
just work with the org file (either as an org file or as just plain
text) and not get caught up in formatting etc, in which case I can
extract their changes with diff. However, too often, they just don't get
it or cannot resist and insist on changing the formatting without
changing the content, so diffs become less useful.

Tim

-- 
Tim Cross



Re: [O] How to make agenda generation faster

2018-10-10 Thread Samuel Wales
for cleaning logbook entries, i'd enjoy having an agenda view that
shows every entry that has state changes [above a minimum number of
them to keep it small], with the size of the logbook drawer in the
prefix or so next to the category, sorted by that size.

there would be a corresponding agenda batch command that would
archive, delete, or archive all except most recent for the marked
entries.

is it the number of headlines in a file or the total number in agenda files?

i think it's great to have org-ql.  lispy query is great.  although
mostly i just use text search, it would be more memorizable syntax for
tags type search [and custom sorts?].  is this a suitable start for
agenda-ng?  will it be cleaner and faster?

another speedup possibility might be to allow redoing the agenda with
a new sorting strategy without having to redo the scanning of agenda
files.

i agree not scanning unchanged buffers could really speed up the
agenda in principle. [it'd be great if emacs could parallelize across
smp cores in addition.  :]]


On 10/10/18, Marcin Borkowski  wrote:
>
> On 2018-10-08, at 09:20, Michael Welle  wrote:
>
>> Hello,
>>
>> Marcin Borkowski  writes:
>>
>>> Hi Orgers,
>>>
>>> my agenda takes almost 10 seconds to show up.  Are there any ideas for
>>> profiling that?
>>>
>>> I suspect that archiving a lot of old entries I don't use anymore might
>>> help, but is there any way to e.g. display some stats on which
>>> file/headline took how much time?
>> since no one answered yet, there are some similar threads. IIRC the way
>> to go is to use elp for profiling.
>>
>> Well, on my laptop the initial agenda run takes about 7s or so (150
>> agenda files) using the current day/week agenda ("a"). All subsequent
>> (after loading the files) agenda runs are fast (split second I would
>> say). I had some performance issues in the past caused by SCM. Emacs
>> tried to check if every file is checked out in the latest version. That
>> slowed down the process a lot (starting 150 mercurial processes in
>> sequential order, checking results, etc.). The initial run doesn't
>> bother me much. I bound the initial agenda run to an idle timer at Emacs
>> start.
>
> Interesting.  I did not notice such differences between the first and
> subsequent runs.
>
> Anyway, thanks for your input (to all people who replied, actually).
>
> --
> Marcin Borkowski
> http://mbork.pl
>
>


-- 
The Kafka Pandemic: 

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

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



Re: [O] An Org-based productivity tool

2018-10-10 Thread Samuel Wales
auto-clocking might be interesting.

there would be a concept of a dominating clocking entry similar to
dominating file.  i.e. if where you are is not a clocking entry, go up
until you find one that is.  if you find none at top level, you create
a clock entry in the logbook there.

if you switch buffers or move around, you clock out and in where you
were and are.  every few minutes, you try to clock in where you are,
or the dominating clocking entry.  this is done with timers.  idle
time might go to a special clocking entry.

or something like that.  the idea is that you don't have to remember
to clock in and out.

On 10/10/18, Marcin Borkowski  wrote:
>
> On 2018-10-10, at 18:50, William Denton  wrote:
>
>> On 10 October 2018, Marcin Borkowski wrote:
>>
>>> I am making an Org-mode-based tool to help boost my productivity.
>>> ...
>>> - is anyone interested in something like this?
>>
>> I am---I'd love to see what you come up with.  I'm doing something
>> similar, but much less fancy, with clock tables and some R:
>>
>> https://www.miskatonic.org/2017/11/16/clocktableii/
>>
>> I need to do one more post about that to wrap it up.  It's working
>> well for me, but warnings about not being clocked in to something, and
>> better understanding of what I'm doing based on headings or tags,
>> would be useful.
>
> Thanks for your kind words!
>
> It's not that fancy (yet?), but has one big advantage over clock tables:
> it updates dynamically (using org-clock-out-hook), so it's fast.  Also,
> as you could see, it does some simple calculations.
>
> And for the record: it's based on properties, not tags - but that is
> a minor issue.
>
> Best,
>
> --
> Marcin Borkowski
> http://mbork.pl
>
>


-- 
The Kafka Pandemic: 

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

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



Re: [O] Org brings people together!

2018-10-10 Thread Eric Abrahamsen
John Hendy  writes:

[...]

> So far, Org-ers have been 100% awesome in person, and I look forward
> to running into more down the road. Anyway, just felt like a fun bit
> of news to share, and hopefully you all can nerd out about Org in
> person at some point too!

Somebody tell me if there's a Seattle meetup!

Eric




Re: [O] An Org-based productivity tool

2018-10-10 Thread Marcin Borkowski


On 2018-10-10, at 18:50, William Denton  wrote:

> On 10 October 2018, Marcin Borkowski wrote:
>
>> I am making an Org-mode-based tool to help boost my productivity.
>> ...
>> - is anyone interested in something like this?
>
> I am---I'd love to see what you come up with.  I'm doing something
> similar, but much less fancy, with clock tables and some R:
>
> https://www.miskatonic.org/2017/11/16/clocktableii/
>
> I need to do one more post about that to wrap it up.  It's working
> well for me, but warnings about not being clocked in to something, and
> better understanding of what I'm doing based on headings or tags,
> would be useful.

Thanks for your kind words!

It's not that fancy (yet?), but has one big advantage over clock tables:
it updates dynamically (using org-clock-out-hook), so it's fast.  Also,
as you could see, it does some simple calculations.

And for the record: it's based on properties, not tags - but that is
a minor issue.

Best,

-- 
Marcin Borkowski
http://mbork.pl



Re: [O] What is the difference between `org-narrow-to-subtree' and `org-narrow-to-element'?

2018-10-10 Thread Marcin Borkowski


On 2018-10-08, at 17:47, Marco Wahl  wrote:

> Hi!
>
>> I found these two commands.  They seem to do the same thing.  What is
>> the difference?
>
> This is an example illustrating the difference.
>
> - Have point on the *table* of the following subtree.
>
>
> --8<---cut here---start->8---
> * foo
>
> | foo | foo |
> | foo | foo |
>
> * bar
> --8<---cut here---end--->8---
>
>
> - Use command `org-narrow-to-subtree'.  See the effect.
> - Use command `widen' to get rid of the restriction.
> - Make sure to have point on the table of the subtree again.
> - Use command `org-narrow-to-element.  See the effect.
> - Compare!

Thanks, it did not occur to me that "element" may be something other
than a "subtree"!

Best,

-- 
Marcin Borkowski
http://mbork.pl



Re: [O] What is the difference between `org-narrow-to-subtree' and `org-narrow-to-element'?

2018-10-10 Thread Marcin Borkowski


On 2018-10-08, at 17:58, Eric S Fraga  wrote:

> On Monday,  8 Oct 2018 at 17:26, Marcin Borkowski wrote:
>> Hi all,
>>
>> I found these two commands.  They seem to do the same thing.  What is
>> the difference?
>
> These will only do the same thing if your element (where point is) happens to 
> be the sub-tree and nothing else.  Try it within a list element in a sub-tree 
> and you should notice a difference in behaviour.

Thanks, I didn't think about this!

-- 
Marcin Borkowski
http://mbork.pl



Re: [O] How to make agenda generation faster

2018-10-10 Thread Marcin Borkowski


On 2018-10-08, at 09:20, Michael Welle  wrote:

> Hello,
>
> Marcin Borkowski  writes:
>
>> Hi Orgers,
>>
>> my agenda takes almost 10 seconds to show up.  Are there any ideas for
>> profiling that?
>>
>> I suspect that archiving a lot of old entries I don't use anymore might
>> help, but is there any way to e.g. display some stats on which
>> file/headline took how much time?
> since no one answered yet, there are some similar threads. IIRC the way
> to go is to use elp for profiling.
>
> Well, on my laptop the initial agenda run takes about 7s or so (150
> agenda files) using the current day/week agenda ("a"). All subsequent
> (after loading the files) agenda runs are fast (split second I would
> say). I had some performance issues in the past caused by SCM. Emacs
> tried to check if every file is checked out in the latest version. That
> slowed down the process a lot (starting 150 mercurial processes in
> sequential order, checking results, etc.). The initial run doesn't
> bother me much. I bound the initial agenda run to an idle timer at Emacs
> start. 

Interesting.  I did not notice such differences between the first and
subsequent runs.

Anyway, thanks for your input (to all people who replied, actually).

-- 
Marcin Borkowski
http://mbork.pl



Re: [O] How to make agenda generation faster

2018-10-10 Thread Marcin Borkowski


On 2018-10-09, at 13:47, Julius Dittmar  wrote:

> Hi Marcin,
>
> I can't advise as to profiling to find out what really bogs down agenda
> building.
>
> I found that log messages do bog it down.
>
> I have a lot of recurring tasks, which accumulate log entries for every
> closing (which in fact means rescheduling to the next day). Every two to
> three months I prune my org files of those log entries. This
> significantly speeds up agenda building.

By experiments, I found that the main bottleneck was a file with lots (=
a few thousand) headlines.

Best,

-- 
Marcin Borkowski
http://mbork.pl



Re: [O] How to make agenda generation faster

2018-10-10 Thread Marcin Borkowski


On 2018-10-09, at 18:11, Nicolas Goaziou  wrote:

> Hello,
>
> Adam Porter  writes:
>
>> My feedback is: there be dragons.  ;)  The Agenda code is very
>> complicated and hard to follow, and it's hard to optimize something that
>> is hard to understand.
>
> And hard to maintain. We should really do something about it.
>
>> In the long run, to get significant speed improvements, I think it may
>> be necessary to reimplement the Agenda.
>
> Agreed.

+1

> [...]
>
> I didn't look closely at org-ql, but I had the idea of splitting the
> Agenda in two distinct parts. One would be responsible for collecting,
> possibly asynchronously, and caching data from Org documents. The other
> one would provide a DSL to query and display the results extracted from
> the output of the first part. The second part could even be made generic
> enough to be extracted from Org and become some part of Emacs.
> Displaying filtered data, maybe in a timeline, could be useful for other
> packages. Unfortunately, I don't have time to work on this. Ah well.
>
> So again, wouldn't it be nice to think about Org Agenda-ng?

That is a great idea!  In general, I find Org-mode to be lacking APIs.
I'dlove to build some applications on top of it, but getting some
information is very difficult.  (For instance, I'd like to get info
about clocks for all headlines in the agenda.  It seems I have to
implement parsing clocks myself, at least partially.)

Best,

-- 
Marcin Borkowski
http://mbork.pl



Re: [O] How to make agenda generation faster

2018-10-10 Thread Marcin Borkowski


On 2018-10-09, at 08:37, Adam Porter  wrote:

> Hi Marcin,
>
> [...]
>
> If you haven't seen them already, you may find my org-ql and
> org-ql-agenda code useful.  org-ql-agenda presents an Agenda-like
> buffer.  N.B. It does *not* implement most of the Agenda features, but
> it does emulate an Org Agenda buffer by setting the appropriate text
> properties on entries and formatting them in a similar way.
>
> It's built on org-ql, which provides per-buffer query caching, which
> means that generating an org-ql-agenda view for Org buffers that haven't
> changed since the last view was generated is very fast.  It's also
> written in a more functional way, which I think is easier to follow and
> modify.  Performance of uncached queries/buffers depends on the
> query--some are relatively fast, while others are slower than the "real"
> Org Agenda.  I think there is significant potential for optimizations,
> and I'm hoping to implement some in the future.  Your feedback would be
> appreciated!
>
> https://github.com/alphapapa/org-ql

Thanks, I'll check those out!

Best,

-- 
Marcin Borkowski
http://mbork.pl



Re: [O] Org brings people together!

2018-10-10 Thread John Kitchin
Thanks for making it happen John! I had a great visit, and hope to see some
org-mode adoption in a company environment. That would be amazing!

John

---
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Tue, Oct 9, 2018 at 11:24 PM John Hendy  wrote:

> Hi all,
>
>
> Just wanted to celebrate the fact that 3M (where I work [1]) was able
> to host Prof. John Kitchen last week to give two talks: one on his
> work in catalysis, touching on modeling molecular interactions, and a
> second one about reproducible research with Org-mode.
>
> At 3M we have chapters, which I describe like college clubs, but
> organized around different technology topics. These are volunteer
> groups responsible for some ~450 events per year at 3M Center in St.
> Paul, MN. The events are things like internal product/technology
> talks, vendor presentations, poster sessions, and hosting professors.
>
> When I saw John's mention scimax [2] maybe a year ago and realized he
> works in an area where we have such a chapter (catalysis), as well as
> works with Org-mode (relevant to our software chapter), I started
> scheming and pitched that we invite him. Fast forward a few back and
> forths about timing later, followed by a sabbatical at Google, and
> revisiting the idea... and it finally happened!
>
> Sadly, I missed the Org talk (CTO was presenting at the same time),
> but I did go to the first and was able to join him for dinner. I admit
> that the others at dinner were not quite as programm-y as we were, and
> might have been playing along laughing we got into the inevitable vim
> vs. emacs jokes. We were quite amused, though.
>
> John will be the second person I've met on the user list. I met Erik
> Iverson, a long-time user, back in 2011. Turns out he was running the
> Twin Cities R User Group here and we ended up co-organizing together
> for a couple years.
>
> So far, Org-ers have been 100% awesome in person, and I look forward
> to running into more down the road. Anyway, just felt like a fun bit
> of news to share, and hopefully you all can nerd out about Org in
> person at some point too!
>
> It was great to meet you John, great work, great talk, and I look
> forward to digging into scimax more soon!
>
>
> Best regards,
> John
>
> [1] If 3M isn't immediately recognizable, you might know it for some
> of it's bigger brands/products like Scotch Tape, Command Strips,
> Post-It Notes, Filtrete filters, and Scotch-Brite.
>
> [2] https://github.com/jkitchin/scimax
>
>


Re: [O] An Org-based productivity tool

2018-10-10 Thread William Denton

On 10 October 2018, Marcin Borkowski wrote:


I am making an Org-mode-based tool to help boost my productivity.
...
- is anyone interested in something like this?


I am---I'd love to see what you come up with.  I'm doing something similar, but 
much less fancy, with clock tables and some R:


https://www.miskatonic.org/2017/11/16/clocktableii/

I need to do one more post about that to wrap it up.  It's working well for me, 
but warnings about not being clocked in to something, and better understanding 
of what I'm doing based on headings or tags, would be useful.


Bill
--
William Denton :: Toronto, Canada   ---   Listening to Art: 
https://listeningtoart.org/
https://www.miskatonic.org/ ---   GHG.EARTH: http://ghg.earth/
Caveat lector.  ---   STAPLR: http://staplr.org/



[O] An Org-based productivity tool

2018-10-10 Thread Marcin Borkowski
Hi Orgers,

I am making an Org-mode-based tool to help boost my productivity.

I am constantly fighting a losing battle with distractions.  I figured
out that showing me how much time I spent goofing around would help me
stay on track (being a math geek and a gamer, my "let's break my
yesterday's score" and similar instincts kick in immediately, too).  So
far, I have these in my prototype:

- a notification (recurring every n seconds) that I'm not clocking
  anything,

- some stats about what I spent my time on and what my efficiency (i.e.,
  percentage of time I spent working from the point when I started
  counting to now) is,

- info about how much work I need to do in order to meet my set goal,
  and how much will it take if my efficiency remains constant,

- a warning when my efficiency is lower than a set value, and info about
  how much work I need to do to bump it up to that value.

Here's an example output (with some partially faked data):

--8<---cut here---start->8---
39min of your workday (10%) has passed, and you have 5h 31min left.

work - 30min spent (12% of your goal of 4h and 75% of your workday so far)
   3h 30min remaining (4h 39min with your current efficiency of 75%).
   You need 9min of uninterrupted work to get back to 80% efficiency.

eating - 4min spent (10% of your workday so far)

bathroom - 2min spent (5% of your workday so far)

unclassified - 0min spent (0% of your workday so far)

Unclocked time so far: 3min.
--8<---cut here---end--->8---

My questions are:

- is anyone interested in something like this?

- are there any features you would like to have?  (I have some ideas,
  too.)

- does anyone have an idea of how to /name/ this project?

TIA,

--
Marcin Borkowski
http://mbork.pl



Re: [O] exporting to latex and docx not honouring carriage returns to tabbing

2018-10-10 Thread Eric S Fraga
On Wednesday, 10 Oct 2018 at 08:31, Tim Cross wrote:

[...]

> One of the most common mistakes I see when people start using latex as
> the basis for document generation is ad hoc tweaking of the
> style. This is an unfortunate consequence of most of us being exposed
> to traditional word processors such as MS Word or Libre Office.

I agree with everything you said in your post.  

The first thing I tell my students when they start working in my group (i.e., 
after telling them that I expect all writing to be done in LaTeX...) is "to go 
with the flow" and not try to fight the system.  LaTeX know better than them 
what is a good layout for text.  Their concern should be the content.

Most listen but there's always one that insists that they have a better idea of 
what looks good... and you can imagine the result. ;-)

So, yes, my advice as well is to find a LaTeX document class that does what you 
want and go with it.  Minor tweaks are of course always possible but anything 
else should be avoided except for very special cases.  YMMV, of course.

And I highly recommend the koma-script classes as opposed to the default LaTeX 
ones.  For Sharon, the scrreprt class may be what you want.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.1.11-620-ga548e4



Re: [O] [PATCH] org: Support creating arbitrary headline paths when refiling

2018-10-10 Thread Sebastian Reuße

Hello Nicolas,

Nicolas Goaziou  writes:


Compiling your patch generates the following warnings.

org.el:11417:1:Warning: Unused lexical variable ‘parent’
org.el:11417:1:Warning: Unused lexical variable ‘child’
org.el:11417:1:Warning: Unused lexical variable 
‘parent-target’


Good catch, thanks. I forgot to remove these let-bindings when 
factoring the respective ‘org-refile’ branch into a separate 
function. I amended the commit correspondingly.


Also, I couldn't test it because completing asks for a mandatory 
match
among candidates. Such a match is not possible if you need to 
create

a path out of the blue. Am I missing something?


Do you have ‘org-refile-allow-creating-parent-nodes’ set to an 
appropriate value? When non-nil, ‘org-refile’ should invoke the 
completing read function without requiring a full match.


Kind regards,

SR

--
Insane cobra split the wood
Trader of the lowland breed
Call a jittney, drive away
In the slipstream we will stay



[O] [PATCH] org: Support creating arbitrary headline paths when refiling

2018-10-10 Thread Sebastian Reuße
* org.el (org--refile-new-path): Add.
(org-refile): Use it.
(org-refile-new-child): Make new nodes more compact.

* test-org.el (test-org/org-refile): Add test.

While ‘org-refile’ currently supports creating new headlines when
refiling, only one single headline can be created this way. For
convenience, we now generalize this use-case to support creating
arbitrary headline paths on the fly.
---
 lisp/org.el  | 37 +--
 testing/lisp/test-org.el | 42 
 2 files changed, 65 insertions(+), 14 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index e3866c2c0..b81a58e4e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11450,7 +11450,7 @@ (defun org-refile-get-location ( prompt 
default-buffer new-nodes)
  (concat " (default " (car org-refile-history) 
")"))
 (and (assoc cbnex tbl) (setq cdef cbnex)
  (concat " (default " cbnex ")"))) ": "))
-pa answ parent-target child parent old-hist)
+pa answ old-hist)
 (setq old-hist org-refile-history)
 (setq answ (funcall cfunc prompt tbl nil (not new-nodes)
nil 'org-refile-history (or cdef (car 
org-refile-history
@@ -11467,17 +11467,12 @@ (defun org-refile-get-location ( prompt 
default-buffer new-nodes)
(when (equal (car org-refile-history) (nth 1 org-refile-history))
  (pop org-refile-history)))
  pa)
-  (if (string-match "\\`\\(.*\\)/\\([^/]+\\)\\'" answ)
- (progn
-   (setq parent (match-string 1 answ)
- child (match-string 2 answ))
-   (setq parent-target (org-refile--get-location parent tbl))
-   (when (and parent-target
-  (or (eq new-nodes t)
-  (and (eq new-nodes 'confirm)
-   (y-or-n-p (format "Create new node \"%s\"? "
- child)
- (org-refile-new-child parent-target child)))
+  (if (and (string-match "\\`\\(.*\\)/\\([^/]+\\)\\'" answ)
+  (or (eq new-nodes t)
+  (and (eq new-nodes 'confirm)
+   (y-or-n-p (format "Create new path \"%s\"? "
+ answ)
+ (org--refile-new-path answ tbl)
(user-error "Invalid target location")
 
 (declare-function org-string-nw-p "org-macs" (s))
@@ -11501,6 +11496,20 @@ (defun org-refile-check-position (refile-pointer)
   (unless (looking-at-p re)
 (user-error "Invalid refile position, please clear the cache with 
`C-0 C-c C-w' before refiling"
 
+(defun org--refile-new-path (path tbl)
+  "Ensure that all parent nodes leading to refile target PATH exist.
+
+Use TBL as a look-up table for existing nodes.
+
+Return the corresponding refile location."
+  (let ((target (org-refile--get-location path tbl)))
+(if (and (not target)
+(string-match "\\`\\(.*\\)/\\([^/]+\\)\\'" path))
+   (let ((child (match-string 2 path))
+ (parent (org--refile-new-path (match-string 1 path) tbl)))
+ (org-refile-new-child parent child))
+  target)))
+
 (defun org-refile-new-child (parent-target child)
   "Use refile target PARENT-TARGET to add new CHILD below it."
   (unless parent-target
@@ -11519,8 +11528,8 @@ (defun org-refile-new-child (parent-target child)
 (setq level (funcall outline-level))
 (org-end-of-subtree t t))
(org-back-over-empty-lines)
-   (insert "\n" (make-string
-(if pos (org-get-valid-level level 1) 1) ?*)
+   (insert (make-string
+   (if pos (org-get-valid-level level 1) 1) ?*)
   " " child "\n")
(beginning-of-line 0)
(list (concat (car parent-target) "/" child) file "" (point))
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 3f5aa09e4..93ca2bc90 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -5789,6 +5789,48 @@
(org-refile-targets `((nil :level . 1
(member (buffer-name) (mapcar #'car (org-refile-get-targets)))
 
+(ert-deftest test-org/org-refile ()
+  "Test `org-refile' specifications."
+  ;; Create new parent nodes via `org--refile-new-path'.
+  (let* ((low-calorie-buffer "* Cake
+** Topping
+*** Rainbow chocolates
+*** Pistachio icing
+** Filling
+*** Banana ice cream
+*** Cookie dough
+*** Crispy crunch
+* Extra Ingredients
+** Marshmallows
+")
+(low-calorie-buffer-target "* Cake
+** Topping
+*** Rainbow chocolates
+*** Pistachio icing
+** Filling
+*** Banana ice cream
+*** Cookie dough
+*** Crispy crunch
+** Bottom
+*** Base
+ Marshmallows
+* Extra Ingredients
+")
+(cursor-after "Marshmallows")
+(refile-target "Cake/Bottom/Base")
+(org-refile-use-outline-path t)
+(org-refile-targets nil)
+

Re: [O] [PATCH] org: Support creating arbitrary headline paths when refiling

2018-10-10 Thread Nicolas Goaziou
Hello,

Sebastian Reuße  writes:

> * org.el (org--refile-new-path): Add.
> (org-refile): Use it.
> (org-refile-new-child): Make new nodes more compact.
>
> * test-org.el (test-org/org-refile): Add test.
>
> While ‘org-refile’ currently supports creating new headlines when
> refiling, only one single headline can be created this way. For
> convenience, we now generalize this use-case to support creating
> arbitrary headline paths on the fly.

Compiling your patch generates the following warnings.

org.el:11417:1:Warning: Unused lexical variable ‘parent’
org.el:11417:1:Warning: Unused lexical variable ‘child’
org.el:11417:1:Warning: Unused lexical variable ‘parent-target’

Also, I couldn't test it because completing asks for a mandatory match
among candidates. Such a match is not possible if you need to create
a path out of the blue. Am I missing something?

Regards,

-- 
Nicolas Goaziou