Menu
▾
▴
erc-help — Archive of problems, bugs, features, news
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
(46) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(5) |
Feb
|
Mar
(6) |
Apr
(2) |
May
(25) |
Jun
(2) |
Jul
(1) |
Aug
(5) |
Sep
(4) |
Oct
(7) |
Nov
|
Dec
(18) |
| 2003 |
Jan
(8) |
Feb
(1) |
Mar
(2) |
Apr
(4) |
May
(14) |
Jun
(32) |
Jul
(15) |
Aug
(23) |
Sep
(23) |
Oct
(22) |
Nov
(27) |
Dec
(24) |
| 2004 |
Jan
(18) |
Feb
(38) |
Mar
(32) |
Apr
(18) |
May
(70) |
Jun
(1) |
Jul
(21) |
Aug
(19) |
Sep
(32) |
Oct
(11) |
Nov
(11) |
Dec
(19) |
| 2005 |
Jan
(48) |
Feb
(13) |
Mar
(19) |
Apr
(25) |
May
(4) |
Jun
(23) |
Jul
(8) |
Aug
(13) |
Sep
(12) |
Oct
(17) |
Nov
(4) |
Dec
(5) |
| 2006 |
Jan
(31) |
Feb
(30) |
Mar
(28) |
Apr
(11) |
May
(21) |
Jun
(7) |
Jul
(12) |
Aug
(5) |
Sep
(7) |
Oct
(24) |
Nov
(2) |
Dec
|
|
From: Stefan <mo...@ir...> - 2004-09-19 07:01:25
|
> When a buffer has no file name, basic-save-buffer will prompt the user
> interactively for one. Since before-save-hook isn't run until after
> the interactive request for a file name, this prevents a hook from
> setting a file name based on external factors (such as the time),
> without first requiring the user to input some junk data. The use of
> "" was a hack to avoid prompting, since for ERC logging, the value of
> buffer-file-name is ignored and computed by a routine instead.
Why use "" rather than something else (since you say it's ignored anyway)?
I suspect "" will create other problems than just with this new VC code.
E.g. I wouldn't be surprised to see it bump into uniquify for example.
Stefan
|
|
From: Damien E. <da...@re...> - 2004-09-19 04:20:56
|
Romain Francoise <ro...@or...> writes: >> Where is the use of "" as a value of buffer-file-name documented? > > See the commit message for erc-log.el rev. 1.7: > > | (erc-log-setup-logging): set buffer-file-name to "", as (basic-save-buffer) > | will prompt for a buffer name before invoking hooks. the buffer-file-name > | will be overridden by (erc-save-buffer-in-logs) anyway - the main danger > | of doing this is write-file-contents hooks. Let's see if anyone complains. > | (erc-save-buffer-in-logs): return t, so that further write hooks are not run > > The real problem is probably that buffer-file-name cannot be set in > advance to the correct value since the filename will often be based on > the date/time of saving. When a buffer has no file name, basic-save-buffer will prompt the user interactively for one. Since before-save-hook isn't run until after the interactive request for a file name, this prevents a hook from setting a file name based on external factors (such as the time), without first requiring the user to input some junk data. The use of "" was a hack to avoid prompting, since for ERC logging, the value of buffer-file-name is ignored and computed by a routine instead. Cheers, Damien |
|
From: Romain F. <ro...@or...> - 2004-09-18 20:09:19
|
Adrian Aichner <ad...@xe...> writes: > Where is the use of "" as a value of buffer-file-name documented? See the commit message for erc-log.el rev. 1.7: | (erc-log-setup-logging): set buffer-file-name to "", as (basic-save-buffer) | will prompt for a buffer name before invoking hooks. the buffer-file-name | will be overridden by (erc-save-buffer-in-logs) anyway - the main danger | of doing this is write-file-contents hooks. Let's see if anyone complains. | (erc-save-buffer-in-logs): return t, so that further write hooks are not run The real problem is probably that buffer-file-name cannot be set in advance to the correct value since the filename will often be based on the date/time of saving. CC'ing Damien for comments. -- Romain Francoise <ro...@or...> | And you never lay down and it's a miracle -- http://orebokech.com/ | you never stay home... |
|
From: Adrian A. <ad...@xe...> - 2004-09-18 18:59:39
|
The following message is a courtesy copy of an article that has been posted to gmane.emacs.devel as well. Romain Francoise <ro...@or...> writes: > This change is problematic for buffers where buffer-file-name is "" > (like ERC server buffers in my case), file-name-directory returns nil so Hi Romain, Stefan, I can confirm this for ERC channel buffers as well, running with CVS erc and consider this a bug just like Stefan. Where is the use of "" as a value of buffer-file-name documented? Best regards, Adrian > string-match signals an error. It makes it impossible to quit Emacs > (you need to kill all such buffers manually). -- Adrian Aichner mailto:ad...@xe... http://www.xemacs.org/ |
|
From: Alex S. <al...@em...> - 2004-09-17 00:55:36
|
Does anybody know why the *tip* buffer sometimes appears in
erc-modified-channels-alist? I think it only happens if you enable
erc-track-when-inactive-mode.
The following patch will remove all buffers that are not in erc-mode
from the alist. I'd still like to know why it got added in the first
place. :( I'm not sure what to do about this... I think we should
debug some more.
Alex.
diff -c "c:/Programme/Emacs/site-lisp/erc/erc-track.el.~1.65.~" "c:/Programme/Emacs/site-lisp/erc/erc-track.el"
*** c:/Programme/Emacs/site-lisp/erc/erc-track.el.~1.65.~ Sat Aug 14 22:09:35 2004
--- c:/Programme/Emacs/site-lisp/erc/erc-track.el Thu Sep 16 14:44:28 2004
***************
*** 471,477 ****
(let ((buffer (car elt)))
(when (or (not (bufferp buffer))
(not (buffer-live-p buffer))
! (erc-buffer-visible buffer))
(erc-modified-channels-remove-buffer buffer))))
erc-modified-channels-alist)
(erc-modified-channels-display)
--- 471,479 ----
(let ((buffer (car elt)))
(when (or (not (bufferp buffer))
(not (buffer-live-p buffer))
! (erc-buffer-visible buffer)
! (not (with-current-buffer buffer
! (eq major-mode 'erc-mode))))
(erc-modified-channels-remove-buffer buffer))))
erc-modified-channels-alist)
(erc-modified-channels-display)
Diff finished. Thu Sep 16 14:44:49 2004
|
|
From: Jorgen S. <fo...@fo...> - 2004-08-14 20:43:36
|
Jorgen Schaefer <fo...@fo...> writes:
> Hi there!
> Bojohan managed to talk me into refactoring erc-send-current-line,
> which needed that _badly_. Since it's a big change, he had the
> idea of posting the diff on the list and ask wether people are
> happy with it.
Since noone objected, I just commited the change as revision 1.694.
Good luck!
-- Jorgen
--
((email . "fo...@fo...") (www . "http://www.forcix.cx/")
(gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet"))
|
|
From: <boj...@dd...> - 2004-08-03 03:34:33
|
Lucas Bonnet <lu...@ri...> writes: > "VERSION \C-bERC\C-b %s - an IRC client for emacs (\C-b%s\C-b)" I think it should say "XEmacs" on XEmacs (and "Emacs" on Emacs) and perhaps the Emacs version. "an IRC client" is redundant, btw. -- Johan Bockgård |
|
From: Lucas B. <lu...@ri...> - 2004-08-02 10:56:57
|
2 août 2004, 12:59 : Lawrence Mitchell wrote: > (info "(elisp)Documentation Tips") Ok, thanks. I thought it was a flag like the FIXME or something like that. -- Lucas / Lukhas |
|
From: Lawrence M. <we...@gm...> - 2004-08-02 10:34:28
|
Lucas Bonnet wrote: [...] > BTW, why should i put a "*" in front of the docstring ? (info "(elisp)Documentation Tips") -- Lawrence Mitchell <we...@gm...> |
|
From: Lucas B. <lu...@ri...> - 2004-08-01 22:25:23
|
2 août 2004, 00:27 :Andreas Schwab wrote: > That's not how defcustom works. You need to add a :group and a :type > spec. > > Andreas. How about that : (defcustom erc-ctcp-query-VERSION-string (format "VERSION \C-bERC\C-b %s - an IRC client for emacs (\C-b%s\C-b)" erc-version-string erc-official-location) "*The string to return to a CTCP VERSION query." :group 'erc :type '(choice (const nil) string)) BTW, why should i put a "*" in front of the docstring ? -- Lucas / Lukhas |
|
From: Andreas S. <sc...@su...> - 2004-08-01 22:11:00
|
Lucas Bonnet <lu...@ri...> writes: > +(defcustom erc-ctcp-query-VERSION-string=20 > + (format > + "VERSION \C-bERC\C-b %s - an IRC client for emacs (\C-b%s\C-b)" > + erc-version-string > + erc-official-location) > + "*The string to return to a CTCP VERSION query.") That's not how defcustom works. You need to add a :group and a :type spec. Andreas. --=20 Andreas Schwab, SuSE Labs, sc...@su... SuSE Linux AG, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany Key fingerprint =3D 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." |
|
From: Lucas B. <lu...@ri...> - 2004-08-01 21:11:25
|
1 août 2004, 23:01 :Lawrence Mitchell wrote:
> Lucas Bonnet wrote:
>
>> -(defun erc-ctcp-query-VERSION (proc nick login host to msg)
>> +(defun my-erc-ctcp-query-VERSION (proc nick login host to msg)
>
> Ooops :).
Hehe, as you say :)
> Other than that, make erc-ctcp-query-VERSION-string a defcustom,
> rather than a defvar, since it's changable by the user, and add a
^- changeable :P
> "*" as the first character of the docstring.
Okay boss.
New version attached.
--
Lucas / Lukhas
|
|
From: Lawrence M. <we...@gm...> - 2004-08-01 20:40:23
|
Lucas Bonnet wrote: > -(defun erc-ctcp-query-VERSION (proc nick login host to msg) > +(defun my-erc-ctcp-query-VERSION (proc nick login host to msg) Ooops :). Other than that, make erc-ctcp-query-VERSION-string a defcustom, rather than a defvar, since it's changable by the user, and add a "*" as the first character of the docstring. -- Lawrence Mitchell <we...@gm...> |
|
From: <boj...@dd...> - 2004-07-29 16:52:04
|
Brian Palmer <bp...@re...> writes: [...] >> (setq user-input (read-from-minibuffer "IRC server: " (erc-compute-server nil) nil nil 'erc-server-history-list)) Please keep the line length down to 80 columns. (imho) -- Johan Bockgård |
|
From: Jeremy Maitin-S. <jb...@at...> - 2004-07-21 00:06:44
|
Lawrence Mitchell <we...@gm...> writes: > [snip] > Either way, from what I can recall (no recourse to ERC sources > here), I don't think we religiously follow the defcustom is > user-changable rule. So that might be something worth looking at. I often forget to add the "*" because I never use `set-variable' myself -- I just evaluate a `setq' form, since it is actually less typing, it works even if a "*" was not used, and I can still get tab completion on the variable name (using M-TAB by default, since the minibuffer is set to emacs-lisp-mode when `eval-expression' is run). -- Jeremy Maitin-Shepard |
|
From: Lawrence M. <we...@gm...> - 2004-07-20 20:47:24
|
Brian Palmer wrote: [...] > One thing I noticed when looking over the patch, is there a reason why > the erc-kill-*-on-* variables are only defcustomizable, but not > set-variable--able? > that is, they're defined with something like > (defcustom erc-kill-queries-on-quit nil > "Kill all query (also channel) buffers of this server on QUIT. > See the variable `erc-kill-buffer-on-part' for details." >> group 'erc >> type 'boolean) > without an initial * in the docstring. Probably an oversight. You might want to add something to HACKING to the effect that variables that are intended to be user-changed should have an inital * in the docstring. I /believe/ there was some discussion about emacs for making all defcustom'ed variables also set-variable-able. However, I don't think set-variable uses the same mechanism, (i.e. not using the custom :set form if it exists), and so nothing came of it. Either way, from what I can recall (no recourse to ERC sources here), I don't think we religiously follow the defcustom is user-changable rule. So that might be something worth looking at. -- Lawrence Mitchell <we...@gm...> |
|
From: Brian P. <bp...@re...> - 2004-07-20 19:19:14
|
Michael Olson <mw...@me...> writes: > On Thu, 15 Jul 2004 13:11:53 +0100, lawrence mitchell wrote: > > That way you don't have to worry about the dodgy behaviour of > > beginning-of-line with invisible/intangible stuff, and you don't > > add the prompt to the kill ring, which would definitely not be > > expected by the user. > > You're right. The included patch incorporates this change. Also: I > forgot to remove the comment about XEmacs; as far as I know, this > method works just as well for XEmacs as with GNU Emacs. Committed. Comments welcome. One thing I noticed when looking over the patch, is there a reason why the erc-kill-*-on-* variables are only defcustomizable, but not set-variable--able? that is, they're defined with something like (defcustom erc-kill-queries-on-quit nil "Kill all query (also channel) buffers of this server on QUIT. See the variable `erc-kill-buffer-on-part' for details." :group 'erc :type 'boolean) without an initial * in the docstring. -- I'm awfully glad I'm a Beta, because I don't work so hard. |
|
From: Brian P. <bp...@re...> - 2004-07-16 16:23:46
|
Brian Palmer <bp...@re...> writes: > Currently erc-select is a interactive function which doesn't actually > set any of its arguments from the (interactive) form; instead, in the > main body of the function, it calls read-from-minibuffer several times > to get important information from the user. Some of this information > is stored in separate history lists, but other information (such as > the port number) is let into the general minibuffer history. I've committed this (well, with some minor changes). If you're using erc-select interactively, there should be few visible differences. 1. [username@]server[:port] if typed at the server question will cause it to skip some of the subsequent questions. The prompt has not changed, however, to indicate this. 2. the port will now use the value of erc-port, if set, to provide a default instead of the old way of hardcoding "ircd" as the default port. If used non-interactively, erc-select now does not read from the minibuffer. Instead, it uses keyword arguments and default values (defun* erc-select (&key (server erc-server) (port erc-port) (nick erc-nick) password (full-name erc-user-full-name)) to get arguments to send to erc. Since erc was basically unusable non-interactively before, I expect this situation is the best time to make incompatible changes for non-interactive. (Note that the previous version I had sent for comment used only &optional arguments). Comments welcome. -- I'm awfully glad I'm a Beta, because I don't work so hard. |
|
From: Michael O. <mw...@me...> - 2004-07-15 21:04:09
|
On Thu, 15 Jul 2004 21:15:09 +0100, lawrence mitchell wrote: > Michael Olson wrote: > >> On Thu, 15 Jul 2004 13:11:53 +0100, lawrence mitchell wrote: > >>> Why does let-binding (I assume that's what you're doing) >>> inhibit-read-only to t not allow reconnection. That sounds like >>> a deeper problem, but, without looking, I'm not really sure. > >> I think this is a problem with Emacs from CVS. I never experienced >> that problem with Emacs 21.3 . I'm thinking about reporting this >> problem to the emacs-devel list. XEmacs handled an attempt to kill >> read-only text by refusing to do it, even though the buffer had the >> inhibit-read-only flag set. > If this is indeed the case, then I think we probably want to > report it as an Emacs bug, rather than use work-arounds in ERC. > However, I see that you no longer use this method (due to the > problems it causes) --- is the new code "neater" than the old > buggy stuff? I'll go into some detail about the problem. The message that appears when the lock-up occurs is "error in process sentinel: erc-encode-coding-string: Text is read-only". I traced that error and found the path of execution to be: erc-process-sentinel -> erc-login -> erc-display-message My guess is that when I used: (let ((inhibit-read-only t)) (kill-line 0)) to kill the prompt, Emacs would allow the text to be killed, but the next time ERC tried to write "special" text properties like read-only to the buffer, Emacs choked. The use of erc-remove-text-properties-region is indeed a much better approach, IMO, as it works on both Emacs and XEmacs, and more elegantly solves the problem at hand. I'll try to come up with a sample routine that will break Emacs, so that the Emacs maintainers can replicate the error. |
|
From: lawrence m. <we...@gm...> - 2004-07-15 20:15:14
|
Michael Olson wrote: > On Thu, 15 Jul 2004 13:11:53 +0100, lawrence mitchell wrote: >> Why does let-binding (I assume that's what you're doing) >> inhibit-read-only to t not allow reconnection. That sounds like >> a deeper problem, but, without looking, I'm not really sure. > I think this is a problem with Emacs from CVS. I never experienced > that problem with Emacs 21.3 . I'm thinking about reporting this > problem to the emacs-devel list. XEmacs handled an attempt to kill > read-only text by refusing to do it, even though the buffer had the > inhibit-read-only flag set. If this is indeed the case, then I think we probably want to report it as an Emacs bug, rather than use work-arounds in ERC. However, I see that you no longer use this method (due to the problems it causes) --- is the new code "neater" than the old buggy stuff? [...] -- lawrence mitchell <we...@gm...> |
|
From: Michael O. <mw...@me...> - 2004-07-15 20:04:39
|
On Thu, 15 Jul 2004 13:11:53 +0100, lawrence mitchell wrote:
> Why does let-binding (I assume that's what you're doing)
> inhibit-read-only to t not allow reconnection. That sounds like
> a deeper problem, but, without looking, I'm not really sure.
I think this is a problem with Emacs from CVS. I never experienced
that problem with Emacs 21.3 . I'm thinking about reporting this
problem to the emacs-devel list. XEmacs handled an attempt to kill
read-only text by refusing to do it, even though the buffer had the
inhibit-read-only flag set.
>>> ;; Kill the prompt
>>> ;; (XEmacs users beware: it doesn't seem to work for you)
>>> (beginning-of-line)
>>> (erc-remove-text-properties-region (point) (point-max))
>>> (kill-line nil)
>
> Better written as:
>
> (forward-line 0)
> (erc-remove-text-properties-region (point) (point-max))
> (delete-region (point) (point-max))
>
> That way you don't have to worry about the dodgy behaviour of
> beginning-of-line with invisible/intangible stuff, and you don't
> add the prompt to the kill ring, which would definitely not be
> expected by the user.
You're right. The included patch incorporates this change. Also: I
forgot to remove the comment about XEmacs; as far as I know, this
method works just as well for XEmacs as with GNU Emacs.
*** Beginning of patch ***
Index: erc.el
===================================================================
RCS file: /cvsroot/erc/erc/erc.el,v
retrieving revision 1.672
diff -u -b -w -r1.672 erc.el
--- erc.el 14 Jun 2004 20:56:47 -0000 1.672
+++ erc.el 15 Jul 2004 20:01:39 -0000
@@ -913,6 +913,11 @@
:group 'erc
:type 'boolean)
+(defcustom erc-kill-server-buffer-on-quit nil
+ "Kill the server buffer of the process on QUIT."
+ :group 'erc
+ :type 'boolean)
+
(defcustom erc-quit-reason-various-alist nil
"Alist of possible arguments to the /quit command.
@@ -2402,58 +2407,69 @@
(erc-parse-server-response proc line))
(erc-split-multiline string))))
+(defun erc-process-sentinel-1 (event)
+ "This will be called when erc-process-sentinel has decided that we
+are going to quit. Determine whether user has quit or whether erc has
+been terminated. Conditionally try to reconnect and take appropriate
+action."
+ (if quitting
+ ;; normal quit
+ (progn
+ (let ((string "\n\n*** ERC finished ***\n"))
+ (erc-put-text-property 0 (length string)
+ 'face 'erc-error-face string)
+ (insert string))
+ (when erc-kill-server-buffer-on-quit
+ (set-buffer-modified-p nil)
+ (kill-buffer (current-buffer))))
+ ;; unexpected disconnect
+ (erc-display-message nil 'error (current-buffer)
+ (if erc-auto-reconnect
+ 'disconnected
+ 'disconnected-noreconnect))
+ (erc-update-mode-line)
+ (setq erc-active-buffer (current-buffer))
+ (setq last-sent-time 0)
+ (setq erc-lines-sent 0)
+ (if erc-auto-reconnect
+ (erc erc-session-server erc-session-port current-nick
+ erc-session-user-full-name t erc-session-password)
+ ;; terminate, do not reconnect
+ (let ((string (concat "\n\n*** ERC terminated: " event
+ "\n")))
+ (erc-put-text-property 0 (length string)
+ 'face 'erc-error-face string)
+ (insert string)))))
+
(defun erc-process-sentinel (cproc event)
"Sentinel function for ERC process."
+ (with-current-buffer (process-buffer cproc)
(erc-log (format
"SENTINEL: proc: %S status: %S event: %S (quitting: %S)"
erc-process (process-status erc-process) event quitting))
- (save-excursion
- (set-buffer (process-buffer cproc))
- (cond
- ((equal event "open\n")
- ;; newly opened connection for a nowait connection
- (erc-login))
- ;; ((eq event 'failed)))
- ;; default to this
- (t
+ (if (equal event "open\n")
+ ;; newly opened connection (no wait)
+ (erc-login)
+ ;; assume event is 'failed
+ (let ((buf (process-buffer cproc)))
(erc-with-all-buffers-of-server cproc nil (setq erc-connected nil))
(when erc-ping-handler
- (with-current-buffer (current-buffer)
(progn (cancel-timer erc-ping-handler)
- (setq erc-ping-handler nil))))
+ (setq erc-ping-handler nil)))
(run-hook-with-args 'erc-disconnected-hook
(erc-current-nick) (system-name) "")
- (if (string= event "exited abnormally with code 256\n")
-
- ;; Sometimes (eg on a /LIST command) ERC happens to die with
- ;; an exit code 256. The icrii client also shows this behavior
- ;; and it restarts itself. So do I.
-
- (cond
- ((not quitting)
- (erc-display-message nil 'error (current-buffer)
- (if erc-auto-reconnect
- 'disconnected
- 'disconnected-noreconnect))
+ ;; Remove the prompt
+ (forward-line 0)
+ (erc-remove-text-properties-region (point) (point-max))
+ (delete-region (point) (point-max))
+ ;; Decide what to do with the buffer
+ ;; Restart if disconnected
+ (erc-process-sentinel-1 event)
+ ;; Make sure we don't write to the buffer if it has been
+ ;; killed
+ (when (buffer-live-p buf)
(erc-update-mode-line)
- (setq erc-active-buffer (current-buffer))
- (setq last-sent-time 0)
- (setq erc-lines-sent 0)
- (when erc-auto-reconnect
- (erc erc-session-server erc-session-port current-nick
- erc-session-user-full-name t erc-session-password))
- (goto-char (point-max)))
- (t
- (let* ((wd (window-width))
- (msg "*** ERC finished ***")
- (off (/ (- wd (length msg)) 2))
- (s ""))
- (if (> off 0)
- (setq s (make-string off ? )))
- (insert (concat "\n\n" s msg "\n")))))
- (insert (concat "\n\n*** ERC terminated: " event "\n"))))
- (goto-char (point-max))
- (erc-update-mode-line))))
+ (set-buffer-modified-p nil))))))
;;; I/O interface
*** End of patch ***
|
|
From: lawrence m. <we...@gm...> - 2004-07-15 12:11:58
|
Michael Olson wrote: [...] > I figured out what the problem is. My original patch tried to set the > inhibit-read-only variable to `t' in order to be able to kill the > prompt when exiting. What I needed to do was use > erc-remove-text-properties-region to remove the read-only property of > the prompt before killing. Why does let-binding (I assume that's what you're doing) inhibit-read-only to t not allow reconnection. That sounds like a deeper problem, but, without looking, I'm not really sure. [...] >> ;; Kill the prompt >> ;; (XEmacs users beware: it doesn't seem to work for you) >> (beginning-of-line) >> (erc-remove-text-properties-region (point) (point-max)) >> (kill-line nil) Better written as: (forward-line 0) (erc-remove-text-properties-region (point) (point-max)) (delete-region (point) (point-max)) That way you don't have to worry about the dodgy behaviour of beginning-of-line with invisible/intangible stuff, and you don't add the prompt to the kill ring, which would definitely not be expected by the user. [...] -- lawrence mitchell <we...@gm...> |
|
From: Michael O. <mw...@me...> - 2004-07-15 04:11:28
|
On Wed, 14 Jul 2004 21:19:30 -0500, Michael Olson wrote:
> When I /QUIT from a server and then reconnect to it later, Emacs
> (the CVS version) flashes the visual bell at me so fast that it
> causes Emacs to lock up. It won't respond to any keystrokes.
I figured out what the problem is. My original patch tried to set the
inhibit-read-only variable to `t' in order to be able to kill the
prompt when exiting. What I needed to do was use
erc-remove-text-properties-region to remove the read-only property of
the prompt before killing.
In addition, I'm using the -b and -w options for this diff so I don't
mess things up my manually editing the diff to get rid of unwanted
whitespace changes.
Index: erc.el
===================================================================
RCS file: /cvsroot/erc/erc/erc.el,v
retrieving revision 1.672
diff -u -b -w -r1.672 erc.el
--- erc.el 14 Jun 2004 20:56:47 -0000 1.672
+++ erc.el 15 Jul 2004 03:58:23 -0000
@@ -913,6 +913,11 @@
:group 'erc
:type 'boolean)
+(defcustom erc-kill-server-buffer-on-quit nil
+ "Kill the server buffer of the process on QUIT."
+ :group 'erc
+ :type 'boolean)
+
(defcustom erc-quit-reason-various-alist nil
"Alist of possible arguments to the /quit command.
@@ -2402,58 +2407,70 @@
(erc-parse-server-response proc line))
(erc-split-multiline string))))
+(defun erc-process-sentinel-1 (event)
+ "This will be called when erc-process-sentinel has decided that we
+are going to quit. Determine whether user has quit or whether erc has
+been terminated. Conditionally try to reconnect and take appropriate
+action."
+ (if quitting
+ ;; normal quit
+ (progn
+ (let ((string "\n\n*** ERC finished ***\n"))
+ (erc-put-text-property 0 (length string)
+ 'face 'erc-error-face string)
+ (insert string))
+ (when erc-kill-server-buffer-on-quit
+ (set-buffer-modified-p nil)
+ (kill-buffer (current-buffer))))
+ ;; unexpected disconnect
+ (erc-display-message nil 'error (current-buffer)
+ (if erc-auto-reconnect
+ 'disconnected
+ 'disconnected-noreconnect))
+ (erc-update-mode-line)
+ (setq erc-active-buffer (current-buffer))
+ (setq last-sent-time 0)
+ (setq erc-lines-sent 0)
+ (if erc-auto-reconnect
+ (erc erc-session-server erc-session-port current-nick
+ erc-session-user-full-name t erc-session-password)
+ ;; terminate, do not reconnect
+ (let ((string (concat "\n\n*** ERC terminated: " event
+ "\n")))
+ (erc-put-text-property 0 (length string)
+ 'face 'erc-error-face string)
+ (insert string)))))
+
(defun erc-process-sentinel (cproc event)
"Sentinel function for ERC process."
+ (with-current-buffer (process-buffer cproc)
(erc-log (format
"SENTINEL: proc: %S status: %S event: %S (quitting: %S)"
erc-process (process-status erc-process) event quitting))
- (save-excursion
- (set-buffer (process-buffer cproc))
- (cond
- ((equal event "open\n")
- ;; newly opened connection for a nowait connection
- (erc-login))
- ;; ((eq event 'failed)))
- ;; default to this
- (t
+ (if (equal event "open\n")
+ ;; newly opened connection (no wait)
+ (erc-login)
+ ;; assume event is 'failed
+ (let ((buf (process-buffer cproc)))
(erc-with-all-buffers-of-server cproc nil (setq erc-connected nil))
(when erc-ping-handler
- (with-current-buffer (current-buffer)
(progn (cancel-timer erc-ping-handler)
- (setq erc-ping-handler nil))))
+ (setq erc-ping-handler nil)))
(run-hook-with-args 'erc-disconnected-hook
(erc-current-nick) (system-name) "")
- (if (string= event "exited abnormally with code 256\n")
-
- ;; Sometimes (eg on a /LIST command) ERC happens to die with
- ;; an exit code 256. The icrii client also shows this behavior
- ;; and it restarts itself. So do I.
-
- (cond
- ((not quitting)
- (erc-display-message nil 'error (current-buffer)
- (if erc-auto-reconnect
- 'disconnected
- 'disconnected-noreconnect))
+ ;; Kill the prompt
+ ;; (XEmacs users beware: it doesn't seem to work for you)
+ (beginning-of-line)
+ (erc-remove-text-properties-region (point) (point-max))
+ (kill-line nil)
+ ;; Decide what to do with the buffer
+ ;; Restart if disconnected
+ (erc-process-sentinel-1 event)
+ ;; Make sure we don't write to the buffer if it has been
+ ;; killed
+ (when (buffer-live-p buf)
(erc-update-mode-line)
- (setq erc-active-buffer (current-buffer))
- (setq last-sent-time 0)
- (setq erc-lines-sent 0)
- (when erc-auto-reconnect
- (erc erc-session-server erc-session-port current-nick
- erc-session-user-full-name t erc-session-password))
- (goto-char (point-max)))
- (t
- (let* ((wd (window-width))
- (msg "*** ERC finished ***")
- (off (/ (- wd (length msg)) 2))
- (s ""))
- (if (> off 0)
- (setq s (make-string off ? )))
- (insert (concat "\n\n" s msg "\n")))))
- (insert (concat "\n\n*** ERC terminated: " event "\n"))))
- (goto-char (point-max))
- (erc-update-mode-line))))
+ (set-buffer-modified-p nil))))))
;;; I/O interface
|
|
From: Michael O. <mw...@me...> - 2004-07-15 02:19:37
|
> Francis Litterio wrote: > > Please keep in mind that GNU Emacs versions 21.3.2 and earlier do not > call the process sentinel when you kill a server buffer, so the more > work that's done in the sentinel, the wierder ERC will behave when a > server buffer is killed in those versions of GNU Emacs. I don't think my patch is moving any major functionality to erc-process-sentinel. It is, however, causing me to experience a problem. When I /QUIT from a server and then reconnect to it later, Emacs (the CVS version) flashes the visual bell at me so fast that it causes Emacs to lock up. It won't respond to any keystrokes. It looks like the unpatched version of erc doesn't cause this behavior, so I advise the erc maintainers to hold off on applying the patch until I can sort out the problems. Mike Olson |
|
From: Francis L. <fr...@wo...> - 2004-07-14 15:27:04
|
Please keep in mind that GNU Emacs versions 21.3.2 and earlier do not call the process sentinel when you kill a server buffer, so the more work that's done in the sentinel, the wierder ERC will behave when a server buffer is killed in those versions of GNU Emacs. See http://www.emacswiki.org/cgi-bin/wiki?ErcBugs for a description of this bug. -- Fran |
197 messages has been excluded from this view by a project administrator.
