unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#53520: [PATCH] tabulated-list gradually truncate image
@ 2022-01-25  9:08 Thuna
  2022-01-25 13:36 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Thuna @ 2022-01-25  9:08 UTC (permalink / raw)
  To: 53520

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


Previously images were displayed as is which would potentially cause
misalignment if the column width were less than the image width.  Image
is now cropped width-wise to fit the column width.  This patch, however,
does not affect the height of the image.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-tabulated-list-gradually-collapse-images.patch --]
[-- Type: text/x-diff, Size: 908 bytes --]

diff --git a/lisp/emacs-lisp/tabulated-list.el b/lisp/emacs-lisp/tabulated-list.el
index 2ace7ebb35..b964dd56e9 100644
--- a/lisp/emacs-lisp/tabulated-list.el
+++ b/lisp/emacs-lisp/tabulated-list.el
@@ -577,7 +577,11 @@ tabulated-list-print-col
                      (propertize label 'help-echo help-echo))))
           ((eq (car col-desc) 'image)
            (insert (propertize " "
-                               'display col-desc
+                               'display `(,col-desc
+                                          (slice 0.0 0.0
+                                                 ,(* (frame-char-width)
+                                                     available-space)
+                                                 1.0))
                                'help-echo help-echo)))
           ((apply 'insert-text-button label (cdr col-desc))))
     (let ((next-x (+ x pad-right width)))

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* bug#53520: [PATCH] tabulated-list gradually truncate image
  2022-01-25  9:08 bug#53520: [PATCH] tabulated-list gradually truncate image Thuna
@ 2022-01-25 13:36 ` Lars Ingebrigtsen
  2022-01-25 14:02   ` Thuna
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-25 13:36 UTC (permalink / raw)
  To: Thuna; +Cc: 53520

Thuna <thuna.cing@gmail.com> writes:

> Previously images were displayed as is which would potentially cause
> misalignment if the column width were less than the image width.  Image
> is now cropped width-wise to fit the column width.  This patch, however,
> does not affect the height of the image.

[...]

> +                                          (slice 0.0 0.0
> +                                                 ,(* (frame-char-width)
> +                                                     available-space)

I think it a tabulated-list caller wants to insert images into the
table, they should ensure that the width of the image is appropriate for
the column.  And as you say, this only chops off the parts of the
image -- I think it's more likely that a caller would want to set the
width with :max-width or the like.

So I don't think this makes all that much sense as a feature.

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#53520: [PATCH] tabulated-list gradually truncate image
  2022-01-25 13:36 ` Lars Ingebrigtsen
@ 2022-01-25 14:02   ` Thuna
  2022-01-25 14:37     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Thuna @ 2022-01-25 14:02 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 53520


> I think it a tabulated-list caller wants to insert images into the
> table, they should ensure that the width of the image is appropriate for
> the column.

Considering the width of a column can be changed arbitrarily by the user
is it not expected for tabulated-list to handle images in a way that
works for all widths?

> And as you say, this only chops off the parts of the image -- I think
> it's more likely that a caller would want to set the width with
> :max-width or the like.

I do not wholly disagree that the current strategy of slicing the image
may not be the ideal solution for all situations, however is it not
better to handle images even if done poorly (which I would argue is not
the case) than it is to not handle them altogether?

Other methods of (yet unimplemented) resizing an image include scaling
it down and hiding it when it doesn't fit.  All of these methods have
their use cases and it should be relatively simple to introduce a
variable that controls which one is used.






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#53520: [PATCH] tabulated-list gradually truncate image
  2022-01-25 14:02   ` Thuna
@ 2022-01-25 14:37     ` Lars Ingebrigtsen
  2022-01-25 16:04       ` Thuna
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-25 14:37 UTC (permalink / raw)
  To: Thuna; +Cc: 53520

Thuna <thuna.cing@gmail.com> writes:

> I do not wholly disagree that the current strategy of slicing the image
> may not be the ideal solution for all situations, however is it not
> better to handle images even if done poorly (which I would argue is not
> the case) than it is to not handle them altogether?
>
> Other methods of (yet unimplemented) resizing an image include scaling
> it down and hiding it when it doesn't fit.  All of these methods have
> their use cases and it should be relatively simple to introduce a
> variable that controls which one is used.

I think you're trying to use the mode for things it's not really suited
for, and adding things like this will only be half measures.  There's a
lot of things the package using the mode could want to have done with
the contents of the table, and modes can advise tabulated-list-print to
do these transforms if they want to.

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#53520: [PATCH] tabulated-list gradually truncate image
  2022-01-25 14:37     ` Lars Ingebrigtsen
@ 2022-01-25 16:04       ` Thuna
  2022-01-26 13:11         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Thuna @ 2022-01-25 16:04 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 53520


> I think you're trying to use the mode for things it's not really
> suited for, and adding things like this will only be half measures.

A clarification on what exactly is expected of tabulated-list-mode with
regards to the current issue and how it fails to (in an unamendable way)
fulfill those expectations would be appreciated.

---

> There's a lot of things the package using the mode could want to have
> done with the contents of the table,

Image resizing can be handled the same way `tabulated-list-printer' is
currently handled; as a variable that points to a function, whose
built-in value supports most common needs.  That would solve the issue
of packages being incapable of controlling the process.

> and modes can advise tabulated-list-print to do these transforms if
> they want to.

As it stands, the variable `tabulated-list-printer' is used to control
the way printing is done and any package that wants to print differently
should be setting that variable to their own printing function.
Packages should not be exposed to the printing process unless they are
offering functionality that /cannot/ be handled by tabulated-list.

---

PS: The actual point of the previous message, which went unanswered was:
> Considering the width of a column can be changed arbitrarily by the user
> is it not expected for tabulated-list to handle images in a way that
> works for all widths?

---

PPS: I am thinking of carrying this conversation over to emacs-devel.
     Are you okay with that?





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#53520: [PATCH] tabulated-list gradually truncate image
  2022-01-25 16:04       ` Thuna
@ 2022-01-26 13:11         ` Lars Ingebrigtsen
  2022-09-08 13:38           ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-26 13:11 UTC (permalink / raw)
  To: Thuna; +Cc: 53520

Thuna <thuna.cing@gmail.com> writes:

> PS: The actual point of the previous message, which went unanswered was:
>> Considering the width of a column can be changed arbitrarily by the user
>> is it not expected for tabulated-list to handle images in a way that
>> works for all widths?

I thought I answered that -- the package should advice the tabulated
list to do the thing it wants.

> PPS: I am thinking of carrying this conversation over to emacs-devel.
>      Are you okay with that?

Sure, go ahead.

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#53520: [PATCH] tabulated-list gradually truncate image
  2022-01-26 13:11         ` Lars Ingebrigtsen
@ 2022-09-08 13:38           ` Lars Ingebrigtsen
  0 siblings, 0 replies; 7+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-08 13:38 UTC (permalink / raw)
  To: Thuna; +Cc: 53520

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I thought I answered that -- the package should advice the tabulated
> list to do the thing it wants.

I think the conclusion here is that we don't want to add this, so I'm
closing this bug report.






^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-09-08 13:38 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-25  9:08 bug#53520: [PATCH] tabulated-list gradually truncate image Thuna
2022-01-25 13:36 ` Lars Ingebrigtsen
2022-01-25 14:02   ` Thuna
2022-01-25 14:37     ` Lars Ingebrigtsen
2022-01-25 16:04       ` Thuna
2022-01-26 13:11         ` Lars Ingebrigtsen
2022-09-08 13:38           ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).