Bruce Dodson wrote:
I do think it makes more sense to keep the saveBefore separate from the
flags, because saveBefore is not used by the job subsystem; saveBefore is
applied "before" the job is placed in queue.
With or without that change, here is a further refactoring of the good work
you've done to remove some repetitions from the code. Among other things,
the new version smooths out the discontinuity between yes / no and the other
option values. This version also fixes a regression in the save-before
handling: in case of an invalid mode value (e.g., "savebefore:oops"), it was
treating it as "savebefore:no," instead of skipping that tag.
Hi Bruce,
We are definitely of two minds on the savebefore flags. Though the
flags are applied by SciTE before a job executes, I feel that they are a
component of the job system. Consider that the filter flag and group
undo are used by SciTE after a job has run, it is arguable that they too
should be removed. Since all of these flags are configured by the user
with the command.mode property or some equivalent, I see no reason to
decode and manipulate them separately.
The use of the enum within your DecodeCommandMode() example is a better
design that what I wrote. I will implement this, with due credit
indicated. Thank you.
April
--
I am willing to make the mistakes if someone else is willing to learn from them.
_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest
