On Sat, Jan 24, 2015 at 1:05 AM, Louis Gesbert <[email protected]> wrote: > 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.
That sounds good. >> > * 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. That seems totally fine. >> 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) Excellent. I'll take a look. y _______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
