caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Török Edwin" <edwin+ml-ocaml@etorok.net>
To: caml-list@inria.fr
Subject: Re: AW: AW: [Caml-list] geany as an ocaml ide
Date: Thu, 14 Feb 2013 00:06:43 +0200	[thread overview]
Message-ID: <511C0E73.3040808@etorok.net> (raw)
In-Reply-To: <wf4nhfncc1.fsf@gmail.com>

On 02/13/2013 11:17 PM, Wojciech Meyer wrote:
> Gerd Stolpmann <info@gerd-stolpmann.de> writes:
> 
>> I can well imagine such a toolkit - basically an editor without user
>> interface. It would just consist of the underlying modules, and would
>> solve all difficult tasks - like incremental indentation, or
>> transparent network file access. Other developers can then pick things
>> up - only parts, or everything - and I'm sure we'll see then a couple
>> of GUIs on top of this, some expressive, some minimalistic, some
>> specializing on certain domains (web, GUI, etc.), some cloning emacs.
>> And, as you write, existing editors can be "upgraded" by providing
>> bindings.
> 
> I think the major point we raised here, that we all want the same from the
> editor: syntax highlighting, parsing in the background, invoking tools,
> editing over the network etc. However, each of us, have a completely
> different taste of how we interact with the editor and how we use the
> GUI.

Don't forget that the preferred "GUI" is sometimes just a console application.
I'm using vim to edit files in remote ssh sessions (unless latency makes it impractical), and even
on the desktop I much prefer the console version: mostly because its so easy to put it into the background, do some other tasks (building / debugging), then bring back the editor to fix things, and so
on. For some reason I also find it easier to switch between console tabs in Konsole than between multiple windows.

> For one person this might be Emacs which wins, other prefer
> Code::Blocks. What matters here is not to focus on GUI but the features
> that would be accessible from the different frontends. (which seem to be
> a little hard, given diversity of the solutions on the market, but
> perhaps possible)

I agree that the focus should be on functionality, if I see an IDE with features I like my first thought would be:
 "thats nice, now how do I make that work in Vim?".
If an OCaml library, or even just a command-line tool is provided that implements feature X independently of the full editor,
then its a matter of writing some editor-specific scripts to hook it up.

On the other hand care should be taken when advertising the editor for beginners:
 - if editor lacks feature X, then a beginner might generalize that to "Ocaml is the language without X"
 - will the editor be maintained with new ocaml releases?
 - once the beginner is ready to move to more advanced features, are they required to abandon the editor, or will it be customizable with plugins?
 - once the beginner is ready to move on to using <his favourite editor>, how can the features of the ocaml editor be accomplished there?

Also are we talking about complete beginners to programming, or beginners to OCaml that know other languages already?

I think that having an ocaml-specific editor with all the features people typically want from the IDE
would not necessarily be bad though, in the sense that it shows whats *possible* for an OCaml editor. And it'd be something people can easily try out.
For example Java has an IDE written in Java that people (at least those that I know) like a lot, unfortunately its not the open source one: IntelliJ Idea.
If something that has similar features and ease of use could be implemented in OCaml that'd be a good advertisement for the language itself too.
On the other hand integrating the new features with existing editors *first* would IMHO probably be better.

> 
>> Let's call this "editor" ModelOnly (following the common
>> model/view/controller abstraction).
> 
> Certainly one does not exclude the other option!
> 
> I just drew the border of the simple editor, and design requriments for
> the "ModelOnly".
> 
>> I completely agree that there are totally different requirements if you
>> compare the needs of beginners and professionals. However, this is
>> mostly a matter of presentation, and implementation-wise, there is a
>> lot of overlap, and also an editor for beginners would profit from a
>> good model library.
> 
> One could think about different incarnations of the same editor, did
> anybody think about Emacs, beginner mode, with CUA bindings and limited
> access to the functionality just so to make it easily accessible for the
> beginners?

From what I've seen at beginners in other languages they used: (on Linux) Kate,
Emacs (using the menus, not the shortcuts), mcedit, Code::Blocks, Eclipse/Netbeans; Dev-C++ and the various
Visual* stuff on Win32.

Out of those Kate seems to be the easiest to just start using, as it has a terminal too (and it supports plugins/extensions),
but I don't know if / how well it'd work on Win32.
Unfortunately it is the first time I've heard of Geany, haven't seen anyone use it.

Best regards,
--Edwin

  reply	other threads:[~2013-02-13 22:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-11  0:49 Martin DeMello
2013-02-11  1:37 ` Ashish Agarwal
2013-02-11 11:40 ` Louis Gesbert
2013-02-11 12:14   ` Gabriel Scherer
2013-02-11 12:47     ` Fabrice Le Fessant
2013-02-11 12:58       ` Gabriel Scherer
2013-02-11 13:34         ` Fabrice Le Fessant
2013-02-11 13:12     ` Daniel Bünzli
2013-02-11 23:24   ` Martin DeMello
2013-02-12 11:29     ` Louis Gesbert
2013-02-13 14:12       ` AW: " Gerd Stolpmann
2013-02-13 15:41         ` Wojciech Meyer
2013-02-13 17:09           ` AW: " Gerd Stolpmann
2013-02-13 21:17             ` Wojciech Meyer
2013-02-13 22:06               ` Török Edwin [this message]
2013-02-13 23:30                 ` Wojciech Meyer
2013-02-13 23:44               ` Jon Harrop
2013-02-13 20:49           ` Martin DeMello
2013-02-13 16:30   ` Jon Harrop

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=511C0E73.3040808@etorok.net \
    --to=edwin+ml-ocaml@etorok.net \
    --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).