Hello, Yes, sounds reasonable. But I worry configure command could be overabused with all that features, like: configue soft keepstate keepdebug keepsomethingelse :) May be some means to provide default configure variant could be useful... But lets leave it for futher generations for now.
How this configure flag could be implemented? I see there are reconfigure type variable in code - sould it be extended to bitmask somehow? Or separate variable to keep this flag? I could try to provide some patch, but I'm not sure it would be easy for me to change parser's part in that case. It looks more complex than for adding new protocol option. On Thu, Nov 29, 2018 at 11:54 PM Ondrej Zajicek <santi...@crfreenet.org> wrote: > > On Wed, Nov 28, 2018 at 04:30:02PM +0100, Alexander Zubkov wrote: > > Hello, > > > > I have received no feedback on this suggestion and suppose it got > > lost. I would be glad to hear some comments about this improvement. > > Hello > > Sorry for not responding earlier. It seems to me that although the issue > makes sense and deserves some solution, the approach in the patch is not > the right one. There are other properties that could be changed in > runtime (e.g. debug), possibly more in the future, and we do not want to > make such options for all of them. IMHO more appropriate solution would > be to have some option for the configure command that decides whether > such changes in general should be kept or reset (analogously we have > 'configure soft' for filters). > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > "To err is human -- to blame it on a computer is even more so."