From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: RFC: Automatic setup for bug-reference-mode Date: Sun, 14 Jun 2020 15:56:27 +0100 Message-ID: <87k109vgpw.fsf@tcd.ie> References: <87r1uihtsu.fsf@gnu.org> <87blllx2t6.fsf@tcd.ie> <875zbt24br.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="79438"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 14 16:57:09 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 1jkU4K-000KXt-PM for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Jun 2020 16:57:08 +0200 Original-Received: from localhost ([::1]:54346 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jkU4J-00005h-RV for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Jun 2020 10:57:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34930) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jkU3m-000854-Qe for emacs-devel@gnu.org; Sun, 14 Jun 2020 10:56:35 -0400 Original-Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:39686) by eggs.gnu.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jkU3k-0001hd-Ol for emacs-devel@gnu.org; Sun, 14 Jun 2020 10:56:34 -0400 Original-Received: by mail-wm1-x330.google.com with SMTP id o8so2716574wmh.4 for ; Sun, 14 Jun 2020 07:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Sar2H5MWq3urWcB9W2WVb4pNrr4wJmoQxX+egFcaAn4=; b=a5FnFH5Cl2yW/cFRRMn6fL5z0Zp7T2i9z3WsyfL03k+RFI44Sh1niL53g954doequI HKnovSJX361FxVZ+kimJvhfJYGdO8+Vo+CJMCcpkDLlirI1nStX2CRDYfcRlchp+Nj06 z0Iss6WuUsu4xiZmS+Q6srRN/NikvTzMJzRzXjSLZYP5lFpqisOs8xPycv8dwpm1MFr9 5R4UI4TiPyO2ggfXhqTtrno+Zg66zVrZPMvzkvkkoserX9AwL4AgN96xJ6/qSl1AS9Tn JgaZeC+5sTVGBxmhrjefc8ksnELbxQa2Hf1PygyYKwjXvFFs/9iMmDmL39m1yeaw8DVE 9Pxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Sar2H5MWq3urWcB9W2WVb4pNrr4wJmoQxX+egFcaAn4=; b=LnkQDHMv18F2AnCKw78v1eYRMDUtdpcfqlrN1CbQV5eoKDAMPFWFYx9Y9qVoLtTLqo 5vBBYuiVgJUsYk0TEOQdfNDJE07Ezp5hY+bzVz3Zcjz+FBTsh8WMPt62dJ5ntYajROrH tHUWxiMvBQvwvvJt2PR/+JMCg4p4wjOvdEUl1ImOzy9qN+Pkx7/zACWO1pu+uzJQUO4X FVidX3zxHnaYnYova40MFo+N5clbZ9qMpWYduKuBaPwrv56VHruWzbtSGf9MfVwK/Ekg 3Hz+dyGizTVf0mpABrWAGv0SIS3tXdsvs6DUMYnRODwyMgfi13HUIs6YlpIgOLCWU4Sj povg== X-Gm-Message-State: AOAM532mBgBn4ILCFKWfvMfkwZF1s6mo8tOKYjXKyoURg3BM4w3xrbkS JuoJX7wse0MUU9Y2a4l9ShdkUprEHkwVng== X-Google-Smtp-Source: ABdhPJwEyak/VJAH7KPHzoaRBuIMcWtJy3PEUCMJjdWeye1JfpeJk2X/YHgI6A/tSJr7v6mEKCcq8w== X-Received: by 2002:a1c:4009:: with SMTP id n9mr8748937wma.104.1592146589324; Sun, 14 Jun 2020 07:56:29 -0700 (PDT) Original-Received: from localhost ([2a02:8084:20e2:c380:92bd:1bfd:38fc:fae2]) by smtp.gmail.com with ESMTPSA id 88sm21783065wre.45.2020.06.14.07.56.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2020 07:56:28 -0700 (PDT) In-Reply-To: <875zbt24br.fsf@gnu.org> (Tassilo Horn's message of "Sun, 14 Jun 2020 14:56:56 +0200") Received-SPF: none client-ip=2a00:1450:4864:20::330; envelope-from=contovob@tcd.ie; helo=mail-wm1-x330.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: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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:252232 Archived-At: Tassilo Horn writes: > "Basil L. Contovounesios" writes: > >>> + (url (pcase backend >>> + ('Git (string-trim >> >> This needs (eval-when-compile (require 'subr-x)). > > Or simply remove the "p" from "pcase", I guess. I was referring to your use of string-trim. >>> + (shell-command-to-string >>> + "git ls-remote --get-url")))))) >> >> Doesn't VC provide a robust way to get output from Git? > > vc-git--call maybe? Perhaps; I'm not that familiar with VC. >>> + (cl-flet ((maybe-set (url-rx bug-rx bug-url-fmt) >>> + (when (string-match url-rx url) >>> + (setq bug-reference-bug-regexp bug-rx) >>> + (setq bug-reference-url-format >>> + (if (functionp bug-url-fmt) >>> + (funcall bug-url-fmt) >>> + bug-url-fmt))))) >>> + (when (and url >>> + ;; If there's a space in the url, it's propably an >>> + ;; error message. >>> + (not (string-match-p "[[:space:]]" url))) >>> + (or >>> + ;; GNU projects on savannah. FIXME: Only a fraction of >>> + ;; them uses debbugs. >>> + (maybe-set "git\\.\\(sv\\|savannah\\)\\.gnu\\.org:" >> ^^^ >> Nit: Can this be a shy group? > > Yes. Is is generally better to use shy groups if we aren't going to do > anything with the groups anyway? Yes, for the negligible potential performance gain, so that there's one less group number taken, and more importantly so the reader isn't left wondering why we're capturing this. Personally, I often just go with what rx does, either by writing rx forms directly or by manually copying its expansion into the program, as that way I'm less likely to make a mistake. >>> ;;;###autoload >>> -(defun vc-responsible-backend (file) >>> +(defun vc-responsible-backend (file &optional no-error) >>> "Return the name of a backend system that is responsible for FILE. >>> >>> If FILE is already registered, return the >>> @@ -967,7 +967,10 @@ vc-responsible-backend >>> >>> Note that if FILE is a symbolic link, it will not be resolved -- >>> the responsible backend system for the symbolic link itself will >>> -be reported." >>> +be reported. >>> + >>> +If NO-ERROR is nil, signal an error that no VC backend is >>> +responsible for the given file." >>> (or (and (not (file-directory-p file)) (vc-backend file)) >>> (catch 'found >>> ;; First try: find a responsible backend. If this is for registration, >> >> NO-ERROR seems to be a no-op in this patch. > > Indeed. Obviously it should have done what the docstring says. > >> Instead of changing the function's arglist, would it be any worse to >> do the following? >> >> (ignore-errors (vc-responsible-backend ...)) > > IMHO, that it errors if no backend is found is the actual error but we > cannot change that anymore. And to me "what backend would this file > use" is a very common question. Even vc.el itself encodes that (dolist > (backend vc-handled-backends) ...) form again in > `vc-backend-for-registration' in order not to trigger the error > semantics of `vc-responsible-backend'. > > But that's not important to me. I can also leave it as it is. FWIW I'm happy with the optional argument you suggest. > PS: I like your style of suggesting improvements using questions which > all have a positive answer. Did you visit a lecture of Stefan? ;-) No, but I wish. ;) Thanks, -- Basil