info invisible changes

info invisible changes

[Miles Bader]

Hi Kim,\r਀ഊI see you put in your info changes.\r਀ഊIt does look nicer (cleaner), but there are some problems:\r਀ഊWhen I do `Memacs' from the top-level dir (with point at the beginning\r਀漀昀 琀栀攀 戀甀昀昀攀爀⤀Ⰰ 䤀 最攀琀 琀栀攀 昀漀氀氀漀眀椀渀最 攀爀爀漀爀㨀ഊ\r਀   䐀攀戀甀最最攀爀 攀渀琀攀爀攀搀ⴀⴀ䰀椀猀瀀 攀爀爀漀爀㨀 ⠀攀爀爀漀爀 ∀一漀 猀甀挀栀 愀渀挀栀漀爀 椀渀 琀愀最 琀愀戀氀攀 漀爀 渀漀搀攀 椀渀 琀愀最 琀愀戀氀攀 漀爀 昀椀氀攀㨀 吀栀攀 攀砀琀攀渀猀椀戀氀攀 猀攀氀昀ⴀ搀漀挀甀洀攀渀琀椀渀最 琀攀砀琀 攀搀椀琀漀爀∀⤀ഊ     signal(error ("No such anchor in tag table or node in tag table or file: The extensible self-documenting text editor"))\r਀     攀爀爀漀爀⠀∀一漀 猀甀挀栀 愀渀挀栀漀爀 椀渀 琀愀最 琀愀戀氀攀 漀爀 渀漀搀攀 椀渀 琀愀最 琀愀戀氀攀 漀爀 昀椀氀攀㨀 ─猀∀ ∀吀栀攀 攀砀琀攀渀猀椀戀氀攀 猀攀氀昀ⴀ搀漀挀甀洀攀渀琀椀渀最 琀攀砀琀 攀搀椀琀漀爀∀⤀ഊ     byte-code("Æ\b!ƒ1\0\b\x19Ç	\n\"‰^[ƒ0\0\vA@\x14È\v8É=„!\0Ê\f!\x14\v@ƒ0\0\f‰\x15bˆËÌÍ\"ˆ*eÎ\f!ÏZ]bˆÐ\n!‰\x1e\x13ƒL\0\x0e\x13bˆËÌÍ\"ˆÑÒ\x0e\x14\"ˆ)Ƈ" [Info-tag-table-marker m regexp found guesspos anchorpos marker-position Info-find-in-tag-table 2 Info-mode Info-read-subfile throw foo t byte-to-position 1000 Info-find-node-in-buffer error "No such anchor in tag table or node in tag table or file: %s" pos nodename] 4)\r਀     䤀渀昀漀ⴀ昀椀渀搀ⴀ渀漀搀攀ⴀ㈀⠀渀椀氀 ∀吀栀攀 攀砀琀攀渀猀椀戀氀攀 猀攀氀昀ⴀ搀漀挀甀洀攀渀琀椀渀最 琀攀砀琀 攀搀椀琀漀爀∀ 渀椀氀⤀ഊ     Info-find-node(nil "The extensible self-documenting text editor")\r਀     䤀渀昀漀ⴀ最漀琀漀ⴀ渀漀搀攀⠀∀吀栀攀 攀砀琀攀渀猀椀戀氀攀 猀攀氀昀ⴀ搀漀挀甀洀攀渀琀椀渀最 琀攀砀琀 攀搀椀琀漀爀∀ 渀椀氀⤀ഊ     Info-menu("Emacs" nil)\r਀     挀愀氀氀ⴀ椀渀琀攀爀愀挀琀椀瘀攀氀礀⠀䤀渀昀漀ⴀ洀攀渀甀⤀ഊ\r਀嬀一漀琀攀 琀栀愀琀 琀栀攀 ∀吀栀攀 攀砀琀攀渀猀椀戀氀攀 ⸀⸀⸀∀ 椀猀 琀栀攀 搀攀猀挀爀椀瀀琀椀瘀攀 琀攀砀琀 昀漀爀 琀栀攀ഊ `Emacs' menu line, so apparently the `M' command is getting confused\r਀ 愀戀漀甀琀 栀漀眀 琀栀椀渀最猀 愀爀攀 昀漀爀洀愀琀琀攀搀⸀崀ഊ\r਀ഊThere are some other, more minor problems with this:\r਀ഊ  (1) The dir file (and presumably other info menus) I have was\r਀      昀漀爀洀愀琀琀攀搀 愀猀猀甀洀椀渀最 琀栀愀琀 渀漀 琀攀砀琀 眀漀甀氀搀 戀攀 栀椀搀搀攀渀Ⰰ 猀漀 椀渀 猀漀洀攀 挀愀猀攀猀Ⰰഊ      the invisible text results in a very wierd looking display.\r਀ഊ      Here's an example display from my *info* dir node (these are all\r਀      搀攀戀椀愀渀 攀渀琀爀椀攀猀⤀㨀ഊ\r਀ⴀⴀⴀ 戀攀最椀渀 焀甀漀琀攀 ⴀⴀⴀഊ* CVS		        Concurrent Versions\r਀ऀऀऀऀऀऀ     匀礀猀琀攀洀ഊ* CVS client/server     Describes the\r਀ऀऀऀऀऀऀ     挀氀椀攀渀琀⼀猀攀爀瘀攀爀 瀀爀漀琀漀挀漀氀ഊ						     used by CVS.\r਀⨀ 最挀挀ⴀ㈀㤀㔀ऀऀ吀栀攀 䜀一唀 䌀漀洀瀀椀氀攀爀ഊ						     Collection (Version\r਀ऀऀऀऀऀऀ     ㈀⸀㤀㔀⸀砀⤀⸀ഊ* Gdb			The GNU debugger.\r਀⨀ 䜀搀戀ⴀ䤀渀琀攀爀渀愀氀猀ऀऀ吀栀攀 䜀一唀 搀攀戀甀最最攀爀✀猀ഊ						     internals.\r਀ⴀⴀⴀ  攀渀搀 焀甀漀琀攀  ⴀⴀⴀഊ\r਀      䠀攀爀攀✀猀 琀栀攀 琀攀砀琀 愀猀 椀琀 愀瀀瀀攀愀爀猀 眀椀琀栀漀甀琀 椀渀瘀椀猀椀戀氀攀 爀攀最椀漀渀猀㨀ഊ\r਀ⴀⴀⴀ 戀攀最椀渀 焀甀漀琀攀 ⴀⴀⴀഊ* CVS: (cvs).					     Concurrent Versions\r਀ऀऀऀऀऀऀ     匀礀猀琀攀洀ഊ* CVS client/server: (cvsclient).		     Describes the\r਀ऀऀऀऀऀऀ     挀氀椀攀渀琀⼀猀攀爀瘀攀爀 瀀爀漀琀漀挀漀氀ഊ						     used by CVS.\r਀⨀ 最挀挀ⴀ㈀㤀㔀㨀 ⠀最挀挀ⴀ㈀㤀㔀⤀⸀ऀऀऀऀ     吀栀攀 䜀一唀 䌀漀洀瀀椀氀攀爀ഊ						     Collection (Version\r਀ऀऀऀऀऀऀ     ㈀⸀㤀㔀⸀砀⤀⸀ഊ* Gdb: (gdb).					     The GNU debugger.\r਀⨀ 䜀搀戀ⴀ䤀渀琀攀爀渀愀氀猀㨀 ⠀最搀戀椀渀琀⤀⸀ऀऀऀ     吀栀攀 䜀一唀 搀攀戀甀最最攀爀✀猀ഊ						     internals.\r਀ⴀⴀⴀ  攀渀搀 焀甀漀琀攀  ⴀⴀⴀഊ\r਀      䘀爀漀洀 琀栀攀 愀戀漀瘀攀Ⰰ 椀琀 猀攀攀洀猀 琀栀愀琀 礀漀甀爀 挀栀愀渀最攀 愀氀猀漀 爀攀洀漀瘀攀猀 猀漀洀攀ഊ      whitespace, because just difference can't be accounted for by just\r਀      洀愀欀椀渀最 琀栀攀 渀漀搀攀ⴀ渀愀洀攀 愀渀搀 瀀甀渀挀甀琀愀琀椀漀渀 椀渀瘀椀猀椀戀氀攀⸀ഊ\r਀ഊ  (2) Cursor movement is `wierd' around the invisible text region.  For\r਀      椀渀猀琀愀渀挀攀Ⰰ 琀愀欀椀渀最 漀渀攀 漀昀 琀栀攀 洀攀渀甀 氀椀渀攀猀 昀爀漀洀 愀戀漀瘀攀㨀ഊ\r਀ⴀⴀⴀ 戀攀最椀渀 焀甀漀琀攀 ⴀⴀⴀഊ* gcc-295		The GNU Compiler\r਀ⴀⴀⴀ  攀渀搀 焀甀漀琀攀  ⴀⴀⴀഊ\r਀      眀栀攀渀 䤀 甀猀攀 䌀ⴀ昀 琀漀 洀漀瘀攀 昀漀爀眀愀爀搀 昀爀漀洀 琀栀攀 戀攀最椀渀渀椀渀最 漀昀 琀栀攀 氀椀渀攀Ⰰഊ      everything's OK until point is before the `5'.  If I hit C-f\r਀      琀栀攀渀Ⰰ 瀀漀椀渀琀 樀甀洀瀀猀 琀漀 戀攀椀渀最 戀攀昀漀爀攀 琀栀攀 怀吀✀Ⰰ 眀栀攀渀 䤀 攀砀瀀攀挀琀攀搀 椀琀 琀漀ഊ      move to just after the `5'.  If I then hit C-f again, the cursor\r਀      搀漀攀猀渀✀琀 洀漀瘀攀Ⰰ 怀猀琀椀挀欀椀渀最✀ 愀琀 琀栀攀 瀀漀椀渀琀 戀攀昀漀爀攀 琀栀攀 怀吀✀㬀 愀渀漀琀栀攀爀 䌀ⴀ昀ഊ      then moves forward as expected.\r਀ഊ      I thought these sorts of problems were supposed to be generally\r਀      昀椀砀攀搀 琀栀攀猀攀 搀愀礀猀 ⠀眀攀氀氀Ⰰ 䌀ⴀ渀⼀䌀ⴀ瀀 愀爀攀 猀琀椀氀氀 昀甀挀欀攀搀 䤀 琀栀椀渀欀Ⰰ 戀甀琀ഊ      they're a separate case), so perhaps there's something odd with\r਀      琀栀攀 眀愀礀 礀漀甀✀爀攀 猀攀琀琀椀渀最 甀瀀 礀漀甀爀 椀渀瘀椀猀椀戀氀攀 琀攀砀琀⸀ഊ\r਀ഊ  (3) In the gcc-2.95 info doc, there's a node (`(gcc-295)G++ and GCC')\r਀      琀栀愀琀 挀漀渀琀愀椀渀猀 琀栀攀 昀漀氀氀漀眀椀渀最 琀攀砀琀㨀ഊ\r਀ⴀⴀⴀ 戀攀最椀渀 焀甀漀琀攀 ⴀⴀⴀഊthat you get better object code, and better debugging information.  The\r਀䜀一唀 搀攀戀甀最最攀爀Ⰰ 䜀䐀䈀Ⰰ 眀漀爀欀猀 眀椀琀栀 琀栀椀猀 椀渀昀漀爀洀愀琀椀漀渀 椀渀 琀栀攀 漀戀樀攀挀琀 挀漀搀攀 琀漀ഊgive you comprehensive C++ source-level editing capabilities (*note C\r਀愀渀搀 䌀⬀⬀㨀 ⠀最搀戀⸀椀渀昀漀⤀䌀⸀⤀⸀ഊ---  end quote  ---\r਀ഊ      your *note hack turns it into:\r਀ഊ--- begin quote ---\r਀琀栀愀琀 礀漀甀 最攀琀 戀攀琀琀攀爀 漀戀樀攀挀琀 挀漀搀攀Ⰰ 愀渀搀 戀攀琀琀攀爀 搀攀戀甀最最椀渀最 椀渀昀漀爀洀愀琀椀漀渀⸀  吀栀攀ഊGNU debugger, GDB, works with this information in the object code to\r਀最椀瘀攀 礀漀甀 挀漀洀瀀爀攀栀攀渀猀椀瘀攀 䌀⬀⬀ 猀漀甀爀挀攀ⴀ氀攀瘀攀氀 攀搀椀琀椀渀最 挀愀瀀愀戀椀氀椀琀椀攀猀 ⠀猀攀攀 䌀ഊand C++.info)C.).\r਀ⴀⴀⴀ  攀渀搀 焀甀漀琀攀  ⴀⴀⴀഊ\r਀  ⠀㐀⤀ 吀栀攀 眀爀愀瀀瀀椀渀最 瀀爀漀戀氀攀洀 栀愀瀀瀀攀渀猀 眀椀琀栀 ⨀渀漀琀攀 琀愀最猀 琀漀漀㬀 漀昀琀攀渀 椀琀✀猀 昀愀椀爀氀礀ഊ      benign (a line that's unusually short because of invisible'd text),\r਀      戀甀琀 猀漀洀攀琀椀洀攀猀 椀琀 最攀琀猀 愀 戀椀琀 甀最氀椀攀爀㬀 攀⸀最⸀ 琀栀攀 漀爀椀最椀渀愀氀㨀ഊ\r਀ⴀⴀⴀ 戀攀最椀渀 焀甀漀琀攀 ⴀⴀⴀഊ     order to be compiled,and also requires the header files for the\r਀     琀愀爀最攀琀✀猀 琀栀爀攀愀搀 氀椀戀爀愀爀礀 椀昀 礀漀甀 眀愀渀琀 琀栀爀攀愀搀 猀甀瀀瀀漀爀琀⸀  ⨀一漀琀攀ഊ     Cross-Compilers and Header Files: Cross Headers, for discussion\r਀     愀戀漀甀琀 栀攀愀搀攀爀 昀椀氀攀猀 椀猀猀甀攀猀 昀漀爀 挀爀漀猀猀ⴀ挀漀洀瀀椀氀愀琀椀漀渀⸀ഊ---  end quote  ---\r਀ഊ      turns into [note the wrapped line]:\r਀ഊ--- begin quote ---\r਀     漀爀搀攀爀 琀漀 戀攀 挀漀洀瀀椀氀攀搀Ⰰ愀渀搀 愀氀猀漀 爀攀焀甀椀爀攀猀 琀栀攀 栀攀愀搀攀爀 昀椀氀攀猀 昀漀爀 琀栀攀ഊ     target's thread library if you want thread support.  See Cross-Compilers and Header Files, for discussion\r਀     愀戀漀甀琀 栀攀愀搀攀爀 昀椀氀攀猀 椀猀猀甀攀猀 昀漀爀 挀爀漀猀猀ⴀ挀漀洀瀀椀氀愀琀椀漀渀⸀ഊ---  end quote  ---\r਀ഊ  (5) Cursor movement around the `See' is wierd, but I guess that's\r਀      猀漀洀攀琀栀椀渀最 礀漀甀 挀愀渀 搀漀 洀甀挀栀 愀戀漀甀琀⸀ഊ\r਀  ⠀㘀⤀ 䄀栀Ⰰ 䤀 樀甀猀琀 猀愀眀 愀渀漀琀栀攀爀 洀椀猀昀漀爀洀愀琀琀攀搀 洀攀渀甀 攀渀琀爀礀㬀 琀栀攀 漀爀椀最椀渀愀氀㨀ഊ\r਀ⴀⴀⴀ 戀攀最椀渀 焀甀漀琀攀 ⴀⴀⴀഊ* gcc-3.2: (gcc-3.2).				     The GNU Compiler\r਀ऀऀऀऀऀऀ     䌀漀氀氀攀挀琀椀漀渀 ⠀嘀攀爀猀椀漀渀 ㌀⸀㈀⤀⸀ഊ* gccint-3.2: (gccint-3.2).			     Internals of the GNU\r਀ऀऀऀऀऀऀ     䌀漀洀瀀椀氀攀爀 䌀漀氀氀攀挀琀椀漀渀ഊ						     (Version 3.2).\r਀ⴀⴀⴀ  攀渀搀 焀甀漀琀攀  ⴀⴀⴀഊ\r਀      琀甀爀渀猀 椀渀琀漀㨀ഊ\r਀ⴀⴀⴀ 戀攀最椀渀 焀甀漀琀攀 ⴀⴀⴀഊ* gcc-3.2		2).				     The GNU Compiler\r਀ऀऀऀऀऀऀ     䌀漀氀氀攀挀琀椀漀渀 ⠀嘀攀爀猀椀漀渀 ㌀⸀㈀⤀⸀ഊ* gccint-3.2		2).			     Internals of the GNU\r਀ऀऀऀऀऀऀ     䌀漀洀瀀椀氀攀爀 䌀漀氀氀攀挀琀椀漀渀ഊ						     (Version 3.2).\r਀ⴀⴀⴀ  攀渀搀 焀甀漀琀攀  ⴀⴀⴀഊ\r਀ഊAnyway, I basically like it, it's noticably easier to read than the old\r਀猀琀礀氀攀⸀ഊ\r਀ⴀ䴀椀氀攀猀ഊ-- \r਀嬀簀渀甀爀最氀攀簀崀  搀搀琀ⴀ 搀攀洀漀渀椀挀㼀 猀漀 焀甀愀欀攀 眀椀氀氀 栀愀瘀攀 愀渀 攀瘀椀氀 欀椀渀搀愀 猀攀琀琀椀渀最㼀 漀渀攀 琀栀愀琀 ഊ            will  make every christian in the world foamm at the mouth? \r਀嬀椀搀搀琀崀      渀甀爀最Ⰰ 琀栀愀琀✀猀 琀栀攀 最漀愀氀 ഊ

