From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pA4CeLk2030713 for ; Fri, 4 Nov 2011 13:40:21 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8CAIbcs05KfVK2kGdsb2JhbABEFpoJjRiBNYEYCCIBAQEBCQkNBxQEIYFyAQEBAw0GAiwBGxILAQMBERANDUMBEQEFAQoYExIHCYdgCJdsCotUgmGFQT2IcAIFCoM9hWQElByNOj2DcA X-IronPort-AV: E=Sophos;i="4.69,455,1315173600"; d="scan'208";a="128392338" Received: from mail-wy0-f182.google.com ([74.125.82.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Nov 2011 13:40:16 +0100 Received: by wyg36 with SMTP id 36so4175619wyg.27 for ; Fri, 04 Nov 2011 05:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=0btKIteLXfbIH+1JRby/1HtHveJyB4wHY8PSYG8mYJM=; b=Io/D4+WCMvnBEgmmmZCWUQy5OL6GMLeAYN5CzQ0Ml5KkiYkWbfRLcB0mATUzv/lTbB 5uKdGtA4EYToe0SHoY/CsAeM/Zc1uc32dq33qLKH+yPZTpzb9K5HFN1CQ3g3hg5SnOh/ 2vAyAeeSpy151Vib0JfBp1tHpnfYCwqo8DNHk= Received: by 10.227.202.140 with SMTP id fe12mr17490445wbb.27.1320410416123; Fri, 04 Nov 2011 05:40:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.203.134 with HTTP; Fri, 4 Nov 2011 05:39:55 -0700 (PDT) From: Gabriel Scherer Date: Fri, 4 Nov 2011 13:39:55 +0100 Message-ID: To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: Thomas Gazagnaire , caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pA4CeLk2030713 Subject: [Caml-list] Jump-to-definition and type-aware completion for Caml (was : Argot 1.0 release) > But having been recently forced out of emacs into a proprietary IDE to > be *able* to work on a project written in a > programmingLanguageWithAbsurdlyLongNamingConventions, one thing I > actually became very fond of is type aware autocompletion and the > ability to browse from a symbol in my code directly to the page where > its documented. The former may be complex to implement without > compiler support but I'm sure the latter is not. My elisp skills are > however too limited for me to implement that myself but I'd love to > have that in ocaml's emacs mode. There are various external projects/patches to do this kind of things: - Jun Furuse's [Ocamlspotter] is a patch to the compiler to enrich .annot files with where-defined information on symbols. It has some emacs integration code. - Peng Zang's Enhtop+ (an incremental update of Zeng Li's Enhtop enhanced toplevel) provides enviroment lookup capacities in the toplevel. He uses it to build [tuareg-plus], an emacs glue providing context-aware completion (I'm not sure how good it works though, never tried myself) [Ocamlspotter] http://jun.furuse.info/hacks/ocamlspotter [Enhtop+] http://www.cc.gatech.edu/~pengzang/enhtop+.html [Enhtop] http://www.pps.jussieu.fr/~li/software/index.html#enhtop [tuareg-plus] http://www.cc.gatech.edu/~pengzang/tuareg-plus.html Beware that all those projects tend to be built as patches to the ocaml distribution, which means difficult deployment (which means few users, which means few maintenance, which means bitrot). I'm not saying life is *easy* if you wish to use IDE tools for OCaml, only that it is possible. There are surely other alternatives I forgot about (please feel free to add something) and related projects that are interesting as well (eg. Jérémie Dimino 'utop' toplevel). You may also have a look at the various attempts at integrating OCaml with Java IDEs (Oca'IDE, Ocaml Development Tools, etc.). I'm various people are also developing new exciting tools. For example, Ocamlpro has announced that it could/would develop IDE tooling, for example; incidentally, they also work on internal passes dumping techniques that might make development and deployment of such tools easier in the future. On Fri, Nov 4, 2011 at 12:25 PM, Daniel Bünzli wrote: > Hello, > > A few comments on the design. Overall much better than ocaml's current > stylesheet and completely web 2.0 correct. But. > > One problem of web 2.0 correct interfaces is that they are a little > bit patronizing, and don't show enough data. The information density > is too low. Do you really half of my screen to communicate me the name > of the module I'm currently looking at ? Overall I find the spacing to > be too loose. I want to see more information on a screenful. Much more > can be shown, while retaining the ability to rapidly skim from one > definition to the other and without cramping the design. > > Another thing is the fixed-width layout. The width of the page is too > wide. First the lines are too long which causes a readability issue: > it makes it hard to read from one line to the other --- depends on the > font but beyond approx. 80 chars per line it becomes hard for > continuous reading. Second I personally never work on 27-inch > displays. With the current design I cannot put my browser window next > to emacs and read the doc without a horizontal scroll bar. The design > grid should be fluid, within reasonable limits (cf. css's min-width, > max-width and if you want to go wild, media queries to use different > style sheets for different devices widths, a few techniques and > pointers here [1]). > > Finally do something with css' *:target selector it's useful when you > link to anchors that are at the bottom of a page or on a page that is > too small to scroll. E.g. : > > http://erratique.ch/software/cmdliner/doc/Cmdliner.Arg.html#VALpair > >> The goal is to be able to browse it locally (it's a bit awkward to have to run a webserver to read documentation). > > Yes. > >> The searching tools are quite limited currently, > > To me the search tools are not so useful. Usually I know in which > module I want to lookup a function. To get there quickly I use my OS > file search --- thanks to ocamldoc generating one file per module --- > and then the incremental search of my browser. Of course this is quite > different of indexing e.g. the symbols directly but it works well in > practice. > > But having been recently forced out of emacs into a proprietary IDE to > be *able* to work on a project written in a > programmingLanguageWithAbsurdlyLongNamingConventions, one thing I > actually became very fond of is type aware autocompletion and the > ability to browse from a symbol in my code directly to the page where > its documented. The former may be complex to implement without > compiler support but I'm sure the latter is not. My elisp skills are > however too limited for me to implement that myself but I'd love to > have that in ocaml's emacs mode. > > Regarding search by type, I wonder if people actually use this for > useful reasons or if it's just out of curiosity or for the cool hack > factor -- and sure it's cool. I mean there's not enough semantics in > types to tell you what a function will do, and since we curry it is > not always clear in which order we will argument. > > Best, > > Daniel > > [1] http://www.alistapart.com/articles/responsive-web-design/ > > -- > Caml-list mailing list.  Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > >