Jean Louis 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?