From: Ergus <spacibba@aol.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rudalics@gmx.at, emacs-devel@gnu.org
Subject: Re: Question about display engine
Date: Sun, 29 Sep 2019 12:30:34 +0200 [thread overview]
Message-ID: <20190929103034.jw5qolfjtbjkbk5p@Ergus> (raw)
In-Reply-To: <83zhiohfnx.fsf@gnu.org>
On Sat, Sep 28, 2019 at 01:35:30PM +0300, Eli Zaretskii wrote:
Hi Eli:
>
>Thanks, I took a look. I think the branch is almost ready to be
>merged, once we address the following minor comments:
>
> . I don't understand why you changed the underlined_p and
> underline_type stuff in struct face. What were the reasons for
> that part of the changeset? Its sole effect seems to be to
> generate some redundant changes, or am I missing something?
>
Use double variable to describe the same is an error prone
practice. This change simplifies the checks in all the code related (as
there will be only one variable to set/check), reduces one name and
member in the struct and avoids errors related to changing one value and
not the other.
>
> . In this hunk from append_space_for_newline, why did you change
> FACE_FROM_ID_OR_NULL to FACE_FROM_ID?
>
> - int local_default_face_id =
> + int char_width = 1;
> +
> + if (default_face_p
> +#ifdef HAVE_WINDOW_SYSTEM
> + || FRAME_WINDOW_P (it->f)
> +#endif
> + )
> + {
> + const int local_default_face_id =
> lookup_basic_face (it->w, it->f, DEFAULT_FACE_ID);
> struct face* default_face =
> - FACE_FROM_ID_OR_NULL (it->f, local_default_face_id);
> + FACE_FROM_ID (it->f, local_default_face_id);
>
The call is made after a lookup_basic_face and it's for DEFAULT_FACE_ID
is it needed the check? Normally for other faces if it is NULL then we
use the DEFAULT_FACE_ID. In this case it should be unneeded right?
> . Please use comments /* in this style */, not // like this.
>
Fixed
>
> . In this hunk from extend_face_to_end_of_line you lost the
> comment. Is that comment no longer correct?
>
> - int column_x;
>
> - if (!INT_MULTIPLY_WRAPV (indicator_column, char_width, &column_x)
> - && !INT_ADD_WRAPV (it->lnum_pixel_width, column_x, &column_x)
> - && column_x >= it->current_x
> - && column_x <= it->last_visible_x)
> - {
> + const int indicator_column =
> + fill_column_indicator_column (it, char_width);
> +
> const char saved_char = it->char_to_display;
> const struct text_pos saved_pos = it->position;
> const bool saved_avoid_cursor = it->avoid_cursor_p;
> - const int saved_face_id = it->face_id;
> const bool saved_box_start = it->start_of_box_run_p;
> Lisp_Object save_object = it->object;
> + const int saved_face_id = it->face_id;
>
> - /* The stretch width needs to considet the latter
> - added glyph. */
> - const int stretch_width
> - = column_x - it->current_x - char_width;
> -
> - memset (&it->position, 0, sizeof it->position);
> + it->face_id = extend_face_id;
> it->avoid_cursor_p = true;
> it->object = Qnil;
>
> + if (indicator_column >= 0
> + && indicator_column > it->current_x
> + && indicator_column < it->last_visible_x)
> + {
> +
> + const int stretch_width =
> + indicator_column - it->current_x - char_width;
> +
> + memset (&it->position, 0, sizeof it->position);
> +
>
The comment is now in the function fill_column_indicator_column where
the calculation is performed now.
>
> . And here the comment was not moved with the code which it
> describes:
>
> /* Restore the face after the indicator was generated. */
> - it->face_id = saved_face_id;
>
> /* If there is space after the indicator generate an
> extra empty glyph to restore the face. Issue was
> @@ -20634,8 +20633,8 @@ extend_face_to_end_of_line (struct it *it)
> it->avoid_cursor_p = saved_avoid_cursor;
> it->start_of_box_run_p = saved_box_start;
> it->object = save_object;
> - }
> - }
> + it->face_id = saved_face_id;
>
Fixed.
> . This hunk looks redundant to me:
>
> @@ -20681,10 +20680,9 @@ extend_face_to_end_of_line (struct it *it)
> /* The last row's stretch glyph should get the default
> face, to avoid painting the rest of the window with
> the region face, if the region ends at ZV. */
> - if (it->glyph_row->ends_at_zv_p)
> - it->face_id = default_face->id;
> - else
> - it->face_id = face->id;
> + it->face_id = (it->glyph_row->ends_at_zv_p ?
> + default_face->id : face->id);
>
> (there's at least one more like it in the changeset).
>
For me this looked better (shorter and clearer), but I will restore it
if you prefer that.
> . This also looks redundant:
>
> @@ -25436,8 +25423,8 @@ display_string (const char *string, Lisp_Object lisp_str
>
> /* Initialize the iterator IT for iteration over STRING beginning
> with index START. */
> - reseat_to_string (it, NILP (lisp_string) ? string : NULL, lisp_string, start,
> - precision, field_width, multibyte);
> + reseat_to_string (it, NILP (lisp_string) ? string : NULL, lisp_string,
> + start, precision, field_width, multibyte);
>
The line was too long. I just tried to reduce it a bit.
> . In this commentary, please upcase attr_filter, as that is our
> convention for describing function arguments in comments:
>
> @@ -2269,6 +2282,11 @@ filter_face_ref (Lisp_Object face_ref,
> of ERR_MSGS). Use NAMED_MERGE_POINTS to detect loops in face
> inheritance or list structure; it may be 0 for most callers.
>
> + attr_filter is the index of a parameter that conditions the merging
> + for named faces (case 1) to only the face_ref where
> + lface[merge_face_ref] is non-nil. To merge unconditionally set this
> + value to 0.
>
> . Likewise here:
>
> @@ -5988,6 +6039,8 @@ compute_char_face (struct frame *f, int ch, Lisp_Object pr
> which a different face is needed, as far as text properties and
> overlays are concerned. W is a window displaying current_buffer.
>
> + attr_filter is passed merge_face_ref.
>
> The sentence you added sounds incomplete here: did you mean to say
> "passed to merge_face_ref"?
>
Fixed both.
> . This hunk looks redundant:
>
> @@ -4505,7 +4552,8 @@ lookup_face (struct frame *f, Lisp_Object *attr)
> suitable face is found, realize a new one. */
>
> int
> -face_for_font (struct frame *f, Lisp_Object font_object, struct face *base_face
> +face_for_font (struct frame *f, Lisp_Object font_object,
> + struct face *base_face)
>
The line was too long. 85 chars long.
> . This also looks redundant:
>
> @@ -6068,19 +6122,18 @@ face_at_buffer_position (struct window *w, ptrdiff_t pos
> }
>
> /* Optimize common cases where we can use the default face. */
> - if (noverlays == 0
> - && NILP (prop))
> + if (noverlays == 0 && NILP (prop))
>
> . And this one:
>
> /* Begin with attributes from the default face. */
> - memcpy (attrs, default_face->lface, sizeof attrs);
> + memcpy (attrs, default_face->lface, sizeof(attrs));
>
> . Finally, please write some short description for NEWS, as this
> feature definitely needs to be mentioned there.
>
It seems unneeded two lines for this; but fixed.
>Thanks again for working on this, and sorry for my unusually slow
>responses.
Thank to you.
next prev parent reply other threads:[~2019-09-29 10:30 UTC|newest]
Thread overview: 183+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <318675867.1913640.1567711569517.ref@mail.yahoo.com>
2019-09-05 19:26 ` Question about display engine Ergus
2019-09-06 8:22 ` martin rudalics
2019-09-06 9:31 ` Ergus
2019-09-07 6:52 ` martin rudalics
2019-09-07 7:37 ` Eli Zaretskii
2019-09-07 7:55 ` Eli Zaretskii
2019-09-08 0:51 ` Ergus via Emacs development discussions.
2019-09-08 8:40 ` martin rudalics
2019-09-08 12:53 ` Ergus
2019-09-09 7:39 ` martin rudalics
2019-09-09 13:56 ` Ergus
2019-09-09 16:00 ` Eli Zaretskii
2019-09-09 17:08 ` Ergus
2019-09-09 18:08 ` Eli Zaretskii
2019-09-09 19:29 ` Ergus
2019-09-10 2:27 ` Eli Zaretskii
2019-09-12 3:37 ` Ergus
2019-09-13 8:50 ` Eli Zaretskii
2019-09-08 17:51 ` Eli Zaretskii
2019-09-08 18:23 ` Ergus
2019-09-14 20:42 ` Ergus
2019-09-15 8:25 ` martin rudalics
2019-09-15 11:26 ` Ergus
2019-09-15 12:22 ` martin rudalics
2019-09-15 14:28 ` Stefan Monnier
2019-09-16 9:05 ` martin rudalics
2019-09-15 15:32 ` Eli Zaretskii
2019-09-15 21:42 ` Ergus
2019-09-17 2:17 ` Ergus
2019-09-17 9:48 ` Eli Zaretskii
2019-09-21 8:20 ` Eli Zaretskii
2019-09-21 13:57 ` Ergus
2019-09-21 21:55 ` Ergus
2019-09-26 16:32 ` Ergus
2019-09-28 10:35 ` Eli Zaretskii
2019-09-29 10:30 ` Ergus [this message]
2019-09-29 10:57 ` Eli Zaretskii
2019-10-07 15:40 ` Ergus
2019-10-09 9:02 ` Eli Zaretskii
2019-10-12 18:16 ` Ergus
2019-10-12 18:29 ` Eli Zaretskii
2019-09-06 8:55 ` Eli Zaretskii
2019-09-06 10:30 ` Ergus
2019-09-06 13:28 ` Eli Zaretskii
2019-09-06 16:34 ` Ergus
2019-09-06 18:12 ` Eli Zaretskii
2019-09-07 2:35 ` Ergus
2019-09-07 6:41 ` Eli Zaretskii
[not found] <20191012222305.jpjinkd5y2lz6xiv@Ergus>
[not found] ` <83mue5kmfx.fsf@gnu.org>
2019-10-13 15:40 ` Ergus
2019-10-13 16:06 ` Eli Zaretskii
2019-10-13 16:44 ` Ergus
2019-10-13 17:04 ` Eli Zaretskii
2019-10-13 18:11 ` Ergus
2019-10-13 18:25 ` Ergus
2019-10-13 18:53 ` Eli Zaretskii
2019-10-13 19:38 ` Ergus
2019-10-13 21:01 ` Eli Zaretskii
2019-10-13 22:27 ` Ergus
2019-10-14 8:26 ` Eli Zaretskii
2019-10-20 22:20 ` Ergus
2019-10-21 6:38 ` Eli Zaretskii
2019-10-13 19:41 ` Ergus
2019-10-13 16:11 ` Eli Zaretskii
2019-08-27 16:01 Keith David Bershatsky
-- strict thread matches above, loose matches on Subject: below --
2019-08-07 0:54 Ergus
2019-08-07 15:01 ` Eli Zaretskii
2019-08-07 15:32 ` Ergus
2019-08-07 15:45 ` Eli Zaretskii
2019-08-07 15:57 ` Ergus
2019-08-07 16:12 ` Eli Zaretskii
2019-08-07 16:25 ` martin rudalics
2019-08-07 16:41 ` Eli Zaretskii
2019-08-08 7:25 ` martin rudalics
2019-08-08 8:38 ` Ergus
2019-08-08 8:45 ` martin rudalics
2019-08-08 9:29 ` Ergus
2019-08-08 13:05 ` martin rudalics
2019-08-08 13:59 ` Eli Zaretskii
2019-08-08 16:43 ` Ergus
2019-08-08 17:50 ` Eli Zaretskii
2019-08-08 22:37 ` Ergus
2019-08-09 6:28 ` Eli Zaretskii
2019-08-09 9:08 ` Ergus
2019-08-09 9:40 ` Eli Zaretskii
2019-08-09 11:31 ` Ergus
2019-08-09 14:04 ` Eli Zaretskii
2019-08-09 15:09 ` Ergus
2019-08-09 8:59 ` martin rudalics
2019-08-09 9:31 ` Ergus
2019-08-09 9:38 ` Ergus
2019-08-10 11:42 ` Eli Zaretskii
2019-08-11 8:14 ` martin rudalics
2019-08-09 8:59 ` martin rudalics
2019-08-08 14:50 ` Ergus
2019-08-09 8:59 ` martin rudalics
2019-08-10 11:30 ` Eli Zaretskii
2019-08-11 8:14 ` martin rudalics
2019-08-11 14:13 ` Eli Zaretskii
2019-08-12 8:59 ` martin rudalics
2019-08-12 15:29 ` Eli Zaretskii
2019-08-12 22:18 ` Stefan Monnier
2019-08-13 8:17 ` martin rudalics
2019-08-13 15:32 ` Eli Zaretskii
2019-08-13 22:33 ` Stefan Monnier
2019-08-14 8:58 ` martin rudalics
2019-08-13 8:17 ` martin rudalics
2019-08-13 15:31 ` Eli Zaretskii
2019-08-14 8:58 ` martin rudalics
2019-08-14 15:14 ` Eli Zaretskii
2019-08-15 8:13 ` martin rudalics
2019-08-15 15:18 ` Eli Zaretskii
2019-08-16 7:29 ` martin rudalics
2019-08-16 8:34 ` Eli Zaretskii
2019-08-17 8:25 ` martin rudalics
2019-08-19 16:13 ` Ergus
2019-08-19 16:50 ` Eli Zaretskii
2019-08-19 21:30 ` Ergus
2019-08-20 14:09 ` Eli Zaretskii
2019-08-25 10:22 ` Ergus
2019-08-25 10:44 ` Eli Zaretskii
2019-08-26 4:31 ` Ergus
2019-08-26 7:45 ` Eli Zaretskii
2019-08-26 8:18 ` Ergus
2019-08-26 9:49 ` Eli Zaretskii
2019-08-27 22:20 ` Ergus
2019-08-28 8:35 ` martin rudalics
2019-08-28 9:07 ` Eli Zaretskii
2019-08-28 12:19 ` martin rudalics
2019-08-28 16:31 ` Ergus
2019-08-28 17:24 ` Eli Zaretskii
2019-08-28 18:19 ` Ergus
2019-08-29 18:28 ` Eli Zaretskii
2019-08-30 7:02 ` martin rudalics
2019-08-30 7:26 ` Eli Zaretskii
2019-08-30 9:34 ` Ergus
2019-08-29 7:45 ` martin rudalics
2019-08-28 17:21 ` Eli Zaretskii
2019-08-29 7:45 ` martin rudalics
2019-08-29 18:36 ` Eli Zaretskii
2019-08-30 7:03 ` martin rudalics
2019-08-30 8:48 ` Eli Zaretskii
2019-08-31 7:29 ` martin rudalics
2019-08-31 7:57 ` Eli Zaretskii
2019-09-01 8:14 ` martin rudalics
2019-09-01 12:26 ` Ergus
2019-09-02 8:36 ` martin rudalics
2019-09-02 11:05 ` Ergus
2019-09-02 16:18 ` Eli Zaretskii
2019-09-03 5:33 ` Ergus
2019-09-03 8:45 ` martin rudalics
2019-09-03 11:23 ` Ergus
2019-09-03 12:17 ` martin rudalics
2019-09-03 14:56 ` Eli Zaretskii
2019-09-03 5:35 ` Ergus via Emacs development discussions.
2019-09-03 8:45 ` martin rudalics
2019-09-03 14:53 ` Eli Zaretskii
2019-09-03 16:41 ` martin rudalics
2019-09-03 17:31 ` Eli Zaretskii
2019-09-03 18:59 ` martin rudalics
2019-09-04 18:33 ` Ergus
2019-09-04 20:04 ` martin rudalics
2019-09-04 20:19 ` Ergus via Emacs development discussions.
2019-09-05 7:32 ` martin rudalics
2019-09-05 13:54 ` Ergus
2019-09-05 19:31 ` Ergus
[not found] ` <1826922767.1725310.1567682307734@mail.yahoo.com>
2019-09-05 11:18 ` Ergus
2019-08-21 7:37 ` martin rudalics
2019-08-08 17:37 ` Eli Zaretskii
2019-08-09 12:46 ` martin rudalics
2019-08-10 11:25 ` Eli Zaretskii
2019-08-10 23:04 ` Stefan Monnier
2019-08-11 2:43 ` Eli Zaretskii
2019-08-11 8:17 ` martin rudalics
2019-08-11 8:11 ` martin rudalics
2019-08-08 17:38 ` Eli Zaretskii
2019-08-08 8:15 ` Ergus
2019-08-08 8:45 ` martin rudalics
2019-08-08 9:17 ` Ergus
2019-08-08 17:35 ` Eli Zaretskii
2019-08-08 20:37 ` Juri Linkov
2019-08-08 22:24 ` Ergus
2019-08-09 6:42 ` Eli Zaretskii
2019-08-09 17:54 ` Juri Linkov
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=20190929103034.jw5qolfjtbjkbk5p@Ergus \
--to=spacibba@aol.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--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).