You're making important points; this is an area where pragmatism is way above consistency or simplicity of design, just because the one direction it'll have to scale is users.
> > * this is not focused on advanced users with multiple switches, > > etc. and it makes the configuration simpler to understand and > > edit. > > Fair, although it would be a lot better if this created dot files that > were suitable for people who wanted to extend to more advanced use > later. Setting up emacs files and the like is quite painful, even for > sophisticated users, and I think a lot of them would appreciate the > help. Agreed: best if it can be scaled to the needs of more advanced users without having to restart configuring from scratch, let's not add more steps than needed. > > * user-setup configures editors depending on what is installed in > > the current switch ; it may not make sense in other switches. > > I'm tempted to think that this is a mistake, as I said in my previous > email. I think we'd probably get a more readable and robust set of > emacs configs if they just auto-detected what was there, and > conditionally enabled those bits of editor automation. Hmm, I was afraid of writing something that could get inconsistent, but indeed, if possible, there is no good reason not to add the detection code in the editor itself. Tool-configuration snippets may still be useful in some cases (less versatile editors), but it's best to put as much as possible in the base snippet for the editor. > > * some tools are generally useful (tuareg, ocp-indent) and > > installing them in one switch should be enough. There is a clear > > distinction though for compiler-version dependent tools (merlin, > > ocp-index). > > Yeah, that's a good point. I think I'd personally prefer to just > install tuareg and ocp-indent and the like in all my switches, and > have merlin and ocp-index work properly as I > switch.https://github.com/AltGr/opam-user-setup Nothing is actually preventing us from being static for the first class of tools (tuareg, indent), and dynamic for the second class (compiler-specific ones), except maybe complexity and readability. I'd like to have similar (dynamic) code for all, but then set a static path for first-class tools so that it'll still work if you don't install them everywhere. > > * this approach is guaranteed to be available for all editors. > > Perhaps we should do something more custom for individual editors. We > could just have different packages for different editors, vim-support, > sublime-text-support, emacs-support, etc, which had some useful > dot-files and a setup script for them. I'm not sure a one-size-fits-all > -editors approach is going to really be possible here. I'd still like to try: there is an (editor x tool) matrix that can quickly gain in size, and gathering everything at a single place will really help maintaining various combinations, or at least knowing were to search. If it explodes in size, we can still start referring to other packages. > If we get user-setup to install a robust set of emacs (or vim, or > sublime text...) macros, there isn't really a switch problem. After > all, my current emacs configs work fine when I flip between different > switches. If all user-setup is a set of configs to install such > robust scripts, we're in a pretty good place. > > In other words, maybe we should focus on building highly robust > scripts first, and then just have an easy delivery mechanism for those > scripts in opam. That's indeed my goal, maybe I over-engineered the tool. But I am also concerned with the convergence for such scripts: everyone typically tends to have his or her own tailored version of the editor configuration, and is generally reluctant to swap it for one in n integrated solutions, so it's really important to manage and focus the effort somewhere for establishing and testing these files. I just updated the README at https://github.com/AltGr/opam-user-setup to reflect these thoughts in one place (it's by no means the end of discussion) Best, Louis _______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
