[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [StrongED] Unexplained beep



The following bytes were arranged on 7 Oct 2012 by Fred Graute :

> In message <5fce4dd552.martin@xxxxxxxxxxxxxxxx>
>           Martin Bazley <martin.bazley@xxxxxxxxxxxxxxxx> wrote:

[snip again]

> If you want to distribute a mode with a choices file that only sets the
> options that are required by the mode then that's not a problem. Options
> not in the choices file will get their value from BaseMode. Mode colours
> not specified get their values from BaseMode too.

Does this mean that I could theoretically avoid the warning beep by
distributing a file called 'Choices' which is completely blank?

There's nothing in that file which I feel warrants customisation for
this fairly limited mode.  It's mainly there so keywords and syntax can
be helpfully coloured, and a 'Save and run' icon added to the toolbar.

> Repurposing the modename field in the mode choices window is something I
> already considered many years ago, and for a similar purpose: scoping of
> choices. My notes on this date from 2003/2004 and describe how changing
> of choices could be limited to a given scope, envisioned scopes were:
> Apply [changed, all] options to [view, text, mode, all modes].
>
> Not quite the same as what you're proposing now but it does gone some
> way to what you want, and it's slightly less complicated I feel.

Yes, that would definitely be an improvement (for example, changing the
font used in all modes simultaneously).  I tend to err on the side of
adding more functionality to cater to all possible circumstances,
regardless of how likely any of it is to be used.  (I'm probably the
only person in the world with an MBBack source file longer than a couple
of lines!)

> > That's a bit complicated, so here's the matrix of effects:
>
> [snip very clear description of how things might work]
>
> > There - is it practical now? :-)
>
> Thanks for the detailed outline of your inheritance model but there's
> still a number of things that would need clearing up.
>
> For one, how to keep track of which options are set at mode level and
> which are inherited? There are two ways that I can think of:
>
>  - Use the choices file. If a choices section is about to be opened the
>    icons inside it need to be initialised. We could at that stage check
>    if the option an icon represents has an entry in the choices file. If
>    it does it's set a mode level, otherwise it's inherited.
>    Problem; when OK is clicked, altered options are now set a mode level
>    but have no corresponding entry in the choices file.
>
>  - Use a duplicate of the choices section in the mode record. Inherited
>    options have their word/byte/bit set to 0, options set at mode level
>    have it set to 1. When initialising a choices section we check the
>    duplicate area to find out where the option gets its value from.

I was vaguely thinking of a mechanism such as "if this string pointer is
0 then look it up in the BaseMode choices instead", but of course that
wouldn't allow for binary options.  An 'inheritance mask' like the one
in your second option would probably be the best way to go.

One 'nice to have' which would probably be very difficult to implement
in practice would be showing which options in BaseMode are currently
being inherited by other modes, but that would require a bidirectional
system of some sort (or else checking every single mode for every single
option).

> Another consideration is how often would this system be used? If it's
> only at initial configuration then we may as well stick to StrongSet.

As I said above... :-)
-- 
  __<^>__   Red sky in the morning: Shepherd's warning
 / _   _ \  Red sky at night: Shepherd's delight
( ( |_| ) ) Mince and potatoes: Shepherd's pie
 \_>   <_/  ======================= Martin Bazley ==========================

-- 
To unsubscribe send a mail to StrongED+unsubscribe@xxxxxxxxxxxxxx