Org merge

Org merge

[Bastien]

I'm about to merge Org 8.2.2 with Emacs trunk.

The (big) diff is here:
http://bzg.fr/u/emacs-org-mode_09112013.diff

The ChangeLog for Elisp code:
http://bzg.fr/u/ChangeLog_emacs-org-lisp-09112013.txt

and that of the .texi manual:
http://bzg.fr/u/ChangeLog_emacs-org-texi-09112013.txt

I spent time cleaning up those files as much as possible, but I'm sure
there is more to do.

One question: if e.g. org-latex.el has been fully rewritten and
renamed ox-latex.el, shall we ignore changes that happen after the
rewrite and only say something like 

  * org-latex.el: Delete.
  * ox-latex.el: Renamed and rewritten from org-latex.el

?  This would spare a lot of lines, as there were several of such
rewrites.

Thanks,

-- 
 Bastien

Re: Org merge

[Stefan Monnier]

> One question: if e.g. org-latex.el has been fully rewritten and
> renamed ox-latex.el, shall we ignore changes that happen after the
> rewrite and only say something like 

>   * org-latex.el: Delete.
>   * ox-latex.el: Renamed and rewritten from org-latex.el

If the two are completely different, then yes,or:

   * org-latex.el: Delete.
   * ox-latex.el: New file, to replace it.


-- Stefan

Re: Org merge

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> One question: if e.g. org-latex.el has been fully rewritten and
>> renamed ox-latex.el, shall we ignore changes that happen after the
>> rewrite and only say something like 
>
>>   * org-latex.el: Delete.
>>   * ox-latex.el: Renamed and rewritten from org-latex.el
>
> If the two are completely different, then yes,or:
>
>    * org-latex.el: Delete.
>    * ox-latex.el: New file, to replace it.

Thanks.

Generally, the functions are completely different, but most
of the options are the same.

PS: I'll also patch etc/ORG-NEWS:
http://orgmode.org/cgit.cgi/org-mode.git/tree/etc/ORG-NEWS

-- 
 Bastien

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> most of the options are the same.
  ^^^^

It is difficult to say what you have in mind there.

The diff you posted doesn't include the exporters.  But from the diff of
.texi file, I see things like

-@vindex org-export-html-preamble
-@vindex org-export-html-postamble
+@vindex org-html-preamble
+@vindex org-html-postamble

The changes in prefixes are a rule rather than an exception.  i.e., it
is all over.  Many variables have been removed and new ones introduced.

Some exporters have been removed, docbook, freemind etc.

Re: Org merge

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> most of the options are the same.
>   ^^^^
>
> It is difficult to say what you have in mind there.

Sorry, I should have been clearer: what I meant is that, while most
Org>8.0 exporters functions structurally changed compared to their
Org<7.9.3f ancestors (because of the use of a new export engine), most
options have only seen a change in their name, not in their content or
meaning.  Some options have been deleted and others added.

So I guess a proper ChangeLog would document deleted options and new
ones.  This is tiresome, but can be done.  What is difficult is to
document new fonctions: I guess it's fine to document new functions
that add new_features_ while leaving aside functions that are new but
are only part of the new exporter machinery, since the use of this
new machinery is part of the rewriting.

Does it seem a reasonable course of action?

-- 
 Bastien

Re: Org merge

[Stefan Monnier]

> Sorry, I should have been clearer: what I meant is that, while most
Org> 8.0 exporters functions structurally changed compared to their
> Org<7.9.3f ancestors (because of the use of a new export engine), most
> options have only seen a change in their name, not in their content or
> meaning.  Some options have been deleted and others added.

The NEWS file should explain how the options have been changed, but the
ChangeLog is only concerned about the actual code.  From what you say,
it seems to actual code shares no history with the previous code (a bit
like a "clean room" reimplementation), so the ChangeLog doesn't need to
explain the changes.

> What is difficult is to document new fonctions:

The usual course of action for new functions is to describe them in
ChangeLog as:

    (foo, bar, baz): New function.

so other than enumerating them, there's nothing to do.


        Stefan

