unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Tad Fisher <tadfisher@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: vtable: Add column weights feature
Date: Sun, 09 Oct 2022 16:26:07 +0200	[thread overview]
Message-ID: <87a665qdj4.fsf@gnus.org> (raw)
In-Reply-To: <CA+BndftG5NJ3tJYqig1e4regjzs4xB-U_aSfVgadBL7HuFuG9A@mail.gmail.com> (Tad Fisher's message of "Sat, 8 Oct 2022 14:11:13 -0700")

Tad Fisher <tadfisher@gmail.com> writes:

> In my mind, "percentage of window width" specs aren't useful to begin
> with, because they interact poorly with fixed-width columns. If your
> goal is to have the vtable occupy a particular width of the window (e.g.
> 100%), this goal becomes difficult/impossible as soon as a fixed-width
> column is added.

That shouldn't be impossible -- the normal way to do this is to let the
percentage columns soak up the available space (but you need a way to
specify the total width of the table, which should be easy enough to
add).

> Ideally, you'd have a constraint on the vtable itself---as in, "I want
> the vtable to occupy 80% of the window width", and that value is used
> instead of (window-width nil t) when calculating column widths.

Yes, we could add that.

> And I do think that defining these concepts as "constraints" is the
> better approach in the long run; as in, the "width", "min-width", and
> "max-width" slots become part of an enumerated "constraint" type,
> so the API limits the possible values to those that make sense. Then
> the vtable--column-widths function solves those constraints to obtain
> the final width values. Does this make sense? My experience is mostly
> from Android UIs where this is a common way to define layouts, and my
> understanding is that the CSS "flexbox" model is similar.

I think percentages are easier to deal with if you don't consider them
to be strict.  That is, if you've specified the width of the entire
table, then having one table saying "10%" and another "20%" means that
any extra space would be distributed 1:2 between those two columns.




      reply	other threads:[~2022-10-09 14:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-08  1:51 vtable: Add column weights feature Tad Fisher
2022-10-08 13:06 ` Lars Ingebrigtsen
2022-10-08 21:11   ` Tad Fisher
2022-10-09 14:26     ` Lars Ingebrigtsen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a665qdj4.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=emacs-devel@gnu.org \
    --cc=tadfisher@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).