Re: [O] capture template and writeroom mode ?

[Jean-Christophe Helary]

Thank you Bsstien.

> On Jul 3, 2017, at 12:46, Bastien  wrote:
> 
>> What would be the best way to have writeroom mode called in one
>> given capture template and not the others ?
> 
> I would you a (file+)function to get the location:
> 
>`(file+function "path/to/file" function-finding-location)'
>  A function to find the right location in the file.
> 
>`(function function-finding-location)'
>  Most general way: write your own function which both visits
>  the file and moves point to the right location.
> 
> then tell the function to use writeroom-mode.

I'm already using the file+datetree target so I guess that's not possible, 
unless I define a function that triggers the writeroom mode *and* adds the 
datetree...

 ("j" "Journal" entry (file+datetree "~/org/journal.org")   
  
   "* %^{Titre} [%<%H:%M>]\n%?\n") ;;; :clock-in t :clock-resume t) 
   

Jean-Christophe 

Re: [O] org babel, ess, R

[Charles C. Berry]

On Tue, 4 Jul 2017, Vikas Rawal wrote:




On 04-Jul-2017, at 1:22 AM, John Hendy  wrote:

On Sun, Jul 2, 2017 at 7:17 PM, Vikas Rawal
 wrote:


Vikas Rawal  writes:


Isn’t is what most users need while editing the code block? The
possibility of evaluating the code to test and see what happens?


Often, but not always.  And it would be seriously annoying to have the 
session buffer pop up every time I wanted to browse the code in a src 
block while simultaneously viewing the results of a previous invocation 
in the org buffer.


As noted by others C-RET (or C-c C-n) on an empty line will make the 
session buffer visible.


So will C-c C-z C-c C-z if you are in an ESS[S] mode buffer (and it will 
do that without trying to eval anything).


There are any number of possibilities for customizing =org-edit-src-code= 
to your liking. For example, with this code C-c M-' will display the edit 
buffer and the session buffer as desired by Vikas:


