bug#37179: 27.0.50; tabulated-list-mode creates obsolete empty line on the end

[Stefan Kangas]

Jean Louis <bugs@gnu.support> writes:

> Here is sample demonstration:
>
> (define-derived-mode my-mode tabulated-list-mode "My Mode" "My mode"
>   (setq tabulated-list-format [("ID" 5 t . (:right-align t))
>                                ("Hyperlink" 30 t)
>                                ("Type" 10 t)])
>   (setq tabulated-list-padding 1)
>   (setq tabulated-list-sort-key (cons "ID" nil))
>   (tabulated-list-init-header))
>
> (defun my-set-list (&optional parent)
>   (interactive)
>   (let ((buffer "*Hyperspace*"))
>     (pop-to-buffer buffer nil)
>     (read-only-mode 0)
>     (erase-buffer)
>     (read-only-mode 1)
>     (my-mode)
>     (hl-line-mode)
>     (setq tabulated-list-entries (list
>                                 (list "1" ["1" "Link 1" "Type"])
>                                 (list "2" ["2" "Link 2" "Type"])))
>     (tabulated-list-print t)))
>
> When it is defined the M-x my-set-list allows me to go after the last
> line. Yet that is not logical, and empty line shall not be displayed, as
> it does not exist in the tabulated-list-entries variable.
>
> Video demonstration 1MB:
> https://gnu.support/images/2019/08/2019-08-25/2019-08-25-11:15:46.ogv

I tend to agree; there doesn't seem to be any point to go to a line
after the last entry.

But this issue is not unique to tabulated-list-mode, and in fact crops
up in all kinds of places in Emacs.  IME, the usual solution is to just
leave the final newline, and maybe there are good reasons for that.  See
Dired for example, or Gnus.

As an experiment, I came up with the attached patch that removes the
final newline in `tabulated-list-mode'.  As expected, it is not without
issues: `end-of-buffer' leaves point at the end of last line.  If that
line is very long, we can end up scrolled far to the right, which is
rather unsettling.  Another thing that may or may not be problematic (I
didn't test it) is if we have commands that operate on regions of lines.

So I'm not exactly sure what to do here.  Perhaps we should just leave
it alone...  Or maybe there is some smart solution just waiting to be
discovered.

Does anyone else have any comments?

37179.diff
Description: Text Data