Re: info invisible changes

[Miles Bader]

"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

Re: info invisible changes

[Stefan Monnier]

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

Can you try again ?  There's been changes w.r.t. intangibility
which might explain the bug and which should be fixed now.
This also applies to the cursor motion.  It's definitely not
perfect now but it's probably slightly different.

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

We should probably refill the text.  After all, I think this problem only
happens for the `dir' file, not in other menus.


	Stefan

Re: info invisible changes

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

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

Thanks for reporting those problems; I have tried to fix some of them
as described below.

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

I cannot reproduce this with the lastest CVS.  I think Stefan fixed it.

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

> * CVS client/server     Describes the
> 						     client/server protocol
> 						     used by CVS.

I have added code to properly align (+2 spaces) the following description
lines.  Please try it out.


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

Indeed.  However, I'm definitely not going to hack on the display
engine to improve this [minor] issue.

BTW, try turning on M-x line-number-mode and M-x column-number-mode
and what what happens as you move through invisible text with embedded
newlines :-(


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

I've fixed that.

>   (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),

Yes, but as you'd see by turning on column-number-mode, there is no
easy way to decide what column a given character is displayed at [of
if there is, please enlighten me].  So it is really difficult to try
to improve this "locally".

As Stefan suggested we could refill the text, but then we start
modifying the text in the info buffer - and I'm not sure what the
implications of doing that are.

Also, how do we know what part of the text is safe to refill.

So for the moment, I don't see how we can easily get rid of those
short lines.

>       but sometimes it gets a bit uglier; e.g. the original:

>      target's thread library if you want thread support.  *Note
>      Cross-Compilers and Header Files: Cross Headers, for discussion
>      target's thread library if you want thread support.  See Cross-Compilers and Header Files, for discussion

I've fixed that (inserting a newline if the hidden text contains one),
but unfortunately this means that you'll see more short lines in some
places.

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

No, I don't think so...

>   (6) Ah, I just saw another misformatted menu entry; the original:
> 
> * gcc-3.2: (gcc-3.2).				     The GNU Compiler
> * gcc-3.2		2).				     The GNU Compiler

I've fixed that too.


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

Thanks!  I think so too, but not everyone was pleased with the
change, so I had to make it customizable...


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

Re: info invisible changes

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> >   (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.
> 
> > * CVS client/server     Describes the
> > 						     client/server protocol
> > 						     used by CVS.
> 
> I have added code to properly align (+2 spaces) the following description
> lines.  Please try it out.

Hmmm, well it looks _less_ bad: now the text is all in a properly-
indented, but absurdly narrow column.

I agree with Stefan that the text should be refilled in the top-level
dir node -- it's special because it contains much more hidden text than
a normal node, and looks especially bad without refilling, and also it's
not connected with a file (it's generated), so it's safe to modify.

Morever, the format of the menu entries seems regular enough that
finding the bounds required to fill/reindent; something like

  (goto-char START-OF-MENU-ENTRY-TEXT)
  (forward-sentence)
  (while (looking-at ".*\n[ \t]+[^ \t]")
    (forward-sentence))
  ;; point is now at END-OF-MENU-ENTRY-TEXT

seems to work alright.

Filling the test in the non-dir case is maybe more difficult, but
luckily that also seems to be less of a problem.

BTW, another wierd case I found is that sometimes footnotes are
followed by a newline and a then period (when obviously there should be
just a period).  For instance, in `(emacs)Glossary', I see:

