Discussion:
Replace use of obsolete Emacs feature "write-file-hooks"
(too old to reply)
Glenn Morris
2018-03-07 01:27:58 UTC
Permalink
Hi,

Many gnulib files contain an Emacs-specific feature like the
following, eg in build-aux/gitlog-to-changelog:

eval: (add-hook 'write-file-hooks 'time-stamp)

write-file-hooks is obsolete since Emacs 22.1 (released June 2007),
and hopefully can be removed from Emacs one day.

Please replace "write-file-hooks" with "before-save-hook".

(The literal replacement for "write-file-hooks" is "write-file-functions",
but for adding a time-stamp like you do above, "before-save-hook" is
recommended. Both replacements exist since Emacs 22.1.)

Thanks!
Glenn Morris
2018-03-07 01:46:17 UTC
Permalink
PS If you drop Emacs < 23.1 (released July 2009), you can switch to a
single .dir-locals.el file (rather than having the same stanza in
multiple source files), as someone pointed out in

http://lists.gnu.org/r/bug-gnulib/2011-02/msg00282.html
Paul Eggert
2018-03-07 03:43:40 UTC
Permalink
Post by Glenn Morris
PS If you drop Emacs < 23.1 (released July 2009), you can switch to a
single .dir-locals.el file (rather than having the same stanza in
multiple source files)
That would make sense if we assume that Gnulib source files live in a directory
controlled by the .dir-locals.el file. However, Gnulib is designed to copy
source files hither and yon, and it'd be a pain to arrange to update the
.dir-locals.el files (if any) appropriate for the hither-and-yon copies.
Glenn Morris
2018-03-07 07:40:12 UTC
Permalink
Post by Paul Eggert
That would make sense if we assume that Gnulib source files live in a directory
controlled by the .dir-locals.el file. However, Gnulib is designed to copy
source files hither and yon, and it'd be a pain to arrange to update the
.dir-locals.el files (if any) appropriate for the hither-and-yon copies.
Why would you need to copy a dir-locals file outside the gnulib repo?
You can't force your downstreams to use a particular editor to make
any local changes. Any changes they did make would show up via vcs, in
the normal way. I assumed any utility to keeping the time stamps
update was solely for edits in gnulib itself.
Paul Eggert
2018-03-07 08:34:09 UTC
Permalink
Post by Glenn Morris
I assumed any utility to keeping the time stamps
update was solely for edits in gnulib itself.
I assumed otherwise, in that if a change was made downstream by hand they'd want
the timestamps to be updated.

By the way, I would rather remove these timestamps as they are causing
maintenance issues. They may have been worthwhile in the 1980s before
version-control was widespread, but nowadays they are more trouble than they're
worth, in my experience.
Paul Eggert
2018-03-07 08:38:05 UTC
Permalink
Post by Glenn Morris
Please replace "write-file-hooks" with "before-save-hook".
I did that in all files maintained in Gnulib, along with files we're copying
from Automake (I updated Automake), by installing the attached. Two files remain
that I don't believe I have commit privileges on upstream: build-aux/texinfo.tex
and doc/maintain.texi. I think Karl Berry can do those so I'll CC: him.
Glenn Morris
2018-03-07 17:32:33 UTC
Permalink
Thanks for replacing the obsolete forms.
A few files were already using write-file-functions; I don't know if
you want to change those to before-save-hook, for consistency.
From today's gnulib:

build-aux/config.sub
build-aux/config.guess
doc/standards.texi
Paul Eggert
2018-03-07 19:46:56 UTC
Permalink
Post by Glenn Morris
Thanks for replacing the obsolete forms.
A few files were already using write-file-functions; I don't know if
you want to change those to before-save-hook, for consistency.
build-aux/config.sub
build-aux/config.guess
doc/standards.texi
These are all upstream from Gnulib. For the first two, I'm attaching a
proposed patch and CC'ing this to config-patches. For the last one, I
fixed the upstream and propagated it to Gnulib.
Ben Elliston
2018-03-07 23:10:10 UTC
Permalink
Post by Paul Eggert
These are all upstream from Gnulib. For the first two, I'm attaching
a proposed patch and CC'ing this to config-patches. For the last
one, I fixed the upstream and propagated it to Gnulib.
Applied.

Ben
Karl Berry
2018-03-07 23:58:09 UTC
Permalink
build-aux/texinfo.tex

bug-***@gnu.org

and doc/maintain.texi.

bug-***@gnu.org

I think Karl Berry can do those so I'll CC: him.

Technically I can still commit to the repos, but I think it would be
better if I didn't step in.

(I can't help but remark that backward compatibility breakage in Emacs
to the extent of having to edit source files that have been stable for
decades wrt this feature seems very sad. Oh well.) --best, karl.
Paul Eggert
2018-03-08 01:31:02 UTC
Permalink
    doc/maintain.texi.
Whaddya know, it turns out that I have the bits to do bug-standards
after all; I'd forgotten about that. I installed a patch and propagated
it into Gnulib.
build-aux/texinfo.tex
Thanks, I sent in a bug report about this to bug-texinfo, here:

https://lists.gnu.org/r/bug-texinfo/2018-03/msg00022.html

I think build-aux/texinfo.tex is the only remaining Gnulib source file
that uses the obsolescent form.

Loading...