[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62994: [PATCH v5] Add support for colored and styled underlines on t
From: |
Eli Zaretskii |
Subject: |
bug#62994: [PATCH v5] Add support for colored and styled underlines on tty frames |
Date: |
Thu, 14 Mar 2024 12:20:17 +0200 |
> From: Mohsin Kaleem <mohkale@kisara.moe>
> Cc: 62994@debbugs.gnu.org
> Date: Sun, 10 Mar 2024 18:08:19 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Thanks. I think in addition to NEWS, we'd need to update the ELisp
> > Reference manual, because the new underline styles are not currently
> > mentioned there.
>
> Added. Should I mention display support between GUI and TTY frames or is
> it sufficient just to mention these are the options?
The documentation should say which displays support this.
> >> - if (foreground_p)
> >> - face->foreground = pixel;
> >> - else
> >> - face->background = pixel;
> >> + switch (idx)
> >> + {
> >> + case LFACE_FOREGROUND_INDEX:
> >> + face->foreground = pixel;
> >> + break;
> >> + case LFACE_BACKGROUND_INDEX:
> >> + face->background = pixel;
> >> + break;
> >> + case LFACE_UNDERLINE_INDEX:
> >> + face->underline_color = pixel;
> >> + break;
> >> + default:
> >> + emacs_abort ();
> >
> > The original code didn't call emacs_abort, but instead simply used
> > PIXEL as the background color. Why would we do something different
> > now?
>
> Earlier in the function we call eassert on the index parameter. I
> might've misunderstood but I thought that check would terminate the
> function at that point so this line where we handle a index value
> outside the supported range should never be called.
eassert are only active in debug builds with --enable-checking; they
compile to nothing in production builds.
> If preferred I can
> fallthrough into the background statement to stay consistent?
Yes, please.
> >> +static void
> >> +map_tty_color2 (struct frame *f, struct face *face, Lisp_Object color,
> >> + enum lface_attribute_index idx)
> >> +{
> >> + bool face_colors_defaulted = false;
> >> + map_tty_color (f, face, color, idx, &face_colors_defaulted);
> >> }
> >
> > Is this function really justified? why not call map_tty_color?
>
> The extra parameter face_colors_defaulted doesn't really make sense for
> anything but foreground/background color calls. Using the existing one
> would make the callsite for the underline color set more noisy with an
> extra output param that we then just ignore. I thought this was a
> slightly nicer solution from the caller side. If preferred I can remove
> and go the alternate route?
How many callers does this function have? If just one or two, I don't
think a separate function is worth our while.
Thanks.