unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: redisplay code is ugly (was: Cursor positioning with `after-string' overlays)
Date: Sat, 03 Apr 2010 10:30:57 +0300	[thread overview]
Message-ID: <83zl1luh5a.fsf@gnu.org> (raw)
In-Reply-To: <jwviq895ocl.fsf-monnier+emacs@gnu.org>

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 02 Apr 2010 21:21:09 -0400
> Cc: emacs-devel@gnu.org
> 
> I.e. it's workable but it'd probably be ugly.

Ugly is xdisp.c's middle name.  I hate to say it, but almost every
important function of the display engine has become so convoluted and
under-commented that they all simply cry for refactoring.  Look at
move_it_in_display_line_to or at display_line -- with all the
different temporary `struct it' and flag variables, the amount of
cruft there is so large that it is next to impossible to even grasp
the overall control and data flow there, let alone make a non-trivial
modification.  (set_cursor_from_row was in a similar state; I hope
that after the rewrite on the trunk, it is a bit more manageable, but
I'd certainly love some critical peer review there.)

I frequently need to look at the Emacs 21 sources, just to understand
the original design and implementation.  At least there, they are
clearly visible and adequately commented.

My conclusion from almost a year of hacking the display engine is that
we are currently stretching it way past its original design
limitations.  Somebody(TM) should take a fresh look at the code and
refactor it.  I'm quite sure that quite a few of ugly places could be
rectified by adding some data to the core data structures, for
example.

Emacs 24 sounds like a good opportunity for such a refactoring.

And no, I'm not volunteering.  One reason is that I'm not good at this
job -- I try to stick to the original design on some deeply
subconscious level.




  parent reply	other threads:[~2010-04-03  7:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-01 13:15 Cursor positioning with `after-string' overlays Eli Zaretskii
2010-04-01 21:54 ` Kim F. Storm
2010-04-02  7:53   ` Eli Zaretskii
2010-04-02  8:54     ` Eli Zaretskii
2010-04-02 10:24       ` Kim F. Storm
2010-04-01 22:06 ` Stefan Monnier
2010-04-02  8:16   ` Eli Zaretskii
2010-04-02 18:17     ` Stefan Monnier
2010-04-02 18:38       ` Eli Zaretskii
2010-04-02 20:35         ` Stefan Monnier
2010-04-02 21:16           ` Eli Zaretskii
2010-04-03  1:21             ` Stefan Monnier
2010-04-03  7:26               ` Eli Zaretskii
2010-04-03  7:30               ` Eli Zaretskii [this message]
2010-04-03 10:42               ` Eli Zaretskii
2010-04-03 10:28       ` 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

  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=83zl1luh5a.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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).