headers
Alok G. Singh | 4 May 2007 08:22
Picon
Favicon

Re: multi X display Emacs

On 28 Apr 2007, timotheus <at> tstotts.net wrote:

> 5. Starting emacs in a screen session and then creating X frames
> causes the X frames to have no color, ignore the X resources,
> etc.

This is exactly how I use mtty. Run Gnus inside screen and use
emacsclient in X. I have colours and emacsclient honours my
.Xresources. Are you use your Xresources are being loaded ? 

Also, Emacs.* refers to all emacsen, while emacs-multi-tty.* refers to
those programs named emacs-multi-tty. This allows you to have
different Xresources based on the emacs flavour.

--

-- 
Alok

"BTW, does Jesus know you flame?"
		-- Diane Holt, dianeh <at> binky.UUCP, to Ed Carp
Permalink | Reply | 0 comments |
headers
Johan Bockgård | 4 May 2007 17:15
Picon
Picon

Re: multi X display Emacs

timotheus <timotheus <at> tstotts.net> writes:

> 2. When X-windowing via `ssh -X' an `emacsclient -d $DISPLAY' (on a LAN
> connection), the Emacs GUI frame will die without error message in less than
> 10 minutes. Usually on a mouse click. No other applications exhibit the
> behavior.

Try `ssh -Y'.
Permalink | Reply | 1 comment |
headers
timotheus | 7 May 2007 02:22

Re: multi X display Emacs

Dan Nicolaescu <dann <at> ics.uci.edu> writes:

> What is the value of $TERM for the 2 situations above? 
> What is the result of:
> infocmp | grep colors
>
> (emacs uses the above information to decide what colors to use)
>

-- screen --
# echo $TERM
screen
# infocmp | grep colors
        colors#8, cols#80, it#8, lines#24, ncv#3, pairs#64,

-- urxvt --
# echo $TERM
rxvt-unicode
# infocmp | grep colors
	btns#5, colors#88, cols#80, it#8, lines#24, lm#0, ncv#0,

Screen is compiled with --enable-256; but only one terminfo file
exists. (Gentoo distribution.) I know that Debian has a separate
package for screen256; will have to google a bit ...

> What do you mean by better than Emacs 22? 
> multi-tty does not do anything special here, there should be no
> difference between what Emacs 22 does and what emacsclient -t does...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
timotheus | 7 May 2007 03:38

Re: multi X display Emacs


bojohan+news <at> dd.chalmers.se (Johan Bockgård) writes:

> Try `ssh -Y'.

Thanks, it works. I understand the difference between `-X' and `-Y', but
that is curious...

_______________________________________________
multi-tty mailing list
multi-tty <at> lists.fnord.hu
http://lists.fnord.hu/mailman/listinfo/multi-tty
Permalink | Reply | 0 comments |
headers
Yoshiaki Kasahara | 8 May 2007 03:49
Picon

Re: multi X display Emacs

Hi,

On Mon, 07 May 2007 10:20:19 -0700,
	Dan Nicolaescu <dann <at> ics.uci.edu> said:

>   > Screen is compiled with --enable-256; but only one terminfo file
>   > exists. (Gentoo distribution.) I know that Debian has a separate
>   > package for screen256; will have to google a bit ...
> 
> Unfortunately even if you have a version screen that is 256 color
> enabled, and the correct 256 color terminfo entry, emacs won't be able
> to take advantage of that and use 256 colors because it knows nothing
> about screen. 
> It would be quite easy to write the necessary code, it just needs a
> screen user to take interest in it and do it...

I know it is just a hack, but I'm using customized termcap entry which
has the name "xterm-screen" to make emacs believing that it is inside
256-color xterm (term/xterm.el will be loaded), and happily using
256color emacs inside screen.  Co, pa, AB and AF are modified from the
original "screen" entry.

