unicode-2, Emacs.app terminal mode after multi-tty merge

unicode-2, Emacs.app terminal mode after multi-tty merge

[Adrian Robert]

Hi,

I updated Emacs.app (Mac Cocoa port) to run under the multi-tty
changes as merged into the unicode-2 branch, however before releasing
I need to solve one remaining problem: when run as -nw, the default
face is set to green foreground, yellow background.  (If I go to
customize-face it actually says "green" and "yellow".)  This occurs
with emacs -Q -nw and is new -- unicode-2 CVS before the merge
produces a black-on-white default face.

Someone suggested something in my terminal settings caused the
problem, though I don't have any customization (moved aside .cshrc).
However the Apple terminal itself may be the cause?  If I run under an
xterm the problem goes away, but I'm in black-and-white mode.  Setting
the TERM variable under Apple terminal to various values likewise
either gives green/yellow or full b-&-w mode.

Anyway if anyone has any suggestions as to where to start hunting, I
would be grateful.

Another question -- is there any way to ask the new emacsclient to
open a frame in the default windowing terminal?  There is the
--display argument but that seems to force X.  What about adding
--terminal=zz, with zz='default' meaning $DISPLAY env variable (X), or
normal GUI display on Mac or Windows?  Or simply "-gui" as a synonym
for --terminal=default?

Finally, is basic use of multi-tty from inside emacs documented
anywhere?  I read about some functions in the NEWS but could not find
out how to get a list of the available terminal names to use for 'tty'
arguments, or how to specify displays in non-X environments.  E.g.,
I'd like to throw up a GUI window from inside a -nw session.

thanks,
Adrian

Re: unicode-2, Emacs.app terminal mode after multi-tty merge

[Stefan Monnier]

> I updated Emacs.app (Mac Cocoa port) to run under the multi-tty
> changes as merged into the unicode-2 branch,

Wonderful.  Can't wait to see this code in the CVS repository.

> however before releasing I need to solve one remaining problem: when
> run as -nw, the default face is set to green foreground, yellow
> background.  (If I go to customize-face it actually says "green" and
> "yellow".)  This occurs with emacs -Q -nw and is new -- unicode-2 CVS
> before the merge produces a black-on-white default face.

> Someone suggested something in my terminal settings caused the
> problem, though I don't have any customization (moved aside .cshrc).
> However the Apple terminal itself may be the cause?  If I run under an
> xterm the problem goes away, but I'm in black-and-white mode.  Setting
> the TERM variable under Apple terminal to various values likewise
> either gives green/yellow or full b-&-w mode.

