rcirc fails to authenticate with bitlbee
In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-04-20 on DEYKE1 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4)' rcirc fails to authenticate with bitlbee. The error message is: 08:36 *** 401 bitlbee Nick does not exist The following patch fixes the problem for me: *** old-rcirc.elSun Apr 23 08:30:37 2006 --- new-rcirc.elSun Apr 23 08:31:03 2006 *** *** 2140,2146 ((equal method 'bitlbee) (rcirc-send-string process ! (concat PRIVMSG bitlbee :identify (car args (t (message No %S authentication method defined method --- 2140,2146 ((equal method 'bitlbee) (rcirc-send-string process ! (concat PRIVMSG #bitlbee :identify (car args (t (message No %S authentication method defined method -- Dieter Deyke mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Vs lbh pna ernq guvf, lbh unir jnl gbb zhpu gvzr. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar-setup overwrites local tool-bar-map
Richard Stallman [EMAIL PROTECTED] writes: You can reproduce with emacs22 -Q --xrm Emacs.toolBar:0. Is this a corner-case we wish to fix? I think so. We should fix every case, except when the fix is so hard or risky that we decide to let it go. My (last) patch still seems to be working well for me. Is anyone else observing this problem that can verify the patch? If not, does anyone object if I try checking it in so we can see if it causes problems for others? (Does anyone on this list use tool bars? ;-) -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-abbrev-file
I cannot reproduce the problem. Maybe it has been fixed since February. Does it fail in the latest sources? If so, can you try to debug it by running under GDB and putting a breakpoint at Fsignal? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon / tool-bar: changes in size temporarily
I just installed changes in emacs CVS to fix this problem - which is also seen on X when changing fonts to e.g. Courier 24 and/or Courier 18 Fixing that bug revealed another bug which could cause the toolbar icons to appear twice in the line -- I fixed that too. Please see if the problem has been fixed for you. David Reitter [EMAIL PROTECTED] writes: In the Carbon port, when a large font (e.g. Monaco 18) is selected for a frame, the tool-bar becomes (visually) much higher (I guess 3 lines high). However, when you toggle the visibility of the tool-bar, for example with the following code (modify-frame-parameters nil '((tool-bar-lines . 0))) (modify-frame-parameters nil '((tool-bar-lines . 1))) the tool-bar shrinks back to a visually much more appealing height - that is, about 2 lines high. It would be consistent if the tool-bar resized directly to the lowest multiple of line height that is larger than the maximal icon height when the font is changed. That would be 2 lines in this case. Begin forwarded message: From: Konrad Podczeck [EMAIL PROTECTED] Date: 29 March 2006 21:01:02 BDT To: David Reitter [EMAIL PROTECTED], aquamacs- [EMAIL PROTECTED] Subject: Three bugs with 0.9.9 (2) There is some strange behaviour of the toolbar now. Example: I start Aquamacs and open a texfile, initially displayed in Monaco 14. I change the font to TimesNewRoman 18, and as a byproduct the height of the toolbar drastically increases. I invoke the button for toggling the appearance of the toolbar twice, and now the height of the toolbar is smaller, and in fact smaller then it was initially when I opened the file in Monaco 14. I didn't observe such behaviour in earlier versions of Aquamacs. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: syntax-ppss bug?
I tracked down the problem below to an infloop in python-beginning-of-statement which occurs because syntax-ppss returns -1 as the depth. I think that is the wrong value. Would you please investigate? It does sound like an incorrect value indeed. Is it ever legitimate for syntax-ppss to return negative depth values? I think it is not. So I think if it ever does so, it is a reason to do something to cope with confusion. Perhaps it should pick a different defun start, or replace the negative value with 0, or just signal an error. I suspect this Python program was garbled by introduction of incorrect line breaks, and that it is actually invalid. Do you know? If true, that doesn't change the fact that this is a bug in Emacs, but it does mean that there is no need to worry about what indentation is correct for this case. Please work on this and respond. I'll look at it and get back to you, Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
