Re: [patch 04/11] terminal: Define separate structs for

Kalle Olavi Niemitalo <[email protected]>
Newsgroups gmane.comp.web.links
Message-ID <[email protected]>
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....

_______________________________________________
elinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
signature.asc (application/pgp-signature, 188 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFE1QO2Hm9IGt60eMgRAjEzAJ9OWi5+JCcsxJByRmK/QOfAdcjWxQCg7fhX
KWaetfQAzRjQ9AWjM1yizvw=
=z+3H
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.