bug#34952: files with/out final newline look the same no matter what

bug#34952: files with/out final newline look the same no matter what

[積丹尼 Dan Jacobson]

indicate-empty-lines is great, but still doesn't show the user the difference between
$ echo    abcd > fileA
$ echo -n abcd > fileB
$ emacs file*
Therefore some new variable is needed.
No I'm not talking about writing files, I'm just talking about how they
look when opened.

bug#34952: files with/out final newline look the same no matter what

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
> 	<jidanni@jidanni.org>
> Date: Sat, 23 Mar 2019 13:08:06 +0800
> 
> indicate-empty-lines is great, but still doesn't show the user the difference between
> $ echo    abcd > fileA
> $ echo -n abcd > fileB
> $ emacs file*
> Therefore some new variable is needed.
> No I'm not talking about writing files, I'm just talking about how they
> look when opened.

You want a visual indication of a newline?  Then turn on
whitespace-mode, it does that.

bug#34952: files with/out final newline look the same no matter what

[Basil L. Contovounesios]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> indicate-empty-lines is great, but still doesn't show the user the difference between
> $ echo    abcd > fileA
> $ echo -n abcd > fileB
> $ emacs file*
> Therefore some new variable is needed.
> No I'm not talking about writing files, I'm just talking about how they
> look when opened.

I know and make use of two different customisations to indicate missing
newlines at EOF.

The first is built-in and (probably) more subtle/elegant/efficient, but
relies on the fringe, so only works on graphical frames:

  (setq-default indicate-buffer-boundaries t)

See (info "(emacs) Displaying Boundaries") and
(info "(elisp) Fringe Indicators") for details and
variations of this feature.

The second uses font-lock-mode via hi-lock-mode.  You can configure
font-lock-mode to highlight missing EOF newlines directly, without
relying on hi-lock-mode, but the latter conveniently provides the global
minor mode global-hi-lock-mode and blacklist hi-lock-exclude-modes for
easy customisation.  Here are the incantations:

  (defun my-hi-lock-no-eof-nl ()
    "Highlight missing trailing EOF newlines."
    (setf (alist-get "^.+\\'" hi-lock-interactive-patterns nil nil #'equal)
          '(0 'trailing-whitespace prepend)))

  (add-hook 'hi-lock-mode-hook #'my-hi-lock-no-eof-nl)
  (global-hi-lock-mode)

You can, of course, change trailing-whitespace to a face of your
choosing.  See (info "(emacs) Highlight Interactively") for more
information on hi-lock-mode.

Having said all this, I still think it would be nice to add a
whitespace-style setting which visualised missing EOF newlines.

-- 
Basil

bug#34952: files with/out final newline look the same no matter what

[Basil L. Contovounesios]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>   (defun my-hi-lock-no-eof-nl ()
>     "Highlight missing trailing EOF newlines."
>     (setf (alist-get "^.+\\'" hi-lock-interactive-patterns nil nil #'equal)
>           '(0 'trailing-whitespace prepend)))

