From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id uFbjITqI8WFoQAAAgWs5BA (envelope-from ) for ; Wed, 26 Jan 2022 18:43:22 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id AOjGHjqI8WEcngAAauVa8A (envelope-from ) for ; Wed, 26 Jan 2022 18:43:22 +0100 Received: from mail.notmuchmail.org (yantan.tethera.net [IPv6:2a01:4f9:c011:7a79::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 346D5473E5 for ; Wed, 26 Jan 2022 18:43:22 +0100 (CET) Received: from yantan.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id B69F65F719; Wed, 26 Jan 2022 17:43:18 +0000 (UTC) Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by mail.notmuchmail.org (Postfix) with ESMTPS id 60E515E022 for ; Wed, 26 Jan 2022 17:43:16 +0000 (UTC) Received: from [2001:470:142:3::e] (port=37922 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCmKA-0006BJ-ND for notmuch@notmuchmail.org; Wed, 26 Jan 2022 12:43:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=m62lyjJGELdghtp1RL26phuG3Ul/05VbpcUxDRoVl1Q=; b=eiltUWmQ6h27Uy9H++lE +398spfOaqhc9hqg0D0vJf6mqYrgTgjiFZDzBz2qHGPVorvFoX55ix8X7lmrsXeo+R3oNdI/HQ5h7 oGy8ITo03BviSCgc5DQOoTU2++F3XzgoBGNy8Nvir/LQE2L0WhOvhVNEBgjFsvYoMpIb/HIchj9h3 iLJ2fPxskrX+RYE+FbcajacQwfIOfgoJnMHfg1IxNx0PzFLN+zPvaEAScVKVgJTDRVds7qM2fz8Mu I65GOFrTfpduvJ7iCRC0mb3Bduq0hJm4W3OvojRWgSGHlCSWHhyn0adovboA4hr61wX+49R2rKKOh H0ZIXWzARYKV7w==; Received: from cpc103048-sgyl39-2-0-cust502.18-2.cable.virginm.net ([92.233.85.247]:45002 helo=rivendell.localdomain) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nCmKA-00047h-8X for notmuch@notmuchmail.org; Wed, 26 Jan 2022 12:43:14 -0500 Received: from localhost (rivendell.localdomain [local]) by rivendell.localdomain (OpenSMTPD) with ESMTPA id 3e4e3148 for ; Wed, 26 Jan 2022 17:43:11 +0000 (UTC) From: Jose Antonio Ortega Ruiz To: notmuch@notmuchmail.org Subject: Re: [PATCH] emacs: add global tag history In-Reply-To: <878rv2foky.fsf@wondoo.home.cworth.org> References: <20220126153214.1366353-1-inwit@sindominio.net> <87v8y6a4k2.fsf@tethera.net> <950e8c5ec7ca93f9d21c9c0855971511@sindominio.net> <878rv2foky.fsf@wondoo.home.cworth.org> X-Attribution: jao X-Clacks-Overhead: GNU Terry Pratchett X-URL: Date: Wed, 26 Jan 2022 17:43:11 +0000 Message-ID: <87ee4u9yvk.fsf@gnus.jao.io> MIME-Version: 1.0 Message-ID-Hash: FXHTBHVXRYMRWQFJMH7DPJLKV2AMIBYJ X-Message-ID-Hash: FXHTBHVXRYMRWQFJMH7DPJLKV2AMIBYJ X-MailFrom: jao@gnu.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_IN X-Migadu-Country: DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1643219002; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to: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-owner:list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=sdyhpB3t6cCJKHx0o63OfWEVbjCwCxJ5V8dho4XD1RU=; b=JSc6t4mONGYiJmLs7CAvrj5ArxIMlDt5hdZ5pT7UiR4ciQGIbN98hon8wgzd+A0RU4RGh7 aEjYOZsyt+D1Ml4r7vA/eTLMRm6N11+QAxZwXoLX4wVKZ8t8Ekn7jVAf/AH/gQR3s291iK uVx+tgKABub4n5QVERPW2p1199cvAtUDHjlb4v/3zJyHuJ8xbGws+ISsblS30IKX2mwdIn Okq7D0GsZIGNLkkVA/EIFSAKDiH0sXK1KpBsItynorU8ybD2Ljwrph6Z2mB6IlJ8AbxM+N y/stmJ6Qi4taDYeWwf3Q09Q8zRNpdetJAboJTeKABiqJS7e6MSYEg5QM/93GWw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1643219002; a=rsa-sha256; cv=none; b=m9YEfLuxCe3sa+z8IkZi+3hh4jqlcuZgqmnAjAIgY4oOubqi4TECEbRdocNk1MPrwCaqab T4LonjIojJkpZvBobRYcDcFFbncUqom94u5B7v4LApOkwFh/qN5tE8f+iCrSGazohIt3xP 9O3cKyuFaXN/oWPNwQrVpMYq2Z+1CaKGQRiljFIpS8B9QCVt1msJRZ7P7FOJpUoX1qD++A 3fceoftqDb2m98gqF6jCNyIvQR/QlQ69/XQebDdtruLQnQIYNsDKRVDU4ATX416yYw0GCN md4GSjLeTLtpUj6NOvCmR39qEeFSBUL12PbuOknwJSh5gV3nITKfSkrBaDQ+Cg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=gnu.org header.s=fencepost-gnu-org header.b=eiltUWmQ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gnu.org (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2a01:4f9:c011:7a79::1 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: -1.64 Authentication-Results: aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=gnu.org header.s=fencepost-gnu-org header.b=eiltUWmQ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gnu.org (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2a01:4f9:c011:7a79::1 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: 346D5473E5 X-Spam-Score: -1.64 X-Migadu-Scanner: scn1.migadu.com X-TUID: 8LJW2JTXYREF On Wed, Jan 26 2022, Carl Worth wrote: > On Wed, Jan 26 2022, inwit wrote: >>> Even that will not be perfect (since the messages matching the query >>> could change behind emacs back), but close enough for most interactive >>> use, maybe? >> >> I was thinking about saving the IDs of the messages affected by the >> change, but I still don't know how would I go about that or if it's >> sensible. > > One could imagine a history that would enable a conventional undo stack > for a notmuch interface. The trick with making that usable would be the > need to refresh views to make what was undone evident, (and the fact > that some of the operations could be large/slow). > > All of those issues kept me from pursuing the idea in early days of > coding up the emacs notmuch UI. But someone could certainly explore the > implementation further if desired. maybe this could be a buffer-local history variable, for notmuch search and tree search buffers, and the undo feature apply only to the current search buffer. the view update is then well-defined, i think, if it's just changing tags, at least, and per-buffer operation is the normal behaviour of undo/redo in emacs. hooking that up with the regular emacs undo/redo mechanism would be great (in my book at least), but i've never looked at that, so not sure if it's possible. cheers, jao -- Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great. - Mark Twain