caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: bcpierce@cis.upenn.edu, caml-list@inria.fr
Subject: [Caml-list] Re: ocamlbrowser [was labels]
Date: Sun, 01 Apr 2001 18:28:17 +0900	[thread overview]
Message-ID: <20010401182817E.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <27280.986075478@saul.cis.upenn.edu>

Hi Benli,

Thanks for the feedback. This is what is needed to improve
ocamlbrowser :-)

> I've tried OCamlBrowser on a few occasions, but its default behavior
> is not quite intuitive enough for me to make it easier than looking
> things up in the ocaml manual.  Here are a few reasons...
> 
> * I was never able to make the search functions work (which is precisely
> what would have made it REALLY useful).  

That's pretty strange. You just have to input a defined name in the
entry field and press Search. Remark that it can take a long time when
you do it for the first time, since it must load all the .cmi in the
load path.
I would suggest you first read the 2 pages in the manual describing
how ocamlbrowser works, they should answer some of your questions.
In particular it explains how to search using type patterns.

> * Since it uses pop-up windows, I find that my screen quickly fills up
> with dozens of windows so that pretty soon I can't find anything or see
> what I'm doing.  I wonder whether it would be worth considering managing
> those windows yourself (i.e., enclosing them all in some big window that
> you manage) and using some kind of tiling scheme to manage the space
> better (with history/focus mechanisms to help recover recently viewed
> stuff).

As somebody else suggests, moving to a more smalltalk style navigation
would not be difficult. The current approach is mainly due to a
historical evolution, taking for first model the original camlbrowser,
where one window pops up for every definition!
In the current system you have one window per module, but one could
easily have a single window for all modules, as long as we do not have
recursive modules including each other...
I could include this as another style of UI.

Yet, I'm not 100% sure it would be better. The way you use
ocamlbrowser is different from a smalltalk browser, in that most of
the navigation is done through types: first look for a function, then
for the definition of the type of one of its argument, then for the
definition of a type appearing inside this definition... You often
want to see several things at once, and the current approach can help
there. Once in a while you press close all to collect the garbage.

> * Adding a path to the search path does not seem to have any persistent
> effect, so every time I restart I have to manually fix up the paths to
> find the lablgtk libraries, for example.  (I know there must be
> command-line switches to do this, but I have never become a serious
> enough user to look for them.  What I'm describing here is my experiences
> as a naive, occasional user.)  

Same syntax as ocamlc: use "ocamlbrowser -I +lablgtk".
If you define aliases, you can have several paths: that's the Unix
way.
I was only too lazy to develop a preference file format. That would
really be a nice utility module to share between Caml applications,
and it would help to have a compatible syntax. Could the unison
preference format be made an independent, reusable module ?

> Even better would be to be able to switch easily *between* sets of paths
> (something like Unison's named profiles), so that I could keep the
> standard OCaml libraries in one pane, the lablgtk interfaces in another,
> and the Unison sources in another.  When they're mixed together, the main
> interface list gets too long and it's difficult to find things.

This problem of list length is real. What you really want is to use
the same path (because it is also used for type checking), but to
restrict the list (and maybe search) to the part of the path your are
interested in. This could be done.

> * One feature that I'd REALLY like would be the ability to click on a use
> of an identifier and be transported to its def-site.  Similarly, I'd like
> to be able to click on a declaration in a .mli file and be taken to the
> corresponding definition in the .ml file.  I guess doing this right 100%
> of the time might be hard (at least, it might require help from the
> compiler), but I'll bet a simple guess would usually be OK.

You can. Because of the Amazon patent, this is not single click:
first type check the file you are browsing with Alt-t, then
double click once on the identifier to get to its interface
declaration, and then press either Impl (for implementation) or Intf
(for the interface, including comments).
It should be 100% correct.

Best regards,

Jacques
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr


  parent reply	other threads:[~2001-04-01  9:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-29 19:56 [Caml-list] Future of labels Manuel Fahndrich
2001-03-30  3:01 ` Jacques Garrigue
2001-03-30  8:23   ` Markus Mottl
2001-03-30  9:45   ` kahl
2001-03-30 10:43     ` Jacques Garrigue
2001-03-30 12:32       ` Benjamin C. Pierce
2001-03-31 21:52         ` [Caml-list] ocamlbrowser [was labels] Brock
     [not found]           ` <27280.986075478@saul.cis.upenn.edu>
2001-04-01  9:28             ` Jacques Garrigue [this message]
2001-04-01 21:16               ` [Caml-list] " Benjamin C. Pierce
2001-04-03 17:43                 ` Francisco Valverde Albacete
2001-04-04  7:56                   ` Michael Hicks
2001-04-09  4:43                 ` John Max Skaller
2001-03-30 10:39   ` [Caml-list] Future of labels Judicael Courant
2001-03-30 10:54     ` Jacques Garrigue
2001-03-30 11:22   ` Francois Pottier
2001-03-30 12:41     ` Benjamin C. Pierce
2001-03-30 14:16       ` Jean-Marc Alliot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010401182817E.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=bcpierce@cis.upenn.edu \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).