#+BEGIN_SRC emacs-lisp
  (defun my-babel-edit-src ( code edit-buffer)
(interactive)
(org-edit-src-code code edit-buffer)
 (when (string= mode-name "ESS[S]")
   (let ((cb (current-buffer)))
 (ess-switch-to-ESS t)
 (switch-to-buffer-other-window cb
  (define-key org-mode-map (kbd "\C-c\M-'") 'my-babel-edit-src)
#+END_SRC

There are loads of possibilities. Just hack away at that function to add 
stops and whistles.


Personally, I find that the code in this thread:

From: Andrew Kirkpatrick 
Subject: Jumping between source blocks in a file
Archived-At: 

has done a lot to ease my browsing and manipulation of src blocks even 
though it displays the org buffer along with the edit buffer --- requiring 
me to key in C-c C-z C-c C-z to get the process buffer back in view.  I 
suppose I could replace =org-edit-src-code= at the end of Andrew 
Kirkpatrick's =my-babel-src-jump= with =my-babel-src-code= to fix that. 
Maybe tomorrow...


Best,

Chuck

Re: [O] Upstream synchronization documentation

[Neil Jerram]

No problem to stick with 'backport' if that is the conventional term here. 
Thanks for considering and explaining the point. 

     Neil 


  Original Message  
From: Rasmus Pank Roulund
Sent: Monday, 3 July 2017 18:22
To: k...@kyleam.com
Cc: n...@ossau.homelinux.net; emacs-orgmode@gnu.org
Subject: Re: [O] Upstream synchronization documentation

Kyle Meyer  writes:

>> Whereas in your text I think it is the other way round, isn't it?
>> (I.e. the Emacs branch is more stable, and you are talking about
>> porting a fix that someone has made in that branch to the Org master.)
>> So perhaps 'forward port' would be clearer?
>
> I suspect that Org's maint (where the Emacs changes land) is generally
> more stable than the Org in Emacs's master, but, yes, Emacs's version is
> the older version. (Well, with v9.0.9 just synced the versions match,
> but maint still has quite a few more commits.)
>
> Since before I took over "backporting" changes from the Emacs repo, it's
> been referred to as this. Although I agree it isn't great word choice,
> I'd prefer that we remain consistent so that, for example, "git log -i
> --grep=backport" remains informative.
>
> But if people think using "backport" is too confusing, I'm OK switching
> to another term. Of "forward port" and "propagate" (suggested in this
> thread by Eric), I prefer "propagate"---or maybe just "port", though
> grepping for that might lead to too many false positives. And if we
> stick with "backport", it still might be a good idea to clarify in
> README_maintainer that we're abusing the term.

So at least I’m not crazy for "coming up with" it backporting!

So I will keep calling it "backporting" but explain that it is more like
propagating changes from the Emacs repository (back) to the Org
repository.

Thanks,
Rasmus

-- 
Dung makes an excellent fertilizer

Re: [O] org babel, ess, R

[Vikas Rawal]

> On 04-Jul-2017, at 1:22 AM, John Hendy  wrote:
> 
> On Sun, Jul 2, 2017 at 7:17 PM, Vikas Rawal
>  wrote:
>>> 
>>> Vikas Rawal  writes:
>>> 
 Isn’t is what most users need while editing the code block? The
 possibility of evaluating the code to test and see what happens?
>>> 
>>> 
>>> Many languages do not support sessions. So, the only possibility to
>>> evaluate the code is to evaluate the code block in the source buffer.
>>> 
>> 
>> Yes, what I am talking about is relevant only when a session is defined. 
>> What I would like is that if in a file the session is defined, C-c’ creates
>> a window configuration that shows the edit buffer and the session. In other 
>> cases, the two windows could show the edit buffer and the original org 
>> buffer.
> 
> As a frequent R user, I completely relate to this. As soon as one
> evaluates code in the session buffer (C-c ') with C-RET, this is the
> setup you get.
> 

Oh! C-RET: I didn’t know this. And this itself is a big help. It is so much 
easier than having to change the buffer manually!

> I'd add to your wish that upon first visiting a file, if I go into
> edit mode, I'd like Org to pick up the fact that there's a :session
> argument with a custom name and use that for C-RET in the edit buffer;

C-RET seems to be picking up the custom session name if it is already there. 
But otherwise it generates the default *R* session there,

This should surely be fixed.
> 
> Anyway, it's easy enough to run one line with C-RET once editing and
> get the session buffer, but just getting it right away is also what I
> would prefer.
> 

I agree and echo.

Thanks a ton for C-RET :)

Vikas

Re: [O] Bug: Org loses data if the user types C-u C-c C-c while composing a state change note [9.0.9 (9.0.9-elpaplus @ /home/jorge/.emacs.d/elpa/org-plus-contrib-20170622/)]

[Nicolas Goaziou]

Hello,

Kyle Meyer  writes:

> On maint, can this issue be solved by just removing the prefix argument
> check from org-store-log-note?  AFAICS, the prefix argument behavior
> isn't documented anywhere, and the same behavior is already available
> through org-kill-note-or-show-branches (C-c C-k).

Done. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Clock table reports wrong data [9.0.9]

[Nicolas Goaziou]

Hello,

"Pierre-Henry F."  writes:

> Hello! Given: ** test
>
> #+BEGIN: clocktable :maxlevel 3 :scope subtree :block 2017-07-03
> #+CAPTION: Clock summary at [2017-07-03 Mon 19:30], for Monday, July 03, 2017.
>
> | Headline | Time | |
> |--++--|
> | *Total time* | *1:55* | |
> |--++--|
> | \_ test | | 1:55 |
> #+END:
> :LOGBOOK:
> CLOCK: [2017-07-02 Sun 20:40]--[2017-07-02 Sun 23:55] => 3:15
> :END:
> If I move the cursor to the "#+BEGIN:" line then "C-c", the table
> reports wrong data. Since ":block 2017-07-03" and "CLOCK: [2017-07-02
> Sun 20:40]--[2017-07-02 Sun 23:55] => 3:15" then the "*Total time*"
> should be: "0" but it is "*1:55*".

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] org mode moves to GNU emacs core

[Tim Cross]

Uwe Brauer writes:

 "qTim" == qTim Cross  writes:
>
>> Just to throw my 2 cents in.
>
>> 1. Problems with mixed versions. Currently, Emacs has org 8.x included
>> in the distribution. This is despite 9.x being out before the release of
>> 25.2. Something needs to be done to improve coordination and perhaps if
>> it was part of the core, this would be more likely. At any rate, the
>> current situation means you need to be very careful to ensure no org
>> feature is loaded before the ELPA package is loaded or you will get odd
>> behaviour and the symbol's value is void errors.
>
>> 2. If you just want to load the ELPA version of org (not
>> org-plus-contrib) it can be a real pain. You have to play around with
>> package lists to ensure you actually get the right one. This can be a
>> real hassle if you also use the use-package package as you will often
>> get the older version bundled with Emacs if you don't have your package
>> lists in the right order.
>
>> 3. I would really like to see two completely separate packages rather
>> than having org and org-plus-contrib. Currently, if you have packages
>> which have org as a dependency and you have loaded org-plus-contrib
>> rather than just org, you will end up with both. Not a big issue, unless
>> your on a slow link as now you will download updates for both org and
>> org-plus-contrib. (there is no 'cleverness' with ELPA dependency
>> specifications - you cannot specify alternative dependencies).
>
> But this critics could be applied to any emacs package and therefore to
> the package system itself.
>
Yes. It is a weakness of the package system not org. However, while I
have quite a few packages installed, org is the only one where I have
two versions installed at once.

>> A lot will depend on when org becomes part f core. The trick will be to
>> do it once development of org slows down. I've been using org for a long
>> time now and have noticed that the rate of new features being added has
>> slowed down. Much of the changes now is about improvement and refinement
>> of the code base. I would imagine that at some point, things will become
>> even more stable with fewer releases. This would be the point at which
>> it would make sense to bring into core.
>
>> The other advantage of being part of core is that updates and changes to
>> Emacs will be integrated into org much better. We won't see situations
>> where new versions of Emacs require a rush to update org. for the end
>> user, this should create a much more stable org environment.
>
> Well I update GNU emacs every 6 months it is not difficult but needs
> considerable longer to compile and install than org mode.
>

I use to do that - actually, probably even more frequently. I still run
from my own build rather than distribution versions because they are
even further behind (generally). However, these days, I just run the
most recent Emacs release i.e. now 25.2

>> Then of course, there will always be the option to run org straight from
>> the git repository for those who really want the latest version. I find
>> that once you have the path added to load-path, running from the git
>> repo is not much more effort than installing the latest ELPA package.
>
> I don't see how that would possible once it is integrated in GNU emacs
> core, there will be no separate makefile or anything of that sort, but
> maybe I am missing something.
>

There is going to have to be a way for people to maintain and build org
independently. When you are maintaining Emacs, you don't want to have to
re-build the whole system every time you create a change. What you tend
to find is there are multiple Makefiles with a top level Emacs makefile
which calls sub-level makefiles as part of the build. It may be
necessary to modify configure or add a new option to build outside the
emacs tree, but that shouldn't be too difficult.

I should emphasise that while I agree org would be good as part of
Emacs' core, I don't think this should occur until org change velocity
has stabilised to a point where change velocity is lower than it is
now. At that point, there will be much less need to be running the most
recent snapshot.

Maybe my experience is very different. However, I found a lot more
motivation to go from org 7.x to 8.x than I did from 8.x to 9.x. In
fact, the only visible changes in 9.x I've had to deal with have been
about compatibility changes and minor bugs I've had to update
for/fix. I could still be running 8.x. The only reason I've updated to
9.x is to avoid issues with some of the contrib packages that have/may
have been updated to work with 9.x

The other point to keep in mind is that this change won't happen
quickly. It will take some time before this can occur and we probably
need to start thinking/talking about it now so that when the right time

Re: [O] exporting org-mode to latex gives unwanted \label on all sections

[Sharon Kimble]

Nicolas Goaziou  writes:

> Hello,
>
> Sharon Kimble  writes:
>
>> I have an org-mode document that I'm exporting to latex which works
>> pretty well. But, there is one problem - for every title in all of the
>> sections, org-mode export has put a label on even where I have none in
>> my source file!
>
> It doesn't hurt, does it? Org uses them to resolve internal references.
>
> If you really need to, I guess you can write an headline filter so as to
> remove them.
>
Thanks for replying Nicolas.

Its not a major problem but its annoying when I've manually cleared all
extraneous references put in by me accidentally, and then discover that
org-mode is placing them during exporting. Because they don't appear in
my org-mode document I'm unaware of them and can therefore not utilise
them in new cross-references. They only appear in the generated latex
file and not in the org-mode source document.

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk  
Debian 9.0, fluxbox 1.3.5-2, emacs 25.1.1, org-mode 9.0.7


signature.asc
Description: PGP signature

Re: [O] org babel, ess, R

[John Hendy]

On Sun, Jul 2, 2017 at 7:17 PM, Vikas Rawal
 wrote:
>>
>> Vikas Rawal  writes:
>>
>>> Isn’t is what most users need while editing the code block? The
>>> possibility of evaluating the code to test and see what happens?
>>
>>
>> Many languages do not support sessions. So, the only possibility to
>> evaluate the code is to evaluate the code block in the source buffer.
>>
>
> Yes, what I am talking about is relevant only when a session is defined. What 
> I would like is that if in a file the session is defined, C-c’ creates
> a window configuration that shows the edit buffer and the session. In other 
> cases, the two windows could show the edit buffer and the original org buffer.

As a frequent R user, I completely relate to this. As soon as one
evaluates code in the session buffer (C-c ') with C-RET, this is the
setup you get.

I'd add to your wish that upon first visiting a file, if I go into
edit mode, I'd like Org to pick up the fact that there's a :session
argument with a custom name and use that for C-RET in the edit buffer;
otherwise it generates the default *R* session there, but if you C-c
C-c the block later it puts it into the custom session name. Perhaps
out of habit, I tend to use :session r for every block that needs to
share results. I'll make some progress, close shop for the day, and to
continue where I left off I need to be sure to C-c C-c something the
next time rather than jumping right to editing. If I forget, end up
with two buffers and I get asked where I want to evaluate every
subsequent bit of code.

Anyway, it's easy enough to run one line with C-RET once editing and
get the session buffer, but just getting it right away is also what I
would prefer.

For other languages, even though one can't evaluate in the edit
buffer, I still use this view more frequently because I get
auto-indenting vs. none (e.g. with python).


John

>
>
> Vikas

Re: [O] org mode moves to GNU emacs core

[Adonay Felipe Nogueira]

Indeed I admit that I might have exagerated when I called it
"average". Please excuse my wrong doing. :)

Re: [O] Upstream synchronization documentation

[Kyle Meyer]

Rasmus  writes:

> The documentation in README_maintainer is a bit outdated
> wrt. synchronizing with upstream Emacs.

Thanks for taking the time to update this.

> +** Backporting changes from upstream Emacs
> +To check for backports from the Emacs upstream repository, one can use
> +the following =git= command, cutesy of 
> [[http://permalink.gmane.org/gmane.emacs.devel/215861][Kyle Meyer]],
^courtesy
> +
> +: git log $rev..origin/emacs-25 -- lisp/org doc/misc/org.texi 
> etc/refcards/orgcard.tex

This pathspec will catch nearly all the changes that should be
considered for backporting.  In the process of this sync, I realized
that the check should include a few more files for completeness.  I now
add etc/ORG-NEWS and etc/org to the pathspec above.  On top of that, the
latest sync introduces od-manifest-schema-v1.2-os.rnc and
od-schema-v1.2-os.rnc to Emacs's etc/schema directory, so I've added
those too.

Anyway, that's just for the record.  Together these files should be the
source of very few backports, but I think they're worth monitoring to be
to make sure we don't need to deal with any changes on the Emacs-side.
I'm not sure if you want to document the extended and unwieldy pathspec
here, but it would be

  -- lisp/org doc/misc/org.texi etc/refcards/orgcard.tex etc/ORG-NEWS etc/org \
  etc/schema/od-manifest-schema-v1.2-os.rnc etc/schema/od-schema-v1.2-os.rnc

> +where =$rev= is the last commit from the =emacs-25= branch that was
> +backported.  The same should be done for the =master= branch.

[...]

> +- =org.texi= :: Copy to =emacs/doc/misc=.  It may be necessary to replace,
> + ~@include org-version.inc~ #+end_src with ~@set VERSION 9.0.9~

Leftover "#+end_src" from a previous edit?

> +** Outdated notes

Instead of creating this heading, should we just delete the outdated
notes?

-- 
Kyle

[O] :noweb & library of babel

[edgar]

Hello,

I would like to know if someone can help me, please.

1. I currently have a file called
code-blocks.org. Let us say that it has something
like this:

code-blocks.org
==
* Routines
** numpy_import.py
#+NAME: py-Routines-numpy_import.py
#+CAPTION: py-Routines-numpy_import.py
#+BEGIN_SRC python :results none :noweb yes :tangle 
Routines/numpy_import.py

  # Numerical package
  import numpy as np
  # Plots
  from matplotlib import pyplot as pl
#+END_SRC

* Test
** simple.py
#+NAME: py-Test-simple_damage.py
#+CAPTION: py-Test-simple_damage.py
#+HEADER: :var fname="steps.csv"
#+HEADER: :dir "../Data/Raw"
#+HEADER: :exports none :results none
#+BEGIN_SRC python :noweb yes :tangle ./Damage/simple_damage.py :session
<>
#+END_SRC
==

2. I load it into the library of babel with
~org-babel-lob-ingest~ (~C-c C-v i~).

3. Then, I have another file called tjp.org, which
may look something like this (please, read the contents):

tjp.org
==
* My tasks
** Go here
   - [X] This is a working example

 The following block works well: I can issue
 C-c C-c, C-c C-v v and the contents are
 parsed correctly.

 #+HEADER: :exports none :results none :eval no-export
 #+BEGIN_SRC python :noweb yes :dir "../Data/Raw"
   <>
 #+END_SRC

   - [-] This does not work

 If I do C-c in the following block

 #+HEADER: :exports none :results none :eval no-export
 #+BEGIN_SRC python :noweb yes :dir "../Data/Raw"
   <>
 #+END_SRC

 I get an error:
 #+BEGIN_EXAMPLE
   File "", line 2
   <>
^
   SyntaxError: invalid syntax
 #+END_EXAMPLE

 If I do C-c C-v v, I see this:
 #+BEGIN_EXAMPLE
   <>
 #+END_EXAMPLE

   - [ ] If I put all the blocks in the same file,
 everything works.
==

Does anybody know what I am doing wrong? Thanks :) .


#+BEGIN_SRC elisp
  (emacs-version)
#+END_SRC

#+RESULTS:
: GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)
:  of 2015-01-11 on maritornes, modified by Debian

#+BEGIN_SRC elisp
  (org-version)
#+END_SRC

#+RESULTS:
: 9.0.9

-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

[O] Bug: Clock table reports wrong data [9.0.9]

[Pierre-Henry F.]

Hello!
Given:
** test
#+BEGIN: clocktable :maxlevel 3 :scope subtree :block 2017-07-03
#+CAPTION: Clock summary at [2017-07-03 Mon 19:30], for Monday, July 03, 2017.
| Headline | Time | |
|--++--|
| *Total time* | *1:55* | |
|--++--|
| \_ test | | 1:55 |
#+END:
:LOGBOOK:
CLOCK: [2017-07-02 Sun 20:40]--[2017-07-02 Sun 23:55] => 3:15
:END:
If I move the cursor to the "#+BEGIN:" line then "C-c", the table
reports wrong data. Since ":block 2017-07-03" and "CLOCK: [2017-07-02
Sun 20:40]--[2017-07-02 Sun 23:55] => 3:15" then the "*Total time*"
should be: "0" but it is "*1:55*".
Emacs : GNU Emacs 25.2.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 
10.9.5 (Build 13F1911))
of 2017-04-21
Package: Org mode version 9.0.9
current state:
==
(setq
org-src-lang-modes '(("ocaml" . tuareg) ("elisp" . emacs-lisp)
("ditaa" . artist) ("asymptote" . asy)
("dot" . graphviz-dot) ("sqlite" . sql)
("calc" . fundamental) ("C" . c) ("js" . js2)
("cpp" . c++) ("C++" . c++) ("screen" . shell-script))
org-export-backends '(ascii beamer html icalendar latex org md)
org-hide-leading-stars t
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-latex-classes '(("beamer" "\\documentclass[presentation]{beamer}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
("article" "\\documentclass[11pt]{article}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"))
("report" "\\documentclass[11pt]{report}"
("\\part{%s}" . "\\part*{%s}")
("\\chapter{%s}" . "\\chapter*{%s}")
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
("book" "\\documentclass[11pt]{book}"
("\\part{%s}" . "\\part*{%s}")
("\\chapter{%s}" . "\\chapter*{%s}")
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}"))
)
org-agenda-skip-deadline-prewarning-if-scheduled t
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-html-format-drawer-function '(closure
(htmlize-buffer-places
org-html-format-table-no-css
htmlize-css-name-prefix
htmlize-output-type htmlize-output-type
htmlize-css-name-prefix t)
(_name contents) contents)
org-log-done 'time
org-latex-format-inlinetask-function 
'org-latex-format-inlinetask-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-link-search-must-match-exact-headline nil
org-agenda-skip-scheduled-if-done t
org-latex-format-headline-function 'org-latex-format-headline-default-function
org-enable-table-editor t
org-todo-keyword-faces '(("TODO" :foreground "red" :weight bold)
("WAIT" :foreground "orange" :weight bold)
("DONE" :foreground "forest green" :weight bold)
("CANCELLED" :foreground "white" :weight bold))
org-capture-templates '(("p" "personal" entry
(file+headline user/tasks-file "tasks")
"* TODO \n DEADLINE: %t" :prepend t :clock-in t
:clock-resume t)
)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-latex-format-drawer-function '(closure (t) (_ contents) contents)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '((closure
(org-inlinetask-min-level buffer-face-mode-face
org-struct-menu org-last-state texmathp-why
remember-data-file iswitchb-temp-buflist
align-mode-rules-list t)
nil
(add-hook (quote change-major-mode-hook)
(quote org-show-block-all) (quote append) (quote local))
)
(closure
(org-inlinetask-min-level buffer-face-mode-face
org-struct-menu org-last-state texmathp-why
remember-data-file iswitchb-temp-buflist
calc-embedded-open-mode calc-embedded-open-formula
calc-embedded-close-formula align-mode-rules-list
org-export-registered-backends t)
nil
(add-hook (quote change-major-mode-hook)
(quote org-show-block-all) (quote append) (quote local))
)
(closure (*this* org-babel-confirm-evaluate-answer-no t) nil
(add-hook (quote change-major-mode-hook)
(quote org-babel-show-result-all) (quote append)
(quote local))
)
org-clock-load org-shortcuts er/add-org-mode-expansions
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-block-all append
local]
5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-babel-show-result-all
append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-archive-hook '(org-attach-archive-delete-maybe)
org-agenda-repeating-timestamp-show-all nil
org-ascii-format-drawer-function '(closure 

