GNU bug report logs - #44078
26.3; `tabulated-list-mode': Use it in any mode and for part of a buffer

Previous Next

To reply to this bug, email your comments to 44078 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; `tabulated-list-mode': Use it in any mode and for part of a
 buffer
Date: Mon, 19 Oct 2020 09:03:24 -0700 (PDT)

Feature request:

I'd like to see `tabulated-list-mode' be usable for only part of a
buffer.  How?  Dunno.  Text property maybe, analogous to property
`keymap'?

One of its greatest weaknesses is that it's (only) a major mode.  It's
buffer-wide, which means you can't do anything else in the buffer.  You
can't use `tabulated-list-mode' for just some table(s) (tabulated info)
within a buffer.  This greatly limits its usefulness, IMO.

In the beginning, IIRC, there was only the major mode `outline-mode'.
Later we added `outline-minor-mode'.  That at least took care of the
problem of not being able to use it with another major mode.

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.

In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
 of 2019-08-29
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor `Microsoft Corp.', version 10.0.18362
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

Message #10 received at 44078 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 44078 <at> debbugs.gnu.org
Subject: Re: bug#44078: 26.3; `tabulated-list-mode': Use it in any mode and
 for part of a buffer
Date: Tue, 20 Oct 2020 13:35:12 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> 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.

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.

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.

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.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #13 received at 44078 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 44078 <at> debbugs.gnu.org
Subject: RE: 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)

> > 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.
> 
> 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.
> 
> 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.
> 
> 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 
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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.