Re: [O] capture templates and ^{prompt}

[Jean-Christophe Helary]

Sorry to send this question again:

> Are there cases where %\1 ... %\N would be used *outside* of a string in a 
> template?

Jean-Christophe 


> On Jun 30, 2017, at 20:04, Jean-Christophe Helary 
>  wrote:
> 
>> 
>> On Jun 30, 2017, at 18:47, Nicolas Goaziou  wrote:
>> 
>> Jean-Christophe Helary  writes:
>> 
>>> * TODO %^{prompt} [/]\n** TODO %\1 %^{prompt} %^t\n
>>> 
>>> gives
>>> 
>>> * TODO stuff [/]
>>>  
>>> ** TODO %^A stuff 
>>> 
>>> Why is that ?
>> 
>> In a string, backslash needs to be escaped: %\\1
> 
> That's certainly something to add to the documentation:
> 
> %\1 ... %\N   Insert the text entered at the Nth %^{prompt}, where N is a 
> number, starting from 1.
> 
> Are there cases where %\1 ... %\N would be used *outside* of a string in a 
> template?
> 
> Jean-Christophe

Re: [O] Subtitles in HTML export render document invalid

[Rasmus]

Hi Olivier,

Olivier Berger  writes:

> Just a minor bug; I think. The W3C validator complains that the document
> is invalid for the  which is nenerated when there's a #+SUBTITLE: :
>
>   end tag for "br" omitted, but OMITTAG NO was specified
>   
>   You may have neglected to close an element, or perhaps you meant to
> "self-close" an element, that is, ending it with "/>" instead of ">".
>
> This is problematic at least for #+HTML_DOCTYPE: xhtml-strict.

You are right.  It should be fixed now.

Rasmus

-- 
El Rey ha muerto. ¡Larga vida al Rey!

[O] Subtitles in HTML export render document invalid

[Olivier Berger]

Hi.

Just a minor bug; I think. The W3C validator complains that the document
is invalid for the  which is nenerated when there's a #+SUBTITLE: :

  end tag for "br" omitted, but OMITTAG NO was specified
  
  You may have neglected to close an element, or perhaps you meant to 
"self-close" an element, that is, ending it with "/>" instead of ">".

This is problematic at least for #+HTML_DOCTYPE: xhtml-strict.

Hope this helps,

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

[Phillip Lord]

Tim Cross  writes:

>> 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.

Emacs builds all its lisp with a single Makefile, but the build is
incremental. So the rebuild is very quick. To be honest, even if you
modify the C layer, the dump is pretty fast.


> 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


This makes the assumption that all of org moves at the same speed. It
seems to me that the things currently in contrib still move fairly fast.

Phil

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

[Phillip Lord]

Tim Cross  writes:

> 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. 


I've argued on emacs-devel about this. The problem here is that the
distributed org-mode remains in the load path, so you are totally
dependent on load path shadowing to ensure the right package gets
loaded. This doesn't happen with ELPA packages since only the latest
gets added to the load path.

My solution to this would be to have Emacs use package.el to load
files in core as well as elsewhere. Then, when you installed org from
ELPA, package.el would remove the core installed files from the
load-path (or rather never add them). You'd need to restart Emacs after
installation, but otherwise the problem goes away.

Everybody else thought this was a bad idea!

Phil

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

[Phillip Lord]

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.
>
> 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.


Yes, it would appear that way. But, at the moment, to be distributed
with Emacs you have to be in the emacs repo. We've discussed this
before, I know, but these two things are not an absolute
necessity. Having the Emacs build populate it's source tree with
packages is also possible.

Phil

Re: [O] org babel, ess, R

[Vikas Rawal]

>> 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).

This is neat. Solves my problem.

Thanks.

Vikas

Re: [O] :noweb & library of babel

[Eric S Fraga]

On Monday,  3 Jul 2017 at 18:58, ed...@openmail.cc wrote:
> 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:

[...]

> - [-] 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 may be wrong but I thought that the library of babel provides a means
of calling (#+CALL: or inline) the codes in the library but not
necessarily use noweb to include them in other codes?

-- 
: Eric S Fraga via Emacs 26.0.50, Org release_9.0.9-573-g09e612


signature.asc
Description: PGP signature

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

[Pierre-Henry F.]

Great! It just works!

Sent with [ProtonMail](https://protonmail.com) Secure Email.

>  Original Message 
> Subject: Re: Bug: Clock table reports wrong data [9.0.9]
> Local Time: July 4, 2017 12:20 AM
> UTC Time: July 3, 2017 10:20 PM
> From: m...@nicolasgoaziou.fr
> To: Pierre-Henry F. 
> emacs-orgmode\@gnu.org 
> 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

[Bastien Guerry]

Hi Robert,

first of all, my bad: what I should have said in all these discussion
is that any decision regarding moving Org to Emacs' core won't happen
any time soon (I'd say two or three years).

Keeping Emacs master branch in sync with Org maint branch is not a
problem anymore, so the decision of whether Org should go into Emacs
core will not depend on this.

And by the time the decision will be made, I expect Emacs and Org
release cycles will come close.  In other words: when Org will be as
stable as Emacs and when most of Org's development will happen in its
external modules, it will be time to move Org's development to Emacs.

But all this is very hypothetical, right now very much "bikeshed" :)

Best,

-- 
 Bastien

Re: [O] Emacs master now updated to Org 9.0.9

[Bastien Guerry]

Indeed, thanks to you and to everyone involved.

I'm very grateful everyone has been patiently baring
with me for this task.

-- 
 Bastien

Re: [O] Upstream synchronization documentation

[Rasmus]

Hi,

Thanks for the comments.

>   -- 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

That's better.

>> +- =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?

Yes, indeed.  Thanks.

>> +** Outdated notes
>
> Instead of creating this heading, should we just delete the outdated
> notes?

Deleting is fine by me.  I don't know if it is useful to anyone else.
Probably not.

Rasmus

--
⠠⠵
>From 556c2937abc5b3fe0f5b9e8861a30aef748215cc 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 | 70 +++
 1 file changed, 66 insertions(+), 4 deletions(-)

diff --git a/README_maintainer b/README_maintainer
index 6b162aa52..60821059c 100644
--- a/README_maintainer
+++ b/README_maintainer
@@ -88,9 +88,71 @@ 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
+Sometimes Emacs maintainers make changes to Org files.  The process of
+propagating the changes back to the Org repository is called
+/backporting/ for historical reasons.
+
+To check for changes that needs to be backported from the Emacs
+repository, one can use the following =git= command, courtesy of [[http://permalink.gmane.org/gmane.emacs.devel/215861][Kyle
+Meyer]],
+#+begin_src shell
+  git log $rev..origin/emacs-25 -- 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
+#+end_src
+where =$rev= is the last commit from the =emacs-25= branch that was
+backported.  The should also be done for the =master= branch.
+
+One may also use Atom feeds to keep track of upstream changes,
+e.g. [[http://git.savannah.gnu.org/cgit/emacs.git/atom/lisp/org/][this feed]] show changes to the =lisp/org= folder.
+** 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~ 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 +162,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 

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

[Rasmus]

Sharon Kimble  writes:

> 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.

But you can refer to them.  E.g.:

** Disclaimer
:PROPERTIES:
:CUSTOM_ID: foo
:END:

See [[*Disclaimer]] or [[#foo]]


-- 
Er du tosset for noge' lårt!