From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#47799: 28.0.50; Default `project-files' implementation doesn't work with quoted filenames Date: Mon, 20 Sep 2021 19:05:03 +0300 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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30803"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: 47799@debbugs.gnu.org To: Philipp Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 20 18:08:49 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 1mSLqa-0007pn-Bz for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Sep 2021 18:08:48 +0200 Original-Received: from localhost ([::1]:55196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSLqZ-0000wR-1y for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 20 Sep 2021 12:08:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSLnv-0006kw-6l for bug-gnu-emacs@gnu.org; Mon, 20 Sep 2021 12:06:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60599) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mSLnu-00070c-6J for bug-gnu-emacs@gnu.org; Mon, 20 Sep 2021 12:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mSLnt-0003IZ-QW for bug-gnu-emacs@gnu.org; Mon, 20 Sep 2021 12:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Sep 2021 16:06:01 +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.163215391412567 (code B ref 47799); Mon, 20 Sep 2021 16:06:01 +0000 Original-Received: (at 47799) by debbugs.gnu.org; 20 Sep 2021 16:05:14 +0000 Original-Received: from localhost ([127.0.0.1]:43912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mSLn8-0003Gd-A0 for submit@debbugs.gnu.org; Mon, 20 Sep 2021 12:05:14 -0400 Original-Received: from mail-wr1-f52.google.com ([209.85.221.52]:33688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mSLn6-0003G4-32 for 47799@debbugs.gnu.org; Mon, 20 Sep 2021 12:05:12 -0400 Original-Received: by mail-wr1-f52.google.com with SMTP id t18so31250612wrb.0 for <47799@debbugs.gnu.org>; Mon, 20 Sep 2021 09:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=f7L9T5N3+d6/GZN0M7h1P8yKlOU3blOZyP8ujvbcyhc=; b=Vr/KBhJfclAO+t90+z6yNJlYD6L/qaDQmSO3sWTzuiX2wRs5QPr4H/DVpDAoXXE7ZG H56xXa3pcijgv4BO/EmYj9Tkz4IYfWR+IXkxopt5FqtrqCfkKjjBiwH69/5YZ2drDUgN TKt2CX6p7UcdRWLfCEzWvVPFSq1vHJzM1NU59L2gB4JvNI3Jb0raw4yhPTMK0D5GQmMC cZ3SmBfE1pjOH9JWh4SmXzzj8RwfEbcTYXM7XfS6KsbxVbBPJJrhb6WM+F2FeQmLy0b3 7Q24dVxKtpQzFjozZDXt52DP/nGVuRYaOh2jHYlYY/mNZMm4HlamkxVnZMwmwyfdSw++ I7iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=f7L9T5N3+d6/GZN0M7h1P8yKlOU3blOZyP8ujvbcyhc=; b=wYsDquGdLBcXqL/ZgBWpJZA20YWkj3Hywz2TOerZ7GJYMrAzhAOZUprQNH5mLeYVGb I6URfKPiRCrZZRnN0LpSwXYAB7JcPYH9dINmVMSUIULTbF08zTTatHSRJwqqm08GLq6j TQ0Z3FIvKgh5rX/ke1LUYUNkWr0bTRKIxBDgikts51jxf371CMaHEJWzo6zZHtFZ0vTk v7yDhJX08i9DBIukdPVk6a1HXXMAkgcWy8eCKrK6cQiv9cQitko8xvqs5tv8l7QeK6DO jYuRtzyK8rYOSL9qkMiFnOfCVOWKKeaUPeeaHLgb9kIy1U5fdAgTcvWVwZGbgy+VVdrJ wb5Q== X-Gm-Message-State: AOAM532yChpjZYAjkNAxV2ZYfBuMAP+6z9M8dtlZdHMKFKmWqFqJp+Qe GmX3OGlZmjzDqTFLJYpOlXz6uqKV00s= X-Google-Smtp-Source: ABdhPJxqzVey6VVqRgMBoVZwLTx0gxilYqjPjhPYDIrnbdD/DFbFiJ9neW1Tge3wiWf6flRguUW4jg== X-Received: by 2002:adf:e406:: with SMTP id g6mr29744498wrm.172.1632153906284; Mon, 20 Sep 2021 09:05:06 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id k17sm16231444wrq.7.2021.09.20.09.05.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Sep 2021 09:05:05 -0700 (PDT) In-Reply-To: Content-Language: en-US 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:214875 Archived-At: Hi Philipp, Sorry for the long pause. On 05.09.2021 20:14, Philipp wrote: > > >> Am 18.07.2021 um 02:53 schrieb Dmitry Gutov : >> >> On 05.07.2021 22:05, Philipp wrote: >> >>>> 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. >> >> 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. >> >> 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/java/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 e ntity, 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. I'm not quite familiar with the practice, and since we don't do type parameterization here, the justification probably doesn't apply. >>> 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. >> >> 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 is also true. So we'll probably go this way: I'm already experimenting with a method called project-files-filtered in the scratch/etags-regen branch. > 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. I get the idea of having a Template Method pattern where the public method is something else (this approach seems to be described in ForOverride.java), but I'm not sure how to apply it to our case. I.e., what kind of data the "public" function would accept and return. If you mean it would return a list of absolute file names, that would actually limit its usefulness. And/or perhaps you imagined that our projects could have a "private" method which would not be "exported" to outside code, but which project-find-regexp would be able to use? I don't really like that approach, outside code should be able to reimplement the same features.