Chong Yidong [EMAIL PROTECTED] wrote:
Looking around, it appears that linux (at least Redhat) has strerror. I
worked around this problem by adding
#define HAVE_STRERROR 1
to src/s/gnu-linux.h. Not sure if that is the right solution or not.
configure should have put HAVE_STRERROR
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of
$ emacs -q
in *scratch* buffer:
M-x ps-print-buffer RET
Debugger entered--Lisp error: (void-variable ps-lf-cache)
ps-header-footer-string()
ps-mule-begin-job(1 193)
ps-generate(#buffer *scratch* 1 193 ps-generate-postscript)
ps-spool-without-faces(1 193 nil)
Here's a somewhat more tested patch. The problem in question is caused
by a change in the behaviour of try-completion between 21 and 22.
(try-completion foo '((foo) (foo)))
returns foo in 21, but t in 22. I don't know if this is a correct
interpretation of the doc-string's unique match which is
What should we do so as to fix both bugs?
The fix installed is OK, that is, keep LIB_X11_LIB defined to -lX11. In
the
cases where XFT_LIBS also includes -lX11, we will have two -lX11 in the
link
command.
Ok, but I am still puzzled by one thing. I thought that the more
Thanks for working on this. It is better to report a bug which isn't
than fail to report a bug which is.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I fixed the bug in the custom type, I think.
I also find (and I'm not quite sure whether it's a real bug or just
something I haven't understood about regexps or re-builder) that
expressions such as \\ and $ in the re-builder buffer don't work
(and are flagged as *invalid* in the
Richard Stallman wrote:
Ok, but I am still puzzled by one thing. I thought that the more
recent fix consisted of reverting the change you had previously made.
How come that didn't bring back the old bug?
Is it the case that the more recent fix did NOT revert your change?
In essence, Jan's
Enter the below text into a vanilla buffer. It consists of a rather
long expression (3415 characters, I believe), which is all in one
line (rather than nicely formatted). Add a few extra lines to the
expression.
Then double-click on the last closing paren ). The wrong region will
be
Oops, this has all been discussed on emacs-devel. Apologies for the
total time waste.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Oops, this has all been discussed on emacs-devel. Apologies for the
total time waste.
Let's get rid of one of the mailing lists (emacs-pretest-bug), point
report-emacs-bug to emacs-devel, and ask savannah hackers (?) to make
emacs-pretest-bug an alias for emacs-devel. I can't see why anyone
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of
In the gmane.emacs.diffs newsgroup, Kim F. Storm wrote:
Index: isearch.el
===
RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.294
retrieving revision 1.295
diff -u -b -r1.294 -r1.295
--- isearch.el
On Mon, 05 Mar 2007 07:33:07 +0100 David Hansen wrote:
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
Please describe exactly
Sorry for the late response on this matter.
In article [EMAIL PROTECTED], Martins Krikis [EMAIL PROTECTED] writes:
Upon testing the new Emacs behavior on Latvian characters encoded in UTF-8,
I noticed that pasting them out of Emacs and into, say, xterm works. However,
pasting them back does
Richard Stallman skrev:
What should we do so as to fix both bugs?
The fix installed is OK, that is, keep LIB_X11_LIB defined to -lX11. In the
cases where XFT_LIBS also includes -lX11, we will have two -lX11 in the link
command.
Ok, but I am still puzzled by one thing. I
On 2/18/07, Richard Stallman [EMAIL PROTECTED] wrote:
These doc changes are ok with me.
Does that mean someone should install them?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Richard Stallman [EMAIL PROTECTED] writes:
I fixed the bug in the custom type, I think.
I also find (and I'm not quite sure whether it's a real bug or just
something I haven't understood about regexps or re-builder) that
expressions such as \\ and $ in the re-builder buffer don't
18 matches
Mail list logo
