Gnus development mailing list
 help / color / mirror / Atom feed
* closing all inactive server connections
@ 2007-07-07 15:59 Ted Zlatanov
  2007-07-10 19:54 ` Ted Zlatanov
  0 siblings, 1 reply; 32+ messages in thread
From: Ted Zlatanov @ 2007-07-07 15:59 UTC (permalink / raw)
  To: Ding Mailing List

Very often, my company's VPN will disconnect and my server connections
will hang.  I have to manually go into the server buffer and hit `C' on
each server to close the connection, then C-g to cancel the ensuing
timeout.  I have 8 servers (NNTP and IMAP) so this is slow and annoying.
My questions are:

1) is there a way to close all the server connections without the
connection timeout?

2) can I set the time a connection becomes inactive (so it needs to be
reopened) to a few seconds?  It seems to be several minutes right now.
Perhaps this is not a Gnus attribute but a system-level TCP setting, I
don't know how Gnus and Emacs manage TCP connections.

Thanks
Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-07 15:59 closing all inactive server connections Ted Zlatanov
@ 2007-07-10 19:54 ` Ted Zlatanov
  2007-07-19 13:46   ` Ted Zlatanov
  0 siblings, 1 reply; 32+ messages in thread
From: Ted Zlatanov @ 2007-07-10 19:54 UTC (permalink / raw)
  To: Ding Mailing List

On Sat, 07 Jul 2007 11:59:40 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> Very often, my company's VPN will disconnect and my server connections
TZ> will hang.  I have to manually go into the server buffer and hit `C' on
TZ> each server to close the connection, then C-g to cancel the ensuing
TZ> timeout.  I have 8 servers (NNTP and IMAP) so this is slow and annoying.
TZ> My questions are:

TZ> 1) is there a way to close all the server connections without the
TZ> connection timeout?

I should mention that I know about gnus-server-close-all-servers, but it
doesn't do all the server connections.  For some reason the variable
gnus-inserted-opened-servers is an incomplete list after a VPN outage.

TZ> 2) can I set the time a connection becomes inactive (so it needs to be
TZ> reopened) to a few seconds?  It seems to be several minutes right now.
TZ> Perhaps this is not a Gnus attribute but a system-level TCP setting, I
TZ> don't know how Gnus and Emacs manage TCP connections.

I still haven't figured this one out.

Thanks
Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-10 19:54 ` Ted Zlatanov
@ 2007-07-19 13:46   ` Ted Zlatanov
  2007-07-27 17:06     ` Ted Zlatanov
  0 siblings, 1 reply; 32+ messages in thread
From: Ted Zlatanov @ 2007-07-19 13:46 UTC (permalink / raw)
  To: Ding Mailing List

On Tue, 10 Jul 2007 15:54:58 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Sat, 07 Jul 2007 11:59:40 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 
TZ> Very often, my company's VPN will disconnect and my server connections
TZ> will hang.  I have to manually go into the server buffer and hit `C' on
TZ> each server to close the connection, then C-g to cancel the ensuing
TZ> timeout.  I have 8 servers (NNTP and IMAP) so this is slow and annoying.
TZ> My questions are:

TZ> 1) is there a way to close all the server connections without the
TZ> connection timeout?

TZ> I should mention that I know about gnus-server-close-all-servers, but it
TZ> doesn't do all the server connections.  For some reason the variable
TZ> gnus-inserted-opened-servers is an incomplete list after a VPN
TZ> outage.

I figured it out, finally.  gnus-server-close-all-servers works on the
servers defined in my Gnus setup, but not on those I subscribed directly
through newsrc.eld (by visiting a foreign news server and subscribing to
individual newsgroups).  I believe this is a bug, can anyone verify?

Thanks
Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-19 13:46   ` Ted Zlatanov
@ 2007-07-27 17:06     ` Ted Zlatanov
  2007-07-28  0:18       ` Ted Zlatanov
  0 siblings, 1 reply; 32+ messages in thread
From: Ted Zlatanov @ 2007-07-27 17:06 UTC (permalink / raw)
  To: Ding Mailing List

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

On Thu, 19 Jul 2007 09:46:43 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Tue, 10 Jul 2007 15:54:58 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 
TZ> On Sat, 07 Jul 2007 11:59:40 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 
TZ> Very often, my company's VPN will disconnect and my server connections
TZ> will hang.  I have to manually go into the server buffer and hit `C' on
TZ> each server to close the connection, then C-g to cancel the ensuing
TZ> timeout.  I have 8 servers (NNTP and IMAP) so this is slow and annoying.
TZ> My questions are:

TZ> 1) is there a way to close all the server connections without the
TZ> connection timeout?

TZ> I should mention that I know about gnus-server-close-all-servers, but it
TZ> doesn't do all the server connections.  For some reason the variable
TZ> gnus-inserted-opened-servers is an incomplete list after a VPN
TZ> outage.

TZ> I figured it out, finally.  gnus-server-close-all-servers works on the
TZ> servers defined in my Gnus setup, but not on those I subscribed directly
TZ> through newsrc.eld (by visiting a foreign news server and subscribing to
TZ> individual newsgroups).  I believe this is a bug, can anyone verify?

Here's a version of gnus-server-close-all-servers that works on all the
server in the buffer.  I preserved the old (buggy I think) behavior with
the `some' parameter.  Can I commit this change?  It works for me.

Unfortunately there were tabs in the gnus-srvr.el file (aren't we
supposed to use untabify?) so the patch comes out too long.  Here's the
method:

(defun gnus-server-close-all-servers (&optional some)
  "Close all servers.  With SOME, only the inserted opened ones will be closed."
  (interactive)
  (let ((servers (if some		     
		     gnus-inserted-opened-servers
		   gnus-server-alist)))
  (dolist (server servers)
    (gnus-server-close-server (car server)))))

in case you don't want to slog through the patch.

Thanks
Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gnus-srvr.patch --]
[-- Type: text/x-patch, Size: 23722 bytes --]

