5:10 a.m.
Hello, Everyone
For quite a while now, Emacs has ceased being useable on our system.
For example, if I run "emacs .bashrc" in a terminal, Emacs starts up as
expected, but the file cannot be edited. I can use the mouse to select
text in the portion of the file that is actually displayed in the
terminal, but I cannot move the cursor(?) or delete/add/change any text.
I have the following alias in ~/.bashrc that has worked perfectly for me
for quite a while:
alias emacs="unset DISPLAY && emacs"
If I just run "/usr/bin/emacs" from a terminal the graphical version of
Emacs opens the file file, and I can edit it as I wish. I do NOT have
xemacs installed on this system.
So, the way this is working for me now, if I want to use Emacs in a
non-graphical console session, I am out of luck. It does not make any
difference what user I am logged in as, the problem is the same. Also,
here is the permissions on the file that I used earlier as my example:
-rw-r--r-- 1 steve steve 6.9K May 23 04:50 .bashrc
So, permissions do not seem to be an issue.
I am running Fedora 16, fully updated. "yum list | grep -i emacs" shows
the following RPM's as being installed:
emacs.x86_64 1:23.3-9.fc16 @updates
emacs-common.x86_64 1:23.3-9.fc16 @updates
emacs-filesystem.x86_64 1:23.3-9.fc16 @updates
emacs-git.noarch 1.7.7.6-1.fc16 @updates
emacs-nox.x86_64 1:23.3-9.fc16 @updates
xemacs-filesystem.noarch 21.5.31-2.fc16 @fedora
Also, I have not been able to find this issue on Google or at
bugzilla.redhat.com.
Thank you,
Steven P. Ulrick
6:57 a.m.
Hi Steven,
On Thu, May 24, 2012 at 11:34 PM, Steven Ulrick <meow8282(a)gmail.com> wrote:
The results were interesting:
1. Rebuilding emacs-24.0.97-1.fc18.src.rpm and changing "resolv=no" to
"resolv=yes" results in my problem being fixed! Emacs works perfectly
for me rebuilding this SRPM with the noted change.
2. Rebuilding emacs-24.0.97-1.fc18.src.rpm and NOT changing
"resolv=no" to "resolv=yes" results in my problem NOT being fixed.
I think this is still worth reporting on the Emacs bug tracker. I
would encourage you to report the problem and let the developers
decide if its worthy of a bugfix.
Thanks,
--
Suvayu
Open source is the future. It sets us free.
4:34 p.m.
On Thu, May 24, 2012 at 1:54 PM, Steven Ulrick <meow8282(a)gmail.com> wrote:
Hello, Everyone
Going off the suggestion that someone made about Emacs having issues
with resolving hostnames, I grabbed the SRPM of emacs from Rawhide,
changed a line that said "resolv=no" to "resolv=yes" and rebuilt it.
When I updated to those newly build RPM's of Emacs and attempted to
see if the problem was still occuring, I discovered that the problem
is fixed!
I accidentally grabbed the Rawhide SRPM of Emacs. So, for kicks, I'm
going to try rebuilding the Fedora 16 SRPM of emacs with NO changes
whatsoever, and then I will try rebuilding the Rawhide version again,
this time NOT changing "resolv=no" to "resolv=yes" This way I will
find out if the change I made really had anything to do with fixing
the problem...
Hello, Everyone
The results were interesting:
1. Rebuilding emacs-24.0.97-1.fc18.src.rpm and changing "resolv=no" to
"resolv=yes" results in my problem being fixed! Emacs works perfectly
for me rebuilding this SRPM with the noted change.
2. Rebuilding emacs-24.0.97-1.fc18.src.rpm and NOT changing
"resolv=no" to "resolv=yes" results in my problem NOT being fixed.
3. Rebuilding emacs-23.3-9.fc16.src.rpm does NOT work for me at all.
Making the same changes referred to in points 1 & 2 above results in
me still having the same problem with Emacs that I've had for a long
time now...
So, I guess I will keep running the Emacs that I got by rebuilding
emacs-24.0.97-1.fc18.src.rpm and changing "resolv=no" to "resolv=yes"
in "configure"
Thanks to everyone for your time and advice,
Steven P. Ulrick
1:54 p.m.
On Wed, May 23, 2012 at 5:10 AM, Steven P. Ulrick <meow8282(a)gmail.com> wrote:
Hello, Everyone
For quite a while now, Emacs has ceased being useable on our system. For
example, if I run "emacs .bashrc" in a terminal, Emacs starts up as
expected, but the file cannot be edited. I can use the mouse to select text
in the portion of the file that is actually displayed in the terminal, but I
cannot move the cursor(?) or delete/add/change any text.
I have the following alias in ~/.bashrc that has worked perfectly for me for
quite a while:
alias emacs="unset DISPLAY && emacs"
If I just run "/usr/bin/emacs" from a terminal the graphical version of
Emacs opens the file file, and I can edit it as I wish. I do NOT have
xemacs installed on this system.
So, the way this is working for me now, if I want to use Emacs in a
non-graphical console session, I am out of luck. It does not make any
difference what user I am logged in as, the problem is the same. Also, here
is the permissions on the file that I used earlier as my example:
-rw-r--r-- 1 steve steve 6.9K May 23 04:50 .bashrc
So, permissions do not seem to be an issue.
Hello, Everyone
Going off the suggestion that someone made about Emacs having issues
with resolving hostnames, I grabbed the SRPM of emacs from Rawhide,
changed a line that said "resolv=no" to "resolv=yes" and rebuilt it.
When I updated to those newly build RPM's of Emacs and attempted to
see if the problem was still occuring, I discovered that the problem
is fixed!
I accidentally grabbed the Rawhide SRPM of Emacs. So, for kicks, I'm
going to try rebuilding the Fedora 16 SRPM of emacs with NO changes
whatsoever, and then I will try rebuilding the Rawhide version again,
this time NOT changing "resolv=no" to "resolv=yes" This way I will
find out if the change I made really had anything to do with fixing
the problem...
Steven P. Ulrick
6:11 a.m.
On 05/23/2012 05:15 PM, Wolfgang S. Rupprecht wrote:
Steven Ulrick <meow8282(a)gmail.com> writes:
> On Wed, May 23, 2012 at 5:10 AM, Steven P. Ulrick <meow8282(a)gmail.com> wrote:
>> Hello, Everyone
>> For quite a while now, Emacs has ceased being useable on our system. For
>> example, if I run "emacs .bashrc" in a terminal, Emacs starts up as
>> expected, but the file cannot be edited. I can use the mouse to select text
>> in the portion of the file that is actually displayed in the terminal, but I
>> cannot move the cursor(?) or delete/add/change any text.
>> I have the following alias in ~/.bashrc that has worked perfectly for me for
>> quite a while:
>> alias emacs="unset DISPLAY && emacs"
emacs hangs for a long timeout if there's a problem resolving the name
of the local machine.
Andrew.
4:10 a.m.
Hi Steven,
On Wed, May 23, 2012 at 10:41 PM, Steven Ulrick <meow8282(a)gmail.com> wrote:
> If its a local problem (1 & 2 above), while debugging you can start
> emacs with the flag --debug-init to get a backtrace. This should help
> you track down the problem.
I just tried that and I am embaressed to ask, where will I find the
resulting backtrace? If it is supposed to be sent to the terminal,
the problem that I am having seems to prevent me seeing a backtrace...
If it is located elsewhere, I am not able to find it's location.
Sorry my suggestion wasn't complete. Since its not the typical elisp
error, you will need to trigger the backtrace with something like `C-g'.
If that does not help, I would recommend you start emacs like this[1]:
$ emacs -nw -Q
Then in your scratch buffer evaluate the following:
(setq debug-on-error t
debug-on-signal nil
debug-on-quit nil)
If your emacs is unresponsive and you can't type in your scratch buffer,
you could also try putting the above in a file, say minimal-init.el and
start emacs as:
$ emacs -nw -Q -l /path/to/minimal-init.el
Once emacs is running, try to trigger the backtrace with `C-g'. You can
post the backtrace[2] on some paste bin and provide a link to the list.
If this does not help tracking down the problem, I would suggest posting
to <bug-gnu-emacs(a)gnu.org> since we have already established its a
problem with your bare bones emacs.
GL
Footnotes:
[1] Lets leave out the alias bit for now, the simpler the test case,
easier it is to debug.
[2] There might be some unintelligible characters in the backtrace, you
can ignore them for now.
--
Suvayu
Open source is the future. It sets us free.
9:59 a.m.
Hi Steven,
On Wed, May 23, 2012 at 12:10 PM, Steven P. Ulrick <meow8282(a)gmail.com> wrote:
alias emacs="unset DISPLAY && emacs"
You can always use "emacs -nw" for nox.
Now to your problem, can you replicate it with "emacs -Q" if not, is it
reproducible by "emacs -q"? If the problem can only be reproduced by
invoking emacs as,
1. "emacs": the problem is in your emacs setup, check your ~/.emacs
2. "emacs -q": check your site files
3. "emacs -Q": report a bug on the emacs bug tracker
If its a local problem (1 & 2 above), while debugging you can start
emacs with the flag --debug-init to get a backtrace. This should help
you track down the problem.
GL
--
Suvayu
Open source is the future. It sets us free.
3:42 p.m.
On Wed, May 23, 2012 at 11:15 AM, Wolfgang S. Rupprecht
<wolfgang.rupprecht(a)gmail.com> wrote:
Steven Ulrick <meow8282(a)gmail.com> writes:
> On Wed, May 23, 2012 at 5:10 AM, Steven P. Ulrick <meow8282(a)gmail.com> wrote:
>> Hello, Everyone
>> For quite a while now, Emacs has ceased being useable on our system. For
>> example, if I run "emacs .bashrc" in a terminal, Emacs starts up as
>> expected, but the file cannot be edited. I can use the mouse to select text
>> in the portion of the file that is actually displayed in the terminal, but I
>> cannot move the cursor(?) or delete/add/change any text.
>> I have the following alias in ~/.bashrc that has worked perfectly for me for
>> quite a while:
>> alias emacs="unset DISPLAY && emacs"
Does "emacs -nw" work any better? How about "emacs -nw -Q" ?
Nope, neither one of those options work...
3:41 p.m.
On Wed, May 23, 2012 at 9:59 AM, suvayu ali <fatkasuvayu+linux(a)gmail.com> wrote:
Hi Steven,
On Wed, May 23, 2012 at 12:10 PM, Steven P. Ulrick <meow8282(a)gmail.com> wrote:
> alias emacs="unset DISPLAY && emacs"
You can always use "emacs -nw" for nox.
Just tried that, and I still have
the problem. Cursor will not move,
and the file cannot be edited.
Now to your problem, can you replicate it with "emacs -Q"
Yes, I can replicate the problem with "emacs -Q"
if not, is it reproducible by "emacs -q"? If the problem
can only
be reproduced by invoking emacs as,
1. "emacs": the problem is in your emacs setup, check your ~/.emacs
I had
already done "rm -rf .emacs" The problem still persists...
2. "emacs -q": check your site files
3. "emacs -Q": report a bug on the emacs bug tracker
The problem persists with trying all of the above options with my
alias in "~/.bashrc":
alias emacs="unset DISPLAY && emacs"
With "alias emacs="unset DISPLAY && emacs"" commented out in
my
.bashrc, the x-window variety of emacs opens. So, no change there.
And like I said in my original message on this subject, I cannot use
Emacs at all unless I am running X-Windows.
If its a local problem (1 & 2 above), while debugging you can
start
emacs with the flag --debug-init to get a backtrace. This should help
you track down the problem.
I just tried that and I am embaressed to ask, where
will I find the
resulting backtrace? If it is supposed to be sent to the terminal,
the problem that I am having seems to prevent me seeing a backtrace...
If it is located elsewhere, I am not able to find it's location.
Just a reminder about the fact that when I try to start Emacs with my
desired (and formerly working) alias, one of the four cores on my CPU
maxes out to 100% until I kill Emacs...
Thank you for your help so far :)
Steven P. Ulrick
11:15 a.m.
Steven Ulrick <meow8282(a)gmail.com> writes:
On Wed, May 23, 2012 at 5:10 AM, Steven P. Ulrick
<meow8282(a)gmail.com> wrote:
> Hello, Everyone
> For quite a while now, Emacs has ceased being useable on our system. For
> example, if I run "emacs .bashrc" in a terminal, Emacs starts up as
> expected, but the file cannot be edited. I can use the mouse to select text
> in the portion of the file that is actually displayed in the terminal, but I
> cannot move the cursor(?) or delete/add/change any text.
> I have the following alias in ~/.bashrc that has worked perfectly for me for
> quite a while:
> alias emacs="unset DISPLAY && emacs"
Does "emacs -nw" work any better? How about "emacs -nw -Q" ?
-wolfgang
--
g+: https://plus.google.com/114566345864337108516/about
5:20 a.m.
On Wed, May 23, 2012 at 5:10 AM, Steven P. Ulrick <meow8282(a)gmail.com> wrote:
Hello, Everyone
For quite a while now, Emacs has ceased being useable on our system. For
example, if I run "emacs .bashrc" in a terminal, Emacs starts up as
expected, but the file cannot be edited. I can use the mouse to select text
in the portion of the file that is actually displayed in the terminal, but I
cannot move the cursor(?) or delete/add/change any text.
I have the following alias in ~/.bashrc that has worked perfectly for me for
quite a while:
alias emacs="unset DISPLAY && emacs"
If I just run "/usr/bin/emacs" from a terminal the graphical version of
Emacs opens the file file, and I can edit it as I wish. I do NOT have
xemacs installed on this system.
So, the way this is working for me now, if I want to use Emacs in a
non-graphical console session, I am out of luck. It does not make any
difference what user I am logged in as, the problem is the same. Also, here
is the permissions on the file that I used earlier as my example:
-rw-r--r-- 1 steve steve 6.9K May 23 04:50 .bashrc
So, permissions do not seem to be an issue.
I am running Fedora 16, fully updated. "yum list | grep -i emacs" shows the
following RPM's as being installed:
emacs.x86_64 1:23.3-9.fc16 @updates
emacs-common.x86_64 1:23.3-9.fc16 @updates
emacs-filesystem.x86_64 1:23.3-9.fc16 @updates
emacs-git.noarch 1.7.7.6-1.fc16 @updates
emacs-nox.x86_64 1:23.3-9.fc16 @updates
xemacs-filesystem.noarch 21.5.31-2.fc16 @fedora
Also, I have not been able to find this issue on Google or at
bugzilla.redhat.com.
Almost forgot, when I start emacs, "ps aux | grep -i emacs" looks like this:
steve@localhost ~$ ps aux | grep -i emacs
steve 6607 101 0.1 260220 13468 pts/2 R+ 05:16 0:39 emacs .bashrc
the first core of my quad core processor is maxed out, and if I "kill
6607" that core immediately goes back to normal...
4395
days inactive
4397
days old
10 comments
4 participants
participants (4)
-
Andrew Haley -
Steven P. Ulrick -
Suvayu Ali -
Wolfgang S. Rupprecht