On 15 Jan 2001, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | >>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> |
> | Lars> My problem with Levons code that I feel it is too static. With
> | Lars> the scheme Andre and I propose it is very easy to load function
> | Lars> os demand or have them created in a scriptlanguage. (or as a
> | Lars> named keyboard macro).
> |
> | Then we should come up with a scheme which makes documentation and
> | debugging as easy as what John proposes. Let's face it: the current
> | scheme is awful debugging-wise. Every time I need to find a function
> | do-foo, I go in lyxaction to find what the LFUN name is (of course, it
> | is LFUN_BAR, not LFUN_FOO), then go in LyXFunc where there is only a
> | small wrapper around something which is somewhere else...
> |
> | One could mostly try to auto-generate a reference manual from a format
> | similar to what John proposes.
>
> I think that can be just as easily don in the scheme I propose.
>
> Each LFUN is a function Levon and I agree on that, afaisi we disagree
> on how to store the LFUNS and how to dispatch them.
>
> Lgb
I don't even disagree on that !
Dispatch("menu-open eric-bristow") is perfectly possible in my
proposal. If you want it like that, fine (but you will have to solve the
frontend menu case as I mentioned - what is your suggestion here).
Rather it seems the disagreement is you don't like auto-generation,
whereas I consider it necessary for debugging and documentation [1]
purposes.
I'm not sure where the disagreement on the storage system is though ?
thanks
john
p.s. my name is John ...
[1] and not just developer docs, as JMarc points out
--
"Threads are for people who can't program state machines."
- Alan Cox
