From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Use vtable for eww-bookmarks Date: Sun, 1 Dec 2024 00:39:33 -0600 Message-ID: References: <87ldx0vufd.fsf@sebasmonia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18721"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org, jporterbugs@gmail.com To: sebastian@sebasmonia.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 01 07:40:46 2024 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 1tHddN-0004ge-ML for ged-emacs-devel@m.gmane-mx.org; Sun, 01 Dec 2024 07:40:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tHdcN-0008NG-6G; Sun, 01 Dec 2024 01:39:43 -0500 Original-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 1tHdcL-0008N2-Oh for emacs-devel@gnu.org; Sun, 01 Dec 2024 01:39:41 -0500 Original-Received: from iguana.tulip.relay.mailchannels.net ([23.83.218.253]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tHdcI-0001P6-QE for emacs-devel@gnu.org; Sun, 01 Dec 2024 01:39:40 -0500 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7D8D0A231A; Sun, 1 Dec 2024 06:39:35 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a231.dreamhost.com (100-118-20-208.trex-nlb.outbound.svc.cluster.local [100.118.20.208]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 24F21A21D0; Sun, 1 Dec 2024 06:39:35 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1733035175; a=rsa-sha256; cv=none; b=Fp+RG/d06tSEBeK+66CcE26tFepqxhlmvHcYqdBhTMtfx7CBScxf14CmUuTmom5HGcn0wz mOIe2qzXk5nT5N6ceRFLSRGek/g3on9fAa40g+KyW3KVQrLiN23dpgBie0kImj8QoXosBa SRcrT1wHqLGFnanQtMMTR5bGH9yDdhSOIN6QhfnaSwXvtzlTiBScO/QatxJBFNJTgQfEY9 6R3oSAaVTtV2cZDx3OahHIgh3Trl5sJ3WIhvBDCdkayV05GRtYzQ1F5eZTTFLkKt5Pd5l9 8ZO8vWrwVbOlpfQ2kPrtDTpdMVD9va/vbvl11ZXP0jdEDVPikgijsAXnRnD/ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1733035175; h=from:from: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:dkim-signature; bh=DjV0hd4Cl3CRdleFIA0Ng0O9xD8Ehy0gdcpJw2OItgU=; b=CDh/J+gJk0CrSK3hLyhPtjU+UQ3D7QxPrbbhjhYKOmwwNU/clbaaFphIbaNcqWba5oc0M3 euCd9s4f7JXthIQZasaX09WoV85o3TSovOh+HfGMBcSIZgHvnpYbP0gaqQQRX4Lea2bCXp RaMAT0vzeqmLXv6WCj22CGCjER4uSp/hwZFZ9VeWmNX2FfjjyxqemwkkNlo3BJpc03Z/0x hgf9wW2ctC82QKfHdiK90hcaL4v/MT2l+oaCGHztz/sFWYb/wIp72mwj17bNgOKAzMOOkY Yuz+Fz5ku/Z9QVHAkrNwGawgTdIvW723q0mvQkSSx/U45TepslRjSIdfbjth8w== ARC-Authentication-Results: i=1; rspamd-5d9d86ff64-qg6g8; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Reaction-Bubble: 55f204b17ff48ca0_1733035175374_809703124 X-MC-Loop-Signature: 1733035175374:3329265368 X-MC-Ingress-Time: 1733035175374 Original-Received: from pdx1-sub0-mail-a231.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.118.20.208 (trex/7.0.2); Sun, 01 Dec 2024 06:39:35 +0000 Original-Received: from [10.17.80.5] (unknown [172.98.33.7]) (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) (Authenticated sender: adam@alphapapa.net) by pdx1-sub0-mail-a231.dreamhost.com (Postfix) with ESMTPSA id 4Y1HMV4gxnz6f; Sat, 30 Nov 2024 22:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1733035175; bh=DjV0hd4Cl3CRdleFIA0Ng0O9xD8Ehy0gdcpJw2OItgU=; h=Date:To:Cc:Subject:From:Content-Type:Content-Transfer-Encoding; b=WOFCW9oKvVyKQEJgUbyD4JxkGqcURZgaMljwcKeXW8mEPaSaUW+BEpmrGUP+rO99A r5Y7wKF19AtLj+deWBOVE9YkQ/5xzF+Lsz+alPM1mIhaoNYLFCcyEiHc5jCrxrAmWp vuu+dgQkRLl7BdNPToheC7HwXNhSHk8a1BxGTqakgccHqqa2x/bUnOqVdlpEkkKdN/ ugdWA6EHICjB334tGgZ/CPx+PmBgQlylAObCEg0CDppir7wxNUFtxvAQkcoJxGkfNX Z8KDZVJn9xCZebPPakaryrUeTdUJ2z/4tnrWs7FeLCRYkCms3HRQKNHVJ+bZVhJpMF gSWPUSvjcx40Q== Content-Language: en-US In-Reply-To: <87ldx0vufd.fsf@sebasmonia.com> Received-SPF: neutral client-ip=23.83.218.253; envelope-from=adam@alphapapa.net; helo=iguana.tulip.relay.mailchannels.net X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325904 Archived-At: > Jim Porter writes: >> Given that, let's go with your implementation, though I do have one >> last concern with the "undo sort": the keybinding ("u") is the same as >> what other table-like modes (e.g. dired, list-packages) use for >> "unmark". Currently we don't support marking/unmarking in the >> bookmarks menu, but that seems like a useful thing we might add one >> day: you could mark several bookmarks in order to open them all, >> delete them all, add some kind of tag to them, etc. > > This is a good idea. > >> I'm not sure what a better key would be though. Maybe "C" for "clear sort"? > > Attached a patch that uses "c" ("c", not "C") and renames the function > to match. > Let me know what you think! Given how many similar modes and buffers that are in Emacs (i.e. where some kind of objects are displayed in a list with metadata), I think it would be best if any new such feature followed existing paradigms as closely as possible. To have each vtable-like view (whether implemented with vtable or tabulated-list or anything else) have slightly different concepts and bindings is not helpful to the user. So I'd suggest a reconsideration of the concept of sorting: There is no such thing as "clearing" the sorting, because the entries are always sorted by something, even if that's just the order in which the bookmarks are present in the list (which is probably the order in which they were created, or the inverse). As an example, consider Dired: there is no "clearing" of sorting options in Dired, but there is dired-sort-toggle-or-edit: it toggles between sorting by date and sorting by the default (i.e. alphabetically). In this case, the vtable-map already binds vtable-sort-by-current-column. So it seems like what we need is a column by which to sort entries by default. That would seem to leave us with two options: a) Sort by bookmark name by default b) Add a column for the bookmarks' place in the list, and sort by that by default. Then the user could simply sort by one column or the other, without needing to add the additional concept of "clearing" the sorting (a concept that's not generally present in such views in other GUIs, anyway--usually a table view is always sorted by one column or another). And with that, the existing binding of vtable-sort-by-current-column would suffice, eliminating the need for another sort-related binding. What do you think? :) BTW, instead of doing: + (while (not (equal (vtable-current-object) + bookmark-at-point)) + (forward-line 1)))) Could you use vtable-goto-object? I realize that it currently uses EQ for comparison, but 1) we've talked about changing that, and 2) ISTM that EQ should work for this case anyway, because entries in the bookmark list are being compared, and they shouldn't be getting copied. Am I missing something? Thanks, Adam