[Razan]

So this issue came up recently with some of our immortals looking for better ways to edit code. We run a highly customized LPC MUD where basically you 'ed' files then load them and clone them. Some of us (myself included) using Linux/*nix/Mac (BSD) have been using Tinyfugue w/ some macros to download our files by copying them to a public web address, shelling out and 'wget'ting the file locally, then throwing up 'vi' on it to edit the source. It works great, but kind of requires you have a command prompt and text editor of that sort. Furthermore, not all of our wizards are Unix people and I'd prefer not to be an OS bigot to them.

So how are you guys editing your source? I can't imagine going back to editing using 'ed' and it's painful to watch some of our wizards do it. I'd prefer ideas for ways you address this that don't involve a custom client your MUD uses (while I'm envious of how cool that might be, it's not particularly portable).

Thoughts?

- Razan d'Tsunami (Tsunami - Home)

[Ide]

Originally Posted by Razan So how are you guys editing your source?

Well it depends on their client obviously, but most Windows users could use a client with a /quote in command, then just cut and paste the file to their text editor, make changes, and /quote in the result, right? Or are you talking about something more complicated?

[Magstant]

Originally Posted by Razan So this issue came up recently with some of our immortals looking for better ways to edit code. We run a highly customized LPC MUD where basically you 'ed' files then load them and clone them. Some of us (myself included) using Linux/*nix/Mac (BSD) have been using Tinyfugue w/ some macros to download our files by copying them to a public web address, shelling out and 'wget'ting the file locally, then throwing up 'vi' on it to edit the source. It works great, but kind of requires you have a command prompt and text editor of that sort. Furthermore, not all of our wizards are Unix people and I'd prefer not to be an OS bigot to them. So how are you guys editing your source? I can't imagine going back to editing using 'ed' and it's painful to watch some of our wizards do it. I'd prefer ideas for ways you address this that don't involve a custom client your MUD uses (while I'm envious of how cool that might be, it's not particularly portable). Thoughts? - Razan d'Tsunami (Tsunami - Home)

I use to pwn with zmud 5, where you could only do 1 line at a time .


ed workroom.c

50 lines, 1 ata time

but zmud 7 is awesome, 70 lines at once = easy, BUt razans way just confused the living **** out of me xD

(Y) Razan

-Magstant


ps. if you couldn't tell we both play the same mud !

[Mabus]

I have the exact same code on my home server as the game server.

At home I write the code usually in an IDE, or with a simple editor like ConText if it is a small change. I then use Ant to compile. I do any needed (major) testing before I take it from there.

I then Putty into the server, and depending on file size I either FTP the code in, or open a pico -w and copy/paste from my home file. Small code changes on the server are also usually done with pico. I also use Ant as a compiler on the game server (not just at home).

Life is easy.

[The_Fury]

I have AndLinux installed within XP and do all my coding locally using Kdevelop for the IDE. So from within the one program i have access to Konsole and Subversion which i use for source control. Server side i use a bunch of scripts and cron jobs that take care of daily backups, source updates from SVN, recompilation of the server and just about everything else, so much so that its been months since i have had to shell into the server to do anything.

I guess work flow might be different for the OP and anyone using LP or simular, but for the rest of us who have to compile then run, the above set up works very well. For me anyway. LOL

Something the OP might like to look at is BVRDE - Remote Compile and Debug IDE bvrde is a c and c++ windows ide with ftp and ssh capabilities buit in, so from within the one program you can directly download the file/s you want to work on, edit them in a nice environment and then click save to have them saved back to the server.

I keep bvrde on a pen drive and take it anywhere i go, so i can always do some work on code no matter where i am, its a neat program and free.

[Threshold]

Cool topic.

For many years, I would write all of my code in notepad and paste it into Threshold through ed. That worked pretty well for a long time. I'd boot up my PC, open 4-8 instances of notepad, tile them, and go to work.

5 or 6 years ago, I started using UltraEdit and that made things a little better.

But about 2 years ago I started using WinSCP to download/upload all my files through ssh directly to the machine. This is even better, faster, and in a lot of ways more convenient. Every few days or so I completely overwrite my "workspace" file-for-file copy of the mudlib to make sure I have any changes made by any other developers.

[Markov_AU]

I've used multiple methods myself, form KDevelope, nano, nad if I was on my windows PC editing something source wise I tend to use TeraText Editor

[Zivilyn]

Sometimes I'll use pico or nano in shell, but usually I use BBEdit (OSX, OS 9 when I had that). It has an FTP window and will open/save to the file on the server. This works great with ONE coder going at a time, but in the past I've had 'hey, you editing something_source.c?' moments.

Absolutely love the newest BBEdit though, it has foldable code (so I can close between braces to see functions/checks easier), I can fold any 'if' check or switch/for/while etc statement so I just see the if (somecheck){<>}, it might be 300 lines between but I can fold it. Also, line numbering on the side lets me know where I'm at, and shows line number ranges in folded code. That, and the grep function is awesome in BBEdit.

[Lasher]

I've tried every IDE, editor and development tool I can find.

For pure efficiency, nothing still beats vi+cscope for me. There's a steep learning curve with some of the obscure key combinations, but once you have it down it is excellent.

[Kylotan]

I have a local copy of the (Diku, not LPC) code on my home PC. For small changes, I make them in TextPad/EditPlus/whatever, and FTP them up. Many text editors come with FTP built in, so that works well. For bigger changes, I boot into my Linux partition, edit in Kate, and test that it builds (with SCons) and runs locally. Having a local build and execution environment speeds up turnaround significantly when the change is not trivial enough to be guaranteed to work first time.

I find I need 2 things - to have a local copy of everything so that Find In Files executes quickly, and to have some sort of windowed multi-file text editor. Life's too short to spend memorising Vi keypresses.

[Markov_AU]

Originally Posted by Kylotan I have a local copy of the (Diku, not LPC) code on my home PC. For small changes, I make them in TextPad/EditPlus/whatever, and FTP them up. Many text editors come with FTP built in, so that works well. For bigger changes, I boot into my Linux partition, edit in Kate, and test that it builds (with SCons) and runs locally. Having a local build and execution environment speeds up turnaround significantly when the change is not trivial enough to be guaranteed to work first time. I find I need 2 things - to have a local copy of everything so that Find In Files executes quickly, and to have some sort of windowed multi-file text editor. Life's too short to spend memorising Vi keypresses.

Kdevelop I believe uses Kate as the text editor in it.

[The_Fury]

Originally Posted by Markov_AU Kdevelop I believe uses Kate as the text editor in it.

You know, i would have thought that it used Kwrite, in keeping with the K theme, but after a little searching on the matter it turns out that it does infact use Kate. Something that i did no know was that Kate stands for, KDE Advanced Text Editor. Thanks for the education. LOL

[Kylotan]

I think I have stayed away from KDevelop since it used to be quite unstable, and didn't work well with SCons-based projects. Maybe that's changed now though.

[Baram]

CVS and whatever editor/method they want to use. I personally use EditPlus2, which is an IDE for windows but works better on Linux under wine.

[chaosprime]

vi on the server for me. (I cannot fathom accepting the tradeoff of easy-to-use-at-first for less-power-when-expert. What, do you plan on only coding for a month or two of your life?)

My developers have FTP access to their workspace directories, so they use whatever they like, though of course editors with FTP integration have an edge. Crimson and nano appear to be popular choices.

[Kylotan]

Originally Posted by chaosprime vi on the server for me. (I cannot fathom accepting the tradeoff of easy-to-use-at-first for less-power-when-expert. What, do you plan on only coding for a month or two of your life?)

More like 20 years :P But generally speaking it's far more productive to work with tools that don't require massive memorisation. I'll save that for areas that actually need it. Let's not pretend that these editors are cryptic because that way is somehow better; they're necessarily cryptic because of restrictions on the interface when they were created.

[Lasher]

Originally Posted by Kylotan More like 20 years :P But generally speaking it's far more productive to work with tools that don't require massive memorisation. I'll save that for areas that actually need it. Let's not pretend that these editors are cryptic because that way is somehow better; they're necessarily cryptic because of restrictions on the interface when they were created.

Once you know them you know them, I don't feel like they "use up memory space" that should be saved for something else.

Another benefit of using VI+cscope (and for me it's the cscope part that really makes the difference) of course is that no matter where I login from, anywhere I can get an SSH connection all my tools are right there on the server. Some people may never need this, but for me it is invaluable.

I've even coded on a blackberry using midpssh to get back to the server. Although, I do have to admit, on a blackberry getting some of those key combinations in can be considered about the same as trying to juggle 18 onions while doing a handstand.

[chaosprime]

Originally Posted by Kylotan More like 20 years :P But generally speaking it's far more productive to work with tools that don't require massive memorisation. I'll save that for areas that actually need it. Let's not pretend that these editors are cryptic because that way is somehow better; they're necessarily cryptic because of restrictions on the interface when they were created.

To some extent that's true of line editors. In vi's case, it's stayed cryptic because yes, that way is somehow better. That way is, precisely, that a friendly interface that's clear and helpful for newbies gets in the way of experts, slows them down and hobbles them. Because vi stuck with cryptic, I can reindent a paragraph of code with three keystrokes and no mouse movement (don't get me started on how crippling an input device the mouse is), I can perform operations like pattern-based column transposition that people using pretty, friendly editors can hardly dream of, and I can combine all kinds of operations in the ways that I need rather than the ways that some dialog box designer thought would best serve 95% of his market.

People who use pretty IDEs seem to think vi users are somehow kidding or deluded when we say that we use it because it's more powerful than other editors when you know it. But I'm afraid we're both entirely serious and speaking directly from substantial experience.

[Kylotan]

Originally Posted by Lasher Once you know them you know them, I don't feel like they "use up memory space" that should be saved for something else.

But the same could be said for learning Esperanto. I spent plenty of time learning vi keystrokes at my last job, and ultimately you're just memorising things that other editors have on menus.

Originally Posted by chaosprime Because vi stuck with cryptic, I can reindent a paragraph of code with three keystrokes and no mouse movement (don't get me started on how crippling an input device the mouse is)

A common mistake that vi and emacs fans make is to think that someone who uses a windowed editor is mouse-reliant. I can reindent a paragraph of code with three or four keystrokes in most of my Windows-based editors too.

When used appropriately, the mouse is more efficient than the keyboard. And vice-versa. The difference is that in one situation, you have that choice, in another situation, you don't.

I can perform operations like pattern-based column transposition that people using pretty, friendly editors can hardly dream of, and I can combine all kinds of operations in the ways that I need rather than the ways that some dialog box designer thought would best serve 95% of his market.

I don't doubt there's some cases which you find a lot more efficient, but all the examples I ever hear are of convoluted things that I need to do no more than once every 6 months in the usual course of coding. Quite often the people using the 'friendly' editors don't dream of these operations because they never found themselves performing them. I seriously doubt that the time spent learning these things in the first place is worth the investment for most people.

[chaosprime]

Originally Posted by Kylotan I seriously doubt that the time spent learning these things in the first place is worth the investment for most people.

I imagine that's true. I don't consider myself or any other ambitious coder to be "most people".

Really, in the final analysis, much of my position is a matter of how intimidated my IDE-using colleagues are when they have occasion to see me working in vi. I suppose that could be me as much as vi. But I tend to believe that vi has a bit to do with it.

[Ide]

Originally Posted by chaosprime I imagine that's true. I don't consider myself or any other ambitious coder to be "most people". Really, in the final analysis, much of my position is a matter of how intimidated my IDE-using colleagues are when they have occasion to see me working in vi. I suppose that could be me as much as vi. But I tend to believe that vi has a bit to do with it.

My main experience has been with vim, but my day-to-day editor is SciTE. I just don't use editors that much to warrant a 'real' IDE or a 'real' screen editor, but from even my limited experience with vim I have to say that a key-combo editor is superior to a mouse-based editor, or even using keystroke commands to access menus, because typically your menu options are far more limited than the options of a keystroke-based editor. Keeping your hands on the home position is just more efficient in my experience. That said, if you use a trackpoint for a mouse like I do you get the best of both worlds. ;D

[Anasadi]

Razan,

Your question can mean a lot of things for our MUD. If you refer to editors, the immortals use anything that can save a file to a UNIX text format, e.g. emacs. I use BBEdit currently. I've also used vim, pico, nano, JEdit and UltraEdit.

If you refer to the location of the code, we use an SVN repository, and for years before that CVS. Certain immortals have the code checked out locally, updating and checking in changes when needed. The production code is compiled on the server itself and svn'd there.

If you refer to the code itself, we use both Java and Scheme (a flavor of Lisp). We update the Java code, compile and test it out locally, then compile it on the server right before a reboot. We do the Scheme code the same way, except we can update it live on the MUD, no reboot required. This sorta drives our playerbase crazy, as we sometimes go for months at a time without a reboot. We also can update our areas (and mobprogs/scripts) live, but we refrain from it generally and wait for reboots to do this.

We also have been playing around with Groovy. We haven't done too much with it, however, but our mud is fully Groovy-enabled.

I hope this helps.

Anasadi

[chaosprime]

Anasadi, if I could interest you in giving a quick summary of the ups and downs of switching from CVS to SVN as a MUD developer, I'd be interested.

[Kylotan]

Anybody use any other form of source control? I use Mercurial locally, but haven't looked into whether I could use it on my shared host. We use CVS at work and that can get quite painful when several people are trying to maintain different combinations of changes independently.

[Ide]

Maybe someone could explain the differences between distributed RCSs (I think Mercurial is one of those) and systems meant to be centralized like SVN and CVS. Not that you can't work in a distributed manner with SVN but I don't think that is the main intent. I've also been experimenting with Bazaar, another distributed RCS. From what I've read Bazaar and Mercurial have some similarities.

[Kylotan]

The main difference with something like Mercurial is that everybody's checking in to their own local repositories and then sharing changes as needed, rather than everybody checking in to one place. You can check in and roll back locally without affecting anybody else. You can also be more selective about what and when you check things in, such as stopping half way through your big combat system revamp which you commit locally, making some unrelated bug fixes, and then trivially submitting a changeset of only those bug fixes to the central repository, even if they're in the same files as the ones you're changing for the combat system. Or you can easily send those bug fixes to someone else to merge into their local repository to test for compatibility with their new skills and spells etc, without needing to commit to the main source repository first. If you want a distinct 'branch', you clone a repository locally, and that's that.

I think some people might not like the idea that there isn't one single authoritative repository with clear versions and so on, but it's easy enough to designate one repository as having that role if you need. Generally I find that Mercurial just feels both simpler and more advanced than the centralised systems I've used.

[Anasadi]

Chaosprime,

There's not much to describe. If a person knows CVS, they already know a great deal about SVN. Command-wise. Here's some brief examples -

CVS / SVN
---------------------------------
cvs checkout / svn checkout
cvs add foo.txt / svn add foo.txt
cvs update / svn update
cvs commit / svn commit
...

There weren't really downs to switching to svn, unless you count the upgrades to the OS and Apache, which should be done regularly anyway. It was merely a matter of allotting time.

On the other hand, with svn, we can now open up portions of our repository to the web (we may have been able to publish portions with cvs, I don't know, we didn't use that bit), create individualized checkouts for immortals, have the diffs between files mailed to us directly, and more. I believe we can do file locking, so no more than one person is working on a file at a time, but we haven't used it, and if two of us do happen to work on the same file and commit it without updating, svn will merge the changes (letting you know where these take place). Renaming and moving files in SVN is a bit easier than doing it in CVS. SVN also seems a little faster than CVS, but that's my experience, your mileage may vary.

I'm not saying CVS is bad - it isn't. Just SVN provides us more options. If I were given the choice, I would go with SVN.

Anasadi

[Spoke]

In my opinion vi is the way to go. The advantage is portability because you basically have to carry nothing around. Everything remains in the server making things much easier, you have a single configuration that you like and use it from wherever you log in. The fact that is text based makes is a practical choice even in places where you have a poor internet connection. There are a few graphical interfaces for vi too, so it does not mean that the two things are mutually exclusive, but as a rule of thumb, if you have a key-stroke to perform an action that you need to repeat often, it is usually more efficient than using a mouse, plus, the requirement of a pointing device for anything is a hassle when you are dealing with mobile devices (you may also navigate vi's help and menus with a mouse if you so configure it by the way).

Though a bit off-topic, this is the same reason I stopped using zMud and other windows based mud clients. It was horrible to have to depend on being able to run or install a piece of software wherever I went and having to carry around my character files, and then having to update them as I got home so I knew I had the latest version up etc etc. Now when I play, I just keep a copy of tintin running in my linux box, connect to it through ssh and voila, everything is there, and once again, because it is only text, you can make it work wherever you are.

With respect to whomever mentioned 'I can do the key-typing too' in Menu based editors, well, if you know a key-stroke sequence for performing such tasks then I do not understand your objection to vi ("I spent plenty of time learning vi keystrokes at my last job, and ultimately you're just memorizing things that other editors have on menus.") since you are doing it with your Menu based editor anyway.

Lastly, I believe the choice of editor goes along with the mental disposition of the user. Some people feel more comfortable with Menus and a friendly graphical atmosphere and are thus more efficient working in such an environment. Other people may thrive in environments where they have more control on the subtleties of editing and being able to do arbitrary thing, and so they devote more time to learning to just do so and work effectively in this kind of environment. For me, as a physics student the clearest way to explain it is comparing typing papers in LaTeX vs typing them in MS Word. Yes, you can get everything to look the way you want in MS Word, eventually, and you can have a publish-worthy paper typed and formatted on MS Word, but once you learn the tricks and commands on LaTeX (not entirely intuitive) you realize that finishing a publication worthy paper with tons of equations and graphs on it takes about 1/5 th of the time in LaTeX.

Anyway </2 Cents>

[Kylotan]

Originally Posted by Spoke With respect to whomever mentioned 'I can do the key-typing too' in Menu based editors, well, if you know a key-stroke sequence for performing such tasks then I do not understand your objection to vi ("I spent plenty of time learning vi keystrokes at my last job, and ultimately you're just memorizing things that other editors have on menus.") since you are doing it with your Menu based editor anyway.

That was me. And the difference is that with the menu it is easier to find the information for first and subsequent uses until memorisation takes place, and that the search for that information is prompted at every step. For regularly-used commands, there's no benefit. But for less regularly used commands, they're easier to find within a hierarchical menu system, and for obscure commands you rarely use and will probably never memorise, a dialog based approach reduces the chance of error by providing context-specific feedback. The idea of providing context-specific cues and feedback is key to making an interface more usable and is the main advantage that most windowed environments have over the command-line.

[Orrin]

I use WinSCP to connect to the server and then edit the source files locally using notepad2. I've used more complicated setups in the past, but I find that this works well enough for what I want.