Re: User preferences lost between Hugs upgrades on Windows
[some possibly shared hugs/ghci concerns]
The settings on Windows are stored under a registry key for each specific release. This means that if you install WinHugs, carefully set up everything, then upgrade, you loose all your settings.
part of the reason was also to enable multiple independent versions of Hugs to be installed, I think? So: a) shouldn't there be a way from within Hugs (or GHCi) to export/import settings? b) shouldn't there be an installation option checking for compatible old settings and offering to copy them? c) given the move towards cabal, shouldn't there be a way for new Hugs/GHC installs to take over existing library install setups (provided that the libraries sources haven't been removed, and that the rebuild is possible with the new Haskell implementation)? while on the subject of user preferences, does the current round of Hugs/GHC releases on Windows do away with that "we take over the handling of Haskell files, no matter what the user wanted"? - it's a pain to have Hugs and GHCi compete with each other on this - I don't want either to be the default handler for .hs/.lhs files; not only do I tend to have several versions of Haskell implementations installed at any time (usually including 2 ghcs), I want Haskell files to open in my favourite editor, not in any of those Haskell implementations (and no, going via WinHugs :e is not an option, eg when browsing files from some darcs repo on the web) any chance of Haskell implementations being less greedy and more cooperative on Windows this time round?-) cheers, claus
Hi,
a) shouldn't there be a way from within Hugs (or GHCi) to export/import settings?
That can be added, but no one will use it - too much effort, not obvious thats what needs to be done.
b) shouldn't there be an installation option checking for compatible old settings and offering to copy them?
Reasonable, although I still think just having one set of settings is a better way forward.
c) given the move towards cabal, shouldn't there be a way for new Hugs/GHC installs to take over existing library install setups (provided that the libraries sources haven't been removed, and that the rebuild is possible with the new Haskell implementation)?
A cabal issue, since Hugs has no knowledge of Cabal, but a reasonable idea.
while on the subject of user preferences, does the current round of Hugs/GHC releases on Windows do away with that "we take over the handling of Haskell files, no matter what the user wanted"?
Nope :) I emailed off to people about this offering to cooperate nicely with GHC and Hugs, but no one ever got back to me, so both WinHugs and GHC steal the preferences. GHC also replaces the .hs document icon with one that is more ugly. I tried to submit a patch, and have emailed over the icons, but the GHC installer stuff isn't publically available, so I have no way to fix it.
- I don't want either to be the default handler for .hs/.lhs files; not only do I tend to have several versions of Haskell implementations installed at any time (usually including 2 ghcs), I want Haskell files to open in my favourite editor, not in any of those Haskell implementations (and no, going via WinHugs :e is not an option, eg when browsing files from some darcs repo on the web)
Have you used a recent copy of WinHugs? The default action is to open the file in WinHugs, but there is also an "edit" action which opens the file in whichever editor you have configured WinHugs to use. It does this by firing off WinHugs, checking your settings for the best haskell editor, and starting it. If you haven't configured any editor specially, it will find the editor that seems best - i.e. if you have TextPad and Notepad, it will pick TextPad, otherwise it will pick Notepad if thats all it can find. All very seamless. I'd love to make Edit be the default, i.e. rename it to Open, and then add Open with WinHugs. However, this is a change in how WinHugs operates. Initially I tried to adhere quite closely to how WinHugs worked before I hacked on it, now I think the time has come to have Open be Edit and add Open in WinHugs.
any chance of Haskell implementations being less greedy and more cooperative on Windows this time round?-)
This time around, no - you just missed the boat on WinHugs and you're probably too late for GHC 6.6. Next time around, perhaps. I'm willing to do the WinHugs side, but it does need someone to do the GHC side. This is especially important because (as far as I was able to make out last time I started asking questions), the GHC installer is generated with a proprietory Haskell script which is not publically available. This means the community cannot play with the GHC installer and fix these issues. I am willing to adapt the Hugs on Windows installer to GHC, if thats something the GHC team would rather? You could also then have nightly builds that included an installer. For reference, Yhc is moving to the Hugs installer, and the Yhc nightly builds will come with an installer. For the moment Yhc won't register any file extensions, but if some suitable agreement can be found, I'll make sure Yhc follows that. Thanks Neil
while on the subject of user preferences, does the current round of Hugs/GHC releases on Windows do away with that "we take over the handling of Haskell files, no matter what the user wanted"?
Nope :) I emailed off to people about this offering to cooperate nicely with GHC and Hugs, but no one ever got back to me, so both WinHugs and GHC steal the preferences. ..
well, you can't change what other people do, but you can make sure that Hugs doesn't steal ;) - register file type handlers optionally (I think Hugs already does this, but GHC doesn't?) - only _add_ file type handlers, never override existing ones nor change the default handler without user confirmation Haskell beginners will not have any Haskell file type handlers registered, but even then the installers should ask before setting defaults, shouldn't they?
(and no, going via WinHugs :e is not an option, eg when browsing files from some darcs repo on the web)
Have you used a recent copy of WinHugs?
oops. I was sure I had, and had encountered problems with starting the editor (:e) on internet files which WinHugs was not equipped to handle (non-standard extensions, missing imports, ..). something like messed up temporary files paths to the downloaded file, which the editor couldn't find when called from WinHugs, I seem to recall.. - but I can't reproduce the problem with "Version: 20051031". offering to call an editor via WinHugs looks nice and convenient when there are no editors registered, but isn't really the way to go otherwise, is it? There was a time when I needed to open Haskell files with several editors, for testing, and in any case, why should editor actions go via other software?
I'd love to make Edit be the default, i.e. rename it to Open, and then add Open with WinHugs. However, this is a change in how WinHugs operates. Initially I tried to adhere quite closely to how WinHugs worked before I hacked on it, now I think the time has come to have Open be Edit and add Open in WinHugs.
why not make that "Open with WinHugs" and "Edit via WinHugs" and let the user decide which, if any, of these should be default?
any chance of Haskell implementations being less greedy and more cooperative on Windows this time round?-)
This time around, no - you just missed the boat on WinHugs and you're probably too late for GHC 6.6. Next time around, perhaps.
oh, you mean I should have mentioned this earlier, as in http://www.haskell.org/pipermail/glasgow-haskell-users/2004-March/006402.htm... http://www.haskell.org/pipermail/hugs-users/2006-February/000656.html for instance?-) cheers, claus
Hi
well, you can't change what other people do, but you can make sure that Hugs doesn't steal ;)
If there are two of you, one that does steal, one that doesn't, I might as well make the Hugs installer register GHC as the extension handler! It's also a bit annoying to do a load of work to get around problems in an open source program, when a much nicer solution could be obtained by cooperation.
- register file type handlers optionally (I think Hugs already does this, but GHC doesn't?) Hugs definately has this as an option (on by default).
- only _add_ file type handlers, never override existing ones nor change the default handler without user confirmation Well, the user has to choose, so they have made confirmation. The way the extension registry system works, this is quite hard! You register an extension with a class, and then you put the available methods in that class. It would be very rude (and fragile) to shove the methods in someone elses class. If there is some cooperation, and agreement before hand (i.e. GHC won't delete the common Hugs/GHC class on uninstall etc. if there is still a Hugs entry), it can be done, but not by one side only.
Have you used a recent copy of WinHugs?
oops. I was sure I had, and had encountered problems with starting the editor (:e) on internet files which WinHugs was not equipped to handle (non-standard extensions, missing imports, ..). something like messed up temporary files paths to the downloaded file, which the editor couldn't find when called from WinHugs, I seem to recall.. - but I can't reproduce the problem with "Version: 20051031".
Good good :) I did rewrite all the editor code substantially for WinHugs.
offering to call an editor via WinHugs looks nice and convenient when there are no editors registered, but isn't really the way to go otherwise, is it? There was a time when I needed to open Haskell files with several editors, for testing, and in any case, why should editor actions go via other software?
The reason editor preference should go via WinHugs, is because the user has selected their preferred text editor in WinHugs, so at that point WinHugs probably has a better chance of guessing which text editor is best. If they register explicit file handlers for .hs we should respect them however.
why not make that "Open with WinHugs" and "Edit via WinHugs" and let the user decide which, if any, of these should be default?
From what I remember, defaults in extension handlers don't work that way :) I think it might be possible though, and I'd love to be able in WinHugs to let the user pick "Open in GHCi" as their preferred option.
oh, you mean I should have mentioned this earlier, as in
http://www.haskell.org/pipermail/glasgow-haskell-users/2004-March/006402.htm... http://www.haskell.org/pipermail/hugs-users/2006-February/000656.html
You're not the only one: http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/14819/ Thanks Neil
participants (2)
-
Claus Reinke -
Neil Mitchell