From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Refreshing Info nodes Date: Mon, 13 Sep 2010 12:11:55 +0200 Message-ID: References: <87631mkeic.fsf@gmail.com> <87hbl54oi0.fsf@mail.jurta.org> <87r5k9clxh.fsf@mail.jurta.org> <87hbl4kn77.fsf@mail.jurta.org> <87bpbbkgt1.fsf@gmail.com> <87vd6upj5m.fsf@gmail.com> <83d3t2lavg.fsf@gnu.org> <8739ty9ybi.fsf@gmail.com> <87r5gy5svm.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1284372736 8037 80.91.229.12 (13 Sep 2010 10:12:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Sep 2010 10:12:16 +0000 (UTC) Cc: juri@jurta.org, Eli Zaretskii , emacs-devel@gnu.org, joakim@verona.se, deniz.a.m.dogan@gmail.com To: Wojciech Meyer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 13 12:12:13 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ov61D-000128-TN for ged-emacs-devel@m.gmane.org; Mon, 13 Sep 2010 12:12:12 +0200 Original-Received: from localhost ([127.0.0.1]:34628 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ov61D-0005SL-8I for ged-emacs-devel@m.gmane.org; Mon, 13 Sep 2010 06:12:11 -0400 Original-Received: from [140.186.70.92] (port=36564 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ov615-0005S6-7T for emacs-devel@gnu.org; Mon, 13 Sep 2010 06:12:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ov613-0001pK-VF for emacs-devel@gnu.org; Mon, 13 Sep 2010 06:12:03 -0400 Original-Received: from impaqm1.telefonica.net ([213.4.138.1]:10281) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ov613-0001ou-Hj for emacs-devel@gnu.org; Mon, 13 Sep 2010 06:12:01 -0400 Original-Received: from IMPmailhost2.adm.correo ([10.20.102.39]) by IMPaqm1.telefonica.net with bizsmtp id 672f1f00s0r0BT601AByYl; Mon, 13 Sep 2010 12:11:58 +0200 Original-Received: from ceviche.home ([83.61.39.212]) by IMPmailhost2.adm.correo with BIZ IMP id 6ABw1f0014aeRwb1iABwpz; Mon, 13 Sep 2010 12:11:58 +0200 X-Brightmail-Tracker: AAAAAA== X-TE-authinfo: authemail="monnier$movistar.es" |auth_email="monnier@movistar.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" Original-Received: by ceviche.home (Postfix, from userid 20848) id 93CE86637B; Mon, 13 Sep 2010 12:11:55 +0200 (CEST) In-Reply-To: <87r5gy5svm.fsf@gmail.com> (Wojciech Meyer's message of "Mon, 13 Sep 2010 02:34:05 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:130036 Archived-At: >>> + ;; This is not interactive because you shouldn't be turning this >>> + ;; mode on and off. You can corrupt things that way. >>> + ;; >>> + ;; Now it's derived mode, so therefore it is interactive. >> >> These two pieces are contradictory, please clarify. BTW, we should >> change archive-mode to use buffer-swap-text like we did for tar-mode, >> which should address this risk of corruption. > Done. I am investigating possibility of using swap-buffer with > archive-mode. Great, but note that it's a separate issue to the one of using special-mode. > BTW: Maybe we should think about merging (at least reusing bits & pieces > and making user interface more consistent) tar-mode <-> archive-mode? Yes, bringing them closer would be good, indeed. > - changing `image-mode' to something else and wrapping the rest into > `defun' (ad-hoc solution, which I like at least) This solution you like least is the right one: image-mode should really be a command that sets the major-mode to image-mode, not a command that tries it and does something else if it can't be done. I.e. we need a separate command to do the "check if image-mode can be used, and call image-mode if possible". > Ideally in case of saving previous mode we should have a stack for this > (even better, stack with functions that restore previous state, but this > might be an overkill). The user might want to switch in a circular rather than stack fashion. Since we don't know how best to solve this general case, we stick to the only really use case we know, where the user switches between two modes (the doc-view/image-mode and the "see raw data" mode (can be fundamental-mode, ps-mode, c-mode, ...)). > (define-derived-mode my-major-mode special-mode > :keymap > (("n" . 'my-next-page) > ("C-s" . 'my-search)) > ...) We could, but a separate variable isn't that much hassle. > (define-derived-mode my-major-mode special-mode > :keymap 'my-major-mode-map > ...) This would encourage the use of non-standard naming, so I'd rather not go down that road. > As you notice I also think that defining key-maps should be easier. > Generally maybe we should do what's been done with `easy-menu' for maps. As you may have noticed in easy-mmode-define-keymap, I've toyed with this idea in the past. Maybe a `defkeymap' macro would be good, indeed, but it's not that important, I think. > +(define-derived-mode archive-mode special-mode "Archive mode" [...] > ;; Archive mode is suitable only for specially formatted data. > (put 'archive-mode 'mode-class 'special) The above line is made redundant by deriving from special-mode. > +(define-derived-mode bookmark-edit-annotation-mode nil "Edit Bookmark Annotation" [...] > (run-mode-hooks 'text-mode-hook)) This run-mode-hooks is a good hint that the mode should actually derive from text-mode-hook. > (put 'occur-mode 'mode-class 'special) > -(defun occur-mode () > +(define-derived-mode occur-mode special-mode "Occur" Here also, the `put' is now redundant. Stefan