Oops, you probably don't want to use setf+alist-get here.  Better just:

  (add-to-list 'hi-lock-interactive-patterns
               '("^.+\\'" 0 'trailing-whitespace prepend))

-- 
Basil

bug#34952: files with/out final newline look the same no matter what

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Having said all this, I still think it would be nice to add a
> whitespace-style setting which visualised missing EOF newlines.

Yeah, that seems like an obvious thing to add, I think?  I've had a
quick peek at whitespace.el, and it doesn't look that difficult to add.

So I think I'll take a whack at that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34952: files with/out final newline look the same no matter what

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yeah, that seems like an obvious thing to add, I think?  I've had a
> quick peek at whitespace.el, and it doesn't look that difficult to add.

I'm not familiar with the code in whitespace.el, but it seemed totally
trivial to add (since Emacs has a regexp for end-of-buffer), so I've now
added it.  Give a shout if it doesn't work properly...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34952: files with/out final newline look the same no matter what

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 07 Aug 2020 09:29:20 +0200
> Cc: 34952@debbugs.gnu.org,
>  積丹尼 Dan Jacobson <jidanni@jidanni.org>
> 
> I'm not familiar with the code in whitespace.el, but it seemed totally
> trivial to add (since Emacs has a regexp for end-of-buffer), so I've now
> added it.  Give a shout if it doesn't work properly...

<SHOUT>
This addition causes the last character highlighted in annoying red
color when typing at the end of the buffer.  Can we do better by NOT
highlighting character at EOB when point is at EOB, please?  That
would be in line with whitespace-mode behavior regarding trailing
whitespace that precedes point.
</SHOUT>

Thanks.

bug#34952: files with/out final newline look the same no matter what

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> <SHOUT>
> This addition causes the last character highlighted in annoying red
> color when typing at the end of the buffer.  Can we do better by NOT
> highlighting character at EOB when point is at EOB, please?  That
> would be in line with whitespace-mode behavior regarding trailing
> whitespace that precedes point.
> </SHOUT>

Oh, yeah, that makes sense.  I'll fix that.

And the colour should probably be a bit more subtle than it is.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34952: files with/out final newline look the same no matter what

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oh, yeah, that makes sense.  I'll fix that.

Actually, I don't know how.  How do you ask, when you're in the
font-lock machinery, what the original point was?  Like here:

       ,@(when (memq 'missing-newline-at-eof whitespace-active-style)
           ;; Show missing newline.
           `(("[^\n]\\'" 0 (if .... something) t)))))

By the way, have I whined about how difficult debugging font-lock stuff
is?  I can't put a `debug' in there, for instance, to examine the
calling sequence, which would probably tell me what I need to know.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34952: files with/out final newline look the same no matter what

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: contovob@tcd.ie,  34952@debbugs.gnu.org,  jidanni@jidanni.org
> Date: Fri, 07 Aug 2020 14:02:31 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Oh, yeah, that makes sense.  I'll fix that.
> 
> Actually, I don't know how.  How do you ask, when you're in the
> font-lock machinery, what the original point was?  Like here:
> 
>        ,@(when (memq 'missing-newline-at-eof whitespace-active-style)
>            ;; Show missing newline.
>            `(("[^\n]\\'" 0 (if .... something) t)))))

What, calling 'point' doesn't work?  Then maybe Stefan could help us
out.

> By the way, have I whined about how difficult debugging font-lock stuff
> is?  I can't put a `debug' in there, for instance, to examine the
> calling sequence, which would probably tell me what I need to know.

I think Stefan posted some advice at some point?

bug#34952: files with/out final newline look the same no matter what

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Actually, I don't know how.  How do you ask, when you're in the
>> font-lock machinery, what the original point was?  Like here:
>> 
>>        ,@(when (memq 'missing-newline-at-eof whitespace-active-style)
>>            ;; Show missing newline.
>>            `(("[^\n]\\'" 0 (if .... something) t)))))
>
> What, calling 'point' doesn't work?  Then maybe Stefan could help us
> out.

No, (point) here has already been moved by the font locking machinery...

>> By the way, have I whined about how difficult debugging font-lock stuff
>> is?  I can't put a `debug' in there, for instance, to examine the
>> calling sequence, which would probably tell me what I need to know.
>
> I think Stefan posted some advice at some point?

Not unlikely!  I keep forgetting stuff...  Perhaps Stefan can remind me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34952: files with/out final newline look the same no matter what

[Stefan Monnier]

>> > Oh, yeah, that makes sense.  I'll fix that.
>> Actually, I don't know how.  How do you ask, when you're in the
>> font-lock machinery, what the original point was?

font-lock is "per buffer" whereas point is "per window", so I'm not sure
what "*the* original point" should mean.

>> Like here:
>>        ,@(when (memq 'missing-newline-at-eof whitespace-active-style)
>>            ;; Show missing newline.
>>            `(("[^\n]\\'" 0 (if .... something) t)))))
> What, calling 'point' doesn't work?  Then maybe Stefan could help us
> out.
>> By the way, have I whined about how difficult debugging font-lock stuff
>> is?  I can't put a `debug' in there, for instance, to examine the
>> calling sequence, which would probably tell me what I need to know.
> I think Stefan posted some advice at some point?

You can try `jit-lock-debug-mode` (which delays the jit-lock from
"within redisplay" to "the next idle time").  Otherwise, you can set
`font-lock-support-mode` to nil, then turn font-lock-mode off and back
on (after which font-lock is triggered via `after-change-functions`).


        Stefan

bug#34952: files with/out final newline look the same no matter what

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Oh, yeah, that makes sense.  I'll fix that.
>
> Actually, I don't know how.  How do you ask, when you're in the
> font-lock machinery, what the original point was?  Like here:
>
>        ,@(when (memq 'missing-newline-at-eof whitespace-active-style)
>            ;; Show missing newline.
>            `(("[^\n]\\'" 0 (if .... something) t)))))

Isn't it possible to just copy what whitespace-trailing-regexp is doing?
I.e. use a function instead of a regexp?  (I don't think the regexp
construct \= would help much here.)

> By the way, have I whined about how difficult debugging font-lock stuff
> is?  I can't put a `debug' in there, for instance, to examine the
> calling sequence, which would probably tell me what I need to know.

Would font-lock-studio help?  (I haven't tried it.)
https://github.com/Lindydancer/font-lock-studio

Thanks,

-- 
Basil

bug#34952: files with/out final newline look the same no matter what

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> font-lock is "per buffer" whereas point is "per window", so I'm not sure
> what "*the* original point" should mean.

I guess it's not a well-defined question...  but some action triggered
the fontification, and I guess what's interesting question here is "what
was point in the window that triggered the fontification"?

> You can try `jit-lock-debug-mode` (which delays the jit-lock from
> "within redisplay" to "the next idle time").  Otherwise, you can set
> `font-lock-support-mode` to nil, then turn font-lock-mode off and back
> on (after which font-lock is triggered via `after-change-functions`).

I see; thanks.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34952: files with/out final newline look the same no matter what

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Isn't it possible to just copy what whitespace-trailing-regexp is doing?
> I.e. use a function instead of a regexp?  (I don't think the regexp
> construct \= would help much here.)

\=
    matches the empty string, but only at point.

Heh, I didn't even know about that one...

Ah, yeah:

(defvar whitespace-point (point)
  "Used to save locally current point value.
Used by function `whitespace-trailing-regexp' (which see).")

So that's basically the same problem I'm having here, and it's solved by
machinery that keeps that variable updated in whitespace buffers,
probably because font-lock doesn't provide that information?

>> By the way, have I whined about how difficult debugging font-lock stuff
>> is?  I can't put a `debug' in there, for instance, to examine the
>> calling sequence, which would probably tell me what I need to know.
>
> Would font-lock-studio help?  (I haven't tried it.)
> https://github.com/Lindydancer/font-lock-studio

Interesting...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34952: files with/out final newline look the same no matter what

[Stefan Monnier]

>> font-lock is "per buffer" whereas point is "per window", so I'm not sure
>> what "*the* original point" should mean.
> I guess it's not a well-defined question...  but some action triggered
> the fontification, and I guess what's interesting question here is "what
> was point in the window that triggered the fontification"?

In GNU ELPA's `nhexl-mode` I had a similar need, which I solved by using
a `nhexl--point` variable (updated via `post-command-hook`) to keep
track of `point`.

It does mean that the package can't properly handle the case where the
buffer is simultaneously displayed in several windows :-(


        Stefan