On Tue, Feb 10, 2009 at 2:58 PM, Daniel Schoepe <[email protected]> wrote:

> Thanks for the help, but I see two (potential) problems with that:
> 1. Some modules/functions directly set the mode to some hardcoded Mode
> structure(like `interactive' in Yi.Mode.Interactive) which can't be
> practically changed in yi.hs. Having the mode hooks depend on everything
> else to use the modeTable from Config wouldn't be such a good idea in my
> opinion.
> 2. That way it is less simple to add a mode hook in the configuration,
> since one has to figure out what the default mode structure for that
> mode is, change it, add it to the modeTable and one probably also wants
> to remove the old mode structure from (modeTable defaultConfig). Using
> nubBy with the modeNames on the resulting list isn't hard though, but it
> clutters up the config.

I think we ought to avoid the "hooks within hooks" syndrome. I.e. we don't
want to many ways to configure things: this can easily kill us in terms of
maintenance burden. Additionally, new users will never know how "the best way"
to configure things.

I think the only defensible way is to have one Config that parameterize
the whole program. We should of course provide convenient ways to
build this Config value.

BTW, did you look at how I configure modes in Yi.Users.JP ?

As for
1: if you want the Interactive mode configurable, it has to depend on Config in
some way.
2: we could provide accessors for entries in the mode table.

> Besides, I think there's a conceptual point here: Is it really intended
> that something as basic as `Action',`Yi' or `YiM' is in the _Keymap_
> module? As that example shows, these data types aren't limited to things
> related to keyboard input as putting them in Keymap might suggest. So I
> would be in favor of moving these data types to a different, more basic,
> module, since similar issues might arise for future modifications as
> well. (And it would make more sense from my point of view)
> Would this refactoring cause any significant problems I'm overlooking here?

The only reason was to limit the number of hs-boot files and usage of
the newtype
deriving construct. I'm unsure if this last point will allow you to
even split it in a separate module.

Another take on the issue is to rename Yi.Keymap into Yi.Action.

Cheers,
JP.

--~--~---------~--~----~------------~-------~--~----~
Yi development mailing list
[email protected]
http://groups.google.com/group/yi-devel
-~----------~----~----~----~------~----~------~--~---

Reply via email to