[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [External] : Re: [PATCH] When deleting in bookmark menu, prompt for

From: Drew Adams
Subject: RE: [External] : Re: [PATCH] When deleting in bookmark menu, prompt for confirmation.
Date: Wed, 5 May 2021 23:17:49 +0000

> >> Hmm, I can understand, but... let me give you my best argument
> >> for why to do this instead of implementing undo:
> >
> > Makes a lot of sense to me, yes.
> > While the idea of "undo" was brought up in response to your
> > proposal and can indeed be seen as providing a similar
> > functionality, I think the two are mostly orthogonal.
> Glad to hear that.  +1 to the rest of your analysis below, too,
> including that last part about how for undo purposes the Bookmark
> Menu buffer can be thought of as "visiting" the file in which
> bookmarks are saved.  (However, users are much less directly
> exposed to the bookmark file than they are to the regular kind of
> file that one visits, edits, and saves -- so the analogy fits
> mostly but perhaps not perfectly.  A person could in theory use
> bookmarks regularly without ever needing to be aware that the file
> even exists.)
> I don't plan to implement the undo functionality myself.  It's a
> larger task than I want to take on.  Or rather, if I were going to
> find time to do something of that size in Emacs, there are other
> things I would pick before this.  However, it's good to have all
> these thoughts archived here, in case anyone else decides to do
> it.

FWIW, I'm not warm to the idea of undoing operations,

Consider undo in WDired.  You can just as easily want
to think of WDired as "visiting" a directory, but
that's problematic.  It's visiting a presentation of
a directory listing.  (Actually, the listing can be of
several directories, or even of arbitrary files located

We support undoing text changes to the buffer in Wired.
But WDired doesn't perform operations _on the files_
listed.  (Dired does.)  It's a view of some files -
in that sense it "visits" them or their directory.
But the analogy of a buffer visiting a file is poor.

The bookmark-list display buffer (bookmark "menu") is
more analogous to Dired than WDired.  How much undo
does Dired support?  Only undo to what are, in effect
annotations (and not done via `undo' but by specific
operations such as unmarking etc.).

We don't support undo for its operations on files and
dirs that are listed.  If you use `x' to delete all
flagged files, there's no undo for that.  (We have a
move-to-trash possibility, but nothing with `undo'.)

And for good reason, I think.

This can certainly be discussed/explored more, but a
priori I think that direction is generally misguided,
especially from a user point of view.

Take the buffer-list display as another example.
Do we offer undo as a way to undo operations on
buffers there?  Should we?  I think not.  Not in
general.  Undo The Hammer is not the best way to
undo some things.

The bookmark-list display is, like Dired, a view
of a listing of things.  And no, those things are
not the bookmarks in "the bookmark file".  They're
the bookmarks in the _current bookmark list_.

The bookmarks in that list can be loaded from any
number of bookmark files, and more bookmarks can
be added on the fly, so that the list corresponds
to no bookmark file.

The only thing you can say about it is that if you
_save_ the current bookmark list then, by default,
its bookmarks will replace those in a particular
bookmark file.

[On the other hand, at least with Bookmark+, you
can save the bookmark-list display itself - its
current state - in a file.  And you can restore
it from that file (or another).  So perhaps there's
room for being able to undo some textual changes
in the bookmark-list display - like using undo in
WDired.  But I don't see that as a rich mine of
interest, at least not a priori.]


As for offering undo of `x' deletions as a
_substitute_ for prompting for confirmation:
that's simply wrong, IMO.  There are several
reasons that undo either won't help or can cause
harm in this context.  They've already been
pointed out.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]