--- begin quote ---
Aborting
     Aborting means getting out of a recursive edit (q.v.).  The
     commands `C-]' and `M-x top-level' are used for this.  See Quitting
.
---  end quote  ---

Thanks,

-Miles

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: info invisible changes

[Miles Bader]

On Wed, Nov 06, 2002 at 01:46:28PM +0100, Kim F. Storm wrote:
> > Hmmm, well it looks _less_ bad: now the text is all in a properly-
> > indented, but absurdly narrow column.
> 
> Weren't they in an absurdly narrow column already ?  ;-)

Indeed, but pushed over to the right side of the window by the long node
name, which made it look vaguely natural (though still bad).  Luckily this
generally only seems to be the case in the dir menu, and that's the one that
it's OK to modify...

> > Morever, the format of the menu entries seems regular enough that
> > finding the bounds required to fill/reindent; something like
> > 
> >   (goto-char START-OF-MENU-ENTRY-TEXT)
> >   (forward-sentence)
> >   (while (looking-at ".*\n[ \t]+[^ \t]")
> >     (forward-sentence))
> >   ;; point is now at END-OF-MENU-ENTRY-TEXT
> > 
> > seems to work alright.
>
> Maybe.  If you send me some misc dir files which have particular problems,
> I can probably do a better job at getting this right.

