Info menus on text-mode terminals

Info menus on text-mode terminals

[Eli Zaretskii]

Did someone look lately at how we display Info menus on text-mode
terminals?  For example, type "C-h i d m elisp RET".

I think this is ugly, especially the way the long descriptions are
wrapped.  Here's one example, indented by my by 4 characters (I also
capitalized the menu entry name, since in Emacs it stands out in
color):

    * SEQUENCES ARRAYS Vectors Lists, strings and vectors are called sequences.
     Certain functions act on any kind of sequence.
     The description of vectors is here as well.

Is it possible to do better than that?  Any hope of aligning the
descriptive text on some column that is farther to the right, like
this:


    * SEQUENCES ARRAYS          Vectors Lists, strings and vectors are
      	                         called sequences.
                                Certain functions act on any kind of sequence.
                                The description of vectors is here as well.

Re: Info menus on text-mode terminals

[Luc Teirlinck]

Eli Zarestkii wrote:

   Here's one example, indented by my by 4 characters (I also
   capitalized the menu entry name, since in Emacs it stands out in
   color):

       * SEQUENCES ARRAYS Vectors Lists, strings and vectors are called sequences.
	Certain functions act on any kind of sequence.
	The description of vectors is here as well.

I do not see this.  With:

emacs-21.3.50 -q --eval \"(blink-cursor-mode 0)\" &

and then:

C-h i m Elisp RET

I get:

* Sequences Arrays Vectors  Lists, strings and vectors are called sequences.
                          Certain functions act on any kind of sequence.
                          The description of vectors is here as well.

and with `Info-hide-note-references' set to nil I get:

* Sequences Arrays Vectors::  Lists, strings and vectors are called sequences.
                                Certain functions act on any kind of sequence.
                                The description of vectors is here as well.

both of which look reasonable to me.  The only reason for the: 

--eval \"(blink-cursor-mode 0)\" 

is that I can not stand blinking cursors, not even for short periods
of time.  Are you getting the effect you describe using emacs -q?  Or
are you seeing the same I am seeing, but copied it indented
differently in your mail buffer?  In that case, I personally believe
that aligning things further to the right (than in the two examples I
showed, certainly the second) would look ugly for longer descriptions
and make Info menus more difficult to use, because of the (in my
opinion) needless increase in vertical space used up by the
description.

Sincerely,

Luc.

Re: Info menus on text-mode terminals

[Luc Teirlinck]

Frm my previous message:

   I do not see this.  With:

   emacs-21.3.50 -q --eval \"(blink-cursor-mode 0)\" &

The two `\' are of course wrong.   (I copied from an alias in .bashrc,
where the entire expression is quoted.)

Sincerely,

Luc.

Re: Info menus on text-mode terminals

[Luc Teirlinck]

Sorry for my previous reply.  Just ignore it.  I forgot to read the
   
   on text-mode terminals

part.  With:

emacs-21.3.50 -q -nw

I do see what you see.

Sincerely,

Luc.

Re: Info menus on text-mode terminals

[Luc Teirlinck]

Eli Zaretskii wrote:

   Did someone look lately at how we display Info menus on text-mode
   terminals?

The problem seems to be that the `Info-hide-note-references' machinery
does not expect Emacs to be running on a text-mode terminal.  If one
sets `Info-hide-note-references' to nil, the problem disappears.

One possible solution is to add a line to the documentation string of
`Info-hide-note-references' saying that it does not work very well on
text-only terminals and set the default for
`Info-hide-note-references' to nil on such terminals.

Sincerely,

Luc.

Re: Info menus on text-mode terminals

[Luc Teirlinck]

To elaborate somewhat on my previous reply:

The reason why `Info-hide-note-references' does not work well on
text-only terminals is because it relies on the display property for
indentation.  I do not believe that the display property works on
text-only terminals.  It definitely does not _seem_ to work.  Unless I
am mistaken about that, this should be clearly pointed out in
(elisp)Display Property.  Authors using the display property should
take that fact into account and provide alternatives for text-only
terminals, if possible.  (Again, unless I would be mistaken.)  In the
case we are considering, one such alternative is to set
`Info-hide-note-references' to nil on these terminals.

Sincerely,

Luc.

Re: Info menus on text-mode terminals

[Eli Zaretskii]

