unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: joostkremers@fastmail.fm, emacs-devel@gnu.org
Subject: Re: Better handling of window margins
Date: Thu, 03 Dec 2015 22:09:54 +0200	[thread overview]
Message-ID: <83h9jzi99p.fsf@gnu.org> (raw)
In-Reply-To: <566086FA.6010603@gmx.at>

> Date: Thu, 03 Dec 2015 19:16:26 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, emacs-devel@gnu.org
> 
>  >> You say that linum-mode will specify a "display width of the same N
>  >> columns in pixels".  How would it react to an increase of the width of
>  >> the default face?
>  >
>  > How is it covered today?
> 
> Via ‘post-command-hook’ I suppose.
> 
>  >> IIUC this is not covered by any special hook so it has to be done
>  >> via ‘post-command-hook’.  No great deal but it shows that
>  >> ‘post-command-hook’ is indispensable for such modes.
>  >
>  > Even if this conclusion is correct, is it really relevant to the
>  > concrete issue being discussed?
> 
> Hopefully.  If we want to get rid of ‘post-command-hook’ dependencies.

My suggestion wasn't supposed to do anything about post-command-hook.
It aimed only at allowing separate features display in the margins
without interfering with one another.

>  > IOW, what I suggested wasn't supposed to solve any problem except one:
>  > how can several features display simultaneously on the same display
>  > margin.  It wasn't supposed magically solve other related or unrelated
>  > problems.
> 
> How does the ability to specify a margin size in pixels help to display
> several features simultaneously?

Size in pixels is not the main part of what I proposed.  I only
mentioned pixels because the margins can display images, and there's
no easy way of knowing how many columns an image will take.

The main part of my proposal is that each request for a window margin
will specify both the margin size and the size of the stuff that will
be displayed there.  Two values, not one.

>  >> So you mean there's no need for any new infrastructure here - the
>  >> ‘split-window’ window parameter can take care of this.
>  >
>  > I simply don't believe there could be a generic solution that doesn't
>  > involve active participation of the modes that are affected by this.
> 
> If modes can specify their needs for each window they act on, the
> overhead will be encapsulated in calculating a window's minimum width.

How can you encapsulate what an unknown mode will want to do?

> If we can't manage that, then modes will also have to intervene every
> time we set a window's fringes or scroll-bar width or adjust its right
> trailing edge.  I'm afraid that mode authors won't want to do that.

Sorry, you lost me.  What do fringes and scroll bars have in common
with the issue at point?  Do you envision a window with 20-column wide
fringes or something?

>  >>   >> When two modes simultaneously use the margins, which buffer display
>  >>   >> function would be chosen?
>  >>   >
>  >>   > The same problem exists with the proposed solution, doesn't it?
>  >>
>  >> Is there one?
>  >
>  > Of course: imagine that the effects of 2 or more elements of the list
>  > contradict each other.  Which one to choose?
> 
> I thought Joost's idea was to capture this issue by having
> ‘window-splittable-p’ count static margins only.  So I don't see any
> contradiction.

It makes little sense to me to solve a small portion of a problem.




  reply	other threads:[~2015-12-03 20:09 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 21:28 Better handling of window margins Joost Kremers
2015-12-02  8:23 ` martin rudalics
2015-12-02 13:41 ` Eli Zaretskii
2015-12-02 17:43   ` martin rudalics
2015-12-02 17:53     ` Eli Zaretskii
2015-12-02 18:11       ` martin rudalics
2015-12-03  6:49         ` Eli Zaretskii
2015-12-03 18:16           ` martin rudalics
2015-12-03 20:09             ` Eli Zaretskii [this message]
2015-12-03 20:43               ` Stefan Monnier
2015-12-04  8:14                 ` Eli Zaretskii
2015-12-04 13:22                   ` Stefan Monnier
2015-12-04 14:46                     ` Eli Zaretskii
2015-12-04 17:30                       ` Stefan Monnier
2015-12-04 18:45                         ` Eli Zaretskii
2015-12-04 20:55                           ` Stefan Monnier
2015-12-04 21:13                             ` Eli Zaretskii
2015-12-04 21:33                               ` Stefan Monnier
2015-12-05  7:56                                 ` Eli Zaretskii
2015-12-05 15:17                                   ` Stefan Monnier
2015-12-05 15:49                                     ` Eli Zaretskii
2015-12-06  4:27                                       ` Stefan Monnier
2015-12-06  5:02                                         ` John Wiegley
2015-12-06 16:10                                           ` Eli Zaretskii
2015-12-06 20:24                                             ` Yuri Khan
2015-12-07  3:32                                               ` Eli Zaretskii
2015-12-07 10:35                                                 ` Yuri Khan
2015-12-07 16:39                                                   ` Eli Zaretskii
2015-12-07  0:29                                             ` John Wiegley
2015-12-07 16:24                                               ` Eli Zaretskii
2015-12-07 17:35                                                 ` John Wiegley
2015-12-07 17:38                                                   ` Achim Gratz
2015-12-07 17:41                                                     ` John Wiegley
2015-12-07 17:50                                                       ` Achim Gratz
2015-12-07 17:36                                                 ` Stefan Monnier
2015-12-07 17:39                                                   ` John Wiegley
2015-12-07 18:42                                                     ` Stefan Monnier
2015-12-07 19:14                                                       ` John Wiegley
2015-12-04  8:07               ` martin rudalics
2015-12-04  9:42                 ` Eli Zaretskii
2015-12-04 10:21                   ` martin rudalics
2015-12-04 15:34                     ` Eli Zaretskii
2015-12-04 16:56                       ` martin rudalics
2015-12-04 18:34                         ` Eli Zaretskii
2015-12-04 19:23                           ` martin rudalics
2015-12-02 19:52       ` Joost Kremers
2015-12-03  7:17         ` Eli Zaretskii
2015-12-02 19:55   ` Joost Kremers
2015-12-03  7:21     ` Eli Zaretskii
2015-12-04 12:49 ` John Wiegley

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=83h9jzi99p.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joostkremers@fastmail.fm \
    --cc=rudalics@gmx.at \
    /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).