I've done that too, and it's great, especially considering that the
authors of most of XWiki's templates seem to dislike whitespace (!).
However, the added step of moving them between there and my browser adds
another layer of work, though I could certainly use Eclipse's built-in.
The only place I routinely use it is when working on my server's
templates.
BTW, I know of two, and have installed both; which one were you using?
One of them at least allows you to declare elements of the Velocity
context, and that helps a lot, but for some reason it doesn't always
work - at minimum I have to go back and reset it often.
brain[sic]
-----Original Message-----
From: Esbach, Brandon [mailto:Esbachb@tycoelectronics.com]
Sent: Tuesday, October 24, 2006 11:24 AM
To: xwiki-users(a)objectweb.org
Subject: RE: [xwiki-users] More on editing
Actually, I stopped using the wiki edit features for coding
new wiki scripts/pages.. Lately I've been using Eclipse with
the VM plug-in, and have found it to be a fairly good editor:
even highlighting mistakes fairly well. You can even have
syntax-highlighting and code completion (to a lesser
capability) works with both velocity and html tags.
As to users editing documents.. This is one area perhaps that
would benefit from a bit more visibility certainly, though I
have a funny feeling that adding line numbers will be easier
than searching..
-----Original Message-----
From: THOMAS, BRIAN M (SBCSI) [mailto:bt0008@att.com]
Sent: 24 October 2006 17:11
To: xwiki-users(a)objectweb.org
Subject: [xwiki-users] More on editing
Another feature for editing which is sorely missed even by
users of non-WYSIWYG editors is the ability to search the
text of a textarea. When an XWiki document gets long, it's
really painful when testing out subtle changes or scripting
which requires me to keep previewing while editing, and going
back to the edit screen which has now reset the field to the top.
At the least, the ability to put line numbering in would be
useful. I'm planning to put up a bookmarklet to do that,
except that it may interfere with any onchange-triggerred scripting.
brain[sic]