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

[Andrea Rossato]

On Tue, Oct 23, 2007 at 08:20:50AM -0400, Gwern Branwen wrote:
> On 2007.10.23 11:29:34 +0300, "Valery V. Vorotyntsev" <valery.vv at gmail.com> scribbled 0 lines:
> > On 10/19/07, gwern0 at gmail.com <gwern0 at gmail.com> wrote:
> > >
> > > Fri Oct 19 14:09:00 EDT 2007  gwern0 at 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 at gmail.com
> > >   * XSelection.hs: fmt imports and sigs
> > >
> > > Fri Oct 19 14:12:55 EDT 2007  gwern0 at gmail.com
> > >   * SshPrompt.hs: fmt imports and update
> > >
> > > Fri Oct 19 14:13:17 EDT 2007  gwern0 at 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.

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.

Cheers,
Andrea