On Sat, Oct 24, 2015 at 4:02 AM, Jonas Bernoulli <[email protected]> wrote:
>> (It shouldn't be necessary to save the buffer too -- see
>> `git-blame-mode' (from the git contrib directory) that works fine
>> with unsaved modifications.)
>
> The buffer has to be saved, or this might happen:
> [...]
I gave `git-blame-mode' as an example which shows that it's very
possible to have a blame interface that doesn't require saving the
buffer. Independent of the fact that `magit-blame' breaks or not.
(And the fact that `magit-blame' works fine with local uncommitted
changes makes me think that it should be easy to make it work with
unsaved buffers too.)
>>> Finally you could redefine `magit-save-repository-buffers' to only
>>> save the current buffer, but again that would affect [a lot] of
>>> code, which assumes every buffer that visits a file in the current
>>> repository [does get refreshed]. So you probably shouldn't do that
>>> either.
>>
>> I can't parse the first sentence above: are you saying that there is
>> code that would break when buffers are *not* saved? In other words,
>> is there any code that will *break* when
>> `magit-save-repository-buffers' is set to nil, or when it's set to t
>> and when asked I refuse to save some buffer?
>
> I have inserted some missing words. Additionally I should have said
> "features" instead of "code". But I did use the word "affect", as in
> "things will behave differently", and not "break".
I parse "affect" as "behave differently", and therefore "broken". Is
there a place with a list of such things?
>> Are you saying that there are some buffers that can be saved
>> *without* such a question?
>
> No, that wasn't my intention. If you request to be asked then you
> will be asked.
Whew.
>> (No! This is repeating the same auto-revert story...
>
> Thanks for the reminder. I added a safety net for your benefit and
> some other hypothetical users who also rely on unsaved buffers as a
> sort of staging area.
1. This attempt at painting me and people who have similar expectations
as hypothetical is not helping. If it helps, I remember at least two
other complaints from other people about this kind of thing.
2. I don't rely on unsaved buffers as a staging area. In the context of
both saving files and refreshing them my main concern is to *know*
when either is happening, so I don't lose stuff that was saved or
stuff that was typed.
3. I never needed any kind of safety net: just the ability to disable
any implicit reverts.
> And you were very much not satisfied with the approach I took, because
> it did not go far enough in your opinion. I instead settled for a
> compromise.
4. By "safety net" I'm assuming that you're talking about the default
value of a message about the default behavior. It's something that I
never tried before (I just disabled it). I did that now, and it does
look over-verbose and weird ("I did something that you possibly don't
like, here's how you undo it").
A more emacs-like approach would be to be to have the default be
`ask', and possibly extend *that* message with a note about
customizing it.
5. I assume that this what you mean by "not go far enough". Indeed, the
current setup looks like it guarantees that everyone is annoyed:
"hypothetical people" like me would be annoyed that the revert
happened, "the sheep masses" (to be equally unnecessarily offensive)
are annoyed at code that spews too many words at them.
6. Note that the only reason I tried it now, and the only reason I'd
ever talk about what it should do by default (when I have an option
to change it and therefore never be bothered by that default) is as
advice to making magit be more Emacs like.
Feel free to ignore it. *I* certainly won't care since (like I said
enough times to be clear now) I'm not using the default.
> At the same time *many* other users were very dissatisfied by that
> compromise because it went *too* far. In their eyes
[You really want to flame this?? OK, I'll play along.]
> I was "needlessly forcing them to set an option" when the "old default
> obviously was the right behavior in the first place"
It's funny to say that it was right when code can be lost, silently.
This is exactly what I mean by "Emacs like": by default, there is no
functionality in Emacs that can lose stuff in a buffer (silent auto
revert) or stuff in a file (silent auto saving).
> and you were "using a very odd work flow"
That might be true[*]. I might also look weird, or whatever. The fact
is just the above: how Emacs does things, and the expectation that new
Emacs functionality follows the same lines. Like I said, there is no
functionality in Emacs that changes either files or buffer without your
explicit concent.
([*] And BTW, it might be surprising at this point that my workflow is
absolutely not odd. I pretty much always work with saved buffers. It
might even surprise you that in my own Emacs setup I have buffers revert
themselves automatically(!) when I touch a buffer and it was changed on
disk. Why? Because ... I find it more convenient. But that's just me,
and that happens when I touch the file and therefore I *know* that a
revert happened, and at that point it's easy for me to assess whether I
want to undo that or not. Even more: I almost never undo these reverts.
So not only am I using an auto revert feature, but I put the time in to
implement it. That means that I'm even more into auto-reverting than
all those non-hypothetical people.)
> and "wrong about the safety of the old default"
Um, no -- that is just plain wrong since the old default could lose
code. I'm very happy that some people consider "code" as "anything that
is saved on file". Perhaps years of Windows/OSX-induced restarts got
that to be a popular view. I consider "code" as "anything that I
bothered to type in a buffer", and that's stuff that my editor should
treat as sacred. (And Emacs always did that.)
> and I "should therefore just have ignored you".
That's certainly something that you can do. But to make it more
precise: it's not *me* that you should ignore or not. Like I said, I'm
happy to have a way to disable the thing and never hear about it again.
It's the way that Emacs normally behaves that you'll be ignoring.
> Yes, these things were said. This is not over, users are still being
> inconvenient by having to set the option and by unavoidable
> side-effects of the change I made in response to you request.
I'll repeat just because you took so much effort to flame this: *my*
original request was to have a way to turn it off. The rest is up to
you and new prospective users or ones that might run away when they find
that stuff happened without them knowing about it. This new default
that you're so eager to blame me for is something that I have never even
seen until 5 minutes ago.
> Never-the-less I think compromising was the right decision,
> unfortunately it doesn't make anyone happy.
If you agree that it was the right decision, then you should stand
behind it. Either make that message less obnoxious (or, god forbid, do
the right thing and ask whether buffers should be reverted), or just
make the default silently do the reverts (or erase them). But please
don't hide behind an imaginary boogeyman that made you do it, at least
not when I'm it.
>> You should *never* assume that having some feature around when people
>> don't notice it is any kind of justification for its validity!)
>
> I didn't try to justify anything. I was just saying that, it appears
> that Patrick does not very often have unsaved buffers when he invokes
> commands which, depending on the setting, would then ask to save these
> buffers, or not.
(I read that as "Q: it asked me to save something, why? A: it saves
stuff a lot, so you shouldn't ask why.".)
> Also I really don't want to get into a discussion about such things
> with you again. It was unpleasant enough the first time around.
I can assure you that both sentences are mutual.
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
--
You received this message because you are subscribed to the Google Groups
"magit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