Index: gnus-srvr.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-srvr.el,v
retrieving revision 7.29
diff -r7.29 gnus-srvr.el
254c254
< 	 '(gnus-server-font-lock-keywords t)))
---
>          '(gnus-server-font-lock-keywords t)))
259,275c259,275
< 	 (gnus-tmp-where (nth 1 method))
< 	 (elem (assoc method gnus-opened-servers))
< 	 (gnus-tmp-status
< 	  (cond
< 	   ((eq (nth 1 elem) 'denied) "(denied)")
< 	   ((eq (nth 1 elem) 'offline) "(offline)")
< 	   (t
< 	    (condition-case nil
< 		(if (or (gnus-server-opened method)
< 			(eq (nth 1 elem) 'ok))
< 		    "(opened)"
< 		  "(closed)")
< 	      ((error) "(error)")))))
< 	 (gnus-tmp-agent (if (and gnus-agent
< 				  (gnus-agent-method-p method))
< 			     " (agent)"
< 			   "")))
---
>          (gnus-tmp-where (nth 1 method))
>          (elem (assoc method gnus-opened-servers))
>          (gnus-tmp-status
>           (cond
>            ((eq (nth 1 elem) 'denied) "(denied)")
>            ((eq (nth 1 elem) 'offline) "(offline)")
>            (t
>             (condition-case nil
>                 (if (or (gnus-server-opened method)
>                         (eq (nth 1 elem) 'ok))
>                     "(opened)"
>                   "(closed)")
>               ((error) "(error)")))))
>          (gnus-tmp-agent (if (and gnus-agent
>                                   (gnus-agent-method-p method))
>                              " (agent)"
>                            "")))
298c298
< 	(gnus-carpal-setup-buffer 'server)))))
---
>         (gnus-carpal-setup-buffer 'server)))))
304,305c304,305
< 	(buffer-read-only nil)
< 	done server op-ser)
---
>         (buffer-read-only nil)
>         done server op-ser)
311,314c311,314
< 	(push (cdar alist) done)
< 	(setq server (pop alist))
< 	(when (and server (car server) (cdr server))
< 	  (gnus-server-insert-server-line (car server) (cdr server))))
---
>         (push (cdar alist) done)
>         (setq server (pop alist))
>         (when (and server (car server) (cdr server))
>           (gnus-server-insert-server-line (car server) (cdr server))))
316c316
< 	(pop alist)))
---
>         (pop alist)))
321,327c321,327
< 		 ;; Just ignore ephemeral servers.
< 		 (not (member (car open) gnus-ephemeral-servers)))
< 	(push (car open) done)
< 	(gnus-server-insert-server-line
< 	 (setq op-ser (format "%s:%s" (caar open) (nth 1 (car open))))
< 	 (car open))
< 	(push (list op-ser (car open)) gnus-inserted-opened-servers))))
---
>                  ;; Just ignore ephemeral servers.
>                  (not (member (car open) gnus-ephemeral-servers)))
>         (push (car open) done)
>         (gnus-server-insert-server-line
>          (setq op-ser (format "%s:%s" (caar open) (nth 1 (car open))))
>          (car open))
>         (push (list op-ser (car open)) gnus-inserted-opened-servers))))
349,351c349,351
< 	   (entry (assoc server gnus-server-alist))
< 	   (oentry (assoc (gnus-server-to-method server)
< 			  gnus-opened-servers)))
---
>            (entry (assoc server gnus-server-alist))
>            (oentry (assoc (gnus-server-to-method server)
>                           gnus-opened-servers)))
353,355c353,355
< 	(gnus-dribble-enter
< 	 (concat "(gnus-server-set-info \"" server "\" '"
< 		 (gnus-prin1-to-string (cdr entry)) ")\n")))
---
>         (gnus-dribble-enter
>          (concat "(gnus-server-set-info \"" server "\" '"
>                  (gnus-prin1-to-string (cdr entry)) ")\n")))
357,367c357,367
< 	;; Buffer may be narrowed.
< 	(save-restriction
< 	  (widen)
< 	  (when (gnus-server-goto-server server)
< 	    (gnus-delete-line))
< 	  (if entry
< 	      (gnus-server-insert-server-line (car entry) (cdr entry))
< 	    (gnus-server-insert-server-line
< 	     (format "%s:%s" (caar oentry) (nth 1 (car oentry)))
< 	     (car oentry)))
< 	  (gnus-server-position-point))))))
---
>         ;; Buffer may be narrowed.
>         (save-restriction
>           (widen)
>           (when (gnus-server-goto-server server)
>             (gnus-delete-line))
>           (if entry
>               (gnus-server-insert-server-line (car entry) (cdr entry))
>             (gnus-server-insert-server-line
>              (format "%s:%s" (caar oentry) (nth 1 (car oentry)))
>              (car oentry)))
>           (gnus-server-position-point))))))
374c374
< 	     (gnus-prin1-to-string info) ")"))
---
>              (gnus-prin1-to-string info) ")"))
376,377c376,377
< 	   (entry (assoc server gnus-server-alist))
< 	   (cached (assoc server gnus-server-method-cache)))
---
>            (entry (assoc server gnus-server-alist))
>            (cached (assoc server gnus-server-method-cache)))
379,380c379,380
< 	  (setq gnus-server-method-cache
< 		(delq cached gnus-server-method-cache)))
---
>           (setq gnus-server-method-cache
>                 (delq cached gnus-server-method-cache)))
382,390c382,390
< 	  (progn
< 	    ;; Remove the server from `gnus-opened-servers' since
< 	    ;; it has never been opened with the new `info' yet.
< 	    (gnus-opened-servers-remove (cdr entry))
< 	    ;; Don't make a new Lisp object.
< 	    (setcar (cdr entry) (car info))
< 	    (setcdr (cdr entry) (cdr info)))
< 	(setq gnus-server-alist
< 	      (nconc gnus-server-alist (list (cons server info))))))))
---
>           (progn
>             ;; Remove the server from `gnus-opened-servers' since
>             ;; it has never been opened with the new `info' yet.
>             (gnus-opened-servers-remove (cdr entry))
>             ;; Don't make a new Lisp object.
>             (setcar (cdr entry) (car info))
>             (setcdr (cdr entry) (cdr info)))
>         (setq gnus-server-alist
>               (nconc gnus-server-alist (list (cons server info))))))))
407c407
< 				gnus-server-alist))
---
>                                 gnus-server-alist))
410,412c410,412
< 	       (gnus-yes-or-no-p
< 		(format "Kill all %s groups from this server? "
< 			(length groups))))
---
>                (gnus-yes-or-no-p
>                 (format "Kill all %s groups from this server? "
>                         (length groups))))
414,419c414,419
< 	(setq gnus-newsrc-alist
< 	      (delq (assoc group gnus-newsrc-alist)
< 		    gnus-newsrc-alist))
< 	(when gnus-group-change-level-function
< 	  (funcall gnus-group-change-level-function
< 		   group gnus-level-killed 3)))))
---
>         (setq gnus-newsrc-alist
>               (delq (assoc group gnus-newsrc-alist)
>                     gnus-newsrc-alist))
>         (when gnus-group-change-level-function
>           (funcall gnus-group-change-level-function
>                    group gnus-level-killed 3)))))
428,429c428,429
< 	(server (gnus-server-server-name))
< 	(killed (car gnus-server-killed-servers)))
---
>         (server (gnus-server-server-name))
>         (killed (car gnus-server-killed-servers)))
431c431
< 	(setq gnus-server-alist (nconc gnus-server-alist (list killed)))
---
>         (setq gnus-server-alist (nconc gnus-server-alist (list killed)))
433,439c433,439
< 	  (push killed gnus-server-alist)
< 	(while (and (cdr alist)
< 		    (not (string= server (caadr alist))))
< 	  (setq alist (cdr alist)))
< 	(if alist
< 	    (setcdr alist (cons killed (cdr alist)))
< 	  (setq gnus-server-alist (list killed)))))
---
>           (push killed gnus-server-alist)
>         (while (and (cdr alist)
>                     (not (string= server (caadr alist))))
>           (setq alist (cdr alist)))
>         (if alist
>             (setcdr alist (cons killed (cdr alist)))
>           (setq gnus-server-alist (list killed)))))
465c465
< 	(setcar (cdr entry) status)
---
>         (setcar (cdr entry) status)
471c471
< 				  gnus-opened-servers)))
---
>                                   gnus-opened-servers)))
481,482c481,482
< 	(or (gnus-open-server method)
< 	    (progn (message "Couldn't open %s" server) nil))
---
>         (or (gnus-open-server method)
>             (progn (message "Couldn't open %s" server) nil))
500c500
< 	(gnus-close-server method)
---
>         (gnus-close-server method)
511c511
< 	(gnus-close-server method)
---
>         (gnus-close-server method)
516,517c516,517
< (defun gnus-server-close-all-servers ()
<   "Close all servers."
---
> (defun gnus-server-close-all-servers (&optional some)
>   "Close all servers.  With SOME, only the inserted opened ones will be closed."
519,520c519,523
<   (dolist (server gnus-inserted-opened-servers)
<     (gnus-server-close-server (car server))))
---
>   (let ((servers (if some
>                       gnus-inserted-opened-servers
>                    gnus-server-alist)))
>   (dolist (server servers)
>     (gnus-server-close-server (car server)))))
545c548
< 	(error "No server on the current line"))
---
>         (error "No server on the current line"))
556c559
< 			      (gnus-server-to-method from)))))
---
>                               (gnus-server-to-method from)))))
565,566c568,569
< 				  gnus-valid-select-methods nil t))
< 	 (read-string "Server name: ")))
---
>                                   gnus-valid-select-methods nil t))
>          (read-string "Server name: ")))
577c580
< 			       'gnus-server (intern server))))
---
>                                'gnus-server (intern server))))
594,596c597,599
< 	(gnus-server-set-info ,server form)
< 	(gnus-server-list-servers)
< 	(gnus-server-position-point))
---
>         (gnus-server-set-info ,server form)
>         (gnus-server-list-servers)
>         (gnus-server-position-point))
604c607
< 	(error "Server %s can't scan" (car method))
---
>         (error "Server %s can't scan" (car method))
620c623
< 	(gnus-browse-foreign-server server buf)
---
>         (gnus-browse-foreign-server server buf)
622,624c625,627
< 	(set-buffer buf)
< 	(gnus-server-update-server (gnus-server-server-name))
< 	(gnus-server-position-point)))))
---
>         (set-buffer buf)
>         (gnus-server-update-server (gnus-server-server-name))
>         (gnus-server-position-point)))))
697,699c700,702
< 	 (orig-select-method gnus-select-method)
< 	 (gnus-select-method method)
< 	 groups group)
---
>          (orig-select-method gnus-select-method)
>          (gnus-select-method method)
>          groups group)
709,711c712,714
< 	   (gnus-message 6 "Reading active file...")
< 	   (gnus-request-list method)
< 	 (gnus-message 6 "Reading active file...done")))
---
>            (gnus-message 6 "Reading active file...")
>            (gnus-request-list method)
>          (gnus-message 6 "Reading active file...done")))
717,757c720,760
< 	(let ((cur (current-buffer)))
< 	  (goto-char (point-min))
< 	  (unless (string= gnus-ignored-newsgroups "")
< 	    (delete-matching-lines gnus-ignored-newsgroups))
< 	  ;; We treat NNTP as a special case to avoid problems with
< 	  ;; garbage group names like `"foo' that appear in some badly
< 	  ;; managed active files. -jh.
< 	  (if (eq (car method) 'nntp)
< 	      (while (not (eobp))
< 		(ignore-errors
< 		  (push (cons
< 			 (mm-string-as-unibyte
< 			  (buffer-substring
< 			   (point)
< 			   (progn
< 			     (skip-chars-forward "^ \t")
< 			     (point))))
< 			 (let ((last (read cur)))
< 			   (cons (read cur) last)))
< 			groups))
< 		(forward-line))
< 	    (while (not (eobp))
< 	      (ignore-errors
< 		(push (cons
< 		       (mm-string-as-unibyte
< 			(if (eq (char-after) ?\")
< 			    (read cur)
< 			  (let ((p (point)) (name ""))
< 			    (skip-chars-forward "^ \t\\\\")
< 			    (setq name (buffer-substring p (point)))
< 			    (while (eq (char-after) ?\\)
< 			      (setq p (1+ (point)))
< 			      (forward-char 2)
< 			      (skip-chars-forward "^ \t\\\\")
< 			      (setq name (concat name (buffer-substring
< 						       p (point)))))
< 			    name)))
< 		       (let ((last (read cur)))
< 			 (cons (read cur) last)))
< 		      groups))
< 	      (forward-line)))))
---
>         (let ((cur (current-buffer)))
>           (goto-char (point-min))
>           (unless (string= gnus-ignored-newsgroups "")
>             (delete-matching-lines gnus-ignored-newsgroups))
>           ;; We treat NNTP as a special case to avoid problems with
>           ;; garbage group names like `"foo' that appear in some badly
>           ;; managed active files. -jh.
>           (if (eq (car method) 'nntp)
>               (while (not (eobp))
>                 (ignore-errors
>                   (push (cons
>                          (mm-string-as-unibyte
>                           (buffer-substring
>                            (point)
>                            (progn
>                              (skip-chars-forward "^ \t")
>                              (point))))
>                          (let ((last (read cur)))
>                            (cons (read cur) last)))
>                         groups))
>                 (forward-line))
>             (while (not (eobp))
>               (ignore-errors
>                 (push (cons
>                        (mm-string-as-unibyte
>                         (if (eq (char-after) ?\")
>                             (read cur)
>                           (let ((p (point)) (name ""))
>                             (skip-chars-forward "^ \t\\\\")
>                             (setq name (buffer-substring p (point)))
>                             (while (eq (char-after) ?\\)
>                               (setq p (1+ (point)))
>                               (forward-char 2)
>                               (skip-chars-forward "^ \t\\\\")
>                               (setq name (concat name (buffer-substring
>                                                        p (point)))))
>                             name)))
>                        (let ((last (read cur)))
>                          (cons (read cur) last)))
>                       groups))
>               (forward-line)))))
759,760c762,763
< 			 (lambda (l1 l2)
< 			   (string< (car l1) (car l2)))))
---
>                          (lambda (l1 l2)
>                            (string< (car l1) (car l2)))))
762,816c765,819
< 	  (let* ((gnus-select-method orig-select-method)
< 		 (gnus-group-listed-groups
< 		  (mapcar (lambda (group)
< 			    (let ((name
< 				   (gnus-group-prefixed-name
< 				    (car group) method)))
< 			      (gnus-set-active name (cdr group))
< 			      name))
< 			  groups)))
< 	    (gnus-configure-windows 'group)
< 	    (funcall gnus-group-prepare-function
< 		     gnus-level-killed 'ignore 1 'ignore))
< 	(gnus-get-buffer-create gnus-browse-buffer)
< 	(when gnus-carpal
< 	  (gnus-carpal-setup-buffer 'browse))
< 	(gnus-configure-windows 'browse)
< 	(buffer-disable-undo)
< 	(let ((buffer-read-only nil))
< 	  (erase-buffer))
< 	(gnus-browse-mode)
< 	(setq mode-line-buffer-identification
< 	      (list
< 	       (format
< 		"Gnus: %%b {%s:%s}" (car method) (cadr method))))
< 	(let ((buffer-read-only nil)
< 	      name
< 	      (prefix (let ((gnus-select-method orig-select-method))
< 			(gnus-group-prefixed-name "" method))))
< 	  (while (setq group (pop groups))
< 	    (gnus-add-text-properties
< 	     (point)
< 	     (prog1 (1+ (point))
< 	       (insert
< 		(format "%c%7d: %s\n"
< 			(let ((level
< 			       (if (string= prefix "")
< 				   (gnus-group-level (setq name (car group)))
< 				 (gnus-group-level
< 				  (concat prefix (setq name (car group)))))))
< 			  (cond
< 			   ((<= level gnus-level-subscribed) ? )
< 			   ((<= level gnus-level-unsubscribed) ?U)
< 			   ((= level gnus-level-zombie) ?Z)
< 			   (t ?K)))
< 			(max 0 (- (1+ (cddr group)) (cadr group)))
< 			;; Don't decode if name is ASCII
< 			(if (and (fboundp 'detect-coding-string)
< 				 (eq (detect-coding-string name t) 'undecided))
< 			    name
< 			  (mm-decode-coding-string
< 			   name
< 			   (inline (gnus-group-name-charset method name)))))))
< 	     (list 'gnus-group name)
< 	     )))
< 	(switch-to-buffer (current-buffer)))
---
>           (let* ((gnus-select-method orig-select-method)
>                  (gnus-group-listed-groups
>                   (mapcar (lambda (group)
>                             (let ((name
>                                    (gnus-group-prefixed-name
>                                     (car group) method)))
>                               (gnus-set-active name (cdr group))
>                               name))
>                           groups)))
>             (gnus-configure-windows 'group)
>             (funcall gnus-group-prepare-function
>                      gnus-level-killed 'ignore 1 'ignore))
>         (gnus-get-buffer-create gnus-browse-buffer)
>         (when gnus-carpal
>           (gnus-carpal-setup-buffer 'browse))
>         (gnus-configure-windows 'browse)
>         (buffer-disable-undo)
>         (let ((buffer-read-only nil))
>           (erase-buffer))
>         (gnus-browse-mode)
>         (setq mode-line-buffer-identification
>               (list
>                (format
>                 "Gnus: %%b {%s:%s}" (car method) (cadr method))))
>         (let ((buffer-read-only nil)
>               name
>               (prefix (let ((gnus-select-method orig-select-method))
>                         (gnus-group-prefixed-name "" method))))
>           (while (setq group (pop groups))
>             (gnus-add-text-properties
>              (point)
>              (prog1 (1+ (point))
>                (insert
>                 (format "%c%7d: %s\n"
>                         (let ((level
>                                (if (string= prefix "")
>                                    (gnus-group-level (setq name (car group)))
>                                  (gnus-group-level
>                                   (concat prefix (setq name (car group)))))))
>                           (cond
>                            ((<= level gnus-level-subscribed) ? )
>                            ((<= level gnus-level-unsubscribed) ?U)
>                            ((= level gnus-level-zombie) ?Z)
>                            (t ?K)))
>                         (max 0 (- (1+ (cddr group)) (cadr group)))
>                         ;; Don't decode if name is ASCII
>                         (if (and (fboundp 'detect-coding-string)
>                                  (eq (detect-coding-string name t) 'undecided))
>                             name
>                           (mm-decode-coding-string
>                            name
>                            (inline (gnus-group-name-charset method name)))))))
>              (list 'gnus-group name)
>              )))
>         (switch-to-buffer (current-buffer)))
858,863c861,866
< 	    (gnus-ephemeral-group-p group))
< 	(unless (gnus-group-read-ephemeral-group
< 		 group gnus-browse-current-method nil
< 		 (cons (current-buffer) 'browse)
< 		 nil nil nil number)
< 	  (error "Couldn't enter %s" group))
---
>             (gnus-ephemeral-group-p group))
>         (unless (gnus-group-read-ephemeral-group
>                  group gnus-browse-current-method nil
>                  (cons (current-buffer) 'browse)
>                  nil nil nil number)
>           (error "Couldn't enter %s" group))
865c868
< 	(error "Couldn't enter %s" group)))))
---
>         (error "Couldn't enter %s" group)))))
891c894
< 	(arg (abs arg)))
---
>         (arg (abs arg)))
893,895c896,898
< 		(not (eobp))
< 		(gnus-browse-unsubscribe-group)
< 		(zerop (gnus-browse-next-group ward)))
---
>                 (not (eobp))
>                 (gnus-browse-unsubscribe-group)
>                 (zerop (gnus-browse-next-group ward)))
907,909c910,912
< 	(concat (gnus-method-to-server-name gnus-browse-current-method) ":"
< 		(or name
< 		    (match-string-no-properties 1)))))))
---
>         (concat (gnus-method-to-server-name gnus-browse-current-method) ":"
>                 (or name
>                     (match-string-no-properties 1)))))))
919,920c922,923
< 	(buffer-read-only nil)
< 	group)
---
>         (buffer-read-only nil)
>         group)
925c928
< 	(setq sub t))
---
>         (setq sub t))
928c931
< 	(setq group (gnus-group-real-name group)))
---
>         (setq group (gnus-group-real-name group)))
930,954c933,957
< 	  (progn
< 	    ;; Make sure the group has been properly removed before we
< 	    ;; subscribe to it.
<  	    (if (gnus-ephemeral-group-p group)
< 		(gnus-kill-ephemeral-group group))
< 	    ;; We need to discern between killed/zombie groups and
< 	    ;; just unsubscribed ones.
< 	    (gnus-group-change-level
< 	     (or (gnus-group-entry group)
< 		 (list t group gnus-level-default-subscribed
< 		       nil nil (if (gnus-server-equal
< 				    gnus-browse-current-method "native")
< 				   nil
< 				 (gnus-method-simplify
< 				  gnus-browse-current-method))))
< 	     gnus-level-default-subscribed (gnus-group-level group)
< 	     (and (car (nth 1 gnus-newsrc-alist))
< 		  (gnus-group-entry (car (nth 1 gnus-newsrc-alist))))
< 	     (null (gnus-group-entry group)))
< 	    (delete-char 1)
< 	    (insert ? ))
< 	(gnus-group-change-level
< 	 group gnus-level-unsubscribed gnus-level-default-subscribed)
< 	(delete-char 1)
< 	(insert ?U)))
---
>           (progn
>             ;; Make sure the group has been properly removed before we
>             ;; subscribe to it.
>             (if (gnus-ephemeral-group-p group)
>                 (gnus-kill-ephemeral-group group))
>             ;; We need to discern between killed/zombie groups and
>             ;; just unsubscribed ones.
>             (gnus-group-change-level
>              (or (gnus-group-entry group)
>                  (list t group gnus-level-default-subscribed
>                        nil nil (if (gnus-server-equal
>                                     gnus-browse-current-method "native")
>                                    nil
>                                  (gnus-method-simplify
>                                   gnus-browse-current-method))))
>              gnus-level-default-subscribed (gnus-group-level group)
>              (and (car (nth 1 gnus-newsrc-alist))
>                   (gnus-group-entry (car (nth 1 gnus-newsrc-alist))))
>              (null (gnus-group-entry group)))
>             (delete-char 1)
>             (insert ? ))
>         (gnus-group-change-level
>          group gnus-level-unsubscribed gnus-level-default-subscribed)
>         (delete-char 1)
>         (insert ?U)))
974c977
< 		(substitute-command-keys "\\<gnus-browse-mode-map>\\[gnus-group-next-group]:Forward  \\[gnus-group-prev-group]:Backward  \\[gnus-browse-exit]:Exit  \\[gnus-info-find-node]:Run Info  \\[gnus-browse-describe-briefly]:This help")))
---
>                 (substitute-command-keys "\\<gnus-browse-mode-map>\\[gnus-group-next-group]:Forward  \\[gnus-group-prev-group]:Backward  \\[gnus-browse-exit]:Exit  \\[gnus-info-find-node]:Run Info  \\[gnus-browse-describe-briefly]:This help")))
983,984c986,987
< 	(gnus-get-function (gnus-server-to-method server)
< 			   'request-regenerate)
---
>         (gnus-get-function (gnus-server-to-method server)
>                            'request-regenerate)
986c989
< 	(error "This back end doesn't support regeneration")))
---
>         (error "This back end doesn't support regeneration")))
991c994
< 	(gnus-message 5 "Requesting regeneration of %s...done" server)
---
>         (gnus-message 5 "Requesting regeneration of %s...done" server)
1010,1011c1013,1014
< 	(gnus-get-function (gnus-server-to-method server)
< 			   'request-compact)
---
>         (gnus-get-function (gnus-server-to-method server)
>                            'request-compact)
1016c1019
< 		  server)
---
>                   server)
1020c1023
< 	(gnus-message 5 "Couldn't compact %s" server)
---
>         (gnus-message 5 "Couldn't compact %s" server)
1026c1029
< 	(and original (gnus-kill-buffer original))))))
---
>         (and original (gnus-kill-buffer original))))))

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-27 17:06     ` Ted Zlatanov
@ 2007-07-28  0:18       ` Ted Zlatanov
  2007-07-30  6:22         ` Katsumi Yamaoka
  0 siblings, 1 reply; 32+ messages in thread
From: Ted Zlatanov @ 2007-07-28  0:18 UTC (permalink / raw)
  To: Ding Mailing List

On Fri, 27 Jul 2007 13:06:14 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> Here's a version of gnus-server-close-all-servers that works on all the
TZ> server in the buffer.  I preserved the old (buggy I think) behavior with
TZ> the `some' parameter.  Can I commit this change?  It works for me.

