Why is Emacs so slow when used remotely?
Russ P.
Emacs so I can use Ensime (an Emacs-based IDE for Scala). I finally
got my .emacs file debugged, but now I am finding that Emacs seems to
be very slow when used remotely.
When I work from home, I login from one Linux machine to another using
ssh -X over a high-speed Internet connection, using my home machine as
an X terminal for my work machine. I am using Emacs 23.2.1 on Red Hat.
I am finding that opening a file or switching buffers by middle-
clicking in dired or the buffer menu takes approximately 20-30
seconds. With XEmacs it takes less than one second. I hope I am doing
something wrong that can be corrected, because I'll grow old sitting
around that long every time I open a file or switch buffers. Any
suggestions? Thanks.
Russ P.
des...@verizon.net
Did you file a bug report?
Emacs seems a little over-active in dired-mode.
I'm running at least one emacs remotely too.
Just hovering over a name in dired causes a packet storm.
My first guess was that it was tooltip-mode so I toggled that
off.
Dired is still doing something during hover though
in the mode line it tries to tell me which button to push.
Each time it does that, I get a mini-packet storm.
(I can see my packet monitor graph move up.)
Maybe someone knows how to kill over active help in Dired?
Russ P.
> "Russ P." <russ.paie...@gmail.com> writes:
> > As I explained a few days ago, I am trying to switch from XEmacs to
> > Emacs so I can use Ensime (an Emacs-based IDE for Scala). I finally
> > got my .emacs file debugged, but now I am finding that Emacs seems to
> > be very slow when used remotely.
>
> > When I work from home, I login from one Linux machine to another using
> > ssh -X over a high-speed Internet connection, using my home machine as
> > an X terminal for my work machine. I am using Emacs 23.2.1 on Red Hat.
> > I am finding that opening a file or switching buffers by middle-
> > clicking in dired or the buffer menu takes approximately 20-30
> > seconds. With XEmacs it takes less than one second. I hope I am doing
> > something wrong that can be corrected, because I'll grow old sitting
> > around that long every time I open a file or switch buffers. Any
> > suggestions? Thanks.
>
> Did you file a bug report?
No. I don't know if this behavior is a bug or just poor performance.
(Nor do I know, off hand, how to file a bug report.)
This is disappointing. As far as I can tell, Emacs seems to be
essentially unusable for remote usage. I can't believe I am the only
one who has noticed this problem. Am I the only one who uses Emacs/
XEmacs to work remotely over ssh -X?
Russ P
Thorsten Bonow
Russ> On Sep 20, 6:40 pm, des...@verizon.net wrote:
>> Did you file a bug report?
Russ> No. I don't know if this behavior is a bug or just poor performance.
Russ> (Nor do I know, off hand, how to file a bug report.)
Russ> This is disappointing. As far as I can tell, Emacs seems to be
Russ> essentially unusable for remote usage. I can't believe I am the only
Russ> one who has noticed this problem. Am I the only one who uses Emacs/
Russ> XEmacs to work remotely over ssh -X?
I can't reproduce the problems. Start-up time of GNU Emacs 23.2.1 called with
"-Q" on my up to date remote Debian Unstable machine over ssh -X to my nearly
identical system over here is basically the same as GVim's; file opening and
buffer switching, typing and calling commands is all right. The menus are a
little bit sluggish and navigating in dired via mouse clicks really is
sloooow---close to 20 seconds. Keyboard navigation works fast, though.
Russ> Russ P
Toto
--
Aaachen University of Technology -- now even further ahead...
des...@verizon.net
Try clicking on a file in dired. (You must use the mouse.)
des...@verizon.net
> On Sep 20, 6:40 pm, des...@verizon.net wrote:
>> "Russ P." <russ.paie...@gmail.com> writes:
>> > As I explained a few days ago, I am trying to switch from XEmacs to
>> > Emacs so I can use Ensime (an Emacs-based IDE for Scala). I finally
>> > got my .emacs file debugged, but now I am finding that Emacs seems to
>> > be very slow when used remotely.
>>
>> > When I work from home, I login from one Linux machine to another using
>> > ssh -X over a high-speed Internet connection, using my home machine as
>> > an X terminal for my work machine. I am using Emacs 23.2.1 on Red Hat.
>> > I am finding that opening a file or switching buffers by middle-
>> > clicking in dired or the buffer menu takes approximately 20-30
>> > seconds. With XEmacs it takes less than one second. I hope I am doing
>> > something wrong that can be corrected, because I'll grow old sitting
>> > around that long every time I open a file or switch buffers. Any
>> > suggestions? Thanks.
>>
>> Did you file a bug report?
>
> No. I don't know if this behavior is a bug or just poor performance.
> (Nor do I know, off hand, how to file a bug report.)
Poor performance is a bug.
To send a bug report, click on Help, select Send Bug Report...
> This is disappointing. As far as I can tell, Emacs seems to be
> essentially unusable for remote usage. I can't believe I am the only
> one who has noticed this problem. Am I the only one who uses Emacs/
> XEmacs to work remotely over ssh -X?
As I said, I use emacs remotely all the time.
I actually one of the reasons I moved from XEmacs to Emacs was
the greatly improved performance.
The specific issue you are having has to do with dired and
it's "hover" feature. I was hoping someone would explain
how to turn the too helpful feature off.
I might dig into dired myself, but no promises.
Tim X
A few things to try ...
1. turn off tooltip mode
2. Try running with -nw to turn off X and only have a terminal UI and
see what the performance is like. this will let you know if the problem
is basic emacs or the X protocol stuff
3. Have you considered running tramp rather than a remote emacs? I've
not bothered with a remote emacs for a long time, preferring to run
tramp (especially with tramps support for remote execution of commands
etc).
4. Have you experimented with ssh compression? Sometimes you need to try
various values to get the optimal setting for your connection. Most X
protocol packets are quite small and too high a setting for compression
can actaully slow things down.
5. When I did run remote X based emacs versions, I found using one of
the X compression protocols gave a huge performance improvement. From
memory, the one I used was something like xdcp (X differential
compression protocol or something similar). I believe recent X.org
versions come with support for such protocols. Maybe look at setting
this up.
HTH
Tim
--
tcross (at) rapttech dot com dot au
David Kastrup
For a distant machine with an ssh connection, you are usually quite
better off running Emacs on your _own_ machine and just accessing files
remotely.
Something like
C-x C-f /user...@my.remote.host:local.filename RET
This will open an ssh session under username on my.remote.host and use
shell commands for transferring the file to your local Emacs.
Even things like
M-x compile RET
should work reasonably well (executing on the remote host with output to
a window in your local Emacs).
Much better than having to update a graphical display, and you need not
bother installing and maintaining an Emacs on the remote site.
--
David Kastrup
Pascal J. Bourguignon
> A few things to try ...
>
> 1. turn off tooltip mode
Yes. Anything graphic.
> 2. Try running with -nw to turn off X and only have a terminal UI and
> see what the performance is like. this will let you know if the problem
> is basic emacs or the X protocol stuff
This is not useful, if you only work with text. The X protocol is not
significantly worse than any other terminal protocol to send over text.
> 3. Have you considered running tramp rather than a remote emacs? I've
> not bothered with a remote emacs for a long time, preferring to run
> tramp (especially with tramps support for remote execution of commands
> etc).
>
> 4. Have you experimented with ssh compression? Sometimes you need to try
> various values to get the optimal setting for your connection. Most X
> protocol packets are quite small and too high a setting for compression
> can actaully slow things down.
Also, on a trusted network (ie. a LAN), you could bypass ssh, and just
send X directly over the LAN.
> 5. When I did run remote X based emacs versions, I found using one of
> the X compression protocols gave a huge performance improvement. From
> memory, the one I used was something like xdcp (X differential
> compression protocol or something similar). I believe recent X.org
> versions come with support for such protocols. Maybe look at setting
> this up.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Russ P.
> 3. Have you considered running tramp rather than a remote emacs? I've
> not bothered with a remote emacs for a long time, preferring to run
> tramp (especially with tramps support for remote execution of commands
> etc).
I was not aware of tramp. Thanks for mentioning it. I see from the
docs that it is included with Emacs since version 22. Can you give me
a clue how to find it in Emacs and use it?
I'm wondering how it will work with Ensime (Emacs-based IDE for
Scala).
Russ P.
David Kastrup
> Tim X <ti...@nospam.dev.null> writes:
>
>> A few things to try ...
>>
>> 1. turn off tooltip mode
>
> Yes. Anything graphic.
>
>
>> 2. Try running with -nw to turn off X and only have a terminal UI and
>> see what the performance is like. this will let you know if the problem
>> is basic emacs or the X protocol stuff
>
> This is not useful, if you only work with text. The X protocol is not
> significantly worse than any other terminal protocol to send over text.
Font rendering/antialiasing/composition nowadays happens mostly at the
client side if I am not mistaken. That makes the X protocol much worse
even with text.
--
David Kastrup
Uday Reddy
>
> When I work from home, I login from one Linux machine to another using
> ssh -X over a high-speed Internet connection, using my home machine as
> an X terminal for my work machine. I am using Emacs 23.2.1 on Red Hat.
You haven't mentioned how you are running the remote Emacs. I presume via X
windows?
I have never been happy with the performance of X windows myself. If I have to
access remote stuff, my solutions are:
1. To try remote file access from a local Emacs session. You can tunnel
various file access protocols through SSH (I tunnel SMB from Windows), and
there is also Emacs's own tramp which allows you to access remote files.
2. Run Emacs on the remote machine and connect to it from a locally run
emacsclient.
Cheers,
Uday
Pascal J. Bourguignon
That's not what I observe. It's possible for an application to deal
with characters itself and send bitmaps but normally, and it looks
like it's what emacs does, it sends only the strings and the font
rendering is done in the X server.
David Kastrup
For bitmap fonts. I don't think the X protocol channels antialiased
fonts yet. Usually xfs (the font server) runs on the client side of the
connection.
--
David Kastrup
Pascal J. Bourguignon
Let's get specific. IIRC, antialiased fonts appeared on emacs 23. So
there would be a risk of slow text mode with emacs >=23, but we'd be
assured to get a fast text mode with emacs <=22. Right?
Andrea Venturoli
> This is disappointing. As far as I can tell, Emacs seems to be
> essentially unusable for remote usage. I can't believe I am the only
> one who has noticed this problem. Am I the only one who uses Emacs/
> XEmacs to work remotely over ssh -X?
I used to use emacs over X/ssh on remote links, but finally had to give
up: with recent versions it has become almost unusable.
Starting it up takes half a minute, it's a bit slow at everything and
you'll have to remember to avoid using certain features: e.g. hitting
Ctrl-K (to delete a line) takes about 10 seconds; same goes for anything
that will (possibly as a side-effect) copy something to the clipboard.
In the end I moved to "emacs -nw" and forgot about X entirely.
Of course, on a LAN, it's a whole different story and I'm using
emacs/X/ssh everyday.
Just my two cents
bye
av.
Tim X
> David Kastrup <d...@gnu.org> writes:
>
>> p...@informatimago.com (Pascal J. Bourguignon) writes:
>>
>>> Tim X <ti...@nospam.dev.null> writes:
>>>
>>>> A few things to try ...
>>>>
>>>> 1. turn off tooltip mode
>>>
>>> Yes. Anything graphic.
>>>
>>>
>>>> 2. Try running with -nw to turn off X and only have a terminal UI
>>>> and see what the performance is like. this will let you know if
>>>> the problem is basic emacs or the X protocol stuff
>>>
>>> This is not useful, if you only work with text. The X protocol is
>>> not significantly worse than any other terminal protocol to send
>>> over text.
>>
Not my practical experience. When I run I don't use the menus, mouse or
toolbar. However, -nw is much faster than X. The only issue I've had is
with different local X terminals 'grabbing' some keys, making some key
combinations harder to achieve in the remote emacs. Depending on yhour
window manager and terminal emulator, it may be necessary to tweak
things to get the full list of keys to the remote emacs.
However, my recommendation for the OPs question is to run one of the X
compression protocols. X was designed for a LAN rather than a WAN and
has a lot of overhead. However, much of this is easily compressed.
In the past, on a 56k modem, I used dxcp with good results. Still a bit
slow, but usable. Anyone using DSL should get much better results.
There is also nxproxy, which I've not used, but which is based on the
concepts in dxcp.
Setting up dxcp was fairly trivial.
Russ P.
changing my strategy. I intend to use rsync and git to keep my home
and work computers synchronized. Then I will be able to use Emacs
locally and not worry about network delays. Maybe I should have done
this a while back, but better late than never. I just learned how to
use rsync through an ssh tunnel, and that is what I need (see my post
at comp.unix.shell on that).
I'd still like to see future versions of Emacs with improved network
performance. For whatever reason, XEmacs seems to do much better in
that regard.
Russ P.
Tim X
> Thanks for all the replies and suggestions. At this point, I am
> changing my strategy. I intend to use rsync and git to keep my home
> and work computers synchronized. Then I will be able to use Emacs
> locally and not worry about network delays. Maybe I should have done
> this a while back, but better late than never. I just learned how to
> use rsync through an ssh tunnel, and that is what I need (see my post
> at comp.unix.shell on that).
>
> I'd still like to see future versions of Emacs with improved network
> performance. For whatever reason, XEmacs seems to do much better in
> that regard.
>
If remote editing is all you require, tramp mode is really good. Once
you setup ssh and ssh-agent, all you need to do is
C-x C-f /hostname:path/to/file
I find setting the tramp cache directory to a local temp directory helps
on slow or unreliable ssh connections that drop out. A lot easier than
maintaining mirirs with rsynch (which is what I use to do).
If you need to use other tools on the files and want things to look like
they are local, sshfs is also useful.
Stefan Monnier
If you don't like it, then it qualifies to file a bug report.
> (Nor do I know, off hand, how to file a bug report.)
Menu "Help" entry "Send bug report..." should do it, as should M-x
report-emacs-bug. Note that it's also the right way to send
feature requests.
Stefan
Stefan Monnier
>> significantly worse than any other terminal protocol to send over text.
> Font rendering/antialiasing/composition nowadays happens mostly at the
> client side if I am not mistaken. That makes the X protocol much worse
> even with text.
Apparently it doesn't have to be that way: client-side rendering
requires sending pixmaps to the server, whereas server-side rendering
requires sending font-metadata to the client. Depending on the
particular situation either one can be faster than the other.
Apparently, if the pixmaps get appropriately cached, the amount of data
in either case, for some mythical "typical" situation, has been measured
to be comparable, while the client-side rendering benefits from the fact
the sending pixmaps to the server is much more latency-tolerant than
querying font metadata, which requires a lot round-tripping.
It sounded very counter-intuitive to me, but it came from some USENIX
article by one of the head X guys, IIRC.
Stefan
Stefan Monnier
>> essentially unusable for remote usage. I can't believe I am the only
>> one who has noticed this problem. Am I the only one who uses Emacs/
>> XEmacs to work remotely over ssh -X?
> I used to use emacs over X/ssh on remote links, but finally had to give up:
> with recent versions it has become almost unusable.
For Emacs-21, we made a specific effort to get remote use working
"efficiently", in response to complaints that it was a lot slower than
Emacs-20. I guess we need to do the same now.
The best for that is to give (via M-x report-emacs-bug) very concrete,
easy to reproduce steps that are noticably slower in Emacs-23 than in
Emacs-22 (or Emacs-21), so we can analyze the network traffic in those
two cases and try to improve it.
Stefan
des...@verizon.net
Giacomo Boffi
> As I explained a few days ago, I am trying to switch from XEmacs to
> Emacs so I can use Ensime (an Emacs-based IDE for Scala). I finally
> got my .emacs file debugged, but now I am finding that Emacs seems to
> be very slow when used remotely.
>
> When I work from home, I login from one Linux machine to another using
> ssh -X
is sshfs not an option for you?
Giacomo Boffi
> I used to use emacs over X/ssh on remote links, but finally had to
> give up: with recent versions it has become almost unusable.
> Starting it up takes half a minute, it's a bit slow at everything and
> you'll have to remember to avoid using certain features: e.g. hitting
> Ctrl-K (to delete a line) takes about 10 seconds; same goes for
> anything that will (possibly as a side-effect) copy something to the
> clipboard.
XEmacs had the same problem a few years ago but in the end a solution
was found, sorry i don't remember the exact details (available with
some searching on xemacs-beta archives)
des...@verizon.net
The clipboard issue was XEmacs using the X11 clipboard for kills.
A switch could turn it off.
I haven't noticed a similar issue with Emacs.
Some where in my .emacs I may still be turning it off.
Russ P.
I was not aware of it, but I'll check it out. Thanks.
Russ P.
I looked up sshfs, and it looks interesting. Before I go to the
trouble of installing it, can anyone tell me something about its
performance and how it should be used. Would I open Emacs locally on
my home machine and edit remote files? What are the delays like?
Thanks.
Russ P.
Tim X
I'll try to clarify things. I'm assuming you have ssh setup and use
ssh-agent (not strictly necessary, but makes life a lot easier by
avoiding the need to enter passwords when loging into the remote host)
You have three options for editing remote files using emacs.
1. Run emacs rmotely. This approach has given you performance issues.
You could get better performance running it without X support i.e.
issuing emacs -nw on the remote machine, but you then don't have menus
or full mouse support. If you still want to run reotely with X, you only
remaining option is to use one of the X compression protocols, such as
dxcp or nxproxy.
2. Use tramp to edit the files remotely. Run emacs on the local machine
as usual. When you want to edit a file on the remote host, just do
C-x C-f /remote-hostname:path/to/file/to/edit
There are a few tweaks you can do to improve performance, such as
setting a local temp directory, but it should just work 'out of the box'
(depending on your version of emacs). I've been using tramp mode for
about 8 years. It has been part of emacs for the last two or three
releases.
3. Use sshfs. This is similar in concept to using NFS. You 'mount' a
remote file system locally over the ssh protocol. The remote file system
is mounted on a local directory. You can then cd to that directory and
view/edit files as if they were local files. Of course, performance may
be a bit slower than a real local file due tot he ssh overhead
anddepending on your network stability, you can get drop outs.
Sometimes, you need to tweak the sshfs otptions to get the best
performance and you may need to turn on auto-reconnect etc.
As this makes the remote filesystem appear as a local filesystem to the
OS, you just edit the files as if they were local files.
I find this option very useful when I want to manipulate the files with
other non-emacs tools. If I only want to edit the file, tramp is easier.
Performance is difficult to quantify as it depends a lot on your network
connection. I use a pretty fast DSL link and connect using ssh inside an
SSL VPN tunnel. With either tramp or sshfs, the only time you notice any
delay is when you first open the file and when you save it - the delay
is small, though of course it can be longer if you have other network
activity happening at the same time you open/save a file (i.e. mail
download, web browsing etc). To get optimal performance, depending on
your environment, you may need to tweak things. However, I've found most
of the time, the defaults work fine.
Giacomo Boffi
> On Sep 24, 8:45 am, Giacomo Boffi <giacomo.bo...@polimi.it> wrote:
>> "Russ P." <russ.paie...@gmail.com> writes:
>> > As I explained a few days ago, I am trying to switch from XEmacs to
>> > Emacs so I can use Ensime (an Emacs-based IDE for Scala). I finally
>> > got my .emacs file debugged, but now I am finding that Emacs seems to
>> > be very slow when used remotely.
>>
>> > When I work from home, I login from one Linux machine to another using
>> > ssh -X
>>
>> is sshfs not an option for you?
>
> I looked up sshfs, and it looks interesting. Before I go to the
> trouble of installing it, can anyone tell me something about its
> performance and how it should be used.
here i am
> Would I open Emacs locally on my home machine and edit remote files?
yes, you "cd mount_point" and the it's normal editing
> What are the delays like?
if you're on a link barely not fast enough for X, very short
the real difference between sshfs and tramp is that sshfs is
transparent to all programs, tramp is only for emacs
if Ensime uses external utilities, sshfs would seem more appropriate
--
la panna resta piů pannosa. -- Ruggine, in IHC
Stefan Monnier
> transparent to all programs, tramp is only for emacs
Another difference is that with Tramp, you can have processes (like M-x
compile) running on the remote host, which may be much better or much
worse, depending on what you need.
Stefan
Giacomo Boffi
>> the real difference between sshfs and tramp is that sshfs is
>> transparent to all programs, tramp is only for emacs
>
> Another difference is that with Tramp, you can have processes (like
> M-x compile) running on the remote host,
that's interesting... does it work with auctex too?
tia
g
Stefan Monnier
>>> transparent to all programs, tramp is only for emacs
>> Another difference is that with Tramp, you can have processes (like
>> M-x compile) running on the remote host,
> that's interesting... does it work with auctex too?
No idea: try it and if it doesn't work, report it to the AUCTeX
maintainers: it's easy to make it work (typically replace call-process
by process-file or start-process by start-file-process).
Stefan
mgr...@gmail.com
>
> > As I explained a few days ago, I am trying to switch from XEmacs to
> > Emacs so I can use Ensime (an Emacs-based IDE for Scala). I finally
> > got my .emacs file debugged, but now I am finding that Emacs seems to
> > be very slow when used remotely.
> >
> > When I work from home, I login from one Linux machine to another using
> > an X terminal for my work machine. I am using Emacs 23.2.1 on Red Hat.
> > I am finding that opening a file or switching buffers by middle-
> > clicking in dired or the buffer menu takes approximately 20-30
> > seconds. With XEmacs it takes less than one second. I hope I am doing
> > something wrong that can be corrected, because I'll grow old sitting
> > around that long every time I open a file or switch buffers. Any
> > suggestions? Thanks.
>
>
> Emacs seems a little over-active in dired-mode.
>
> I'm running at least one emacs remotely too.
>
> Just hovering over a name in dired causes a packet storm.
> My first guess was that it was tooltip-mode so I toggled that
> off.
>
> Dired is still doing something during hover though
> in the mode line it tries to tell me which button to push.
> Each time it does that, I get a mini-packet storm.
> (I can see my packet monitor graph move up.)
>
> Maybe someone knows how to kill over active help in Dired?
I was having the same problem using this version:
GNU Emacs 23.1.1 (x86_64-redhat-linux-gnu, GTK+ Version 2.18.9)
after recompiling with the latest version, the problem was still present:
GNU Emacs 24.3.4 (x86_64-unknown-linux-gnu, GTK+ Version 2.18.9)
I have worked around it by setting mouse-highlight to nil. So it guess that it is a problem with the mouse highlighting and ssh -X.
Bob Proulx
> El martes, 21 de septiembre de 2010 03:40:53 UTC+2, des...@verizon.net escribió:
> > "Russ P." writes:
> > Emacs seems a little over-active in dired-mode.
> guess that it is a problem with the mouse highlighting and ssh -X.
I don't think it is that reasonable to expect an X program to be
snappy fast over a high latency WAN connection. There are many
issues with throwing a display remotely. Many programs have been
written to try to optimize it. But it remains a hard problem.
Instead I definitely recommend that you try using emacs in text mode.
That is the original operation mode. It is really quite a fine
terminal screen editor. The performance of throwing whold characters
over the Internet will be much better than throwing pixels over the
Internet.
Bob
Drew Adams
I.e., not `M-x text-mode'. HTH.)
Bob Proulx
latency WAN can be terrible. And even on a relatively lower latency
connection WAN it isn't great even when it is good. Better to avoid
the issue entirely. Simply log in with an ssh connection in a text
terminal and then run emacs in that same text terminal window.
And although I find it somewhat slow I think everyone who is working
on remote systems should check out emacs tramp as well. It is
definitely a good tool for remote edits.
Bob
Dan Espen
Turning off tool tips helps a lot:
(tooltip-mode nil)
but Emacs could do better.
This came up a while back and my opinion hasn't changed.
Emacs should have an option that turns off all hover detection.
Tracking enter and leave is too slow for remote use and isn't
necessary for dired, mode lines, buffer lists.
--
Dan Espen
Manuel Gómez
When I found it by my own experimentation I wanted to share it with the
other possible sufferers. I suspect the original poster and I are not
the only ones.
> It may be true that the display code is very inefficient there. But
> I don't think it is that reasonable to expect an X program to be
> snappy fast over a high latency WAN connection. There are many
> issues with throwing a display remotely. Many programs have been
> written to try to optimize it. But it remains a hard problem.
disabled, it runs smoothly.
>
> Instead I definitely recommend that you try using emacs in text mode.
> That is the original operation mode. It is really quite a fine
> terminal screen editor. The performance of throwing whold characters
> over the Internet will be much better than throwing pixels over the
> Internet.
loose other graphical features when it is not needed. But I agree with
you that a modern Emacs is also very good in the terminal.
Bob Proulx
> Bob Proulx escribió:
>
> I found the description of my problem while searching for a
> solution. When I found it by my own experimentation I wanted to
> share it with the other possible sufferers. I suspect the original
> poster and I are not the only ones.
>
> > It may be true that the display code is very inefficient there. But
> > I don't think it is that reasonable to expect an X program to be
> > snappy fast over a high latency WAN connection. There are many
> > issues with throwing a display remotely. Many programs have been
> > written to try to optimize it. But it remains a hard problem.
>
> This is the only interaction that it is slow over this connection.
> Once disabled, it runs smoothly.
to be improved and fixed.
> > Instead I definitely recommend that you try using emacs in text mode.
> > That is the original operation mode. It is really quite a fine
> > terminal screen editor. The performance of throwing whold characters
> > over the Internet will be much better than throwing pixels over the
> > Internet.
>
> I prefer disabling only the mouse-highlight feature. I wouldn't like
> to loose other graphical features when it is not needed.
happy to hear that you have a compromise that works for you.
> But I agree with you that a modern Emacs is also very good in the
> terminal.
You included the word "modern" there. But emacs has been used on
terminals for decades. An ancient emacs is very good in the terminal!
That is the foundation upon which the graphical version is built upon.
Of course a modern one still works well too. Not as well as it used
to work. I have some terminal regressions that have been nagging at
me that I need to report. And so I would have to say that the older
emacs worked better at the terminal than the modern one. Though the
modern one is still very good. In my not so humble opinion your
statement would have been perfect if you hadn't said "modern" there. :-)
Bob
Kenneth Jacker
Which function(s)/variable(s) configure "mouse highlighting"?
I tried to find something with "C-h a" and other things,
but couldn't find any help.
Thanks,
--
Prof Kenneth H Jacker k...@cs.appstate.edu
Computer Science Dept www.cs.appstate.edu/~khj
Appalachian State Univ
Boone, NC 28608 USA
Manuel Gómez
El 24/11/13 17:17, Kenneth Jacker escribi�:
> Which function(s)/variable(s) configure "mouse highlighting"?
>
> I tried to find something with "C-h a" and other things,
> but couldn't find any help.
mouse-highlight" and you will be able to customize it from there.
By the way, anyone knows whether is possible to disable only the text
background highlighting without disabling also the shape change of the
mouse pointer over links? I don't know anything about the X protocol but
I guess that this graphic feedback is more optimal than the font
background highlight, which might be the only responsible of the
performance problem.
Ken Goldman
>
>> It may be true that the display code is very inefficient there. But
>> I don't think it is that reasonable to expect an X program to be
>> snappy fast over a high latency WAN connection. There are many
>> issues with throwing a display remotely. Many programs have been
>> written to try to optimize it. But it remains a hard problem.
>
> This is the only interaction that it is slow over this connection. Once
> disabled, it runs smoothly.
- Run emacs locally and access remote files using tramp
- Run a vnc client/server and run in that window
vnc is 'snappy', even with a remote connection through a VPN tunnel.
Peter Dyballa
Am 27.11.2013 um 18:58 schrieb Ken Goldman:
> - Run a vnc client/server and run in that window
--
Greetings
Pete
Remember: use logout to logout.
Bob Proulx
> Am 27.11.2013 um 18:58 schrieb Ken Goldman:
> > - Run a vnc client/server and run in that window
>
> Doesn't it have problems with characters outside the limited US-ASCII range?
Perhaps you are thinking of something other than VNC?
Bob
Stefan Monnier
> Once disabled, it runs smoothly.
performance over the network, usually, so it may be a simple issue
that's easy to fix.
If you can give a recipe to reproduce the slow behavior, then we can
look at the network traffic and try to understand what's causing
the slowdown.
Stefan
Peter Dyballa
Am 28.11.2013 um 03:34 schrieb Bob Proulx:
> Perhaps you are thinking of something other than VNC?
OK, I'll try free products!
--
Greetings
Pete
If all else fails read the instructions.
- Donald Knuth
Bob Proulx
> schrieb Bob Proulx:
> > > US-ASCII range?
> >
>
> I had this bad experience with a commercial product… And I also have
> similar experience with system virtualisation products. As long as I
> use US-ASCII they work… somehow.
>
> OK, I'll try free products!
Because the entire concept caused me to take pause. My brain made a
funny face and went huh? Let me say some words here about VNC and it
will probably be just noise. But I think there is probably
environment differences when used between us.
In a Unix like system we are mostly talking about X for graphics. It
is a bit mapped display. Objects are rendered using a software
rendering engine. Characters are displayed using a selected font.
Depending upon the font rendering will be bit-mapped or scaled or
perhaps something different. This is all somewhat a fuzzy
description. Don't look too closely at the details. Just the higher
level view of things.
VNC creates a virtual display very much the same as X. But where X
has an actual display VNC doesn't need any physical display. VNC is a
virtual display. We then use a client to connect between the virtual
display and a physical display. On my monitor I will see X as the
host display and then, say, a smaller rectangle will be the VNC
display. (Might be full screen. Might be larger than full screen
with scrolling needed.) A graphics display within a graphics
display. Layers and layers. (Used to be we would say layers like an
onion. But ever since the movie Shrek we now might say layers like an
ogre.)
When using VNC everything is graphical. I have a layered graphical
desktop within a graphical desktop. The host desktop will be running
a window manager and the "inner" VNC desktop will be running a window
manager. (I usually make them different window managers so that they
look much different. It helps my brain know which is which. Because
it is easy to confuse local windows with remote windows.)
In the remote VNC desktop I can start up any manor of graphical
client. There are lots of uses. My main use for it is to start up a
web browser on the remote computer sitting in a private network behind
restrictive firewalls. The browser there can then access resources
available only on the inner side of the firewall. The graphical
display of it will be available to me outside the firewall using VNC
to transport the display from there to here[1]. When I want to see a
graphical display of exactly what I would see if I were sitting on
that remote network then I always use VNC for it.
When X is used to throw the display across the network it does so
using the X protocol. That isn't a very efficient protocol. It says
things like color #RGB numbers, X Y coordinates, color #RGB numbers, X
Y coordinates. It is a quite low level and brute force protocol.
Lots of X protocol accelerators exist to try to compress the data
stream such as stacking up a run of the same color and so forth but
there is only so much that they can do. The VNC server and client
exchange data using a different protocol. I looked just now to
remember the name of it and see that it is RFB the remote framebuffer
protocol. It was designed by the same folks who did VNC and I think
for VNC use. It also has variations of stream compressors. VNC is
definitely faster over the WAN than native X. But while VNC is faster
it still isn't perfectly fast. I know one comment in this thread was
that emacs in graphical mode was snappy fast that way. I am sure it
is faster than X. But I still don't find that to be the most
efficient way for me because it isn't fast enough. :-) It all depends
upon the latency between the client and server that you are using and
perhaps I am unfortunate to have a higher latency connection than most
at around 80ms. If you can get down in the 10ms or less range then
you probably think it is very fast indeed. If someone is committed to
using a graphical emacs then I would definitely try it in a VNC
session to see if that was better.
So when you say that it has problems with characters outside of the
US-ASCII range my immediate thought was everything is graphical and
what does the character range have to do with it? It is all just
pixels at that point. Must be talking about something else. But
maybe not. Probably not the character range but it might have
something to do with the font which is related.
Because with VNC I have seen some strange graphical artifacts over the
years. Usually when working with mixes of the various servers and
clients such as RealVNC and TightVNC. RealVNC is the original.
TightVNC is a fork of the code with additional optimizations for
performance. I used to always use TightVNC because it was faster than
RealVNC. But recently I have had to switch back to RealVNC because
TightVNC has been giving me strange graphical artifacts. Things like
black boxes and pull down menus that are blank and things like text
boxes with unreadable small white boxes instead of text. And so I
switched back to RealVNC. Bugs for sure. But I am just a VNC user
and I am not going to find and fix them.
I think it is possible that you are seeing some type of artifact in
the same way. It might even be related to the fonts too. Because it
might be related to the font rendering engine. Don't know. It can
give wierd results that defy easy description. And then there are the
commercial products you mentioned (such as NoMachine NX) and other
products. I will just say that conceptually they are similar and
either work or don't (mostly they work fine just as VNC works fine) in
similar ways.
And there is my noise to add to the conversation. Hopefully it wasn't
too noisy.
Bob
[1] It is actually more complicated than that. If I were only wanting
to run a web browser such as Firefox or Chromium then I usually tunnel
a proxy connection through over ssh instead. Then set up the http
proxy configuration on the browser to use the tunnel to the private
side of the network. The result is a much faster browsing experience
since my browser is then on the native desktop. The local graphics is
fast and the result just acts like the slow WAN network that it is.
But instead the problem is usually needing to run a specific version
of MS-IE accessing a private resources that requires ActiveX in
exactly MS-IE 6 and does not function with any other web browser.
Sigh. Of course MS-IE 6 runs on Windows. Therefore after setting up
VNC on the private side of the firewall network then I would rdesktop
over to a Windows terminal server on that side of the LAN. That
creates a third layered graphical display! Windows, VNC, my X
display. Each has its own window manager. (Layers like an ogre.) In
the MS Windows remote desktop display I would run IE and do the
required tasks. Not a pretty situation. Rather amazing that it all
works.
Peter Dyballa
Am 28.11.2013 um 20:48 schrieb Bob Proulx:
> So when you say that it has problems with characters outside of the
> US-ASCII range my immediate thought was everything is graphical and
> what does the character range have to do with it? It is all just
> pixels at that point.
I think of installing TigerVNC and TightVNC, which both need (Real?)VNC to be installed.
--
Greetings
Pete
They're putting dimes in the hole in my head to see the change in me.
Bob Proulx
> Am 28.11.2013 um 20:48 schrieb Bob Proulx:
> > So when you say that it has problems with characters outside of the
> > US-ASCII range my immediate thought was everything is graphical and
> > what does the character range have to do with it? It is all just
> > pixels at that point.
>
> I don't think that pressing a key is a bunch of pixels – I mean
> outside of a virtual reality, that what some folks call real life.
have never seen a key input problem. Of course that doesn't mean that
they don't exist. It just means that I haven't ever seen them while
supporting myself and others using it. I rarely input those
characters but others I work with who use VNC do and I would have
expected to have heard them complain if they were having problems.
But I have seen graphics artifacts very much too often. That is
definitely a problematic area. So I jumped to the conclusion that you
were talking about the display of non-ascii characters.
But from this I read that you have had problems inputing non-ascii
characters when using VNC?
> I think of installing TigerVNC and TightVNC, which both need
> (Real?)VNC to be installed.
the most stable for me. I recommend it as the reference platform to
compare any others against. YMMV.
TightVNC is an extension of RealVNC that adds the "Tight" extensions
and other useful features. Its main advantage being performance due
to data stream compression. It is completely self contained.
TightVNC as I understand it was created due to developers wanting
faster development than RealVNC since RealVNC development is very
mature, stable, doesn't accept patches very quickly, and does not
change very often.
Installing TightVNC does not need RealVNC installed. If you install
TightVNC then you should have everything you need all in one place.
This is just the same as installing RealVNC. Both TightVNC and
RealVNC can be installed side by side and either used independently of
the other.
TigerVNC is a fork of TightVNC. TigerVNC as I understand it was
created due to developers wanting faster development than available
through TightVNC and/or they had differences of opinion with the
TightVNC developers. I wasn't following the development there and am
a little fuzzy on the details. In any case Tiger is a fork of Tight
and as far as I know is also self contained. I haven't used it but it
should be installable side by side with either of the other others
too.
Personally I have had the most reliable success using RealVNC. At one
time the performance advantage of TightVNC was very attractive and I
used it in preference due to this. In the last two years I have been
having graphics artifacts with TightVNC and so have reverted to using
RealVNC. I haven't investigated further since the other worked and
the performance issue was no longer a driving factor for me since I
was doing less with it. YMMV. I say try each of them and make your
own evaluations. For best performance both client and server should
be the same flavor.
Bob
Perry Smith
On Nov 29, 2013, at 12:56 PM, Bob Proulx <b...@proulx.com> wrote:
> Peter Dyballa wrote:
>> Am 28.11.2013 um 20:48 schrieb Bob Proulx:
>>> So when you say that it has problems with characters outside of the
>>> US-ASCII range my immediate thought was everything is graphical and
>>> what does the character range have to do with it? It is all just
>>> pixels at that point.
>>
>> I don't think that pressing a key is a bunch of pixels – I mean
>> outside of a virtual reality, that what some folks call real life.
>
> In all of the time I have been using the various VNC implementations I
> have never seen a key input problem. Of course that doesn't mean that
> they don't exist.
paste from one application into emacs (yank actually) and emacs
is running inside a VNC server window. I asked about this about
a month ago with no reply. I've not had time to track it down. It
started somewhere in 24. I'm using RealVNC server and either
the RealVNC client or JollyVNC. The emacs and VNC server
are running on AIX 6.1.
I've also noticed that magit on this set up if painfully slow as if it is
polling the dog @#%^ out of something. I've not had time to
track that down either. It is slow only for a brief time and I have
so far just endured.
Perry
Peter Dyballa
Am 30.11.2013 um 16:23 schrieb Perry Smith:
> I've also noticed that magit on this set up if painfully slow
--
Greetings
Pete
Mac OS X is like a wigwam: no fences, no gates, but an apache inside.
Perry Smith
On Nov 30, 2013, at 5:03 PM, Peter Dyballa <Peter_...@Web.DE> wrote:
>
> Am 30.11.2013 um 16:23 schrieb Perry Smith:
>
>> I've also noticed that magit on this set up if painfully slow
>
> Are both AIX machine similar in performance, from the CPU as from the graphics card and other hardware?
As far as comparing it, for example, with my Mac laptop, it is not as fast and the AIX host has
essentially no graphics adapter with any type of GPU on it. But magit (or emacs for that matter)
isn't particularly graphics intense is it?
Perry