No one felt strongly enough about the current behavior of savebefore:yes to speak up in defense of it (except April, who was speaking hypothetically). With that in mind, it seems clear that savebefore:yes should behave the way Jos described. It's probably what people thought was happening all along.
In addition, I see no reason to implement the fourth option. What useful purpose does it serve? If someone does find a legitimate need for it, they can add it later and call it "force" or "always". But I doubt anyone ever will. For now, we can leave it out. Just change (saveBefore == 1 && Save()) to (...1 && (!(CurrentBuffer()->isDirty) || Save())) and I think everyone will be happy. Bruce "Neil Hodgson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > April White: > >> I've not tested it yet, but I did implement a savebefore:auto command >> mode, changing it to yes ot no depending on whether the buffer is dirty. >> >> Would you prefer that this not be so implemented? > > I don't have any strong feelings and was hoping that you and Bruce > and Jos would work out what to do. You could have "savebefore:yes" > behave similarly to the "Save" command as the most common thing needed > and "savebefore:always" (or "force") available for the cases where it > matters. > > Neil _______________________________________________ Scite-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scite-interest