Re: Org merge

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> The NEWS file should explain how the options have been changed, but the
> ChangeLog is only concerned about the actual code.  From what you say,
> it seems to actual code shares no history with the previous code (a bit
> like a "clean room" reimplementation), so the ChangeLog doesn't need to
> explain the changes.

Okay, thanks.

>> What is difficult is to document new fonctions:
>
> The usual course of action for new functions is to describe them in
> ChangeLog as:
>
>     (foo, bar, baz): New function.
>
> so other than enumerating them, there's nothing to do.

Yes -- my point was that some functions that are currently listed as
"new functions" in the Changelog I posted are part of the clean room
implementation, others are new functions corresponding to new
features.  I will clean up the Changelog to only document the latter.

Then I'll repost the patch just to make sure applying it is fine.

Best,

-- 
 Bastien

Re: Org merge

[Stefan Monnier]

> Yes -- my point was that some functions that are currently listed as
> "new functions" in the Changelog I posted are part of the clean room
> implementation, others are new functions corresponding to new
> features.  I will clean up the Changelog to only document the latter.

The ChangeLog doesn't need to distinguish between the two.


        Stefan

Re: Org merge

[Stephen J. Turnbull]

Bastien writes:

 > > The usual course of action for new functions is to describe them in
 > > ChangeLog as:
 > >
 > >     (foo, bar, baz): New function.
 > >
 > > so other than enumerating them, there's nothing to do.
 > 
 > Yes -- my point was that some functions that are currently listed as
 > "new functions" in the Changelog I posted are part of the clean room
 > implementation, others are new functions corresponding to new
 > features.  I will clean up the Changelog to only document the
 > latter.

No, the point of the ChangeLog entry is to make it straightforward to
find out what identifiers (functions and variables) are new (for
review at the time of integration), and when they were introduced (for
context in debugging and study later).

You should list all new global identifiers (functions and variables).
It's not necessary (although some projects prefer to do so) to
document the functionality added in the ChangeLog -- the docstring or
comment in the code does that for developers, and NEWS does it in
cases where the new identifier is something that users use.

N.B. Making such a list is something that can't be done (at least not
trivially) with the VCS itself; the developer has to do it mostly by hand.

Steve

Re: Org merge

[Bastien]

Bastien <bzg@gnu.org> writes:

> Then I'll repost the patch just to make sure applying it is fine.

Here it is:

http://bzg.fr/u/emacs_org_diff_11112013.patch.txt

-- 
 Bastien

Re: Org merge

[Bastien]

Bastien <bzg@gnu.org> writes:

> http://bzg.fr/u/emacs_org_diff_11112013.patch.txt

I merged Org 8.2.3a into Emacs -- now you can fire back with
proofreading and the usual clean up... hope there is not a lot.

Thanks!

-- 
 Bastien

Re: Org merge

[Michael Albinus]

Bastien <bzg@gnu.org> writes:

> Bastien <bzg@gnu.org> writes:
>
>> http://bzg.fr/u/emacs_org_diff_11112013.patch.txt
>
> I merged Org 8.2.3a into Emacs -- now you can fire back with
> proofreading and the usual clean up... hope there is not a lot.

Compiling org/org-docbook.el

In toplevel form:
org/org-docbook.el:76:1:Error: Cannot open load file: no such file or
directory, org-exp
make[2]: *** [org/org-docbook.elc] Error 1
make[2]: Leaving directory `/usr/local/src/emacs/lisp'
make[1]: *** [compile-main] Error 2
make[1]: Leaving directory `/usr/local/src/emacs/lisp'
make: *** [lisp] Error 2

> Thanks!

Best regards, Michael.

Re: Org merge

[Bastien]

Michael Albinus <michael.albinus@gmx.de> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Bastien <bzg@gnu.org> writes:
>>
>>> http://bzg.fr/u/emacs_org_diff_11112013.patch.txt
>>
>> I merged Org 8.2.3a into Emacs -- now you can fire back with
>> proofreading and the usual clean up... hope there is not a lot.
>
> Compiling org/org-docbook.el

