[Caml-list] new emacs tuareg mode release
Sam Steingold
The original author of the alternative Emacs mode for editing Ocaml code
(tuareg-mode), Albert Cohen, has stopped development some time ago.
Now, with his blessing, Jane Street Capital took over maintenance of the code
from him, and released Tuareg Mode v. 2.0.0.
It is available for download at <http://www.janestreet.com/ocaml/tuareg.tgz>.
It is still released under the GNU General Public License (GPL) v2.
Please report bugs and submit patches to the dedicated public mailing list at
<http://groups.google.com/group/tuareg-mode>.
Happy hacking!
Sam
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Stéphane Glondu
> Now, with his blessing, Jane Street Capital took over maintenance of the
> code from him, and released Tuareg Mode v. 2.0.0.
> It is available for download at
> <http://www.janestreet.com/ocaml/tuareg.tgz>.
Is there some kind of project page, with available versions? A place to
check for new releases, if you will...
Cheers,
--
Stéphane
Sam Steingold
> Sam Steingold a écrit :
>
> > Now, with his blessing, Jane Street Capital took over maintenance of the
> > code from him, and released Tuareg Mode v. 2.0.0.
> > It is available for download at
> > <http://www.janestreet.com/ocaml/tuareg.tgz>.
>
> Is there some kind of project page, with available versions? A place to
> check for new releases, if you will...
new releases will be announced on the tuareg-mode and caml-list mailing lists.
--
Sam Steingold <http://sds.podval.org>
Philip
> Hi,
> The original author of the alternative Emacs mode for editing Ocaml code
> (tuareg-mode), Albert Cohen, has stopped development some time ago.
> Now, with his blessing, Jane Street Capital took over maintenance of the code
> from him, and released Tuareg Mode v. 2.0.0.
> It is available for download at <http://www.janestreet.com/ocaml/tuareg.tgz>.
> It is still released under the GNU General Public License (GPL) v2.
> Please report bugs and submit patches to the dedicated public mailing list at
> <http://groups.google.com/group/tuareg-mode>.
> Happy hacking!
> Sam
>
philip@io:~/Desktop/tuareg$ make
emacs -batch -q -f batch-byte-compile tuareg.el
Loading 00debian-vars...
No /etc/mailname. Reverting to default...
Loading /etc/emacs/site-start.d/50a2ps.el (source)...
Error while loading 50a2ps: Symbol's value as variable is void:
a2ps-region
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el
(source)...
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el
(source)...
Loading /etc/emacs/site-start.d/50festival.el (source)...
Loading /etc/emacs/site-start.d/50git-core.el (source)...
Loading /etc/emacs/site-start.d/50ocaml-mode.el (source)...
Loading /etc/emacs/site-start.d/50psvn.el (source)...
Loading /etc/emacs/site-start.d/51tuareg-mode.el (source)...
In toplevel form:
tuareg.el:1933:1:Error: Invalid modifier in string
make: *** [tuareg.elc] Error 1
-philip
Sam Steingold
> Hi, i get an error:
>
> philip@io:~/Desktop/tuareg$ make
> emacs -batch -q -f batch-byte-compile tuareg.el
> Loading 00debian-vars...
> No /etc/mailname. Reverting to default...
> Loading /etc/emacs/site-start.d/50a2ps.el (source)...
> Error while loading 50a2ps: Symbol's value as variable is void:
> a2ps-region
> Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
> Loading debian-ispell...
> Loading /var/cache/dictionaries-common/emacsen-ispell-default.el
> (source)...
> Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el
> (source)...
> Loading /etc/emacs/site-start.d/50festival.el (source)...
> Loading /etc/emacs/site-start.d/50git-core.el (source)...
> Loading /etc/emacs/site-start.d/50ocaml-mode.el (source)...
> Loading /etc/emacs/site-start.d/50psvn.el (source)...
> Loading /etc/emacs/site-start.d/51tuareg-mode.el (source)...
>
> In toplevel form:
> tuareg.el:1933:1:Error: Invalid modifier in string
> make: *** [tuareg.elc] Error 1
what is your emacs version?
could you please add "--no-site-file" to the emacs invocations:
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
EMACS = emacs
-BATCH = -batch -q --load tuareg.elc
+BATCH = -batch -q --no-site-file --load tuareg.elc
RM = rm -rf
CP = cp -f
LN = ln
@@ -21,7 +21,7 @@
elc : $(ELC)
%.elc : %.el
- $(EMACS) -batch -q -f batch-byte-compile $<
+ $(EMACS) -batch -q --no-site-file -f batch-byte-compile $<
camldebug.elc : camldebug.el tuareg.elc
--
Sam Steingold <http://sds.podval.org>
_______________________________________________
blue storm
advice someone told me that it was better than the standard caml
mode), and have recently wondered if that choice was motivated by
rational reasons. When I looked at it, I discovered that the original
caml mode has overall the same set of features (with some of them
coming earlier due to it being maintained by the OCaml team), was
reasonably well documented and was split in multiple source files
instead of one monolithic .el for tuareg-mode. I switched to the
standard caml-mode. The indentation, coloring and shorctuts are a bit
different, but otherwise I don't see what motivated the better tuareg
reputation.
Are you planning to add new features that would make tuareg decisively
better ? Have I missed some existing killer feature ? Why did you
choose to maintain the tuareg mode instead of collaborating with the
caml-mode upstream ?
Philip
> Error 1
>
> what is your emacs version?
Hi,
GNU Emacs 22.2.1 ,ubuntu 10.04
> could you please add "--no-site-file" to the emacs invocations:
>
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -1,5 +1,5 @@
> EMACS = emacs
> -BATCH = -batch -q --load tuareg.elc
> +BATCH = -batch -q --no-site-file --load tuareg.elc
> RM = rm -rf
> CP = cp -f
> LN = ln
> @@ -21,7 +21,7 @@
> elc : $(ELC)
>
> %.elc : %.el
> - $(EMACS) -batch -q -f batch-byte-compile $<
> + $(EMACS) -batch -q --no-site-file -f batch-byte-compile $<
>
> camldebug.elc : camldebug.el tuareg.elc
>
done, but same error:
philip@io:~/Desktop/tuareg$ make
emacs -batch -q --no-site-file -f batch-byte-compile append-tuareg.el
Wrote /home/philip/Desktop/tuareg/append-tuareg.elc
emacs -batch -q --no-site-file -f batch-byte-compile tuareg.el
In toplevel form:
tuareg.el:1933:1:Error: Invalid modifier in string
make: *** [tuareg.elc] Error 1
_______________________________________________
Sam Steingold
wfm with 23.1 and 24.0
> philip@io:~/Desktop/tuareg$ make
>
> emacs -batch -q --no-site-file -f batch-byte-compile append-tuareg.el
> Wrote /home/philip/Desktop/tuareg/append-tuareg.elc
> emacs -batch -q --no-site-file -f batch-byte-compile tuareg.el
>
> In toplevel form:
> tuareg.el:1933:1:Error: Invalid modifier in string
> make: *** [tuareg.elc] Error 1
my tuareg.el has this as line 1933:
(defun tuareg-semicolon-indent-kwop-point (&optional leading-semi-colon)
I have no idea what could be causing this error.
please try to investigate this yourself to produce a small test case.
e.g., try removing this or the previous form.
--
Sam Steingold <http://sds.podval.org>
_______________________________________________
Eliot Handelman
> my tuareg.el has this as line 1933:
> (defun tuareg-semicolon-indent-kwop-point (&optional leading-semi-colon)
>
> I have no idea what could be causing this error.
>
> please try to investigate this yourself to produce a small test case.
> e.g., try removing this or the previous form.
>
>
Sam,
I have the same problem with 22.3.1
playing around, this construction seems to be causing some invalid
modifier errors:
(skip-syntax-backward "\s-")
in tuareg-find-colon-typespec and other places
and also captive= as a let variable seems to cause problems in
tuareg-indent-from-previous-kwop. commenting all these things out
(or changing the var name) the file does load.
best,
-- eliot
Jan Rehders
Sam Steingold
On 5/24/10, Eliot Handelman <el...@colba.net> wrote:
>
> I have the same problem with 22.3.1
>
> playing around, this construction seems to be causing some invalid modifier
> errors:
> (skip-syntax-backward "\s-")
>
> in tuareg-find-colon-typespec and other places
what kind of error?
I.e., start emacs like this:
$ emacs -q --no-site-file
and type in the *scratch* buffer and tell me what you type and cut and
paste the error message from the *Messages* buffer.
> and also captive= as a let variable seems to cause problems in
> tuareg-indent-from-previous-kwop. commenting all these
> things out
> (or changing the var name) the file does load.
what problems? again, please start from a fresh emacs and try to reproduce.
thanks.
--
Sam Steingold <http://sds.podval.org>
_______________________________________________
Mehdi Dogguy
> Sam Steingold wrote:
>> Please report bugs and submit patches to the dedicated public mailing
>> list at
>> <http://groups.google.com/group/tuareg-mode>.
>
> Please use https://forge.ocamlcore.org/projects/tuareg/ instead.
> bugs: https://forge.ocamlcore.org/tracker/?atid=255&group_id=43&func=browse
> patches:
> https://forge.ocamlcore.org/tracker/?atid=257&group_id=43&func=browse
> support:
> https://forge.ocamlcore.org/tracker/?atid=256&group_id=43&func=browse
>
The SVN repository seems to contain the old version of tuareg-mode
(which I find curious). Do you intend to update the SVN repository at
some point?
Regards,
--
Mehdi Dogguy مهدي الدڤي
http://www.pps.jussieu.fr/~dogguy
Christophe TROESTLER
>
> On 05/24/2010 11:44 PM, Sam Steingold wrote:
> > Sam Steingold wrote:
> >> Please report bugs and submit patches to the dedicated public mailing
> >> list at
> >> <http://groups.google.com/group/tuareg-mode>.
> >
> > Not any more.
> > Please use https://forge.ocamlcore.org/projects/tuareg/ instead.
> > bugs: https://forge.ocamlcore.org/tracker/?atid=255&group_id=43&func=browse
> > patches:
> > https://forge.ocamlcore.org/tracker/?atid=257&group_id=43&func=browse
> > support:
> > https://forge.ocamlcore.org/tracker/?atid=256&group_id=43&func=browse
> >
>
> The SVN repository seems to contain the old version of tuareg-mode
> (which I find curious). Do you intend to update the SVN repository at
> some point?
The main development line will use mercurial. In intend to overwrite
it after the hg repo is uploaded.
Best,
C.
Stéphane Glondu
>> I have the same problem with 22.3.1
>>
>> playing around, this construction seems to be causing some invalid modifier
>> errors:
>> (skip-syntax-backward "\s-")
>>
>> in tuareg-find-colon-typespec and other places
>
> what kind of error?
> I.e., start emacs like this:
> $ emacs -q --no-site-file
> and type in the *scratch* buffer and tell me what you type and cut and
> paste the error message from the *Messages* buffer.
On emacs 22.3.1,
(skip-syntax-backward "\s-")
gives the backtrace:
Debugger entered--Lisp error: (error "Invalid modifier in string")
read(#<buffer *scratch*>)
preceding-sexp()
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp)
recursive-edit()
byte-code("\306^P
@\307=\203!^@\310\311\312\"\210\313\311!\211^ZA@)\242\314=\203!^@\310\315\312\"\210\316^K!\210\317
\210\320 !\210\f\203c^@\321ed\"^MV\203W^@eb\210\322^$
debug(error (error "Invalid modifier in string"))
read(#<buffer *scratch*>)
preceding-sexp()
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp)
(and nothing in *Messages*)
By the way, I wasn't able to find documentation for this construct. The
"\s" is responsible, but I have no idea what is its semantics. I have
not been able to observe a behaviour different than with just
(skip-syntax-backward "-").
Cheers,
--
Stéphane
Tom Hutchinson
I too have wondered about the differences between tuareg mode and caml mode.
I noticed that key bindings are different and formatting is handled a little differently. I have never seen a good comparison between the two though. Or why tuareg-mode exists at all (instead of improving caml mode).
Another thing is that in the tuareg mode documentation, there is no mention that you need to install files from caml mode. It seems like C-c C-t (type throwback) only works after installing caml-types.el from caml mode. What other files from caml mode need to be installed?
I'm glad to see ocamlspot.el is included now.
Thanks
Tom
Eliot Handelman
> I would be most interested to hear answers to this e-mail.
>
> I too have wondered about the differences between tuareg mode and caml mode.
>
screwups involving comments. For
example font-lock didn't work on multiline comments. This gave all
comments an ugly random
colorization. I was very happy to discover this had been fixed in tuareg.
-- eliot
Jacques Garrigue
> Tom Hutchinson wrote:
>> I would be most interested to hear answers to this e-mail.
>>
>> I too have wondered about the differences between tuareg mode and caml
>> mode.
>>
> One of the major differences I found (emacs 22.3.1) were persistent
> screwups involving comments. For
> example font-lock didn't work on multiline comments. This gave all
> comments an ugly random
> colorization. I was very happy to discover this had been fixed in
> tuareg.
This has been fixed in caml-mode long ago too.
I think the main difference is that ocaml-mode is based on very old
code, developped originally for caml-light, and was it emacs 18 at
that time. It contained various hacks to make it faster, with some bad
side effects at times. Overall the bugs have been corrected, but this
is probably the case that at one point tuareg mode was more stable.
I'm not going to suggest that tuareg mode switch to the ocaml-mode
code base, because I think that actually the tuareg code is cleaner.
However, for various historical reasons the two code bases are
developped in parallel, with some reasonable amount of sharing, so
I see no real problem with the current situation.
Jacques Garrigue
Mehdi Dogguy
> I would be most interested to hear answers to this e-mail.
>
Me too. It would be nice if tuareg's upstream could summarize some points
to show the difference. That would help!
> I too have wondered about the differences between tuareg mode and caml
> mode.
>
I use only two features in tuareg-mode which are syntax coloring and
indentation (and from time to time, caml-show-types from caml-mode when
debugging). So my remarks (below) might not be complete but should be
enough (IMHO) for most of users to get an idea of the difference (for a
daily use):
- colors:
* caml-mode doesn't colorize mll files as good as tuareg-mode: open any
.mll file and look at any "rule foo bar = parse", it's all black. rules
are functions, so they should be colorized the same way.
* in caml-mode, functions and arguments have the same colors (when
defining functions).
* some operators are not colorized in caml-mode (e.g. "::"). I didn't
check all of them, only "::"… but that's enough for me to not use
caml-mode because, visually, "a::b" looks like a single block and
might be harder to read (or to detect the structure when the expression
if more complicated), which is not very nice.
* in tuareg-mode 2.0, "let" and "open" statements (and some others) are
bold and blue. I found that change quite surprising. It keeps my eyes
clipped on them. They contrast too much with the other colors used.
* in tuareg-mode 2.0, in mll files, rules are now harder to read because
it uses mainly red (for symbols, let's say) and light brown for strings
(as usual) and the contrast between these two colors is too low. It
used to be dark purple and light brown which is (not perfect, but at
least)a better default setting, IMHO.
* For mly files, they provide almost the same coloring.
- indentation: they simply have different defaults. caml-mode sticks to
the recommendations listed on ocaml's website, AFAIK, which is nice.
Indentation is configurable in both modes and is a matter of taste.
- other features (ocamldebug, toplevel, …): almost the same, but with
different names. Maybe there are some tiny differences here, but they
don't pop up.
It might obvious for some people but, apparently, maybe not for who set
the new default colors, but syntax coloring is used to show in a *clear*
way the structure of the code. From what I see, they both fail to provide
a good syntax coloring. tuareg-mode 1.xx used to have better defaults.
Some people might consider my remarks as nipticking, and I can understand
that (since I can change these settings). But, tuareg-mode used to have
good defaults and failing at such a basic features for such a program is
completely crazy. Besides, I appreciate the efforts done from both sides and
I hope that they'll get better soon.
Regards,
--
Mehdi Dogguy مهدي الدڤي
http://www.pps.jussieu.fr/~dogguy
_______________________________________________
Sam Steingold
> (skip-syntax-backward "\s-")
> Debugger entered--Lisp error: (error "Invalid modifier in string")
I see. Thanks.
I will fix this and make tuareg 2.0.1 available soon.
--
Sam Steingold <http://sds.podval.org>
_______________________________________________
Christophe TROESTLER
>
> * in tuareg-mode 2.0, "let" and "open" statements (and some others) are
> bold and blue. I found that change quite surprising. It keeps my eyes
> clipped on them. They contrast too much with the other colors used.
That is one thing I like with tuareg: you can change the colors
without affecting other modes. For your "problem", I have in
'tuareg-load-hook the following:
(face-spec-set 'tuareg-font-lock-governing-face
'((((class color) (type tty)) (:bold t))
(((class color) (background light)) (:foreground "black" :bold t))
(((class color) (background dark))
(:foreground "wheat" :bold t))))
> * in tuareg-mode 2.0, in mll files, rules are now harder to read because
> it uses mainly red (for symbols, let's say) and light brown for strings
> (as usual) and the contrast between these two colors is too low. It
> used to be dark purple and light brown which is (not perfect, but at
> least)a better default setting, IMHO.
I do not like operators to stand out that much, so I use:
(face-spec-set
'tuareg-font-lock-operator-face
'((((class color) (type tty)) (:foreground "white"))
(((class color) (background light)) (:foreground "DimGray"))
(((class color) (background dark)) (:foreground "Tan")))
)
You can play with colors that suit you too!
Another difference with indentation is that, e.g. "let", is electric
(it indents the line) and M-q reindent the entire expression (which
can really be handy).
Best,
C.
Mehdi Dogguy
> On Wed, 26 May 2010 15:33:13 +0200, Mehdi Dogguy wrote:
>>
>> * in tuareg-mode 2.0, "let" and "open" statements (and some others)
>> are bold and blue. I found that change quite surprising. It keeps my
>> eyes clipped on them. They contrast too much with the other colors
>> used.
>
> That is one thing I like with tuareg: you can change the colors without
> affecting other modes.
Well… thanks for this advice, but I know how to configure it :) My
"problem" are not the colors but rather the bad default colors (for the
reasons I've already mentioned).
Regards,
--
Mehdi Dogguy مهدي الدڤي
http://www.pps.jussieu.fr/~dogguy
Tel.: (+33).1.44.27.28.38
Christophe TROESTLER
Concerning the tuareg mode, the current default is to have "let
.. in" indented like
let v = e1 in
e2
instead of
let v = e1 in
e2
-- for which you have to use (setq tuareg-in-indent 0). We would like
not to bother people by changing the default but, on the other hand, I
have yet to meet somebody who finds it useful (in fact, it seems to
bother newcomers). So the request is
COULD PEOPLE WHO FIND THE DEFAULT USEFUL SPEAK UP NOW ?
In order not to clutter the list, you can use
https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=646&group_id=43&atid=258
to discuss this.
Thanks,
C.
Daniel Bünzli
>
> let v = e1 in
> e2
>
> instead of
>
> let v = e1 in
> e2
Why don't you simply make the default according to OCaml's programming
guidelines [1] ?
Best,
Daniel
[1] http://caml.inria.fr/resources/doc/guides/guidelines.en.html#id2269164
Christophe TROESTLER
>
> > Concerning the tuareg mode, the current default is to have "let
> > ... in" indented like
> >
> > �let v = e1 in
> > � �e2
> >
> > instead of
> >
> > �let v = e1 in
> > �e2
>
> Why don't you simply make the default according to OCaml's programming
> guidelines [1] ?
I am in favor of that (it was suggested by others too
https://forge.ocamlcore.org/tracker/?func=detail&atid=258&aid=646&group_id=43 )
but the question is whether some people would object to (or be upset
by) a change of defaults.
Cheers,
C.
Stefano Zacchiroli
> > Why don't you simply make the default according to OCaml's programming
> > guidelines [1] ?
>
> I am in favor of that (it was suggested by others too
> https://forge.ocamlcore.org/tracker/?func=detail&atid=258&aid=646&group_id=43 )
> but the question is whether some people would object to (or be upset
> by) a change of defaults.
I don't see any valid reason to oppose the official coding guidelines,
really. Guidelines exist exactly to uniform the implementation of OCaml
indentation in different tools; tools should use them as their
specification.
If the tuareg default is different, then it's buggy.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'� ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu � tous ceux que j'aime
Sam Steingold
Tuareg 2.0.1 is now available from
<https://forge.ocamlcore.org/frs/?group_id=43>.
The main difference is a skip-syntax bug fix.
The sources are also available via svn from
<https://forge.ocamlcore.org/scm/?group_id=43>.
--
Sam Steingold <http://sds.podval.org>
_______________________________________________
David Baelde
<Christophe.Tr...@umh.ac.be> wrote:
> �COULD PEOPLE WHO FIND THE DEFAULT USEFUL SPEAK UP NOW ?
I prefer the default:
let x = ... in
let y = ... in
foo
For what it's worth: I agree with the guidelines that two let-in are
like two assumptions and should be indented the same. But I like to
visualize the separation between the set of assumptions and what we do
with it. Another argument is that let-in creates a new scope, and
captures sequences of expressions. Visualizing it helps to understand
the structure of code. For example:
if blah then
let () = f () in
g () ;
h ()
is not the same as
if blah then
f () ;
g () ;
h ()
Cheers,
--
David
Eray Ozkural
> On Wed, May 26, 2010 at 4:31 PM, Christophe TROESTLER
> <Christophe.Tr...@umh.ac.be> wrote:
>> �COULD PEOPLE WHO FIND THE DEFAULT USEFUL SPEAK UP NOW ?
>
> I prefer the default:
>
> let x = ... in
> let y = ... in
> �foo
>
> For what it's worth: I agree with the guidelines that two let-in are
> like two assumptions and should be indented the same.
Seconded, I think it looks neat and it avoids too much nesting clutter.
Best,
--
Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct
Grant Rettke
> On Thu, May 27, 2010 at 12:46 PM, David Baelde <david....@gmail.com> wrote:
>> On Wed, May 26, 2010 at 4:31 PM, Christophe TROESTLER
>> <Christophe.Tr...@umh.ac.be> wrote:
>>> �COULD PEOPLE WHO FIND THE DEFAULT USEFUL SPEAK UP NOW ?
>>
>> I prefer the default:
>>
>> let x = ... in
>> let y = ... in
>> �foo
>>
>> For what it's worth: I agree with the guidelines that two let-in are
>> like two assumptions and should be indented the same.
>
> Seconded, I think it looks neat and it avoids too much nesting clutter.
Agreed.
Edgar Friendly
> For example:
>
> if blah then
> let () = f () in
> g () ;
> h ()
>
> is not the same as
>
> if blah then
> f () ;
> g () ;
> h ()
>
>
[if]/[then] syntax. Namely that semicolon-delimited chains of
expressions don't parse within the [then] or [else] sections without
extra bracketing. This lets adding a bit of debug code (in if/then -
exactly where it's usually needed) to totally break the semantics by
pushing code outside the if/then expression. With improper indentation
(like your second example), one can make it look like one thing is
happening while another will happen.
Your first code block is a good example of non indented [let] blocks
looking good. Your second example should be indented as follows to
clarify its actual structure:
if blah then
f () ;
g () ;
h ()
E
David Baelde
> Your first code block is a good example of non indented [let] blocks looking
> good. �Your second example should be indented as follows to clarify its
> actual structure:
>
> if blah then
> �f () ;
> g () ;
> h ()
Right, this was a bad example, and I can't think of a good one. Maybe
indentation can't help with that tricky syntax after all, and all I
can say is "I prefer the way it looks that way" (which is no surprise
since I've been learning OCaml under Tuareg).
Cheers,
--
David
Albert Cohen
With some delay, I would like to thank Sam and all Jane St Capital folks
for taking over the maintenance of Tuareg.
Happy hacking indeed!
Albert
On 05/24/2010 06:36 PM, Sam Steingold wrote:
> Hi,
> The original author of the alternative Emacs mode for editing Ocaml code
> (tuareg-mode), Albert Cohen, has stopped development some time ago.
> Now, with his blessing, Jane Street Capital took over maintenance of the
> code from him, and released Tuareg Mode v. 2.0.0.
> It is available for download at
> <http://www.janestreet.com/ocaml/tuareg.tgz>.
> It is still released under the GNU General Public License (GPL) v2.
> Please report bugs and submit patches to the dedicated public mailing
> list at
> <http://groups.google.com/group/tuareg-mode>.
> Happy hacking!
> Sam