>>> I have some vague memory of this being added in a pull request shortly >>> after I started maintaining stump... >> >>The commit might be 0df1e87. >> >>The commit message reads: >> >> Defcommand exports the command to the UI. Obviously it should export >> the command t the API. > > And the reason for that was that without that most of the modules break > because they use otherwise-unexported commands from StumpWM UI.
StumpWM has an inconsistency set of exported symbols. In my module, I use exported and internal ones. So it is possible, and sometimes necessary, to use internal StumpWM symbols within modules. So it is not strictly necessary for `defcommand' to export symbols defining new commands. There is also no consistence on how modules are written. Some use (in-package :stumpwm), so they access all StumpWM symbols and define new symbols for the StumpWM packages. Others define separate packages and hence are affected by symbol visibility, but like I said in the first paragraph, they might need to access internal symbols anyway. I am talking from the point of view of a module writer. Defining new commands doesn't mean I want to export symbols. And exporting symbols inside the macro was surprising and caused a little problem. Maybe StumpWM should have two `defcommands'? One for internal use of StumpWM, which exports symbols, and one for modules, which doesn't? I am not so sure myself tho. That is why I asked for the reason for the exporting in the first place. > Also, I think I have the same situation that you describe with SBCL and > SBCL gives a continuable warning for this (i.e. I do asdf:load-system > and see the warning and then the load succeeds). Your warning might be related to this, but like I said in a previous message, my error is triggered when I try to compile a new definition of `defpackage' after defining some commands in the package. _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