I had to revise the function, apparently I need both lists.

(defun gnus-server-close-all-servers ()
  "Close all servers."
  (interactive)
  (let ((servers (append
                  gnus-inserted-opened-servers
                  gnus-server-alist)))
  (dolist (server servers)
    (gnus-server-close-server (car server)))))

I tested this on several Gnus setups and it seems OK.

TZ> Unfortunately there were tabs in the gnus-srvr.el file (aren't we
TZ> supposed to use untabify?) so the patch comes out too long.

Any response on this?  Reiner?  The function gnus-server-close-server is
definitely better that the old version, and I believe we shouldn't have
tabs.  I'll commit the untabified version unless I hear from someone.

Thanks
Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-28  0:18       ` Ted Zlatanov
@ 2007-07-30  6:22         ` Katsumi Yamaoka
  2007-07-30 15:39           ` Ted Zlatanov
  0 siblings, 1 reply; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-07-30  6:22 UTC (permalink / raw)
  To: ding

>>>>> Ted Zlatanov wrote:
> On Fri, 27 Jul 2007 13:06:14 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote:

TZ> Here's a version of gnus-server-close-all-servers that works on all the
TZ> server in the buffer.  I preserved the old (buggy I think) behavior with
TZ> the `some' parameter.  Can I commit this change?  It works for me.

