How do YOU edit source on your MUD?

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).

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?

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).

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).

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

Quote:

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.

Quote:

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.

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.