I removed this file, it is not in Org 8.2.3 anymore.

Thanks!

-- 
 Bastien

Re: Org merge

[Michael Albinus]

Bastien <bzg@gnu.org> writes:

> I removed this file, it is not in Org 8.2.3 anymore.

Compiling org/org-taskjuggler.el

In toplevel form:
org/org-taskjuggler.el:157:1:Error: Cannot open load file: no such file
or directory, org-exp
make[2]: *** [org/org-taskjuggler.elc] Error 1
make[2]: Leaving directory `/usr/local/src/emacs/lisp'
make[1]: *** [compile-main] Error 2
make[1]: Leaving directory `/usr/local/src/emacs/lisp'
make: *** [lisp] Error 2

> Thanks!

Best regards, Michael.

Re: Org merge

[Bastien]

Michael Albinus <michael.albinus@gmx.de> writes:

> Bastien <bzg@gnu.org> writes:
>
>> I removed this file, it is not in Org 8.2.3 anymore.
>
> Compiling org/org-taskjuggler.el
>
> In toplevel form:
> org/org-taskjuggler.el:157:1:Error: Cannot open load file: no such
> file

Removed too... thanks!

-- 
 Bastien

Re: Org merge

[Nathan Trapuzzano]

Bastien <bzg@gnu.org> writes:

> I merged Org 8.2.3a into Emacs -- now you can fire back with
> proofreading and the usual clean up... hope there is not a lot.

In toplevel form:
org/ob.el:30:1:Error: Cannot open load file: no such file or directory, org-exp-blocks
Makefile:267: recipe for target 'org/ob.elc' failed
make[2]: *** [org/ob.elc] Error 1
make[2]: Leaving directory '/home/nathan/opt/etc/bzr-repos/emacs/trunk/lisp'
Makefile:295: recipe for target 'compile-main' failed
make[1]: *** [compile-main] Error 2
make[1]: Leaving directory '/home/nathan/opt/etc/bzr-repos/emacs/trunk/lisp'
Makefile:378: recipe for target 'lisp' failed
make: *** [lisp] Error 2

Re: Org merge

[Stefan Monnier]

> In toplevel form:
> org/ob.el:30:1:Error: Cannot open load file: no such file or directory, org-exp-blocks
> Makefile:267: recipe for target 'org/ob.elc' failed
> make[2]: *** [org/ob.elc] Error 1

You probably need to "make -k" a few times, or "make bootstrap".


        Stefan

Re: Org merge

[Jambunathan K]

Nathan Trapuzzano <nbtrap@nbtrap.com> writes:

> In toplevel form:
> org/ob.el:30:1:Error: Cannot open load file: no such file or directory, org-exp-blocks

rm *.elc files from org directory and make.  That's what I did right now.

Re: Org merge

[Jambunathan K]

In the new exporters, some defcustoms have no :version properties or
they reflect old values.  

Some samples here.  Not an exhaustive list.

(defcustom org-html-text-markup-alist nil
  :group 'org-export-html
  :type '(alist :key-type (symbol :tag "Markup type")
		:value-type (string :tag "Format string"))
  :options '(bold code italic strike-through underline verbatim))