Re: [O] org-protocol documentation

[Mario Martelli]

>> This one I do not understand.
>> I use now @file{emacsclient} consistently if that was the meaning of the 
>> comment.
>> 
> 
> No, it's a much more mundane style issue: you need to have two spaces after a 
> period.

:smile:

I hope I got that changed too ;)

rgrds
Mario
— 



smime.p7s
Description: S/MIME cryptographic signature

Re: [O] exporting org-mode to latex gives unwanted \label on all sections

[Nicolas Goaziou]

Hello,

Sharon Kimble  writes:

> I have an org-mode document that I'm exporting to latex which works
> pretty well. But, there is one problem - for every title in all of the
> sections, org-mode export has put a label on even where I have none in
> my source file!

It doesn't hurt, does it? Org uses them to resolve internal references.

If you really need to, I guess you can write an headline filter so as to
remove them.

Regards,

-- 
Nicolas Goaziou

Re: [O] org mode moves to GNU emacs core

[Nick Dokos]

Adonay Felipe Nogueira  writes:

> I have just thought of some more advantages and disadvantages too.
>
> * Strengths
>
> ** One less split in development effort
>
> This one explains itself. Also, for a related article against "forking",
> "bundling", and "reinventing the wheel" practices, see
> [[https://wingolog.org/archives/2015/11/09/embracing-conways-law]].
>
> * Threats
>
> ** People who still refuse to contribute to GNU Emacs for some reason
>
> I have seem people making completely separated projects from GNU Emacs
> due to concerns of being required to assign copyright to the
> FSF. However, first and foremost, I must add that I'm in favor of doing
> such assignment, because FSF is a charity organization --- not just a
> non-profit ---, and they, together with other organizations, do
> community-oriented copyleft enforcement, not the
> "average"/"extortion-based" copyleft enforcement.
>

Whoa: some of what you describe exists (see e.g.
https://sfconservancy.org/blog/2016/jul/19/patrick-mchardy-gpl-enforcement/),
but it is a distant outlier. Calling it "average" is as inaccurate as
calling Pele an "average" footballer.

-- 
Nick

Re: [O] Upstream synchronization documentation

[Rasmus Pank Roulund]

Kyle Meyer  writes:

>> Whereas in your text I think it is the other way round, isn't it?
>> (I.e. the Emacs branch is more stable, and you are talking about
>> porting a fix that someone has made in that branch to the Org master.)
>> So perhaps 'forward port' would be clearer?
>
> I suspect that Org's maint (where the Emacs changes land) is generally
> more stable than the Org in Emacs's master, but, yes, Emacs's version is
> the older version.  (Well, with v9.0.9 just synced the versions match,
> but maint still has quite a few more commits.)
>
> Since before I took over "backporting" changes from the Emacs repo, it's
> been referred to as this.  Although I agree it isn't great word choice,
> I'd prefer that we remain consistent so that, for example, "git log -i
> --grep=backport" remains informative.
>
> But if people think using "backport" is too confusing, I'm OK switching
> to another term.  Of "forward port" and "propagate" (suggested in this
> thread by Eric), I prefer "propagate"---or maybe just "port", though
> grepping for that might lead to too many false positives.  And if we
> stick with "backport", it still might be a good idea to clarify in
> README_maintainer that we're abusing the term.

So at least I’m not crazy for "coming up with" it backporting!

So I will keep calling it "backporting" but explain that it is more like
propagating changes from the Emacs repository (back) to the Org
repository.

Thanks,
Rasmus

-- 
Dung makes an excellent fertilizer

Re: [O] org-protocol documentation

[Nick Dokos]

Mario Martelli  writes:

>>> +Org protocol is triggered by @file{emacsclient}. If you want to use Org
>>  ^^^
>> Gotcha
>> 
>>> +protocol, there are many possibilities to do so.  You can invoke 
>>> emacsclient
>>> +by a shortcut on your desktop for example. Or by adding a bookmark to your 
>>> browser.
>>^^^
>>   Ditto
>
> This one I do not understand.
> I use now @file{emacsclient} consistently if that was the meaning of the 
> comment.
>

No, it's a much more mundane style issue: you need to have two spaces after a 
period.

-- 
Nick

Re: [O] [Chris Kauffman] Re: include org-table-move-single-cell.el in org mode

[Nick Dokos]

Nicolas Goaziou  writes:

> Hello,
>
> Uwe Brauer  writes:
>
>> I found swapping of cells very useful and came across some code written
>> by Chris Kauffman, which proved to be very helpful and considerably
>> shorted by workflow. 
>>
>> https://cs.gmu.edu/~kauffman/software/org-table-move-single-cell.el
>>
>>
>> Chris agreed that his code could be included in the orgmode repo,  I
>> have attached his mail.
>>
>> I recommend strongly to do that.
>
> Thank you for the heads-up.
>
> I see no objection to this. I can be useful sometimes.
>
> However, the feature would require documentation and a couple of simple
> tests. Would Chris, or someone else, be willing to do that?
>

Wouldn't it also require Chris's copyright assignment?

-- 
Nick

Re: [O] org mode moves to GNU emacs core

[Adonay Felipe Nogueira]

Also, all the issues related to updates and compatibility would be
solved if more poeple used GNU Guix package manager. This way, GNU Emacs
can integrate Org in its core, and use the "1 release per 9 months"
cycle, and also could have package recipes pointing to arbitrary commits
if there is a critical feature or critical bug.

Also, GNU Guix users can make and use their own package recipes with
ease.

Lastly, now a bit more technical: Among other things, GNU Guix project
tries to make package recipes in such a way that the package recipe
being created or edited avoids depending on specific versions of other
packages.

[O] exporting org-mode to latex gives unwanted \label on all sections

[Sharon Kimble]

I have an org-mode document that I'm exporting to latex which works
pretty well. But, there is one problem - for every title in all of the
sections, org-mode export has put a label on even where I have none in
my source file!

Example -

--8<---cut here---start->8---
* Preface
\minitoc

** Disclaimer


The author of this book has used her best efforts in preparing this book and 
the information
contained in it. This book is distributed as is, without warranty of any kind, 
either express or
implied, respecting the contents of this ebook, including but not limited to 
implied warranties for
the ebook's quality, performance, or fitness for any purpose. The author and 
any dealers and
distributors shall not be liable to the purchaser or any other person or entity 
with respect to
liability, loss, or damages caused or alleged to have been caused directly or 
indirectly by this
ebook. This document is provided as is.

\begin{mdframed}[outerlinecolor=black,outerlinewidth=2pt,linecolor=cccolor,middlelinewidth=3pt,roundcorner=10pt]
\textcolor{red}{The author takes no responsibilities for any problems,
  damages, or loss of sanity resulting from improper usage of hormones. If
  you are in any doubt, do NOT take the tablets, or whatever but post a
  question to your relevant newsgroup or refer to a competent medical
  doctor or endocrinologist. Messing about with something you do not
  understand may seriously damage your health. YOU HAVE BEEN WARNED.}
\end{mdframed}

** Introduction
--8<---cut here---end--->8---

Becomes -

--8<---cut here---start->8---
\chapter{Preface}
\label{sec:org07cbb06}
\minitoc

\section{Disclaimer}
\label{sec:orgd2a1339}


The author of this book has used her best efforts in preparing this book and 
the information
contained in it. This book is distributed as is, without warranty of any kind, 
either express or
implied, respecting the contents of this ebook, including but not limited to 
implied warranties for
the ebook's quality, performance, or fitness for any purpose. The author and 
any dealers and
distributors shall not be liable to the purchaser or any other person or entity 
with respect to
liability, loss, or damages caused or alleged to have been caused directly or 
indirectly by this
ebook. This document is provided as is.

\begin{mdframed}[outerlinecolor=black,outerlinewidth=2pt,linecolor=cccolor,middlelinewidth=3pt,roundcorner=10pt]
\textcolor{red}{The author takes no responsibilities for any problems,
  damages, or loss of sanity resulting from improper usage of hormones. If
  you are in any doubt, do NOT take the tablets, or whatever but post a
  question to your relevant newsgroup or refer to a competent medical
  doctor or endocrinologist. Messing about with something you do not
  understand may seriously damage your health. YOU HAVE BEEN WARNED.}
\end{mdframed}

\section{Introduction}
\label{sec:orge89bb2c}
--8<---cut here---end--->8---

So how can I get rid of this unwanted \label action please?

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk  
Debian 9.0, fluxbox 1.3.5-2, emacs 25.1.1, org-mode 9.0.7


signature.asc
Description: PGP signature

Re: [O] Versioning of worg content

[Achim Gratz]

Bastien writes:
> No.  Worg needs love.  And yes, we could tag Worg's repository
> with Org-mode versions, the same as we would do with documentation.

If you are talking about the Git repository behind Worg, then:

a) Yes, we could give that repository version tags.
b) No, we shouldn't do that unless SomeOne™ keeps all of Worg consistent
with the Org releases.

If you are saying instead that the examples in Worg should be annotated
with the Org version that they were provided for (or last tested to be
working at), that would be good, but see b) above.


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

