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
> 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...
On 5/24/10, Stéphane Glondu <st...@glondu.net> wrote:
> 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.
On Mon, 2010-05-24 at 12:36 -0400, 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
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
I have long used the emacs tuareg mode (simply because when I asked 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 ?
Sam Steingold wrote: > 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.
On Tue, May 25, 2010 at 3:00 AM, Eliot Handelman <el...@colba.net> wrote: > Sam Steingold wrote:
>> 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.
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.
On Tue, 25 May 2010 20:08:33 +0200, Mehdi Dogguy wrote:
> 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>.
> 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.
>> 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.
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 "-").
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.
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 have long used the emacs tuareg mode (simply because when I asked > 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 ?
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.
> 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.
> 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.
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. For your "problem", I have in 'tuareg-load-hook the following:
> * 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:
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).
> 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).
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 ?
On Wed, May 26, 2010 at 06:01:39PM +0200, Christophe TROESTLER wrote: > > Why don't you simply make the default according to OCaml's programming > > guidelines [1] ?
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