(defcustom org-odt-prettify-xml nil
  :group 'org-export-odt
  :version "24.1" 
            ^^^^
            ^^^^
            ^^^^ 
  :type 'boolean)

Re: Org merge

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> In the new exporters, some defcustoms have no :version properties or
> they reflect old values.  

I've done some fixes in this area in Org's git repo, thanks.

-- 
 Bastien

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

>> In the new exporters, some defcustoms have no :version properties or
>> they reflect old values.  
>
> I've done some fixes in this area in Org's git repo, thanks.

Thanks for immediately responding to my request.

The :version property is an Emacs version right?  It says 8.0 and 24.1
and numerous places.

http://orgmode.org/w/?p=org-mode.git;a=commitdiff;h=369f70ac288099b9e2c8158ffa4b4dd2871ecba3

Re: Org merge

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>>> In the new exporters, some defcustoms have no :version properties or
>>> they reflect old values.  
>>
>> I've done some fixes in this area in Org's git repo, thanks.
>
> Thanks for immediately responding to my request.
>
> The :version property is an Emacs version right?  It says 8.0 and 24.1
> and numerous places.

There was some erroneous :version "8.0" lines, I fixed those in Org's
git maint branch, it will be in the next merge.

But I don't see any occurrence of
  
  :version "24.1"
  :package-version '(Org . "8.0")

Do you?

Thanks,

-- 
 Bastien

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> But I don't see any occurrence of
>   
>   :version "24.1"
>   :package-version '(Org . "8.0")
>
> Do you?

Some defcustoms are still not OK both on maint and master.

Re: Org merge

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> But I don't see any occurrence of
>>   
>>   :version "24.1"
>>   :package-version '(Org . "8.0")
>>
>> Do you?
>
> Some defcustoms are still not OK both on maint and master.

Can you be more specific?

-- 
 Bastien

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> Can you be more specific?

:version values are still wrong.

Re: Org merge

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Can you be more specific?
>
> :version values are still wrong.

Sorry, I don't get it.

What :version values are wrong?

-- 
 Bastien

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> What :version values are wrong?

defcustom's.

Re: Org merge

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> What :version values are wrong?
>
> defcustom's.

Last try: can you point what are the defcustoms for which you think
that :version and/or :package-version is wrong?

-- 
 Bastien

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> Last try: can you point what are the defcustoms for which you think
> that :version and/or :package-version is wrong?

M-x occur :version

I pointed to the files already.

Re: Org merge

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Last try: can you point what are the defcustoms for which you think
>> that :version and/or :package-version is wrong?
>
> M-x occur :version
>
> I pointed to the files already.

You may be confused.  There are options with :version "24.1" because
they were already in Emacs >= 24.1.  None of these options have a
wrong :package-version in Org's git repo, which will be merged with
Emacs repo soon again.

-- 
 Bastien

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> There are options with :version "24.1" because they were already in
> Emacs >= 24.1.

The whole ox-odt.el is new.   So are the options in it.

Re: Org merge

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> There are options with :version "24.1" because they were already in
>> Emacs >= 24.1.
>
> The whole ox-odt.el is new.   So are the options in it.

ox-odt.el is a rewrite of org-odt.el, some options are new,
some are in org-odt.el already.  Please let me know if you
find a new options in ox-odt.el that was not in org-odt.el
and that needs a fix for its :version and :package-version
properties.

Thanks,

-- 
 Bastien

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> ox-odt.el is a rewrite of org-odt.el, some options are new,
> some are in org-odt.el already.

Stop lecturing to me about ox-odt.el or ox-html.el.  90% of letters
there are typed by fingers.

All options are new.  That's what I am saying.

Re: Org merge

[Bastien]

Jambunathan K <kjambunathan@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> ox-odt.el is a rewrite of org-odt.el, some options are new,
>> some are in org-odt.el already.
>
> Stop lecturing to me about ox-odt.el or ox-html.el.  90% of letters
> there are typed by fingers.
>
> All options are new.  That's what I am saying.

You are 60% wrong.

Here is a table showing the list of options -- the one on the top
are the ones that are new in Org >8.0.  The one at the bottom are
the ones that were already in Emacs and Org 7.9.3, although they
were named with the org-export-odt prefix.

| Option (defcustom)                           | Org version |
|----------------------------------------------+-------------|
| org-odt-display-outline-level 2              |         8.0 |
| org-odt-format-drawer-function nil           |         8.0 |
| org-odt-format-headline-function nil         |         8.0 |
| org-odt-format-inlinetask-function nil       |         8.0 |
| org-odt-inline-formula-rules                 |         8.0 |
| org-odt-inline-image-rules                   |         8.0 |
| org-odt-use-date-fields nil                  |         8.0 |
| org-odt-with-latex org-export-with-latex     |         8.0 |
|----------------------------------------------+-------------|
| org-odt-content-template-file nil            |       7.9.3 |
| org-odt-convert-capabilities                 |       7.9.3 |
| org-odt-convert-process "LibreOffice"        |       7.9.3 |
| org-odt-convert-processes                    |       7.9.3 |
| org-odt-create-custom-styles-for-srcblocks t |       7.9.3 |
| org-odt-fontify-srcblocks t                  |       7.9.3 |
| org-odt-pixels-per-inch 96.0                 |       7.9.3 |
| org-odt-preferred-output-format nil          |       7.9.3 |
| org-odt-prettify-xml nil                     |       7.9.3 |
| org-odt-schema-dir                           |       7.9.3 |
| org-odt-styles-file nil                      |       7.9.3 |
| org-odt-table-styles                         |       7.9.3 |

-- 
 Bastien

Re: Org merge

[Andreas Schwab]

Jambunathan K <kjambunathan@gmail.com> writes:

> The whole ox-odt.el is new.   So are the options in it.

Not if they retained their meaning and value.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> the one on the top are the ones that are new in Org >8.0.  The one at
> the bottom are the ones that were already in Emacs and Org 7.9.3,

We are talking about :version and NOT the version of Org.  Your data is
totally irrelevant.

> although they were named with the org-export-odt prefix.
                                    ^^^^^^^^^^^^^^ 

Set up an obsolete alias or fix the :version or do something else.
Choice is yours. This has to happen in ALL the exporters and not just
the ODT exporter.

There is no `org-odt-content-template-file' in Emacs 24.1.

If you claim that ONLY variables' prefix has changed and not their
default value or interpretation, I am willing to argue that out with
specific examples.

Jambunathan K.

Re: Org merge

[Jambunathan K]

Andreas Schwab <schwab@suse.de> writes:

> Not if they retained their meaning and value.

Variables are on new prefix. If they aren't aliased they are NEW
variables entirely.

Marked portion below means implies discontinuity and not backward
compatibility.

As some one who is familiar with ox-html.el, I KNOW for sure that
aliasing simply will not work for some variables.  This is because their
default values have changed or new interepretation introduced.

I will not comment on variables in ox.el.  Nicolas has done an all out
re-implementation.  In some cases, he might have retained the name but
added new interpretation.  (It is better to check with him.)

It is safe to add a :version of 24.4 to all variables rather than audit
each variable to see for their backward compatibility.

,---- From line 232 of etc/ORG-NEWS
| If you customized an export back-end (like HTML or LaTeX), you will need
| to rename some options so that your customization is not lost.
     ^^^^^^^^^^^^^^^^^^^                            ^^^^^^^^^^^     
| Typically, an option starting with =org-export-html-= is now named
| =org-html-=.  See the manual for details and check
| [[http://orgmode.org/worg/org-8.0.html][this Worg page]] for directions.
`----

Re: Org merge

[Bastien]

I'm not willing to argue about anything.

Please point me at specific problems this:

  "At line X in file Y :version should be Z because of ..."

Evasive and peremptory advice does not help.

-- 
 Bastien

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> I'm not willing to argue about anything.

You are not willing to do what is required.  Plain and simple.

Re: Org merge

[Jambunathan K]

Bastien <bzg@gnu.org> writes:

> I'm not willing to argue about anything.

bug#15896

Re: Org merge

[Eli Zaretskii]

> From: Jambunathan K <kjambunathan@gmail.com>
> Date: Thu, 14 Nov 2013 22:33:27 +0530
> Cc: emacs-devel@gnu.org
> 
> Bastien <bzg@gnu.org> writes:
> 
> > I'm not willing to argue about anything.
> 
> bug#15896

Closed.

Please stop wasting everyone's time.  You were told very clearly that
this is not a bug.

Re: Org merge

[Jambunathan K]

Eli Zaretskii <eliz@gnu.org> writes:

> You were told very clearly that this is not a bug.

Why?  What part of my argument is wrong?  "Being told" is NOT doing "due
diligence".

   M-x customize-changed 

is how I explore new options and features.  It is an Emacs facility to
help users find out what they need to do.

It doesn't work for the new exporters.  Why is this bug closed forcibly.