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 00:18:14 +0300 Message-ID: <26757137-dcf1-3700-e142-cdc9d4cfb1ef@yandex.ru> References: <87bllfqj82.fsf@warpmail.net> <83o8pfxhzq.fsf@gnu.org> <83imfnxgt3.fsf@gnu.org> <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> <87eeqat0wz.fsf@gmail.com> <83tuz5vrog.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="42159"; 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, emacs-devel@gnu.org, theothornhill@pm.me, kevin.legouguec@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 20 23:18:55 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 1jmkt4-000As0-1M for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 23:18:54 +0200 Original-Received: from localhost ([::1]:48682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmkt3-0006xl-2O for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 17:18:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmksX-0006YX-MC for emacs-devel@gnu.org; Sat, 20 Jun 2020 17:18:21 -0400 Original-Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:51586) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jmksV-0003kG-Rr; Sat, 20 Jun 2020 17:18:21 -0400 Original-Received: by mail-wm1-x32c.google.com with SMTP id x16so2398898wmj.1; Sat, 20 Jun 2020 14:18:19 -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=cy6xkgz1jshEdm9NVqlBh9ZgIb6c8OW5OH7e8FrzLmw=; b=Yb6gEBaRrkrOfdKpI/ZheAJ3LC6z0D24YYO4F5ATQ92X71D3WjNkf2tf9C0n2rsRNg tHkS58YbDqGcep0mXqsJmiLcbeBTGjcgmZymr3eia+SPMLH88ZCpJ93dJAlwI90kId+E Jw8zNbv5U2Yw4UPMxChEDGINVeffIgiHU1OO3chmRi4lW5UpYCVjkNHPZwdVw7ZZ0XfN YaPoEmkUYrxzwAS96asxaIqJYBgSVOiyul92oSoUQx5m0Ip1Em0IKoXCcomCNyf2Y4Sm 0N5A9mt5El49Z2n2eD/q1QYjmsmgJjeZlZKYpB5FZDYKXmJfAiP0YjcK51vogVZkk3z3 2djg== 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=cy6xkgz1jshEdm9NVqlBh9ZgIb6c8OW5OH7e8FrzLmw=; b=LLsSKtwkxvEY/TbDwPAs/vSreDO7v6gA652o+3z4hELRRjHxyGbJj55H+BD00Rc5W6 YTViBF4maRbv3N/qF4qDezbG9ky9zgipnHbyCGWVbVmAL8RPLq3cXG6WiNOEyZjoaf6x PGzksMAHJbZqp9V2xAkFNV2XX/9K5d47N3UVbU0vGitPdrjVZiyYnr/eDMWrenINYezy CJkg60Yrqiv7JRhnpSYXAhTlk0ACjxwnt/xhabV3s9KdL8peWhipeASjGe3nieVJEzwp HofauIpHZCicFvgel4oQSm+KHxW4eOSaMNNog4hpTZwNL1+F8XHMuhrkh6vGmnqK+Jfg Z+Rw== X-Gm-Message-State: AOAM532r8YMgpqcKLomdp3MZOQ4w26hH83hqBXkmOVPLeXz98971Hac+ CbwJ4uLoroiSLPTjuhVDVZkAyKu6 X-Google-Smtp-Source: ABdhPJy0vCeOCIS3cKDFPkGSFk8G7OmPoZxJOA11mfcGBdnvb7Jp+fQcuDYfNFSNUE5G9H8MjGNuUQ== X-Received: by 2002:a1c:8186:: with SMTP id c128mr10864208wmd.114.1592687897397; Sat, 20 Jun 2020 14:18:17 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id f186sm1935962wmf.29.2020.06.20.14.18.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 20 Jun 2020 14:18:16 -0700 (PDT) In-Reply-To: <83tuz5vrog.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32c; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32c.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: 10 X-Spam_score: 1.0 X-Spam_bar: + X-Spam_report: (1.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, FREEMAIL_REPLY=1, 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:252462 Archived-At: On 20.06.2020 15:37, Eli Zaretskii wrote: >> Cc: Eli Zaretskii , Theodor Thornhill , >> philip@warpmail.net, emacs-devel@gnu.org >> From: Dmitry Gutov >> Date: Sat, 20 Jun 2020 14:57:07 +0300 >> >>> Would it make sense for these special modes to have a buffer-local >>> variable pointing to the buffer where the command was invoked? >>> project.el could then consult that variable first, then fallback to >>> default-directory? >> >> Perhaps. I don't know if that would be enough for Eli's purposes, however. > > It will solve some of them, to be sure. Solve them how? Do you always invoke that search command from a buffer belonging to the original project? 75% of the time? 30%? >> After all, in the Grep example, it could have been invoked from one of >> the buffers belonging to the current project, or just as well from an >> "outside" buffer (because, for example, that made it easier to select >> the intended directory). > > So you are saying that it's better to have no way of supporting that > use case than have some, even restricted, way? No. I even suggested a few ways how this can be user-extensible. And I'm saying we need a coherent design that's in line with what is already there. Or extends the behavior in a predictable way. Going back to Kevin's suggestion, I'm fairly sure it will also generate both false positives and false negatives, going simply by my own usage habits: the originating buffer of where I'm calling a command doesn't necessarily correspond to which project I'm thinking of right now. So I'm not sure if we can do this for the default behavior. Hence we'd need to use either one of the existing customization point, or add a new one.