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 08:35:15 -0400 Message-ID: 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="257471"; 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 Sun Oct 27 13:35:29 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 1iOhlZ-0014qO-Lp for ged-emacs-devel@m.gmane.org; Sun, 27 Oct 2019 13:35:29 +0100 Original-Received: from localhost ([::1]:45132 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOhlY-0007l1-E8 for ged-emacs-devel@m.gmane.org; Sun, 27 Oct 2019 08:35:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54507) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOhlQ-0007h0-IY for emacs-devel@gnu.org; Sun, 27 Oct 2019 08:35:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOhlP-0000b6-0f for emacs-devel@gnu.org; Sun, 27 Oct 2019 08:35:20 -0400 Original-Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]:42820) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iOhlO-0000as-Sk for emacs-devel@gnu.org; Sun, 27 Oct 2019 08:35:18 -0400 Original-Received: by mail-qt1-x835.google.com with SMTP id z17so3924818qts.9 for ; Sun, 27 Oct 2019 05:35:18 -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=9D5SNYSz04bNUwlCf7hmgKncgQb+fkQomyGwZkDb56k=; b=JQ2X8mO9m3BtOpLC/VBUk2CmBA1GWdZ+EPOfOpVYP85lthG4Gi2/mEw648MmCTc7ag E5rVqRFOWyRpVZ93gf/dldZRFn0TrbhhhqyV6Ytu9QRUjtkdZ9ZHIngiQOneTPP5vhM1 9pZOZEqBOiVIWXEz8U2YlYuuubzgfhKWOxy/lGxFxlxwnm6g6BK13s1a2JLRGRgvZe1m f0CeYPF7RmlDDho1v4ixmvCFUIyfOMG8isUt+uvzFMWhD8BTi3nohvgxjQyBHaVlcwFi 86x+w3kx6LV9uvNG6btGyjDF0qotULX8s33CBqELx6SVs9vccDqLz7Cs9OovdDFjxgaU KmcQ== 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=9D5SNYSz04bNUwlCf7hmgKncgQb+fkQomyGwZkDb56k=; b=TgDq34jfE0MwewaR/2eMj7fAOfL2jcYcZKZQJQk9VVXWUnIHJUuDgox0F80z+tTuwI MMvnIHOYn2jYlPlmtwh0TGa3aFCVeBks9+jPqfm7Jn+zP/cfRu8zX1BwIJGiMwnSAnTX f1MbKMY9Boc2vfRI6zOqKysegw6SIBd4PTGf/znKcntCYK0bPMLYhwPKileeoVnv3duw xOqoiaVNqrtdUwInQSXbINWlfrapj2L5WwY6TNdc7T1LbJizN7j/AeKmIF/2iNC7UUJ6 9jzWAVwuxecACJ0auIeouP+bWU6nH2KcOlHdDlNOvCVQ6gN6QoDw7uBIzMIpGc6PfEhk zShg== X-Gm-Message-State: APjAAAUT4AdGNffw/sF5JnPyAmKYB5QXgkvS+poHxFA+QtM5icrxuaOF poVJC43uljaZGEoACc/+WNHyzB6z X-Google-Smtp-Source: APXvYqwleDWaI0YpYrHPtLWk3ndUUluvBNPJNmnktljQbRRA3nHFIMr277OfL8WjP2xFkP2b2FhrIg== X-Received: by 2002:ac8:17e2:: with SMTP id r31mr12957026qtk.133.1572179717483; Sun, 27 Oct 2019 05:35:17 -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 x3sm1725391qkn.109.2019.10.27.05.35.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Oct 2019 05:35:16 -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::835 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:241517 Archived-At: On 10/24/19 4:17 PM, Stefan Monnier wrote: >> I went back to mode-local to remind myself about it.  One of the things it >> handled was derived modes. > The `derived-mode` specializer I used in the patch for the &context part > correctly handles derived modes, as the name suggests. It doesn't pay > attention to mode-local's `mode-local-parent` property, of course, only > to the `derived-mode-parent` property. > > [ BTW: I'd like to remove the `mode-local-parent` property. > AFAICT it's only ever set by set-mode-local-parent which is only used by > define-child-mode which is used as follows: > > bovine/c.el:(define-child-mode c++-mode c-mode > bovine/el.el:(define-child-mode lisp-mode emacs-lisp-mode > html.el:(define-child-mode html-helper-mode html-mode > wisent/javascript.el:(define-child-mode js-mode javascript-mode) > wisent/javascript.el:(define-child-mode js-mode javascript-mode) > wisent/python.el:(define-child-mode python-2-mode python-mode "Python 2 mode") > wisent/python.el:(define-child-mode python-3-mode python-mode "Python 3 mode") > > I suspect these could be replaced with other things. WDYT? ] It sounds like a goal is to slowly remove mode-local.  If there is a better official way to do the same thing that seems fine with me. 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. > >> Also in your patch is a TODO about `with-mode-local'.  That with-mode-local >> did more than just allow the next method call to dispatch correctly.  It >> also sets up mode local variables, and other mode-local dispatchers for >> anything the dispatched call might need.  In this case, the completion call >> uses lots of other mode local dispatched functions.  with-mode-local doesn't >> set the major-mode though.  Since all of CEDET is presumably still using >> mode-local features, you will need both. > Yes. More importantly, I see that additionally to > define-mode-local-override some functions are overloaded on > a buffer-local basis via semantic-install-function-overrides. > This doesn't fit well with the cl-defmethod system. I can probably get > rid of semantic-install-function-overrides, but do you happen to > know if some functions are overloaded on a buffer-local basis from > elsewhere than semantic-install-function-overrides? 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. On a side note, I was testing your patch that started this thread by converting more tests from CEDET on sourceforge to be part of Emacs.  It has test files from a broader range of modes.  It doesn't test all the different overrides and modes, but if a goal is to factor mode-local out, it could more definitively answer if any parsing infrastructure is broken given some of these proposed changes.  I'll try and get it wrapped up and ready soon. Eric