GNU bug report logs -
#36837
26.2; whitespace-mode: whitespace-line-column is not set to local fill-column
Previous Next
Reported by: tastytea <tastytea <at> tastytea.de>
Date: Mon, 29 Jul 2019 14:40:02 UTC
Severity: minor
Found in version 26.2
Fixed in version 28.1
Done: Noam Postavsky <npostavs <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 36837 in the body.
You can then email your comments to 36837 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Mon, 29 Jul 2019 14:40:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
tastytea <tastytea <at> tastytea.de>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 29 Jul 2019 14:40:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
whitespace-mode will highlight long lines starting at 70 characters
instead of what fill-column is set to, if whitespace-line-column is set
to nil.
To reproduce:
1. Create the file test.cfg with this as the first line:
# -*- fill-column: 200 -*-
2. Run emacs -Q
3. Execute the following commands:
(setq whitespace-line-column nil)
(add-hook 'conf-mode-hook
(lambda () (whitespace-mode)))
4. Open test.cfg and type more than 70 characters
After disabling whitespace-mode and enabling it again,
whitespace-line-column is set correctly to 200.
In GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.8)
of 2019-07-02 built on ventiloplattform
Windowing system distributor 'The X.Org Foundation', version
11.0.12004000 System Description: Gentoo Base System release 2.6
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
test.cfg has auto save data; consider M-x recover-this-file
Making completion list...
Configured using:
'configure --prefix=/usr --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
--localstatedir=/var/lib --disable-silent-rules
--docdir=/usr/share/doc/emacs-26.2
--htmldir=/usr/share/doc/emacs-26.2/html --libdir=/usr/lib64
--program-suffix=-emacs-26 --includedir=/usr/include/emacs-26
--infodir=/usr/share/info/emacs-26 --localstatedir=/var
--enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
--without-compress-install --without-hesiod --without-pop
--with-file-notification=inotify --enable-acl --with-dbus
--with-modules --without-gameuser --with-gpm --without-kerberos
--without-kerberos5 --with-lcms2 --with-xml2 --without-mailutils
--without-selinux --with-gnutls --without-libsystemd --with-threads
--without-wide-int --with-zlib --with-sound=no --with-x --without-ns
--without-gconf --without-gsettings --with-toolkit-scroll-bars
--with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-xpm
--with-imagemagick --with-xft --without-cairo --without-libotf
--without-m17n-flt --with-x-toolkit=gtk3 --with-xwidgets
'CFLAGS=-march=native -O2 -pipe' CPPFLAGS= 'LDFLAGS=-Wl,-O1
-Wl,--as-needed''
Configured features:
XPM JPEG TIFF GIF PNG RSVG GPM DBUS GLIB NOTIFY ACL GNUTLS LIBXML2
FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS
XWIDGETS LCMS2
Important settings:
value of $LC_CTYPE: de_DE.utf8
value of $LC_TIME: en_DK.UTF-8
value of $LANG: de_DE.utf8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Conf[Space]
Minor modes in effect:
whitespace-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
easymenu mml-sec password-cache epa derived epg epg-config gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils disp-table whitespace conf-mode edmacro
kmacro cl-loaddefs cl-lib elec-pair time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
font-render-setting xwidget-internal move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)
Memory information:
((conses 16 100238 7390)
(symbols 48 20661 1)
(miscs 40 61 129)
(strings 32 29484 1113)
(string-bytes 1 794338)
(vectors 16 15267)
(vector-slots 8 515682 9350)
(floats 8 51 66)
(intervals 56 351 0)
(buffers 992 14))
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 14:58:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Mon, 29 Jul 2019 11:17:56 +0200
tastytea <at> tastytea.de wrote:
> whitespace-mode will highlight long lines starting at 70 characters
> instead of what fill-column is set to, if whitespace-line-column is set
> to nil.
>
> To reproduce:
>
> 1. Create the file test.cfg with this as the first line:
>
> # -*- fill-column: 200 -*-
>
> 2. Run emacs -Q
>
> 3. Execute the following commands:
>
> (setq whitespace-line-column nil)
> (add-hook 'conf-mode-hook
> (lambda () (whitespace-mode)))
>
> 4. Open test.cfg and type more than 70 characters
>
> After disabling whitespace-mode and enabling it again,
> whitespace-line-column is set correctly to 200.
Yes, unfortunately, file-local variables are only setup (via
`hack-local-variables') _after_ the mode hooks are run (cf.
`run-mode-hooks'), so `whitespace-color-on' still sees the original
`fill-column' the first time.
Intuitively this order seems backwards to me, but I assume there must be
a (good?) reason? I'd like to hear it, in any case.
You can work around this by hacking^W having `hack-local-variables' also
run in your hook function:
(add-hook 'conf-mode-hook
(lambda () (hack-local-variables) (whitespace-mode))
BTW, it's usually better (e.g. for debugging purposes,
removal/modification etc.) not to put lambdas into hooks. If you only
need a particular mode, i.e. a single function/command, the lambda is
redundant anyway:
(add-hook 'some-hook #'some-mode)
If you need more I suggest defining a named function.
HTH,
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 15:05:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Aug 02 2019, Štěpán Němec <stepnem <at> gmail.com> wrote:
> Yes, unfortunately, file-local variables are only setup (via
> `hack-local-variables') _after_ the mode hooks are run (cf.
> `run-mode-hooks'), so `whitespace-color-on' still sees the original
> `fill-column' the first time.
>
> Intuitively this order seems backwards to me, but I assume there must be
> a (good?) reason? I'd like to hear it, in any case.
I'd guess the reason is that file local variables should override mode
stettings.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 15:12:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Fri, 02 Aug 2019 17:04:35 +0200
Andreas Schwab wrote:
> On Aug 02 2019, Štěpán Němec <stepnem <at> gmail.com> wrote:
>
>> Yes, unfortunately, file-local variables are only setup (via
>> `hack-local-variables') _after_ the mode hooks are run (cf.
>> `run-mode-hooks'), so `whitespace-color-on' still sees the original
>> `fill-column' the first time.
>>
>> Intuitively this order seems backwards to me, but I assume there must be
>> a (good?) reason? I'd like to hear it, in any case.
>
> I'd guess the reason is that file local variables should override mode
> stettings.
Sure, but isn't that precisely an argument for the reverse order?
Typically those settings are in defvars/defcustoms and thus if set
before loading the library the user value is respected. And on the other
hand those variables are often used for setup (during loading) which is
not automatically redone when modifying the value after the library is
loaded (such as is the very case of this report), unless using some of
the customize machinery, typically interactively.
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 15:16:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Aug 02 2019, Štěpán Němec <stepnem <at> gmail.com> wrote:
> On Fri, 02 Aug 2019 17:04:35 +0200
> Andreas Schwab wrote:
>
>> On Aug 02 2019, Štěpán Němec <stepnem <at> gmail.com> wrote:
>>
>>> Yes, unfortunately, file-local variables are only setup (via
>>> `hack-local-variables') _after_ the mode hooks are run (cf.
>>> `run-mode-hooks'), so `whitespace-color-on' still sees the original
>>> `fill-column' the first time.
>>>
>>> Intuitively this order seems backwards to me, but I assume there must be
>>> a (good?) reason? I'd like to hear it, in any case.
>>
>> I'd guess the reason is that file local variables should override mode
>> stettings.
>
> Sure, but isn't that precisely an argument for the reverse order?
No. File local variables should have the last say.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 15:21:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 36837 <at> debbugs.gnu.org (full text, mbox):
> From: Štěpán Němec
> <stepnem <at> gmail.com>
> Date: Fri, 02 Aug 2019 17:11:39 +0200
> Cc: tastytea <tastytea <at> tastytea.de>, 36837 <at> debbugs.gnu.org
>
> On Fri, 02 Aug 2019 17:04:35 +0200
> Andreas Schwab wrote:
>
> > I'd guess the reason is that file local variables should override mode
> > settings.
>
> Sure, but isn't that precisely an argument for the reverse order?
No. The logic here is that a mode hook is more general than
file-local variables (because a mode hook affects _all_ files that are
visited with that mode).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 15:23:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Fri, 02 Aug 2019 17:15:07 +0200
Andreas Schwab wrote:
>> Sure, but isn't that precisely an argument for the reverse order?
>
> No. File local variables should have the last say.
Right. As illustrated by this bug report. :-D
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 15:31:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Fri, 02 Aug 2019 18:20:13 +0300
Eli Zaretskii wrote:
>> Sure, but isn't that precisely an argument for the reverse order?
>
> No. The logic here is that a mode hook is more general than
> file-local variables (because a mode hook affects _all_ files that are
> visited with that mode).
Precisely. Maybe I'm being thick, but have you (and Andreas) actually
read what I wrote? I.e., instead of restating the obvious (mode hooks
are more general and should be overridden by file-local variables; no
disagreement there), could you provide some concrete counter-arguments
to my arguments?
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 15:34:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Aug 02 2019, Štěpán Němec <stepnem <at> gmail.com> wrote:
> Right. As illustrated by this bug report. :-D
No. It has nothing to do with file-local variables.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 18:53:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 36837 <at> debbugs.gnu.org (full text, mbox):
> From: Štěpán Němec <stepnem <at> gmail.com>
> Cc: schwab <at> linux-m68k.org, tastytea <at> tastytea.de, 36837 <at> debbugs.gnu.org
> Date: Fri, 02 Aug 2019 17:30:41 +0200
>
> Maybe I'm being thick, but have you (and Andreas) actually read what
> I wrote?
Do you realize how rude this kind of question sounds?
> I.e., instead of restating the obvious (mode hooks are more general
> and should be overridden by file-local variables; no disagreement
> there), could you provide some concrete counter-arguments to my
> arguments?
We just did, both of us.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 19:11:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Fri, 02 Aug 2019 21:51:51 +0300
Eli Zaretskii wrote:
>> Maybe I'm being thick, but have you (and Andreas) actually read what
>> I wrote?
>
> Do you realize how rude this kind of question sounds?
If I did I definitely wouldn't have posed it that way and I'm sorry if
that upset you. I simply stated what I (still) mean: it seems to me that
your and Andreas's response did not address what I wrote, and I can only
think of two possible explanations: either you actually really did and
somehow I don't realize it (i.e., I'm stupid, thick or however one might
call it, or simply misunderstanding), or you must be misunderstanding
what I wrote.
>> I.e., instead of restating the obvious (mode hooks are more general
>> and should be overridden by file-local variables; no disagreement
>> there), could you provide some concrete counter-arguments to my
>> arguments?
>
> We just did, both of us.
OK. I don't see it that way or just don't get it, I'm sorry. No need to
assume ill will or offense, I have no idea why I should want to waste
our time that (or any other) way.
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 19:29:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 36837 <at> debbugs.gnu.org (full text, mbox):
Štěpán Němec <stepnem <at> gmail.com> writes:
> On Fri, 02 Aug 2019 17:04:35 +0200
> Andreas Schwab wrote:
>
>> On Aug 02 2019, Štěpán Němec <stepnem <at> gmail.com> wrote:
>>
>>> Yes, unfortunately, file-local variables are only setup (via
>>> `hack-local-variables') _after_ the mode hooks are run
>>
>> I'd guess the reason is that file local variables should override mode
>> stettings.
>
> Sure, but isn't that precisely an argument for the reverse order?
> Typically those settings are in defvars/defcustoms and thus if set
> before loading the library the user value is respected.
It sounds like you are confusing defcustom settings with file-local
variable settings. Those are two very different things. At any rate,
there is no "library being loaded" here.
See also (info "(emacs) File Variables")
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 19:40:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 36837 <at> debbugs.gnu.org (full text, mbox):
> From: Štěpán Němec <stepnem <at> gmail.com>
> Cc: schwab <at> linux-m68k.org, tastytea <at> tastytea.de, 36837 <at> debbugs.gnu.org
> Date: Fri, 02 Aug 2019 21:10:34 +0200
>
> >> I.e., instead of restating the obvious (mode hooks are more general
> >> and should be overridden by file-local variables; no disagreement
> >> there), could you provide some concrete counter-arguments to my
> >> arguments?
> >
> > We just did, both of us.
>
> OK. I don't see it that way or just don't get it, I'm sorry.
Once again: file-local variables is a way for a file to override
_every_ other possible setting. That includes any user customizations
and everything else, because all of the other means to give variables
non-default values are not specific to one file, they always affect
more than one.
If that doesn't address your arguments, please consider elaborating
those arguments.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 19:46:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Fri, 02 Aug 2019 15:28:01 -0400
Noam Postavsky wrote:
> It sounds like you are confusing defcustom settings with file-local
> variable settings. Those are two very different things. At any rate,
> there is no "library being loaded" here.
>
> See also (info "(emacs) File Variables")
I'm not sure what you mean.
For me there are two issues here: the particular case described in this
bug report, and the (related) general issue of ordering modes and
file-local variable settings inside `run-mode-hooks'.
You seem to be responding to the latter part of what I wrote. Whether a
library will need to be loaded or not depends on whether the feature
required by a particular hook or variable value (e.g. in case of "eval"
file-local variables) is already provided or not.
In this particular case, if you follow OP's recipe (emacs -Q),
`whitespace-mode' is autoloaded, so the whitespace library will be
loaded only at the point the hook is run.
Really, isn't this how we all customize all kinds of variables? In your
init file you have (setq some-var some-value) (or the equivalent
customize forms if you're into that) even before the relevant feature is
provided (by loading the library), and the defvar form in the pertinent
library will of course not clobber the user-specified value. Unless I'm
missing something, it works the same way if you `hack-local-variables'
before loading the whitespace.el library in this particular case.
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 21:15:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 36837 <at> debbugs.gnu.org (full text, mbox):
Štěpán Němec <stepnem <at> gmail.com> writes:
> On Fri, 02 Aug 2019 15:28:01 -0400
> Noam Postavsky wrote:
>
>> It sounds like you are confusing defcustom settings with file-local [...]
>
> I'm not sure what you mean.
I think it was me who was confused about what you meant. See the last
section of this message.
> Whether a library will need to be loaded or not depends on whether the
> feature required by a particular hook or variable value (e.g. in case
> of "eval" file-local variables) is already provided or not.
>
> In this particular case, if you follow OP's recipe (emacs -Q),
> `whitespace-mode' is autoloaded, so the whitespace library will be
> loaded only at the point the hook is run.
You are right that, strictly speaking, whitespace.el does get loaded
while opening the file (via running conf-mode-hook). But if I modify
the OP's recipe by adding a require:
(require 'whitespace)
(setq whitespace-line-column nil)
(add-hook 'conf-mode-hook
(lambda () (whitespace-mode)))
I get the same result. So I don't think the autoloading is relevant.
> Really, isn't this how we all customize all kinds of variables? In your
> init file you have (setq some-var some-value) (or the equivalent
> customize forms if you're into that) even before the relevant feature is
> provided (by loading the library), and the defvar form in the pertinent
> library will of course not clobber the user-specified value. Unless I'm
> missing something, it works the same way if you `hack-local-variables'
> before loading the whitespace.el library in this particular case.
Oh, the digression into the defvars/defcustom thing was just an analogy?
Ignore my previous message then.
If I've now understood correctly, you are assuming the file-local
setting is a kind of default setting, like (defvar foo DEFAULT) which
you expect to override from your init file. But the intended usage is
that you do:
(setq some-var some-value) in your init file as a global setting,
(add-hook some-mode-hook (lambda () (setq some-var another-value)) as
a mode-specific seting, and
-*- some-var: yet-another-value -*- as a file-specific setting.
So they go in that order: global may be overridden by mode-specific,
which may be overriden by file-specific.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 21:51:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Fri, 02 Aug 2019 17:14:34 -0400
Noam Postavsky wrote:
> (setq some-var some-value) in your init file as a global setting,
> (add-hook some-mode-hook (lambda () (setq some-var another-value)) as
> a mode-specific seting, and
> -*- some-var: yet-another-value -*- as a file-specific setting.
>
> So they go in that order: global may be overridden by mode-specific,
> which may be overriden by file-specific.
Yes, but OP's case is a bit more subtle, as I described in my very
first e-mail. Maybe a more visual representation will help. Here's
what happens (simplified) when visiting test.cfg during OP's recipe:
1. fill-column is at default value
2. `run-mode-hooks' is called
3. `conf-mode-hook' is run
4. `whitespace-mode' is called
5. `whitespace-color-on' is called, which sets up whitespace-font-lock-keywords,
still with the default value of fill-column
6. `hack-local-variables' is called to parse and apply file-local settings
7. fill-column is set to 200
If what's really intended is that file-local settings prevail as much
as possible, this is a failure. That's why I'm wondering whether
reversing the order wouldn't actually work better, for reasons I
detailed in the reply to Andreas. As this case illustrates, libraries
often do all kinds of setup during load or mode activation, so unless
the relevant settings are applied before that, they don't really take
the desired effect.
Sure, if the order _was_ reversed and the mode hooks run _after_
`hack-local-variables', they could override file-local variable
settings, but I'm wondering how likely such conflicts really are or if
that's really a bad thing at all, given typical usage.
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 02 Aug 2019 21:55:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Aug 02 2019, Štěpán Němec <stepnem <at> gmail.com> wrote:
> Yes, but OP's case is a bit more subtle, as I described in my very
> first e-mail. Maybe a more visual representation will help. Here's
> what happens (simplified) when visiting test.cfg during OP's recipe:
>
> 1. fill-column is at default value
> 2. `run-mode-hooks' is called
> 3. `conf-mode-hook' is run
> 4. `whitespace-mode' is called
> 5. `whitespace-color-on' is called, which sets up whitespace-font-lock-keywords,
> still with the default value of fill-column
> 6. `hack-local-variables' is called to parse and apply file-local settings
> 7. fill-column is set to 200
>
> If what's really intended is that file-local settings prevail as much
> as possible, this is a failure.
It's a failure in whitespace-mode, not in hack-local-variables.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Sat, 03 Aug 2019 09:24:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 36837 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, 03 Aug 2019 09:50:56 +0200
tastytea <at> tastytea.de wrote:
> Maybe whitespace-mode could watch fill-column for changes, at least
> until the file-local variables are loaded?
> There is also the possibility that fill-column is changed afterwards by
> the user, but I guess that's not too common…
Ah, the new variable watcher thing. I suppose that would be a
possibility, though so far its use in Emacs seems to be quite limited.
Less avant-garde perhaps would be to do what's being done for some of
the other regexps already: turn it into a function:
[whitespace.diff (text/x-patch, inline)]
diff --git a/lisp/whitespace.el b/lisp/whitespace.el
index d0368b54a8..a67e5efee5 100644
--- a/lisp/whitespace.el
+++ b/lisp/whitespace.el
@@ -2066,16 +2066,7 @@ whitespace-color-on
,@(when (or (memq 'lines whitespace-active-style)
(memq 'lines-tail whitespace-active-style))
;; Show "long" lines.
- `((,(let ((line-column (or whitespace-line-column fill-column)))
- (format
- "^\\([^\t\n]\\{%s\\}\\|[^\t\n]\\{0,%s\\}\t\\)\\{%d\\}%s\\(.+\\)$"
- tab-width
- (1- tab-width)
- (/ line-column tab-width)
- (let ((rem (% line-column tab-width)))
- (if (zerop rem)
- ""
- (format ".\\{%d\\}" rem)))))
+ `((,#'whitespace-lines-regexp
,(if (memq 'lines whitespace-active-style)
0 ; whole line
2) ; line tail
@@ -2176,6 +2167,19 @@ whitespace-trailing-regexp
(setq status nil))) ;; end of buffer
status))
+(defun whitespace-lines-regexp (limit)
+ (re-search-forward
+ (let ((line-column (or whitespace-line-column fill-column)))
+ (format
+ "^\\([^\t\n]\\{%s\\}\\|[^\t\n]\\{0,%s\\}\t\\)\\{%d\\}%s\\(.+\\)$"
+ tab-width
+ (1- tab-width)
+ (/ line-column tab-width)
+ (let ((rem (% line-column tab-width)))
+ (if (zerop rem)
+ ""
+ (format ".\\{%d\\}" rem)))))
+ limit t))
(defun whitespace-empty-at-bob-regexp (limit)
"Match spaces at beginning of buffer which do not contain the point at \
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Sat, 03 Aug 2019 15:18:04 GMT)
Full text and
rfc822 format available.
Message #59 received at 36837 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 02 Aug 2019 16:57:37 +0200
Štěpán Němec <stepnem <at> gmail.com> wrote:
> On Mon, 29 Jul 2019 11:17:56 +0200
> tastytea <at> tastytea.de wrote:
>
> > whitespace-mode will highlight long lines starting at 70 characters
> > instead of what fill-column is set to, if whitespace-line-column is
> > set to nil.
> > […]
>
> Yes, unfortunately, file-local variables are only setup (via
> `hack-local-variables') _after_ the mode hooks are run (cf.
> `run-mode-hooks'), so `whitespace-color-on' still sees the original
> `fill-column' the first time.
Maybe whitespace-mode could watch fill-column for changes, at least
until the file-local variables are loaded?
There is also the possibility that fill-column is changed afterwards by
the user, but I guess that's not too common…
> You can work around this by hacking^W having `hack-local-variables'
> also run in your hook function:
>
> (add-hook 'conf-mode-hook
> (lambda () (hack-local-variables) (whitespace-mode))
Thanks, that's a better workaround than my solution of setting
whitespace-line-column and restarting whitespace-mode in
find-file-hook. :-)
Kind regards, tastytea
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Mon, 24 Feb 2020 19:57:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 36837 <at> debbugs.gnu.org (full text, mbox):
severity 36837 minor
severity 39427 minor
quit
Štěpán Němec <stepnem <at> gmail.com> writes:
> On Sat, 03 Aug 2019 09:50:56 +0200
> tastytea <at> tastytea.de wrote:
>
>> Maybe whitespace-mode could watch fill-column for changes, at least
>> until the file-local variables are loaded?
>> There is also the possibility that fill-column is changed afterwards by
>> the user, but I guess that's not too common…
>
> Ah, the new variable watcher thing. I suppose that would be a
> possibility, though so far its use in Emacs seems to be quite limited.
It's intended mainly for debugging.
> Less avant-garde perhaps would be to do what's being done for some of
> the other regexps already: turn it into a function:
I think this would make more sense, and also fix #39427 "whitespace-mode
doesn't track fill-column changes".
Severity set to 'minor' from 'normal'
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 24 Feb 2020 19:57:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Mon, 24 Feb 2020 20:13:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 36837 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
tags 36837 patch
thanks
On Mon, 24 Feb 2020 14:56:25 -0500
Noam Postavsky wrote:
>> Less avant-garde perhaps would be to do what's being done for some of
>> the other regexps already: turn it into a function:
>
> I think this would make more sense, and also fix #39427 "whitespace-mode
> doesn't track fill-column changes".
FWIW, I have been running with this change ever since I suggested it.
Here it is as proper patch with a commit message on top of recent
master. Let me know if anything else is needed (I've been a bit out of
the loop lately but I think it could still go to emacs-27, and doesn't
warrant a NEWS entry?).
--
Štěpán
[0001-whitespace-Turn-long-lines-regexp-into-a-function-bu.patch (text/x-patch, inline)]
From a4fe6400e6a5ddf3f63d6f059058ed2abf04f1b5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=A0t=C4=9Bp=C3=A1n=20N=C4=9Bmec?= <stepnem <at> gmail.com>
Date: Thu, 29 Aug 2019 19:32:08 +0200
Subject: [PATCH] whitespace: Turn long lines regexp into a function
(bug#36837)
* lisp/whitespace.el (whitespace-color-on): Turn long lines regexp
into a function to ensure it uses current 'whitespace-line-column'
and 'fill-column' values. (Bug#36837)
(whitespace-lines-regexp): New function.
---
lisp/whitespace.el | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/lisp/whitespace.el b/lisp/whitespace.el
index 0137ddcf04..47434bf3d2 100644
--- a/lisp/whitespace.el
+++ b/lisp/whitespace.el
@@ -2067,16 +2067,7 @@ whitespace-color-on
,@(when (or (memq 'lines whitespace-active-style)
(memq 'lines-tail whitespace-active-style))
;; Show "long" lines.
- `((,(let ((line-column (or whitespace-line-column fill-column)))
- (format
- "^\\([^\t\n]\\{%s\\}\\|[^\t\n]\\{0,%s\\}\t\\)\\{%d\\}%s\\(.+\\)$"
- tab-width
- (1- tab-width)
- (/ line-column tab-width)
- (let ((rem (% line-column tab-width)))
- (if (zerop rem)
- ""
- (format ".\\{%d\\}" rem)))))
+ `((,#'whitespace-lines-regexp
,(if (memq 'lines whitespace-active-style)
0 ; whole line
2) ; line tail
@@ -2177,6 +2168,19 @@ whitespace-trailing-regexp
(setq status nil))) ;; end of buffer
status))
+(defun whitespace-lines-regexp (limit)
+ (re-search-forward
+ (let ((line-column (or whitespace-line-column fill-column)))
+ (format
+ "^\\([^\t\n]\\{%s\\}\\|[^\t\n]\\{0,%s\\}\t\\)\\{%d\\}%s\\(.+\\)$"
+ tab-width
+ (1- tab-width)
+ (/ line-column tab-width)
+ (let ((rem (% line-column tab-width)))
+ (if (zerop rem)
+ ""
+ (format ".\\{%d\\}" rem)))))
+ limit t))
(defun whitespace-empty-at-bob-regexp (limit)
"Match spaces at beginning of buffer which do not contain the point at \
--
2.25.1
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Wed, 26 Feb 2020 00:39:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 36837 <at> debbugs.gnu.org (full text, mbox):
Štěpán Němec <stepnem <at> gmail.com> writes:
> Here it is as proper patch with a commit message on top of recent
> master. Let me know if anything else is needed (I've been a bit out of
> the loop lately but I think it could still go to emacs-27, and doesn't
> warrant a NEWS entry?).
I've been somewhat out of things as well, but I believe emacs-27 is
still open for bug fixes. And I would classify this as a bug fix, so no
NEWS needed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 28 Feb 2020 05:02:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 36837 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Tue, 25 Feb 2020 19:38:21 -0500
> Cc: tastytea <tastytea <at> tastytea.de>, 36837 <at> debbugs.gnu.org
>
> Štěpán Němec <stepnem <at> gmail.com> writes:
>
> > Here it is as proper patch with a commit message on top of recent
> > master. Let me know if anything else is needed (I've been a bit out of
> > the loop lately but I think it could still go to emacs-27, and doesn't
> > warrant a NEWS entry?).
>
> I've been somewhat out of things as well, but I believe emacs-27 is
> still open for bug fixes. And I would classify this as a bug fix, so no
> NEWS needed.
I won't argue if this is a bug fix or not, but why is it urgent to
have this in Emacs 27?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Fri, 28 Feb 2020 08:15:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 36837 <at> debbugs.gnu.org (full text, mbox):
On Fri, 28 Feb 2020 07:01:18 +0200
Eli Zaretskii wrote:
>> From: Noam Postavsky <npostavs <at> gmail.com>
>> I've been somewhat out of things as well, but I believe emacs-27 is
>> still open for bug fixes. And I would classify this as a bug fix, so no
>> NEWS needed.
>
> I won't argue if this is a bug fix or not, but why is it urgent to
> have this in Emacs 27?
I find that question hard to address (isn't the "bug fix or not", and of
course _your_ and other maintainers' personal definition of "bug fix"
and "urgent" precisely the crucial factors for answering it?).
Personally I don't see any reason not to consider behaviours observed in
both bug reports bugs, but "urgent" certainly sounds more dramatic than
I feel about it. IOW, I don't feel strongly about having to have this in
27, especially in case of any doubts on maintainers' part.
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#36837; Package
emacs.
(Mon, 02 Mar 2020 04:00:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 36837 <at> debbugs.gnu.org (full text, mbox):
close 36837 28.1
close 39427 28.1
quit
Štěpán Němec <stepnem <at> gmail.com> writes:
> Personally I don't see any reason not to consider behaviours observed in
> both bug reports bugs, but "urgent" certainly sounds more dramatic than
> I feel about it. IOW, I don't feel strongly about having to have this in
> 27, especially in case of any doubts on maintainers' part.
Yeah, I don't think it's really important enough to spend more time
thinking about where to put it. I've just gone ahead and pushed to
master.
[1: 1939f7580b]: 2020-03-01 22:54:32 -0500
whitespace: Turn long lines regexp into a function (bug#36837)
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1939f7580bd283286dce8be7c99ab5dec1bb0814
bug marked as fixed in version 28.1, send any further explanations to
36837 <at> debbugs.gnu.org and tastytea <tastytea <at> tastytea.de>
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 02 Mar 2020 04:00:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 30 Mar 2020 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 26 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.