> I had to revise the function, apparently I need both lists.

> (defun gnus-server-close-all-servers ()
>   "Close all servers."
>   (interactive)
>   (let ((servers (append
>                   gnus-inserted-opened-servers
>                   gnus-server-alist)))
>   (dolist (server servers)
>     (gnus-server-close-server (car server)))))

> I tested this on several Gnus setups and it seems OK.

I can agree to this change if it is really helpful to you.  But
you still need to type `C-g' for almost servers when the VPN is
disconnected, don't you?  Even so, is it really helpful to you?
I don't have a problem like yours and don't know how to reproduce
it without VPN, so don't know how to solve it so far.

In addition, isn't it unnecessary to use `let'?  I mean:

(defun gnus-server-close-all-servers ()
  "Close all servers."
  (interactive)
  (dolist (server gnus-inserted-opened-servers)
    (gnus-server-close-server (car server)))
  (dolist (server gnus-server-alist)
    (gnus-server-close-server (car server))))

or

(defun gnus-server-close-all-servers ()
  "Close all servers."
  (interactive)
  (dolist (server (append gnus-inserted-opened-servers gnus-server-alist))
    (gnus-server-close-server (car server))))

TZ> Unfortunately there were tabs in the gnus-srvr.el file (aren't we
TZ> supposed to use untabify?) so the patch comes out too long.

I cannot understand what you want to do.  gnus-srvr.el in the CVS
trunk uses tabs for the indentations that require eight or more
characters width (except for only one line).  The reason the patch
is big should be that you, some program or other untabified them.
Do you think that it should be applied to all the Gnus sources?
I don't agree.  IMO, whoever changes the Gnus sources should use
the default value for the `indent-tabs-mode' variable.

> Any response on this?  Reiner?  The function gnus-server-close-server is
> definitely better that the old version, and I believe we shouldn't have
> tabs.  I'll commit the untabified version unless I hear from someone.



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-30  6:22         ` Katsumi Yamaoka
@ 2007-07-30 15:39           ` Ted Zlatanov
  2007-07-31  2:57             ` Katsumi Yamaoka
  2007-07-31  2:58             ` untabify Lisp sources (was Re: closing all inactive server connections) Katsumi Yamaoka
  0 siblings, 2 replies; 32+ messages in thread
From: Ted Zlatanov @ 2007-07-30 15:39 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding

On Mon, 30 Jul 2007 15:22:50 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

>>>>>> Ted Zlatanov wrote:
>> On Fri, 27 Jul 2007 13:06:14 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote:

TZ> Here's a version of gnus-server-close-all-servers that works on all the
TZ> server in the buffer.  I preserved the old (buggy I think) behavior with
TZ> the `some' parameter.  Can I commit this change?  It works for me.

>> I had to revise the function, apparently I need both lists.

>> (defun gnus-server-close-all-servers ()
>> "Close all servers."
>> (interactive)
>> (let ((servers (append
>> gnus-inserted-opened-servers
>> gnus-server-alist)))
>> (dolist (server servers)
>> (gnus-server-close-server (car server)))))

>> I tested this on several Gnus setups and it seems OK.

KY> I can agree to this change if it is really helpful to you.  But
KY> you still need to type `C-g' for almost servers when the VPN is
KY> disconnected, don't you?  Even so, is it really helpful to you?
KY> I don't have a problem like yours and don't know how to reproduce
KY> it without VPN, so don't know how to solve it so far.

Yes, I need C-g, but I don't need to

1) go to each opened server
2) press C
3) press C-g

(repeat 3-4 times for each foreign server that's hung)

now I just

1) M-c
2) press C-g for whatever hangs.

Much better user experience.  Of course, avoiding the C-g would be even
better; my other question in the original e-mail was if I can tell Emacs
all these connections are truly dead so Gnus doesn't hang trying to
close them.

KY> In addition, isn't it unnecessary to use `let'?  I mean:

KY> (defun gnus-server-close-all-servers ()
KY>   "Close all servers."
KY>   (interactive)
KY>   (dolist (server gnus-inserted-opened-servers)
KY>     (gnus-server-close-server (car server)))
KY>   (dolist (server gnus-server-alist)
KY>     (gnus-server-close-server (car server))))

KY> or

KY> (defun gnus-server-close-all-servers ()
KY>   "Close all servers."
KY>   (interactive)
KY>   (dolist (server (append gnus-inserted-opened-servers gnus-server-alist))
KY>     (gnus-server-close-server (car server))))

I was debugging, so the variable was handy.  I am OK with your version.

TZ> Unfortunately there were tabs in the gnus-srvr.el file (aren't we
TZ> supposed to use untabify?) so the patch comes out too long.

KY> I cannot understand what you want to do.  gnus-srvr.el in the CVS
KY> trunk uses tabs for the indentations that require eight or more
KY> characters width (except for only one line).  The reason the patch
KY> is big should be that you, some program or other untabified them.
KY> Do you think that it should be applied to all the Gnus sources?
KY> I don't agree.  IMO, whoever changes the Gnus sources should use
KY> the default value for the `indent-tabs-mode' variable.

I was told by Lars a while ago to use untabify on Gnus commits, so I do
as a general rule.  That's what I mean by my question "aren't we
supposed to use untabify?"

I didn't know the convention had changed, that's all.  I'm happy to
stick with whatever is the current convention.  Let me know if you want
me to commit the change, or if you'll commit your version instead.

Thanks
Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-30 15:39           ` Ted Zlatanov
@ 2007-07-31  2:57             ` Katsumi Yamaoka
  2007-07-31  3:08               ` Katsumi Yamaoka
  2007-07-31  3:16               ` Ted Zlatanov
  2007-07-31  2:58             ` untabify Lisp sources (was Re: closing all inactive server connections) Katsumi Yamaoka
  1 sibling, 2 replies; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-07-31  2:57 UTC (permalink / raw)
  To: ding

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]

>>>>> Ted Zlatanov wrote:

>>> (defun gnus-server-close-all-servers ()
>>> "Close all servers."

[...]

KY> I can agree to this change if it is really helpful to you.  But
KY> you still need to type `C-g' for almost servers when the VPN is
KY> disconnected, don't you?  Even so, is it really helpful to you?
KY> I don't have a problem like yours and don't know how to reproduce
KY> it without VPN, so don't know how to solve it so far.

> Yes, I need C-g, but I don't need to

> 1) go to each opened server
> 2) press C
> 3) press C-g

> (repeat 3-4 times for each foreign server that's hung)

> now I just

> 1) M-c
> 2) press C-g for whatever hangs.

> Much better user experience.  Of course, avoiding the C-g would be even
> better; my other question in the original e-mail was if I can tell Emacs
> all these connections are truly dead so Gnus doesn't hang trying to
> close them.

I see.  Though I've never looked into this problem throughly,
the cause is often `accept-process-output' to which the timeout is
not specified.  So, I guess `nntp-wait-for-string' is the culprit
(I have no idea for IMAP connections).  To verify it, we probably
need to remove all the `condition-case' forms and `ignore-errors'
forms from nntp.el.  But, er, it might be hard to do.  How about
deleting the processes immediately instead of quitting mannerly?
The following patch forces Gnus to delete the nntp process if
the server doesn't respond when Gnus tries to open it for sending
the QUIT command:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1034 bytes --]

--- nntp.el~	2007-07-18 12:07:39 +0000
+++ nntp.el	2007-07-31 02:54:25 +0000
@@ -978,8 +978,12 @@
       (or (nntp-find-connection nntp-server-buffer)
 	  (nntp-open-connection nntp-server-buffer)))))
 
