From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Extending define-derived-mode Date: Fri, 02 Jun 2023 14:51:17 +0300 Message-ID: <83jzwmaxqi.fsf@gnu.org> References: <20F07C52-6B39-4B24-8433-82E2226EADA6@gmail.com> <83zg5mf62s.fsf@gnu.org> <88498EC5-0870-45ED-802D-85286FB2E9FC@gmail.com> <83edmventk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35204"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org, mickey@masteringemacs.org, theo@thornhill.no, dgutov@yandex.ru To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 02 13:51:30 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q53Ja-0008vY-G6 for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Jun 2023 13:51:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q53Ij-00070y-GM; Fri, 02 Jun 2023 07:50:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q53If-00070m-7r for emacs-devel@gnu.org; Fri, 02 Jun 2023 07:50:33 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q53Ic-0006qv-2h; Fri, 02 Jun 2023 07:50:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=FzbpE7Sx/G1ubwRaICvN38JUI6rmGuVgD3cy6R8iLfY=; b=ULeuEyZ3tCEnTmJlJsta i7Xw71iu68vSuH69kslX5p5IiT2Q3UCJ3bZjdHMAFkCCe5L4ZDVr+undILW9HOBjuhn3PgDkeOt+O il2w6Uu7IjUrEA18MJQclihmQgceGT8dBYyVeafmouYB8cT1wZfc1+Ky/sGZvMylzpL7RYMpwkNnG eHW5AE3ScN5iu44txfH1109TMPb7P5GuL+0mkabuVo3iel1hcupImW7PAH56vJprXBl6Xt/LrMPg+ ofnv4E4VoR+B2hSWo56jz2sxym16t1CyZ8n7EEFHkxNOqSvuM8iqbjgWlB9FhnfAJZ+Hp9vHJEKHv liZqDbrHwzgVwg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q53Ib-0007TB-6k; Fri, 02 Jun 2023 07:50:29 -0400 In-Reply-To: (message from Yuan Fu on Fri, 2 Jun 2023 00:45:31 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:306551 Archived-At: > From: Yuan Fu > Date: Fri, 2 Jun 2023 00:45:31 -0700 > Cc: Stefan Monnier , > emacs-devel@gnu.org, > mickey@masteringemacs.org, > theo@thornhill.no, > dgutov@yandex.ru > > >> I don’t entirely understand the example. Say I have a xxx-base-mode, and I want to setup menu-bar menus in it to be shared by xxx-mode and xxx-ts-mode. What is the problem that I’m gonna run into? Couldn’t you just use the base-mode’s keymap? > > > > A base mode usually doesn't have a map, only the actually used derived > > modes do. > > We can create a map for the base mode, and the child mode’s map will inherit from it. We can, but it won't solve the basic problem. This sub-thread comes from me explaining why this presents a problem for, e.g., defining menu-bar items, remember? So, if we examine the issue in that context, you will see that creating a map for the base mode has the following downsides: . It can only have bindings for the commands that are identical in all child modes, something that normally isn't the case. For example "C-c C-q" is bound in both c-mode and c-ts-mode, but to different commands. . The menu items you can define in the base mode can therefore only reference commands bound in the base mode's map, which once again means only identical commands. For example, compare the menu items in the "C/C++" menu-bar menu of c-ts-mode with those in the "C" menu of c-mode, and you will see what I mean. This is why it makes sense to define the bindings and menus in the child modes, not in the common base mode: in many cases the same key sequences and menu items will be bound to different commands. Likewise with buffer-local variables: in many cases they will have different values for different modes, and sometimes even different names, although their functions and effects could be very similar or identical. Bottom line: based on our experience to this point, it sounds like at least in some cases the differences between the non-TS mode and TS mode supporting the same language is significant enough to make the idea of inheriting from a common base mode problematic if not impractical.