unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@jurta.org>
Subject: Re: bug in save-some-buffers or diff.el?
Date: 23 Oct 2003 07:53:22 +0300	[thread overview]
Message-ID: <874qy08shp.fsf@mail.jurta.org> (raw)
In-Reply-To: <5567-Wed22Oct2003195204+0200-eliz@elta.co.il>

"Eli Zaretskii" <eliz@elta.co.il> writes:
> > From: Kevin Rodgers <ihs_4664@yahoo.com>
> > Date: Wed, 22 Oct 2003 10:34:15 -0600
> > 
> > > Instead, `load' should load the newest of .el
> > > or .elc files, and report the same warning as a simple reminder to
> > > recompile updated .el files to execute them faster.
> > 
> > That may be true for developers running CVS Emacs.  But for normal
> > users, it is the historic and expected behavior.  For instance, it
> > allows me to develop and test my own .el files while still having a
> > working .elc file for both myself and others to use.
> 
> Indeed.
> 
> I fully agree with Kevin: the current behavior of `load' should not be
> changed.
> 
> I do work on developing CVS Emacs, but still I find the current
> behavior much more useful than the suggested one.  For example, it
> allows me to do a "cvs up" on selected files without worrying about
> possible inconsistencies that might introduce (because some changes in
> *.el files require related changes in other files in order for them to
> work correctly).

Seems, it's just matter of habit.  I find the less error-prone and
more reliable the standard "UNIX-like" development style, where files
under development are placed into another directory, whose name is
listed in the front of `load-path'.  But currently `load-path' implies
additional hidden layer for searching files that prefers .elc files
over .el ones in every directory.

Maybe, a new option could be added to choose between these two cases.

Anyhow, I'm just trying to find the solution to the real problem about
warnings that go unnoticed because they become overwritten by the
new messages in the minibuffer.  And user remains unaware that he is
using old files until he is hit strongly by the resulting problems,
because usually .el files newer than .elc files mean that user forgot
to recompile them.  One solution to this problem is to display such
critical warnings in the separate window instead of minibuffer.

-- 
http://www.jurta.org/emacs/

  reply	other threads:[~2003-10-23  4:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-22  0:07 bug in save-some-buffers or diff.el? David Abrahams
2003-10-22  8:38 ` Juri Linkov
2003-10-22  9:35   ` David Abrahams
2003-10-22 12:52     ` Stefan Monnier
2003-10-22 15:22       ` David Abrahams
2003-10-22 14:35     ` Juri Linkov
2003-10-22 16:28       ` David Abrahams
2003-10-22 16:34       ` Kevin Rodgers
2003-10-22 17:52         ` Eli Zaretskii
2003-10-23  4:53           ` Juri Linkov [this message]
2003-10-23  6:06             ` Eli Zaretskii
2003-10-23  8:00               ` Juri Linkov
2003-10-24 14:52                 ` Eli Zaretskii
2003-10-23 18:38       ` Richard Stallman
2003-10-23 19:47         ` David Abrahams
2003-10-24 10:41           ` Richard Stallman
2003-10-27 17:44             ` emacshear (was: bug in save-some-buffers or diff.el?) Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874qy08shp.fsf@mail.jurta.org \
    --to=juri@jurta.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).