On Sat, May 19, 2012 at 09:43:13PM +0200, David Nadlinger wrote:
> On Saturday, 19 May 2012 at 19:28:44 UTC, Paulo Pinto wrote:
> >I like UNIX and the command line is invaluable for certain tasks regardless of the operating system, but sometimes I wonder if people realized that it is no longer 1970 and better ways to develop software do exist.
> 
> …especially because it would be perfectly possible to provide a command-line interface to »intelligent« (i.e. frontend-backed) refactoring tools as well.
[...]

+1. I think the ideal development environment would be one where there are reusable parsers and syntax-tree rewriters (either standalone programs or libraries with generic API), that can be used to do semantic-level text manipulations, which can then be used with basic text-editing functions.

I envision something like this (using vim as an example, substitute your favorite editor at will): have a bunch of language-specific plugins, like xml, c, c++, d, etc., for basic syntax-tree level navigation through source code, bound to a bunch of designated syntax-tree navigation keys in the editor, plus a bunch of language-specific operations (like rename identifiers, move nested function in/out of nesting, etc.) bound to some kind of command interface, which can be aliased to unused command keys. These plugins can be applied to arbitrary blocks of text -- usually an entire buffer, but possibly to sections within a buffer, such as D code embedded in an email, or XML embedded in a heredoc, etc..

The plugins autodetect the environment they're in, much like vim already does nowadays to a limited extent, but you can also bind specific plugins to sections of text at will.

Now you have an environment that lets you work on all kinds of files in all kinds of formats, with basic text editing capability common to all of them, plus semantic actions for language-specific operations.

Best of all, these plugins have a common, generic API, that can be reused by _anything_. Imagine if you can, for example, grep for stuff in a large source tree and have grep automatically detect the language of a particular file so that it can use a plugin for locating stuff at specified places in a syntax tree. You'd then be able to do really handy stuff like "find this regex in the body of for loops that are nested inside a top-level function", or "enumerate all occurrences of if-statements nested at least 3 levels deep".


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG