From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eric Ludlam Newsgroups: gmane.emacs.devel Subject: Re: completion-at-point + semantic : erroneous error Date: Sun, 27 Oct 2019 19:36:06 -0400 Message-ID: <38f698ab-bf54-9124-5b88-dd81da37c576@gmail.com> References: <957ad127-0d84-69e3-49b6-9799975bd724@siege-engine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="29738"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: Emacs Development , Eric Ludlam To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 28 00:36:58 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iOs5f-0007U8-Fd for ged-emacs-devel@m.gmane.org; Mon, 28 Oct 2019 00:36:55 +0100 Original-Received: from localhost ([::1]:49954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOs5e-00046I-6C for ged-emacs-devel@m.gmane.org; Sun, 27 Oct 2019 19:36:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37700) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOs4x-000448-Bq for emacs-devel@gnu.org; Sun, 27 Oct 2019 19:36:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOs4w-0002xs-3K for emacs-devel@gnu.org; Sun, 27 Oct 2019 19:36:11 -0400 Original-Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]:34586) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iOs4v-0002xf-TT for emacs-devel@gnu.org; Sun, 27 Oct 2019 19:36:10 -0400 Original-Received: by mail-qt1-x832.google.com with SMTP id e14so12107845qto.1 for ; Sun, 27 Oct 2019 16:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=MmTSSv0uFLbOzJEErCl5mL0nDxAwO8JHI2wMGsl8mBM=; b=jxD1LeUdhdUvZfRv5pbOCYqTCdW6fDGZ24wkqiCiwjhOiU3p85sxZtsOi7xDtmFNK3 SUZL2MM87Npq5GqGo7ya+031TNNP87C4Ptv3xh9j1lnJQuOZ3MYHAYCdo7vYJbgHh2Jm tHSwd/AztvExdi/KZ+dEw7VY29mmfsSRz7NNBwn0CQvpY7w2BeGEsfYvM4VznxpIUiKC CWfSX4isBXa3xUSGpWu2DsX7vU9VXVM4o9qRdWBUs50eHoI2HGmd61r/lypA9DfCb5VR MVmZM8uqoKJ8y7/No0+46OGfJVIMTxTyQEE+Ij6il1MhpDWfXTjz6Iti5O1mmt+QMrZf htag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=MmTSSv0uFLbOzJEErCl5mL0nDxAwO8JHI2wMGsl8mBM=; b=XyElcmzOHn7X1//5o/qawMcNewHAGYNZRIJnyhnHy7E9O+KaiuE/cU4dUC6QePuIJi xMC33PSHW6J/1MnQTt3eS2Ns2XLll+mAbPvpx3L7fVJz/LDKoEQu3nT3f25K4J8W9xtX 8Jmzg7exVpHrqpilAJWjOy/7ik+JkuJAyxaE24CxxTaadu1tZLu8veS0Q/Iqo1Whiz8n RmWl3hRAN6T56anoXwCLjy38y93oxM3I5J4Iok1gScnMZOwCOXQo5HyWsInJeUoxJOCP 9z/JYTbFs58My6xrUdBb8ZLIu9a3GUq0Sy20R6bYwGJd/mB4wFTdOv04XNCI9N5L+EDs ZmnA== X-Gm-Message-State: APjAAAUtGKVHyu4ejsHRflfiDBSiAX+0Ajf4n/hRnojEjju05UC9PNIH paSKGWA5UmlnuAnZsdHfTLQrukaP X-Google-Smtp-Source: APXvYqyhm9RxooydseODfmlhpTsvsyBZ/CcJSBdpPhhLqCYfYzHuJwIYyvn4B+amGcxMGD2acWC0oQ== X-Received: by 2002:a0c:c3c4:: with SMTP id p4mr15054455qvi.178.1572219368357; Sun, 27 Oct 2019 16:36:08 -0700 (PDT) Original-Received: from [192.168.1.202] (pool-108-20-30-136.bstnma.fios.verizon.net. [108.20.30.136]) by smtp.googlemail.com with ESMTPSA id l129sm4945249qkd.84.2019.10.27.16.36.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Oct 2019 16:36:07 -0700 (PDT) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::832 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:241537 Archived-At: On 10/27/19 4:38 PM, Stefan Monnier wrote: >> >> It sounds like a goal is to slowly remove mode-local. > Yes and no: I'd like to remove the duplication that it entails. > E.g. I think defmethod's &context has made mode-local's > overloadable-functions largely redundant, so I think it would be good to > remove those overloadable-functions. > > I haven't looked at the mode-local-variable part of mode-local.el, so > I don't plan on removing any of it for now, tho I think that if it > stays, it would be good to better integrate it into the rest of Emacs. > >> If there is a better official way to do the same thing that seems fine >> with me. > My hope is that defmethod's &context covers those needs and that "it > seems fine" to you. Don't know if it's the case. Heh, sure.  The defmethod technique solves the same core problem, but has the added benefit of being clearer by not depending on a magic -default implementation somewhere.  It has been long enough I don't recall all the variants out there. >> For this specific item, I'm curious what the alternative might be.  The >> obvious solution I can think of is making all the assignments for >> functions and variables to all relevant modes, which feels error prone. >> This was a way to specify similar modes for all overrides for this tool. > W.r.t the `mode-local-parent` property, it looks pretty ad-hoc (not to > say hackish): why not set `derived-mode-parent` instead? Of course, the > right way to set it is to change the mode so it sets it via > `define-derived-mode`. Otherwise you're in "it's kind of a child but > not really" territory. > > BTW, regarding the above uses of define-child-mode, they've been reduced > down to just: > > bovine/c.el: (define-child-mode c++-mode c-mode > bovine/el.el: (define-child-mode lisp-mode emacs-lisp-mode > > I think the `lisp-mode` one is an error: lisp-mode is supposed to be for > common-lisp, which is clearly not a child of emacs-lisp-mode. > This said, AFAIK noone uses lisp-mode, everyone uses some other mode for > common-lisp, either the one from SLIME or the one from SLY. > > The one for `c++-mode` is more tricky: I guess one could change cc-mode > to make c++-mode derive from c-mode instead of prog-mode, but that would > make it run c-mode-hook which some users might not like. Maybe we > should have a c-base-mode from which both c-mode and c++-mode derive? > This question is of course largely irrelevant since Alan will likely > never accept any such change in cc-mode.el. But I think it would be > perfectly fine to make define-child-mode set the derived-mode-parent > property in this particular case. This part of the mode-local system was put together to workaround the fact that we weren't modifying Emacs itself, and sometimes wanted to support multiple versions, and support other random modes not in Emacs.  The thing with c/c++ is a prime example.  If we externally define c++ as a child of c, will that break anything else? >> I'm not sure.  David Engster did most of the work on mode-local. There used >> to be the primitive semantic- only version you found that he wrapped up in >> mode-local.  Looking at this in retrospect, I'm not sure why the functions >> installed with semantic-install-function-overrides weren't done using >> mode-local more directly.  If they were converted, then >> semantic-install-function-overrides could be removed. > OK. I'm not sufficiently familiar with the code to see how it can be > changed to use define-overloadable-function instead of > semantic-install-function-overrides, but I'll try and find out. > I can take a crack at this.  I'd like to figure out the test issues first though. Eric