* bug#34952: files with/out final newline look the same no matter what
@ 2019-03-23 5:08 積丹尼 Dan Jacobson
2019-03-23 7:34 ` Eli Zaretskii
2019-03-24 1:07 ` Basil L. Contovounesios
0 siblings, 2 replies; 16+ messages in thread
From: 積丹尼 Dan Jacobson @ 2019-03-23 5:08 UTC (permalink / raw
To: 34952
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2019-03-23 5:08 bug#34952: files with/out final newline look the same no matter what 積丹尼 Dan Jacobson
@ 2019-03-23 7:34 ` Eli Zaretskii
2019-03-24 1:07 ` Basil L. Contovounesios
1 sibling, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2019-03-23 7:34 UTC (permalink / raw
To: 積丹尼 Dan Jacobson; +Cc: 34952
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2019-03-23 5:08 bug#34952: files with/out final newline look the same no matter what 積丹尼 Dan Jacobson
2019-03-23 7:34 ` Eli Zaretskii
@ 2019-03-24 1:07 ` Basil L. Contovounesios
2019-03-24 1:23 ` Basil L. Contovounesios
2020-08-06 19:00 ` Lars Ingebrigtsen
1 sibling, 2 replies; 16+ messages in thread
From: Basil L. Contovounesios @ 2019-03-24 1:07 UTC (permalink / raw
To: 積丹尼 Dan Jacobson; +Cc: 34952
積丹尼 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2019-03-24 1:07 ` Basil L. Contovounesios
@ 2019-03-24 1:23 ` Basil L. Contovounesios
2020-08-06 19:00 ` Lars Ingebrigtsen
1 sibling, 0 replies; 16+ messages in thread
From: Basil L. Contovounesios @ 2019-03-24 1:23 UTC (permalink / raw
To: 積丹尼 Dan Jacobson; +Cc: 34952
"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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2019-03-24 1:07 ` Basil L. Contovounesios
2019-03-24 1:23 ` Basil L. Contovounesios
@ 2020-08-06 19:00 ` Lars Ingebrigtsen
2020-08-07 7:29 ` Lars Ingebrigtsen
1 sibling, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-06 19:00 UTC (permalink / raw
To: Basil L. Contovounesios; +Cc: 34952, 積丹尼 Dan Jacobson
"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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-06 19:00 ` Lars Ingebrigtsen
@ 2020-08-07 7:29 ` Lars Ingebrigtsen
2020-08-07 11:07 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-07 7:29 UTC (permalink / raw
To: Basil L. Contovounesios; +Cc: 34952, 積丹尼 Dan Jacobson
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-07 7:29 ` Lars Ingebrigtsen
@ 2020-08-07 11:07 ` Eli Zaretskii
2020-08-07 11:20 ` Lars Ingebrigtsen
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2020-08-07 11:07 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: contovob, 34952, jidanni
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-07 11:07 ` Eli Zaretskii
@ 2020-08-07 11:20 ` Lars Ingebrigtsen
2020-08-07 12:02 ` Lars Ingebrigtsen
0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-07 11:20 UTC (permalink / raw
To: Eli Zaretskii; +Cc: contovob, 34952, jidanni
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-07 11:20 ` Lars Ingebrigtsen
@ 2020-08-07 12:02 ` Lars Ingebrigtsen
2020-08-07 12:11 ` Eli Zaretskii
2020-08-07 21:54 ` Basil L. Contovounesios
0 siblings, 2 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-07 12:02 UTC (permalink / raw
To: Eli Zaretskii; +Cc: contovob, 34952, jidanni
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-07 12:02 ` Lars Ingebrigtsen
@ 2020-08-07 12:11 ` Eli Zaretskii
2020-08-07 12:17 ` Lars Ingebrigtsen
2020-08-07 14:20 ` Stefan Monnier
2020-08-07 21:54 ` Basil L. Contovounesios
1 sibling, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2020-08-07 12:11 UTC (permalink / raw
To: Lars Ingebrigtsen, Stefan Monnier; +Cc: contovob, 34952, jidanni
> 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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-07 12:11 ` Eli Zaretskii
@ 2020-08-07 12:17 ` Lars Ingebrigtsen
2020-08-07 14:20 ` Stefan Monnier
1 sibling, 0 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-07 12:17 UTC (permalink / raw
To: Eli Zaretskii; +Cc: contovob, 34952, Stefan Monnier, jidanni
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-07 12:11 ` Eli Zaretskii
2020-08-07 12:17 ` Lars Ingebrigtsen
@ 2020-08-07 14:20 ` Stefan Monnier
2020-08-08 9:41 ` Lars Ingebrigtsen
1 sibling, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2020-08-07 14:20 UTC (permalink / raw
To: Eli Zaretskii; +Cc: contovob, 34952, Lars Ingebrigtsen, jidanni
>> > 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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-07 12:02 ` Lars Ingebrigtsen
2020-08-07 12:11 ` Eli Zaretskii
@ 2020-08-07 21:54 ` Basil L. Contovounesios
2020-08-08 9:47 ` Lars Ingebrigtsen
1 sibling, 1 reply; 16+ messages in thread
From: Basil L. Contovounesios @ 2020-08-07 21:54 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: 34952, jidanni
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-07 14:20 ` Stefan Monnier
@ 2020-08-08 9:41 ` Lars Ingebrigtsen
2020-08-08 13:14 ` Stefan Monnier
0 siblings, 1 reply; 16+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-08 9:41 UTC (permalink / raw
To: Stefan Monnier; +Cc: contovob, 34952, jidanni
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-07 21:54 ` Basil L. Contovounesios
@ 2020-08-08 9:47 ` Lars Ingebrigtsen
0 siblings, 0 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-08 9:47 UTC (permalink / raw
To: Basil L. Contovounesios; +Cc: 34952, jidanni
"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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#34952: files with/out final newline look the same no matter what
2020-08-08 9:41 ` Lars Ingebrigtsen
@ 2020-08-08 13:14 ` Stefan Monnier
0 siblings, 0 replies; 16+ messages in thread
From: Stefan Monnier @ 2020-08-08 13:14 UTC (permalink / raw
To: Lars Ingebrigtsen; +Cc: contovob, 34952, jidanni
>> 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
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-08-08 13:14 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-23 5:08 bug#34952: files with/out final newline look the same no matter what 積丹尼 Dan Jacobson
2019-03-23 7:34 ` Eli Zaretskii
2019-03-24 1:07 ` Basil L. Contovounesios
2019-03-24 1:23 ` Basil L. Contovounesios
2020-08-06 19:00 ` Lars Ingebrigtsen
2020-08-07 7:29 ` Lars Ingebrigtsen
2020-08-07 11:07 ` Eli Zaretskii
2020-08-07 11:20 ` Lars Ingebrigtsen
2020-08-07 12:02 ` Lars Ingebrigtsen
2020-08-07 12:11 ` Eli Zaretskii
2020-08-07 12:17 ` Lars Ingebrigtsen
2020-08-07 14:20 ` Stefan Monnier
2020-08-08 9:41 ` Lars Ingebrigtsen
2020-08-08 13:14 ` Stefan Monnier
2020-08-07 21:54 ` Basil L. Contovounesios
2020-08-08 9:47 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.