[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23574: 24.5; Overzealous underlining in emacs-nox

From: Colin Woodbury
Subject: bug#23574: 24.5; Overzealous underlining in emacs-nox
Date: Mon, 6 Jun 2016 11:25:34 -0700

> 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 <address@hidden> 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.


Colin Woodbury
Geotrellis Team @ Azavea

reply via email to

[Prev in Thread] Current Thread [Next in Thread]