setnu.el / setnu+.el

setnu.el / setnu+.el

[Sean Sieger]

Is there a way to have line numbers
go unaffected by highlighting?

RE: setnu.el / setnu+.el

[Drew Adams]

    Is there a way to have line numbers
    go unaffected by highlighting?

Could you elaborate? Do you see highlighted line numbers?

Re: setnu.el / setnu+.el

[Sean Sieger]

"Drew Adams" <drew.adams@oracle.com> writes:

       Is there a way to have line numbers
       go unaffected by highlighting?

   Could you elaborate? Do you see highlighted line numbers?

Yes, my line numbers have the same highlighting as
the adjacent code.

RE: setnu.el / setnu+.el

[Drew Adams]

           Is there a way to have line numbers
           go unaffected by highlighting?

       Could you elaborate? Do you see highlighted line numbers?

    Yes, my line numbers have the same highlighting as
    the adjacent code.

I just checked in Emacs 22, and you're right. However, in Emacs 20, the line
numbers are not highlighted. I wrote setnu+.el, which is a only minor tweak
of setnu.el, but I don't know enough to help you here. I believe that this
is the code, in setnu.el, that is in question:

(defun setnu-set-glyph-face (g face)
   (put-text-property 0 (length g) 'face face g))

This code is intended to impose the given face (just bold, by default) on
the line-number overlay text. It does that correctly, but I guess it does
not also remove other text properties that might be on the same overlay
(imposed by font-locking).

It appears that if the newline at the end of a line is fontified (matches a
regexp that imposes fontification), then the line-number overlay is
fontified in the same way.

At first I thought it might be the new `font-lock-face' property that is
supplying the fontification, because that wouldn't be cancelled just by
adding a `face' property. So I tried adding this to the code above:

(put-text-property 0 (length g) 'font-lock-face nil g)

But that had no visible effect. I think that someone who knows either the
setnu.el code or the font-lock mechanisms or overlays better than I will
have to help you. Sorry.

Re: setnu.el / setnu+.el

[Sean Sieger]

"Drew Adams" <drew.adams@oracle.com> writes:

              Is there a way to have line numbers
              go unaffected by highlighting?

          Could you elaborate? Do you see highlighted line numbers?

       Yes, my line numbers have the same highlighting as
       the adjacent code.

   I just checked in Emacs 22, and you're right. However, in Emacs 20, the line
   numbers are not highlighted. I wrote setnu+.el, which is a only minor tweak
   of setnu.el, but I don't know enough to help you here. I believe that this
   is the code, in setnu.el, that is in question:

   (defun setnu-set-glyph-face (g face)
      (put-text-property 0 (length g) 'face face g))

   This code is intended to impose the given face (just bold, by default) on
   the line-number overlay text. It does that correctly, but I guess it does
   not also remove other text properties that might be on the same overlay
   (imposed by font-locking).

   It appears that if the newline at the end of a line is fontified (matches a
   regexp that imposes fontification), then the line-number overlay is
   fontified in the same way.

   At first I thought it might be the new `font-lock-face' property that is
   supplying the fontification, because that wouldn't be cancelled just by
   adding a `face' property. So I tried adding this to the code above:

   (put-text-property 0 (length g) 'font-lock-face nil g)

   But that had no visible effect. I think that someone who knows either the
   setnu.el code or the font-lock mechanisms or overlays better than I will
   have to help you. Sorry.

Thank you, Drew -- I sent mail to Kyle and I'll try to pursue the
ideas you've put forward.

Re: setnu.el / setnu+.el

[Kevin Rodgers]

Drew Adams wrote:
>            Is there a way to have line numbers
>            go unaffected by highlighting?
> 
>        Could you elaborate? Do you see highlighted line numbers?
> 
>     Yes, my line numbers have the same highlighting as
>     the adjacent code.
> 
> I just checked in Emacs 22, and you're right. However, in Emacs 20, the line
> numbers are not highlighted. I wrote setnu+.el, which is a only minor tweak
> of setnu.el, but I don't know enough to help you here. I believe that this
> is the code, in setnu.el, that is in question:
> 
> (defun setnu-set-glyph-face (g face)
>    (put-text-property 0 (length g) 'face face g))
> 
> This code is intended to impose the given face (just bold, by default) on
> the line-number overlay text. It does that correctly, but I guess it does
> not also remove other text properties that might be on the same overlay
> (imposed by font-locking).
> 
> It appears that if the newline at the end of a line is fontified (matches a
> regexp that imposes fontification), then the line-number overlay is
> fontified in the same way.

Each overlay has its before-string property set to the fontified string
returned by setnu-set-glyph-face.  That string is intended to be
displayed before the overlay, which starts at the beginning of the line
and ends after the newline (i.e. at the beginning of the next line).

I don't know what change in Emacs 22 causes the before-string to inherit
properties from the adjacent text, but according to the Overlay
Properties node of the Emacs Lisp manual, all overlays take priority
over text properties.  So maybe it would work to set the overlay's face
property in setnu-make-setnu-extent:

     (setnu-set-extent-property e 'face nil) ; or 'default

> At first I thought it might be the new `font-lock-face' property that is
> supplying the fontification, because that wouldn't be cancelled just by
> adding a `face' property. So I tried adding this to the code above:
> 
> (put-text-property 0 (length g) 'font-lock-face nil g)
> 
> But that had no visible effect. I think that someone who knows either the
> setnu.el code or the font-lock mechanisms or overlays better than I will
> have to help you. Sorry.

I don't know any better than you, but my guess is that the overlay
needs to be modified, not it's before-string.

-- 
Kevin Rodgers

RE: setnu.el / setnu+.el

[Drew Adams]

    >     my line numbers have the same highlighting as
    >     the adjacent code.
    >
    > I just checked in Emacs 22, and you're right. However, in
    > Emacs 20, the line numbers are not highlighted. I believe that
    > this is the code, in setnu.el, that is in question:
    >
    > (defun setnu-set-glyph-face (g face)
    >    (put-text-property 0 (length g) 'face face g))
    >
    > This code is intended to impose the given face (just bold, by
    > default) on the line-number overlay text. It does that correctly,
    > but I guess it does not also remove other text properties that
    > might be on the same overlay (imposed by font-locking).
    >
    > It appears that if the newline at the end of a line is
    > fontified (matches a regexp that imposes fontification), then
    > the line-number overlay is fontified in the same way.

I should have said instead that it appears that if the first character in a
line is fontified then the line number has the same face. I'm seeing this in
an emacs-lisp-buffer, where this occurs, coincidentally, for multiline
strings and start-of-line comments, which I believe are fontified
differently, IIUC - so-called "syntactic" font-lock"? I don't know if that
is pertinent.

    Each overlay has its before-string property set to the fontified string
    returned by setnu-set-glyph-face.  That string is intended to be
    displayed before the overlay, which starts at the beginning of the line
    and ends after the newline (i.e. at the beginning of the next line).

    I don't know what change in Emacs 22 causes the before-string to inherit
    properties from the adjacent text, but according to the Overlay
    Properties node of the Emacs Lisp manual, all overlays take priority
    over text properties.  So maybe it would work to set the overlay's face
    property in setnu-make-setnu-extent:

         (setnu-set-extent-property e 'face nil) ; or 'default

Without really knowing what I'm doing, I tried each of those. Nil had no
effect. `default' caused the entire buffer to lose its fontification when
the line numbers are shown.

Re: setnu.el / setnu+.el

[Sean Sieger]

That this is helpful would surprise me but ... C-x C-s
intermittently causes another overlay of the last line
number, like this:

1  #!/usr/bin/perl
2  use strict;
3  use warnings;
4    4

toggling setnu-mode turns line numbering off but leaves
the duplicate -- so far, only killing the file removes
the duplicate overlay.

I have not yet noticed a pattern to how or when it occurs.

Re: setnu.el / setnu+.el

[Stefan Monnier]

> (defun setnu-set-glyph-face (g face)
>    (put-text-property 0 (length g) 'face face g))

Most likely the problem is that the face property of your overlay's
after-string is merged with the face property of the buffer text.
I expect that the overlay string's face takes precedence, so if you make
the face inherit from the `default' face, none of the bufer text's face
attributes will "show through".

BTW has anyone tried to re-implement setnu using the `margin' rather than
after-strings?


        Stefan

RE: setnu.el / setnu+.el

[Drew Adams]

    > (defun setnu-set-glyph-face (g face)
    >    (put-text-property 0 (length g) 'face face g))

    Most likely the problem is that the face property of your overlay's
    after-string is merged with the face property of the buffer text.
    I expect that the overlay string's face takes precedence, so if you make
    the face inherit from the `default' face, none of the bufer text's face
    attributes will "show through".

I'm not knowledgeable in this area. I tried what Kevin suggested, in
setnu-make-setnu-extent:

  (setnu-set-extent-property e 'face 'default)

Is that what you meant also? It removed all fontification in the entire
buffer (when the line numbers were present). The line numbers were
(correctly) bold, but nothing else appeared fontified (colored).

    BTW has anyone tried to re-implement setnu using the `margin'
    rather than after-strings?

Not that I know of. Could you explain the relative advantages and
disadvantages>  (Setnu uses before-strings, not after-strings, BTW.)

Re: setnu.el / setnu+.el

[Kevin Rodgers]

Drew Adams wrote:
>     > (defun setnu-set-glyph-face (g face)
>     >    (put-text-property 0 (length g) 'face face g))
> 
>     Most likely the problem is that the face property of your overlay's
>     after-string is merged with the face property of the buffer text.
>     I expect that the overlay string's face takes precedence, so if you make
>     the face inherit from the `default' face, none of the bufer text's face
>     attributes will "show through".
> 
> I'm not knowledgeable in this area. I tried what Kevin suggested, in
> setnu-make-setnu-extent:
> 
>   (setnu-set-extent-property e 'face 'default)
> 
> Is that what you meant also? It removed all fontification in the entire
> buffer (when the line numbers were present). The line numbers were
> (correctly) bold, but nothing else appeared fontified (colored).

Ah, because the overlay covers the entire line, so its face takes
precedence over the text as well as its before string.

I think what Stefan had in mind is something like:

(defface setnu-line-number-face
   '((t (:inherit default) (:weight bold)))
   "Face used to display the line numbers.")

>     BTW has anyone tried to re-implement setnu using the `margin'
>     rather than after-strings?
> 
> Not that I know of. Could you explain the relative advantages and
> disadvantages>  (Setnu uses before-strings, not after-strings, BTW.)

Is the Emacs 22 Lisp manual available from cvs.savannah.gnu.org?  I
can't find it...

-- 
Kevin Rodgers

Re: setnu.el / setnu+.el

[Stefan Monnier]

> I think what Stefan had in mind is something like:

> (defface setnu-line-number-face
>    '((t (:inherit default) (:weight bold)))
>    "Face used to display the line numbers.")

Yes, exactly.

>> BTW has anyone tried to re-implement setnu using the `margin'
>> rather than after-strings?
>> Not that I know of. Could you explain the relative advantages and
disadvantages> (Setnu uses before-strings, not after-strings, BTW.)

> Is the Emacs 22 Lisp manual available from cvs.savannah.gnu.org?  I
> can't find it...

Yes, it's part of the Emacs distribution.
BTW, the margin is an Emacs-21 feature.


        Stefan

RE: setnu.el / setnu+.el

[Drew Adams]

    > I think what Stefan had in mind is something like:

    > (defface setnu-line-number-face
    >    '((t (:inherit default) (:weight bold)))
    >    "Face used to display the line numbers.")

    Yes, exactly.

OK, thanks. I tried that, adding only this code to file setnu.el (so that it
affects only GNU Emacs):

(unless setnu-running-under-xemacs
  (defface setnu-line-number-face
      '((t (:inherit default) (:weight bold)))
    "Face used to display the line numbers.")
  (setq setnu-line-number-face 'setnu-line-number-face))

(I left the unnecessary face variable, because the rest of the code uses
that, and it is designed to work also with XEmacs.)

Unfortunately, I see no change in behavior. Perhaps someone else would like
to play with this a bit? I personally don't care if the line numbers are
colored, but it would be nice to fix this.

Re: setnu.el / setnu+.el

[Kevin Rodgers]

Stefan Monnier wrote:
>>>BTW has anyone tried to re-implement setnu using the `margin'
>>>rather than after-strings?
>>
>>Is the Emacs 22 Lisp manual available from cvs.savannah.gnu.org?  I
>>can't find it...
> 
> Yes, it's part of the Emacs distribution.
> BTW, the margin is an Emacs-21 feature.

OK, I've had a go at it, but it's not working:

Instead of setting the overlay's before-string property to "...", I
tried setting its display property to ((margin left-margin) "...") plus
the left-margin-width variable to the length of "...".

What that does is make every line of the buffer invisible -- including
the newline and the "..." text, so the buffer appears to be empty.

What am I doing wrong?

Thanks,
-- 
Kevin

RE: setnu.el / setnu+.el

[Drew Adams]

Could someone please explain the relative advantages and disadvantages of
using margin vs overlay? What is expected to be gained by making a change to
using the margin?

Re: setnu.el / setnu+.el

[Stefan Monnier]

> Instead of setting the overlay's before-string property to "...", I
> tried setting its display property to ((margin left-margin) "...") plus
> the left-margin-width variable to the length of "...".

Yes, the use of the display property for such uses is somewhat odd: you have
to use a (dummy) before-string (or after-string) property on an overlay and
place the `display' property on that string.  The dummy string should have
length >= 1.

Typically the code looks something like:

  (let ((ol (make-overlay start end))) ;; start can be equal to end if you want
    (overlay-put ol 'before-string
                 (propertize " " 'display
                             <the intersting stuff>)))

See for instance the code of put-image.


        Stefan

Re: setnu.el / setnu+.el

[Kevin Rodgers]

Stefan Monnier wrote:
>>Instead of setting the overlay's before-string property to "...", I
>>tried setting its display property to ((margin left-margin) "...") plus
>>the left-margin-width variable to the length of "...".
> 
> 
> Yes, the use of the display property for such uses is somewhat odd: you have
> to use a (dummy) before-string (or after-string) property on an overlay and
> place the `display' property on that string.  The dummy string should have
> length >= 1.
> 
> Typically the code looks something like:
> 
>   (let ((ol (make-overlay start end))) ;; start can be equal to end if you want
>     (overlay-put ol 'before-string
>                  (propertize " " 'display
>                              <the intersting stuff>)))
> 
> See for instance the code of put-image.

Yes, the way put-image works is well-documented, in both its doc string
and the Emacs Lisp manual.  But the fact that the display property
doesn't work unless it's a text property of an overlay's before- or
after-string is not documented.

That the display property doesn't work as expected seems to me to be a
bug, and it's definitely a documentation bug that the way to get it to
work is only described in regards to the put-image function.

Thanks,
-- 
Kevin

Re: setnu.el / setnu+.el

[Stefan Monnier]

> But the fact that the display property doesn't work unless it's a text
> property of an overlay's before- or after-string is not documented.

The `display' property works in other caqses as well.  But not the way
you expect: the `display' property causes the text covered by that property
to be replaced on-screen by what the display property says.
Of course, that makes sense for some values of the `display' property but
not for others.


        Stefan

Re: setnu.el / setnu+.el

[Stefan Monnier]

> Could someone please explain the relative advantages and disadvantages of
> using margin vs overlay? What is expected to be gained by making a change
> to using the margin?

Not sure: hopefully it solves the OP's problem with faces.

Maybe it also makes it possible to use things like proportional fonts for
the line numbers, without messing the main buffer text's alignment.


        Stefan