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: Sun, 18 Jul 2021 03:53:55 +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="4985"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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 Sun Jul 18 02:55:12 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 1m4v5M-00019D-L2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Jul 2021 02:55:12 +0200 Original-Received: from localhost ([::1]:46084 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m4v5L-0005T7-3u for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Jul 2021 20:55:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38436) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m4v5C-0005Sz-Ll for bug-gnu-emacs@gnu.org; Sat, 17 Jul 2021 20:55:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43347) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m4v5C-0003rx-ER for bug-gnu-emacs@gnu.org; Sat, 17 Jul 2021 20:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m4v5C-00072H-7J for bug-gnu-emacs@gnu.org; Sat, 17 Jul 2021 20:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Jul 2021 00:55: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.162656964626979 (code B ref 47799); Sun, 18 Jul 2021 00:55:02 +0000 Original-Received: (at 47799) by debbugs.gnu.org; 18 Jul 2021 00:54:06 +0000 Original-Received: from localhost ([127.0.0.1]:54893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m4v4I-000715-H3 for submit@debbugs.gnu.org; Sat, 17 Jul 2021 20:54:06 -0400 Original-Received: from mail-ed1-f48.google.com ([209.85.208.48]:44605) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m4v4G-00070a-C4 for 47799@debbugs.gnu.org; Sat, 17 Jul 2021 20:54:05 -0400 Original-Received: by mail-ed1-f48.google.com with SMTP id l1so18107102edr.11 for <47799@debbugs.gnu.org>; Sat, 17 Jul 2021 17:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=M66UMmKJ83F8OfbMRleiCeBlHytp8Rju/rI6mSmqT0c=; b=AevKDn7fsdIdSKL58G/FQPER4DGp2K+6p5Y0ULKbTerCg5I/peufwQVKlJ3W6Pkn3l Qtdk3TMCy+SEHrToDMkf9jnFo2QclWYXUR+f7xYdcl66c/LR108//dFin1LutiM8+hxl Yfg0HsJxbHUV6OOS00+zpzDI0czyA4wZgULRT3BFa51o2G6QKrWqcY728p8DyJr1n9ey R77kWaxLK8ib9rP4bmHhDUQLr9Tn9bTua7YHZumMpfJASv2QVRyF9+S/lPYSHqLHJ0d1 RJuHOvYmKmY84+SW/6nGlLlCUDLFHyfKEFO24605EUDzdInuFnALi8vXKyINJejbtPmO /yeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=M66UMmKJ83F8OfbMRleiCeBlHytp8Rju/rI6mSmqT0c=; b=ChUUknjfmVdslZoy8/Ymb1vfwMrmC7AEprnugIbqT4rmsy7NsUYSVFdkcCiCopb1Uv tn5qSePhGMZPcQJvBy2uOfr9OCOk9EcSfoOVBC9heNPi7o1izl/bBYFiNEkDfd10LzTW LRdYca9l2h2N/lkcpA8AxCbFGno5Dsl5IQcUN5wXHTs+fl6k6KuZxxDQVANaNwRxXce+ ApwTF83uooiuqNxH9Bl/9JScHRQ4FprSkiLnMbPaxiWk668eLLT2lSUCslCWHC+0Jprc fZIY3nmQbtGMkU71/uhy2YvsIoAw+LLYzJHt8nOIBqC9ysQ8SHxcp2TqTrNey1OSrWYb KRpQ== X-Gm-Message-State: AOAM5305ATXtil5s8TwiThYME0zU+j2S4pBi/JV0W4gXwYrwpaayWYpX 72KznsqqguwhPs6uuIvcFC+WVR1Z41I= X-Google-Smtp-Source: ABdhPJyE+OLih3sieCBpX6xO/UYala44eh5c5ahimV0lAy95jVkQC6dmEC4MnwOhU2s3wCfURCWnbA== X-Received: by 2002:aa7:d4c2:: with SMTP id t2mr16023803edr.241.1626569638524; Sat, 17 Jul 2021 17:53:58 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n10sm5696192edw.70.2021.07.17.17.53.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Jul 2021 17:53:57 -0700 (PDT) In-Reply-To: <5196C041-589E-4876-8254-3A6974D6DA53@gmail.com> 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:210156 Archived-At: On 05.07.2021 22:05, Philipp wrote: >> What I was also thinking of previously, is some "fileset" data structure which could contain a list of local file names and their connection in a separate slot. Maybe even separating the parent/root directory into a separate slot when feasible, to minimize GC further, though that might complicate applications. >> >> A more structured "file" value format might make this stuff easier to use indeed, and perhaps the performance difference will be negligible. > > I think those are very good ideas. The "fileset" structure sounds like a pretty good abstraction. I've yet to express that in terms of code, though. >> 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. > 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.