Re: info invisible changes

[Miles Bader <miles@lsi.nec.co.jp>]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> Can you decode for me the following email you sent ;-) ?

Whoops, sorry; maybe that's why I didn't any response (until I looked
just now, I didn't even realize that it had gotten encoded into some
wierd encoding, base64'd, etc!)...

Here's the original mail, sans byte-code strings:


Hi Kim,

I see you put in your info changes.

It does look nicer (cleaner), but there are some problems:

When I do `Memacs' from the top-level dir (with point at the beginning
of the buffer), I get the following error:

   Debugger entered--Lisp error: (error "No such anchor in tag table or node in tag table or file: The extensible self-documenting text editor")
     signal(error ("No such anchor in tag table or node in tag table or file: The extensible self-documenting text editor"))
     error("No such anchor in tag table or node in tag table or file: %s" "The extensible self-documenting text editor")
     byte-code(...)
     Info-find-node-2(nil "The extensible self-documenting text editor" nil)
     Info-find-node(nil "The extensible self-documenting text editor")
     Info-goto-node("The extensible self-documenting text editor" nil)
     Info-menu("Emacs" nil)
     call-interactively(Info-menu)

[Note that the "The extensible ..." is the descriptive text for the
 `Emacs' menu line, so apparently the `M' command is getting confused
 about how things are formatted.]

There are some other, more minor problems with this:

  (1) The dir file (and presumably other info menus) I have was
      formatted assuming that no text would be hidden, so in some cases,
      the invisible text results in a very wierd looking display.

      Here's an example display from my *info* dir node (these are all
      debian entries):

--- begin quote ---
* CVS		        Concurrent Versions
						     System
* CVS client/server     Describes the
						     client/server protocol
						     used by CVS.
* gcc-295		The GNU Compiler
						     Collection (Version
						     2.95.x).
* Gdb			The GNU debugger.
* Gdb-Internals		The GNU debugger's
						     internals.
---  end quote  ---

      Here's the text as it appears without invisible regions:

--- begin quote ---
* CVS: (cvs).					     Concurrent Versions
						     System
* CVS client/server: (cvsclient).		     Describes the
						     client/server protocol
						     used by CVS.
* gcc-295: (gcc-295).				     The GNU Compiler
						     Collection (Version
						     2.95.x).
* Gdb: (gdb).					     The GNU debugger.
* Gdb-Internals: (gdbint).			     The GNU debugger's
						     internals.
---  end quote  ---

      From the above, it seems that your change also removes some
      whitespace, because just difference can't be accounted for by just
      making the node-name and puncutation invisible.

  (2) Cursor movement is `wierd' around the invisible text region.  For
      instance, taking one of the menu lines from above:

--- begin quote ---
* gcc-295		The GNU Compiler
---  end quote  ---

      when I use C-f to move forward from the beginning of the line,
      everything's OK until point is before the `5'.  If I hit C-f
      then, point jumps to being before the `T', when I expected it to
      move to just after the `5'.  If I then hit C-f again, the cursor
      doesn't move, `sticking' at the point before the `T'; another C-f
      then moves forward as expected.

      I thought these sorts of problems were supposed to be generally
      fixed these days (well, C-n/C-p are still fucked I think, but
      they're a separate case), so perhaps there's something odd with
      the way you're setting up your invisible text.

  (3) In the gcc-2.95 info doc, there's a node (`(gcc-295)G++ and GCC')
      that contains the following text:

--- begin quote ---
that you get better object code, and better debugging information.  The
GNU debugger, GDB, works with this information in the object code to
give you comprehensive C++ source-level editing capabilities (*note C
and C++: (gdb.info)C.).
---  end quote  ---

      your *note hack turns it into:

--- begin quote ---
that you get better object code, and better debugging information.  The
GNU debugger, GDB, works with this information in the object code to
give you comprehensive C++ source-level editing capabilities (see C
and C++.info)C.).
---  end quote  ---

  (4) The wrapping problem happens with *note tags too; often it's fairly
      benign (a line that's unusually short because of invisible'd text),
      but sometimes it gets a bit uglier; e.g. the original:

--- begin quote ---
     order to be compiled,and also requires the header files for the
     target's thread library if you want thread support.  *Note
     Cross-Compilers and Header Files: Cross Headers, for discussion
     about header files issues for cross-compilation.
---  end quote  ---

      turns into [note the wrapped line]:

--- begin quote ---
     order to be compiled,and also requires the header files for the
     target's thread library if you want thread support.  See Cross-Compilers and Header Files, for discussion
     about header files issues for cross-compilation.
---  end quote  ---

  (5) Cursor movement around the `See' is wierd, but I guess that's
      something you can do much about.

  (6) Ah, I just saw another misformatted menu entry; the original:

--- begin quote ---
* gcc-3.2: (gcc-3.2).				     The GNU Compiler
						     Collection (Version 3.2).
* gccint-3.2: (gccint-3.2).			     Internals of the GNU
						     Compiler Collection
						     (Version 3.2).
---  end quote  ---

      turns into:

--- begin quote ---
* gcc-3.2		2).				     The GNU Compiler
						     Collection (Version 3.2).
* gccint-3.2		2).			     Internals of the GNU
						     Compiler Collection
						     (Version 3.2).
---  end quote  ---

Anyway, I basically like it, it's noticably easier to read than the old
style.

-Miles

-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia