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