[O] Emacs master now updated to Org 9.0.9 (Was: org-merger questions)

[Kaushal Modi]

Yay!

emacs -Q on emacs master will now feature the new Org 9.0.9.

Thanks to Rasmus, Kyle, Bastien in making this merge happen. This was a
mega-merger and it happened in a seamless fashion.

Thanks to Nicolas and everyone involved in the Org development that enabled
us getting Org updates with new features and fixes on timely basis.

On Mon, Jul 3, 2017 at 3:25 AM Bastien  wrote:

> Hi John,
>
> John Wiegley  writes:
>
> >> Bastien Guerry  writes:
> >
> >> John and Eli, if there is any concern, let us know.
> >
> > No concerns here, thanks for the heads up, Bastien.
>
> Done, thanks!  Emacs master now features Org 9.0.9.
>
-- 

Kaushal Modi

[O] No support for generation of 'HELP' setting of org-info.js in HTML export

[Olivier Berger]

Hi.

Unless I'm mistaken, the generation of the init section in HTML export
won't set the HELP variable supported by org-info.js [0], which allows
to display a message advertizing the use of org-info and pointing to its
help.

It would be interesting to be able to set it with #+INFOJS_OPT:
settings.

Thanks in advance.

Best regards,

[0] http://orgmode.org/worg/code/org-info-js/#text-using-set
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Re: [O] org mode moves to GNU emacs core

[Robert Horn]

Bastien Guerry writes:

> Hi Philip,
>
> phillip.l...@russet.org.uk (Phillip Lord) writes:
>
>> I presume you do see this as an advantage? The issue is, surely,
>> that it's too much of a PITA for the advantage that you gain?
>
> Well, it's not really about PITA-or-not-PITA, it's just that I want
> org-mode to be the default mode for some files in Emacs, and having
> org-mode in Emacs' core is the most simple way to go for this.
>

I just did a quick check of my git repositories for org-mode and emacs.
There is a significant difference in release cycle policies, and this
will affect users.  Emacs makes a release about once every 9 months,
usually a point release.  Major feature releases are less frequent.
Org-mode makes a release about once per month, also usually a point
release.

I think that switching to the emacs cycle would be perceived as making
org-mode far less responsive to problem reports and feature improvements.

There are ways that the git repositories and release policies can be
organized to enable more rapid response to minor bugs and small features
while still integrating into core emacs.  I think that you should figure
out a mutually acceptable means of maintaining the present rapid
responsiveness.  With a suitable structuring of make files, etc., you
can probably also deal with the performance issues associated with
building updated versions.  The emacs maintainers would have to agree.

It does call for a little more setup work, and probably a semi-permanent
branch structure in git to allow for org updates, while gaining most of
what you want.

It would also mean that those who want to stay on the leading edge of
org-mode would need to maintain git synchronization with emacs rather
than org-mode.  With good explanation and documentation that shouldn't
be too much of a problem.  I do it already on an ad-hoc basis because I
found elpa to be too problematic.

R Horn

Re: [O] Upstream synchronization documentation

[Kyle Meyer]

Neil Jerram  writes:

> I just noticed that your text talks about 'backporting', and wondered if 
> that is the clearest term to use.  To me, a 'backport' usually means 
> porting a change or fix from the master or development branch to some 
> older or more stable branch.

Right.  Thanks for bringing this up.

> Whereas in your text I think it is the other way round, isn't it?
> (I.e. the Emacs branch is more stable, and you are talking about
> porting a fix that someone has made in that branch to the Org master.)
> So perhaps 'forward port' would be clearer?

