bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Boruch Baum]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]


----- Forwarded message from Boruch Baum <boruch_baum@gmx.com> -----

Date: Mon, 11 Jun 2018 14:06:41 -0400
From: Boruch Baum <boruch_baum@gmx.com>
To: Emacs-Devel List <emacs-devel@gnu.org>
Cc: Chong Yidong <cyd@stupidchicken.com>
Subject: tabulated-list-resize-current-column
User-Agent: NeoMutt/20180512

Attached is a proposed contribution for the package `tabulated-list.el'.

The idea is to offer to emacs users a feature long-common in GUI
tabulated list widgets - the ability to dynamically resize columns. I
only use emacs in nox, so in my selfishness (and in my ignorance of most
programming things GUI) that's all this function provides, but it's a
start for anyone wanting to extend to that environment.

An obvious follow-up idea is a companion function to change the
sequence of columns, also a long-common feature in GUI environments.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

[-- Attachment #2: tabulated-list-resize-current-column.el --]
[-- Type: text/plain, Size: 890 bytes --]

(defun tabulated-list-resize-current-column (&optional num)
  "Change width of the current column by N columns.

This is a buffer-local change. To permanently change a column's
size, see defcustom `tabulated-list-format'."
  (interactive "N(In/De)crease size of current column by:")
  (let ((col (current-column))
        (total-column-count 0)
        (len (length tabulated-list-format))
	(idx 0) this-column-size found)
   (while (and (not found) (< idx len))
     (if (> col (setq total-column-count
                    (+ total-column-count
                       (setq this-column-size
                         (cadr (aref tabulated-list-format idx))))))
       (setq idx (1+ idx))
      (setf (cadr (aref tabulated-list-format idx)) (max 1 (+ this-column-size num)))
      (setq found t)
      (tabulated-list-init-header)
      (tabulated-list-print)
      (move-to-column col)))))

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Eli Zaretskii]

