From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Newsgroups: gmane.emacs.bugs Subject: bug#47799: 28.0.50; Default `project-files' implementation doesn't work with quoted filenames Date: Sun, 5 Sep 2021 19:14:29 +0200 Message-ID: References: <658a3e61-9511-5502-43de-8f591cec7387@yandex.ru> <91dd2467-f64e-eede-8098-14fc8ccd7ae7@yandex.ru> <429484E1-DDFA-4050-B5BF-E43477441C84@gmail.com> <5196C041-589E-4876-8254-3A6974D6DA53@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30972"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 47799@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 05 19:15:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1mMvjb-0007or-GK for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Sep 2021 19:15:11 +0200 Original-Received: from localhost ([::1]:38764 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMvjZ-00016Z-Pg for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Sep 2021 13:15:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48740) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMvjS-00016P-NM for bug-gnu-emacs@gnu.org; Sun, 05 Sep 2021 13:15:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39375) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mMvjS-0000zY-FI for bug-gnu-emacs@gnu.org; Sun, 05 Sep 2021 13:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mMvjS-0000ZO-9o for bug-gnu-emacs@gnu.org; Sun, 05 Sep 2021 13:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Sep 2021 17:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47799 X-GNU-PR-Package: emacs Original-Received: via spool by 47799-submit@debbugs.gnu.org id=B47799.16308620782147 (code B ref 47799); Sun, 05 Sep 2021 17:15:02 +0000 Original-Received: (at 47799) by debbugs.gnu.org; 5 Sep 2021 17:14:38 +0000 Original-Received: from localhost ([127.0.0.1]:50921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mMvj4-0000YY-E9 for submit@debbugs.gnu.org; Sun, 05 Sep 2021 13:14:38 -0400 Original-Received: from mail-wm1-f43.google.com ([209.85.128.43]:56229) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mMvj2-0000YL-JG for 47799@debbugs.gnu.org; Sun, 05 Sep 2021 13:14:37 -0400 Original-Received: by mail-wm1-f43.google.com with SMTP id g135so2915116wme.5 for <47799@debbugs.gnu.org>; Sun, 05 Sep 2021 10:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MJ44jntjSlmldBloQ6xEHm2EjgjBbAxykmhN+H1DXy0=; b=bLWVWVvq4c3gE0nCyR0h/dfzVz78n6pcs7e15WfuwRZj57IF5j5cI7cOTGbqjpclux P6SJrJ9HJGYORAOOa+EZptxt1a96WeFTrwlcNyLHRFRsiFZCB6gaLyCxACEc/wEoDZxo o8LIRUUKFqeoMzVle+OovPS991UbLqRIba6XrDHuvTkrch68cVv6ZPISpydxj/jIssL3 T6RE1yvByc4TiXmLnseP9b4m+GU1WWg1Put32Q1R0U/YEON6wuWLgc/U+RU5EvtXXllk iZ3IO2Hz3UmXN5f6pYeiiBKcJ/ahaEmaL4r8VURR+nS3Ch7O6Q9tUT9zPWwGBKGTNHtU xodA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MJ44jntjSlmldBloQ6xEHm2EjgjBbAxykmhN+H1DXy0=; b=B47GCQQZGdvP9rNG51e1h/KajjyYhDZCIWovWUlc6hdMIGoxS5tBsHk4dBudldfpxA 1Vt/wiZDc2hmFxv/OiNrUKDNrNE2AvuP+cUw30ovvE7LWRdiHvzCYsfF/1fxrLb5zLRM xT0KrPeTPkYmr4aZ++qk67l/RPihszfNAcxzNTiAaKodHafcSMsF3P78rTPb3WsLQEO6 IJjCt+cbUg2fMDW09mskyP5+QB3vSEtH5sss5VO6M61ZBgwG47/goeWCSc7FZqm96o1R k0bdTwEs+MMAhQnwUdA8TnCm8SZcCSv65ytoqlfrZGk2ZDujYSxC9ykcPDWV7sPqJmvr UpzQ== X-Gm-Message-State: AOAM5310DrvTXLGFPTb2X1hTmrD2dx/NSWww5z5pfHyJQvZQej09Ys5y d6ZEs+Xf/lsKXgbnrI7Gq0A= X-Google-Smtp-Source: ABdhPJy6IIJiLke4I5ngHJOULOrgEqqHrPHYXS1S/CtfjjzxORxxu9bNglNA06NNvKBIs3OTr6dIgg== X-Received: by 2002:a05:600c:1d29:: with SMTP id l41mr7707608wms.177.1630862070597; Sun, 05 Sep 2021 10:14:30 -0700 (PDT) Original-Received: from smtpclient.apple ([46.128.209.111]) by smtp.gmail.com with ESMTPSA id c3sm5439451wrd.34.2021.09.05.10.14.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Sep 2021 10:14:30 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:213519 Archived-At: > Am 18.07.2021 um 02:53 schrieb Dmitry Gutov : >=20 > On 05.07.2021 22:05, Philipp wrote: >=20 >>> The difficulty is having a method like project-files return one = format for some users, and another for users who want to take advantage = of this performance improvement. Or we break the compatibility and/or = introduce a new method with this new behavior. >> A general design approach in OOP is to not treat abstract virtual = functions (generic functions in ELisp terminology) as part of the public = interface of a type; i.e., abstract functions can be implemented, but = shouldn't be called outside of the module that defines them (project.el = in this case). That allows for changes like this: implementers could = freely return the new fileset structure because only project.el would = call project-files. Not sure how much ELisp code adheres to this = principle, though. =20 >=20 > When you say "abstract virtual functions", do you mean OOP as in C++ = OOP? I'm not sure about standard practices there, but this sounds more = like C++ and less like OOP in general. >=20 > I'm looking as generic functions here as part of an interface = signature (like Java or Go interface). They are programmed against = (which is the case with project.el) and are supposed to be stable. I think the idea is applicable to most programming languages that have = some form of subtype polymorphism. Basically, for a normal = (monomorphic) function, you can make the parameter types more general or = the return type over time more specific over time without breaking = compatibility. For a polymorphic function that's only specialized but = not called outside the defining entity, e.g. a private virtual function = in C++ or a method marked as @ForOverride = (https://github.com/google/error-prone/blob/master/annotations/src/main/ja= va/com/google/errorprone/annotations/ForOverride.java) in Java, it's the = other way round: you can make the parameter types more specific and the = return type more generic over time. That implies that for a polymorphic = function that's also called outside the defining entity, you can't = change any of the types without breaking compatibility. Thus the = suggestion to separate the interface for callers from the interface for = subclasses/specializers. >=20 > > If there's too much code (outside of project.el) that relies on = project-files returning a list, we need to indeed fall back to some of = the other options. >=20 > A new method seems to be the way forward. Or, say, an ad-hoc argument = which determines whether file names should be relative. I guess you also can't introduce new parameters without breaking = compatibility either. That would only leave the new method possibility. = We could then say that nothing outside project.el should call it to = avoid the above problem. Ideally, the byte compiler would support a = declaration form similar to @ForOverride to warn about such invocations.