From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Sun, 21 Jun 2020 01:21:48 +0300 Message-ID: References: <87bllfqj82.fsf@warpmail.net> <626efe11-0f9c-081b-11dd-0d61cee8168d@yandex.ru> <83h7v7xf7w.fsf@gnu.org> <831rmayj55.fsf@gnu.org> <6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru> <83wo42w83e.fsf@gnu.org> <83a70yw1y8.fsf@gnu.org> <87mu4ym6f6.fsf@thornhill.no> <834kr6vymb.fsf@gnu.org> <90f4c9e8-bf8d-3b27-a8a9-ed44c5d23839@yandex.ru> <83y2ohvrxl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="37206"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: philip@warpmail.net, theo@thornhill.no, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 21 00:22:34 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jmlsf-0009cH-MT for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Jun 2020 00:22:33 +0200 Original-Received: from localhost ([::1]:48174 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmlse-0004FF-Lw for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 18:22:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35946) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmls3-0003lJ-1m for emacs-devel@gnu.org; Sat, 20 Jun 2020 18:21:55 -0400 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:42360) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jmls1-0004Mz-4S; Sat, 20 Jun 2020 18:21:54 -0400 Original-Received: by mail-wr1-x42f.google.com with SMTP id o11so5392836wrv.9; Sat, 20 Jun 2020 15:21:52 -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=1Pw+zbpONxE2VynnJfFiYqxFn2iT4ekmclmdrcZK5nE=; b=USpVCE9OwS5cam/DF4gGyAydI6PBR1u1prI3j64NUQRbDo8KnDr5wgDGfAze5visFV dcmesPIrWpPy5Q8dzIjK0IZWiuE+AeTRCj9sfGr6nrSmcZmyiRccr38EMyR+WmEkcRGV CHKLgh+eT9nLpVyb69KPyoegUqMm0uvg7VjMIfyFEZfpUkBNPoXJLwdLE8qfGhSn4miG poTdU1kcw0rbaTDo3sb6HmUeKC+QOrXaBEWputZ+NgUs/eQNEob9OlS1EPmaec1HqU/y cxsWYcESApO0jx7vf9sy3JUCz0v1k6duHrKxZabPYo80C7EpgKw22DYGCb0yZYfdBzc/ jkvQ== 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=1Pw+zbpONxE2VynnJfFiYqxFn2iT4ekmclmdrcZK5nE=; b=mZzwTXWhv8LFhsFbFzmZePK+9GODuTeXp/jEoiOwwHwvBKDw45dAPLQK+DIY1wad4t 0Til9NU3VNcmxuD3pga+K7Y+a1RNkFAMqIjpjihk5x5ZRv/lSRKEhjvkZdi0MyMynpO6 IQwPBTS0FMMWa9Iu8WPugwRw+P7btA4DA6OWhXJAm45MxhEk3HU5yqkyDU6fvmJcyi14 GsDRrd8qb7LvjaucYInGaemjt6s/hqHIPhtabJ/J16Z7WP6eWq2XObzJzQSdig0rnsZt qu3kpqrsnqz8MzwlMTuLvXseGCaI/XUJOfJzvS35pQcH14E/CUOkbn9t3lB2YE6H8Ziz ZRgg== X-Gm-Message-State: AOAM530SvzzpFUkBAeTyvpc1u4093etBcUb3N4M5G7cwnn9ghZM3q10z wEsU9Xz/48Oe97szgYfgYpnOuejT X-Google-Smtp-Source: ABdhPJxbZG1Jhi/C4qpRNm3eZA+qKY95jEXlMyCD1HROuBicmoy8CDxeY6+n9TEGmYJVXxsTDsUWiw== X-Received: by 2002:adf:fe0b:: with SMTP id n11mr10605887wrr.245.1592691710983; Sat, 20 Jun 2020 15:21:50 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id s2sm10869559wmh.11.2020.06.20.15.21.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 20 Jun 2020 15:21:50 -0700 (PDT) In-Reply-To: <83y2ohvrxl.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=1, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252467 Archived-At: On 20.06.2020 15:32, Eli Zaretskii wrote: >> On 20.06.2020 13:07, Eli Zaretskii wrote: >>> In any case, my proposal was not about the API itself, it was more >>> about the implementation of the API. For example, we could have an >>> implementation of the generic project-files API that consulted some >>> list instead of asking the VCS or the filesystem to provide the files. >> >> You can of course do this already, in 10 lines or so. > > I'm a user. I don't want to write code every time I want something > simple from the project-related commands. I expect such simple use > cases to be supported OOTB. I think we're generally comfortable recommending users customize something in their init script, if that's a one-off request, and nobody else comes with the same request. Of course, when such customization turns out to be useful and elegant enough, we can always incorporate it later. For less technical users, we sometimes offer a snippet to use. Even if you just do this for yourself, it can be a valuable of the API is defined, whether it can support your usage scenario this way. >> But imagine you did add such a backend where project-files returns an >> arbitrary list of files. And you use it. >> >> How would project-switch-to-buffer consult it? Will it have to call >> project-files now, as opposed to just using project-root as the basis >> for comparison? And then compare buffer-file-name of all file-visiting >> buffers against that list? > > That's one possibility, yes. I'm asking for a concrete suggestion, if you have it. And I have just outlined a problem with the most obvious approach. >> That would work for smaller projects, but in large ones project-files is >> not instantaneous, so they will be penalized in performance by such an >> approach. > > We have faster data structures than lists. We could use them. List as a data structure is a secondary problem. Big projects can take a while to fetch that list. > And in any case, we should identify the needs first, and then > implement the features that support those needs. Rejecting some of > the needs because they don't fit the current implementation is the > wrong way for designing features such as this, which is supposed to be > part of our IDE infrastructure. As outlined above, even if I recommend trying to implement a usage pattern in one's init script first, that doesn't necessarily mean I rejected it. >> And project-switch-to-buffer should work with all kinds of projects. > > Yes. And one such kind is an ad-hoc collection of files and buffers, > where only the user knows which ones he/she is interested in and which > ones he/she isn't. Every IDE I saw supports something like that, so > we should do that as well, IMO. I'm curious about those "every IDE". I don't recall such a feature in ones I tried. Perhaps I just didn't use it, of course. >> That also wouldn't solve the problem of non-file-visiting buffers like >> Grep from your example. > > You talked about project-files, so buffers that don't visit files are > excluded, of course. But an indication that supports marking buffers > as belonging to a project could support both file-visiting and non > file-visiting buffers. Buffers are essentially transient. An indication could be a list of files, but the project API has no provision for "list of buffers", and such a thing has never come up until now. So my first instinct would be to make this customizable through some hook, rather than extend the API.