Hi,
Responses inline:
"Diogo F. S. Ramos" <d...@riseup.net> writes:
>>>> 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.
This is understood, which is why the official policy is to open an issue
requesting which symbol you need exported and why (ie you need to use it
in your module).
>
> 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.
Unfortunately, the modules are not good examples of how to write
modules. I can point out some that follow policy, but by and large they
are extremely inconsistent and were just wrapped enough to be loadable
by ASDF, before then they were simply (load)ed based on the contrib-dir
and the filename.
>
> 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.
I agree, this was the path of least resistance when handling the nasty
inconsistencies in how modules were written. While it seemed sound at
the time, I can see now that different developers have different
expectations when you use `defcommand'.
>
> Maybe StumpWM should have two `defcommands'? One for internal use of
> StumpWM, which exports symbols, and one for modules, which doesn't?
No, this is not something I support. If we're going to all agree that
defcommand shouldn't export commands, then we need to go back through
the sources and make sure that each defcommand'ed function is listed in
the export declaration.
Two paths forward:
1. Keep the export command in and make module writers deal with this
edge case. Diogo, how many times on average would you run into this
behavior? This only happens when you redefine the package right? I'm
not trying to be dismissive, I really don't know how many times you
would have to deal with this. (My understanding is that you would
have to completely reload your StumpWM instance to fix this)
2. Remove the export and manually move the defcommands into the export
lines of the packages. This involves a lot of tedious code changes,
(not that I'm opposed). It also puts the responsibility on the person
who defcommands to decide whether it should be exported.
Cheers,
Dave
_______________________________________________
Stumpwm-devel mailing list
Stumpwm-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
