stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] Why does `defcommand' export the command symbol?


From: Diogo F. S. Ramos
Subject: Re: [STUMP] Why does `defcommand' export the command symbol?
Date: Sat, 08 Nov 2014 10:05:03 -0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

>>> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]