Peter Seibel [EMAIL PROTECTED] writes:
Okay, here's another strange one which has happened a few times. I'll
get an error in the minibuffer that says:
Symbol's value as variable is void: nil
No matter what I do I continue to get that error or something similar
such as:
Error in
Richard Stallman [EMAIL PROTECTED] writes:
this works, but after some time emacs hangs.
I attached gdb and found it hangs around here:
Program received signal SIGTSTP, Stopped (user).
0x0819f18a in truncate_undo_list (b=0x9430a08) at undo.c:366
Of course, that will
Hi,
Stefan Monnier [EMAIL PROTECTED] schrieb am 05.04.05 00:52:22:
- Load a vhdl file
- Divide emacs into two windows vertically, both showing the same buffer
- Jump to the end of the buffer in the upper window
- Switch to the lower window, near the beginning
- Type signal (with a
Richard Stallman [EMAIL PROTECTED] writes:
I think the current situation is best, it fixed the bug that the behavior
was different when loading the .el file than when loading the .elc file.
Sorry, I've decided I won't let this change remain installed.
We will not move towards
Jan D. [EMAIL PROTECTED] writes:
That is truly odd. How come the XIM code doesn't trigger this
same problem?
I think the XIM code explicitly names the charset it wants.
But our XIM code calls XCreateFontSet, just like Xt code.
And browsing the Xt source, the Cannot convert string to
A recent CVS build (22.0.50.6, 2005-03-29) fails to run on OS X 10.4
(Tiger). If the Carbon binary is run from the command line, the user
gets
Warning: arch-dependent data dir
(/usr/local/libexec/emacs/22.0.50/powerpc-apple-darwin7.8.0/) does not
exist.
Fatal error (6)Abort trap
There is no
Very occasionally I find that my Emacs environment gets into a state
when most operations I try to do result in a Lisp nesting exceeds
max-lisp-eval-depth error. I've no idea what triggers this
condition, and killing the Emacs process (for 'save-buffers-kill-emacs'
is one of the operations which
[EMAIL PROTECTED] (Kim F. Storm) writes:
Peter Seibel [EMAIL PROTECTED] writes:
Okay, here's another strange one which has happened a few times. I'll
get an error in the minibuffer that says:
Symbol's value as variable is void: nil
No matter what I do I continue to get that error or
$ ./missfonts
$ ./missfonts -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*
Missing 0: ISO8859-1
$ ./missfonts -*-helvetica-medium-r-*--*-120-*-*-*-*,*
Missing 0: ISO8859-1
The xfs configuration doesn't list any ISO8859-1 fonts:
Somewhere, specifying UTF-8 requires ISO8859-1 ?
So it seems
Peter Seibel [EMAIL PROTECTED] writes:
What does M-x list-processes show ?
When? I am typically running a shell and an inferior lisp (with
SLIME).
Can you reproduce the problem starting with emacs -q, i.e. without
loading your .emacs and not loading any other packages.
We have seen
The problem is triggered in vhdl-template-field, it seems that
read-from-minibuffer switches to the point position of the wrong window.
I don't know how to fix it, but I've traced it to the following problem:
% emacs -Q
[ type in some random text]
C-x 2
[ move point elsewhere ]
M-:
Stefan Monnier [EMAIL PROTECTED] writes:
$ ./missfonts
$ ./missfonts -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*
Missing 0: ISO8859-1
$ ./missfonts -*-helvetica-medium-r-*--*-120-*-*-*-*,*
Missing 0: ISO8859-1
The xfs configuration doesn't list any ISO8859-1 fonts:
Somewhere, specifying
The value of gud-pdb-command-name was changed from pdb, which I
think was a result of my misunderstanding. It should be changed back
to pdb since the output of the `pydb' variant of the debugger isn't
compatible.
The doc string could note that incompatibility. It could also say
that if you
Juri Linkov [EMAIL PROTECTED] writes:
But wouldn't it be better instead of these extension to add ZIP magic
string PK^C^D to `magic-mode-alist' to recognize archive files for
any possible extension?
Yes, in principle (like compressed files), but please don't mess with
that now. I doubt using
Luc Teirlinck [EMAIL PROTECTED] writes:
You should be able to reproduce the bug however, if you first set
isearch-allow-scroll to t.
For what it's worth, in my case that was nil.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
David Hunter [EMAIL PROTECTED] writes:
Exactly what Windows does for what? Recognizing a utf-16 registry
file when opened in the registry editor?
Auto-detecting utf-16 generally. Although I don't think it would give
false positives on iso-8859 text, I don't know if it could with other
Dave Love [EMAIL PROTECTED] writes:
Luc Teirlinck [EMAIL PROTECTED] writes:
You should be able to reproduce the bug however, if you first set
isearch-allow-scroll to t.
For what it's worth, in my case that was nil.
Has this problem been solved with the fix I installed?
--
Kim F. Storm
Richard Stallman [EMAIL PROTECTED] writes:
What I'm telling you is that the standards are not authorities.
They obviously are authorities when they define the charsets Emacs
wants to implement, at least. As far as I know, Unicode is the single
authority on the world's character usage, as far
Richard Stallman [EMAIL PROTECTED] writes:
Unicode is entitled to its opinion, but we do not necessarily
follow Unicode's opinion.
It's not an opinion, it's a statement of fact about line breaking in
general even if you don't accept the semantics of U+00AD as a format
character. Even if you
Kim Storm wrote:
Dave Love [EMAIL PROTECTED] writes:
Luc Teirlinck [EMAIL PROTECTED] writes:
You should be able to reproduce the bug however, if you first set
isearch-allow-scroll to t.
For what it's worth, in my case that was nil.
Has this problem been solved with
In article [EMAIL PROTECTED], Dave Love [EMAIL PROTECTED] writes:
Kenichi Handa [EMAIL PROTECTED] writes:
I didn't realize that was implemented. It looks helpful, but it
doesn't do what I'd expect. For instance, if I type `\righta TAB',
I'd like it to complete to `\rightarrow', like
On Apr 6, 2005 8:46 AM, Lute Kamstra [EMAIL PROTECTED] wrote:
I've got a sneaky suspicion that something goes awry with the
interaction between font-locking and the code in
grep-mode-font-lock-keywords that removes the escape sequences.
That sounds likely. The technique that grep.el uses
In article [EMAIL PROTECTED], Dave Love [EMAIL PROTECTED] writes:
Unicode says how guillemets are used as a matter of fact, which you
can verify. It's manifestly wrong for single ones to have word syntax
and double ones to have paren syntax and I wish I'd just changed it
when I had the
The value of gud-pdb-command-name was changed from pdb, which I
think was a result of my misunderstanding. It should be changed back
to pdb since the output of the `pydb' variant of the debugger isn't
compatible.
The doc string could note that incompatibility. It could also say
As far as I know,
(define-key map (kbd S-TAB) 'nero-move-to-previous-link)
should work, i.e., it should do the same thing as
(define-key map [(shift tab)] 'nero-move-to-previous-link)
However, I needed to use the latter syntax to actually get
my binding bound.
Using the first form and C-h
If things are that messed up, you probably need to do your debugging
in GDB. You could put a GDB breakpoint at lines like this in eval.c:
error (Lisp nesting exceeds max-lisp-eval-depth);
(I think there are two such lines.)
___
Emacs fails to respond, because it is buzy truncating a very large
undo list. My emacs doesnt respond to c-g during this operation, and
maybe that is normal behaviour.
It is strange that the undo list could get so big
that traversing it takes such a long time
without having been
27 matches
Mail list logo
