RR-SET-CRTC-CONFIG was unexported, and the extension's errors (and conditions) were undefined.
Additionally, conform the order of the exports and function definitions to that of the opcodes, unexport some undefined functions, wrap some overlong lines, and clean up some comments and whitespace.
I am unsure of the naming convention for errors and conditions (and other symbols in the extensions in general). Various conventions exist in the codebase, e.g., FOO-ERROR in input.lisp, BAD-FOO in a subpackage in extensions/glx.lisp (my preference), and prefixing the errors with a common string (related to the extension name) in extensions/xvidmode.lisp (which is also the convention of extensions/randr.lisp – though not faithfully adhered to – and thus the one I followed in this PR). In #172 I removed the RR- prefix from +RR-CONNECTION+ because first, it was missing from the CONNECTION type, and second, in the RandR specification it has no prefix (unlike RRCONFIGSTATUS, for instance). However, perhaps the extensions should prefix all of their symbols (consistently) to avoid conflicting with each other and with the base library. This would be done, if at all, in a future PR, of course.
I think that the right convention is the one from the core module (which is documented), that is foo-error. Extensions should be adjusted to follow it.
RR-SET-CRTC-CONFIG was unexported, and the extension's errors (and conditions) were undefined.
Additionally, conform the order of the exports and function definitions to that of the opcodes, unexport some undefined functions, wrap some overlong lines, and clean up some comments and whitespace.
I am unsure of the naming convention for errors and conditions (and other symbols in the extensions in general). Various conventions exist in the codebase, e.g., FOO-ERROR in
input.lisp
, BAD-FOO in a subpackage inextensions/glx.lisp
(my preference), and prefixing the errors with a common string (related to the extension name) inextensions/xvidmode.lisp
(which is also the convention ofextensions/randr.lisp
– though not faithfully adhered to – and thus the one I followed in this PR). In #172 I removed the RR- prefix from +RR-CONNECTION+ because first, it was missing from the CONNECTION type, and second, in the RandR specification it has no prefix (unlikeRRCONFIGSTATUS
, for instance). However, perhaps the extensions should prefix all of their symbols (consistently) to avoid conflicting with each other and with the base library. This would be done, if at all, in a future PR, of course.