losing a menuconfig session to a typo

losing a menuconfig session to a typo

[euphoria]

It's easy to accidentally lose a menuconfig session.  Scenarios start with a
user being accustomed to hitting [right-arrow][return] to exit from a typical
menu.  Perhaps the user prefers his underutilized numeric keypad over adding to
the beating [escape] takes.  Scenarios finish with the user accidentally
issuing [right-arrow][return] to "Do you wish to save? <Yes> <No>".  I only
lost a quick change, but it's easy to imagine how a few hours of menuconfig
time might go away.  "It'll just take a few minutes to whip my distro's kernel
into shape."  Yeah right.  Four hours of guesswork and research later, you're
tired, thinking about the make command to follow, [right-arrow][return] as
usual, wait! no! damndamndamn!, yer snookered.

There are a variety of simple ways to address this.  First, change the menu.
Swapping the order of the <Yes> and <No> would be begging for even more
trouble.  However, the <Yes>/<No> decision could be made a <Yes>/<Maybe>/<No>
decision.  This leaves <Yes>, the predominant choice, in place.  <Maybe>, in
the disputed position, could simply present the same menu.  Someone might even
have a little well-deserved fun with <Maybe> menus.  This doesn't seem all that
intrusive to me.  Second, print the diff.  When changes aren't saved, a diff of
the original config and one that would've been saved could simply be written to
stdout followed by a little blurb, "Those were the changes you didn't save.".
Third, add a save command.  I save at comfortable intervals when editing
everything else, why not kernel configurations?  This reduces the scope of
lossage in general.

Regards, [Ag]   Andy Gaynor   euphoria@inbox.com

Re: losing a menuconfig session to a typo

[Pavel Machek]

On Mon 2008-12-15 13:03:28, euphoria@inbox.com wrote:
> It's easy to accidentally lose a menuconfig session.  Scenarios start with a
> user being accustomed to hitting [right-arrow][return] to exit from a typical
> menu.  Perhaps the user prefers his underutilized numeric keypad over adding to
> the beating [escape] takes.  Scenarios finish with the user accidentally
> issuing [right-arrow][return] to "Do you wish to save? <Yes> <No>".  I only
> lost a quick change, but it's easy to imagine how a few hours of menuconfig
> time might go away.  "It'll just take a few minutes to whip my distro's kernel
> into shape."  Yeah right.  Four hours of guesswork and research later, you're
> tired, thinking about the make command to follow, [right-arrow][return] as
> usual, wait! no! damndamndamn!, yer snookered.
> 
> There are a variety of simple ways to address this.  First, change the menu.
> Swapping the order of the <Yes> and <No> would be begging for even more
> trouble.  However, the <Yes>/<No> decision could be made a <Yes>/<Maybe>/<No>
> decision.  This leaves <Yes>, the predominant choice, in place.  <Maybe>, in
> the disputed position, could simply present the same menu.  Someone might even
> have a little well-deserved fun with <Maybe> menus.  This doesn't
seem all that

Too ugly to live. But maybe periodically saving config to
.config.autosave once in 5 minutes...?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html