What values give what result?  Check the code they run in lisp/term/*.el

> Another question -- is there any way to ask the new emacsclient to
> open a frame in the default windowing terminal?

That's what supposedly happens if you pass no option, if not, report it
as a bug.

> Finally, is basic use of multi-tty from inside emacs documented
> anywhere?

There's make-frame-on-tty.

> I read about some functions in the NEWS but could not find out how to
> get a list of the available terminal names to use for 'tty' arguments,

AFAIK there's no generic way to get such a list, indeed.  But any tty
in /dev to which we have write access should do.
It's kind of like X displays: you can't get a list of available
displays, but you can use any display to which you have access.

> or how to specify displays in non-X environments.  E.g.,
> I'd like to throw up a GUI window from inside a -nw session.

Don't know about that one.  There's probably no specific way to do it
because this was developed under X11.  So feel free to define such
a functionality for gnustep.  Note that IIRC w32 specifies
a constant/dummy value for `display' parameter of its frames, and
I guess the carbon code does likewise, so you may want to use that.


        Stefan

Re: unicode-2, Emacs.app terminal mode after multi-tty merge

[Adrian Robert]

On 11/5/07, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>
> > Another question -- is there any way to ask the new emacsclient to
> > open a frame in the default windowing terminal?
>
> That's what supposedly happens if you pass no option, if not, report it
> as a bug.

This happens if you started up a normal GUI session, but if you
started emacs with -nw, how do you ask it to put up a GUI frame?  Like
I said the --display option seems to be usable only for X.  It
requires something like ":0", etc... maybe the "dummy values" for
Win32 and Carbon follow this format?  But in any case a simple -gui
option to do the right thing by default would be nice.  (I guess I'm
just suggesting work for myself and W32/Carbon folks here..)



> > Finally, is basic use of multi-tty from inside emacs documented
> > anywhere?
>
> There's make-frame-on-tty.
>
> > I read about some functions in the NEWS but could not find out how to
> > get a list of the available terminal names to use for 'tty' arguments,
>
> AFAIK there's no generic way to get such a list, indeed.  But any tty
> in /dev to which we have write access should do.
> It's kind of like X displays: you can't get a list of available
> displays, but you can use any display to which you have access.

What I was after was something that lists all the terminal types (tty,
Carbon, X, etc.) that are loaded into the running instance of emacs.
But even this should not be needed for most basic use.  User needing
to specify a precise display makes sense only under X, and even in
that case only if the value of the DISPLAY environment variable is not
what is desired.  So, e.g., a make-frame-on-default-graphical-display
function, or simply (make-frame-on-display nil) does the right thing.

(I'm thinking of the use case, user starts emacs -nw in a terminal
window, or from an ssh'd session to a remote X client, then wants a
bit more room for maneuvering.)

Re: unicode-2, Emacs.app terminal mode after multi-tty merge

[Stefan Monnier]

> What I was after was something that lists all the terminal types (tty,
> Carbon, X, etc.) that are loaded into the running instance of emacs.
> But even this should not be needed for most basic use.  User needing
> to specify a precise display makes sense only under X, and even in
> that case only if the value of the DISPLAY environment variable is not
> what is desired.  So, e.g., a make-frame-on-default-graphical-display
> function, or simply (make-frame-on-display nil) does the right thing.

> (I'm thinking of the use case, user starts emacs -nw in a terminal
> window, or from an ssh'd session to a remote X client, then wants a
> bit more room for maneuvering.)

I understand.  But as I said it's not there yet.  Feel free to add it.
The multi-tty code is (in many ways) a first attempt at it: there's a lot of
polishing that could be done.


        Stefan

Re: unicode-2, Emacs.app terminal mode after multi-tty merge

[Adrian Robert]

> > however before releasing I need to solve one remaining problem: when
> > run as -nw, the default face is set to green foreground, yellow
> > background.  (If I go to customize-face it actually says "green" and
> > "yellow".)  This occurs with emacs -Q -nw and is new -- unicode-2 CVS
> > before the merge produces a black-on-white default face.

I tracked this down a bit and found the green/yellow is coming from
FACE_TTY_DEFAULT_FG_COLOR and FACE_TTY_DEFAULT_BG_COLOR in
dispextern.h: these are defined to 2 and 3 respectively.  Meanwhile
tty-defined-color-alist is:

 (("black" 0 0 0 0)
("red" 1 52685 0 0)
("green" 2 0 52685 0)
("yellow" 3 52685 52685 0)
("blue" 4 0 0 61166)
("magenta" 5 52685 0 52685)
("cyan" 6 0 52685 52685)
("white" 7 58853 58853 58853))

So green and yellow are coming from indices 2/3 in that list.  I'm
getting the feeling something isn't working right, since these are
supposed to be markers for "unknown", not indices into a color list,
but I'm not sure what it is, or why this would be selectively failing
under the Cocoa port, since none of that code should affect tty
operation at all.

Also this color list seems a little strange, why does white get 58853
instead of 65535?  I know there is color approximation code in
tty-colors.el, but why would it even get activated for 'white', or if
so, why not generate 65535?

I'll keep investigating, but if anyone has any ready insight on any of
these issues, it is appreciated.

Re: unicode-2, Emacs.app terminal mode after multi-tty merge

[Jason Rumney]

Adrian Robert wrote:
>  (("black" 0 0 0 0)
> ("red" 1 52685 0 0)
> ("green" 2 0 52685 0)
> ("yellow" 3 52685 52685 0)
> ("blue" 4 0 0 61166)
> ("magenta" 5 52685 0 52685)
> ("cyan" 6 0 52685 52685)
> ("white" 7 58853 58853 58853))
>
> Also this color list seems a little strange, why does white get 58853
> instead of 65535?

Do the colors on this terminal get lighter when the bold attribute is set?

I think something in the multi-tty merged redefined how the color
indexes are defined. On MS-Windows, all colors are appearing as black on
lightgray on the console, though there are still 16 colors defined, so
the colors are being initialised correctly.

Re: unicode-2, Emacs.app terminal mode after multi-tty merge

[Adrian Robert]

> > Also this color list seems a little strange, why does white get 58853
> > instead of 65535?
>
> Do the colors on this terminal get lighter when the bold attribute is set?

Subjectively, no.  There is an unexpected effect of this though.
Normally when emacs -nw starts the slightly gray white color seems to
be only shown under where text is rendered - the bg color of the frame
itself is (really) white.  However if I customize bold on the default
face and restart, it gets the grayish white.


> On MS-Windows, all colors are appearing as black on
> lightgray on the console, though there are still 16 colors defined, so
> the colors are being initialised correctly.

It really seems like things are operating strangely in color setting
now, but the exact sequence of initialization calls between faces.el,
tty-colors.el, frame.el, frame.c, and xfaces.c is not easy to schuss
out.

Re: unicode-2, Emacs.app terminal mode after multi-tty merge

[Dan Nicolaescu]

"Adrian Robert" <adrian.b.robert@gmail.com> writes:

  > > > however before releasing I need to solve one remaining problem: when
  > > > run as -nw, the default face is set to green foreground, yellow
  > > > background.  (If I go to customize-face it actually says "green" and
  > > > "yellow".)  This occurs with emacs -Q -nw and is new -- unicode-2 CVS
  > > > before the merge produces a black-on-white default face.
  > 
  > I tracked this down a bit and found the green/yellow is coming from
  > FACE_TTY_DEFAULT_FG_COLOR and FACE_TTY_DEFAULT_BG_COLOR in
  > dispextern.h: these are defined to 2 and 3 respectively.  Meanwhile
  > tty-defined-color-alist is:
  > 
  >  (("black" 0 0 0 0)
  > ("red" 1 52685 0 0)
  > ("green" 2 0 52685 0)
  > ("yellow" 3 52685 52685 0)
  > ("blue" 4 0 0 61166)
  > ("magenta" 5 52685 0 52685)
  > ("cyan" 6 0 52685 52685)
  > ("white" 7 58853 58853 58853))
  > 
  > So green and yellow are coming from indices 2/3 in that list.  I'm
  > getting the feeling something isn't working right, since these are
  > supposed to be markers for "unknown", not indices into a color list,
  > but I'm not sure what it is, or why this would be selectively failing
  > under the Cocoa port, since none of that code should affect tty
  > operation at all.
  > 
  > Also this color list seems a little strange, why does white get 58853
  > instead of 65535?  I know there is color approximation code in
  > tty-colors.el, but why would it even get activated for 'white', or if
  > so, why not generate 65535?
  > 
  > I'll keep investigating, but if anyone has any ready insight on any of
  > these issues, it is appreciated.

Is this when TERM=xterm?
xterm.el defines white as 
    ("white"          7 (229 229 229))  ; gray90
                                 
229 is 0xe5, 58853 is 0xe5e5, so nothing unexpected WRT "white".

Re: unicode-2, Emacs.app terminal mode after multi-tty merge

[Eli Zaretskii]

> Date: Mon, 12 Nov 2007 09:49:45 +0300
> From: "Adrian Robert" <adrian.b.robert@gmail.com>
> 
> I tracked this down a bit and found the green/yellow is coming from
> FACE_TTY_DEFAULT_FG_COLOR and FACE_TTY_DEFAULT_BG_COLOR in
> dispextern.h: these are defined to 2 and 3 respectively.

??? Where did you see them defined to 2 and 3?  I see -2 and -3:

    /* Color index indicating that face uses an unknown foreground color.  */

    #define FACE_TTY_DEFAULT_FG_COLOR ((unsigned long) -2)

    /* Color index indicating that face uses an unknown background color.  */

    #define FACE_TTY_DEFAULT_BG_COLOR ((unsigned long) -3)

This is with today's CVS.

> Also this color list seems a little strange, why does white get 58853
> instead of 65535?  I know there is color approximation code in
> tty-colors.el, but why would it even get activated for 'white', or if
> so, why not generate 65535?

tty-colors.el is activated for _all_ colors (where else do you want
Emacs to get RGB values of terminal colors? the terminal does not tell
us, so we need to invent the values), but it does generate 65535 for
white, as you can see yourself.

Re: unicode-2, Emacs.app terminal mode after multi-tty merge

[Adrian Robert]

On 11/12/07, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Mon, 12 Nov 2007 09:49:45 +0300
> > From: "Adrian Robert" <adrian.b.robert@gmail.com>
> >
> > I tracked this down a bit and found the green/yellow is coming from
> > FACE_TTY_DEFAULT_FG_COLOR and FACE_TTY_DEFAULT_BG_COLOR in
> > dispextern.h: these are defined to 2 and 3 respectively.
>
> ??? Where did you see them defined to 2 and 3?  I see -2 and -3:

Thank you so much, that fixed everything.  Looking back at past
revisions, I have no idea where the positive values came from.. merge
gremlins I guess.