From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#44078: 26.3; `tabulated-list-mode': Use it in any mode and for part of a buffer Date: Tue, 20 Oct 2020 09:20:30 -0700 (PDT) Message-ID: <30886403-3940-456d-9d1a-5ced5a7baba6@default> References: <87pn5dgmfj.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22250"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44078@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 20 18:29:50 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kUuWE-0005iA-FZ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Oct 2020 18:29:50 +0200 Original-Received: from localhost ([::1]:47236 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUuWD-0006zm-HG for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 20 Oct 2020 12:29:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43784) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUuNk-0003bS-0J for bug-gnu-emacs@gnu.org; Tue, 20 Oct 2020 12:21:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34957) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kUuNi-00072a-JN for bug-gnu-emacs@gnu.org; Tue, 20 Oct 2020 12:21:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kUuNi-0006CA-Ek for bug-gnu-emacs@gnu.org; Tue, 20 Oct 2020 12:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Oct 2020 16:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44078 X-GNU-PR-Package: emacs Original-Received: via spool by 44078-submit@debbugs.gnu.org id=B44078.160321084423767 (code B ref 44078); Tue, 20 Oct 2020 16:21:02 +0000 Original-Received: (at 44078) by debbugs.gnu.org; 20 Oct 2020 16:20:44 +0000 Original-Received: from localhost ([127.0.0.1]:46503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kUuNQ-0006BF-0S for submit@debbugs.gnu.org; Tue, 20 Oct 2020 12:20:44 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:52220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kUuNN-0006B3-Ms for 44078@debbugs.gnu.org; Tue, 20 Oct 2020 12:20:42 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09KGIn9I146211; Tue, 20 Oct 2020 16:20:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=Q01s3CJ1I79AkvYMm3KdOYj7xIl3+QrPkC4PZ101i4E=; b=O2nxvE+rLVIw+SoVj0gcXnivNg/95XaaM75HAiYXxEC3ZJ4RHH2RQ/Bq6bR3yD9o44G+ q9UBzF82SvDt6Um02c15iVhCwLwPUIjoTDfwTfnowlma3dWnGq0rQyTnx+q1ASwfHQm5 c/v3Y6Ct4nPZ/4MnJJEIfEXwLKjOLjhbtK85IHRUWzy02FrOcuIXVQt4qlD/wbjQRiFB HLnFhH9xBYIBnLP5YOe8v9/ctVKqUjT6tthmVKQGTedHWKF7yD9F3/MzUlJZCXEaUj3M CO1WVXd+1sXNb7CZQHkwMFKT6EW12Sqo7TYnYfglPkLlGl8EnpX5KjJZE8/zrJhUwPQE uA== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 349jrpm6sn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 20 Oct 2020 16:20:34 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09KGEu2L069795; Tue, 20 Oct 2020 16:20:34 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 348ahwfhf2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 20 Oct 2020 16:20:33 +0000 Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 09KGKVha030724; Tue, 20 Oct 2020 16:20:32 GMT In-Reply-To: <87pn5dgmfj.fsf@gnus.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5056.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9779 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010200109 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9779 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 adultscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 spamscore=0 suspectscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010200109 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:191107 Archived-At: > > But for `tabulated-list-mode' I think we need more than just to add a > > minor-mode version. We really need a way to confine its effect to a > > part of a buffer. >=20 > Whenever I've done some work on tabulated-list-mode, I've been kinda > frustrated by its design. You'd ideally just be able to have a > functional interface where you just call a function with all the data > (and some commands to apply to the data), and then everything would > work. But instead it's a strange mixture of functional, buffer-local > data and updating functions. >=20 > A side effect of this is that the table isn't an "object" you can do > operations on -- there can only be one table per buffer, and it wants to > control the entire buffer. >=20 > So I'd welcome a more functional rewrite of tabulated-list-mode that > would constrain all actions to the area of the buffer where the table > is, and leave the rest of the buffer alone. And stash the table data in > the table instead of using the buffer-local variables. I agree with all that you say. And this is a great summary of my feelings about the failings of t-m-mode: there can only be one table per buffer, and it wants to control the entire buffer I don't expect this enhancement request to get traction anytime soon. And in fact I think that ultimately this is related to the real need for some kind of reasonable, robust, multiple-major-modes feature. That might not be the best name, and there are multiple ways to envision such things. But wrt this request, I'm thinking of an ability to, in the same buffer, have tables that are governed by something like t-m-mode, but without impacting the buffer mode in general or at least other parts of the buffer. The key-bindings part could likely be dealt with using a `keymap' text property. But t-m-mode is a major mode so far, and there are its local variables to be dealt with (and a mode hook, and maybe other buffer-related=20 stuff). Variables with values specific to a given span of text, i.e., realized via text properties, might be a way to deal with some of this. Dunno, and dunno how that might be realized. Just thinking out loud. I'm sure that others, who've spent a lot of time trying to think about multiple major modes, have a much better view of the obstacles and possibilities in this regard. It just seems to me that making t-m-mode a major mode is a mistake. You can't even add any additional text to the buffer, outside the table - not even a heading. It just kind of takes over a buffer, and that's quite limiting.