unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Uday S Reddy'" <u.s.reddy@cs.bham.ac.uk>, <emacs-devel@gnu.org>
Subject: RE: save-excursion and save-current-buffer - edits to the manual
Date: Sun, 13 Mar 2011 11:27:13 -0700	[thread overview]
Message-ID: <1D85C3D14179400982EEB993C6CFFD99@us.oracle.com> (raw)
In-Reply-To: <19836.61380.828000.270873@gargle.gargle.HOWL>

> The debate on save-excursion getting "defeated" flared up again on
> gnu.emacs.help.  Somebody noticed that the Lisp manual hasn't been
> updated properly to take account of the new compiler warning.

No, someone simply pointed out that the Lisp manual does not say what you were
trying to make it say.  What it says is correct.  It just hasn't yet been purged
of `save-excursion' the way you would like.  And that's a good thing.

> The attached patch/bundle is an attempt to explain the situation as
> well as to provide guidance on how to use these forms correctly.
> Please let me have any comments.

My comment is to please leave it as it was.

You have replaced mention of using `save-excursion' or `save-current-buffer'
when one uses `set-buffer' with just mention of using `save-current-buffer' with
it.  Both can be useful here.

You've added this:

"However, it is not a recommended use of `save-excursion' for reverting buffer
changes."

The word "it" references nothing here - no meaning.

And `save-excursion' is not about reverting buffer changes - never has been.
And no one would ever think that it is.  And the warning you then try to explain
also has nothing to do with reverting buffer changes.

And your explanation of the warning, like the warning itself, does not help.

And in your "recommended practice" section, you completely miss that
`save-excursion' is not only about restoring point (and mark).  It is
specifically designed to restore `current-buffer' as well.

And there should be no "there should be"s in technical doc:

"there should be no calls to `set-buffer' in the intervening code
 inside the `save-excursion' form before the changes to point or mark,"

Nonsense.  Let's help users understand, not just give them a catechism to follow
blindly.

"because `save-excursion' only restores the point and mark of
 the current buffer, not for the other buffers that may be the target
 of `set-buffer'"

Doesn't follow at all.  That certainly is not a reason not to use `set-buffer'
in the body of `save-excursion' before any point movements.  No connection.  In
your "because A", A is true - so what?  It does not follow that you should not
move point in buffer X after calling (set-buffer X).

This is getting sillier and sillier.  All because of a warning that no one can
decipher and the explanations for which go round and round...nowhere.

This is how we end up with "guidance" in the manual that is later pointed to as
proof, The Word, and is hammered into user heads as a catechism.  This is
obviously a controversial area where judgments differ and programmer judgment is
called for.  Please do not try to carve one view of this in stone.

Just give users the facts of what these functions do, and let them decide for
themselves whether and how to use them.  Users are not idiots, in general.

Underlying your attempt to revise the manual here, your real contribution is in
underlining that this message is incomprehensible and unhelpful on its own.  The
right solution is to get rid of the misguided message, IMO.




  reply	other threads:[~2011-03-13 18:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-13 16:24 save-excursion and save-current-buffer - edits to the manual Uday S Reddy
2011-03-13 18:27 ` Drew Adams [this message]
2011-03-13 21:22   ` Uday S Reddy
2011-03-14  0:26     ` Drew Adams
2011-03-14  1:17       ` Tim Cross
2011-03-14 22:33       ` Richard Stallman
2011-03-15  7:08         ` Uday S Reddy
2011-03-13 21:40   ` Stefan Monnier
2011-03-14  0:45     ` Drew Adams
2011-03-19 20:36 ` Chong Yidong

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=1D85C3D14179400982EEB993C6CFFD99@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=u.s.reddy@cs.bham.ac.uk \
    /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).