On Thu, Dec 14, 2023 at 12:22:22AM +0100, Vincent Lefevre wrote: > > Mutt is a user application that already provides two methods of > > exiting the program "nicely" with two different behaviors: Save state > > or don't. CTRL-C/SIGINT allows for a third way to terminate the > > program when it is behaving in an incorrect/undesirable way, when for > > example you're not able to get to a menu, or Mutt is failing to > > process menu selections for whatever reason. > > OK, but that's not the only use of Ctrl-C. It can also be used to > interrupt an ongoing operation, such as a search/limit, but it may > happen that the time the user hits Ctrl-C, the operation has just > finished, so that instead, Ctrl-C will attempt to terminate Mutt. > One may also hit Ctrl-C by mistake.
Fair--ideally those would be two different functions mapped to different keys. I can't immediately think of a way to divorce them without rewriting Mutt to process UI input in a separate thread (eww)... > > Mutt already prompts to allow for the possibility that you've hit > > CTRL-C by mistake. When you haven't, clearly the intention is to > > terminate immediately, so that is quite sensibly the default, whereas > > whatever you configured for OPT_QUIT doesn't necessarily apply in this > > circumstance, since the assumption there is that you are exiting under > > normal and expected circumstances. > > There could be a new option, say OPT_SIGINT, which could have the same > default as the current behavior. So, for users who do not change this > option, there would still be the same behavior with the introduction > of "query_quadoption (OPT_SIGINT". Sure, I don't think this is a crazy suggestion either. As you probably recall, I'm generally averse to adding new options. The number of options Mutt already has drastically increase its learning curve and make it hard (tedious, time-consuming, error-prone, etc.) to configure the way you want it, and every option is an increase in complexity, a potential risk for maintenance/testing, etc.. That said, this may well be straightforward, and the pragmatist in me thinks that the ship has already sailed on the "too many options" problem. ¯\_(ツ)_/¯ > > If not for this distinction, you could simply ignore SIGINT > > entirely. > > I don't understand what you mean. I can't tell Mutt to ignore it in > this particular case. Essentially I was saying that--arguably--Mutt shouldn't need a third mode of exiting, so signal(SIGINT, SIG_IGN); /* but use the POSIX interface */ ...EXCEPT that there IS a distinction between how SIGINT is used compared to quit/exit, so there is value in the third mode. [And of course if you did that, you would need to address the other uses of SIGINT somehow...] > >--particularly when you > > obviously already realize this is a mistake you sometimes make--and > > as I'm certain you are aware, there are already solutions possible to > > help you deal with that (remapping Mutt's keys, remapping SIGINT in > > your terminal, etc.). > > First, remapping Mutt's keys can't affect the intr character. No, but it CAN make Copy Message (or whatever you have bound to SHIFT-C) bound to a different key that prevents you from mixing up SHIFT-C and CTRL-C... And you can still remap SIGINT to another key in your terminal. BTW FWIW, I think the reason I've never had this problem is that I don't use copy message all that often, and when I do the folder it suggests is ALWAYS wrong. So I can't ever just hit enter, and have to actually pay atention to the prompt to correct it. So here again, this comes down to personal habit and usage patterns. I suspect the majority, and probably even the vast majority, of Mutt users are in a similar boat as me. But it took even you almost 30 years to complain about it. ;-) > And changing the standard Ctrl-C for SIGINT would be more > error-prone, with no simple way to restore the behavior, e.g. after > a Ctrl-Z, or when running shell commands. All of this comes down to personal habit and preference (e.g. don't CTRL-Z out of Mutt--use a different terminal instead). You can certainly dislike the available options, but you can't argue that it can't be done--there are several ways for you to work around this. > > Perhaps, but since 1995, I'm pretty sure I've personally made that > > mistake exactly zero times, nor have I ever noticed anyone complaining > > about this in the past, here or anywhere. That leads me to think that > > rather than changing the current behavior--which seems already > > sensible--you should adapt to it yourself, as I suggested above. > > Sorry, but this is silly. No it isn't, stop doing that. > Software should adapt to the human, not the other way round. Yeah, I agree with that as a general principle, but there are limits, and there have to be. An extreme, obvious example is if an app uses a particular paradigm that is, say, new (and therefore different from existing ways of doing that thing), the user who wants to continue with the old paradigm should not expect the app to adapt to the human. Either the human adapts to the application, or chooses a different application. Obviously, that's not what we're talking about here, but there are examples much closer to the opposite end of the spectrum that are still valid. My point was that making a change here, by all appearances, would be to appease exactly one person--you--and that's not how software development decisions should be made. If one person has a problem, the one person solves the problem. If many people have the problem, the software fixes the problem, to prevent the many people from all having to independently solve the problem. Ideally, anyway. If you were making this request for a commercial software, and yours was the only complaint in almost 30 years, it would almost certainly end up in the bit bucket, and rightly so. Or perhaps it would end up in the "low-priority" queue that no one ever looks at. Same difference. > FYI, for some reasons, I use various machines, with various keyboards, > where the layout is not exactly the same. This may tend to increased > mistakes. Yeah. That's actually why I stopped using Macs (and I am obviously aware that that isn't an option for everyone). The interface is fairly similar to Linux (or what I use in Linux, at least) but just different enough that it, let's say ENCOURAGES me to make key-press mistakes, and the visual cues are insufficiently different to prevent me from repeatedly making them over and over. So I totally get what you're saying. For whatever that's worth... > > > BTW, as mutt_query_exit() doesn't save, the message should be > > > "Exit Mutt without saving?" like with <exit>, IMHO. > > > > This seems perfectly sensible, though I also think that to anyone > > who's familiar with what CTRL-C typically does on a Unix terminal (and > > plenty of other places), this is already implied and obvious. > > Perhaps obvious, but what is already implied is with OP_QUIT, > where the question is just "Quit Mutt?" and saving is done. > So this is rather strange that "Exit Mutt?" has almost the same > behavior as "Exit Mutt without saving?", but is significantly > different from the "Quit Mutt?" behavior. Like I said, it's perfectly reasonable. But context matters, and programs should be allowed to behave differently to match expectations in different contexts. Humans ought to be able to understand that context can/should change those expectations in intuitive ways. > > I would note that if the issue is that you're hitting <enter> too > > quickly to read the prompt and respond to it appropriately, the > > wording doesn't matter much. =8^) > > Indeed, but this is another issue. Quite so. I dare say though that this whole discussion seems rather academic (which I enjoy--that's how one learns new things), since it seems no one wants to continue mainaining new development for Mutt. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