> Date: Sat, 27 Sep 2003 12:07:03 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> The reason why `Info-hide-note-references' does not work well on
> text-only terminals is because it relies on the display property for
> indentation.  I do not believe that the display property works on
> text-only terminals.

Is there any reason why this particular use of the display property
could not work on text-mode terminals?

Re: Info menus on text-mode terminals

[Luc Teirlinck]

Eli Zaretskii wrote:

   Is there any reason why this particular use of the display property
   could not work on text-mode terminals?

Yes, apparently I was wrong and the display property does work on
text-only terminals.  Actually, the particular feature in question
(space :align-to some-column-number) apparently starts to work on
text-only terminals after setting `buffer-invisibility-spec' to nil
using `visible-mode'.  But the character having the display property
does not have the invisibility property, although the character
preceding it does.  Also, everything works fine under X.

I will try to figure out more precisely what is going on.

Sincerely,

Luc.

Re: Info menus on text-mode terminals

[Luc Teirlinck]

Eli Zaretskii wrote:

   Is there any reason why this particular use of the display property
   could not work on text-mode terminals?

My temporary belief that it did work was apparently due to an optical
illusion.

Perform the following exercise with an emacs under X (or probably some
other window system) and with emacs -q -nw:

Go to the scratch buffer:

;; This buffer is for notes you don't want to save, and for Lisp evaluation.

Then do:

M-:  (put-text-property 4 5 'display '(space :align-to 30))

In the regular Emacs, the "T" gets replaced by a bunch whitespace, as
expected, but for emacs -nw, nothing happens, although C-u C-x = on
"T" shows that it really has the correct display property, it just has
no effect.

Does anybody know whether this is actually _supposed_ to work?

Sincerely,

Luc.

Re: Info menus on text-mode terminals

[Eli Zaretskii]

> Date: Sat, 27 Sep 2003 14:51:03 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> Perform the following exercise with an emacs under X (or probably some
> other window system) and with emacs -q -nw:
> 
> Go to the scratch buffer:
> 
> ;; This buffer is for notes you don't want to save, and for Lisp evaluation.
> 
> Then do:
> 
> M-:  (put-text-property 4 5 'display '(space :align-to 30))
> 
> In the regular Emacs, the "T" gets replaced by a bunch whitespace, as
> expected, but for emacs -nw, nothing happens, although C-u C-x = on
> "T" shows that it really has the correct display property, it just has
> no effect.
> 
> Does anybody know whether this is actually _supposed_ to work?

Gerd, could you please help us here?

TIA

Re: Info menus on text-mode terminals

[Gerd Moellmann]

"Eli Zaretskii" <eliz@elta.co.il> writes:

> > M-:  (put-text-property 4 5 'display '(space :align-to 30))
> > Does anybody know whether this is actually _supposed_ to work?
> 
> Gerd, could you please help us here?

I didn't implement `space' for ttys, AFAIR because ttys don't have the
necessary facilities to implement `space' fully.  So,
implementation-wise, `space' is not supposed to work on ttys.

Re: Info menus on text-mode terminals

[Richard Stallman]

    I didn't implement `space' for ttys, AFAIR because ttys don't have the
    necessary facilities to implement `space' fully.

Do you mean that they cannot do fractional spacing?  Nonetheless,
there is no reason why integer spacing values could not work, so they
ought to work.

Re: Info menus on text-mode terminals

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 28 Sep 2003 19:34:29 -0400
> 
>     I didn't implement `space' for ttys, AFAIR because ttys don't have the
>     necessary facilities to implement `space' fully.
> 
> Do you mean that they cannot do fractional spacing?  Nonetheless,
> there is no reason why integer spacing values could not work, so they
> ought to work.

I agree.

Re: Info menus on text-mode terminals

[Gerd Moellmann]

Richard Stallman <rms@gnu.org> writes:

>     I didn't implement `space' for ttys, AFAIR because ttys don't have the
>     necessary facilities to implement `space' fully.
> 
> Do you mean that they cannot do fractional spacing?

Yes, fractional spacing and height changes.

Re: Info menus on text-mode terminals

[David Kastrup]

gerd.moellmann@t-online.de (Gerd Moellmann) writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> >     I didn't implement `space' for ttys, AFAIR because ttys don't
> >     have the necessary facilities to implement `space' fully.
> > 
> > Do you mean that they cannot do fractional spacing?
> 
> Yes, fractional spacing and height changes.

Well, neither can GUIs.  They have to snap to a pixel grid.  The
problem with ttys is the same, it is just that the grid is coarser.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Info menus on text-mode terminals

[Richard Stallman]

    Go to the scratch buffer:

    ;; This buffer is for notes you don't want to save, and for Lisp evaluation.

    Then do:

    M-:  (put-text-property 4 5 'display '(space :align-to 30))

    In the regular Emacs, the "T" gets replaced by a bunch whitespace, as
    expected, but for emacs -nw, nothing happens, although C-u C-x = on
    "T" shows that it really has the correct display property, it just has
    no effect.

    Does anybody know whether this is actually _supposed_ to work?

This makes sense on text terminals, so it should work on text
terminals.  Therefore, I think this is a bug.

Re: Info menus on text-mode terminals

[Luc Teirlinck]

It is possible that the indentation problem in Info on text-only
terminals with `Info-hide-note-references' set to t was made worse by
a change I made (quite a while ago) to a change Stefan made to Kim's
original version.  But all three versions use the display property in
one form or another for indentation and hence, none of them would seem
to be able to work really well on text-only terminals.

