From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id aBfIDTrevmT2ewEASxT56A (envelope-from ) for ; Mon, 24 Jul 2023 22:25:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 6A+qDTrevmTu+AAA9RJhRA (envelope-from ) for ; Mon, 24 Jul 2023 22:25:30 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AA6A93D789 for ; Mon, 24 Jul 2023 22:25:29 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=vodafonemail.de header.s=vfde-mb-mr2-21dec header.b=c3srmh+Z; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=quarantine) header.from=vodafonemail.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1690230330; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=bGmDL0LzrNmq9bMDAwcZ4fgupAwh4hJYDwBhpkEfC/M=; b=fmVyMl0Lwns08mUipLnJde2ixjn/p7XATTm6fZui5XTlygUS0FRF3xTCdw/ohnklvSl8i9 6s4u9pQfHtpY/TXfajoOKSn92wfPA5pmQk8F/M67zB66+D05834hT+wkTvF3kNNvvcw81T tFcbRzFWoOy3eoaJ+Ol7KOoneYkisKSnhl2EfpeszE/Ntkn9ZlgoxSjviNkJ5P0IhcpqgK NoN4156X1KjbCrv9zCJItIOKm2szX12nB7hqY4MBh8XZu5O2G2vN9m30KMRCDl4qBnxuo/ sjfmyHQYbvRrhJtu6bb37rwWQ1GT23QCy4Z/TKu6iehbELU7/FrenTc7jeHSng== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1690230330; a=rsa-sha256; cv=none; b=k3rZML+ARQ/9AQAciaYCsRs35c3o19HT2f6C/bSWJltZNLm1CwA2CN0dc0vt9oDuzYxIrk p30UVv99li6isq6AVOAgjzZthcyJJq5jQsZfRpuV3VuBEKE45tpVLfi7S36HuEY53CtCpz E7cEND/9qr42/DCRVtfWTbxUs9Fcmy8US/9fs8oYvoTTAd2N53c/rgHi4aqd732sAnERKb foAJT1oJbZA9FQ6wQMULdgOnfd/36AHnCflD5NMWbpAuiB2+X8eJardTBEf7ieJv9tfR4Z GgNG56GFH6zPjs0CPtsr7YWwlUQzBW/Knmeey6v5o32Ss5/GhiU3GThuR802sQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=vodafonemail.de header.s=vfde-mb-mr2-21dec header.b=c3srmh+Z; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=quarantine) header.from=vodafonemail.de Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qO26X-0000wl-Kp; Mon, 24 Jul 2023 16:24:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qO26W-0000wa-0T for emacs-orgmode@gnu.org; Mon, 24 Jul 2023 16:24:28 -0400 Received: from mr5.vodafonemail.de ([145.253.228.165]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qO26S-0007lC-QX for emacs-orgmode@gnu.org; Mon, 24 Jul 2023 16:24:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vodafonemail.de; s=vfde-mb-mr2-21dec; t=1690230258; bh=bGmDL0LzrNmq9bMDAwcZ4fgupAwh4hJYDwBhpkEfC/M=; h=Message-ID:Date:User-Agent:Subject:From:To:References: Content-Language:In-Reply-To:Content-Type:From; b=c3srmh+Zsy8jJwjDbkeMR5t3bbcFb3iAtRo9k9nly1YU3ez1dkFLwF1jvAWpmu/YO 4wrsnnZs/lVHX7tGSl6HYtKae16XX1b60i5OJYdOaV66tDEDfCrLcavyz0hNNzuFcA +WV6TvDn8QaNggr5ztx+vuSdMHbxIMcm19XibRtc= Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr5.vodafonemail.de (Postfix) with ESMTPS id 4R8s820c8wz1yHm; Mon, 24 Jul 2023 20:24:18 +0000 (UTC) Received: from [192.168.178.41] (port-92-194-244-77.dynamic.as20676.net [92.194.244.77]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4R8s7q5370zKm4Y; Mon, 24 Jul 2023 20:24:04 +0000 (UTC) Message-ID: <6aa47402-1546-272b-2859-4cfed1ea9ceb@vodafonemail.de> Date: Mon, 24 Jul 2023 22:23:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [BUG] Issues in ol-gnus when storing links in nnvirtual and nnselect articles [9.7-pre (release_9.6.7-570-gd6f3ae.dirty @ /home/jschmidt/work/org-mode/lisp/)] From: Jens Schmidt To: Ihor Radchenko References: <2fa5914d-2cbf-f41f-8be6-e79e77794140@vodafonemail.de> <87y1j8rrag.fsf@localhost> <1b9fbe38-0572-7861-e433-8f26457302bb@vodafonemail.de> Content-Language: de-DE-frami, en-US Cc: Eric Abrahamsen , emacs-orgmode@gnu.org In-Reply-To: <1b9fbe38-0572-7861-e433-8f26457302bb@vodafonemail.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-purgate-type: clean X-purgate: clean X-purgate-size: 3265 X-purgate-ID: 155817::1690230253-9F7B9106-B89954B4/0/0 Received-SPF: pass client-ip=145.253.228.165; envelope-from=jschmidt4gnu@vodafonemail.de; helo=mr5.vodafonemail.de X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx2.migadu.com X-Migadu-Spam-Score: -9.71 X-Spam-Score: -9.71 X-Migadu-Queue-Id: AA6A93D789 X-TUID: RbKD4TKHPrgy Uh, I had technical issues and did not get all mails as I expected. Cobbling things together in one big reply now, with references and quotes hopelessly broken ... hope you can sort it out. Anyway, thanks to Eric for chiming in. > Ideally, it would be nice to have tests, though I have no clue how to > approach writing them. I have created a somewhat minimal Gnus setup to develop and test this patch on my development laptop, where I normally do not use Gnus. It consists of a bunch of files and directories and a bit of configuration. I can follow up on this if you like, but preferably in a separate thread. >> If we're currently in article-mode. The call to >> `gnus-article-show-summary' would protect against the case where the >> summary buffer has been killed in the meantime [...]. Not really. The following executed in an article buffer: (progn (kill-buffer gnus-summary-buffer) (gnus-article-show-summary)) results in Debugger entered--Lisp error: (error "There is no summary buffer for this article buffer") signal(error ("There is no summary buffer for this article buffer")) error("There is no summary buffer for this article buffer") gnus-article-show-summary() [...] Which, OTOH, shows that I was wrong in one aspect: Gnus at least in some cases *does* give a reasonable error message when the summary buffer for an article buffer is gone. >> Probably it would be enough to wrap the whole containing `let*' in a >> (with-current-buffer gnus-summary-buffer ...). If we're already in the >> summary buffer, no harm done. > > I am not sure if it is safe. > There is > (save-window-excursion (gnus-summary-select-article)) > which calls (set-buffer gnus-summary-buffer) I agree with Ihor here and would rather go for individual wraps into `with-current-buffer'. As I have done in my patch already, incidentially. >> Ugh, this whole thing is a mess. I think the first question is: should >> this function "fix" the state of Gnus before it makes a link? Should it >> attempt to re-open the Summary buffer if it's been closed? Should it >> switch current articles if the open article buffer is not the one that >> point is on in the Summary buffer? >> >> If we make a decision about that, then it should be easier to decide how >> to handle the code changes themselves. > > ol-gnus should store link for thing at point in current buffer. Ideally, > without side effects. Everything else should be implementation detail. Could we agree on: ol-gnus should store Gnus links with as little effort and side-effect as possible while providing reasonable functionality for the common use cases. I think, again incidentially, that my patch matches this criterion. What optionally could be improved, though, is error handling in these pathological cases. But that would probably require some macro (ol-gnus-with-current-summary-buffer BODY) to have the error handling available in the separate places. Not sure whether this is worth the effort. > Or, at least, it was not sufficient at the time when ol-gnus has been > written (quite a while ago). I don't think this has changed, really.