Re: [Xmonad] darcs patch: XSelection.hs: simplify creation of window (and 10 more)

On 2007.10.23 15:36:12 +0200, Andrea Rossato scribbled 0 lines:

On Tue, Oct 23, 2007 at 08:20:50AM -0400, Gwern Branwen wrote:

...

On 2007.10.23 11:29:34 +0300, "Valery V. Vorotyntsev" scribbled 0 lines:

...

On 10/19/07, gwern0@gmail.com wrote:

...

Fri Oct 19 14:09:00 EDT 2007 gwern0@gmail.com * Run.hs, ShellPrompt.sh: mv runInXTerm to ShellPrompt.hs

What is the purpose of this moving? IMHO, the function fits nicely in Run.hs.

IIRC, leaving runInXTerm in Run.hs causes a cyclical import - but I might have moved it because it made more sense to me in there.

...

...

Fri Oct 19 14:12:32 EDT 2007 gwern0@gmail.com * XSelection.hs: fmt imports and sigs

Fri Oct 19 14:12:55 EDT 2007 gwern0@gmail.com * SshPrompt.hs: fmt imports and update

Fri Oct 19 14:13:17 EDT 2007 gwern0@gmail.com * ShellPrompt.hs: fmt imports and update

The code looks somewhat polluted now. :) ``*Do not use explicit import lists*, except to resolve name clashes.'' - GHC Coding Style Guidelines, http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle

-- WBR, vvv

Well, I'm not sure what's right for GHC's modules is right for XMonad's modules. I personally find they make things easier, but that may be just me.

I must confess I don't think I like these patches very much. Lately I was very busy with the starting of the new semester and didn't have time to review the code carefully (I still have to pull them) but they add functionalities that seem not to be related to a shell prompt at first sight, and should probably belong to a different module.

Regarding the style: I hope that Don will come up with some coding convention I remember he was talking about.

For the time being, and for the code I maintain, I believe that patches should not change the coding style of a module to adapt it to every contributor's own feelings. This would lead to some confusion. So, if the coding style of a module is not a specific issue itself, I would leave it unchanged, or let the original author decide. And so I think I'll bring that module back to its pristine status.

Yes, this struck me as possible, which is why the formatting was (generally) split out to their own patches. I didn't separate them as cleanly as I could have, perhaps, but I didn't *really* expect anyone to take exception.

I'll probably going to add a different version of the main function, because I think it could be useful a different way of handling completion since the latest changes were not welcome but everyone - the way you use the prompt may required "unoptimized" code for efficiency.

The other prompts - but I will first review the problem more carefully - can be moved to a new prompt module, connected to XSelection if I understand correctly the issue.

The prompts which use XSelection's getSelection are already in XSelection - unsafePromptSelection, and safePromptSelection. They do rely on the safeSpawn and unsafeSpawn in Run.hs however, and have nothing to do with ShellPrompt.

Cheers, Andrea

-- gwern fake E-Bomb NAAP FSF WORM SUW NMI Merlin charge CUN