GNU bug report logs - #34952
files with/out final newline look the same no matter what

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34952 in the body.
You can then email your comments to 34952 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: files with/out final newline look the same no matter what
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.

Message #8 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 34952 <at> debbugs.gnu.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Sat, 23 Mar 2019 09:34:04 +0200

> From: 積丹尼 Dan Jacobson
> 	<jidanni <at> 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.

Message #11 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 34952 <at> debbugs.gnu.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Sun, 24 Mar 2019 01:07:26 +0000

積丹尼 Dan Jacobson <jidanni <at> 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

Message #14 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 34952 <at> debbugs.gnu.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Sun, 24 Mar 2019 01:23:20 +0000

"Basil L. Contovounesios" <contovob <at> 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

Message #17 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 34952 <at> debbugs.gnu.org,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Thu, 06 Aug 2020 21:00:44 +0200

"Basil L. Contovounesios" <contovob <at> 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

Message #20 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 34952 <at> debbugs.gnu.org,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Fri, 07 Aug 2020 09:29:20 +0200

Lars Ingebrigtsen <larsi <at> 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

Message #27 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: contovob <at> tcd.ie, 34952 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Fri, 07 Aug 2020 14:07:17 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 07 Aug 2020 09:29:20 +0200
> Cc: 34952 <at> debbugs.gnu.org,
>  積丹尼 Dan Jacobson <jidanni <at> 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.

Message #30 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: contovob <at> tcd.ie, 34952 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Fri, 07 Aug 2020 13:20:53 +0200

Eli Zaretskii <eliz <at> 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

Message #33 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: contovob <at> tcd.ie, 34952 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Fri, 07 Aug 2020 14:02:31 +0200

Lars Ingebrigtsen <larsi <at> 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

Message #36 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: contovob <at> tcd.ie, 34952 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Fri, 07 Aug 2020 15:11:43 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: contovob <at> tcd.ie,  34952 <at> debbugs.gnu.org,  jidanni <at> jidanni.org
> Date: Fri, 07 Aug 2020 14:02:31 +0200
> 
> Lars Ingebrigtsen <larsi <at> 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?

Message #39 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: contovob <at> tcd.ie, 34952 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, jidanni <at> jidanni.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Fri, 07 Aug 2020 14:17:38 +0200

Eli Zaretskii <eliz <at> 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

Message #42 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: contovob <at> tcd.ie, 34952 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 jidanni <at> jidanni.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Fri, 07 Aug 2020 10:20:50 -0400

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

Message #45 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 34952 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, jidanni <at> jidanni.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Fri, 07 Aug 2020 22:54:56 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Lars Ingebrigtsen <larsi <at> 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

Message #48 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: contovob <at> tcd.ie, 34952 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 jidanni <at> jidanni.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Sat, 08 Aug 2020 11:41:30 +0200

Stefan Monnier <monnier <at> 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

Message #51 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 34952 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, jidanni <at> jidanni.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Sat, 08 Aug 2020 11:47:05 +0200

"Basil L. Contovounesios" <contovob <at> 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

Message #54 received at 34952 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: contovob <at> tcd.ie, 34952 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 jidanni <at> jidanni.org
Subject: Re: bug#34952: files with/out final newline look the same no matter
 what
Date: Sat, 08 Aug 2020 09:14:35 -0400

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

Previous Next

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