unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Richard Stallman <rms@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Missing `with' macro?
Date: Tue, 08 Aug 2006 14:01:50 -0400	[thread overview]
Message-ID: <E1GAVtm-00062e-Hh@fencepost.gnu.org> (raw)
In-Reply-To: <48104.128.165.123.18.1154986690.squirrel@webmail.lanl.gov> (herring@lanl.gov)

    > To use the user's existing buffer would save the user's own unsaved
    > changes without asking.  That is completely unacceptable.

    Is it completely unacceptable even if the file in question is principally
    "owned" by code anyway?

Yes, I think so.  If it is unlikely that users will edit the file by
hand, that means there is unlikely to be a buffer to reuse.  But IF
there is a buffer to reuse, it means the user edited the file by hand.
When he does so, you should not save his changes without his ok!

    I see other possibilities:
    1. (and REUSE WRITE (buffer-modified-p #<buffer extant-buffer>) (error
    "Attempt to co-opt user's unsaved changes")) - that is, only allow REUSE
    and WRITE on an unmodified buffer.

It is better to go ahead not reusing the buffer than to signal an
error.

    2. Go on modifying (because of WRITE) the buffer (because of REUSE), but
    don't save the changes at the end, or else ask the user whether to save
    them.

That would be very inconvenient.  There is no need to implement that
option, and it would be better to avoid it for simplicity's sake.

    Either of these could be combined with a query beforehand:

Any query will be an inconvenience.  That's another reason now to
implement these options.

Complexity is a drawback, not a feature.  I am looking for ways
to simplify this.  We should not reject them because of maybes.

  reply	other threads:[~2006-08-08 18:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-24 10:17 Missing `with' macro? Mathias Dahl
2006-07-24 13:46 ` Stefan Monnier
2006-07-24 14:33   ` Mathias Dahl
2006-07-24 18:22 ` Richard Stallman
2006-07-24 20:55   ` Jorgen Schaefer
2006-07-25  3:09     ` Richard Stallman
2006-07-28  2:14   ` Stuart D. Herring
2006-07-28  2:23     ` Stuart D. Herring
2006-07-29 15:18     ` Richard Stallman
2006-08-01  1:06       ` Stuart D. Herring
2006-08-07  5:01         ` Richard Stallman
2006-08-07 21:38           ` Stuart D. Herring
2006-08-08 18:01             ` Richard Stallman [this message]
2006-08-08 18:32               ` Stuart D. Herring
2006-08-09  4:58                 ` Richard Stallman
2006-08-08 18:01             ` Richard Stallman
2006-08-16 19:59               ` Stuart D. Herring
2006-08-17 15:18                 ` Richard Stallman

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=E1GAVtm-00062e-Hh@fencepost.gnu.org \
    --to=rms@gnu.org \
    --cc=emacs-devel@gnu.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).