+(defvar nntp-force-close-server nil
+  "Non-nil means force server to close if it doesn't respond immediately.")
+
 (deffoo nntp-close-server (&optional server)
-  (nntp-possibly-change-group nil server t)
+  (let ((nntp-force-close-server t))
+    (nntp-possibly-change-group nil server t))
   (let ((process (nntp-find-connection nntp-server-buffer)))
     (while process
       (when (memq (process-status process) '(open run))
@@ -1728,7 +1732,10 @@
     (while (and (setq proc (get-buffer-process buf))
 		(memq (process-status proc) '(open run))
 		(not (re-search-forward regexp nil t)))
-      (accept-process-output proc)
+      (if nntp-force-close-server
+	  (unless (accept-process-output proc 1)
+	    (delete-process proc))
+	(accept-process-output proc))
       (set-buffer buf)
       (goto-char (point-min)))))
 

[-- Attachment #3: Type: text/plain, Size: 245 bytes --]

KY> In addition, isn't it unnecessary to use `let'?  I mean:

[...]

> I was debugging, so the variable was handy.  I am OK with your version.

I see.  If you think the variable will be useful in the future
too, please leave it as is.

Regards,

^ permalink raw reply	[flat|nested] 32+ messages in thread

* untabify Lisp sources (was Re: closing all inactive server connections)
  2007-07-30 15:39           ` Ted Zlatanov
  2007-07-31  2:57             ` Katsumi Yamaoka
@ 2007-07-31  2:58             ` Katsumi Yamaoka
  2007-07-31 22:05               ` untabify Lisp sources Reiner Steib
  2007-07-31 22:57               ` Miles Bader
  1 sibling, 2 replies; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-07-31  2:58 UTC (permalink / raw)
  To: larsi; +Cc: ding

Hi Lars, I wish you to respond.

>>>>> Ted Zlatanov wrote:

TZ> Unfortunately there were tabs in the gnus-srvr.el file (aren't we
TZ> supposed to use untabify?) so the patch comes out too long.

KY> I cannot understand what you want to do.  gnus-srvr.el in the CVS
KY> trunk uses tabs for the indentations that require eight or more
KY> characters width (except for only one line).  The reason the patch
KY> is big should be that you, some program or other untabified them.
KY> Do you think that it should be applied to all the Gnus sources?
KY> I don't agree.  IMO, whoever changes the Gnus sources should use
KY> the default value for the `indent-tabs-mode' variable.

> I was told by Lars a while ago to use untabify on Gnus commits, so I do
> as a general rule.  That's what I mean by my question "aren't we
> supposed to use untabify?"

Oops.  I might have overlooked it in this list.  But I don't see
an advantage of untabifying the indentations.  What is the reason
(if it exists) to force all the Gnus developers to alter the default
value of `indent-tabs-mode' or to use a hook that runs when CVS
committing?

> I didn't know the convention had changed, that's all.  I'm happy to
> stick with whatever is the current convention.  Let me know if you want
> me to commit the change, or if you'll commit your version instead.

I can agree with the new convention if there is a good reason.
But even if the convention changes (or had changed?), I think
that we should separately do untabifying of the Lisp sources and
installing of changes.

Regards,



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-31  2:57             ` Katsumi Yamaoka
@ 2007-07-31  3:08               ` Katsumi Yamaoka
  2007-07-31  3:19                 ` Ted Zlatanov
  2007-07-31  3:16               ` Ted Zlatanov
  1 sibling, 1 reply; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-07-31  3:08 UTC (permalink / raw)
  To: ding

[-- Attachment #1: Type: text/plain, Size: 230 bytes --]

>>>>> Katsumi Yamaoka wrote:

> The following patch forces Gnus to delete the nntp process if
> the server doesn't respond when Gnus tries to open it for sending
> the QUIT command:

Or this might be sufficient for that purpose:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 426 bytes --]

--- nntp.el~	2007-07-18 12:07:39 +0000
+++ nntp.el	2007-07-31 03:04:52 +0000
@@ -979,7 +979,7 @@
 	  (nntp-open-connection nntp-server-buffer)))))
 
 (deffoo nntp-close-server (&optional server)
-  (nntp-possibly-change-group nil server t)
+  ;;(nntp-possibly-change-group nil server t)
   (let ((process (nntp-find-connection nntp-server-buffer)))
     (while process
       (when (memq (process-status process) '(open run))

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-31  2:57             ` Katsumi Yamaoka
  2007-07-31  3:08               ` Katsumi Yamaoka
@ 2007-07-31  3:16               ` Ted Zlatanov
  2007-07-31  3:19                 ` Katsumi Yamaoka
  1 sibling, 1 reply; 32+ messages in thread
From: Ted Zlatanov @ 2007-07-31  3:16 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding

On Tue, 31 Jul 2007 11:57:56 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

>> I was debugging, so the variable was handy.  I am OK with your version.

KY> I see.  If you think the variable will be useful in the future
KY> too, please leave it as is.

Let's go with your more succinct version.  Please install it.

Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-31  3:08               ` Katsumi Yamaoka
@ 2007-07-31  3:19                 ` Ted Zlatanov
  2007-07-31  8:52                   ` Katsumi Yamaoka
  0 siblings, 1 reply; 32+ messages in thread
From: Ted Zlatanov @ 2007-07-31  3:19 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding

On Tue, 31 Jul 2007 12:08:23 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

>>>>>> Katsumi Yamaoka wrote:
>> The following patch forces Gnus to delete the nntp process if
>> the server doesn't respond when Gnus tries to open it for sending
>> the QUIT command:

KY> Or this might be sufficient for that purpose:
KY> --- nntp.el~	2007-07-18 12:07:39 +0000
KY> +++ nntp.el	2007-07-31 03:04:52 +0000
KY> @@ -979,7 +979,7 @@
KY>  	  (nntp-open-connection nntp-server-buffer)))))
 
KY>  (deffoo nntp-close-server (&optional server)
KY> -  (nntp-possibly-change-group nil server t)
KY> +  ;;(nntp-possibly-change-group nil server t)
KY>    (let ((process (nntp-find-connection nntp-server-buffer)))
KY>      (while process
KY>        (when (memq (process-status process) '(open run))

I tried it and the IMAP server still hangs.  Maybe the fix is in
nnimap.el?  I haven't looked deeper into this issue but I'll be glad to
debug things on my side.

Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-31  3:16               ` Ted Zlatanov
@ 2007-07-31  3:19                 ` Katsumi Yamaoka
  0 siblings, 0 replies; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-07-31  3:19 UTC (permalink / raw)
  To: ding

>>>>> Ted Zlatanov wrote:

> Let's go with your more succinct version.  Please install it.

Ok.  I will do it later (after the lunch ;-).



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-31  3:19                 ` Ted Zlatanov
@ 2007-07-31  8:52                   ` Katsumi Yamaoka
  2007-08-02 19:51                     ` Ted Zlatanov
                                       ` (2 more replies)
  0 siblings, 3 replies; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-07-31  8:52 UTC (permalink / raw)
  To: ding

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

>>>>> Ted Zlatanov wrote:

KY> --- nntp.el~	2007-07-18 12:07:39 +0000
KY> +++ nntp.el	2007-07-31 03:04:52 +0000

> I tried it and the IMAP server still hangs.  Maybe the fix is in
> nnimap.el?  I haven't looked deeper into this issue but I'll be glad to
> debug things on my side.

Is the patch effective for the hanged nntp connections?

Well, I tried looking into the IMAP code although I've never
used nnimap.  And I found the functions that communicate with
the server all have the following form:


[-- Attachment #2: Type: application/emacs-lisp, Size: 166 bytes --]

[-- Attachment #3: Type: text/plain, Size: 528 bytes --]


This can be an infinite loop if the process-status keeps `open'
or `run' even though the connection has actually died.  In
particular, the `imap-wait-for-tag' function can be the cause of
the hanging since it sends the LOGOUT command to the dead server
and waits for the response.  So, I tried modifying it so as to
quit in a certain time.  The patch to imap.el is below.  Anyway,
it needs to be reviewed by someone who is skilled in IMAP.  The
default value of `imap-timeout-seconds' might be too small for
slow connections.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Type: text/x-patch, Size: 3163 bytes --]

--- imap.el~	2007-01-24 07:15:37 +0000
+++ imap.el	2007-07-31 08:50:30 +0000
@@ -1182,14 +1182,25 @@
 			 imap-server auth)))))
 	imap-state))))
 
