initial nxml merge

initial nxml merge

[Mark A. Hershberger]

I have just merged a minimally tested nXML.  I merged all the
char-name/unicode/*.el files for now because, while this information is
in the unicode branch, it isn't in HEAD.  That still needs to be sorted
out.

-- 
http://hexmode.com/
GPG Fingerprint: 7E15 362D A32C DFAB E4D2  B37A 735E F10A 2DFC BFF5

The most beautiful experience we can have is the mysterious.
    -- Albert Einstein, The World As I See it

Re: initial nxml merge

[Vinicius Jose Latorre]

Mark A. Hershberger wrote:
> I have just merged a minimally tested nXML.  I merged all the
> char-name/unicode/*.el files for now because, while this information is
> in the unicode branch, it isn't in HEAD.  That still needs to be sorted
> out.
>   

I've just updated CVS trunk and unicode branchs.

The nXML was merged in the CVS trunk instead of unicode branch.

Re: initial nxml merge

[Mark A. Hershberger]

Vinicius Jose Latorre <viniciusjl@ig.com.br> writes:

> Mark A. Hershberger wrote:
>> I have just merged a minimally tested nXML.  I merged all the
>> char-name/unicode/*.el files for now because, while this information is
>> in the unicode branch, it isn't in HEAD.  That still needs to be sorted
>> out.
>
> The nXML was merged in the CVS trunk instead of unicode branch.

Right.  Sorry for the confusion.

-- 
http://hexmode.com/
GPG Fingerprint: 7E15 362D A32C DFAB E4D2  B37A 735E F10A 2DFC BFF5

The most beautiful experience we can have is the mysterious.
    -- Albert Einstein, The World As I See it

Re: initial nxml merge

[Romain Francoise]

mah@everybody.org (Mark A. Hershberger) writes:

> I have just merged a minimally tested nXML.  I merged all the
> char-name/unicode/*.el files for now because, while this
> information is in the unicode branch, it isn't in HEAD.  That
> still needs to be sorted out.

Thanks.  A few integration notes:

 * The nXML manual belongs in doc/misc, not in doc/emacs.  You
   probably want to adjust @setfilename to output the info file in
   the info/ top-level directory, and enable compilation of the file
   in the doc/misc Makefile.

 * The NEWS file should not be in lisp/nxml, but in etc/.  See
   GNUS-NEWS, ERC-NEWS, etc.  The README and TODO files can just be
   removed, I think.

 * The subdirs.el files should be generated, not committed in CVS.

Re: initial nxml merge

[Stefan Monnier]

>  * The NEWS file should not be in lisp/nxml, but in etc/.

Seeing how there's been no NEWS since 2004, I think we can just throw
it away.

>    See GNUS-NEWS, ERC-NEWS, etc.  The README and TODO files can just
>    be removed, I think.

The content of the README should be moved to nxml-mode.el's commentary
section, etc/NEWS, and nxml's Texinfo doc.

I'd normally suggest to move the contents of the TODO file to either
etc/TODO or to the commentary sections of the relevant foo.el files, but
it is so ridiculously large that I have no idea what to do with it.

>  * The subdirs.el files should be generated, not committed in CVS.

I just removed them.

Also the test.<foo>.xml files should be moved to somewhere in `etc'.

And of course the unicode subdir needs to be moved elsewhere and merged
with the emacs-unicode info, but that we knew it already.


        Stefan

Re: initial nxml merge

[Mark A. Hershberger]

Romain Francoise <romain@orebokech.com> writes:

>  * The nXML manual belongs in doc/misc, not in doc/emacs.  You
>    probably want to adjust @setfilename to output the info file in
>    the info/ top-level directory, and enable compilation of the file
>    in the doc/misc Makefile.

Done.

>  * The NEWS file should not be in lisp/nxml, but in etc/.  See
>    GNUS-NEWS, ERC-NEWS, etc.  The README and TODO files can just be
>    removed, I think.

Done.  Kept the TODO since there are some interesting things in there
that seem to be worth implementing.

>  * The subdirs.el files should be generated, not committed in CVS.

Removed.

Thanks!

-- 
http://hexmode.com/
GPG Fingerprint: 7E15 362D A32C DFAB E4D2  B37A 735E F10A 2DFC BFF5

The most beautiful experience we can have is the mysterious.
    -- Albert Einstein, The World As I See it

Re: initial nxml merge

[David Kastrup]

mah@everybody.org (Mark A. Hershberger) writes:

> Romain Francoise <romain@orebokech.com> writes:
>
>>  * The nXML manual belongs in doc/misc, not in doc/emacs.  You
>>    probably want to adjust @setfilename to output the info file in
>>    the info/ top-level directory, and enable compilation of the file
>>    in the doc/misc Makefile.
>
> Done.
>
>>  * The NEWS file should not be in lisp/nxml, but in etc/.  See
>>    GNUS-NEWS, ERC-NEWS, etc.  The README and TODO files can just be
>>    removed, I think.
>
> Done.  Kept the TODO since there are some interesting things in there
> that seem to be worth implementing.
>
>>  * The subdirs.el files should be generated, not committed in CVS.
>
> Removed.

It would appear that rnc-auto.el contains versioning and possibly other
information important to the operation of nxml-mode.  But since the
autoloads of nxml-mode are now imported into Emacs, rnc-auto.nl is
probably never loaded normally.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: initial nxml merge

[Glenn Morris]

Mark A. Hershberger wrote:

> I have just merged a minimally tested nXML. 

Please could you add 2007 to all the copyright years, and change the
license notices to be the same as the other Emacs files (GPL >= v3,
correct address for FSF, etc). Thanks.

Re: initial nxml merge

[Richard Stallman]

    I have just merged a minimally tested nXML.  I merged all the
    char-name/unicode/*.el files for now because, while this information is
    in the unicode branch, it isn't in HEAD.

Is clear that the char-name/unicode/* files are not needed in
unicode-2?

If so, let's delete them now from the trunk.  We're not going to make
a release before merging in unicode-2.

Re: initial nxml merge

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I have just merged a minimally tested nXML.  I merged all the
>     char-name/unicode/*.el files for now because, while this information is
>     in the unicode branch, it isn't in HEAD.
>
> Is clear that the char-name/unicode/* files are not needed in
> unicode-2?
>
> If so, let's delete them now from the trunk.  We're not going to make
> a release before merging in unicode-2.

The trunk is our testbed.  We don't want to have an extended time window
with broken and unfixable code in it.  Let us delete them when the merge
is done, or at least when it is immediately imminent.

Otherwise, people won't be able to use any version of nxml-mode until
unicode-2 is merged.  In that case, we are better off removing nxml-mode
altogether for now in the trunk rather than keep a non-operative version
for an extended duration.  It can still be placed in unicode-2 now if it
is expected to work there.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: initial nxml merge

[Richard Stallman]

    Otherwise, people won't be able to use any version of nxml-mode until
    unicode-2 is merged.

Does most use of nxml-mode depend on that data, or is it a special feature?

Re: initial nxml merge

[Dan Nicolaescu]

mah@everybody.org (Mark A. Hershberger) writes:

  > I have just merged a minimally tested nXML.  I merged all the
  > char-name/unicode/*.el files for now because, while this information is
  > in the unicode branch, it isn't in HEAD.  That still needs to be sorted
  > out.

Could you please fix the byte compile warnings?  We are trying to
eliminate all the byte compiler warnings.
The free variable and defsubst warnings have been fixed in the rest of
emacs code.  
Also it looks like all the the char-name/unicode/*.el files need a 
(declare-function nxml-define-char-name-set at the start.

Thanks

        --dan

What happened to (defun x)? (was: initial nxml merge)

[David Kastrup]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> mah@everybody.org (Mark A. Hershberger) writes:
>
>   > I have just merged a minimally tested nXML.  I merged all the
>   > char-name/unicode/*.el files for now because, while this information is
>   > in the unicode branch, it isn't in HEAD.  That still needs to be sorted
>   > out.
>
> Could you please fix the byte compile warnings?  We are trying to
> eliminate all the byte compiler warnings.
> The free variable and defsubst warnings have been fixed in the rest of
> emacs code.  
> Also it looks like all the the char-name/unicode/*.el files need a 
> (declare-function nxml-define-char-name-set at the start.

I might have missed the discussion: pre-22 we had considered having
(defun nxml-define-char-name-set)
be a byte-compiler silencer in the same manner as
(defvar preview-version)
is a byte-compiler silencer.  The obvious advantage over
"declare-function" is that one does not need to remember another idiom
and name.

Is there a particular advantage for a separate declare-function that I
just am not able to see?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What happened to (defun x)?

[martin rudalics]

 > I might have missed the discussion: pre-22 we had considered having
 > (defun nxml-define-char-name-set)
 > be a byte-compiler silencer in the same manner as
 > (defvar preview-version)
 > is a byte-compiler silencer.  The obvious advantage over
 > "declare-function" is that one does not need to remember another idiom
 > and name.
 >
 > Is there a particular advantage for a separate declare-function that I
 > just am not able to see?

It's a question of strong vs weak type-checking.  The advantage of
strong type-checking is to catch errors sooner - in the special case
because a particular file fails to define a declared function.  Its
disadvantage is that you can no more move a defun to another file
without finding and changing all files that have a declaration for it.

Re: What happened to (defun x)?

[David Kastrup]

martin rudalics <rudalics@gmx.at> writes:

>> I might have missed the discussion: pre-22 we had considered having
>> (defun nxml-define-char-name-set)
>> be a byte-compiler silencer in the same manner as
>> (defvar preview-version)
>> is a byte-compiler silencer.  The obvious advantage over
>> "declare-function" is that one does not need to remember another idiom
>> and name.
>>
>> Is there a particular advantage for a separate declare-function that I
>> just am not able to see?
>
> It's a question of strong vs weak type-checking.  The advantage of
> strong type-checking is to catch errors sooner - in the special case
> because a particular file fails to define a declared function.  Its
> disadvantage is that you can no more move a defun to another file
> without finding and changing all files that have a declaration for it.

Couldn't an autoload declaration be made to achieve the same effect?  It
specifies function and file, too.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What happened to (defun x)?

[martin rudalics]

 > Couldn't an autoload declaration be made to achieve the same effect?  It
 > specifies function and file, too.

I'm not sure whether that would be more convenient.  The basic problem
is that defuns get more "static" now - people will hesitate more often
before moving a defun from one file to another because they have to
think of all the files they have to change on top of that.  Merging code
from different versions will become a problem when definitions have
moved.

But I have to admit that - as a _reader_ of Elisp code - I had wanted a
`declare-variable' as well.  Often when I encounter a (defvar foo) I
have to think twice whether that's a variable defined elsewhere or
simply a lazy attitude of a writer who didn't want to provide an initial
value.

Re: What happened to (defun x)?

[Dan Nicolaescu]

David Kastrup <dak@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > mah@everybody.org (Mark A. Hershberger) writes:
  > >
  > >   > I have just merged a minimally tested nXML.  I merged all the
  > >   > char-name/unicode/*.el files for now because, while this information is
  > >   > in the unicode branch, it isn't in HEAD.  That still needs to be sorted
  > >   > out.
  > >
  > > Could you please fix the byte compile warnings?  We are trying to
  > > eliminate all the byte compiler warnings.
  > > The free variable and defsubst warnings have been fixed in the rest of
  > > emacs code.  
  > > Also it looks like all the the char-name/unicode/*.el files need a 
  > > (declare-function nxml-define-char-name-set at the start.
  > 
  > I might have missed the discussion: pre-22 we had considered having
  > (defun nxml-define-char-name-set)
  > be a byte-compiler silencer in the same manner as
  > (defvar preview-version)
  > is a byte-compiler silencer.  The obvious advantage over
  > "declare-function" is that one does not need to remember another idiom
  > and name.
  > 
  > Is there a particular advantage for a separate declare-function that I
  > just am not able to see?

`declare-function' was the result of a long, long discussion on this
list. Please read that discussion and the reasons this design was chosen
before restarting the same discussion again. At least restart the
discussion from an informed position.

Re: What happened to (defun x)?

[Jay Belanger]

Dan Nicolaescu <dann@ics.uci.edu> writes:
...
> `declare-function' was the result of a long, long discussion on this
> list. Please read that discussion and the reasons this design was chosen
> before restarting the same discussion again. At least restart the
> discussion from an informed position.

I missed that; what was the title of the thread?  
(I did check; I looked for "declare-function," but the only long thread
about it that I found was "suppressing byte-compiler warnings about
undefined functions".  It wasn't that long and didn't seem to address
David's question, so perhaps I can't find the discussion or I'm simply
missing something.)

Jay