GNU bug report logs - #23574
24.5; Overzealous underlining in emacs-nox

Previous Next

Full log

View this message in rfc822 format

From: Colin Woodbury <cwoodbury <at> azavea.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 23574 <at> debbugs.gnu.org, John Mastro <john.b.mastro <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: bug#23574: 24.5; Overzealous underlining in emacs-nox
Date: Mon, 6 Jun 2016 11:25:34 -0700

[Message part 1 (text/plain, inline)]

> Yes. However, I believe that this is what the original ensime code
> intended to do; it only underlines the newlines themselves because
> it's easier to make 1 overlay for all the lines at once and the
> programmer didn't notice it was wrong because it happens to give the
> desired effect in GUI mode.

I think that's the case. The purpose of the underlining is to show where
"Scala implicits" are occuring. An implicit is some code brought into scope
through imports, often used for silent conversion to inject methods into
preexisting datatypes. Essentially that with "traits" are how Scala hacks
Haskell typeclasses.

If your statement that uses an implicit happens to span multiple lines,
ensime (I believe) just finds the starting and ending points of the
statement and applies the face to the entire area. In the GUI, this happens
to produce the desired effect of only underlining where characters are
(with the newline as well, as mentioned previously). In TTY this places the
face over everything, which we don't agree is a bug or not.

On Mon, Jun 6, 2016 at 9:54 AM, martin rudalics <rudalics <at> gmx.at> wrote:

> > Going back to the bug report, there's still one issue to consider:
> > should we add underline (and then also overline and strikethrough) to
> > the list of face attributes that cause face extension on GUI frames.
> > The logic behind the current code seems to be to extend attributes
> > that are related to background of the text.  The above 3 seem to be a
> > kind-of background, so maybe we should add them.
>
> It would make my life much easier if face extension were, in general,
> customizable.  I would immediately turn it off everywhere.
>
> My motivation is that I have font-lock distinguish things like comments
> and strings mainly by their background face.  Since these look awful
> when extending to the end of a window, I have to provide my own
> ‘font-lock-fontify-syntactically-region’ function which assures that
> newline characters within strings and comments never get the
> corresponding face.  This consumes resources and, for example, disallows
> using text properties to skip the rest of a comment or a string.  It
> goes without saying, that my version of this function is never in synch
> with the one of the repository.
>
> I also use separate background colors for editable fields, buttons,
> links and the like which also look awful when spanning two or more
> lines.  No font-locking can help me here.
>
> martin
>
>


-- 
Colin Woodbury
Geotrellis Team @ Azavea

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.