all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: emacs-devel@gnu.org
Subject: Re: [RFC] some reworking of struct window
Date: Thu, 21 Mar 2013 20:21:48 +0200	[thread overview]
Message-ID: <83620kzk8z.fsf@gnu.org> (raw)
In-Reply-To: <514AD54F.8050309@yandex.ru>

> Date: Thu, 21 Mar 2013 13:39:27 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> 
> This patch implements the further generalization of an idea suggested by Stefan
> at http://lists.gnu.org/archive/html/emacs-devel/2013-02/msg00088.html. The main
> motivations are 1) make 'struct window' even bit smaller and 2) simplify the code
> like:
> 
> if (!NILP (w->hchild))
>    foo (w->hchild);
> else if (!NILP (w->vchild))
>    foo (w->vchild);
> else /* assume leaf window with w->buffer */
>    bar (w->buffer);
> 
> to:
> 
> if (WINDOWP (w->object))
>    foo (w->object);
> else /* assume leaf window with buffer at w->object */
>    bar (w->object);

Thanks.

> As usual, reviews and comments are highly appreciated, especially for the
> 'struct window' member which replaces hchild/vchild/buffer (I don't like
> too generic 'object', but couldn't think up the better name).

Most of the changes are mechanical, so the review could be much more
efficient if you could point out non-trivial ones.

> @@ -838,16 +838,8 @@
>  {
>    while (w)
>      {
> -      if (!NILP (w->hchild))
> -	{
> -	  eassert (WINDOWP (w->hchild));
> -	  clear_window_matrices (XWINDOW (w->hchild), desired_p);
> -	}
> -      else if (!NILP (w->vchild))
> -	{
> -	  eassert (WINDOWP (w->vchild));
> -	  clear_window_matrices (XWINDOW (w->vchild), desired_p);
> -	}
> +      if (WINDOWP (w->object))
> +	clear_window_matrices (XWINDOW (w->object), desired_p);
>        else
>  	{
>  	  if (desired_p)

Here, you effectively lost the assertion that w->object can only be a
window or a buffer.  With the new code, if it's neither a window nor a
buffer, you will behave as if it were a buffer, without checking.

> -  eassert (NILP (w->hchild) && NILP (w->vchild));
> +  eassert (w->type == WINDOW_LEAF);

Why do you need to store the WINDOW_LEAF type explicitly, if you can
test w->object for being a buffer?  And if you do need this type, why
not use it instead of WINDOWP in the various tests above and below?

> @@ -2069,22 +2060,18 @@
>    if (!NILP (parent) && NILP (w->combination_limit))
>      {
>        p = XWINDOW (parent);
> -      if (((!NILP (p->vchild) && !NILP (w->vchild))
> -	   || (!NILP (p->hchild) && !NILP (w->hchild))))
> +      if (p->type == w->type && p->type > WINDOW_LEAF)
                                   ^^^^^^^^^^^^^^^^^^^^^
I think you are not supposed to compare enumerated types, except for
equality.  How exactly the compiler assigns numerical values to
enumerated types is implementation-defined, I think.

> -  /* P's buffer slot may change from nil to a buffer.  */
> -  adjust_window_count (p, 1);

Why did you remove this call?

> -      if (!NILP (w->vchild))
> -	{
> -	  delete_all_child_windows (w->vchild);
> -	  wset_vchild (w, Qnil);
> -	}
> -      else if (!NILP (w->hchild))
> -	{
> -	  delete_all_child_windows (w->hchild);
> -	  wset_hchild (w, Qnil);
> -	}
> -      else if (!NILP (w->buffer))
> +      if (WINDOWP (w->object))
> +	{
> +	  delete_all_child_windows (w->object);
> +	  w->object = Qnil;
> +	}
> +      else
>  	{
>  	  unshow_buffer (w);
>  	  unchain_marker (XMARKER (w->pointm));

Maybe instead of just "else" you should make sure w->object is a
buffer.

> +/* Window types, see the comment above.  */
> +
> +enum window_type
> +  {
> +    WINDOW_LEAF,
> +    WINDOW_HORIZONTAL_COMBINATION,
> +    WINDOW_VERTICAL_COMBINATION,
> +  };

The test BUFFERP (w->object) already gives you the same info as
WINDOW_LEAF type, no?



  parent reply	other threads:[~2013-03-21 18:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21  9:39 [RFC] some reworking of struct window Dmitry Antipov
2013-03-21 11:38 ` martin rudalics
2013-03-21 18:45   ` Eli Zaretskii
2013-03-21 21:17     ` martin rudalics
2013-03-21 14:26 ` Davis Herring
2013-03-21 14:46 ` Stefan Monnier
2013-03-21 15:01   ` Dmitry Antipov
2013-03-21 17:40     ` Eli Zaretskii
2013-03-21 18:21 ` Eli Zaretskii [this message]
2013-03-21 23:50   ` Stefan Monnier
2013-03-22  7:40     ` Alternate design [Was: Re: [RFC] some reworking of struct window] Dmitry Antipov
2013-03-22 13:34       ` Stefan Monnier
2013-03-25 15:29         ` Dmitry Antipov
2013-03-25 19:02           ` Stefan Monnier
2013-03-22  6:13   ` [RFC] some reworking of struct window Dmitry Antipov
2013-03-22  8:47     ` Eli Zaretskii

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

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

  git send-email \
    --in-reply-to=83620kzk8z.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=dmantipov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.