SC|xterm-screen|VT 100/ANSI X3.64 virtual terminal with 256 xterm-colors:\
        :am:xn:ms:mi:G0:km:\
        :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
        :cb=\E[1K:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
        :do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
        :le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
        :li#24:co#80:us=\E[4m:ue=\E[24m:so=\E[3m:se=\E[23m:\
        :mb=\E[5m:md=\E[1m:mr=\E[7m:me=\E[m:sr=\EM:al=\E[L:\
(Continue reading)

Permalink | Reply | 2 comments |
headers
timotheus | 8 May 2007 05:58

Re: multi X display Emacs

Yoshiaki Kasahara <kasahara <at> nc.kyushu-u.ac.jp> writes:

> I know it is just a hack, but I'm using customized termcap entry which
> has the name "xterm-screen" to make emacs believing that it is inside
> 256-color xterm (term/xterm.el will be loaded), and happily using
> 256color emacs inside screen.  Co, pa, AB and AF are modified from the
> original "screen" entry.
>

Thanks. That was the right idea, though not quite what I had intended. My
solution to making screen+rxvt-unicode+emacs use higher than 16 colors was the
following:

- install terminfo screen-256color
    - comes by default on my distro (Gentoo)
    - for RedHat, copy from another distro to ~/.terminfo/s/

- run `urxvt'
    - in ~/.screenrc:

       term screen-256color

      OR

       screen -T screen-256color

    - `screen'
        - emacs -nw

Interestingly, run the XTerm 256 color test chart:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yoshiaki Kasahara | 8 May 2007 06:23
Picon

Re: multi X display Emacs

On Mon, 07 May 2007 23:58:42 -0400,
	timotheus <timotheus <at> tstotts.net> said:

> Now ViM and such may use 256 colors, even in urxvt. But Emacs still cannot
> figure out that there are 256 colors, despite the correct terminfo entries,

Emacs checks TERM variable to customize itself for the terminal.

term/README in the elisp directory says:

--------------
   When Emacs opens a new terminal, it checks the TERM environment variable to
see what type of terminal the user is running on, searches for an elisp file
named "term/${TERM}.el", and if one exists, loads it.  If Emacs finds no
suitable file, then it strips the last hyphen and what follows it from TERM,
and tries again.  If that still doesn't yield a file, then the previous hyphen
is stripped, and so on until all hyphens are gone.  For example, if the
terminal type is `aaa-48-foo', Emacs will try first `term/aaa-48-foo.el', then
`term/aaa-48.el' and finally `term/aaa.el'.  Emacs stops searching at the
first file found, and will not load more than one file for any terminal.  Note
that it is not an error if Emacs is unable to find a terminal initialization
file; in that case, it will simply proceed with the next step without loading
any files.
--------------

Only term/xterm.el and term/rxvt.el have the code to use 88 or 256
colors (registering the default set of colors available), so I need
to use name "xterm-foobar" for the TERM variable.

Maybe it's better to have term/screen.el to fully utilize 256-color
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Kastrup | 11 May 2007 10:44
Picon
Picon

Merging multitty (was: Reordering etc/NEWS)

Kenichi Handa <handa <at> m17n.org> writes:

> In article <E1HmPmA-0001n5-S7 <at> fencepost.gnu.org>, Richard Stallman <rms <at> gnu.org> writes:
>
>> So people can use the trunk for changes meant for Emacs 23.
>
> Does it mean that it is ok to merge emacs-unicode-2 into the
> trunk now?

Well, this is one of the points we definitely agreed to do for Emacs
23, so it _would_ appear to be in concord with Richard's statement
here.

However, I think we more or less agreed that it would be more prudent
to merge the multitty stuff first and follow up with the Unicode
branch, since that would minimize the merge work on multitty where we
have less active expertise to rely on.

Cc to Károly and the multi-tty list.

In either case, a merge into trunk is quite a bit of work, so it would
certainly not do harm to ask Richard for the explicit goahead if we
can agree on the procedures.

The last updates of multitty appear to have happened on Apr 22nd.
Károly, would it be possible for you to synch one last time to the
trunk and then check the results into a branch in Emacs CVS?

I would propose the following procedure:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Rumney | 11 May 2007 11:20
Picon

Re: Merging multitty

David Kastrup wrote:
> However, I think we more or less agreed that it would be more prudent
> to merge the multitty stuff first and follow up with the Unicode
> branch, since that would minimize the merge work on multitty where we
> have less active expertise to rely on.
>   
I don't recall ever agreeing this, although you have asserted so 
numerous times over the last few weeks.

The merge between multitty and unicode will be the same, whichever order 
it is done in.
The simple fact is that emacs-unicode-2 is ready to go onto the trunk, 
and the multitty is not due to issues mentioned in the README on 
Karoly's website.

> In either case, a merge into trunk is quite a bit of work.
>   

I think in both cases, the branches are well synched with trunk already, 
so there should be very little work in moving either one of the branches 
to the trunk (though in the case of multitty it would break Emacs on 
some platforms). The work comes when the non-merged branch is next 
synched to the trunk. The conflicts will be the same whichever direction 
the merge happens in, so I don't see any compelling reason to hasten the 
multitty merge to trunk (but it should be checked in on a branch ASAP so 
the problems mentioned above can be worked on by someone who is familiar 
with the platforms affected).

Your point that Karoly is not going to be available for much longer is a 
point against merging into trunk quickly IMHO. Either someone else will
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miles Bader | 11 May 2007 11:45
Favicon
Gravatar

Re: Merging multitty

David Kastrup <dak <at> gnu.org> writes:
> Comments, better ideas?

It might be better to merge into the arch version of the trunk, and then
let that be committed to CVS.  The multi-tty is already in arch, so
merging back into the arch-trunk should be basically trivial, and using
the regular arch->CVS gateway is probably safer than doing a one-off.

-Miles
--

-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]
Permalink | Reply | 0 comments |

Gmane