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
next prev parent 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