Sincerely,

Luc.

Re: Info menus on text-mode terminals

[Richard Stallman]

    Did someone look lately at how we display Info menus on text-mode
    terminals?  For example, type "C-h i d m elisp RET".

    I think this is ugly, especially the way the long descriptions are
    wrapped.  Here's one example, indented by my by 4 characters (I also
    capitalized the menu entry name, since in Emacs it stands out in
    color):

We were discussing this a month or so ago, trying to figure out how to
avoid a bunch of different problems.  I think that one very general
refilling mechanism is applied to the entire Info file, and that it
uses heuristics to find the paragraph breaks that should be
maintained.

I think it does not handle menu items specially, but that might not be
hard to do.  You can notice the * Menu: that starts a menu, and then
do special handling on each paragraph that starts a menu item.  Once
you detect that the paragraph is a menu item, I think it won't be very
hard to implement a better behavior in that case.

Re: Info menus on text-mode terminals

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 28 Sep 2003 11:34:15 -0400
> 
>     Did someone look lately at how we display Info menus on text-mode
>     terminals?  For example, type "C-h i d m elisp RET".
> 
>     I think this is ugly, especially the way the long descriptions are
>     wrapped.  Here's one example, indented by my by 4 characters (I also
>     capitalized the menu entry name, since in Emacs it stands out in
>     color):
> 
> We were discussing this a month or so ago, trying to figure out how to
> avoid a bunch of different problems.  I think that one very general
> refilling mechanism is applied to the entire Info file, and that it
> uses heuristics to find the paragraph breaks that should be
> maintained.

I think the discussions you mentioned was about *info* buffers on X
and similar windowing systems.  I can hardly believe that the current
display of menus on text terminals looks like it does by some design.
It's more probably an oversight or a bug.

Re: Info menus on text-mode terminals

[Luc Teirlinck]

Eli Zaretskii wrote:

   It's more probably an oversight or a bug.

Very concretely, it is due to the fact that the code in question
relies on the display "space" property for proper indentation, whereas
that feature does not work on ttys.

Sincerely,

Luc.

Re: Info menus on text-mode terminals

[Miles Bader]

On Sun, Sep 28, 2003 at 11:43:34PM +0200, Eli Zaretskii wrote:
> I think the discussions you mentioned was about *info* buffers on X
> and similar windowing systems.

In the previous discussion I advocated actually modifying and filling the
buffer text to achieve Kim's layout improvements, instead of using display
property hacks to do it.  This would allow better layout, and eliminate some
weird side-effects of using display properties (such as funny cursor
movement).