> Date: Mon, 9 Jul 2018 11:56:11 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> 
> Attached is a proposed contribution for the package `tabulated-list.el'.
> 
> The idea is to offer to emacs users a feature long-common in GUI
> tabulated list widgets - the ability to dynamically resize columns. I
> only use emacs in nox, so in my selfishness (and in my ignorance of most
> programming things GUI) that's all this function provides, but it's a
> start for anyone wanting to extend to that environment.
> 
> An obvious follow-up idea is a companion function to change the
> sequence of columns, also a long-common feature in GUI environments.

Boruch, this patch sits in my queue since the day you first posted
it.  And the reason is that the feature is incomplete, as even you
point out: such features should support dragging by mouse and other
GUI niceties.  It also lacks a NEWS entry.

If you or someone else has time and motivation to make this feature
more complete and add the necessary docs, I will gladly push the
changes.  Otherwise, it will have to wait until I have a rainy day
(which could take a while ;-).

Thanks.

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Boruch Baum]

On 2018-07-09 20:22, Eli Zaretskii wrote:
> > Date: Mon, 9 Jul 2018 11:56:11 -0400
>
> Boruch, this patch sits in my queue since the day you first posted
> it.  And the reason is that the feature is incomplete, as even you
> point out: such features should support dragging by mouse and other
> GUI niceties.  It also lacks a NEWS entry.

Oh. I received no feedback, so I thought maybe posting it to emacs-bugs
would be a better way of eliciting some response.[1]

Why should lack of GUI bells-and-whistles be a "deal-breaker"? Not
everything in emacs has that, and while I can understand a policy to
_urge_ developers to include GUI support, rejecting incremental
improvements just holds the project back.

As for a 'NEWS' entry, I've never written one before, but based upon
what I see, I don't see much to add than:

  ** New function for tabulated lists:
     'tabulated-list-resize-current-column'

> If you or someone else has time and motivation
> ...

For GUI stuff, I'm not a great candidate, but for what I mentioned that

> > An obvious follow-up idea is a companion function to change the
> > sequence of columns, also a long-common feature in GUI environments.

That's likely. My use-case is that I'm preparing a modification for the
emacs-w3m web browser, for which using tabulated-list mode is one
implementation option; however it lacks these features. I would prefer
to code the functionality in a manner that can be used by others in the
emacs-verse; otherwise, they'll get written as functions specific to
emacs-w3m, and frankly that project has way too much of that type of
double-work already.

[1] Did a similar thing happen with my patches for cua-rectangle-mode? I
posted several bug fixes and maybe other stuff, and haven't heard from
anyone else. Wait a minute - the emacs project isn't a one-man show, and
I'm not expecting you to field all its traffic. I'm sure I cc'ed the
maintainers listed in the file's header.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> The idea is to offer to emacs users a feature long-common in GUI
> tabulated list widgets - the ability to dynamically resize columns. I
> only use emacs in nox, so in my selfishness (and in my ignorance of most
> programming things GUI) that's all this function provides, but it's a
> start for anyone wanting to extend to that environment.

The code looks good to me -- Eli points out that it would be great if
you could mode the column sized with a mouse, too, but I think that's
kinda an orthogonal issue.  If somebody were to add a mouse-drag thing
for tabulated mode (and somebody should), then it looks like your
function would perhaps work well as the underlying function for that
command.

So unless anybody objects, I'd like to include this command in
tabulated-list.el (and add documentation, of course).

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

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Drew Adams]

> The code looks good to me -- Eli points out that it would be great if
> you could mode the column sized with a mouse, too, but I think that's
> kinda an orthogonal issue.  If somebody were to add a mouse-drag thing
> for tabulated mode (and somebody should), then it looks like your
> function would perhaps work well as the underlying function for that
> command.
> 
> So unless anybody objects, I'd like to include this command in
> tabulated-list.el (and add documentation, of course).

Yes, this is welcome.  There are a few (relatively minor)
problems with it, which are easily corrected.  The code
below is a bit better, I think.

. The doc string was wrong wrt `tabulated-list-format'
  being a "defcustom" (an option) - it's not.  And that
  var is always buffer-local (as are most things about
  `tabulated-list-mode').  So there's no reason for
  this command's doc to say its change is buffer-local.

. There's a mix of meanings of "column" in the code and
  comments, starting with the main doc-string line:

    "Change width of the current column by N columns."

  It's clearer to use "column" only for either an Emacs
  character/buffer column or a `tabulated-list-mode'
  table column.  In the code below I chose the latter,
  never calling the former a "column".

. It's handier for users for the numeric arg to always
  be provided by the numeric prefix arg (default: 1).
  No prompting, and the command can then be repeated by
  just holding down a key.

. With that change, by default the command widens the
  current column width, and its name can reflect that.
  Increasing by a negative number decreases, as usual.
  A separate command to narrow the column (decrease
  its width) should also be provided, for easy key
  binding.  A user can bind both widen and narrow
  commands to repeatable keys.

. No need to remember the start column.  REMEMBER-POS
  arg to `tabulated-list-print' takes care of that.

(defun tabulated-list-widen-current-column (&optional n)
  "Widen the current tabulated-list column by prefix-arg chars."
  (interactive "p")
  (let ((start        (current-column))
        (nb-cols      (length tabulated-list-format))
        (col-nb       0)
        (total-width  0)
        (found        nil)
        col-width)
    (while (and (not found)  (< col-nb nb-cols))
      (if (> start
             (setq total-width
                   (+ total-width
                      (setq col-width
                            (cadr (aref tabulated-list-format
                                        col-nb))))))
          (setq col-nb  (1+ col-nb))
        (setq found  t)
        (setf (cadr (aref tabulated-list-format col-nb))
              (max 1 (+ col-width n)))
        (tabulated-list-print t)
        (tabulated-list-init-header)))))

(defun tabulated-list-narrow-current-column (&optional n)
  "Narrow the current tabulated list column by N chars.
See `tabulated-list-increase-current-column'."
  (interactive "p")
  (tabulated-list-increase-current-column (- n)))

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Boruch Baum]

On 2019-06-23 19:56, Drew Adams wrote:
> Yes, this is welcome.  There are a few (relatively minor)
> problems with it, which are easily corrected.  The code
> below is a bit better, I think.

I'm okay with all of Drew's modifications. Thanks, Drew.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Drew Adams]

> I'm okay with all of Drew's modifications. Thanks, Drew.

Thanks for doing this, Boruch.

I think mouse manipulation would be a plus, but I don't expect anyone will do that anytime soon.  That might even call for some work at the C level, I'm guessing.

Users can drag Emacs-window borders, for example, but we don't have the kind of thing Eli is suggesting for most other Emacs graphic thingies, such as menu-bar menu names, tool-bar icons, header-line components, and mode-line components (and inline images?).

You can't drag their boundaries to resize them, and you can't drag them (accessing them away from the boundaries) across each other to reorder them.

