Display problems in M-x term (was: terminal emulation)

Display problems in M-x term (was: terminal emulation)

[Michael Heerdegen]

Hi,

Without knowing much background, I tried to use aptitude and some
other applications with M-x term (in Gnu Emacs 23.3 on Debian) myself.
Indeed there are some problems, but generally, isn't `term' supposed
to work with applications like aptitude?

The bad thing with aptitude is that it uses a Unicode letter
(character 9618) to display a scroll-bar.  In some fontsets
(e.g. "startup: 13-dot"), the glyph of this char is wider than the
ASCII-characters (Bug?).  Lines including this character get wrapped,
messing up the whole display.  So, the terminal is only usable with
`truncate-lines' being t in this case.

There are also some Emacs features which interfere with the terminal,
resulting in surprising "effects", e.g.

  - If the user option `scroll-margin' has a value greater than 0,
    then the terminal window gets scrolled if the cursor is near the
    bottom and Emacs does a redisplay.

  - `show-paren-mode': Pairs of "parens" are highlighted by default in
    *terminal*.  E.g. in aptitude dialogs like this:


                    +---------------------+
                    |Really quit Aptitude?|
                    |  [ Yes ]    [ No ]  |
                    +---------------------+

      
    the "parens" around "Yes" and "No" get highlighted if point is
    there.


Maybe features and options like these, which make not much sense in a
terminal emulator, should be treated locally by M-x term?  E.g. it
would be good if `truncate-lines' and `scroll-margin' would be
buffer-local in *terminal* with a useful value.


P.S.: I also needed to apply the patch given in Bug #5615 for an
optimal result.

Re: Display problems in M-x term (was: terminal emulation)

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Sun, 05 Jun 2011 01:15:25 +0200
> Reply-To: michael_heerdegen@web.de
> 
> The bad thing with aptitude is that it uses a Unicode letter
> (character 9618) to display a scroll-bar.  In some fontsets
> (e.g. "startup: 13-dot"), the glyph of this char is wider than the
> ASCII-characters (Bug?).  Lines including this character get wrapped,
> messing up the whole display.

Does it help to modify the entry for that character in
char-width-table so that the value is 2 instead of 1?

>   - If the user option `scroll-margin' has a value greater than 0,
>     then the terminal window gets scrolled if the cursor is near the
>     bottom and Emacs does a redisplay.

term should set this to zero.

>   - `show-paren-mode': Pairs of "parens" are highlighted by default in
>     *terminal*.  E.g. in aptitude dialogs like this:
> 
> 
>                     +---------------------+
>                     |Really quit Aptitude?|
>                     |  [ Yes ]    [ No ]  |
>                     +---------------------+
> 
>       
>     the "parens" around "Yes" and "No" get highlighted if point is
>     there.

Why is that a problem?

Re: Display problems in M-x term

[Michael Heerdegen]

> Does it help to modify the entry for that character in
> char-width-table so that the value is 2 instead of 1?

I tried

  (aset char-width-table 9618 2)

with no visible effect in emacs -Q.  Do I need to eval more than this?


> >   - If the user option `scroll-margin' has a value greater than 0,
> >     then the terminal window gets scrolled if the cursor is near the
> >     bottom and Emacs does a redisplay.
>
> term should set this to zero.

Yes it should (currently, it doesn't).

> >   - `show-paren-mode': Pairs of "parens" are highlighted by default in
> >     *terminal*.  E.g. in aptitude dialogs like this:
> > 
> > 
> >                     +---------------------+
> >                     |Really quit Aptitude?|
> >                     |  [ Yes ]    [ No ]  |
> >                     +---------------------+
> > 
> >       
> >     the "parens" around "Yes" and "No" get highlighted if point is
> >     there.
>
> Why is that a problem?

This isn't a functional problem (but may irritate the user, dunno).