I suspect that Org's maint (where the Emacs changes land) is generally
more stable than the Org in Emacs's master, but, yes, Emacs's version is
the older version.  (Well, with v9.0.9 just synced the versions match,
but maint still has quite a few more commits.)

Since before I took over "backporting" changes from the Emacs repo, it's
been referred to as this.  Although I agree it isn't great word choice,
I'd prefer that we remain consistent so that, for example, "git log -i
--grep=backport" remains informative.

But if people think using "backport" is too confusing, I'm OK switching
to another term.  Of "forward port" and "propagate" (suggested in this
thread by Eric), I prefer "propagate"---or maybe just "port", though
grepping for that might lead to too many false positives.  And if we
stick with "backport", it still might be a good idea to clarify in
README_maintainer that we're abusing the term.

-- 
Kyle

Re: [O] org mode moves to GNU emacs core

[Uwe Brauer]

>>> "qTim" == qTim Cross  writes:

   > Just to throw my 2 cents in.

   > 1. Problems with mixed versions. Currently, Emacs has org 8.x included
   > in the distribution. This is despite 9.x being out before the release of
   > 25.2. Something needs to be done to improve coordination and perhaps if
   > it was part of the core, this would be more likely. At any rate, the
   > current situation means you need to be very careful to ensure no org
   > feature is loaded before the ELPA package is loaded or you will get odd
   > behaviour and the symbol's value is void errors. 

   > 2. If you just want to load the ELPA version of org (not
   > org-plus-contrib) it can be a real pain. You have to play around with
   > package lists to ensure you actually get the right one. This can be a
   > real hassle if you also use the use-package package as you will often
   > get the older version bundled with Emacs if you don't have your package
   > lists in the right order.

   > 3. I would really like to see two completely separate packages rather
   > than having org and org-plus-contrib. Currently, if you have packages
   > which have org as a dependency and you have loaded org-plus-contrib
   > rather than just org, you will end up with both. Not a big issue, unless
   > your on a slow link as now you will download updates for both org and
   > org-plus-contrib. (there is no 'cleverness' with ELPA dependency
   > specifications - you cannot specify alternative dependencies).

But this critics could be applied to any emacs package and therefore to
the package system itself.

   > A lot will depend on when org becomes part f core. The trick will be to
   > do it once development of org slows down. I've been using org for a long
   > time now and have noticed that the rate of new features being added has
   > slowed down. Much of the changes now is about improvement and refinement
   > of the code base. I would imagine that at some point, things will become
   > even more stable with fewer releases. This would be the point at which
   > it would make sense to bring into core.

   > The other advantage of being part of core is that updates and changes to
   > Emacs will be integrated into org much better. We won't see situations
   > where new versions of Emacs require a rush to update org. for the end
   > user, this should create a much more stable org environment.

Well I update GNU emacs every 6 months it is not difficult but needs
considerable longer to compile and install than org mode.

   > Then of course, there will always be the option to run org straight from
   > the git repository for those who really want the latest version. I find
   > that once you have the path added to load-path, running from the git
   > repo is not much more effort than installing the latest ELPA package. 

I don't see how that would possible once it is integrated in GNU emacs
core, there will be no separate makefile or anything of that sort, but
maybe I am missing something.

Uwe 

Re: [O] org mode moves to GNU emacs core

[Adonay Felipe Nogueira]

I have just thought of some more advantages and disadvantages too.

* Strengths

** One less split in development effort