The case for `tabulated-list-mode' column headers is, I imagine, a special case of header-line components.

It would be good, indeed, if Someone(TM) were to add the ability to do such mouse-dragging things at a fairly general level.  I'm not holding my breath, however.

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Lars Ingebrigtsen]

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

> Yes, this is welcome.  There are a few (relatively minor)
> problems with it, which are easily corrected.  The code
> below is a bit better, I think.

Looks good.  I've now added some documentation and then pushed these
changes to the trunk.

Finding the right key pair to bind these one was a struggle, though.
w/n would be natural for widen/narrow, right?  But n is taken.  So I
thought e/s for expand/shrink?  s is taken in *Buffer List* buffers,
which is probably the most prominent use case for the mode.

So I went with w/c for widen/contract, but that's a bit eh...

Bikeshedding is welcome!

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

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Boruch Baum]

On 2019-06-24 16:37, Lars Ingebrigtsen wrote:
> Bikeshedding is welcome!

Challenge accepted! Are the curly braces available? That would have some
consistency with C-x } and C-x {, bound to `enlarge-window-horizontally'
and `shrink-window-horizontally'.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Lars Ingebrigtsen]

Boruch Baum <boruch_baum@gmx.com> writes:

> On 2019-06-24 16:37, Lars Ingebrigtsen wrote:
>> Bikeshedding is welcome!
>
> Challenge accepted! Are the curly braces available? That would have some
> consistency with C-x } and C-x {, bound to `enlarge-window-horizontally'
> and `shrink-window-horizontally'.

Hm...  curly braces are often on weird keyboard combinations on non-US
keyboards, so those aren't idea...

On irc, somebody suggested w/W for widen/narrow, and I guess that's not
bound by any of the major tabulated-list users (like *Buffer List*).

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

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Juri Linkov]

>>> Bikeshedding is welcome!
>>
>> Challenge accepted! Are the curly braces available? That would have some
>> consistency with C-x } and C-x {, bound to `enlarge-window-horizontally'
>> and `shrink-window-horizontally'.
>
> Hm...  curly braces are often on weird keyboard combinations on non-US
> keyboards, so those aren't idea...

{ and } are the most intuitive and easy to remember keys because they are
consistent with C-x { and C-x }.  If on some keyboards they are not
easy to type, then alternative letter-based keys could be added as well.

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> { and } are the most intuitive and easy to remember keys because they are
> consistent with C-x { and C-x }.  If on some keyboards they are not
> easy to type, then alternative letter-based keys could be added as well.

And { and } aren't totally difficult to input on non-US keyboards,
either...  It's usually alt-gr NUM or something equally odd, but that's
just a two-key keystroke, so perhaps that's OK.

Hm...  OK, I've checked with some of the major modes that use tabulated
mode, and none of them seem to have bound those two keys.  I'll make the
change and we'll see what people think.

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

bug#32106: 25.2: tabulated-list-resize-current-column [PATCH INCLUDED]

[Drew Adams]

> Looks good.  I've now added some documentation and then pushed these
> changes to the trunk.
> 
> Finding the right key pair to bind these one was a struggle, though.
> w/n would be natural for widen/narrow, right?  But n is taken.  So I
> thought e/s for expand/shrink?  s is taken in *Buffer List* buffers,
> which is probably the most prominent use case for the mode.
> 
> So I went with w/c for widen/contract, but that's a bit eh...
> 
> Bikeshedding is welcome!

FWIW, I'm not sure these commands should be bound
by default.  `tabulated-list-mode' is a helper mode.
It's used by other modes (user-defined major modes)
to build specific kinds of tables.

Of course, you can say that if we bind, say, `+'
and `-' in `tabulated-list-mode' then a mode that
derives from it can always rebind such keys.  And
`t-l-m' already binds some keys, as does its parent
mode, `special-mode'.

Still, I'm not sure binding more keys in `t-l-m' is
a good idea.  (I don't oppose it; just not convinced.)
In its defense, users can get used to such keys that
then work (by default) across all or most uses of
`t-l-m'.

If you do decide to bind these commands in `t-l-m'
then I'd suggest that the two keys be _obvious_
opposites (so, maybe not `w' and `c').  It's not
important that they be easy to type (e.g., they can
use modifiers), but it's helpful if their keys are
repeatable (by just pressing and holding).

FWIW, I used `+' and `-' for the same purpose in
my library `buff-menu+.el' (which I had to abandon
when `buff-menu.el' moved to use `t-l-m', as `t-l-m'
is too simplistic and rigid for some `buff-menu+.el'
features).