reliably determining if an Info node is an index

reliably determining if an Info node is an index

[Karl Berry]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1194 bytes --]

Back in June 2003, we discussed methods for reliably determining if an
Info node is an index node.  This is to make the ][ commands work
better, among other reasons.  See this message from Luc and the
containing thread for background:
http://mail.gnu.org/archive/html/emacs-devel/2003-06/msg00657.html

Our conclusion was that the best approach would be for makeinfo to write
a magic cookie indicating "this is an index" into index nodes.

We are now approaching the next Texinfo release.  Here is my question:
is the collective wisdom that I should write this cookie now, before an
Emacs release has been made that supports it?  Or should I wait?

If  a user reads an Info file with the cookie when Emacs doesn't support
it, it will be displayed, thus:
^@^H[index^@^H]
(except with real control characters).  This does no harm, but I can see
users being confused or thinking it is a bug if they see it.

It doesn't matter to me.

I'll attach an example info file with the cookie.  It also shows the
(line NNN) feature for precisely locating index entries that we
discussed in another thread.  I hope someone will be able to work on
using the line numbers in the Emacs Info reader.

Thanks,
k


[-- Attachment #2: indexcookie.info --]
[-- Type: application/octet-stream, Size: 540 bytes --]

[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: reliably determining if an Info node is an index

[Richard Stallman]

    We are now approaching the next Texinfo release.  Here is my question:
    is the collective wisdom that I should write this cookie now, before an
    Emacs release has been made that supports it?  Or should I wait?

I think the time to add it is now.  But isn't this a rather ugly way
to do it?

   

Re: reliably determining if an Info node is an index

[Karl Berry]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1085 bytes --]

        We are now approaching the next Texinfo release.  Here is my question:
        is the collective wisdom that I should write this cookie now, before an
        Emacs release has been made that supports it?  Or should I wait?

    I think the time to add it is now.  

Ok, I will.

    But isn't this a rather ugly way to do it?

It is ugly, but it is backward-compatible.

In the mail last year, you suggested
* Index:
instead of
* Menu:
in index nodes, which is prettier -- but then old info readers wouldn't be
able to read new info files properly, which seems too big a drawback to me.

The ^@^H[ stuff, which we invented for images, will also give us an
extensible mechanism, once Emacs Info ignores (and does not display) any
directives it doesn't know what to do with.  (I'll attach a test file.)
So in that sense, it is not *too* ugly a solution.

BTW, can someone volunteer to do that?  I've asked before, but no one
answered.  Maybe we should look for a volunteer to be the official
maintainer Emacs Info?  Unfortunately, I don't have time to do it myself.

Thanks,
k


[-- Attachment #2: newcmd.handmadeinfo --]
[-- Type: application/octet-stream, Size: 228 bytes --]

[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: reliably determining if an Info node is an index

[Richard Stallman]

    The ^@^H[ stuff, which we invented for images, will also give us an
    extensible mechanism, once Emacs Info ignores (and does not display) any
    directives it doesn't know what to do with.  (I'll attach a test file.)
    So in that sense, it is not *too* ugly a solution.

I think we want this change to be released in Emacs soon, if we are
going to put it into Texinfo now.  We should put it into a 21.4
release that we are going to make soon from the RC branch.

Emacs release numbering 21.4 vs. 22.1

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     The ^@^H[ stuff, which we invented for images, will also give us an
>     extensible mechanism, once Emacs Info ignores (and does not display) any
>     directives it doesn't know what to do with.  (I'll attach a test file.)
>     So in that sense, it is not *too* ugly a solution.
> 
> I think we want this change to be released in Emacs soon, if we are
> going to put it into Texinfo now.  We should put it into a 21.4
> release that we are going to make soon from the RC branch.

I believe many emacs users are expecting 21.4 be released from the CVS
head as a major feature update.  

To remove that confusion, I suggest that we decide _NOW_ that when CVS
head will eventually be released as 22.1, and that we start preparing
for that now.

We definitely have enough new functionality in the CVS head to justify
upgrading the major number (and I suppose that the unicode branch will
be merged to the trunk before releasing 22.1 -- right?).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Emacs release numbering 21.4 vs. 22.1

[David Kastrup]

no-spam@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > I think we want this change to be released in Emacs soon, if we
> > are going to put it into Texinfo now.  We should put it into a
> > 21.4 release that we are going to make soon from the RC branch.
> 
> I believe many emacs users are expecting 21.4 be released from the
> CVS head as a major feature update.

I am afraid so.

> To remove that confusion, I suggest that we decide _NOW_ that when
> CVS head will eventually be released as 22.1, and that we start
> preparing for that now.
> 
> We definitely have enough new functionality in the CVS head to
> justify upgrading the major number (and I suppose that the unicode
> branch will be merged to the trunk before releasing 22.1 -- right?).

Personally, I think this decision would have saved me a bit of
trouble.  Whenever showing around new features and being asked when
they would be available, my predictions have been wrong since the next
version happened to be just a bug fix.  22.1 would be a good reply.

Even if we are not talking about added functionality, at the time we
release HEAD a substantial change in stability, behavior, keybindings
and look is to be expected.  I think it would prepare people better
if we changed the major version number as well.

But we should then really incorporate everything that has a
reasonable chance of working.  The unicode branch sounds like a
candidate, as does the bidi branch.  They really should be available
without separate compilation if that does not mean a functional
regression in other areas.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs release numbering 21.4 vs. 22.1

[Stefan Monnier]

I personally don't care about version numbers and not even about whether the
next release will include unicode and/or bidi, but OTOH I really care about
the timeline: I want a feature freeze real-soon-now, so if we want unicode
in there, we'd better merge unicode right away (even if it's not perfect
yet).


        Stefan

Re: Emacs release numbering 21.4 vs. 22.1

[David Kastrup]

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

> I personally don't care about version numbers and not even about
> whether the next release will include unicode and/or bidi, but OTOH
> I really care about the timeline: I want a feature freeze
> real-soon-now, so if we want unicode in there, we'd better merge
> unicode right away (even if it's not perfect yet).

I copy that sentiment about the timeline: it feels somewhat silly if
you are going to annual conferences and tell people several times in
a row "oh, and the stuff I'm showing you will come with the next
non-bugfix release of Emacs".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum