From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] emacs-25 b6d6304: Comment on last change to define-derived-mode Date: Mon, 07 Mar 2016 09:48:25 +0100 Message-ID: <874mciekrq.fsf@oremacs.com> References: <87wppgax5o.fsf@oremacs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1457340541 7857 80.91.229.3 (7 Mar 2016 08:49:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Mar 2016 08:49:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 07 09:48:47 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1acqqL-0003Hp-O2 for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2016 09:48:45 +0100 Original-Received: from localhost ([::1]:54421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acqqL-0007ct-7Z for ged-emacs-devel@m.gmane.org; Mon, 07 Mar 2016 03:48:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acqq7-0007ce-Hq for emacs-devel@gnu.org; Mon, 07 Mar 2016 03:48:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1acqq3-0000uu-GV for emacs-devel@gnu.org; Mon, 07 Mar 2016 03:48:31 -0500 Original-Received: from mail-wm0-f45.google.com ([74.125.82.45]:35587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acqq3-0000uc-AZ for emacs-devel@gnu.org; Mon, 07 Mar 2016 03:48:27 -0500 Original-Received: by mail-wm0-f45.google.com with SMTP id l68so74939247wml.0 for ; Mon, 07 Mar 2016 00:48:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=pWbH/6i1o8Vx19ZcI+UTjfYKueN7Kjv2zKSPoUJLOnc=; b=GRD++OMSWcn+7miQORAyQYW3Rd/q45Jd1m42Rj33D1O0HwBLaDWhVn8JAhOdTlpJio 5iWLFKtjMrRkyoMee0FTcHjcttSStL6EAfmBsBBemXN7BLYFAwYofpihNu6+QMRara94 i/jG0vbmnjMPeU1tK3RxVXTm/m7Fg691Er9iRd1TEebrWeDVZFrb3d0BqYnaD/zWwp+S C9kmnzRjSLy5iPTj39rfK8H5u2/JPxB4nxCG6cYeidg+vROf0tCqPS8jJzCGtqHzlrNn aWa/Soay+0IclmolyNemZeeowB0dGSX7mX566xOgYyYFDrRI+xgm9BmWRoFq/h34i82F s0gw== X-Gm-Message-State: AD7BkJK5vBsuXnKwocXLpcaHOx6Jruauvh1uh8gXInKLzceagXeSgff2juLXRUirX1bfVg== X-Received: by 10.194.174.231 with SMTP id bv7mr15337100wjc.17.1457340506339; Mon, 07 Mar 2016 00:48:26 -0800 (PST) Original-Received: from firefly ([91.219.111.102]) by smtp.gmail.com with ESMTPSA id s206sm12461555wmf.23.2016.03.07.00.48.25 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 07 Mar 2016 00:48:25 -0800 (PST) In-Reply-To: (John Wiegley's message of "Sun, 06 Mar 2016 13:01:19 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.45 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201036 Archived-At: John Wiegley writes: >> Adding meta-data is an innocuous operation, just like adding documentation >> where there was none before. > > Wouldn't it change the way old code might get re-indented? In other words, > was this a no-op addition of metadata, or did it have aesthetic impact on the > way code gets indented? A bit from column A, a bit from column B. I think it's a flaw in the current `indent' metadata design that the absence of metadata is itself metadata. Since it makes it impossible to distinguish whether the absence of metadata is intentional or an oversight. You can grep the core for "(define-derived-mode " and see the possible effect for yourself. Here's a summary: out of 301 grep hits in *.el files, 19 instances don't follow the (indent 3) rule - all the others do: (define-derived-mode bookmark-edit-annotation-mode (define-derived-mode diary-fancy-display-mode special-mode (define-derived-mode semantic-grammar-mode (define-derived-mode electric-buffer-menu-mode Buffer-menu-mode (define-derived-mode reb-lisp-mode (define-derived-mode smime-mode fundamental-mode (define-derived-mode image-dired-thumbnail-mode (define-derived-mode image-dired-display-image-mode (define-derived-mode network-connection-mode (define-derived-mode newsticker-mode fundamental-mode (define-derived-mode newsticker-treeview-list-mode newsticker-treeview-mode (define-derived-mode newsticker-treeview-item-mode newsticker-treeview-mode (define-derived-mode ebrowse-electric-list-mode (define-derived-mode ebrowse-electric-position-mode (define-derived-mode elisp-byte-code-mode emacs-lisp-mode (define-derived-mode pages-directory-address-mode pages-directory-mode (define-derived-mode thumbs-mode (define-derived-mode thumbs-view-image-mode (define-derived-mode vc-git-region-history-mode So I've added an indentation hint that 94% of the code already follows, while 6% doesn't. It's up to you as the maintainer to decide if we want to have a 94/6 split just to not ruffle any feathers. Or we want to enforce a rule to make all code uniform - easier to read and contribute to. Personally I find it annoying tripping over things and trying to preserve the ancient indentation when contributing to the Emacs core. This could be a non-issue in the future.