Re: [emacs-wiki-discuss] Re: [BUG?] muse-publish handling abnormal exit during call to publish

[Peter K . Lee]

drkm <address@hidden> writes:

> Peter K.Lee writes:
>
>> Michael Olson <address@hidden> writes:
>
>>> I really detest that behavior.  In the most recent patch, I've worked
>>> around it by making a new macro called
>>> `muse-with-temp-buffer-no-prompt' that should *never* prompt for
>>> saving when its buffer is killed.  Emacs should implement this
>>> behavior by default, IMNSHO.
>
>> I agree with you there.  I don't think it gives proper meaning to the
>> word "temporary".
>
>   It gives proper meaning to the word "temporary" when the code
> using that buffer, the body of 'with-temp-buffer', runs properly,
> until the end.
>
>   But if it doesn't, if an error is thrown, what's the proper
> meaning of "temporary"?  "Not important at all, so if developpers
> made some mistake, just forget its content"?
>
>   IMHO it's safer to have the current behavior, and using
> 'condition-case' to catch the errors we can solve.

Perhaps.  The issue I have with the current macro has more to do with
the fact that the request to close the buffer comes *before* the error
is thrown.

So, when you're making the decision whether to close the buffer (and
discard the content), or keep it around, you have no idea what you
should do (or why you're asked for that matter).

The likely decision would be to keep it around, but then that open
temporary buffer starts to make emacs get confused about which buffer
is the real buffer and usually wants to save the temp buffer over the
original buffer's content (which happens to be the case here).

So, I guess the question is: if something goes *wrong* in the
processing of a temporary buffer, is the content inside that buffer
legitimate enough to ask the user whether they want to keep it or not?

AFAIK, temporary buffers are used to do some background processing
before real output or action is taken on real active buffers or
files.  In likely all cases, it can be regenerated from the existing
state over and over again.  I actually can't think of any case in
which the previous statement will not hold true.

Even as a developer, I'm not sure if the contents of the temporary
buffer will be of much interest.  What matters is the error case,
which can be traced whether that temporary buffer is around or not.
And once problems are fixed, nobody has to ever know that temporary
buffers were involved in the first place.

I would have considered the current behavior as safe (albeit
irrelevant) had it not been for the case that it somehow had the side
effect of messing with the buffers I was working on.

-Peter