+(defvar imap-timeout-seconds 1
+  "*Number of seconds in which `imap-close' gives up working.")
+
+(defvar imap-timeout nil
+  "Flag that indicates process should die immediately.")
+
 (defun imap-close (&optional buffer)
   "Close connection to server in BUFFER.
 If BUFFER is nil, the current buffer is used."
   (with-current-buffer (or buffer (current-buffer))
     (when (imap-opened)
-      (condition-case nil
-	  (imap-send-command-wait "LOGOUT")
-	(quit nil)))
+      (let ((timer (run-at-time imap-timeout-seconds nil
+				#'set 'imap-timeout t)))
+	(unwind-protect
+	    (condition-case nil
+		(imap-send-command-wait "LOGOUT")
+	      (quit nil)))
+	(cancel-timer timer)
+	(setq imap-timeout nil)))
     (when (and imap-process
 	       (memq (process-status imap-process) '(open run)))
       (delete-process imap-process))
@@ -1882,30 +1893,35 @@
       (while (and (null imap-continuation)
 		  (memq (process-status imap-process) '(open run))
 		  (< imap-reached-tag tag))
-	(let ((len (/ (point-max) 1024))
-	      message-log-max)
-	  (unless (< len 10)
-	    (setq imap-have-messaged t)
-	    (message "imap read: %dk" len))
-	  (accept-process-output imap-process
-				 (truncate imap-read-timeout)
-				 (truncate (* (- imap-read-timeout
-						 (truncate imap-read-timeout))
-					      1000)))))
-      ;; A process can die _before_ we have processed everything it
-      ;; has to say.  Moreover, this can happen in between the call to
-      ;; accept-process-output and the call to process-status in an
-      ;; iteration of the loop above.
-      (when (and (null imap-continuation)
-		 (< imap-reached-tag tag))
-	(accept-process-output imap-process 0 0))
-      (when imap-have-messaged
-	(message ""))
-      (and (memq (process-status imap-process) '(open run))
-	   (or (assq tag imap-failed-tags)
-	       (if imap-continuation
-		   'INCOMPLETE
-		 'OK))))))
+	(if imap-timeout
+	    (progn
+	      (setq imap-timeout nil)
+	      (delete-process imap-process))
+	  (let ((len (/ (point-max) 1024))
+		message-log-max)
+	    (unless (< len 10)
+	      (setq imap-have-messaged t)
+	      (message "imap read: %dk" len))
+	    (accept-process-output imap-process
+				   (truncate imap-read-timeout)
+				   (truncate (* (- imap-read-timeout
+						   (truncate imap-read-timeout))
+						1000))))))
+      (when (memq (process-status imap-process) '(open run))
+	;; A process can die _before_ we have processed everything it
+	;; has to say.  Moreover, this can happen in between the call to
+	;; accept-process-output and the call to process-status in an
+	;; iteration of the loop above.
+	(when (and (null imap-continuation)
+		   (< imap-reached-tag tag))
+	  (accept-process-output imap-process 0 0))
+	(when imap-have-messaged
+	  (message ""))
+	(and (memq (process-status imap-process) '(open run))
+	     (or (assq tag imap-failed-tags)
+		 (if imap-continuation
+		     'INCOMPLETE
+		   'OK)))))))
 
 (defun imap-sentinel (process string)
   (delete-process process))

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: untabify Lisp sources
  2007-07-31  2:58             ` untabify Lisp sources (was Re: closing all inactive server connections) Katsumi Yamaoka
@ 2007-07-31 22:05               ` Reiner Steib
  2007-08-01  2:44                 ` Ted Zlatanov
  2007-07-31 22:57               ` Miles Bader
  1 sibling, 1 reply; 32+ messages in thread
From: Reiner Steib @ 2007-07-31 22:05 UTC (permalink / raw)
  To: ding

On Tue, Jul 31 2007, Katsumi Yamaoka wrote:

>>>>>> Ted Zlatanov wrote:
>> I was told by Lars a while ago to use untabify on Gnus commits, so I do
>> as a general rule.  That's what I mean by my question "aren't we
>> supposed to use untabify?"
>
> Oops.  I might have overlooked it in this list.  But I don't see
> an advantage of untabifying the indentations.

A quick search only shows messages about untabifying of texi files,
AFAICS.

<http://search.gmane.org/?query=untabify&group=emacs.gnus.general&author=Lars&sort=date>

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/




^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: untabify Lisp sources
  2007-07-31  2:58             ` untabify Lisp sources (was Re: closing all inactive server connections) Katsumi Yamaoka
  2007-07-31 22:05               ` untabify Lisp sources Reiner Steib
@ 2007-07-31 22:57               ` Miles Bader
  2007-08-01  2:46                 ` Ted Zlatanov
  1 sibling, 1 reply; 32+ messages in thread
From: Miles Bader @ 2007-07-31 22:57 UTC (permalink / raw)
  To: ding

Katsumi Yamaoka <yamaoka@jpl.org> writes:
> I can agree with the new convention if there is a good reason.
> But even if the convention changes (or had changed?), I think
> that we should separately do untabifying of the Lisp sources and
> installing of changes.

Well, _if_ you're going to do untabification, I guess it's best to keep
it separate, but ... I think in general it's a very bad idea to make
widespread source changes for purely cosmetic reasons (and in this case,
it's not even really "cosmetic" -- whitespace is invisible!); it's a big
pain for merging.

Please, let's just stick with a recommended setting of
`indent-tabs-mode', and not do any untabification.  The benefits of
untabification seem very small compared to the pain (to be honest, what
_are_ the benefits, exactly???).

-Miles

-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]




^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: untabify Lisp sources
  2007-07-31 22:05               ` untabify Lisp sources Reiner Steib
@ 2007-08-01  2:44                 ` Ted Zlatanov
  0 siblings, 0 replies; 32+ messages in thread
From: Ted Zlatanov @ 2007-08-01  2:44 UTC (permalink / raw)
  To: ding; +Cc: Lars Magne Ingebrigtsen

On Wed, 01 Aug 2007 00:05:02 +0200 Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

RS> On Tue, Jul 31 2007, Katsumi Yamaoka wrote:
>>>>>>> Ted Zlatanov wrote:
>>> I was told by Lars a while ago to use untabify on Gnus commits, so I do
>>> as a general rule.  That's what I mean by my question "aren't we
>>> supposed to use untabify?"
>> 
>> Oops.  I might have overlooked it in this list.  But I don't see
>> an advantage of untabifying the indentations.

RS> A quick search only shows messages about untabifying of texi files,
RS> AFAICS.

RS> <http://search.gmane.org/?query=untabify&group=emacs.gnus.general&author=Lars&sort=date>

This is not the first time I've remembered things wrong.  Having two
kids will do that to you.  Sorry for the nuisance.

Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: untabify Lisp sources
  2007-07-31 22:57               ` Miles Bader
@ 2007-08-01  2:46                 ` Ted Zlatanov
  0 siblings, 0 replies; 32+ messages in thread
From: Ted Zlatanov @ 2007-08-01  2:46 UTC (permalink / raw)
  To: Miles Bader; +Cc: ding

On Wed, 01 Aug 2007 07:57:31 +0900 Miles Bader <miles@gnu.org> wrote: 

MB> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> I can agree with the new convention if there is a good reason.
>> But even if the convention changes (or had changed?), I think
>> that we should separately do untabifying of the Lisp sources and
>> installing of changes.

MB> Well, _if_ you're going to do untabification, I guess it's best to keep
MB> it separate, but ... I think in general it's a very bad idea to make
MB> widespread source changes for purely cosmetic reasons (and in this case,
MB> it's not even really "cosmetic" -- whitespace is invisible!); it's a big
MB> pain for merging.

MB> Please, let's just stick with a recommended setting of
MB> `indent-tabs-mode', and not do any untabification.  The benefits of
MB> untabification seem very small compared to the pain (to be honest, what
MB> _are_ the benefits, exactly???).

This was all just my stupidity.  Please ignore.

Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-31  8:52                   ` Katsumi Yamaoka
@ 2007-08-02 19:51                     ` Ted Zlatanov
  2007-08-15 11:28                     ` Simon Josefsson
  2007-08-15 18:28                     ` Reiner Steib
  2 siblings, 0 replies; 32+ messages in thread
From: Ted Zlatanov @ 2007-08-02 19:51 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding, Simon Josefsson

On Tue, 31 Jul 2007 17:52:42 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

>>>>>> Ted Zlatanov wrote:
KY> --- nntp.el~	2007-07-18 12:07:39 +0000
KY> +++ nntp.el	2007-07-31 03:04:52 +0000

>> I tried it and the IMAP server still hangs.  Maybe the fix is in
>> nnimap.el?  I haven't looked deeper into this issue but I'll be glad to
>> debug things on my side.

KY> Is the patch effective for the hanged nntp connections?

My NNTP connections are OK.

KY> Well, I tried looking into the IMAP code although I've never
KY> used nnimap.  And I found the functions that communicate with
KY> the server all have the following form:
KY>   (while (and (memq (process-status PROCESS) '(open run))
KY> 	      (wait-for-a-string-that-the-PROCESS-returns))
KY>     (accept-process-output PROCESS 1)
KY>     (sit-for 1))

KY> This can be an infinite loop if the process-status keeps `open'
KY> or `run' even though the connection has actually died.  In
KY> particular, the `imap-wait-for-tag' function can be the cause of
KY> the hanging since it sends the LOGOUT command to the dead server
KY> and waits for the response.  So, I tried modifying it so as to
KY> quit in a certain time.  The patch to imap.el is below.  Anyway,
KY> it needs to be reviewed by someone who is skilled in IMAP.  The
KY> default value of `imap-timeout-seconds' might be too small for
KY> slow connections.

I tried this and it works fine.  If Simon is around, he can take a look,
but I tested it over 6 hours of IMAP/NNTP use and had no problems.  If
anyone else can verify that it works, this would be a great addition to
Gnus.

Maybe it should be generalized, however, to an IMAP timeout per (server,
group name, command) combination (as a regex or a function), so you can
assign "LOGOUT" a longer timeout with a slower server.  This could also
be a server tuning parameter for nnimap instead of an imap.el parameter.

Thank you for the help!
Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-31  8:52                   ` Katsumi Yamaoka
  2007-08-02 19:51                     ` Ted Zlatanov
@ 2007-08-15 11:28                     ` Simon Josefsson
  2007-08-16  7:18                       ` Katsumi Yamaoka
  2007-08-16 15:32                       ` Ted Zlatanov
  2007-08-15 18:28                     ` Reiner Steib
  2 siblings, 2 replies; 32+ messages in thread
From: Simon Josefsson @ 2007-08-15 11:28 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Well, I tried looking into the IMAP code although I've never
> used nnimap.  And I found the functions that communicate with
> the server all have the following form:
>
>   (while (and (memq (process-status PROCESS) '(open run))
> 	      (wait-for-a-string-that-the-PROCESS-returns))
>     (accept-process-output PROCESS 1)
>     (sit-for 1))
>
> This can be an infinite loop if the process-status keeps `open'
> or `run' even though the connection has actually died.

Can that happen?  Wouldn't that be an emacs bug?  Shouldn't
process-status return exit or closed if a connect/process has gone away?

> In particular, the `imap-wait-for-tag' function can be the cause of
> the hanging since it sends the LOGOUT command to the dead server and
> waits for the response.  So, I tried modifying it so as to quit in a
> certain time.  The patch to imap.el is below.  Anyway, it needs to be
> reviewed by someone who is skilled in IMAP.  The default value of
> `imap-timeout-seconds' might be too small for slow connections.
>
> --- imap.el~	2007-01-24 07:15:37 +0000
> +++ imap.el	2007-07-31 08:50:30 +0000
> @@ -1182,14 +1182,25 @@
>  			 imap-server auth)))))
>  	imap-state))))
>  
> +(defvar imap-timeout-seconds 1
> +  "*Number of seconds in which `imap-close' gives up working.")

This is a bad idea even for fast servers -- some operations (such as
deleting or renaming a mailabox) can take several minutes.  Gnus
shouldn't assume the server isn't responding in this (and other) cases.

Ted Zlatanov <tzz@lifelogs.com> writes:

> Maybe it should be generalized, however, to an IMAP timeout per (server,
> group name, command) combination (as a regex or a function), so you can
> assign "LOGOUT" a longer timeout with a slower server.  This could also
> be a server tuning parameter for nnimap instead of an imap.el parameter.

Having the timeout be restricted to just LOGOUT seems to make more sense
to me.  If the server doesn't respond to a LOGOUT within a short period
of time, one might as well disconnect.

/Simon



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-07-31  8:52                   ` Katsumi Yamaoka
  2007-08-02 19:51                     ` Ted Zlatanov
  2007-08-15 11:28                     ` Simon Josefsson
@ 2007-08-15 18:28                     ` Reiner Steib
  2 siblings, 0 replies; 32+ messages in thread
From: Reiner Steib @ 2007-08-15 18:28 UTC (permalink / raw)
  To: ding

On Tue, Jul 31 2007, Katsumi Yamaoka wrote:

> +(defvar imap-timeout-seconds 1
> +  "*Number of seconds in which `imap-close' gives up working.")

Nitpick: Either the "*" should be removed or it should be a defcustom.
Shouldn't it?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/




^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-15 11:28                     ` Simon Josefsson
@ 2007-08-16  7:18                       ` Katsumi Yamaoka
  2007-08-16  7:25                         ` Katsumi Yamaoka
  2007-08-16  9:49                         ` Simon Josefsson
  2007-08-16 15:32                       ` Ted Zlatanov
  1 sibling, 2 replies; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-08-16  7:18 UTC (permalink / raw)
  To: ding

[-- Attachment #1: Type: text/plain, Size: 3046 bytes --]

>>>>> Simon Josefsson wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> (while (and (memq (process-status PROCESS) '(open run))
>>             (wait-for-a-string-that-the-PROCESS-returns))
>>   (accept-process-output PROCESS 1)
>>   (sit-for 1))
>>
>> This can be an infinite loop if the process-status keeps `open'
>> or `run' even though the connection has actually died.

> Can that happen?  Wouldn't that be an emacs bug?  Shouldn't
> process-status return exit or closed if a connect/process has gone away?

I meant that the /connection/ is the one between the frontend of
Ted Zlatanov's local network (i.e., VPN) and the IMAP server (see
http://article.gmane.org/gmane.emacs.gnus.general/64906).  In his
case, the connection between Emacs and the frontend seems to be
alive even after the connection between the frontend and the IMAP
server dies.  So, ideally, what needs to be fixed should be
the VPN program, not be Emacs or Gnus, I think, and the plan I
proposed was no more than a workaround.  But I thought it was not
necessarily a bad idea even if the problem in the VPN program can
be solved soon, because people in the VPN networks might not
necessarily be able to ask the administrators to replace the
program with the corrected one.

>> In particular, the `imap-wait-for-tag' function can be the cause of
>> the hanging since it sends the LOGOUT command to the dead server and
>> waits for the response.  So, I tried modifying it so as to quit in a
>> certain time.  The patch to imap.el is below.  Anyway, it needs to be
>> reviewed by someone who is skilled in IMAP.  The default value of
>> `imap-timeout-seconds' might be too small for slow connections.

[...]

> This is a bad idea even for fast servers -- some operations (such as
> deleting or renaming a mailabox) can take several minutes.  Gnus
> shouldn't assume the server isn't responding in this (and other) cases.

Ok, but I didn't know it.

> Ted Zlatanov <tzz@lifelogs.com> writes:

>> Maybe it should be generalized, however, to an IMAP timeout per (server,
>> group name, command) combination (as a regex or a function), so you can
>> assign "LOGOUT" a longer timeout with a slower server.  This could also
>> be a server tuning parameter for nnimap instead of an imap.el parameter.

> Having the timeout be restricted to just LOGOUT seems to make more sense
> to me.  If the server doesn't respond to a LOGOUT within a short period
> of time, one might as well disconnect.

I see.  It looks sufficient for Ted.

>>>>> Reiner Steib wrote:
> On Tue, Jul 31 2007, Katsumi Yamaoka wrote:

>> +(defvar imap-timeout-seconds 1
>> +  "*Number of seconds in which `imap-close' gives up working.")

> Nitpick: Either the "*" should be removed or it should be a defcustom.
> Shouldn't it?

I agree to making it use defcustom.  In addition, a good default
will probably be the value meaning there's no timeout.  Anyway I
use neither nnimap nor VPN at all, and I can neither reproduce
the problem nor verify this workaround.  So, I wish Simon and Ted
to take on this.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch for imap.el --]
[-- Type: text/x-patch, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-16  7:18                       ` Katsumi Yamaoka
@ 2007-08-16  7:25                         ` Katsumi Yamaoka
  2007-08-16  9:49                         ` Simon Josefsson
  1 sibling, 0 replies; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-08-16  7:25 UTC (permalink / raw)
  To: ding

[-- Attachment #1: Type: text/plain, Size: 124 bytes --]

>>>>> Katsumi Yamaoka wrote:

> So, I wish Simon and Ted to take on this.

Sorry, I forgot to attach a patch.  Here it is:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch for imap.el --]
[-- Type: text/x-patch, Size: 2212 bytes --]

--- imap.el~	2007-01-24 07:15:37 +0000
+++ imap.el	2007-08-16 07:10:13 +0000
@@ -273,6 +273,14 @@
   :group 'imap
   :type 'boolean)
 
+(defcustom imap-logout-timeout nil
+  "Close server immediately if it can't logout in this number of seconds.
+If it is nil, never close server until logout completes."
+  :version "23.0" ;; No Gnus.
+  :group 'imap
+  :type '(choice (const :tag "No timeout" nil)
+		 (number :value 1.0)))
+
 ;; Various variables.
 
 (defvar imap-fetch-data-hook nil
@@ -554,7 +562,7 @@
 				(not (string-match "failed" response))))
 		(setq done process)
 	      (if (memq (process-status process) '(open run))
-		  (imap-send-command "LOGOUT"))
+		  (imap-logout))
 	      (delete-process process)
 	      nil)))))
     done))
@@ -629,7 +637,7 @@
 				(not (string-match "failed" response))))
 		(setq done process)
 	      (if (memq (process-status process) '(open run))
-		  (imap-send-command "LOGOUT"))
+		  (imap-logout))
 	      (delete-process process)
 	      nil)))))
     done))
@@ -1188,7 +1196,7 @@
   (with-current-buffer (or buffer (current-buffer))
     (when (imap-opened)
       (condition-case nil
-	  (imap-send-command-wait "LOGOUT")
+	  (imap-logout-wait)
 	(quit nil)))
     (when (and imap-process
 	       (memq (process-status imap-process) '(open run)))
@@ -1243,6 +1251,28 @@
 (defun imap-send-command-wait (command &optional buffer)
   (imap-wait-for-tag (imap-send-command command buffer) buffer))
 
+(defun imap-logout (&optional buffer)
+  (if imap-logout-timeout
+      (eval `(with-timeout (imap-logout-timeout
+			    (condition-case nil
+				(with-current-buffer ,(or buffer
+							  (current-buffer))
+				  (delete-process imap-process))
+			      (error)))
+	       (imap-send-command "LOGOUT" buffer)))
+    (imap-send-command "LOGOUT" buffer)))
+
+(defun imap-logout-wait (&optional buffer)
+  (if imap-logout-timeout
+      (eval `(with-timeout (imap-logout-timeout
+			    (condition-case nil
+				(with-current-buffer ,(or buffer
+							  (current-buffer))
+				  (delete-process imap-process))
+			      (error)))
+	       (imap-send-command-wait "LOGOUT" buffer)))
+    (imap-send-command-wait "LOGOUT" buffer)))
+
 \f
 ;; Mailbox functions:
 

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-16  7:18                       ` Katsumi Yamaoka
  2007-08-16  7:25                         ` Katsumi Yamaoka
@ 2007-08-16  9:49                         ` Simon Josefsson
  2007-08-16 15:35                           ` Ted Zlatanov
  1 sibling, 1 reply; 32+ messages in thread
From: Simon Josefsson @ 2007-08-16  9:49 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>>>>> Simon Josefsson wrote:
>> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>
>>> (while (and (memq (process-status PROCESS) '(open run))
>>>             (wait-for-a-string-that-the-PROCESS-returns))
>>>   (accept-process-output PROCESS 1)
>>>   (sit-for 1))
>>>
>>> This can be an infinite loop if the process-status keeps `open'
>>> or `run' even though the connection has actually died.
>
>> Can that happen?  Wouldn't that be an emacs bug?  Shouldn't
>> process-status return exit or closed if a connect/process has gone away?
>
> I meant that the /connection/ is the one between the frontend of
> Ted Zlatanov's local network (i.e., VPN) and the IMAP server (see
> http://article.gmane.org/gmane.emacs.gnus.general/64906).  In his
> case, the connection between Emacs and the frontend seems to be
> alive even after the connection between the frontend and the IMAP
> server dies.  So, ideally, what needs to be fixed should be
> the VPN program, not be Emacs or Gnus, I think, 

I agree.  The VPN should close the internal connection if the external
one is closed.

> and the plan I proposed was no more than a workaround.

Right.

> --- imap.el~	2007-01-24 07:15:37 +0000
> +++ imap.el	2007-08-16 07:10:13 +0000
> @@ -273,6 +273,14 @@
>    :group 'imap
>    :type 'boolean)
>  
> +(defcustom imap-logout-timeout nil
> +  "Close server immediately if it can't logout in this number of seconds.
> +If it is nil, never close server until logout completes."
> +  :version "23.0" ;; No Gnus.
> +  :group 'imap
> +  :type '(choice (const :tag "No timeout" nil)
> +		 (number :value 1.0)))
> +
>  ;; Various variables.
>  
>  (defvar imap-fetch-data-hook nil
> @@ -554,7 +562,7 @@
>  				(not (string-match "failed" response))))
>  		(setq done process)
>  	      (if (memq (process-status process) '(open run))
> -		  (imap-send-command "LOGOUT"))
> +		  (imap-logout))
>  	      (delete-process process)
>  	      nil)))))
>      done))
> @@ -629,7 +637,7 @@
>  				(not (string-match "failed" response))))
>  		(setq done process)
>  	      (if (memq (process-status process) '(open run))
> -		  (imap-send-command "LOGOUT"))
> +		  (imap-logout))
>  	      (delete-process process)
>  	      nil)))))
>      done))
> @@ -1188,7 +1196,7 @@
>    (with-current-buffer (or buffer (current-buffer))
>      (when (imap-opened)
>        (condition-case nil
> -	  (imap-send-command-wait "LOGOUT")
> +	  (imap-logout-wait)
>  	(quit nil)))
>      (when (and imap-process
>  	       (memq (process-status imap-process) '(open run)))
> @@ -1243,6 +1251,28 @@
>  (defun imap-send-command-wait (command &optional buffer)
>    (imap-wait-for-tag (imap-send-command command buffer) buffer))
>  
> +(defun imap-logout (&optional buffer)
> +  (if imap-logout-timeout
> +      (eval `(with-timeout (imap-logout-timeout
> +			    (condition-case nil
> +				(with-current-buffer ,(or buffer
> +							  (current-buffer))
> +				  (delete-process imap-process))
> +			      (error)))
> +	       (imap-send-command "LOGOUT" buffer)))
> +    (imap-send-command "LOGOUT" buffer)))
> +
> +(defun imap-logout-wait (&optional buffer)
> +  (if imap-logout-timeout
> +      (eval `(with-timeout (imap-logout-timeout
> +			    (condition-case nil
> +				(with-current-buffer ,(or buffer
> +							  (current-buffer))
> +				  (delete-process imap-process))
> +			      (error)))
> +	       (imap-send-command-wait "LOGOUT" buffer)))
> +    (imap-send-command-wait "LOGOUT" buffer)))
> +
>  \f
>  ;; Mailbox functions:
>  

This looks fine to me, although I haven't tested it.

/Simon



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-15 11:28                     ` Simon Josefsson
  2007-08-16  7:18                       ` Katsumi Yamaoka
@ 2007-08-16 15:32                       ` Ted Zlatanov
  2007-08-16 15:56                         ` Ted Zlatanov
  1 sibling, 1 reply; 32+ messages in thread
From: Ted Zlatanov @ 2007-08-16 15:32 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding

On Wed, 15 Aug 2007 13:28:44 +0200 Simon Josefsson <simon@josefsson.org> wrote: 

SJ> Ted Zlatanov <tzz@lifelogs.com> writes:

>> Maybe it should be generalized, however, to an IMAP timeout per (server,
>> group name, command) combination (as a regex or a function), so you can
>> assign "LOGOUT" a longer timeout with a slower server.  This could also
>> be a server tuning parameter for nnimap instead of an imap.el parameter.

SJ> Having the timeout be restricted to just LOGOUT seems to make more sense
SJ> to me.  If the server doesn't respond to a LOGOUT within a short period
SJ> of time, one might as well disconnect.

That's fine.  So it should be imap-logout-timeouts, an alist of 
(server-regex seconds) cells.  Agreed?

Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-16  9:49                         ` Simon Josefsson
@ 2007-08-16 15:35                           ` Ted Zlatanov
  0 siblings, 0 replies; 32+ messages in thread
From: Ted Zlatanov @ 2007-08-16 15:35 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding

On Thu, 16 Aug 2007 11:49:22 +0200 Simon Josefsson <simon@josefsson.org> wrote: 

SJ> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> I meant that the /connection/ is the one between the frontend of
>> Ted Zlatanov's local network (i.e., VPN) and the IMAP server (see
>> http://article.gmane.org/gmane.emacs.gnus.general/64906).  In his
>> case, the connection between Emacs and the frontend seems to be
>> alive even after the connection between the frontend and the IMAP
>> server dies.  So, ideally, what needs to be fixed should be
>> the VPN program, not be Emacs or Gnus, I think, 

SJ> I agree.  The VPN should close the internal connection if the external
SJ> one is closed.

I already mentioned this to the VPN administrators.  It doesn't change
the fact that Gnus hangs when an IMAP LOGOUT command times out, which
could happen in other instances, and is the real problem.

Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-16 15:32                       ` Ted Zlatanov
@ 2007-08-16 15:56                         ` Ted Zlatanov
  2007-08-16 23:19                           ` Katsumi Yamaoka
  0 siblings, 1 reply; 32+ messages in thread
From: Ted Zlatanov @ 2007-08-16 15:56 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding

On Thu, 16 Aug 2007 10:32:06 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Wed, 15 Aug 2007 13:28:44 +0200 Simon Josefsson <simon@josefsson.org> wrote: 
SJ> Ted Zlatanov <tzz@lifelogs.com> writes:

>>> Maybe it should be generalized, however, to an IMAP timeout per (server,
>>> group name, command) combination (as a regex or a function), so you can
>>> assign "LOGOUT" a longer timeout with a slower server.  This could also
>>> be a server tuning parameter for nnimap instead of an imap.el parameter.

SJ> Having the timeout be restricted to just LOGOUT seems to make more sense
SJ> to me.  If the server doesn't respond to a LOGOUT within a short period
SJ> of time, one might as well disconnect.

TZ> That's fine.  So it should be imap-logout-timeouts, an alist of 
TZ> (server-regex seconds) cells.  Agreed?

Here's the defcustom I was thinking of:

(defcustom imap-logout-timeout nil
  "Close server immediately if it can't logout in this number of seconds.
If it is nil, never close server until logout completes."
  :version "23.0" ;; No Gnus.
  :group 'imap
  :type '(choice (const :tag "No timeout" nil)
                 (number :value 1.0)
                 (repeat :tag "Set individual timeouts per server"
                         (list :tag "Server/timeout combination"
                               (regexp :tag "Server name regular expression")
                               (choice
                                (number :value 1.0 :tag "Logout timeout for this server")
                                (const :tag "No timeout" nil))))))

Then imap-logout has to be modified too, but I want to make sure this is OK.

Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-16 15:56                         ` Ted Zlatanov
@ 2007-08-16 23:19                           ` Katsumi Yamaoka
  2007-08-16 23:25                             ` Ted Zlatanov
  0 siblings, 1 reply; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-08-16 23:19 UTC (permalink / raw)
  To: ding

>>>>> Ted Zlatanov wrote:

TZ> That's fine.  So it should be imap-logout-timeouts, an alist of
TZ> (server-regex seconds) cells.  Agreed?

Isn't it much better that it is a server variable?  I mean, we leave
`imap-logout-timeout' as is, but bind it by `nnimap-logout-timeout'.
Because this is a server variable, you can specify it per server in
its select-method.  We can probably make it come true in nnimap.el
as follows:

#v+
(defvoo nnimap-logout-timeout nil
  "Close server immediately if it can't logout in this number of seconds.
If it is nil, never close server until logout completes.")

[...]

  (let ((imap-logout-timeout nnimap-logout-timeout))
    (imap-open ...))

  (let ((imap-logout-timeout nnimap-logout-timeout))
    (imap-close ...))
#v-

Note that `imap-open' will run `imap-logout' when opening a server
fails.

Another similar way is to pass the value of `nnimap-logout-timeout'
to `imap-open' and `imap-close' by way of the new optional argument
`logout-timeout' as follows:

#v+
;; imap.el
(defun imap-open (server &optional port stream auth buffer logout-timeout)...
(defun imap-close (&optional buffer logout-timeout)...

;; nnimap.el
  (imap-open ... nnimap-logout-timeout)
  (imap-close ... nnimap-logout-timeout)
#v-



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-16 23:19                           ` Katsumi Yamaoka
@ 2007-08-16 23:25                             ` Ted Zlatanov
  2007-08-16 23:47                               ` Katsumi Yamaoka
  0 siblings, 1 reply; 32+ messages in thread
From: Ted Zlatanov @ 2007-08-16 23:25 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding

On Fri, 17 Aug 2007 08:19:26 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

>>>>>> Ted Zlatanov wrote:
TZ> That's fine.  So it should be imap-logout-timeouts, an alist of
TZ> (server-regex seconds) cells.  Agreed?

KY> Isn't it much better that it is a server variable?  I mean, we leave
KY> `imap-logout-timeout' as is, but bind it by `nnimap-logout-timeout'.
KY> Because this is a server variable, you can specify it per server in
KY> its select-method.  

Agreed, this is a much better solution than what I proposed, and it lets
the user override imap-logout-timeout with nnimap-logout-timeout as
needed.  I think lexical scope with (let) is better than a new optional
parameter.

Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-16 23:25                             ` Ted Zlatanov
@ 2007-08-16 23:47                               ` Katsumi Yamaoka
  2007-08-17 11:09                                 ` Katsumi Yamaoka
  0 siblings, 1 reply; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-08-16 23:47 UTC (permalink / raw)
  To: ding

>>>>> Ted Zlatanov wrote:
> On Fri, 17 Aug 2007 08:19:26 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote:

TZ> That's fine.  So it should be imap-logout-timeouts, an alist of
TZ> (server-regex seconds) cells.  Agreed?

KY> Isn't it much better that it is a server variable?  I mean, we leave
KY> `imap-logout-timeout' as is, but bind it by `nnimap-logout-timeout'.
KY> Because this is a server variable, you can specify it per server in
KY> its select-method.

> Agreed, this is a much better solution than what I proposed, and it lets
> the user override imap-logout-timeout with nnimap-logout-timeout as
> needed.  I think lexical scope with (let) is better than a new optional
> parameter.

Ok. I will do it in this way within today (in Japan :-).



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-16 23:47                               ` Katsumi Yamaoka
@ 2007-08-17 11:09                                 ` Katsumi Yamaoka
  2007-09-10 14:52                                   ` Ted Zlatanov
  0 siblings, 1 reply; 32+ messages in thread
From: Katsumi Yamaoka @ 2007-08-17 11:09 UTC (permalink / raw)
  To: ding

>>>>> Katsumi Yamaoka wrote:
>>>>>> Ted Zlatanov wrote:

>> Agreed, this is a much better solution than what I proposed, and it lets
>> the user override imap-logout-timeout with nnimap-logout-timeout as
>> needed.  I think lexical scope with (let) is better than a new optional
>> parameter.

> Ok. I will do it in this way within today (in Japan :-).

I've installed changes and an Info document in the trunk.  Now
`imap-logout-timeout' is simply a variable, not a user option.
All were done by me who is really not a IMAP user.  So, please
don't hesitate to fix any odd things.

Regards,



^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: closing all inactive server connections
  2007-08-17 11:09                                 ` Katsumi Yamaoka
@ 2007-09-10 14:52                                   ` Ted Zlatanov
  0 siblings, 0 replies; 32+ messages in thread
From: Ted Zlatanov @ 2007-09-10 14:52 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding

On Fri, 17 Aug 2007 20:09:26 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

>>>>>> Katsumi Yamaoka wrote:
>>>>>>> Ted Zlatanov wrote:

>>> Agreed, this is a much better solution than what I proposed, and it lets
>>> the user override imap-logout-timeout with nnimap-logout-timeout as
>>> needed.  I think lexical scope with (let) is better than a new optional
>>> parameter.

>> Ok. I will do it in this way within today (in Japan :-).

KY> I've installed changes and an Info document in the trunk.  Now
KY> `imap-logout-timeout' is simply a variable, not a user option.
KY> All were done by me who is really not a IMAP user.  So, please
KY> don't hesitate to fix any odd things.

After testing this functionality for a while, I can report it has worked
fine for me.

Ted



^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2007-09-10 14:52 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-07-07 15:59 closing all inactive server connections Ted Zlatanov
2007-07-10 19:54 ` Ted Zlatanov
2007-07-19 13:46   ` Ted Zlatanov
2007-07-27 17:06     ` Ted Zlatanov
2007-07-28  0:18       ` Ted Zlatanov
2007-07-30  6:22         ` Katsumi Yamaoka
2007-07-30 15:39           ` Ted Zlatanov
2007-07-31  2:57             ` Katsumi Yamaoka
2007-07-31  3:08               ` Katsumi Yamaoka
2007-07-31  3:19                 ` Ted Zlatanov
2007-07-31  8:52                   ` Katsumi Yamaoka
2007-08-02 19:51                     ` Ted Zlatanov
2007-08-15 11:28                     ` Simon Josefsson
2007-08-16  7:18                       ` Katsumi Yamaoka
2007-08-16  7:25                         ` Katsumi Yamaoka
2007-08-16  9:49                         ` Simon Josefsson
2007-08-16 15:35                           ` Ted Zlatanov
2007-08-16 15:32                       ` Ted Zlatanov
2007-08-16 15:56                         ` Ted Zlatanov
2007-08-16 23:19                           ` Katsumi Yamaoka
2007-08-16 23:25                             ` Ted Zlatanov
2007-08-16 23:47                               ` Katsumi Yamaoka
2007-08-17 11:09                                 ` Katsumi Yamaoka
2007-09-10 14:52                                   ` Ted Zlatanov
2007-08-15 18:28                     ` Reiner Steib
2007-07-31  3:16               ` Ted Zlatanov
2007-07-31  3:19                 ` Katsumi Yamaoka
2007-07-31  2:58             ` untabify Lisp sources (was Re: closing all inactive server connections) Katsumi Yamaoka
2007-07-31 22:05               ` untabify Lisp sources Reiner Steib
2007-08-01  2:44                 ` Ted Zlatanov
2007-07-31 22:57               ` Miles Bader
2007-08-01  2:46                 ` Ted Zlatanov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).