Re: [StrongED] StrongED Choices

[Fred Graute <fjgraute@xxxxxxxxx>]

In message <mpro.ne7v5j0012m4k01ck@xxxxxxxxxxxxxxxxxxxx.invalid>
          Jeremy Nicoll - ml stronged <jn.ml.sed45@xxxxxxxxxxxxxxxxxxxx> wrote:

> Tony Baker <Tony.Baker@xxxxxxxxxxxx> wrote:
>
> > What would interest me would be changes to the Modes system to effectively
> > make it upgrade proof.
>
> I doubt that's possible.  The changes that cause problems are, surely, those
> that come about because Fred makes architectural changes inside SE.

Architectural changes that affect the ModeFiles have been quite rare, I
believe, mostly there are alterations to support new functionality or to
fix problems. Of course, that doesn't make merging ModeFiles less of a
pain.

> Otherwise, if one adopts a proper 'professional' approach to making changes
> to mode definitions - ie writes notes on what one changes and WHY, one can
> rework those changes when a new version comes along...

That, of course, is a vital step. If you don't know what you've changed
and for what reason it becomes difficult to merge your changes with a
new version of a mode.

I'd also suggest keeping a copy of the original ModeFile along side the
modified copy in UserPrefs. This way when the mode is updated you can
compare the new ModeFile against the original one to see what's changed.

The main reason is the see if there are conflicts between your changes
and any alterations in the new ModeFile. If there are none then you can
simply copy your changes over to the new ModeFile. If there is a clash
then you'll need to resolve it first.

> > The sort of thing I am thinking of is:
> >
> >1. Create a new application (eg !StrongMode) to store supplied
> >   StrongED modes.
> >2. StrongED itself would be supplied with just a single 'base'
> >   mode with minimal functionality (probably a lot less than the
> >   current Basemode).
> >3. All modes to operate in an additive fashion. So when a new mode
> >   is selected StrongED would do the following:
> >      a) Start with a clean slate
> >      b) Apply the settings from it's builtin 'base' mode
> >      c) Apply the settings from the supplied Basemode in StrongMode
> >      d) Apply the user settings for Basemode from StrED_cfg
> >      e) Apply the settings from the new mode in StrongMode
> >      f) Apply the user settings for the new mode from StrED_cfg
>
> So a user wanting to develop changes to modes has to look in up to 5
> different places to get an understanding of how all the definitions merge
> together?

Yes, that is my concern too, and the ModeFile parser would need to have
some serious changes made to it to get this scheme to work.

Suggestions along these lines have been made before but in most cases I
feel they create as much problems as they solve.

There are IMO only two scenarios that are worth considering here:

 - Have only those bits of a ModeFile that need augmenting in UserPrefs
   with the rest still in the ModeFile in Defaults.

 - Allow multiple copies of sections in the same ModeFile, eg a default
   Search section and another with user additions / alterations.

Both however come with their own 'problems' when merging with a newer
mode. Here too the ModeFile parser would need changing, to what extent
depends on the model chosen.

Cheers,
Fred.

-- 
StrongED Developer
http://www.stronged.iconbar.com/

--
To unsubscribe send a mail to StrongED+unsubscribe@xxxxxxxxxxxxxx
List archives at http://www.Torrens.org.uk/RO/StrongED/index.html