This one explains itself. Also, for a related article against "forking",
"bundling", and "reinventing the wheel" practices, see
[[https://wingolog.org/archives/2015/11/09/embracing-conways-law]].

* Threats

** People who still refuse to contribute to GNU Emacs for some reason

I have seem people making completely separated projects from GNU Emacs
due to concerns of being required to assign copyright to the
FSF. However, first and foremost, I must add that I'm in favor of doing
such assignment, because FSF is a charity organization --- not just a
non-profit ---, and they, together with other organizations, do
community-oriented copyleft enforcement, not the
"average"/"extortion-based" copyleft enforcement.

One thing that I would like to test would be to ask the same people who
deny copyright assignments to the FSF: Would they assign copyright to
some organization if such organization were to offer them a 1 bi
job? Between the two scenarios, I don't see much difference, except that
FSF works for a free/libre and just/fair digital society, whereas the
"organization" works for its own interests and can kick all their
workers and these wouldn't be able to take their own copyrights/work
back.

-- 
- [[https://libreplanet.org/wiki/User:Adfeno]]
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre, por isso não uso. Iguais a ele prefiro
  GNU Ring, ou Tox. Quer outras formas de contato? Adicione o vCard
  que está no endereço acima aos teus contatos.
- Pretende me enviar arquivos .doc, .ppt, .cdr, ou .mp3? OK, eu
  aceito, mas não repasso. Entrego apenas em formatos favoráveis ao
  /software/ livre. Favor entrar em contato em caso de dúvida.

Re: [O] org mode moves to GNU emacs core

[Eric S Fraga]

On Monday,  3 Jul 2017 at 12:40, Bastien Guerry wrote:

[...]

> Well, it's not really about PITA-or-not-PITA, it's just that I want
> org-mode to be the default mode for some files in Emacs, and having
> org-mode in Emacs' core is the most simple way to go for this.

This, I must admit, is quite a good reason.  I do think of org as an
integral part of Emacs these days (org is my default mode essentially)
so hadn't stopped to think that without it being formally part of Emacs,
Emacs cannot depend on it.

Okay.  I'm convinced.  :-)

Will have to update emacs-snapshot more often then... although
unfortunately not available for my wee Pandora as far as I can see.  And
the thought of building Emacs on the Pandora sends me into a catatonic
state (600 MHz arm5 processor).

-- 
: Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-551-g92e8c8


signature.asc
Description: PGP signature

Re: [O] org mode moves to GNU emacs core

[qTim Cross]

Just to throw my 2 cents in.

While I can understand the benefits of being able to easily install the
latest org package via elpa, I think there are some significant benefits
to org being a part of core Emacs.

I currently find three issues with the current situation which may be
somewhat resolved if org was part of core emacs.

1. Problems with mixed versions. Currently, Emacs has org 8.x included
in the distribution. This is despite 9.x being out before the release of
25.2. Something needs to be done to improve coordination and perhaps if
it was part of the core, this would be more likely. At any rate, the
current situation means you need to be very careful to ensure no org
feature is loaded before the ELPA package is loaded or you will get odd
behaviour and the symbol's value is void errors. 

2. If you just want to load the ELPA version of org (not
org-plus-contrib) it can be a real pain. You have to play around with
package lists to ensure you actually get the right one. This can be a
real hassle if you also use the use-package package as you will often
get the older version bundled with Emacs if you don't have your package
lists in the right order.

3. I would really like to see two completely separate packages rather
than having org and org-plus-contrib. Currently, if you have packages
which have org as a dependency and you have loaded org-plus-contrib
rather than just org, you will end up with both. Not a big issue, unless
your on a slow link as now you will download updates for both org and
org-plus-contrib. (there is no 'cleverness' with ELPA dependency
specifications - you cannot specify alternative dependencies).

A lot will depend on when org becomes part f core. The trick will be to
do it once development of org slows down. I've been using org for a long
time now and have noticed that the rate of new features being added has
slowed down. Much of the changes now is about improvement and refinement
of the code base. I would imagine that at some point, things will become
even more stable with fewer releases. This would be the point at which
it would make sense to bring into core.

The other advantage of being part of core is that updates and changes to
Emacs will be integrated into org much better. We won't see situations
where new versions of Emacs require a rush to update org. for the end
user, this should create a much more stable org environment.

Then of course, there will always be the option to run org straight from
the git repository for those who really want the latest version. I find
that once you have the path added to load-path, running from the git
repo is not much more effort than installing the latest ELPA package. 


Uwe Brauer writes:

 "Bastien" == Bastien   writes:
>
> > Hi Uwe,
> > Uwe Brauer  writes:
>
> >> I am not sure whether I understand that discussion in emacs dev
> >> correctly. Will orgmode be moved into the GNU emacs try as it was done
> >> with gnus?
>
> > for the record, I would be in favor of this.  Why?
>
> > - Less installation headaches
> > - Less maintainance and backward-compatibility headaches
> > - Possibility of having etc/TODO in Emacs using org-mode
> > - Attracting Org developers/contributors to Emacs repo
>
> > As a maintainer, I don't see any advantage of having Org
> > maintained as an ELPA package.
>
> But the release cycles are very different, so in order to have always
> the latest stable org package, I need to compile and install the whole
> GNU emacs beast. I thought the whole idea of a package system is to
> avoid this headache. 


-- 
Tim Cross

Re: [O] org mode moves to GNU emacs core

[Bastien Guerry]

Hi Philip,

phillip.l...@russet.org.uk (Phillip Lord) writes:

> I presume you do see this as an advantage? The issue is, surely,
> that it's too much of a PITA for the advantage that you gain?

Well, it's not really about PITA-or-not-PITA, it's just that I want
org-mode to be the default mode for some files in Emacs, and having
org-mode in Emacs' core is the most simple way to go for this.

Maintainers of projects like Gnus or CEDET don't want their code to
live outside of Emacs repo neither, so I guess simplicity is a big
win.

-- 
 Bastien

Re: [O] Upstream synchronization documentation

[Eric S Fraga]

And "propagate" would arguably be better than "forward port"?
-- 
: Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-551-g92e8c8


signature.asc
Description: PGP signature

Re: [O] org mode moves to GNU emacs core

[Phillip Lord]

Bastien  writes:

> Hi Uwe,
>
> Uwe Brauer  writes:
>
>> I am not sure whether I understand that discussion in emacs dev
>> correctly. Will orgmode be moved into the GNU emacs try as it was done
>> with gnus?
>
> for the record, I would be in favor of this.  Why?
>
> - Less installation headaches
> - Less maintainance and backward-compatibility headaches
> - Possibility of having etc/TODO in Emacs using org-mode
> - Attracting Org developers/contributors to Emacs repo
>
> As a maintainer, I don't see any advantage of having Org
> maintained as an ELPA package.


The advantage should be that it allows an independent upgrade cycle for
org from the long cycle of Emacs. I presume you do see this as an
advantage? The issue is, surely, that it's too much of a PITA for the
advantage that you gain?

If that's true, I'm interested in which bits are a PITA. Is it
fundementally because of ELPA? That is, the latest version of org-mode
has to support more than one version of Emacs? Or, is it having two
version repos, with all the merging?

Phil

Re: [O] Upstream synchronization documentation

[Neil Jerram]

Hi Rasmus,

On 03/07/17 11:35, Rasmus wrote:

Hi,

The documentation in README_maintainer is a bit outdated
wrt. synchronizing with upstream Emacs.

I have updated the to best of my knowledge in the attached patch.  I would
be happy to push it, if there are no objections.

It would also be great if someone would let me know about the mistakes
that are undoubtedly in the draft.

Rasmus



I just noticed that your text talks about 'backporting', and wondered if 
that is the clearest term to use.  To me, a 'backport' usually means 
porting a change or fix from the master or development branch to some 
older or more stable branch.  Whereas in your text I think it is the 
other way round, isn't it?  (I.e. the Emacs branch is more stable, and 
you are talking about porting a fix that someone has made in that branch 
to the Org master.)  So perhaps 'forward port' would be clearer?


Regards - Neil

[O] Upstream synchronization documentation

[Rasmus]

Hi,

The documentation in README_maintainer is a bit outdated
wrt. synchronizing with upstream Emacs.

I have updated the to best of my knowledge in the attached patch.  I would
be happy to push it, if there are no objections.

It would also be great if someone would let me know about the mistakes
that are undoubtedly in the draft.

Rasmus

-- 
I hear there's rumors on the, uh, Internets. . .
>From 2126076308e13efbacf115afc3856d2c1da541fa Mon Sep 17 00:00:00 2001
From: Rasmus 
Date: Mon, 3 Jul 2017 11:48:58 +0200
Subject: [PATCH] Update README_maintainer with upstream synchronization
 instructions

* README_maintainer: Update with upstream synchronization instructions.
---
 README_maintainer | 61 +++
 1 file changed, 57 insertions(+), 4 deletions(-)

diff --git a/README_maintainer b/README_maintainer
index 6b162aa52..bf2678da3 100644
--- a/README_maintainer
+++ b/README_maintainer
@@ -88,9 +88,62 @@ Org and contributed libraries.
 
 org-latest* snapshots are built from the *master* branch.
 
-* Synchronization with Emacs
-
-** Updating etc/ORG-NEWS
+* Synchronization Org and upstream Emacs
+Org should be kept in sync with the upstream [[http://git.savannah.gnu.org/cgit/emacs.git/tree/][Emacs repository]].
+Sometimes Org is changed in the Emacs upstream repo.  These changes
+should be backported.  Likewise, new stable releases of Org should be
+added to Emacs.
+** Backporting changes from upstream Emacs
+To check for backports from the Emacs upstream repository, one can use
+the following =git= command, cutesy of [[http://permalink.gmane.org/gmane.emacs.devel/215861][Kyle Meyer]],
+
+: git log $rev..origin/emacs-25 -- lisp/org doc/misc/org.texi etc/refcards/orgcard.tex
+
+where =$rev= is the last commit from the =emacs-25= branch that was
+backported.  The same should be done for the =master= branch.
+
+One may also use this [[http://git.savannah.gnu.org/cgit/emacs.git/atom/lisp/org/][Atom feed]] to see upstream changes.
+** Updating the Org version in upstream Emacs
+After a new release of Org, it should be synced to the Emacs
+repository.
+
+Typically, Org can be synchronized by copying over files from the
+=emacs-sync= branch of the Org repository to the =master= branch of Emacs
+repository.  The =emacs-sync= branch has a few extra changes compared to
+the =maint= branch.  If the Emacs maintainers are planning a new release
+of Emacs soon, it is possible that another branch, e.g. =emacs-25=,
+should be used.
+
+If you are synchronizing a major release of Org, it may be useful to
+use a separate branch before merging, e.g. =scratch/org-mode-merge=.
+This can then later be merged with the =master= branch, when everything
+has been tested.
+
+Please also see [[http://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE][CONTRIBUTE]] in the Emacs repository.
+*** Where to files go
+The following detail where files in Org repository are copied to in
+the Emacs repository.
+*** =org-mode/doc=
+- =org.texi= :: Copy to =emacs/doc/misc=.  It may be necessary to replace,
+		~@include org-version.inc~ #+end_src with ~@set VERSION 9.0.9~
+		or similar. 
+- =orgcard.tex= :: Copy to =emacs/doc/refcards=.  Make sure that
+		   ~\def\orgversionnumber~ and ~\def\versionyear~ are up
+		   to date, if necessary.
+- =library-of-babel.org= :: Copy to =emacs/etc/org=.
+***  =org-mode/etc=
+- =styles/*= :: Copy to =emacs/etc/org=.
+- =schema/*.rnc= :: Copy to =emacs/etc/schema=.
+- =schema/schemas.xml= :: New entries of this files should be added to
+ =emacs/etc/schema/schemas.xml=.
+- =ORG-NEWS= :: Copy to =emacs/etc=
+*** =org-mode/lisp=
+- Copy =*.el= files to  =emacs/lisp/org=, except =org-loaddefs.el=!
+- You should create =org-version.el= in =emacs/lisp/org=.  The file is
+  created when you =make= Org.
+*** TODO =org-mode/testing=
+** Outdated notes
+*** Updating etc/ORG-NEWS
 
 Latest changes in Emacs are described in Emacs =etc/NEWS=, and latest
 changes in major Emacs packages are described in =etc/ORG-NEWS=. 
@@ -100,7 +153,7 @@ always should), you need to update Org's =etc/ORG-NEWS= file so that
 you can merge it with that of Emacs.  There is one top-level section
 for each release that is merged with Emacs.
 
-** Merging with Emacs trunk branch
+*** Merging with Emacs trunk branch
 
 This is still a significant headache.  Some hand work is needed here.
 
-- 
2.13.2

[O] Adding remarks or warning blocks to technical manuals exported to LaTeX

[Olivier Berger]

Hi.

I'm writing technical instructions in an educational context (technical
course handout, etc.).
I wanted to include sections with icons and "boxes" much like what
exists for alert blocks in beame, but I'm using the article layout.

I've found that the bclogo LaTeX environment suits that need, which
allows me to construct something like the following, using LaTeX special
block:

#+LaTeX_HEADER: \usepackage[tikz]{bclogo}
...
#+ATTR_LATEX: :options [noborder=true,logo=\bcattention]{Important warning}
#+BEGIN_bclogo
Attention, students, read this carefully.
#+END_bclogo

I though this could be a quite generic need, for which I struggled to
find instructions, thus sharing the tip with the org-mode community.

Maybe there are other alternatives to bclogo [0], which may then be
worth sharing too.

Hope this helps,

[0] http://www.ctan.org/pkg/bclogo 
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

[O] Suggestion: provide more detailed example of :options for LaTeX special blocks

[Olivier Berger]

Hi.

May I suggest to improve the docs of
[[http://orgmode.org/manual/Special-blocks-in-LaTeX-export.html][Special
blocks in LaTeX export]] to make it more explicit that the special
blocks :options can contain both options or arguments of the LaTeX environment.

Here's an example:

#+ATTR_LATEX: :options [logo=\bcattention]{The warning}
#+BEGIN_bclogo
Attention, this is a warning
#+END_bclogo

This requires or course:
#+LaTeX_HEADER: \usepackage[tikz]{bclogo}


I've been struggling with trying to do this, until I read the sources of
ox-latex and noticed that it wasn't limited to the '[...]'
options... and much later re-read the manual to finally notice the
"appends as-is to that environment's opening string" ;-)

Maybe providing an example that uses both the '[...]' and the '{...}'
would save others' time.

Unfortunately, I'm not fluent enough in LaTeX to suggest a more
"generic" environment than bclogo, readily available in an article, for a
direct patch proposal to the manual sources.

Hope this helps.

Thanks in advance.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Re: [O] org mode moves to GNU emacs core

[Alan Schmitt]

"ESF" == Eric S Fraga  writes:

ESF> On Monday,  3 Jul 2017 at 08:33, Uwe Brauer wrote:
>> But the release cycles are very different, so in order to have always
>> the latest stable org package, I need to compile and install the whole
>> GNU emacs beast. I thought the whole idea of a package system is to
>> avoid this headache. 

ESF> I agree.  I like tracking org development but would not be at all keen
ESF> on tracking emacs in the same way.  I was actually quite disappointed
ESF> when gnus went into emacs master as I can no longer easily play with any
ESF> experimental branches etc.

Same here. I stopped trying to debug some gnus issues when I could no
longer easily compile and install new versions independently of emacs.
(I use a port of emacs for macOS, so I cannot simply recompile emacs. I
need to wait until the changes are incorporated in that port.) It would
be too bad if the same happened with org mode.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-05: 409.65, 2016-05: 407.70


signature.asc
Description: PGP signature

Re: [O] Donating money to mobile org.

[Rasmus]

Bastien  writes:

> "M. P."  writes:
>
>> Hello If I want to donate specifically to mobile org what would I do?
>
> If you are referring to https://mobileorg.github.io, contacting the
> authors would be the best way to know.

There's also these clients.

Syncorg, Android:https://github.com/wizmer/syncorg
Mobileorg, Android: https://github.com/matburt/mobileorg-android
Orgzly, Android:https://github.com/orgzly/orgzly-android

I am not sure Mobileorg for android is still developed.

Rasmus

-- 
I almost cut my hair, it happened just the other day

Re: [O] org mode moves to GNU emacs core

[Eric S Fraga]

On Monday,  3 Jul 2017 at 08:33, Uwe Brauer wrote:
> But the release cycles are very different, so in order to have always
> the latest stable org package, I need to compile and install the whole
> GNU emacs beast. I thought the whole idea of a package system is to
> avoid this headache. 

I agree.  I like tracking org development but would not be at all keen
on tracking emacs in the same way.  I was actually quite disappointed
when gnus went into emacs master as I can no longer easily play with any
experimental branches etc.

-- 
: Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-551-g92e8c8


signature.asc
Description: PGP signature

Re: [O] Problem with Org-mobile

[Mario Martelli]

> "Steve Prud'Homme"  writes:
> 
>> When I go in the mobile-org App on my phone I sync, nothing append,
>> no file is showing.
> 
> Could it be a problem with Mobile-Org ?

Sounds like it. Would love to hear about it on: 
https://github.com/MobileOrg/mobileorg/issues 


rgrds
Mario
— 



smime.p7s
Description: S/MIME cryptographic signature

Re: [O] org mode moves to GNU emacs core

[Uwe Brauer]

>>> "Bastien" == Bastien   writes:

> Hi Uwe,
> Uwe Brauer  writes:

>> I am not sure whether I understand that discussion in emacs dev
>> correctly. Will orgmode be moved into the GNU emacs try as it was done
>> with gnus?

> for the record, I would be in favor of this.  Why?

> - Less installation headaches
> - Less maintainance and backward-compatibility headaches
> - Possibility of having etc/TODO in Emacs using org-mode
> - Attracting Org developers/contributors to Emacs repo

> As a maintainer, I don't see any advantage of having Org
> maintained as an ELPA package.

But the release cycles are very different, so in order to have always
the latest stable org package, I need to compile and install the whole
GNU emacs beast. I thought the whole idea of a package system is to
avoid this headache. 

Re: [O] org mode moves to GNU emacs core

[Bastien]

Hi Uwe,

Uwe Brauer  writes:

> I am not sure whether I understand that discussion in emacs dev
> correctly. Will orgmode be moved into the GNU emacs try as it was done
> with gnus?

for the record, I would be in favor of this.  Why?

- Less installation headaches
- Less maintainance and backward-compatibility headaches
- Possibility of having etc/TODO in Emacs using org-mode
- Attracting Org developers/contributors to Emacs repo

As a maintainer, I don't see any advantage of having Org
maintained as an ELPA package.

-- 
 Bastien

Re: [O] trying to fixing & make it useful this org-blog.el

[Bastien]

Hi RSM,

RSM  writes:

> Hi, group. I know there are some other solutions about blogging from
> EMACS out there but I find org-blog.el free from dependences other
> than emacs and org-mode. Plus it's light and straightforward however
> outdated as I guess.
> I've been trying to make it works, tried e.g. (see line 127 in this
> pastebin=> https://pastebin.com/8HyViHRp)  it called for 'ox-publish'
> rather than 'org-publish', the old engine & led by error output, but
> unsuccessful I don't know what else to do.
>
> Any clue, plesse??

If you want to use org-blog.el, which dates from 2006, you'd have to
install an old Org version.  You can do this by using the git repo and
checking out the desired tag.

HTH,

-- 
 Bastien

Re: [O] mimetype for orgmode files

[Bastien]

Hi John,

John Kitchin  writes:

> Could we come to an agreement on "text/x-org" or "text/x-orgmode" and
> document that on orgmode.org?

I'd vote for "text/x-org".  The "mode" part sounds emacsy,
which is precisely not the point for a mimetype.

I can add this sentence to orgmode.org's homepage: 

  The /de facto/ mimetype for org attachments is "text/x-org".

Or any better suggestion?

-- 
 Bastien

Re: [O] Org-mode ELPA repository package is not very updated?

[Bastien]

Hi,

"numbch...@gmail.com"  writes:

> I found Org-mode ELPA released source code is old and does not
> include some patches and updates.

This should be fixed now -- please confirm in a few days.

-- 
 Bastien

Re: [O] worg doc page, org-src-mode-hook, textual error

[Bastien]

Hi Matt,

Matt Lye  writes:

> Regarding the entry for `org-src-mode-hook` on the Worg doc page 
> (http://orgmode.org/worg/doc.html).
>
> The current documentation says that this hook is run after entering or 
> leaving `org-src-mode`.
>
> As of "Org mode version 9.0.7 (9.0.7-elpa)," it appears that the
> hook is only run when the major mode is entered.

Fixed, thanks.

-- 
 Bastien

Re: [O] trying to fix link in worg faq

[Bastien]

Hi Stig,

Stig Brautaset  writes:

> I tried to fix the link to the "agenda-optimization" article in in
> worg's FAQ, but it didn't make much of a difference. My commit was:
> http://orgmode.org/cgit.cgi/worg.git/commit/?id=1e9e6a336eb28a705dd61f205378dc19f73f5ad5

this is now fixed in http://orgmode.org/worg/org-faq.html

> As an aside I've tried to build worg locally for preview, but I've not
> been able to do so. Can anyone direct me to instructions, if such
> exists, of how to do that please?

I'm attaching the .emacs.el file that resides on orgmode.org server,
this configuration can help.

-- 
 Bastien


orgmode.org.emacs.el
Description: application/emacs-lisp

Re: [O] Sorting Todo

[Bastien]

Hi Marvin,

marvin doyley  writes:

> I would like to sort my TODO file using two criteria: (a) priority and (b) 
> schedule and deadline.
> I would like items to be ordered as follows - priority, deadline, schedule, 
> and everything else.
> Does anybody know how to do this ?

did you check the documentation?

M-: (info "(Org)Sorting agenda items") RET

Thanks,

-- 
 Bastien

[O] bug#25546: Wrong mailing list

[Bastien]

Hi Wojciech,

Wojciech Gac  writes:

> I just realized I sent this patch to the wrong mailing list. Could
> you please close this issue? I'll post it to the Org mode list where
> it belongs. Sorry for the confusion.

Closed, thanks.

-- 
 Bastien

Re: [O] Manual web page link is not connected properly.

[Bastien]

Hi HyungSuk,

HyungSuk Ryu  writes:

> In online manual page below, 3rd footnote element, [Indirect buffer]
> link is not connected properly.
>
> http://orgmode.org/manual/Global-and-local-cycling.html#
> Global-and-local-cycling

Fixed in master, will be online for the next major release.

Thanks for reporting this,

-- 
 Bastien

Re: [O] org-info.js Clobbering my CSS

[Bastien]

Hi David,

"David A. Gershman"  writes:

> If anyone has any ideas how to style outline-2,3 while in, I think,
> 'info' mode, I'd appreciate it.

did you find a solution for this?

Sadly enough, I don't think Sebastian Rose is still maintaining
org-info.js.

The documentation is here:
http://orgmode.org/worg/code/org-info-js/

And the non-minified version of the source code is here:
http://orgmode.org/worg/code/org-info-js/org-info-src.js

If someone with Javascript understanding wants to pick it
up, put it on a public repo somewhere and give it some love,
it would be nice!

-- 
 Bastien

Re: [O] Problem with Org-mobile

[Bastien]

Hi Steve,

"Steve Prud'Homme"  writes:

> When I go in the mobile-org App on my phone I sync, nothing append,
> no file is showing.

Could it be a problem with Mobile-Org ?

-- 
 Bastien

Re: [O] Cannot reach support button on orgmode web page

[Bastien]

Hi Karl,

Karl Voit  writes:

> - http://orgmode.org/Changes.html
> - Firefox 45.6.0
> - Debian GNU/Linux Jessie
>
> When I try to move my mouse over the "Support Org" button in the
> lower right corner, the following message gets moved in, making it
> impossible to me to reach the button:
>
> "If Emacs is an operating system, Org-mode is the
> office/productivity suite. -- Eric Schulte in his screenshot on
> Worg"
>
> Maybe someone here knows how to fix this.

Fixed, thanks!

-- 
 Bastien

Re: [O] Versioning of worg content

[Bastien]

Hi Stefan,

"Stefan-W. Hahn"  writes:

> is their a defined proceeding of how to cope with incompatible changes of
> org-mode in the examples at orgmode.org/worg?

No.  Worg needs love.  And yes, we could tag Worg's repository
with Org-mode versions, the same as we would do with documentation.

-- 
 Bastien

Re: [O] where and how does one request support for ox-html export into single file?

[Bastien]

Hi Xebar,

Xebar Saram  writes:

> It seems ox-html doesn't support to export into single file.

AFAIK exporting to a single file with C-c C-e h h is the default.

Or did I misundertand?

-- 
 Bastien

Re: [O] Export agenda view into CSV with properties

[Bastien]

Hi Mikhail,

Mikhail Skorzhinskiy  writes:

> I'm wondering, is there any easy way to export some properties from
> agenda view too?

Not at the moment - but maybe you can show the detailed input and
output so that someone starts hacking on this.

-- 
 Bastien

Re: [O] "Show Org source" on http://orgmode.org/worg/ does not work

[Bastien]

Hi Tim,

Tim Landscheidt  writes:

> if I click (for example) on http://orgmode.org/worg/ on the
> button "Show Org source", nothing happens.  The browser con-
> sole shows that "show_org_source is not defined".

This should be fixed now, thanks.

-- 
 Bastien

Re: [O] Useful Org Agenda Function: Add "Today" to event

[Bastien]

Hi Tory,

torys.ander...@gmail.com (Tory S. Anderson) writes:

> (fset 'tsa/org-agenda-add-today
>   (lambda ( arg) "Keyboard macro." (interactive "p")
> (kmacro-exec-ring-item (quote ([return 3 16 14 5 return 21 
> 3 46 return 24 98 return] 0 "%d")) arg)
> (message "Gave event \"TODAY\" date")))
> (with-eval-after-load 'org-agenda (define-key org-agenda-mode-map 
> (kbd "C-c .") 'tsa/org-agenda-add-today))
> (with-eval-after-load 'org-agenda (define-key org-agenda-mode-map 
> (kbd "C-c C-.") 'tsa/org-agenda-add-today))

This looks useful.  Please consider adding it to worg/org-hacks.org.

Thanks!

-- 
 Bastien

Re: [O] Agenda filtering

[Bastien]

Hi Richard,

Richard Lawrence  writes:

> Is there a simple way for me to say to the agenda, "Show me all (and
> only) the NEXT tasks that are part of a project whose deadline is before
> (say) 2016-11-01"?  It seems like this should be possible with the
> built-in agenda but I can't quite figure it out.  The tricky thing is
> filtering by the deadline of the parent project, which might be several
> levels up.

I would add a category to each project, then use something along this:

("N" "My important tasks" tags-todo
 "CATEGORY={cat1\\|cat2}+TODO={NEXT}+DEADLINE<=\"<+3d>\"")

HTH,

-- 
 Bastien

Re: [O] Blogging with Orgmode + Jekyll on GitHub Pages?

[Bastien]

Hi Stig,

Stig Brautaset  writes:

> I made a PR to add the https://github.com/eggcaker/jekyll-org plugin to
> GitHub Pages' whitelist, allowing people to use Orgmode style posts with
> GitHub Pages without checking in generated HTML documents. If this
> sounds like something you would be interested in, head over to
> https://github.com/github/pages-gem/pull/335 and put in a good word.

Thanks for the PR, I gave it a bump, despite its age.

-- 
 Bastien

Re: [O] multiple agenda views -- sticky agendas?, buffer renaming?

[Bastien]

Hi Alain,

alain.coch...@unistra.fr writes:

> I want my *Org Agenda* buffer to be open at all times, but I still
> want to be able to (say) match as many different tags as desired.
>
> Googling and searching the archives suggested 2 possible ways: (1)
> use of sticky agenda views and (2) use 'M-x rename-uniquely'.

"Sticky" agenda buffers means that agenda buffers won't be recreated
each time you call M-x org-agenda.  I'm not sure this is exactly what
you mean by "my *Org Agenda* buffer to be open at all times", is it?

Also I'm not sure what is the exact error you are pointing to: can
you restate it by saying what you expected from what action, and what
you got instead?

Thanks,

-- 
 Bastien

Re: [O] difficulty installing org-plus-contrib

[Bastien]

Hi Joakim,

joa...@verona.se writes:

> During install with package.el I get errors like:
>
> org-attach.el:42:1:Error: Symbol’s function definition is void:
> org-link-set-parameters
>
> I'm using the repo:
> ("org" . "http://orgmode.org/elpa/;)
>
> Am I doing something wrong?

>From memory, and just for the record, this error comes from trying to
install org-plus-contrib when a previous Org version has already been
loaded in your Emacs session.

HTH,

-- 
 Bastien

Re: [O] Bug: JNI Error with ditaa on Fedora 24 [8.3.6 (8.3.6-7-g4d7d52-elpaplus @ /home/stephane/.emacs.d/elpa/org-plus-contrib-20161024/)]

[Bastien]

Hi Stephane,

Stephane Wirtel  writes:

> I use Fedora 25, when I try to use ditaa with org-mode, I
> have got an issue when I try to export to html.

did you find a solution?  It looks like the issue is on ditaa.jar,
not on org-mode.  Thanks for confirming!

-- 
 Bastien

Re: [O] THANK YOU!

[Bastien]

Hi Edgar,

ed...@openmail.cc writes:

> I just want to thank everyone. I really appreciate all the effort that
> everyone has put into making Emacs and Org-mode. I may be in love with
> this software!

Thanks for sharing the good vibes!

-- 
 Bastien

Re: [O] ODT export

[Bastien]

Hi Philip,

Philip Hudson  writes:

> First time out, very disappointing and confusing results.

Did you try the ODT exporter again with better results?

-- 
 Bastien

Re: [O] Installation of org-mode from org repository

[Bastien]

Hi Shawn,

Shawn Way  writes:

> Using elpa, I’ve installed org-mode, org-20161118 which has given me
> the log file below.  I removed and installed this because the
> following error occurs:

did you manage to get a clean installation and to get rid of this
problem?

-- 
 Bastien

Re: [O] bug when generating org text then exporting to html

[Bastien]

Hi Grégoire,

Grégoire Jadi  writes:

> With the following file :
> * Test
>
> #+BEGIN_SRC elisp :results drawer :exports results
> (format "* My Headline")
> #+END_SRC
>
>
> When I export this file to HTML, I expect to have the same result as if
> I had the following file :
> * Test
> * My Headline
>
> However, the exporter also include a paragraph with :RESULTS:.

I cannot reproduce this problem.  Can you now?

-- 
 Bastien

Re: [O] org ELPA broken

[Bastien]

Hi Michael,

Michael Alan Dorman  writes:

> Has the URL for Org ELPA moved?  Because if I look at
> http://orgmode.org/elpa/, I don't see any updates since 11/18?

The cron job for building Org ELPA packages was stopped, it should
work again now - sorry for the delay!

-- 
 Bastien

[O] Bernt Hansen's setup for recent orgmode versions

[Markus Heller]

Hi,

Is anybody aware of an adaptation of Bernt Hansen's orgmode setup for the
current orgmode version?  His setup is for 8.x...

Thanks
Markus

Re: [O] [PATCH 2/2] org-refile: Fix inconsistency when listing refile targets

[Nicolas Goaziou]

Hello,

Allen Li  writes:

> I just realized that this patch was applied to the master branch, not
> the maint branch.
>
> The absence of this patch results in the continued life of a bug in
> the maint branch where it is not possible to refile to the top level
> of an agenda file when using full-file-path for
> org-refile-use-outline-path.
>
> Is it possible to backport this to the maint branch?  This will
> require adding the org-protect-slash that I mentioned earlier in this
> thread.  Otherwise, refile is basically unusable for me when
> full-file-path is set.

Wouldn't 2906e50177d47b4f4a0e75532a0c9dcc9cf72824 be sufficient in your
case?

If not, what commits are required?

Regards,

-- 
Nicolas Goaziou