Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: [Caml-list] Future of labels
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: [Caml-list] Re: ocamlbrowser [was labels]
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