Clisp offers two distinct modules to have CLX: mit-clx (old one) and new-clx (as says its name). Current clisp module, through the use of the X USE flag, offers only new-clx module. There is no way to have the other module for people wanting it. I propose to delete X USE flag in favour of two new local USE flags: mit-clx and new-clx. They will be mutually exclusive resulting in: 1. warn users when they are used together 2. for new-clx module compilation when used together. Please comment this proposition.
Created attachment 83765 [details] New ebuild with the two new USE flags Here is the proposed ebuild to achieve that.
*** Bug 128132 has been marked as a duplicate of this bug. ***
I've been thinking about how to implement this. I think we can do with with an extra USE keyword "new-clx" and use it this way: if X in USE, if new-clx in USE, --with-module=clx/new-clx else --with-module=clx/mit-clx The main points here are 1. only one new USE keyword is required, 2. a user wanting X support for CLISP will get mit-clx (which is probably a good default since it works best with other applications, eg. stumpwm). I think you're right about mit-clx and new-clx being mutually exclusive in CLISP builds. I got a lot of this when i tried --with-module=clx/new-clx --with-module=clx/mit-clx: ;; Loading file /tmp/clisp-2.38/src/clx/mit-clx/input.fas ... WARNING: DEFUN/DEFMACRO: redefining function EVENT-LISTEN in /tmp/clisp-2.38/src/clx/mit-clx/input.fas, was defined in C WARNING: DEFUN/DEFMACRO: redefining function QUEUE-EVENT in /tmp/clisp-2.38/src/clx/mit-clx/input.fas, was defined in C WARNING: DEFUN/DEFMACRO: redefining function DISCARD-CURRENT-EVENT in /tmp/clisp-2.38/src/clx/mit-clx/input.fas, was defined in C What parts of stumpwm do not work with CLISP's new-clx?
(In reply to comment #3) > I've been thinking about how to implement this. I think we can do with with an > extra USE keyword "new-clx" and use it this way: > > if X in USE, > if new-clx in USE, > --with-module=clx/new-clx > else > --with-module=clx/mit-clx Yep, that is even better than my solution. > The main points here are 1. only one new USE keyword is required, 2. a user > wanting X support for CLISP will get mit-clx (which is probably a good default > since it works best with other applications, eg. stumpwm). I agree with this. > What parts of stumpwm do not work with CLISP's new-clx? There are several. First one is this awful timeout when you press C-t, second one is a problem with undefined function: > *** - FUNCALL: undefined function XLIB:CHARACTER->KEYSYMS Which can be solved with something like this: (defun character->keysym (ch) "Convert a char to a keysym" ;; XLIB:CHARACTER->KEYSYMS should probably be implemented in NEW-CLX ;; some day. Or just copied from MIT-CLX or some other CLX ;; implementation (see translate.lisp and keysyms.lisp). For now, ;; we do like this. It suffices for modifiers and ASCII symbols. #-clisp (first (xlib:character->keysyms ch)) #+clisp (case ch (:character-set-switch #xFF7E) (:left-shift #xFFE1) (:right-shift #xFFE2) (:left-control #xFFE3) (:right-control #xFFE4) (:caps-lock #xFFE5) (:shift-lock #xFFE6) (:left-meta #xFFE7) (:right-meta #xFFE8) (:left-alt #xFFE9) (:right-alt #xFFEA) (:left-super #xFFEB) (:right-super #xFFEC) (:left-hyper #xFFED) (:right-hyper #xFFEE) (t (etypecase ch (character ;; Latin-1 characters have their own value as keysym (if (< 31 (char-code ch) 256) (char-code ch) (error "Don't know how to get keysym from ~A" ch))))))) Plus many small things that make use of new-clx sucky with stumpwm. I think, it still needs improvements on new-clx side before actually using it effectively.
Created attachment 83850 [details] clisp-2.38-r2.ebuild Ebuild with X support plus new-clx USE flag. X + new-clx => will build new-clx X (alone) => mit-clx WDYT ?
I committed a new ebuild for clisp-2.38-r1. It is basically the same as your attachment. Xavier, I tried responding to your email but your mail server's verification system seems to believe I'm spam! The verification directions say respond to the email simply by pressing "respond", I do a reply in Gnus and I see that the return To: address with "unknown@gnu-rox.org". I send to that address and then I receive another email classifying my mail as spam. Do you have an alternate email address?
Wll, I will remove that auto-respond system which is not working correctly. Sorry for the inconvenience.
