bug#62994: [PATCH v5] Add support for colored and styled underlines on tty frames

[Eli Zaretskii <eliz@gnu.org>]

> 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.