RE: address@hidden: two View-mode "quit" bugs]

[Drew Adams]

> It is clear that the behaviors he describes are undesirable.
> Whether burying the buffer is the right thing to do instead,
> I am not sure.  What do others think is the right thing to do
> in that case?

Without looking at the details, I'd say TRT to do is probably this: kill the
buffer, delete the window, and, if `one-window-p', delete the frame.

> Meanwhile, finding a way to adjust the heuristics so that these
> behaviors don't happen, without causing bad behavior in another case,
> may be difficult.

Yes. View-mode's quitting behavior is a jungle. It was much more reasonable
and manageable before Emacs 22. Though there are now innumerable cases
treated and uncountable heuristics employed to treat them, users cannot
easily master or manage things. A quick glance at the number of different
view-mode quitting functions, not to mention the convoluted code behind
them, should be enough to hint that there is a problem: `View-quit',
`View-exit', `View-exit-and-edit', `View-quit-all', `View-leave', and
`View-kill-and-leave'.

No, I don't have the time or patience to propose a solution; sorry.

In general (too general to be very useful, I recognize), I'd say that we
probably need to (1) make things simpler and not so smart, (2) give the user
more control, with user options if necessary. In particular, we will need to
find a way to cater to different uses of frames. We might also need to
divide view-mode up: perhaps different uses of view-mode call for different
behaviors.

See also thread "view mode: `q' does not delete frame", from December 2005.
I said there, regarding quitting view-mode:

> The variations [in names of functions for quitting] don't tell us
> anything in particular about what the functions do - there is no
> significant difference between the words "quit", "exit", and "leave".

> My main question about the names cannot be addressed for this
> release: Is it really necessary to have so many ways to quit? Could this
> proliferation be a sign that the design is not as it should be? Why does
> quitting a mode need to be so concerned about which context to restore?
> Perhaps the restoration context should be passed when the mode is
> entered? Or perhaps the caller should control it some other way. And so
> on. It seems odd to me that a function is so concerned with how it was
> called.