>> 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)
I just noticed it now, when redefining the package. > 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. Although it makes it a little inconvenient to do certain things, maybe it makes sense for `defcommand' to export symbols. I thought of commands like an UI thing, but this is not the only interpretation. I say we keep things like they are for now. _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
