Re: Redraw problem with overlapping frames
David Kastrup <[EMAIL PROTECTED]> writes: > 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 the bug: > > When I have overlapping frames and issue a command in the lower frame > that will cause the minibuffer to be extended in size (here: > emacs-version), then after the resize, there is redraw cruft in the > lower frame (which disappears once the minibuffer is shrunk again). > One can't consistently trigger this, and the probability of getting > this behavior is much lower when compared to versions from the > beginning of the year. I would not recommend trying to fix this in > EMACS_22_BASE as the effect lasts only temporarily (until the > minibuffer gets shrunk again). For Emacs 23, however, one might want > to see how it is triggered. > > I have only ever seen this effect with overlapping Emacs frames from > the same session: overlapping frames from other applications possibly > don't trigger it (no guarantees, though). I include a screenshot. Uh, no guarantees... It turns out that when I place something like a shell window partially obscuring an Emacs frame with, say, a shell buffer running some compilation, then I get lots of display cruft in the Emacs frame. The cruft occurs in a) the top line partially obscured by the obscuring window b) below the bottom line partially obscured It would appear that scrolling does copy the material in the partially obscured cases, but fails to clear the partial lines before resp. after moving the displayed material at top resp. bottom. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display problem
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> Cc: Kenichi Handa <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org, >> [EMAIL PROTECTED] >> From: Miles Bader <[EMAIL PROTECTED]> >> Date: Tue, 29 May 2007 13:15:56 +0900 >> >> Perhaps another, better mechanism will come along which will supplant >> glyph codes entirely, but there isn't one yet (AFAIK). > > In case it wasn't clear, I was suggesting that Someone(tm) starts > working on such a mechanism in preparation for Emacs 23. Sounds like something definitely for the unicode-2 code base, whether before or after merging it into the trunk. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Redraw problem with overlapping frames
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 the bug: When I have overlapping frames and issue a command in the lower frame that will cause the minibuffer to be extended in size (here: emacs-version), then after the resize, there is redraw cruft in the lower frame (which disappears once the minibuffer is shrunk again). One can't consistently trigger this, and the probability of getting this behavior is much lower when compared to versions from the beginning of the year. I would not recommend trying to fix this in EMACS_22_BASE as the effect lasts only temporarily (until the minibuffer gets shrunk again). For Emacs 23, however, one might want to see how it is triggered. I have only ever seen this effect with overlapping Emacs frames from the same session: overlapping frames from other applications possibly don't trigger it (no guarantees, though). I include a screenshot. <> In GNU Emacs 23.0.51.5 (i686-pc-linux-gnu, GTK+ Version 2.10.11, multi-tty) of 2007-05-25 on lisa Windowing system distributor `The X.Org Foundation', version 11.0.7020 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars' 'CFLAGS=-g -O2 -fno-crossjumping'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: PDFTeX Minor modes in effect: TeX-PDF-mode: t server-mode: t desktop-save-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: n SPC SPC E q SPC n n q g q y M-x e m a c s - v e r M-x e m a c s - v e r M-x e m a c s - v e r Recent messages: GNU Emacs 23.0.51.5 (i686-pc-linux-gnu, GTK+ Version 2.10.11, multi-tty) of 2007-05-25 on lisa [3 times] Loading emacsbug...done -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with `before-string' in overlay
[EMAIL PROTECTED] (Kim F. Storm) writes: > "Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes: > >> It has not been my intent. I do get a bit upset by some type of >> answers and you are right, it is then in the eye of the beholder. I >> can understand if Eli feel a bit hurt. He took long time to write a >> long answer and I just pointed to some a little bit weaker points in >> the answer. > > IMO, there are _no weak points_ in Eli's message. > > In one sentence: > > "All software have bugs, so to ever make a release, someone must > decide when enough is enough". > > Sadly RMS does not see it that way either ... so we'll probably never > see a release, no matter how close we get to one (unless of course, > people stop reporting bugs in the pretests, even when they find one). I will not be surprised at all if we will see after the release a flood of problem reports currently held back by a large release pain threshold. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mark not set after a yank
Warren L Dodge <[EMAIL PROTECTED]> writes: >> Content-Type: text/plain; charset=ISO-8859-15 >> From: Richard Stallman <[EMAIL PROTECTED]> >> CC: emacs-pretest-bug@gnu.org >> Reply-to: [EMAIL PROTECTED] >> Date: Sun, 01 Apr 2007 10:00:10 -0400 >> >> Very often when I do a move of the point using M-< followed by >> a C-w emacs complains about the mark not being set. emacs-21.3 >> and prior always seems to work as it should. My work around is >> to do c-x c-x and then c-w >> >> This seems to indicate the c-x c-x knows about the mark but not c-w >> >> That is what would happen in Transient Mark mode, I think. >> Is it possible you enabled that mode? >> > > I do not do Transient Mark mode myself. > > This one is hard to repeat. Everytime I see it happen I try to > repeat it and it won't. The most common is the M-< as originally > stated but I also see it other times. I believe this second way is > when I position the cursor at the start of some text and then do a > c-s sequence to move to some text farther down. I'll then hit > to terminate the search and then c-w to cut the text block from the > start of the search to the end of the search string. Sometimes I > would also type c-a to not cut the line I searched to. > > Most of the time the c-x works fine but every so often it says mark > is not set in the buffer. Then the c-x-c-x c-w sequence works. I often have an active mark when doing a followup in gnus. In some extreme cases, mark-active is set while (marker-buffer (mark-marker)) returns nil, leading to errors. I have not yet found a reliable recipe for repeating it, but it is not rare. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
"Juanma Barranquero" <[EMAIL PROTECTED]> writes: > On 3/21/07, David Kastrup <[EMAIL PROTECTED]> wrote: > >> Do you have an example for a Postscript file on your system that is >> neither identified by the magic string "%!PS" nor an appropriate >> extension? > > No. But I don't understand your question. I was agreeing with you > (yeah, it happens sometimes). Basically, we have three "proposals" (partly proposed by previously existing code): a) accept "%!" as magic PostScript override (previous behavior) b) accept "%!PS" as magic override (what I proposed and checked in) c) don't accept any magic postscript override When arguing against c), it is not clear whether you agree with a) being a sufficiently bad idea. I had one example file causing problems with option a), and I already gave examples for files requiring b) (those produced using dvips -i don't have an extension, but in all cases start with "%!PS"). My point of view is that b) nowadays appears like the most pragmatically useful option, judging from problematic cases I have seen. If people can live with that, I suggest we leave it at that. While there are arguments for the other choices, we had them mentioned (Stefan's argument that magic should be kept to a minimum certainly _is_ valid) and, I believe, considered. Repeating them will just waste time. If people feel that they have been weighed wrongly, the way to resolve this is not repeating arguments, but vote on the resolution. Anybody who feels that the current solution b) as checked in by myself is not the best solution? If so, I'd want to either hear new arguments or have a vote. Everything else seems like a waste of time. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
"Juanma Barranquero" <[EMAIL PROTECTED]> writes: > On 3/21/07, Stefan Monnier <[EMAIL PROTECTED]> wrote: > >> because I think magic-mode-alist should really be kept to its absolute >> strictest minimum. > > Certainly, it should only be used for file formats which are often > found without a telling file extension. Alas, it seems like Postscript > is one of those. Do you have an example for a Postscript file on your system that is neither identified by the magic string "%!PS" nor an appropriate extension? -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
Stefan Monnier <[EMAIL PROTECTED]> writes: >>>> Sigh. Seems like a magic string for the "TeXshop" TeX editor. But I >>>> think just ruling out [VT] is still asking for trouble. >>> I think a bug report to the TeXshop is in order. >> Uh, you people are joking, right? > > Nope! > >> It is not a bug in TeXshop if Emacs' magic-mode-alist goes out of control >> and calls everything "PostScript". > > The %! thingy is not Emacs's invention. It's how postscript was > specified. The only relevant standard I can find starts off with "%!PS-Adobe". In contrast, %! is far too generic to be useful. It may be a heuristic for a PostScript interpreter to decide whether it is getting fed PostScript on stdin. But it does not sound like a useful heuristic for a text editor to decide whether a named file contains PostScript code or anything else. > And for that reason `file greek-utf8.tex' agrees with Emacs. > > This said, I'd be happy to see the %! entry removed from > magic-mode-alist, because I think magic-mode-alist should really be > kept to its absolute strictest minimum. I don't think that "%!PS" has comparable potential to do accidental harm. Whether it does noticeable good is a different question altogether. However, dvips -i produces PostScript files where the extension is replaced by a serial number. Those will not be recognized as PostScript without magic number detection. "%!PS" is completely sufficient for that purpose, however. I think that little except hand-crafted PostScript would ever start with "%!" alone, and hand-crafted PostScript will have a proper file name. Even if one uses dvips -N (which disabled structured comments) the file starts with %!PS (but not EPSF; comments have been disabled) So I think that "%!PS" _does_ have some usefulness, and it is clearly not as overboard as "%!". -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
Stefan Monnier <[EMAIL PROTECTED]> writes: >>>>> opening the following file in emacs-snapshot from Ubuntu Edgy >>>>> (sorry, I don't have a fresher CVS Emacs at work) will throw the >>>>> buffer into PostScript mode, presumably because it starts with >>>>> "%!". This seems rather like overkill. > > Same old problem where the file's content and the file's extension do not > agree on what the file actually contains. And once again, the file > extension is the better predictor whereas Emacs uses magic-mode-alist in > preference to auto-mode-alist. > >> Sigh. Seems like a magic string for the "TeXshop" TeX editor. But I >> think just ruling out [VT] is still asking for trouble. > > I think a bug report to the TeXshop is in order. Uh, you people are joking, right? It is not a bug in TeXshop if Emacs' magic-mode-alist goes out of control and calls everything "PostScript". >>> 3) Remove it from magic-mode-alist. >> Also an option in my book. > > Agreed, a very good option I'd say. Especially since editing > postscript is rather uncommon. Since I don't seem too good at explaining what appears as common sense to me, I'll fix the magic expression myself to "#!PS". That's still a less drastic change than removing it altogether, and most people seem to agree that the latter option would be quite feasible. This won't catch "#!\n" which seems to be used in some hand-crafted PS files, but then the handcrafted files (vasarely.ps, for example) should be discernible by file extension, and one would have to actually use some generic line-ending recognizer instead of "\n", anyway, since PostScript has no fixed line-ending convention. If others find they want even the "#!PS" gone (which I don't really see as a problem), or add some form of "#!lineend", feel free to discuss and fix. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
[EMAIL PROTECTED] (Kim F. Storm) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>>> 1) Restrict the magic for PostScript files to %!PS
>>>
>>> ("%!PS" . ps-mode)
>>
>> And probably EPS?
>
> Dunno.
>
>>>
>>> 2) Recognize the specific case of TEX
>>>
>>> ("%![^VT]" . ps-mode)
>
>> Sigh. Seems like a magic string for the "TeXshop" TeX editor. But I
>> think just ruling out [VT] is still asking for trouble.
>
> So maybe add this to the magic-mode-alist before the ps rule:
>
> ("%!TEX" . tex-mode)
That makes "%!" even less discriminatory than your last proposal. The
PostScript magic is _far_ too lenient.
I find strings like the following:
%!PS-Adobe-2.0
The Ghostscript example files (created manually, apparently) start
with
%!
and nothing else. I think it perfectly feasible to detect their
document type on the file name alone.
EPS files seem to start with something like
%!PS-Adobe-2.0 EPSF-2.0
So I'd propose making the magic string for PostScript at least
%!PS
While it may be conceivable to also allow %! on a line of its own, I
would judge that too weak for content-based detection.
--
David Kastrup
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: File type misclassification
[EMAIL PROTECTED] (Kim F. Storm) writes:
> "Juanma Barranquero" <[EMAIL PROTECTED]> writes:
>
>> On 3/20/07, David Kastrup <[EMAIL PROTECTED]> wrote:
>>
>>> opening the following file in emacs-snapshot from Ubuntu Edgy
>>> (sorry, I don't have a fresher CVS Emacs at work) will throw the
>>> buffer into PostScript mode, presumably because it starts with "%!".
>>> This seems rather like overkill.
>>
>> Yep. It's magic-mode-alist's doing:
>>
>> ("%![^V]" . ps-mode)
>
> First line of the file reads:
>
> %!TEX encoding = UTF-8 Unicode
>
>
> I see three fixes:
>
>
> 1) Restrict the magic for PostScript files to %!PS
>
> ("%!PS" . ps-mode)
And probably EPS?
>
> 2) Recognize the specific case of TEX
>
> ("%![^VT]" . ps-mode)
I don't think that there is a special case here: it would be my guess
that the author just picked that string by chance.
[Google]
Sigh. Seems like a magic string for the "TeXshop" TeX editor. But I
think just ruling out [VT] is still asking for trouble.
> 3) Remove it from magic-mode-alist.
Also an option in my book. But I think we should start by making the
string much more discriminatory. There is no harm if we overdo it: in
general, the file extension will catch what we don't, effectively
giving us option 3) for those cases.
--
David Kastrup
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
File type misclassification
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 the bug:
Hi,
opening the following file in emacs-snapshot from Ubuntu Edgy
(sorry, I don't have a fresher CVS Emacs at work) will throw the
buffer into PostScript mode, presumably because it starts with "%!".
This seems rather like overkill.
Maybe it is already fixed in CVS: no idea.
%!TEX encoding = UTF-8 Unicode
%
% Example of Greek input
%
\documentclass[a4paper,greek]{europecv}
%\usepackage[T1]{fontenc}
\usepackage[10pt]{type1ec} % To use CB-Greek
\usepackage[greek,english]{babel} % This is mandatory
\usepackage{graphicx}
\ecvlastname{Επώνυμο}
\ecvfirstname{Όνομα}
\ecvaddress{Οδός, αριθμός, ταχυδρομικός κωδικός, πόλη, χώρα (Προαιρετικά, βλ. οδηγίες)}
\ecvtelephone{(Προαιρετικά, βλ. οδηγίες)}
\ecvfax{(Προαιρετικά, βλ. οδηγίες)}
\ecvemail{(Προαιρετικά, βλ. οδηγίες)}
\ecvnationality{(Προαιρετικά, βλ. οδηγίες)}
\ecvgender{(Προαιρετικά, βλ. οδηγίες)}
\ecvdateofbirth{\foreignlanguage{english}{You can use the Latin alphabet.}}
\begin{document}
\selectlanguage{greek}
\begin{europecv}
\ecvpersonalinfo
\end{europecv}
\end{document}
If emacs crashed, and you have the emacs process in the gdb debugger,
please include the output from the following gdb commands:
`bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/22.0.50/etc/DEBUG for instructions.
In GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.10.3)
of 2006-09-19 on rothera, modified by Debian
(Debian emacs-snapshot package, version 1:20060915-1)
X server distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--build' 'i486-linux-gnu' '--host'
'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info'
'--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/22.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.50/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.50/leim'
'--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu'
'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g
-O2''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: PostScript
Minor modes in effect:
server-buffer-clients: (server <*5*>)
shell-dirtrack-mode: t
TeX-PDF-mode: t
server-mode: t
desktop-save-mode: t
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
B y e s
q g M-x g n u C-g C-x C-v n o
C-c C-n M-x r e v e r t - b u y e s
M-x r e p o r t - e m
Recent messages:
nnml: Reading incoming mail from file...
nnml: Reading incoming mail (no new mail)...done
Opening nndoc server on /tmp/bastmail...done
Checking new news...done
Auto-saving...
Loading ps-mode...done
When done with a buffer, type C-x #
Quit
find-alternate-file: Aborted
Loading emacsbug...done
--
David Kastrup
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
Richard Stallman <[EMAIL PROTECTED]> writes: > So can we install the patch to server.el to terminate > isearch-mode and get on with the release. PLEASE!!! > > Your shouting does not convince me. But it should not keep you from considering the arguments Kim and others (who actually use emacsserver) brought forth. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
[EMAIL PROTECTED] (Kim F. Storm) writes: > "Juanma Barranquero" <[EMAIL PROTECTED]> writes: > >> On 3/13/07, Richard Stallman <[EMAIL PROTECTED]> wrote: >> >>> I don't think that an action from outside Emacs is comparable to one >>> done by typing Emacs commands. >> >> It could be argued (and I would) that typing "emacsclient myfile" or >> clicking in a file associated to emacsclient is comparable to typing >> Emacs commands. The immediate response I expect from both of them is >> getting the Emacs frame on top (server-raise-frame defaults to t for a >> good reason) and ready to accept my input. > > I agree. > > Emacsclient don't just open files -- the user has to request that somehow. > > Also, most commands in Emacs will interrupt isearch. > > So I see NO reason for Emacsclient not to interrupt isearch. > > Let's make that change, and get on with the release! Seconded. I find myself unable to comprehend Richard's rationale for a different behavior here. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
"Juanma Barranquero" <[EMAIL PROTECTED]> writes: > On 3/11/07, Richard Stallman <[EMAIL PROTECTED]> wrote: > >> Use of Emacsclient should not interfere with an isearch! > > Why not? Emacsclient usually interrupts what Emacs is doing (try doing > "sleep 5; emacsclient myfile.txt" from a shell while you work on > Emacs). > > Certainly, emacsclient terminating the isearch is the behavior I would > expect (and so does the user who reported the bug...) I agree. Whether or not isearch is terminated or suspended possibly should be made dependent on the setting of enable-recursive-minibuffers: this is the setting that indicates whether the user can be considered comfortable with suspended minibuffer usage. It definitely is a mistake for Emacs to do nothing visibly: emacsclient is not something called asynchronously, but as a direct result of a user action and/or requiring user attention. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: SIGSEGV, not the first time around
Nick Roberts <[EMAIL PROTECTED]> writes: > > > Although I can't reproduce that bug, I found the code I committed > > > recently was incomplete. As I've just installed a fix, could you > > > please try again. > > > > The bug is not really in the "reproducible" class here, either. I > > think I got it three times so far, in probably three weeks or so. > > > > Nevertheless, I'll of course update and see where this leads us. > > If you observed the crash three weeks ago, it can't due to the change > to send_process_object, as that is only a week old. I am not really able to put a solid date on it, not least of all because I've down with a flu for what seems like eternities but actually isn't. I just remember one inexplicable crash, one that got my attention, well, and after that I used the debugger. It likely can't have have been 3 weeks. Sorry for the fuzziness. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: SIGSEGV, not the first time around
Kenichi Handa <[EMAIL PROTECTED]> writes: > Although I can't reproduce that bug, I found the code I committed > recently was incomplete. As I've just installed a fix, could you > please try again. The bug is not really in the "reproducible" class here, either. I think I got it three times so far, in probably three weeks or so. Nevertheless, I'll of course update and see where this leads us. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
SIGSEGV, not the first time around
s = 0 '\0',
debug_on_exit = 0 '\0'
}
#67 0x08104dcb in command_loop_1 () at /home/tmp/emacs/src/keyboard.c:1873
cmd =
lose =
nonundocount = 0
keybuf = {1073742784, 24, 137570449, -1216724408, 134539288,
-1218015208, 137476297, 137476297, -1080607338, -1080607272, 135263909,
138093357, -1080607338, 134527120, 110932256, 134538990, 218130704, 40, 0,
-1080607308, -1080607472, 0, 0, 137476297, 139762609, -16121856, 0, 137735712,
137735696, -16121856}
i =
prev_modiff = 278
prev_buffer = (struct buffer *) 0x88a1600
was_locked = 0
already_adjusted = 0
#68 0x0815b632 in internal_condition_case (bfun=0x8104a50 ,
handlers=137520953, hfun=0x80ff5a0 ) at
/home/tmp/emacs/src/eval.c:1481
val =
c = {
tag = 137476297,
val = 137476297,
next = 0xbf973f00,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, 137735712, 137735696, -1080607032, 1084046816,
-148916767},
__mask_was_saved = 0,
__saved_mask = {
__val = {135828016, 3214360256, 3086587600, 134538990, 110932256,
16777216, 0 , 3076952088, 3078242960, 3086585844, 3086587600,
134527120, 3214360272}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 137520953,
var = 137476297,
chosen_clause = 137476345,
tag = 0xbf973dec,
next = 0x0
}
#69 0x080fe953 in command_loop_2 () at /home/tmp/emacs/src/keyboard.c:1329
val = 137569401
#70 0x0815b6ea in internal_catch (tag=137514937, func=0x80fe930
, arg=137476297) at /home/tmp/emacs/src/eval.c:1222
c = {
tag = 137514937,
val = 137476297,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, 137735712, 137735696, -1080606776, 1084047088,
-148916515},
__mask_was_saved = 0,
__saved_mask = {
__val = {4294967295, 0, 139901851, 17, 17, 3214360072, 135557802,
139901848, 17, 17, 17, 3214360352, 4294967295, 3214360088, 135557989,
139901848, 137660450, 137660448, 137658760, 3214360488, 135583964, 137658761,
137660450, 137476297, 137508160, 137476321, 2, 0, 137658760, 137658761,
137476297, 3214360552}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#71 0x080ff3dc in command_loop () at /home/tmp/emacs/src/keyboard.c:1308
No locals.
#72 0x080ff79a in recursive_edit_1 () at /home/tmp/emacs/src/keyboard.c:1006
val =
#73 0x080ff886 in Frecursive_edit () at /home/tmp/emacs/src/keyboard.c:1067
buffer =
#74 0x080f5585 in main (argc=1, argv=0xbf974454) at
/home/tmp/emacs/src/emacs.c:1761
tz = 0x0
dummy = -1080605752
stack_bottom_variable = 8 '\b'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 8388608,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
Lisp Backtrace:
"process-send-string" (0x97608f4)
"imap-send-command-1" (0x94053db)
"imap-send-command" (0x940540b)
"imap-send-command-wait" (0x940540b)
0x9171674 PVEC_COMPILED
"imap-interactive-login" (0x92c5ea3)
"imap-login-auth" (0x92c5ea3)
"imap-authenticate" (0x86e4793)
"nnimap-open-connection" (0x8566e6b)
"nnimap-open-server" (0x8566e6b)
"byte-code" (0x8f0c6fb)
"gnus-open-server" (0x84949cd)
"byte-code" (0x8edbaeb)
"gnus-check-server" (0x84949cd)
"gnus-read-active-file-1" (0x84949cd)
"gnus-read-active-file" (0x831b8c9)
"gnus-setup-news" (0x831b8c9)
"byte-code" (0x8fb628b)
"gnus-1" (0x831b8c9)
"gnus" (0x831b8c9)
"call-interactively" (0x83d20b1)
"execute-extended-command" (0x831b8c9)
"call-interactively" (0x83258e1)
"process-send-string" (0x97608f4)
"imap-send-command-1" (0x94053db)
"imap-send-command" (0x940540b)
"imap-send-command-wait" (0x940540b)
0x9171674 PVEC_COMPILED
"imap-interactive-login" (0x92c5ea3)
"imap-login-auth" (0x92c5ea3)
"imap-authenticate" (0x86e4793)
"nnimap-open-connection" (0x8566e6b)
"nnimap-open-server" (0x8566e6b)
"byte-code" (0x8f0c6fb)
"gnus-open-server" (0x84949cd)
"byte-code" (0x8edbaeb)
"gnus-check-server" (0x84949cd)
"gnus-read-active-file-1" (0x84949cd)
"gnus-read-active-file" (0x831b8c9)
"gnus-setup-news" (0x831b8c9)
"byte-code" (0x8fb628b)
"gnus-1" (0x831b8c9)
"gnus" (0x831b8c9)
"call-interactively" (0x83d20b1)
"execute-extended-command" (0x831b8c9)
"call-interactively" (0x83258e1)
In GNU Emacs 22.0.94.2 (i686-pc-lin
Sometimes Emacs eats CPU like mad
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 the bug: I have this sometimes: a dormant Emacs will suddenly eat CPU like mad. I just compiled a fresh Emacs, so the bug is apparently still present. It is not actually necessary for Emacs to be even on screen: when I am on a different page of the window manager, this can still happen. If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /usr/local/emacs-21/share/emacs/22.0.93/etc/DEBUG for instructions. Well, xbacktrace did not display anything, here is the output of the backtrace command: #0 0xe410 in __kernel_vsyscall () #1 0xb77332ed in select () from /lib/tls/i686/cmov/libc.so.6 #2 0x0818ab45 in select_wrapper (n=-514, rfd=0x0, wfd=0xbfda6c74, xfd=0x0, tmo=0xbfda6d34) at /home/tmp/emacs/src/process.c:4202 #3 0x0818de3c in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137476297, wait_proc=0x0, just_wait_proc=0) at /home/tmp/emacs/src/process.c:4571 #4 0x08100a9d in read_char (commandflag=1, nmaps=4, maps=0xbfda7030, prev_event=137476297, used_mouse_menu=0xbfda70d4, end_time=0x0) at /home/tmp/emacs/src/keyboard.c:4016 #5 0x08103026 in read_key_sequence (keybuf=0xbfda7184, bufsize=30, prompt=137476297, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at /home/tmp/emacs/src/keyboard.c:9115 #6 0x08104b43 in command_loop_1 () at /home/tmp/emacs/src/keyboard.c:1618 #7 0x0815b552 in internal_condition_case (bfun=0x81049b0 , handlers=137520953, hfun=0x80ff500 ) at /home/tmp/emacs/src/eval.c:1481 #8 0x080fe8b3 in command_loop_2 () at /home/tmp/emacs/src/keyboard.c:1329 #9 0x0815b60a in internal_catch (tag=137514937, func=0x80fe890 , arg=137476297) at /home/tmp/emacs/src/eval.c:1222 #10 0x080ff33c in command_loop () at /home/tmp/emacs/src/keyboard.c:1308 #11 0x080ff6fa in recursive_edit_1 () at /home/tmp/emacs/src/keyboard.c:1006 ---Type to continue, or q to quit--- #12 0x080ff7e6 in Frecursive_edit () at /home/tmp/emacs/src/keyboard.c:1067 #13 0x080f54e5 in main (argc=1, argv=0xbfda7884) at /home/tmp/emacs/src/emacs.c:1761 At this point of time, Emacs was consuming about 80% of CPU power. So I can't vouch for the backtrace to _really_ be in the code path consuming the CPU, but it is likely. In GNU Emacs 22.0.93.4 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-02-13 on lola X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Message Minor modes in effect: mml-mode: t TeX-PDF-mode: t desktop-save-mode: t minibuffer-electric-default-mode: t iswitchb-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t abbrev-mode: t Recent input: a c s SPC ( e a t s SPC C P U SPC l i k e SPC m a d I t SPC s o m e w h a t SPC a f f e c t s SPC t h e SPC b l i n k i n g SPC a n d SPC c u r s o r SPC d i s p l a y . M-x r e p o r t - e m a c s - b u Recent messages: Sorting environment... Removing duplicates... done Applying style hooks... done uncompressing lilypond.info.gz...done uncompressing lilypond.info-1.gz...done Desktop: 69 buffers restored. For information about the GNU Project and its goals, type C-h C-p. Loading gnus-msg...done Parsing /home/dak/.mailrc... done Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
mpuz hangs
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 the bug: mpuz occasionally locks up. That is a nuisance. Something like (require 'mpuz) (dotimes (i 5) (mpuz-random-puzzle)) almost never terminates because of a bug in selecting the appropriate numbers. I am checking in the following fix: --- mpuz.el 28 Jan 2007 00:19:46 +0100 1.35 +++ mpuz.el 04 Feb 2007 18:10:05 +0100 @@ -262,8 +262,9 @@ (fillarray mpuz-board nil) ; erase the board ;; A,B,C,D & E, are the five rows of our multiplication. ;; Choose random values, discarding cases with leading zeros in C or D. - (let* ((A (+ 112 (random 888))) - (min (1+ (/ 1000 A))) + (let* ((A (if mpuz-allow-double-multiplicator (+ 112 (random 888)) + (+ 125 (random 875 + (min (1+ (/ 999 A))) (B1 (+ min (random (- 10 min B2 C D E) (while (if (= B1 (setq B2 (+ min (random (- 10 min) In GNU Emacs 22.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-01-28 on lola X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: shell-dirtrack-mode: t TeX-PDF-mode: t desktop-save-mode: t minibuffer-electric-default-mode: t iswitchb-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: p u z z l e ) : ( d o t i m e s SPC i SPC ( i SPC 5 0 0 0 0 ) SPC ( m p u z - r a n d o m - p u z z l e ) ) C-M-x : : M-x b u g - e m a r e p o r t - b u g e m Recent messages: Saving /home/dak/.newsrc.eld... Saving file /home/dak/.newsrc.eld... Wrote /home/dak/.newsrc.eld Saving /home/dak/.newsrc.eld...done Mark saved where search started nil Quit mpuz-random-puzzle nil [2 times] Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Creating an empty file
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 the bug: If I do C-x C-f somefile.txt RET C-x C-s in order to create and save an empty file, Emacs replies No changes need to be saved and does not actually save the file, even though saving the file would change the state on disk. In GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, GTK+ Version 2.10.3) of 2006-09-19 on rothera, modified by Debian (Debian emacs-snapshot package, version 1:20060915-1) X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--build' 'i486-linux-gnu' '--host' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/22.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.50/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.50/leim' '--with-x=yes' '--with-x-toolkit=gtk' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Conf[Unix] Minor modes in effect: shell-dirtrack-mode: t TeX-PDF-mode: t server-mode: t desktop-save-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: C-x C-f l t x d o c . c f g C-x C-s M-x r e p o r t - e m a c Recent messages: (New file) (No changes need to be saved) Loading emacsbug...done -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 22.0.50 fails to find ä in different ISO Latin encodings
Kenichi Handa <[EMAIL PROTECTED]> writes: > Peter Dyballa <[EMAIL PROTECTED]> writes: > >> Launched with -Q > >> unify-8859-on-decoding-mode is nil >> unify-8859-on-encoding-mode is t > >> I start i-search in an Unicode encoded buffer (*Help*). In an ISO >> 8859-1 encoded buffer ä and Ä are found, also in ISO 8859-10, ISO >> 8859-13 (except for Ä), ISO 8859-14, and ISO 8859-16 encoded buffers, >> but fails in ISO 8859-2, ISO 8859-3, ISO 8859-4, ISO 8859-9, and ISO >> 8859-15. It is similiar to ö and ü, accept that these are not found >> in the ISO 8859-14 encoded buffer. Changing unify-8859-on-decoding- >> mode's value makes no difference. > > This is the story I remember. > > A while ago, I proposed to change isearch so that it > translates characters by translation-table-for-input to > solve such a problem, but there raised an objection that > read-char should do that translation. RMS asked to check if > such a change to read-char is surely safe or not, but as > such a check is very difficult and time-consuiming, no one > took on the job. > > So, this problem is still unfixed. > > I again propose to change isearch. When we know that > changing read-char is safe in the future, we can cancel that > change in isearch. "in the future", namely after the release, we are going to switch to the unicode2 branch and presumably the problem will go away. So it does not sound like we should attempt any complicated fix for Emacs 22 that is not going to stay around, anyway. If the one problem where people are complaining is search-and-replace, we should fix that case for Emacs 22 and that's it for Emacs 22, in my opinion. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Strange 32bit-ism
Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Type M-: most-negative-fixnum RET and you get the output -268435456 (#o360, #xf000) The unsigned numbers to the right don't make sense: they are 29-bit numbers sign-extended to 32 bit. The additional 3 bits have no roots in Emacs integers but just are a shine-through from the underlying C integers. So this should be either -268435456 (#o20, #x1000) which has the disadvantage that it loosely implies leading zeros because 29 is neither dividable by 3 or 4, or -268435456 (#o-20, #x-1000) In GNU Emacs 22.0.50.8 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-08-28 on lola X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Help Minor modes in effect: TeX-PDF-mode: t desktop-save-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: identity view-mode: t -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Lockup
YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> writes: > Yes, pthread_mutex_(un)lock is not async-signal-safe. But we are > already using such functions as malloc in the signal handler context > (with the help of BLOCK_INPUT). I guess calling > pthread_mutex_(un)lock in the signal handler context is safe in > reality unless the interrupted thread is also executing > pthread_mutex_(un)lock for the same mutex. "I guess ... safe in reality unless ..." Maybe I have been around programmers too long, but I don't find this exactly reassuring. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Busy wait in Emacs
) at /home/tmp/emacs/src/keyboard.c:1305 #39 0x080f0a2f in recursive_edit_1 () at /home/tmp/emacs/src/keyboard.c:1003 #40 0x080f0b00 in Frecursive_edit () at /home/tmp/emacs/src/keyboard.c:1064 #41 0x080efb2d in main (argc=1, argv=0xbfa01d04) at /home/tmp/emacs/src/emacs.c:1794 Lisp Backtrace: "read-event" (0x830f8c9) "sit-for" (0x830d496) "byte-code" (0x8229ae3) "jit-lock-stealth-fontify" (0x830f8c9) "apply" (0x853e069) "byte-code" (0x822ffe3) "timer-event-handler" (0x8ac3e24) (gdb) In GNU Emacs 22.0.50.5 (i686-pc-linux-gnu, GTK+ Version 2.8.18) of 2006-08-09 on lola X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: PDFdocTeX Minor modes in effect: reftex-mode: t TeX-PDF-mode: t desktop-save-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: M-x e m a c s - r e p o r t - b u g r e p o r t - e m a c s - b u g Recent messages: Applying style hooks... done Sorting environment... Removing duplicates... done Applying style hooks... done Loading info...done uncompressing latex.info.gz...done uncompressing gdb.info.gz...done uncompressing guile-tut.info.gz...done Desktop: 14 buffers restored. Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Font Lock on-the-fly misfontification in C++]
Alan Mackenzie <[EMAIL PROTECTED]> writes: > Morning, Richard! > > On Wed, Aug 02, 2006 at 05:20:12PM -0400, Richard Stallman wrote: >> For distinguishing the two versions I write "Emacs" and "XEmacs", >> because the context shows we are talking about these two variants >> of the original GNU Emacs. > > This leaves a difficulty when there is no context. For example, you > might find this in an overview of editors: > > (1) "Most free editors do syntax highlighting. In vim, In > Emacs, syntax highlighting is usually called "font locking"." > > A bit lower down in the same article, there might be > > (2) "In some editors you can also highlight a region of text explicitly. > In vim you do ..., in Emacs you can type M-o M-o." > >> In other contexts, there is no need to refer to the two variants but >> there is a need to connect Emacs with the GNU system. There I write >> "GNU Emacs". > > In paragraph (1), it is clear that "Emacs" includes XEmacs. Not at all. It is clear to those knowing the editors, but they are hardly the target readership. > To substitute "Emacs and XEmacs" would make the sentence clumsy and > less readable, and wouldn't be helpful to the target readership. I can't say I agree here. And you could also write "Emacs variants", but "Emacs and XEmacs" is quite clearer and not at all clumsy. After all, jed and Microemacs, two Emacs-like editors, don't use that terminology. > In paragraph (2), the context of bare "Emacs" having previously been > set to "generic Emacs", clarity demands the substitution of "GNU > Emacs". But there is no point in an implicit "generic Emacs" context when one is discussing Emacs and XEmacs as separate editors. It is only confusing the readers, with no actual gain. > I believe "GNU Emacs" is used mainly for unambiguous identification > rather than connecting it with the GNU system - much like "John of > Gaunt" is used to clarify which John you're talking about rather > than to associate him with the town of Gent in Belgium. > > The root of the problem is that XEmacs is neither identical with > Emacs nor totally independent from it. Until such time as XEmacs > diverges completely from Emacs (another Boston tea party? ;-), or > remerges with it, there will be no good solution to the problem. Since XEmacs has diverged completely from Emacs, it is pointless to try maintaining a language greyzone which has to be constantly adjusted. Keybindings, semantics, data structures (keymaps, characters, integers, specifiers, toolbars, menubars, extents), keybindings and so on _all_ have completely diverged. The editors are dissimilar enough that users accustomed to one of them will not put up with the other interchangeably. There is almost no person who will say "I use Emacs on this computer, and XEmacs on that computer". > How about using a mixture of judgement, good sense, and tact, taking > each case on its merits? :-( It is no help to the reader if he has to secondguess the author and the author's knowledge of the internals of both Emacs and XEmacs. One could make a weak case for using "Emacs" as a proper name and "an Emacs" to signify the class of Emacs and XEmacs, but since there is usually nothing else grouped in that class ever, there is little point in doing so. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Font Lock on-the-fly misfontification in C++]
Aidan Kehoe <[EMAIL PROTECTED]> writes: > Ar an dara lá de mí Lúnasa, scríobh David Kastrup: > > > And we use the term "Emacs" for referring to Emacs. > > > When the term "GNU Emacs" is used, it is to draw attention to the > > GNU project and the part Emacs plays within it, not to insinuate > > that the scope of Emacs is supposed to be restricted to within > > GNU. > > No-one uses “GNU Emacs” to insinuate that the editor is supposed to > be restricted to within the GNU project. What gave you that > impression? Why else use it for distinguishing between Emacs and XEmacs? Their relation to the GNU project is similar. Many parts of GNU are not copyrighted by the FSF, including software carrying "GNU" in its name. > > Contrasting "XEmacs" and "GNU Emacs" is therefore misleading. > > The proper names of the editors are "Emacs" and "XEmacs". > > Then GNU Emacs should call itself just “Emacs” on its startup > screen, as XEmacs calls itself “XEmacs” on its startup screen. I repeat: when the term "GNU Emacs" is used, it is to draw attention to the GNU project and the part Emacs plays within it. > > "GNU Emacs" is a distinction, but not one differentiating Emacs > > and XEmacs. > > I disagree. I am afraid that I consider the opinion of the creator of Emacs more relevant than yours with regard on whether Emacs should be allowed to be named Emacs. Of course, you are free to call XEmacs whatever you like. But the name "Emacs" is already taken. > > [...] I don't think it too onerous to expect that XEmacs > > developers call Emacs "Emacs". > > Active developers call your branch of the editor GNU Emacs! It is > hypocritical at best to object when others do likewise. I repeat: When the term "GNU Emacs" is used, it is to draw attention to the GNU project and the part Emacs plays within it, not to insinuate that the scope of Emacs is supposed to be restricted to within GNU. > > The stance that "Emacs" is supposed to mean "Emacs and XEmacs" > > and only "GNU Emacs" is supposed to carry the meaning "Emacs" is > > not really helpful, not even to XEmacs users. > > XEmacs still supports (emacs-version); lots of our documentation > uses “emacs” to refer to any version of the editor, something the > GNU branch rarely does (that is, it rarely admits that the > documentation may be applicable to other branches.). Don't you find it silly to blame upstream for your failures to update the documentation in order to reflect the fork? > I personally would prefer to do this less; I changed the title bar > to say “XEmacs” rather than “emacs” partly because of that. A perfectly reasonable stance. I'll give you a historical document which might make it clearer to you why a) the documentation of XEmacs has not from early on bothered to distinguish between Lucid Emacs and Emacs. b) RMS is not too enthused about XEmacs documentation and developers trying to hijack the name of Emacs to mean anything but Emacs. http://groups.google.com/group/gnu.emacs.help/msg/764864608067f821?as_q=&[EMAIL PROTECTED]> Note that this is all water under the draw bridge now, but historically, the creators of Lucid Emacs laid claim to and hijacked the name Emacs (without any further qualifications) for their own fork of it. Their claim to be the legitimate successor of interest to Emacs was what has fueled the idea that "Emacs" somehow is supposed be a proper name of XEmacs. These claims were made in order to cause developers to move over to Lucid Emacs. XEmacs is not Emacs, but a fork of it. The license of Emacs permits forking its code, it does not permit forking its name. That is a bit of the background why the usage put forth in the Emacs FAQ should be just "Emacs" and "XEmacs". -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Font Lock on-the-fly misfontification in C++]
Aidan Kehoe <[EMAIL PROTECTED]> writes: > Ar an t-aonú lá is triochad de mí Iúil, scríobh Richard Stallman: > > > To speak of "GNU Emacs" and "XEmacs" gives the impression that XEmacs has > > nothing to do with GNU. Since XEmacs is a forked version of Emacs, that > > is a misleading impression. Please write "Emacs" and "XEmacs", or else > > "GNU Emacs" and "GNU XEmacs". > > Substantial parts of the code of XEmacs are not copyrighted by the > FSF, the legal entity stewarding the GNU project, and this is almost > certain to remain so. The XEmacs project members do not consider the > advancement of the GNU project as a significant part of our job. We > use the term XEmacs, we never use the term GNU XEmacs. And we use the term "Emacs" for referring to Emacs. When the term "GNU Emacs" is used, it is to draw attention to the GNU project and the part Emacs plays within it, not to insinuate that the scope of Emacs is supposed to be restricted to within GNU. Contrasting "XEmacs" and "GNU Emacs" is therefore misleading. The proper names of the editors are "Emacs" and "XEmacs". "GNU Emacs" is a distinction, but not one differentiating Emacs and XEmacs. > If you want to be wilfully disrespectful to the members of the > XEmacs project, use GNU XEmacs to refer to the editor; otherwise, > the established usage, XEmacs on its own, will raise fewer hackles > and doesn’t require you to think extra hard every time you mention > the editor. The same goes for Emacs. Here is the passage from the Emacs FAQ: (info "(efaq) Difference between Emacs and XEmacs") If you want to talk about these two versions and distinguish them, please call them "Emacs" and "XEmacs." To contrast "XEmacs" with "GNU Emacs" would be misleading, since XEmacs too has its origin in the work of the GNU Project. Terms such as "Emacsen" and "(X)Emacs" are not wrong, but they are not very clear, so it is better to write "Emacs and XEmacs." I don't think it too onerous to expect that XEmacs developers call Emacs "Emacs". The stance that "Emacs" is supposed to mean "Emacs and XEmacs" and only "GNU Emacs" is supposed to carry the meaning "Emacs" is not really helpful, not even to XEmacs users. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Lockup
at /home/tmp/emacs/src/eval.c:3028 #50 0x0817c99e in Fbyte_code (bytestr=144059651, vector=144061468, maxdepth=16) at /home/tmp/emacs/src/bytecode.c:679 #51 0x08152b5a in funcall_lambda (fun=144061636, nargs=1, arg_vector=0xbfac03b4) at /home/tmp/emacs/src/eval.c:3169 #52 0x08152fb0 in Ffuncall (nargs=2, args=0xbfac03b0) at /home/tmp/emacs/src/eval.c:3028 #53 0x081506da in Fcall_interactively (function=138222865, record_flag=137410761, keys=137451260) at /home/tmp/emacs/src/callint.c:880 #54 0x080f596e in Fcommand_execute (cmd=138222865, record_flag=137410761, keys=0, special=137410761) at /home/tmp/emacs/src/keyboard.c:9780 #55 0x080fe111 in command_loop_1 () at /home/tmp/emacs/src/keyboard.c:1790 #56 0x081515ec in internal_condition_case (bfun=0x80fddc9 , handlers=137455425, hfun=0x80f6470 ) at /home/tmp/emacs/src/eval.c:1469 #57 0x080f0aef in command_loop_2 () at /home/tmp/emacs/src/keyboard.c:1326 #58 0x081512f0 in internal_catch (tag=0, func=0x80f0acc , arg=137410761) at /home/tmp/emacs/src/eval.c:1210 #59 0x080f0921 in command_loop () at /home/tmp/emacs/src/keyboard.c:1305 #60 0x080f09bf in recursive_edit_1 () at /home/tmp/emacs/src/keyboard.c:1003 #61 0x080f0a90 in Frecursive_edit () at /home/tmp/emacs/src/keyboard.c:1064 #62 0x080efabd in main (argc=1, argv=0xbfac0c84) at /home/tmp/emacs/src/emacs.c:1794 Lisp Backtrace: "file-name-all-completions" (0x98f86fb) "byte-code" (0x81dac1b) "find-backup-file-name" (0x98f874b) "nndraft-request-expire-articles" (0x96f96fd) "message-disassociate-draft" (0x830b8f9) "message-send" (0x830b8c9) "message-send-and-exit" (0x830b8c9) "call-interactively" (0x83d1d11) In GNU Emacs 22.0.50.4 (i686-pc-linux-gnu, GTK+ Version 2.8.18) of 2006-07-28 on lola X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Info Minor modes in effect: TeX-PDF-mode: t desktop-save-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: M-x g n u s - r e p o e m a c s - r e p o b u C-a r e p o r t - C-e Recent messages: Removing duplicates... done Applying style hooks... done Sorting environment... Removing duplicates... done Applying style hooks... done uncompressing latex.info.gz...done uncompressing gdb.info.gz...done Desktop: 7 buffers restored. For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [EMAIL PROTECTED]: Font Lock on-the-fly misfontification in C++]
Alan Mackenzie <[EMAIL PROTECTED]> writes: > Good morning, Richard! > > On Mon, Jul 31, 2006 at 07:59:55PM -0400, Richard Stallman wrote: > >> To speak of "GNU Emacs" and "XEmacs" gives the impression that >> XEmacs has nothing to do with GNU. > > XEmacs isn't maintained by the GNU project. Correct. >> Since XEmacs is a forked version of Emacs, that is a misleading >> impression. Please write "Emacs" and "XEmacs", or else "GNU Emacs" >> and "GNU XEmacs". > > "Emacs", unqualified, can be ambiguous. No. > It can mean either (i) "an editor of the Emacs persuasion"; In which case you can write "Emacsen". Anyway, there are quite more "editors of the Emacs persuasion", such as MicroEmacs and jed, and we don't mean them when writing "Emacs", either. If you mean "Emacs or XEmacs", write "Emacs or XEmacs". > or (ii) "the best editor in the world, maintained by the GNU > project". This is redundant. > In contexts where it is important to emphasise that (ii) is meant, > surely "GNU Emacs" is what to write. Please read the Emacs FAQ entry. We don't need to go through all that _again_. It has been discussed to death already. > "XEmacs", by contrast, means what it means. It's what its > maintainers call it. So why would "Emacs" not mean what its maintainers call it? Here is the FAQ entry: (info "(efaq) Difference between Emacs and XEmacs.") [...] If you want to talk about these two versions and distinguish them, please call them "Emacs" and "XEmacs." To contrast "XEmacs" with "GNU Emacs" would be misleading, since XEmacs too has its origin in the work of the GNU Project. Terms such as "Emacsen" and "(X)Emacs" are not wrong, but they are not very clear, so it is better to write "Emacs and XEmacs." We have had lots of discussions before settling on this, so please don't start it again. We need to get work done. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Exit hooks not run at logout on w32
Lennart Borgman <[EMAIL PROTECTED]> writes: > Jason Rumney wrote: > >> As I said at the start of the thread, it would be correct for Emacs >> to flush its autosave buffers to disk at this point, but not to >> start asking all the questions that save-buffers-kill-emacs >> does. What if Emacs is on a secondary monitor, and the Graphics >> driver shuts it off when it receives the shutdown message? Emacs >> will be delaying shutdown waiting for a response, while the user >> cannot see it. > The problem with autosave is that data might be lost if the user > happens to use some other tool to edit the files afterwards. Tough. That's what "editing" means. I don't want changes saved without my saying so: that might end up the file in a terminally ill state, like when I cut out a large region for the purpose of pasting it somewhere else, and then Emacs shuts down. Recovering a session is good enough for me. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Region undo is rather unusable
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 the bug: Take a buffer and do a dozen editing operations, insertion, deletion, stuff like that, on various points of the buffer. The description for undo says: undo is an interactive compiled Lisp function in `simple.el'. It is bound to C-_, , C-/, . (undo &optional ARG) Undo some previous changes. Repeat this command to undo more changes. A numeric argument serves as a repeat count. In Transient Mark mode when the mark is active, only undo changes within the current region. Similarly, when not in Transient Mark mode, just C-u as an argument limits undo to changes within the current region. Now put a region into transient mark mode (mark one end with C-SPC and the other with C-u C-x C-x). Try repeated undo with C-/. The problem is that after each undo, point gets moved to some wild other place, and so the region changes from undo to undo. This makes it impossibly inconvenient to undo repetitive changes in a region. But the whole _point_ of this feature is _multiple_ undos, namely undoing something further back in the history without affecting changes done later. So for all _practical_ purposes, the implementation of the feature is not useful. I think that if there is an active region, Emacs should try hard to retain point at the proper end of this region when making an undo. In GNU Emacs 22.0.50.39 (i686-pc-linux-gnu, GTK+ Version 2.8.17) of 2006-06-05 on lola X server distributor `The X.Org Foundation', version 11.0.7000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Message Minor modes in effect: shell-dirtrack-mode: t mml-mode: t TeX-PDF-mode: t desktop-save-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t abbrev-mode: t Recent messages: Undo! [2 times] Redo! [2 times] Mark set Transient-mark-mode temporarily enabled Undo in region! Mark set Transient-mark-mode temporarily enabled Undo in region! Quit Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
TAB in rcirc barfs.
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 the bug:
M-x irc RET TAB
gives
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
assoc-string(nil (("#emacs" 17447 25645 77605)) t)
#[(k v) "Å Æ#... \nAB\fB.)." [channel v record k nicks assoc-string t]
5]("dak`" (("#emacs" 17447 25645 77605)))
maphash(#[(k v) "Å Æ#... \nAB\fB.)." [channel v record k nicks
assoc-string t] 5] #)
rcirc-channel-nicks(# nil)
rcirc-complete-nick()
call-interactively(rcirc-complete-nick)
In GNU Emacs 22.0.50.32 (i686-pc-linux-gnu, GTK+ Version 2.8.6)
of 2006-03-25 on lola
X server distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk'
'--without-toolkit-scroll-bars''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: Debugger
Minor modes in effect:
TeX-PDF-mode: t
desktop-save-mode: t
iswitchb-mode: t
minibuffer-electric-default-mode: t
tooltip-mode: t
auto-compression-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-decoding-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
line-number-mode: t
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Error when entering tool-bar-mode
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
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 the bug:
When using
M-x tool-bar-mode RET
from an otherwise toolbar-less Emacs (started with Xresources
containing
Emacs.toolBar: 0
) I got the following backtrace:
Debugger entered--Lisp error: (wrong-type-argument keymapp nil)
signal(wrong-type-argument (keymapp nil))
define-key-after(nil [customize] (menu-item "customize" customize :image
(image :type xpm :file
"/usr/local/emacs-21/share/emacs/22.0.50/etc/images/preferences.xpm") :help
"Edit preferences (customize)"))
tool-bar-local-item("preferences" customize customize nil :help "Edit
preferences (customize)")
apply(tool-bar-local-item "preferences" customize customize nil (:help "Edit
preferences (customize)"))
tool-bar-add-item("preferences" customize customize :help "Edit preferences
(customize)")
tool-bar-setup()
tool-bar-mode(toggle)
call-interactively(tool-bar-mode)
execute-extended-command(nil)
call-interactively(execute-extended-command)
The mode was message-mode, but I doubt that it relevant. I also have
to stress that starting tool-bar-mode will make the Emacs buffer go
off-screen at the bottom. It is a nuisance.
In GNU Emacs 22.0.50.23 (i686-pc-linux-gnu, GTK+ Version 2.8.6)
of 2005-10-28 on lola
X server distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk'
'--without-toolkit-scroll-bars''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: en_US.ISO-8859-1
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
locale-coding-system: iso-latin-1
default-enable-multibyte-characters: t
Major mode: Debugger
Minor modes in effect:
tool-bar-mode: t
TeX-PDF-mode: t
file-name-shadow-mode: t
desktop-save-mode: t
iswitchb-mode: t
minibuffer-electric-default-mode: t
mouse-wheel-mode: t
tooltip-mode: t
auto-compression-mode: t
menu-bar-mode: t
blink-cursor-mode: t
unify-8859-on-decoding-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
line-number-mode: t
Recent input:
C-k C-k E x c e p t SPC t h a t SPC d r o
p SPC s h a d o w s SPC t e n
d o n ' t SPC l o o k SPC f i n e SPC t
h e n . M-x t o o l b a r
- b a r M-x r e p o r t - e m a c s
- b u g
Recent messages:
Opening nntp server on news.gmane.org...done
Opening nntp server on news.freshmeat.net...done
Checking new news...done
Retrieving newsgroup: nnml+private:emacs...
Fetching headers for nnml+private:emacs...done
Scoring...done
Generating summary...done
Mark set [2 times]
Entering debugger...
Loading emacsbug...done
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: scroll-up makes no progress on overtall lines
[EMAIL PROTECTED] (Kim F. Storm) writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >> This bug report will be sent to the Free Software Foundation, >> not to your local site managers! >> 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 the bug: >> >> Hi Kim, when I use preview-latex to generate a line that is taller >> than the buffer and then repeatedly press , the screen position >> goes through a somewhat strange circular pattern, but never manages to >> scroll through it. scroll-down, previous-line and next-line all >> manage to make it through the image, in contrast. > > I suppose that line contains an image as the last thing. Excepting the newline character. > If that line is the _last_ visible line in the buffer, Not at all. > you see some jumpy effects in next when it reaches the last part of > that line. > > I looked at it before, and found that it is a bad interaction between > placing the image text property on the last NL in the buffer and the > way eolp and eobp works. > > If it happens in the middle of a buffer, I would like to know more > about how to reproduce it. Load circ.tex from preview-latex, do C-c C-p C-d wait until it finishes, then do C-x 2 and drag the modeline up until the top window has maybe 1/4 of the screen estate (10 lines or so). Go to the top of the file, press (Page-Down) and let auto-repeat cater for the rest. You will get stuck at a larger image in the middle of the buffer. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
scroll-up makes no progress on overtall lines
This bug report will be sent to the Free Software Foundation, not to your local site managers! 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 the bug: Hi Kim, when I use preview-latex to generate a line that is taller than the buffer and then repeatedly press , the screen position goes through a somewhat strange circular pattern, but never manages to scroll through it. scroll-down, previous-line and next-line all manage to make it through the image, in contrast. If you need a particular example, just holler. In GNU Emacs 22.0.50.13 (i686-pc-linux-gnu, GTK+ Version 2.6.8) of 2005-07-14 on lola X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: PDFLaTeX Minor modes in effect: reftex-mode: t TeX-PDF-mode: t file-name-shadow-mode: t desktop-save-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t mouse-wheel-mode: t tooltip-mode: t auto-compression-mode: t menu-bar-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t next-error-follow-minor-mode: Fol Recent input: M-x r e p o r t - e m a Recent messages: Quit [2 times] Wrote /tmp/junk.tex Applying style hooks... Loading /usr/local/emacs-21/share/emacs/site-lisp/auctex/style/article.elc...done Applying style hooks... done Sorting environment... Removing duplicates... done Wrote /home/dak/range.tex call-interactively: Beginning of buffer [3 times] Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: *cvs-commit* gets used as PCVS buffer
Stefan Monnier <[EMAIL PROTECTED]> writes: >>>>>> "David" == David Kastrup <[EMAIL PROTECTED]> writes: > > Ahh... I think I finally got it. Does the patch below fix the problem? > I believe it should. The only problem is that I can't figure out what this > code was supposed to do, so it may break something. > > --- pcvs.el 02 mai 2005 11:41:42 -0400 1.80 > +++ pcvs.el 04 mai 2005 13:44:29 -0400 > @@ -1438,12 +1438,10 @@ >;; displayed in the wrong minibuffer). >(cvs-mode!) >(let ((buf (cvs-temp-buffer "message" 'normal 'nosetup)) > - (lbd list-buffers-directory) > (setupfun (or (nth 2 (cdr (assoc "message" cvs-buffer-name-alist))) > 'log-edit))) > (funcall setupfun 'cvs-do-commit setup 'cvs-commit-filelist buf) > (set (make-local-variable 'cvs-minor-wrap-function) > 'cvs-commit-minor-wrap) > -(set (make-local-variable 'list-buffers-directory) lbd) > (run-hooks 'cvs-mode-commit-hook))) > > (defun cvs-commit-minor-wrap (buf f) > @@ -1494,14 +1492,12 @@ >;; displayed in the wrong minibuffer). >(cvs-mode!) >(let ((buf (cvs-temp-buffer "message" 'normal 'nosetup)) > - (lbd list-buffers-directory) > (setupfun (or (nth 2 (cdr (assoc "message" cvs-buffer-name-alist))) > 'log-edit))) > (funcall setupfun 'cvs-do-edit-log nil 'cvs-edit-log-filelist buf) > (when text (erase-buffer) (insert text)) > (set (make-local-variable 'cvs-edit-log-revision) rev) > (set (make-local-variable 'cvs-minor-wrap-function) > 'cvs-edit-log-minor-wrap) > -(set (make-local-variable 'list-buffers-directory) lbd) > ;; (run-hooks 'cvs-mode-commit-hook) > )) Well, I guess this is rather obvious. This transfers the original value of list-buffers-directory to a buffer-local copy of the commit buffer so that changes to list-buffers-directory done while the commit is in progress don't affect the operation of the commit. I do this sort of local variable value copying to the process buffer when doing start-process quite a bit in AUCTeX. I have no clue on what list-buffers-directory actually does, it is defined in menu-bar.el defaulting to nil, and it completely baffles me that this should have the given effect or what it is intended for. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
*cvs-commit* gets used as PCVS buffer
This bug report will be sent to the Free Software Foundation, not to your local site managers! 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 the bug: If you do something like M-x cvs-examine RET /home/tmp/emacs RET go on one line, then use C-u C to get a Log edit buffer, then do a kill-buffer of the original *cvs* buffer, switch to some arbitrary buffer and do M-x cvs-examine RET /home/tmp/emacs RET again, then the *cvs-commit* buffer will get "reused" as the main PCVS buffer. Since this usage conflicts when you are doing another commit, PCVS can get rather confused. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2005-04-24 on lola Distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: CVS Minor modes in effect: cvs-minor-mode: t TeX-PDF-mode: t file-name-shadow-mode: t auto-compression-mode: t desktop-save-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t mouse-wheel-mode: t tooltip-mode: t menu-bar-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t next-error-follow-minor-mode: Fol Recent input: Recent messages: (No files need saving) Running cvs update ... CVS process has completed in *cvs* Mark set Press C-c C-c when you are done editing. Type M-x switch-to-buffer-other-window RET to restore the other window. C-M-v to scroll the help. (No files need saving) Running cvs update ... CVS process has completed in *cvs-commit* Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Hang of Emacs
"Jan D." <[EMAIL PROTECTED]> writes: >> Just some ordinary operations in Gnus, nothing particularly >> challenging. >> >> (gdb) where >> #0 0x002b47e2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 >> #1 0x003a2a0e in __lll_mutex_lock_wait () from /lib/tls/libc.so.6 >> #2 0x003392a2 in _L_mutex_lock_15166 () from /lib/tls/libc.so.6 >> #3 0x003efff4 in ?? () from /lib/tls/libc.so.6 >> #4 0x0002 in ?? () >> #5 0xbff886fc in ?? () >> #6 0x0812ee1a in emacs_blocked_malloc (size=4294967294) >> at /home/tmp/emacs/src/alloc.c:1220 >> #7 0x0812ee1a in emacs_blocked_malloc (size=2) >> at /home/tmp/emacs/src/alloc.c:1220 >> #8 0x00335d11 in malloc () from /lib/tls/libc.so.6 >> > > Can you specify the version of libc you have, (run /lib/tls/libc.so.6, > it can be run even if it is a shared library, assuming GNU libc here)? > The line specifying the kind of thread library would be helpful. > > Thanks, GNU C Library development release version 2.3.4, by Roland McGrath et al. Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.0.0 20050323 (Red Hat 4.0.0-0.37). Compiled on a Linux 2.4.20 system on 2005-03-25. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others Native POSIX Threads Library by Ulrich Drepper et al The C stubs add-on version 2.1.2. BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton GNU Libidn by Simon Josefsson Thread-local storage support included. For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Hang of Emacs
59, vector=145705020, maxdepth=8) at /home/tmp/emacs/src/bytecode.c:686 #52 0x0814535b in funcall_lambda (fun=Variable "fun" is not available. ) at /home/tmp/emacs/src/eval.c:2974 #53 0x0814581e in Ffuncall (nargs=4, args=0xbff8a790) at /home/tmp/emacs/src/eval.c:2843 #54 0x0816f9d8 in Fbyte_code (bytestr=145713275, vector=145717972, maxdepth=6) at /home/tmp/emacs/src/bytecode.c:686 #55 0x0814535b in funcall_lambda (fun=Variable "fun" is not available. ) at /home/tmp/emacs/src/eval.c:2974 #56 0x0814581e in Ffuncall (nargs=1, args=0xbff8a8a0) at /home/tmp/emacs/src/eval.c:2843 #57 0x0816f9d8 in Fbyte_code (bytestr=145713339, vector=145726636, maxdepth=5) at /home/tmp/emacs/src/bytecode.c:686 #58 0x0814535b in funcall_lambda (fun=Variable "fun" is not available. ) at /home/tmp/emacs/src/eval.c:2974 #59 0x0814581e in Ffuncall (nargs=1, args=0xbff8a9c0) at /home/tmp/emacs/src/eval.c:2843 #60 0x08146c0a in apply1 (fn=143094377, arg=137318417) at /home/tmp/emacs/src/eval.c:2534 #61 0x0814246f in Fcall_interactively (function=143094377, record_flag=137318417, keys=137375292) at /home/tmp/emacs/src/callint.c:412 #62 0x080eb1e5 in Fcommand_execute (cmd=143094377, record_flag=137318417, keys=137318417, special=137318417) at /home/tmp/emacs/src/keyboard.c:9697 #63 0x080f347f in command_loop_1 () at /home/tmp/emacs/src/keyboard.c:1792 #64 0x08143d8b in internal_condition_case (bfun=0x80f3144 , handlers=137379409, hfun=0x80ebbd4 ) at /home/tmp/emacs/src/eval.c:1385 #65 0x080e66c6 in command_loop_2 () at /home/tmp/emacs/src/keyboard.c:1319 #66 0x08143ca3 in internal_catch (tag=4135080, func=0x80e66a8 , arg=137318417) at /home/tmp/emacs/src/eval.c:1144 #67 0x080e64dd in command_loop () at /home/tmp/emacs/src/keyboard.c:1298 #68 0x080e6577 in recursive_edit_1 () at /home/tmp/emacs/src/keyboard.c:991 #69 0x080e666a in Frecursive_edit () at /home/tmp/emacs/src/keyboard.c:1052 #70 0x080e5784 in main (argc=1, argv=0xbff8b214) at /home/tmp/emacs/src/emacs.c:1767 (gdb) xbacktrace "prin1-to-string" "gnus-prin1-to-string" "gnus-group-update-group" "gnus-group-make-articles-read" 0x8af47fc No enum type named pvec_type. (gdb) In GNU Emacs 22.0.50.3 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2005-03-30 on lola.goethe.zz Distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-gtk' '--without-toolkit-scroll-bars' '--prefix=/usr/local/emacs-21'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: TeX-PDF-mode: t file-name-shadow-mode: t auto-compression-mode: t desktop-save-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: M-x r e b o p o r t - e m a c s - b u Recent messages: Loading preview (compiled; note, source file is newer)...done Applying style hooks... Loading /usr/local/emacs-21/share/emacs/site-lisp/auctex/style/german.elc...done Loading /usr/local/emacs-21/share/emacs/site-lisp/auctex/style/article.elc...done Applying style hooks... done Loading info... Loading tool-bar...done Loading info...done Desktop: 6 buffers restored. Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sensible menu bindings
[EMAIL PROTECTED] (Kim F. Storm) writes: > Stefan Monnier <[EMAIL PROTECTED]> writes: > >>> I recently suggested patches to report menu bindings using the real >>> menu item texts rather than the internal names, like this: >> >>> File=>Print=>Print With Faces >> >> I agree it would be an improvement. But IIRC you did it by >> modifying key-description, which also applies to things like C-h c >> where I think it's important to keep a representation that can be >> passed directly to `kbd'. > > How do you copy/paste the output from C-h c? From *Messages* buffer? > > With C-h k, you get a buffer from which you can copy the original menu > binding -- and with my patch, that binding is still shown for C-h k > (see example below). > >> So I'd recommend to add an arg to key-description and then only use >> it at those places where it makes sense (basically, for the keys >> returned by `where-is'). > > With my patch, (key-description KEY t) will do just that. > Making C-h c using that is trivial (I already did so). > > Anyway, Richard don't think this is an improvement, so > unless more people speak up, it's a dead end. I think it is an improvement since we are talking here mainly about user-level instead of programmer-accessible documentation. With regard to the duplication of information: how feasible would it be to make kbd accept File=>Print=>Print With Faces strings? Then there would be no necessity to report a different form. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Backtrace in splash screen
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
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 the bug:
I called up the splash screen with the Help/About Emacs entry. When I
next moved the mouse over the "Help" menu entry, when it should be
giving a tooltip, it instead barfed with
Debugger entered--Lisp error: (wrong-type-argument wholenump nil)
posn-at-x-y(nil nil #)
tooltip-show-help-function("mouse-2: browse http://www.gnu.org/";)
recursive-edit()
byte-code("Æ.Ç .È!.ÉÊË#.ÉÌÍ#.ÉÎË#.ÉÏË#.Ð..Ð.Ñ.ÒÓÔÕ#.Ö ×. ]\\. ØÙ. Ú. $.
Û *." [map cursor-type display-hourglass minor-mode-map-alist buffer-undo-list
mode-line-format ((byte-code "Æ!. . .Ç.!." [timer old-hourglass
display-hourglass old-minor-mode-map-alist minor-mode-map-alist splash-buffer
cancel-timer kill-buffer] 2)) make-sparse-keymap use-local-map define-key
[switch-frame] ignore [t] fancy-splash-default-action [mouse-movement]
[mode-line t] nil t propertize " %b %-" face (:weight bold) float-time 60
run-with-timer 0 fancy-splash-screens-1 recursive-edit fancy-splash-max-time
fancy-splash-stop-time fancy-splash-delay splash-buffer timer] 6)
fancy-splash-screens()
display-splash-screen()
call-interactively(display-splash-screen)
In GNU Emacs 22.0.50.4 (i686-pc-linux-gnu, GTK+ Version 2.6.4)
of 2005-03-21 on lola.goethe.zz
Distributor `The X.Org Foundation', version 11.0.60802000
configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk'
'--without-toolkit-scroll-bars''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US
locale-coding-system: iso-latin-1
default-enable-multibyte-characters: t
Major mode: Summary
Minor modes in effect:
TeX-PDF-mode: t
file-name-shadow-mode: t
auto-compression-mode: t
desktop-save-mode: t
iswitchb-mode: t
minibuffer-electric-default-mode: t
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
line-number-mode: t
Recent input:
n , SPC b u t SPC I SPC w o u l d SPC n o t SPC d e
p e n d SPC o n SPC i t . C-c C-c q C-c C-c q SPC E
E q 3 SPC SPC SPC
C-x 1
C-x h w M-x M-x r e p o r t -
e m a c s - b u g
Recent messages:
No more articles [2 times]
Retrieving newsgroup: de.comp.editoren...
Fetching headers for de.comp.editoren...done
Scoring...done
Generating summary...done
Auto-saving...done
Entering debugger...
tooltip-show-help-function: Wrong type argument: wholenump, nil
Mark set [2 times]
Loading emacsbug...done
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Dangerous behavior when copying to current directory
Richard Stallman <[EMAIL PROTECTED]> writes: > It is not very dangerous, since it asks the user for confirmation. I just have been bitten by something even worse: namely rename-file. I wanted to move a file into some other directory. So I did M-x rename-file RET somefilename RET /tmp RET then I got the question "/tmp/ already exists. Continue?" Well, weird question, but I replied "yes" to it, figuring that it would not recursively remove the directory and the worst that could happen would be that this fails. What happened is that Emacs took the name of the current buffer and overwrote the file with that name in /tmp. I did not notice this until it told me the file on disk had changed and would I want to revert. Thinking it was CVS-related, I did. Undo did not work, no backup yet. I recovered the file contents from a mail where I had sent out the latest version to a customer. > But it may be inconvenient and annoying. It is more than that. Overwriting an unrelated file, and in the case of rename-file even completely without announcing the file that is going to suffer the damage, is intolerable. Even if there is a question "file exists" when the target is a directory. > I agree it would be better to change this. It is not easy to do, > since there is no way for a C primitive to use Lisp code to read the > arguments. Then it should just refuse to do anything instead of writing over what amounts to an arbitrary unrelated file. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Dangerous behavior when copying to current directory
This bug report will be sent to the Free Software Foundation, not to your local site managers! 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 the bug: I am editing a file, and then I do M-x copy-file /tmp/somefileelsewhere else RET As the target of the copy, my current directory gets displayed. Convenient. I press return since I want to copy the file into the current directory and Emacs asks whether I really want to overwrite the current file I am editing! Of course not. If I don't specify a file name for the copy, I'd expect it to use the original file name, not choose to overwrite whatever I might be working with at the current point of time. At no time (before the question was asked) was the file name ever in the prompt or editing string. In GNU Emacs 22.0.50.29 (i686-pc-linux-gnu, GTK+ Version 2.6.2) of 2005-03-03 on lola.goethe.zz Distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars' 'CFLAGS=-ggdb -O2 -fno-crossjumping'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: PDFLaTeX Minor modes in effect: reftex-mode: t TeX-PDF-mode: t auto-compression-mode: t desktop-save-mode: t file-name-shadow-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: p / b an o q M-x c o p y - f / b a r r o s o 0 5 0 2 . p d f M-x e m a c s - r e p o r e [ p p o r t - e m a c s - b u g Recent messages: Entering debugger... Back to top level. Mark set [3 times] Making completion list... Loading jit-lock...done Auto-saving... Entering debugger... Back to top level. Making completion list... Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
And another crash when scrolling around. No xassert this time.
r mode: C Minor modes in effect: TeX-PDF-mode: t auto-compression-mode: t desktop-save-mode: t file-name-shadow-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t mouse-wheel-mode: t menu-bar-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t abbrev-mode: t Recent input: M-x r e p o r t - e m a c s Recent messages: Loading info...done unzipping latex.info.gz...done unzipping autoconf.info.gz...done Desktop: File "/home/tmp/emacs/admin/.cvsignore" no longer exists. Loading message... Loading executable...done Loading message...done Loading gnus-ems...done Desktop: 29 buffers restored, 1 failed to restore. Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Another crash in scrolling.
[EMAIL PROTECTED] (Kim F. Storm) writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >> Here is at least the dump, "it" does not seem set to any useful >> value. Probably I should set the breakpoint on abort in order to get >> a useful backtrace. > > I cannot reproduce the crash here. Well, basically I run preview-latex on some larger buffer, then page through the buffer forwards and backwards. >> Breakpoint 1, abort () at /home/tmp/emacs/src/emacs.c:456 >> 456 kill (getpid (), SIGABRT); >> (gdb) bt >> #0 abort () at /home/tmp/emacs/src/emacs.c:456 >> #1 0x080997b0 in move_it_vertically_backward (it=0xe6c, dy=0) >> at /home/tmp/emacs/src/xdisp.c:6370 > > Could you try to remove the assert in that line, and see if things > work well without it. There you are, here is the next one: 456 kill (getpid (), SIGABRT); (gdb) bt #0 abort () at /home/tmp/emacs/src/emacs.c:456 #1 0x080997b0 in move_it_vertically_backward (it=0xe6c, dy=0) at /home/tmp/emacs/src/xdisp.c:6321 #2 0x08099364 in move_it_by_lines (it=0xbfecf6e0, dvpos=-2, need_y_p=0) at /home/tmp/emacs/src/xdisp.c:6496 #3 0x080be80f in window_scroll (window=139571676, n=-1074989344, whole=1, noerror=0) at /home/tmp/emacs/src/window.c:4809 #4 0x080be931 in scroll_command (n=137490449, direction=-1) at /home/tmp/emacs/src/window.c:4999 #5 0x080be96f in Fscroll_down (arg=3353) at /home/tmp/emacs/src/window.c:5029 #6 0x08171bf9 in Ffuncall (nargs=2, args=0xbfecfa64) at /home/tmp/emacs/src/eval.c:2783 #7 0x0816e90c in Fcall_interactively (function=137687993, record_flag=137490449, keys=137547324) at /home/tmp/emacs/src/callint.c:877 #8 0x081194a3 in Fcommand_execute (cmd=137687993, record_flag=137490449, keys=137490449, special=137490449) at /home/tmp/emacs/src/keyboard.c:9697 #9 0x08120129 in command_loop_1 () at /home/tmp/emacs/src/keyboard.c:1792 #10 0x0816ff26 in internal_condition_case (bfun=0x811fdd0 , handlers=137551441, hfun=0x8119db0 ) at /home/tmp/emacs/src/eval.c:1385 #11 0x0811485a in command_loop_2 () at /home/tmp/emacs/src/keyboard.c:1319 #12 0x0816fe35 in internal_catch (tag=3353, func=0x811483c , arg=137490449) at /home/tmp/emacs/src/eval.c:1144 #13 0x08114669 in command_loop () at /home/tmp/emacs/src/keyboard.c:1298 #14 0x08114703 in recursive_edit_1 () at /home/tmp/emacs/src/keyboard.c:991 #15 0x081147fe in Frecursive_edit () at /home/tmp/emacs/src/keyboard.c:1052 #16 0x08113b85 in main (argc=3, argv=0xbfed0274) at /home/tmp/emacs/src/emacs.c:1766 (gdb) xbacktrace "scroll-down" "call-interactively" (gdb) > I suspect the two asserts in move_it_vertically_backward are bogus > (although they do appear to be perfectly sane). In connection with preview-latex, it is dangerous to talk about sanity. It changes the _displayed_ text on the screen in filter routines, but exclusively by changing _overlays_, not actually touching the text, but replacing its visual representation with images of differing sizes instead. One crash had a "sit-for" in its backtrace IIRC, and that is one of the opportunities where filter routines run. However, I think that most crashes occured at a time where this filter routine business was not active. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Another crash in scrolling.
[EMAIL PROTECTED] (Kim F. Storm) writes: > David Kastrup <[EMAIL PROTECTED]> writes: > >> Here is at least the dump, "it" does not seem set to any useful >> value. Probably I should set the breakpoint on abort in order to get >> a useful backtrace. > > I cannot reproduce the crash here. > >> >> Breakpoint 1, abort () at /home/tmp/emacs/src/emacs.c:456 >> 456 kill (getpid (), SIGABRT); >> (gdb) bt >> #0 abort () at /home/tmp/emacs/src/emacs.c:456 >> #1 0x080997b0 in move_it_vertically_backward (it=0xe6c, dy=0) >> at /home/tmp/emacs/src/xdisp.c:6370 > > Could you try to remove the assert in that line, and see if things > work well without it. > > I suspect the two asserts in move_it_vertically_backward are > bogus (although they do appear to be perfectly sane). I'll try. Anyway, I set the breakpoint on abort as well and tried getting any useful information out of "it". No such luck. Probably the stack frame is not in useful state. Perhaps I need to switch to gcc4 as compiler as that is supposed to output sufficient debug information to let the debugger keep track of variable values even in the presence of optimization. Sigh. I'll give removing the assertion a try. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Another crash in scrolling.
This bug report will be sent to the Free Software Foundation, not to your local site managers! 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 the bug: Ok, this time I have a screenshot. Oh, RATS. It is a screenshot of the debugger window. Ok, so I don't have one. But there was a large image with the cursor on it at the bottom of the window in question, and I pressed the Page-Down key (bound to scroll-up). Quite likely lower in the file were more images. Here is at least the dump, "it" does not seem set to any useful value. Probably I should set the breakpoint on abort in order to get a useful backtrace. Breakpoint 1, abort () at /home/tmp/emacs/src/emacs.c:456 456 kill (getpid (), SIGABRT); (gdb) bt #0 abort () at /home/tmp/emacs/src/emacs.c:456 #1 0x080997b0 in move_it_vertically_backward (it=0xe6c, dy=0) at /home/tmp/emacs/src/xdisp.c:6370 #2 0x080be7c0 in window_scroll (window=139571676, n=1, whole=1, noerror=0) at /home/tmp/emacs/src/window.c:4570 #3 0x080be95d in scroll_command (n=137490449, direction=1) at /home/tmp/emacs/src/window.c:4999 #4 0x080be9b7 in Fscroll_up (arg=3353) at /home/tmp/emacs/src/window.c:5015 #5 0x08171c25 in Ffuncall (nargs=2, args=0xbfe60574) at /home/tmp/emacs/src/eval.c:2783 #6 0x0816e938 in Fcall_interactively (function=137687969, record_flag=137490449, keys=137547324) at /home/tmp/emacs/src/callint.c:877 #7 0x081194cf in Fcommand_execute (cmd=137687969, record_flag=137490449, keys=137490449, special=137490449) at /home/tmp/emacs/src/keyboard.c:9697 #8 0x08120155 in command_loop_1 () at /home/tmp/emacs/src/keyboard.c:1792 #9 0x0816ff52 in internal_condition_case (bfun=0x811fdfc , handlers=137551441, hfun=0x8119ddc ) at /home/tmp/emacs/src/eval.c:1385 #10 0x08114886 in command_loop_2 () at /home/tmp/emacs/src/keyboard.c:1319 #11 0x0816fe61 in internal_catch (tag=3353, func=0x8114868 , arg=137490449) at /home/tmp/emacs/src/eval.c:1144 #12 0x08114695 in command_loop () at /home/tmp/emacs/src/keyboard.c:1298 #13 0x0811472f in recursive_edit_1 () at /home/tmp/emacs/src/keyboard.c:991 #14 0x0811482a in Frecursive_edit () at /home/tmp/emacs/src/keyboard.c:1052 #15 0x08113bb1 in main (argc=3, argv=0xbfe60d84) at /home/tmp/emacs/src/emacs.c:1766 (gdb) xbacktrace "scroll-up" "call-interactively" (gdb) In GNU Emacs 22.0.50.4 (i686-pc-linux-gnu, GTK+ Version 2.6.2) of 2005-02-20 on lola.goethe.zz Distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-undo-mode: t TeX-PDF-mode: t auto-compression-mode: t desktop-save-mode: t file-name-shadow-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t mouse-wheel-mode: t menu-bar-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: M-x g n u n n 3 SPC E q M-x r e p o r t - e m a c s - b u Recent messages: Processing kill file /home/dak/News/comp.emacs.KILL...done Loading gnus-bcklg...done Loading gnus-async...done Loading mail-extr...done Loading flow-fill...done Loading smiley...done Loading gnus-cite...done No more articles [2 times] No more unread newsgroups Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Abort when scrolling around images
t Major mode: Change Log Minor modes in effect: TeX-PDF-mode: t auto-compression-mode: t desktop-save-mode: t file-name-shadow-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t mouse-wheel-mode: t menu-bar-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t transient-mark-mode: identity Recent input: M-x r e p o r t - e m a c s - b u Recent messages: Applying style hooks... done Loading cc-mode...done Loading info... Loading tool-bar...done Loading info...done unzipping latex.info.gz...done unzipping autoconf.info.gz...done Desktop: File "/home/tmp/emacs/admin/.cvsignore" no longer exists. Desktop: 26 buffers restored, 1 failed to restore. Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error with MetaPost mode and transient-mark-mode
Does the following patch fix it? --- meta-mode.el 22 Aug 2004 12:39:49 +0200 1.10 +++ meta-mode.el 18 Feb 2005 15:10:07 +0100 @@ -898,7 +898,7 @@ ;; Compatibility: XEmacs doesn't have the `mark-active' variable. (defun meta-mark-active () "Return whether the mark and region are currently active in this buffer." - (or (and (boundp 'mark-active) mark-active) (mark))) + (if (boundp 'mark-active) mark-active (mark))) -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: search-forward-regexp has stopped working on multibyte
Richard Stallman <[EMAIL PROTECTED]> writes: > Place a few multibyte characters in the buffer, say with > C-u C-\ latin-1-prefix RET "a "o "s > > Copy them into the killring. Type > M-: (search-forward-regexp (regexp-quote " > Press C-y and then > ")) RET > > And nothing gets found. Not good. > > It doesn't fail for me. I can't reproduce it at the moment. Maybe the language environment (inadvertantly broken for a while on my system) had something to with it. But even with a similarly broken setting of LC_CTYPE I could not reproduce the effect I had seen. Anyway, it was certainly related to case conversion since binding case-fold-search to nil made the strings be found again. Maybe something has changed in that area. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
search-forward-regexp has stopped working on multibyte
This bug report will be sent to the Free Software Foundation, not to your local site managers! 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 the bug: Place a few multibyte characters in the buffer, say with C-u C-\ latin-1-prefix RET "a "o "s Copy them into the killring. Type M-: (search-forward-regexp (regexp-quote " Press C-y and then ")) RET And nothing gets found. Not good. This must have happened rather recently, I think. Well, probably in the last month or so. In GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.6.2) of 2005-02-13 on lola.goethe.zz Distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: C value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US locale-coding-system: nil default-enable-multibyte-characters: t Major mode: LaTeX Minor modes in effect: reftex-mode: t auto-compression-mode: t desktop-save-mode: t file-name-shadow-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t mouse-wheel-mode: t menu-bar-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t transient-mark-mode: identity Recent input: h - f o r w a r d - r e g e x p SPC ( r e g e x p - q u o t e SPC " C-y " ) ) : ( C-g : ( s e a r c h - f o r w a r d SPC " C-y " ) M-x r e p o r t - e m a c s - b u C-g M-x r e p o r t - e m a c s - b u Recent messages: Saving /home/dak/.newsrc.eld... Saving file /home/dak/.newsrc.eld... Wrote /home/dak/.newsrc.eld Saving /home/dak/.newsrc.eld...done eval: Search failed: "für \\$y\\$" Quit 7344 (016260, 0x1cb0) Quit Loading emacsbug...done call-interactively: Text is read-only -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Help with partial line needed
"Jan D." <[EMAIL PROTECTED]> writes: > There is definitly some bug in fluxbox, it sends the most crazy > configure notify events to Emacs when the tool bar is detached. It > usually sends three, two correct ones and one that is off by about 5 > pixels. It is those missing 5 pixels that shrinks the window > (i.e. Emacs rounds it to an even line). There should only be one > configure notify. > > Emacs is special in the way it handles (or rather the GTK version) > detaching and attaching of the tool bar. It tries to keep the same > lines as before, thus the resizing and the configure notify events. Hm. > I see that other applications instead keeps the total pixel size, so > then no configure notify is sent (the frame size is kept). I can > change to that behaviour, but since the tool bar height may not be a > multiple of the line height (as it is in other Emacs ports), there > will most probably be a partial line. And that partial line is the > minibuffer. It would be better if that partial line was in a > non-minibuffer. Does anybody know how to achive that (I just call > change_frame_size)? More concretely: it would be perfect if the _whole_ area from the toolbar was added to the window immediately below the toolbar, and if at the same time vscrol was adjusted by that amount, so that detaching and reattaching the toolbar would not cause any text to move on the screen. There may be exceptions: a) if the buffer display is already at the beginning of the buffer when the toolbar gets detached, the window contents will have to move up. b) if attaching the toolbar moves the cursor off-screen, recentering will become necessary. And of course, the toolbar can't be attached in that manner if the top window does not have the space to accommodate it. > There are another race condition involving configure notify and tool > bar attach/detach, but they happen very seldom, and usually ends up > growing the Emacs frame rather than shrink it. The fluxbox > behaviour is not changed by fixing that race condition. I haven't > checked in the fix for the race condition. If there is a way to > force the partial line to a non-minibuffer I think I'll go with that > solution instead. That sounds much better. > Sorry I couldn't help. Well, if the problem with fluxbox could be wrapped in a bug report and sent to the maintainers, this _could_ help. For me, the effect is not overly tragic since I usually don't use the toolbar, let alone detach it. Detached, I'd consider it quite more useful if it would be vertically arranged, but I have no clue about what GTK+ might offer in that respect. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bad resizing upon detaching/reattaching GTK toolbar
"Jan D." <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>
>>This bug report will be sent to the Free Software Foundation,
>>not to your local site managers!
>>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 the bug:
>>
>>When one detaches and reattaches the toolbar by dragging on its
>>handle, each time the total size of the Emacs window shrinks. This is
>>particularly noisome since it is not easy to reattach the toolbar
>>without the state attached/detached flickering a few times, and each
>>time one line of the window is gone.
>
> I can not reproduce this, what window manager are you running?
Fluxbox.
> Do you get the same behaviour if you disable and enable
> tool-bar-mode?
First I get a backtrace. Sigh.
Debugger entered--Lisp error: (wrong-type-argument keymapp nil)
signal(wrong-type-argument (keymapp nil))
define-key-after(nil [customize] (menu-item "customize" customize :image
(image :type xpm :file
"/usr/local/emacs-21/share/emacs/21.3.50/lisp/toolbar/preferences.xpm") :help
"Edit preferences (customize)"))
tool-bar-local-item("preferences" customize customize nil :help "Edit
preferences (customize)")
apply(tool-bar-local-item "preferences" customize customize nil (:help "Edit
preferences (customize)"))
tool-bar-add-item("preferences" customize customize :help "Edit preferences
(customize)")
tool-bar-setup()
tool-bar-mode(toggle)
call-interactively(tool-bar-mode)
execute-extended-command(nil)
call-interactively(execute-extended-command)
Then the frame gets oversized (namely, the text window size does not
shrink to accommodate the toolbar size, and consequently the
minibuffer gets off-screen). If I disable the toolbar again, the
frame shrinks to normal size again, as the window size stays the same.
However, this first toggling is "neutral" only because of the back
trace, apparently (I have debug-on-error set to t).
The next time I call tool-bar-mode (no backtrace this time), the
window-size _adapts_ to the reduced space. Disabling tool-bar-mode
again, the window does _not_ adapt to the additional space again.
After that, enabling the toolbar makes the size adapt, so the frame
size stays more or less the same while the window size shrinks, and
disabling the toolbar lets the window size stay the same, thus causing
the frame to shrink.
The same happens when detaching and reattaching the toolbar: detach
the toolbar, and the window does not grow in spite of the additional
space, attach it again, and the window shrinks.
Maybe this is an effect of the combination of my line height and the
size of the toolbar? I use 10x20 as my normal font, and the startup
geometry is 80x35.
My X resources contain Emacs.toolBar: 0, so I don't have a toolbar on
startup normally.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Bad resizing upon detaching/reattaching GTK toolbar
This bug report will be sent to the Free Software Foundation, not to your local site managers! 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 the bug: When one detaches and reattaches the toolbar by dragging on its handle, each time the total size of the Emacs window shrinks. This is particularly noisome since it is not easy to reattach the toolbar without the state attached/detached flickering a few times, and each time one line of the window is gone. In GNU Emacs 21.3.50.32 (i686-pc-linux-gnu, GTK+ Version 2.6.1) of 2005-02-01 on lola.goethe.zz Distributor `The X.Org Foundation', version 11.0.60801904 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US locale-coding-system: iso-latin-1 default-enable-multibyte-characters: t Major mode: Fundamental Minor modes in effect: tool-bar-mode: t TeX-PDF-mode: t auto-compression-mode: t desktop-save-mode: t file-name-shadow-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t mouse-wheel-mode: t menu-bar-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t Recent input: C-x k C-x o M-x c v s - e x a / h o m e / t m p / e a u c t e x S O o C-x k C-x k C-x 1 M-x r e p o r t - e m Recent messages: CVS process has completed in *cvs*<2> (No files need saving) Running cvs update ... CVS process has completed in *cvs*<3> call-interactively: Beginning of buffer (No files need saving) Running cvs update ... CVS process has completed in *cvs*<3> call-interactively: Beginning of buffer [2 times] Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