In the context of that discussion, I think you're right, there was no mention
was made of ttys.  The `tty problem' is even more incentive to do it though...

-Miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: Info menus on text-mode terminals

[Luc Teirlinck]

Miles Bader wrote:

   In the previous discussion I advocated actually modifying and filling the
   buffer text to achieve Kim's layout improvements, instead of using display
   property hacks to do it.  This would allow better layout, and eliminate some
   weird side-effects of using display properties (such as funny cursor
   movement).

Yes, but it would have severe negative effects, as I already pointed
out in the previous discussion.  The current implementation of
Info-hide-note-references and related features is fundamentally flawed
because it tries to reformat Info files as if they were written in a
mark up language.  They are not, they are plain text.  The only way to
ever make such functionality work completely satisfactorily is through
a new option to makeinfo.  (That is probably what we eventually will
have to do, but, unfortunately, currently nobody seems to have the
time to do it.)

One consequence of that is that the refilling as attempted a while ago
did not respect the functionality in (texinfo)Breaks, such as @* and
@w.  I have had to use @w in texinfo, to avoid extremely bad line
breaks.

Remember that texinfo is supposed to be a general purpose mark up
language, not a hyper-specialized language for use in Emacs
documentation.  For some types of text, say mathematical text, being
able to force and avoid line breaks is extremely important.  If the
file contains text of a mathematical nature, line breaks at the wrong
places look disastrously bad.  In general, in any type of more
technical text, if one uses technical symbols that _need_ to stay
together, you _need_ to be able to rely 100% on @w.  If not, texinfo
as a mark up language would be badly broken.  Actually, it would be
more correct to say that Emacs as an Info reader would be badly
broken, but due to the importance of Emacs as an Info reader, that
would necessarily affect the texinfo language as such. 

(We discussed this before.)

   In the context of that discussion, I think you're right, there was
   no mention was made of ttys.  The `tty problem' is even more
   incentive to do it though...

Richard seems to believe that there is some hope to make "space" work
on ttys for integer spacing values.  That would eliminate this bug and
probably eliminate similar, not yet discovered, problems on ttys as
well.  (I doubt that the problem we are looking at is the absolute
only instance where somebody used the display property and forgot to
test his code on a tty.)

Sincerely,

Luc.

Re: Info menus on text-mode terminals

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> Yes, but it would have severe negative effects, as I already pointed
> out in the previous discussion.  The current implementation of
> Info-hide-note-references and related features is fundamentally flawed
> because it tries to reformat Info files as if they were written in a
> mark up language.

Whether or not it's a good idea to reformat text is orthogonal to
whether or not it's a good idea to use display properties to do it.

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

Re: Info menus on text-mode terminals

[Thien-Thi Nguyen]

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

   Whether or not it's a good idea to reformat text is orthogonal to
   whether or not it's a good idea to use display properties to do it.

given that any non-markup approach is heuristical, we might as well
expose the option to try different heuristics (including the null
"as-is" method) to the user.  emacs can take a best-guess stab and the
user can cycle through the lower priority methods w/ some key.  if they
bookmark the info page, its preferred display method can also be saved.

i would welcome such a facility if display methods themselves can be
registered by the user, because then i could write (for example) a
method that deletes/hides the explanatory text and leaves just the
function/variable blocks, or one that inserts annotations saved in a
separate file.  this way i would have a more personal relationship w/
the info pages.

thi

Re: Info menus on text-mode terminals

[Richard Stallman]

    Richard seems to believe that there is some hope to make "space" work
    on ttys for integer spacing values.

I am sure it can be done, if someone wants to implement it.  Since it
only needs to generate the proper number of space glyphs, much as a
tab character does, it can't be too hard.  The hardest part is
learning to understand the code that recognizes text properties, if
you don't already know it.  (I don't.)

Gerd, you know how text properties are recognized.  Could you do this?

Re: Info menus on text-mode terminals

[Gerd Moellmann]

Richard Stallman <rms@gnu.org> writes:

> Gerd, you know how text properties are recognized.  Could you do
> this?

Well, I can give some hints how to do it for someone who wants to
implement this.

 -- In handle_single_display_prop, let the Qspace subproperty
    through for terminal frames.

 -- In produce_glyphs, term.c and maybe elsewhere (msdos.c?), handle
    the case that it->what == IT_STRETCH in a way similar to
    x_produce_glyphs/produce_stretch_glyph, only produce some number
    of space glyphs instead of a stretch glyph.

Re: Info menus on text-mode terminals

[Richard Stallman]

    I think the discussions you mentioned was about *info* buffers on X
    and similar windowing systems.  I can hardly believe that the current
    display of menus on text terminals looks like it does by some design.
    It's more probably an oversight or a bug.

I agree it is a bug.  Looks like it was exposed by those changes.