* 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
* 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 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: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: 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-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-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-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 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
* 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-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: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
* 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: 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 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 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: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
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).