I'm just using my normal dir menu, which is emacs' dir merged with the
(auto-generated) debian dir file.  If you don't have a debian system, I can
send you a copy of my file.

I did try out the above lisp by hand on a bunch of entries in my dir menu,
and it worked every time (though there's always an exception I suppose).

BTW, on the issue of whether it's OK to modify the buffer contents, I think
it should be OK; (buffer-file-name) is always nil in the *info* buffer, after
all.  I think a lot of this stuff would become _much_ simpler if you could
must munge the buffer instead of using invisible/display properties (with all
their associated oddities), perhaps using text properties to store the
necessary non-displayed info instead of parsing the buffer for it -- of
course this would perhaps be a bigger change, since you'd have to modify the
various info-getting functions too, but I don't see why it would be _that_
big a job (presumably the modified code would support both text-property
stored info and buffer-parsing, for backward compatibility).

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: info invisible changes

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
> > >   (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.
> > 
> > > * CVS client/server     Describes the
> > > 						     client/server protocol
> > > 						     used by CVS.
> > 
> > I have added code to properly align (+2 spaces) the following description
> > lines.  Please try it out.
> 
> Hmmm, well it looks _less_ bad: now the text is all in a properly-
> indented, but absurdly narrow column.

Weren't they in an absurdly narrow column already ?  ;-)


> 
> I agree with Stefan that the text should be refilled in the top-level
> dir node -- it's special because it contains much more hidden text than
> a normal node, and looks especially bad without refilling, and also it's
> not connected with a file (it's generated), so it's safe to modify.

Yes, I'll see what I can do to improve this.

> 
> Morever, the format of the menu entries seems regular enough that
> finding the bounds required to fill/reindent; something like
> 
>   (goto-char START-OF-MENU-ENTRY-TEXT)
>   (forward-sentence)
>   (while (looking-at ".*\n[ \t]+[^ \t]")
>     (forward-sentence))
>   ;; point is now at END-OF-MENU-ENTRY-TEXT
> 
> seems to work alright.
> 
Maybe.  If you send me some misc dir files which have particular problems,
I can probably do a better job at getting this right.
> 
> BTW, another wierd case I found is that sometimes footnotes are
> followed by a newline and a then period (when obviously there should be
> just a period).  For instance, in `(emacs)Glossary', I see:
> 
> --- begin quote ---
> Aborting
>      Aborting means getting out of a recursive edit (q.v.).  The
>      commands `C-]' and `M-x top-level' are used for this.  See Quitting
> .
> ---  end quote  ---

So I need to massage the *note regexp even further it seems...

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

Re: info invisible changes

[Stefan Monnier]

> Hmmm, well it looks _less_ bad: now the text is all in a properly-
> indented, but absurdly narrow column.
> 
> I agree with Stefan that the text should be refilled in the top-level
> dir node -- it's special because it contains much more hidden text than
> a normal node, and looks especially bad without refilling, and also it's
> not connected with a file (it's generated), so it's safe to modify.

It's also special because it tends to itself not be properly
aligned/filled because each entry can come from a different dir
file (and also from different .texi files (via their .info
and install-info)) so the alignment of text is often strange.
to start with, unless all the dir files have been manually
edited.

In most other menus, the entries are of the form '* blabla::' and
there is thus nothing to hide, really.

> Morever, the format of the menu entries seems regular enough that
> finding the bounds required to fill/reindent; something like
> 
>   (goto-char START-OF-MENU-ENTRY-TEXT)
>   (forward-sentence)
>   (while (looking-at ".*\n[ \t]+[^ \t]")
>     (forward-sentence))
>   ;; point is now at END-OF-MENU-ENTRY-TEXT

I'd use (re-search-forward "^[^ \t]").  I believe that's what I use
in Info-remove-duplicates.

> BTW, on the issue of whether it's OK to modify the buffer contents, I think
> it should be OK; (buffer-file-name) is always nil in the *info* buffer, after

It now indeed is nil.  It used to be the case that it sometimes was
nil sometimes not.

> all.  I think a lot of this stuff would become _much_ simpler if you could
> must munge the buffer instead of using invisible/display properties (with all
> their associated oddities), perhaps using text properties to store the
> necessary non-displayed info instead of parsing the buffer for it -- of
> course this would perhaps be a bigger change, since you'd have to modify the
> various info-getting functions too, but I don't see why it would be _that_
> big a job (presumably the modified code would support both text-property
> stored info and buffer-parsing, for backward compatibility).

I disagree.  Especially since it's all customizable, it's easier and
safer to keep only one buffer-format and change the appearance
via properties.


	Stefan

Re: info invisible changes

[Miles Bader]

On Wed, Nov 06, 2002 at 10:11:41AM -0500, Stefan Monnier wrote:
> > I think a lot of this stuff would become _much_ simpler if you could must
> > munge the buffer instead of using invisible/display properties (with all
> > their associated oddities), perhaps using text properties to store the
> > necessary non-displayed info instead of parsing the buffer for it -- of
> > course this would perhaps be a bigger change, since you'd have to modify
> > the various info-getting functions too, but I don't see why it would be
> > _that_ big a job (presumably the modified code would support both
> > text-property stored info and buffer-parsing, for backward
> > compatibility).
> 
> I disagree.  Especially since it's all customizable, it's easier and
> safer to keep only one buffer-format and change the appearance
> via properties.

Safer I don't know (though I suspect it doesn't really make all that much
difference), but easier?  Modifying a buffer is _far_ more straight-forward
than using display-modification properties (because lots of stuff in emacs
simply doesn't know about them or their effects, and happily proceeds as if
they weren't there).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: info invisible changes

[Richard Stallman]

    > * CVS client/server     Describes the
    > 						     client/server protocol
    > 						     used by CVS.
    > * gcc-295		The GNU Compiler
    > 						     Collection (Version
    > 						     2.95.x).

I don't see anything like this, using sources from CVS today.
The directory looks fine.  I too am using Debian GNU/Linux.

Re: info invisible changes

[Richard Stallman]

    > I agree with Stefan that the text should be refilled in the top-level
    > dir node -- it's special because it contains much more hidden text than
    > a normal node, and looks especially bad without refilling, and also it's
    > not connected with a file (it's generated), so it's safe to modify.

There is no reason to hesitate about refilling the dir node.  It is
constructed inside Emacs anyway.

Re: info invisible changes

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Is someone working on fixing fill.el to deal with these text properties?
> 
> If not, should the code in fill.el be modified in general to deal with
> these properties, or can it be done by adding another type of filling
> specifically for this type of mangled text?  Please advise!

I suspect that this is a somewhat hard problem.  Of course, by simply
modifying the text directly (using properties where necessary to hold
out-of-band info) instead of using invisible/display properties, the
problem just goes away entirely.  ...and if you're gonna modify the
buffer by filling anyway...

-Miles
-- 
自らを空にして、心を開く時、道は開かれる

Re: info invisible changes

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > I agree with Stefan that the text should be refilled in the top-level
>     > dir node -- it's special because it contains much more hidden text than
>     > a normal node, and looks especially bad without refilling, and also it's
>     > not connected with a file (it's generated), so it's safe to modify.
> 
> There is no reason to hesitate about refilling the dir node.  It is
> constructed inside Emacs anyway.

Actually, the *info* buffer is now detached from the original info
file (it uses insert-file to setup the buffer), so we can modify the
*info* quite freely.

In any case, with the current implementation in info.el, I simply
tried to apply fill-paragraph to the sections of the *info* buffer
where I mangle the *note references ...  and although it actually does
a fair job most of the time, it sometimes fails horribly because the
code in fill.el suffers from a number of serious problems:

1) it doesn't test for 'invisible properties, so it happily processes
   invisible text when deciding the (visible) width of the lines,

2) it doesn't test for 'display properties, so if a part of the buffer
   text is hidden and visibly replaced with some other text (or an
   image), the hidden (rather than the visible) text is used for
   filling, and

3) when the fill code inserts a newline to wrap the text, it may
   insert that newline in an invisible part of the buffer, so it has
   no visible effect (i.e. displaying one very long line rather than
   two normal width lines).

Is someone working on fixing fill.el to deal with these text properties?

If not, should the code in fill.el be modified in general to deal with
these properties, or can it be done by adding another type of filling
specifically for this type of mangled text?  Please advise!

I think that if we fix those problems, a simple call to fill-paragraph
at the right place in Info-fontify-node will do a reasonble job of
presenting the mangled information in a more readable form.


++kfs

Re: info invisible changes

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> storm@cua.dk (Kim F. Storm) writes:
> > Is someone working on fixing fill.el to deal with these text properties?
> > 
> > If not, should the code in fill.el be modified in general to deal with
> > these properties, or can it be done by adding another type of filling
> > specifically for this type of mangled text?  Please advise!
> 
> I suspect that this is a somewhat hard problem.  Of course, by simply
> modifying the text directly (using properties where necessary to hold
> out-of-band info) instead of using invisible/display properties, the
> problem just goes away entirely.  ...and if you're gonna modify the
> buffer by filling anyway...

True!

However, I think that fill should at least be aware of 'invisible
properties (which should be doable), while dealing with 'display
properties is harder and less important (for my purpose at least).

If we fixed the 'invisible problem, then I could simply insert the
"see" into the buffer rather than using a 'display property and make
the *note part invisible to allow the Info navigation to remain
unchanged.

BTW, I was asked to implement image support in Info mode.  Has anyone
done some thoughts on how that should work [what kind of reference
would be in the info buffer, and where would the image be stored?]

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

Re: info invisible changes

[Robert J. Chassell]

    BTW, I was asked to implement image support in Info mode.  Has
    anyone done some thoughts on how that should work ....

As a first step, please display the images in the Info file in the
places corresponding to their locations in the Texinfo source, rather
than in some other place.  W3 mode, for example, puts images from the
beginning of an HTML file at the end of the buffer, and vice-versa;
and it drops some images.

Also, when you implement images, please consider additions that may be
made later:

  * An option to present the alternative text rather than the image so
    that the blind can listen to it.  (By blind, I mean people who
    listen to Info as they drive a car, the `situationally blind', as
    well as the permanently blind).

    Note that Emacspeak works well and no longer requires special
    text-to-speech hardware.  I run Emacspeak on this computer on
    which I am writing this using its built-in audio device and free
    software (the Debian `flite', `eflite', and `emacspeak' packages).

    The alternative text will come from the Texinfo source.  Such text
    is already an optional argument to the @image command.

  * The caption text and figure reference for the image.  The TeX for
    this could be taken from the botex.tex sources from 1985, since
    that (print-only) predecessor to Texinfo possessed images with
    captions and cross references to them.  But makeinfo and Info will
    need new code to handle these features, and the @image command
    will need additional options to hold them.

  * An option to put a user-inspired border around images, with a
    local variable, so you can specify it on a per-info file basis.
  
    Many images are plain and look terrible if shown flat against
    whatever background your instance of Emacs is using.  (For
    example, my current background is "DodgerBlue4"; to look good,
    most images need to be set off from that background a little by
    `picture frames' or borders.)

  * An option to load a background as you might for HTML.  Although
    people have complained heavily about Web pages that are unreadable
    because of their backgrounds, some backgrounds do nicely and
    should become a part of Emacs.  

    For examples, look at my Web site

        http://www.teak.cc

    [note the .cc extension] and at my neice's Web site

        http://www.goldenhillfarm.com

    in a Web browser, such as galeon, that shows backgrounds.

    In any event, I presume that Texinfo will eventually support
    backgrounds for its HTML output; Info might as well be ready to do
    the same.

  * An option to increase or decrease the size of the image.
    Different instances of Emacs use different resolution screens.  On
    a high resolution screen, for example, it is hard to read a font
    that is big enough on a low resolution screen.  It is the same
    with images.  An image that looks great on a generic personal
    computer screen looks too small on a high resolution personal
    computer screen.

    Obviously, Info is not bothered by the font size problem, since
    that issue is already solved; but will suffer an image size
    problem.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: info invisible changes

[Stefan Monnier]

> 1) it doesn't test for 'invisible properties, so it happily processes
>    invisible text when deciding the (visible) width of the lines,

Are you sure ?  It uses current-column which does pay attention
to `invisible' properties.

> 3) when the fill code inserts a newline to wrap the text, it may
>    insert that newline in an invisible part of the buffer, so it has
>    no visible effect (i.e. displaying one very long line rather than
>    two normal width lines).

You can fix this easily.  See fill-nobreak-predicate.


	Stefan

Re: info invisible changes

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     BTW, I was asked to implement image support in Info mode.  Has
>     anyone done some thoughts on how that should work ....
> 
> As a first step, please display the images in the Info file in the
> places corresponding to their locations in the Texinfo source, rather
> than in some other place.

Of course, I didn't even imagine there was any other place...

Actually, I'm basically looking for the specification of how images
are supposed to be embedded in or referenced by info files (as a
result of using @image); something like *Image: file. or whatever...?

Does any of the info files provided on, say, a redhat 7.3 system
include images in the info files (so I have something to test on) ?


> Also, when you implement images, please consider additions that may be
> made later:
> 
>   * An option to present the alternative text rather than the image so
>     that the blind can listen to it.  (By blind, I mean people who
>     listen to Info as they drive a car, the `situationally blind', as
>     well as the permanently blind).
> 
>     Note that Emacspeak works well and no longer requires special
>     text-to-speech hardware.  I run Emacspeak on this computer on
>     which I am writing this using its built-in audio device and free
>     software (the Debian `flite', `eflite', and `emacspeak' packages).
> 
>     The alternative text will come from the Texinfo source.  Such text
>     is already an optional argument to the @image command.

I agree, but where is that text available in the generated info file?

> 
>   * The caption text and figure reference for the image.  The TeX for
>     this could be taken from the botex.tex sources from 1985, since
>     that (print-only) predecessor to Texinfo possessed images with
>     captions and cross references to them.  But makeinfo and Info will
>     need new code to handle these features, and the @image command
>     will need additional options to hold them.

Suggest that to the texinfo team -- once it is there, we can start
working on emacs support for it.

> 
>   * An option to put a user-inspired border around images, with a
>     local variable, so you can specify it on a per-info file basis.
>   
>     Many images are plain and look terrible if shown flat against
>     whatever background your instance of Emacs is using.  (For
>     example, my current background is "DodgerBlue4"; to look good,
>     most images need to be set off from that background a little by
>     `picture frames' or borders.)
> 
Emacs already allows image borders, so an Info customization would be
ok here.

>   * An option to load a background as you might for HTML.  Although
>     people have complained heavily about Web pages that are unreadable
>     because of their backgrounds, some backgrounds do nicely and
>     should become a part of Emacs.  
> 
>     For examples, look at my Web site
> 
>         http://www.teak.cc
> 
>     [note the .cc extension] and at my neice's Web site
> 
>         http://www.goldenhillfarm.com
> 
>     in a Web browser, such as galeon, that shows backgrounds.
> 
>     In any event, I presume that Texinfo will eventually support
>     backgrounds for its HTML output; Info might as well be ready to do
>     the same.

Emacs does not support background images, and neither does texinfo in
info files, so I prefer to delay the implementation until the features
are available.

> 
>   * An option to increase or decrease the size of the image.
>     Different instances of Emacs use different resolution screens.  On
>     a high resolution screen, for example, it is hard to read a font
>     that is big enough on a low resolution screen.  It is the same
>     with images.  An image that looks great on a generic personal
>     computer screen looks too small on a high resolution personal
>     computer screen.
> 

Again, this seems to be generally useful.  Maybe a separate TODO
item which can then be utilized by info once it is available.


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

Re: info invisible changes

[Robert J. Chassell]

   Does any of the info files provided on, say, a redhat 7.3 system
   include images in the info files (so I have something to test on) ?

The Solfege music program contains @image command in its
`online-docs/C/music-format.texi' file.  I have version 1.4.3, but the
latest version is 1.9.2:

    http://prdownloads.sourceforge.net/solfege/

    solfege-1.9.2.tar.gz 
or
    solfege-1.9.2-1.src.rpm

The download is not quite 400kb.  The @image commands contain only one
argument like this:

    @image{../png/simple}

The images are in PNG format.  They display well in the HTML files in
Galeon.  

Unfortunately, I could not build an Info file out of the Texinfo
file; the distribution lacks a .txt file for `makeinfo' to use:

    $ makeinfo music-format.texi
    music-format.texi:33: @image file `../png/simple.txt' (for text)
    unreadable: No such file or directory.


Also, the  

    emacs/lispintro/

directory in the current CVS for GNU Emacs 21 contains EPS files for
@image commands in emacs/lispintro/emacs-lisp-intro.texi.  

The @image commands are within @tex ... @end tex environments.  Plain
text diagrams are included within the Texinfo file for Info, HTML, and
for printers that cannot handle EPS, although nowadays, `makeinfo' can
handle plain-text .txt files.

    @tex
    @image{cons-1}
    @end tex

Again, the @image commands contain only one argument even though
the current @image command can hold up to 4 more arguments:

     @image{FILENAME, [WIDTH], [HEIGHT], [ALTTEXT], [EXTENSION]}


These are the only two Texinfo files that I know about that contain
@image, although I am sure there must be others.  Still, I am not
surprised.  The people writing in Texinfo have been mindful of their
potential audience, and understood that it includes those who work
over very slow connections and those who cannot see.


   >     The alternative text will come from the Texinfo source.  Such text
   >     is already an optional argument to the @image command.

   I agree, but where is that text available in the generated info file?

Initially, perhaps it should follow the image as if it were a
caption.  I think that eventually, a user should be able to toggle
among the three states:  image, alt-text, both

   Emacs already allows image borders, so an Info customization would be
   ok here.

Good!  I never realized that!  That would make a nice option.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: info invisible changes

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs/pretest@rum.cs.yale.edu> writes:

> > 1) it doesn't test for 'invisible properties, so it happily processes
> >    invisible text when deciding the (visible) width of the lines,
> 
> Are you sure ?  It uses current-column which does pay attention
> to `invisible' properties.

It works in relation to fill, yes.

But in general, the behaviour of current-column is "questionable" when
the buffer contains invisible newlines.  Consider the following code:

(let ((b (get-buffer-create "current-column test")))
   (set-buffer b)
   (erase-buffer)
   (insert "abc\ndef\nghi")
   (add-text-properties 4 5 '(invisible t))
   (add-text-properties 8 9 '(invisible t))
   ;; buffer now displays as one line: abcdefghi
   ;; position on the `h'
   (goto-char 10)
   (current-column))

It creates a buffer with the following data line (where # indicates an
invisible newline):

        abc#
        def#
        ghi

I.e. the visible result is:

        abcdefghi

Here, current-column claims that `h' is in column 1.

This is because current_column_1 uses scan_newline to find the
line start, but scan_newline doesn't skip over invisible newlines...


> 
> > 3) when the fill code inserts a newline to wrap the text, it may
> >    insert that newline in an invisible part of the buffer, so it has
> >    no visible effect (i.e. displaying one very long line rather than
> >    two normal width lines).
> 
> You can fix this easily.  See fill-nobreak-predicate.

Thanks.  I learn something new every day.

++kfs

Re: info invisible changes

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs/pretest@rum.cs.yale.edu> writes:

> 
> > 3) when the fill code inserts a newline to wrap the text, it may
> >    insert that newline in an invisible part of the buffer, so it has
> >    no visible effect (i.e. displaying one very long line rather than
> >    two normal width lines).
> 
> You can fix this easily.  See fill-nobreak-predicate.

I tried using this, but it is only checked if not at (bolp) --
which may happen inside invisible text.

I have added an explicit fill-nobreak-invisible variable which causes
fill-nobreak-p to return t for invisible text, and explicitly causes
fill-newline to remove any invisible property on the newline it
inserts.

I then modified info to set fill-nobreak-invisible to t and run
fill-paragraph on the paragraphs with mangled *note references.
I think the result is quite pleasant!

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

Re: info invisible changes

[Richard Stallman]

    1) it doesn't test for `invisible' properties, so it happily processes
       invisible text when deciding the (visible) width of the lines,

The TODO item about making filling handle fonts ought to include this
as well.

    2) it doesn't test for `display' properties, so if a part of the buffer
       text is hidden and visibly replaced with some other text (or an
       image), the hidden (rather than the visible) text is used for
       filling, and

I guess it ought to include this as well.

    3) when the fill code inserts a newline to wrap the text, it may
       insert that newline in an invisible part of the buffer,

