Miciah Dashiel Butler Masters <[EMAIL PROTECTED]> writes: > Maybe you should do the same for enum term_event_type as you do for > struct term_event_size.
I guess you mean doing #define interlink_event_type term_event_type and then using enum interlink_event_type. Now, should that enum use the existing constants like EVENT_MOUSE, or should one also #define INTERLINK_EVENT_MOUSE EVENT_MOUSE etc.? Using the existing constants with enum interlink_event_type would lead to bugs should the types ever diverge. Aliasing structures is safer than aliasing enumerations because the compiler will usually notice type mismatches. If there were separate INTERLINK_EVENT_MOUSE etc. constants, then handle_interlink_event would have to explicitly map INTERLINK_EVENT_REDRAW to EVENT_REDRAW, and INTERLINK_EVENT_RESIZE to EVENT_RESIZE; it should not assume that the values are identical. I did not want to add such complexity before it is actually needed. > Maybe this isn't the best thread in which to bring this up, but reading > code like this leads me to wonder why we have set_kbd_term_event, > kbd_set, and so on. Right here, you show that we aren't doing it for > opacity, and surely they don't make such a huge dent in LOC. All they do > is hide some memsets and assignments behind mazes of macros. I assumed their purpose was to ensure that every member of e.g. ev->info.keyboard is actually initialized with an intentional value, rather than just cleared with memset. If a member is added to the structure, then a corresponding parameter will also be added to the macro, and the compiler will notice if something doesn't provide enough parameters. I could be wrong though....
pgpF9gVP2W4JN.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