If this is a significant case, I guess we would want to handle this
case too.


For the immediate issue of *info*, if you are going to fill the buffer
text anyway, the other changes may as well be made by editing the buffer
rather than with text properties.

Re: info invisible changes

[Richard Stallman]

    Unfortunately, I could not build an Info file out of the Texinfo
    file; the distribution lacks a .txt file for `makeinfo' to use:

Now that Emacs can display images, it would be useful to extend the
Info file format so it can include images, and update Texinfo so it
can handle them.

Perhaps the Info file should cointain the file name of a text image
file and the file name of a real image file; then, depending on the 
kind of display, the Info displayer can use one kind of image
or the other.

Re: info invisible changes

[Karl Berry]

    Perhaps the Info file should cointain the file name of a text image
    file and the file name of a real image file; then, depending on the 
    kind of display, the Info displayer can use one kind of image
    or the other.

Yes, this is another Info file format change that has come up before.
We should implement it when we can, along with the other format changes.

Thanks,
karl

Re: info invisible changes

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Unfortunately, I could not build an Info file out of the Texinfo
>     file; the distribution lacks a .txt file for `makeinfo' to use:
> 
> Now that Emacs can display images, it would be useful to extend the
> Info file format so it can include images, and update Texinfo so it
> can handle them.
> 
> Perhaps the Info file should cointain the file name of a text image
> file and the file name of a real image file; then, depending on the 
> kind of display, the Info displayer can use one kind of image
> or the other.

So currently, the Info file format does not support images.

I suspected that!  As I said in a previous mail, I think the texinfo
maintainers or someone else (but not me!) should enhance texinfo to
support images; once that is done, I could add Info image support in
emacs.

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