What's your favorite IDE/text editor when it comes to programming? Also, what's the setup in the banner up top? http://static.4-ch.net/images/boardtitles/programming.gif, that is.
vi
Emacs
leo
another vote for vim.
vim
Evergreen or Cream
The thing up top may be TextMate. I haven't used it.
ed
vim
VI baby. Download it for windows or unix.
vim
Visual Studio, please.
kate
I use eclipse on windows, and vi on bsd. I find that I can get more work done in eclipse, so that's what I prefer.
nvi. vim is worse than emacs.
vim boots slower than emacs and does less. I don't see the point of it at all.
emacs for lisp, irc, and email. vi for editing text files.
Scintilla / Scite. I like my lightweight editor with good syntax editing. I shouldn't have to "wait" any time for a IDE to load.
Nano if im just making a small change in the shell =)
But then again, real programmers tap out their code to their hard drive manually with a ball point pen!
Elvis!
If you break into the command line on an OLPC, there's a copy of vim inside, aliased as vi because someone thought they were being clever. I've been learning to use it and like what I see.
Notepad, Dreamweaver
>>21
the difference that bothers me the most is that vim is slow enough that i actually notice it.
Banner definitely looks like Textmate, which I use and recommend.
Can't see any good reason to use clunky editors that barely changed since the 70's and are a pain to integrate with all my desktop tools.
emacs for coding
ultraedit / notepad++ for quick and dirty text editing
vi on remote server (coz it's a pain to use emacs without my .emacs)
emacs, vim, textmate
and textpad of course
copy con
coda
I seriously don't understand why people continue to say stupid shit like vi, elvis, and nvi.
vi was made in the 70's for unix. it hardly does anything. if you aren't running a propriety version of unix, or perhaps solaris now that it's free, then you're not using vi. Linux simply links the vi name to vim, and *bsd links vi to nvi. So everytime you type 'vi' you're running vim or nvi. nvi hasn't been maintained in years and i doubt freebsd even uses it, they probably just use vim now. elvis isn't maintained anymore either, and hasn't been forever. talking about those ancient editors if fucking ridiculous unless you working from some remote terminal, but is the OP really asking about that?
and idiots saying vim is slower than emacs, or noticing that it is slow at all is complete bullshit. this might be true if you're running gvim on some ancient computer, but nobodys mentioned gvim, we're talking about vim.
vim
> vi was made in the 70's for unix. it hardly does anything. if you aren't running a propriety version of unix, or perhaps solaris now that it's free, then you're not using vi.
it does a lot more than emacs.
$ emacs
emacs: Command not found.solaris uses it's own vi:
http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&sektion=0&manpath=SunOS+5.10&format=html
HP-UX does too:
http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&sektion=0&manpath=HP-UX+11.22&format=html
OS X uses vim:
http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/vi.1.html
apparently they somehow managed to get OS X certified UNIX 03, despite vim not being fully POSIX compliant:
http://www.opengroup.org/onlinepubs/009695399/utilities/vi.html
http://www.polarhome.com/vim/manual/v71/vi_diff.html
Vim is mostly POSIX 1003.2-1 compliant. The only command known to be missing
is ":open". There are probably a lot of small differences (either because Vim
is missing something or because Posix is beside the mark).> nvi hasn't been maintained in years and i doubt freebsd even uses it, they probably just use vim now.
the latest version is from less than 7 months ago:
http://www.kotnet.org/~skimo/nvi/devel/
[ ] nvi-1.81.6.tar.bz2 18-Nov-2007 18:02 1.7M
[ ] nvi-1.81.6.tar.gz 18-Nov-2007 17:57 2.2Mfreebsd uses nvi:
http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html
netbsd uses nvi:
http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&sektion=0&manpath=NetBSD+4.0&format=html
openbsd uses nvi:
http://www.freebsd.org/cgi/man.cgi?query=vi&apropos=0&sektion=0&manpath=OpenBSD+4.3&format=html
> and idiots saying vim is slower than emacs, or noticing that it is slow at all is complete bullshit.
$ /usr/bin/time -h nvi -c :q TWL06.txt > /dev/null
0.49s real 0.40s user 0.06s sys
$ /usr/bin/time -h elvis -c :q TWL06.txt > /dev/null
Read TWL06.txt, 178690 lines, 1763166 chars
0.26s real 0.08s user 0.15s sys
$ /usr/bin/time -h vim -c :q TWL06.txt > /dev/null
Vim: Warning: Output is not to a terminal
2.33s real 0.22s user 0.04s sysWell, to be different, I guess I'll be honest and say I use gEdit for typical stuff, bluefish for perl/php/xhtml, and eric3 for python. The only time I use vim is when I set up the sudoers file, and I suppose I use nano to some extent when I'm running as root from the shell and can't be bothered to start something graphical.
nano is dangerous because it breaks lines in an effort to be helpful. Make sure you have set nowrap in your ~/.nanorc file or use nano -w to avoid breaking important files.
This is especially important when running as root.
I've been using Eclipse on my desktop, and it works wonders for a language like Java (and is still pretty useful for Python), but it lags like hell on my low-end laptop; until now I've been using Komodo editor for my Python code because of its syntax checks and popups for functions, but it's really lacking in any ability to run and test code and previously stated features seem to only work selectively.
Is it possible to get these features into emacs or a vi derivation? From what I've used of emacs, it only really has auto-indentation (which is mostly useless in python) and coloration of code. Moreover, do any of them have useful debugger features like in Eclipse?
>>41
yes they do. both of them. (vim & emacs)
I use E Text Editor. It's supposedly modeled after Textmate which I've never used since I am on Windows, but it's pretty easy to use and I don't really need anything more or less.
nvi
Sometimes I wish there were an X server+window manager that rendered into emacs frames...
>>45
You mean like basically all tiling WMs?
>>9
+1 for ed. I really hate having to move a cursor around.
Real programmers don't use arrow keys, including "hjkl".
ConTEXT
>>43
At least you won't realize how badly they butchered it. Can't stand E as a Textmate user.
vim
vim
my .vimrc
syntax enable
set autoindent
filetype plugin indent on
set nowrap
nnoremap <silent> <F8> :tabnext<CR>
nnoremap <silent> <F7> :tabprevious<CR>
>>51
learn to use buffers instead of tabs you idiot.
Move out of the eighties.
inType
I use the Hessling Editor, and also sometimes XED.
Nib pen and paper.
vim
VIM
colorForth
vigor
vi
>>49
What about InType? It's only in early alpha stage tought...
So I went there, and got to:
Intype is a powerful and intuitive code editor for Windowsand stopped treating it seriously.
Is this some kind of personal problem or what?
vim or vi
wats VIM??
Wow, it's nice to see all the VIM users out there.
VIM
always used VIM as long as I have been testing, using and trying out non-win systems. I have used linux and BSD for a couple of years now, and vi(m) has almost always been preinstalled or available as a package.
I also used emacs for a while, but found the vi-way to be easier to me =)
But I'm still wondering if I wouldn't be better served with a good and mature IDE for developing though =/
I usually use THE or Xed, but I'm learning TECO.
I use VIM to develop my Verilog modules, then synthesize and simulate them in Xilinx ISE. My favorite feature of VIM is that it colors differently the important parts of any language you type in there, be it C or verilog or HTML or ASP or anything else I've used for it.
>>64
Actually, yes, and don't mind it. He has issues.
Of course the users here are too cool (read: unknowledgeable) to admit that Visual Studio is the best IDE.
I became a little envious watching a co-worker of mine show of Visual Studio's SQL tool or whatever you want to call it. Beats my Emacs sql-mode.
All that functionality is availble as a stand-alone app whoes name I can't think of at the moment. It is better than doing SQL in emacs and it is better than MySQL's query browser, But I wouldn't say that would be a the showcase item for me. Although I do love the fact it does integrate some great features like this in to the IDE.
The whole process is incredebly refined. Triple comment code meta data is fucking fantastic. (you enter 3 comment delimiters in a row immediatly preceding a procedure signature and it automatically creates the XML to enter in detailed comment metadata.)
It always stays ahead of the curve on code completion with intellesense.
VB.Net's constant precompliation makes finding many errors in code trivial as they are displaye dbefore compile. (Strangley C# doesn't do this though).
The built in web server makes quick tests trivial as well.
Then there is all the team, testing and other shit built in.
The whole process is incredebly refined. Triple comment code meta data is fucking fantastic. (you enter 3 comment delimiters in a row immediatly preceding a procedure signature and it automatically creates the XML to enter in detailed comment metadata.)
Board title image is TextWrangler, with the "title" commend inbetween some random opensource code.
CODE::BLOCKS
I have read some stupid shit on here but that is the absolute stupides in quite a while.
XML is perfect for creating a markeup to markup comments in every way. To think otherwise means you really don't understand anything about this topic.
>>80
XML is barely human readable. The only purpose this sort of thing serves is to make code even harder to maintain because now the comments are illegible too.
Structured comments solve a non-problem; Extracting useful documentation directly from the source code is useless if there isn't any useful documentation directly in the source code.
There are a large number of nearly empty javadoc and doxygens published on the Internet. Worthless documentation isn't better than no-documentation. At least with the latter it's harder to delude yourself into thinking you've got something. That means autodocumentation tools are simply making things worse.
Good documentation, means prose, not property lists on program definitions. XML simply doesn't enter into it.
Oh wow. More stupididty.
You arguement is meaningless. XML markup of comments has nothing to do with the quality of those comments.
Bad comments are bad. Good comments are good. Good comments with meaningful markup are better.
Comments don't suddenly become bad when you add extra meaningful information to them that identifies exactly what the comment is for.
If you can't see why the ability to have a standard meaningful way to document a function paramter is a good thing, you need to stop "programming." If your comments aren't good enough to provide even basic useful documnetation, then you suck at commenting.
In summary, just because you are bad at something or don't fully understand it, does not make that thing worthless.
Hay guyz,
if you can't present an argument without juvenile ad hominem jabs (<-), please go the back to 4chan.
That is all.
Structured comments make it easier to automatically extract information from comments; it does not make it easier to add information.
Comments are so limited, you cannot put meaningful documentation inside them, and by enforcing a rigid structure you are encouraging poor documentation, and making it impossible to write good documentation.
Generally speaking, I find that if a function parameter isn't apparent from the code or its name (prototype, minidoc, etc), then the API is probably stupid and was written by an idiot. I have never seen those situations saved by documentation.
>>83
It's very possible to add that ``meaningful'' information without adding the clutter XML does. This isn't mainly about structured comments (though >>85 is right about those), it's specifically about using XML to do it.
As far as attempts at literate programming go, XML is a failure because it makes the source code messier and harder to read.
Visual Studio makes the XML trivial as it adds it for you, you only need to provide the content.
Comments are only limited by a persons ability to accurately describe the code. Its apparent that you have not used a mature API extensively. Take something like the .Net APIs. The Visual Studio object explorer displays the XML comments for the APIs (and any other well commented code you are using). This tool is invaluable as is intelligence which also gets its info from the XML comments.
Parameter names should be self evident, but they can't always be. If a function takes a path to a file name, and it has to be a fully qualified path do you name it "strPathName"? That doesn't tell you shit about it. Its obviously for a path, but is it a relative path or a fully qualified one or doesn't it matter? What if there are overloads that take other paths, do you have to get super descriptive? Do you name it "strFullyQualifiedPathNameToTheFileYouWantToWorkWith"? Or maybe I should just memorize the API's full documentation, that sure is reasonable.
Or would it work better if you name it "PathName" and a little tool-tip came up when you got to the point to enter the parameter in the IDE and it read "String: Fully qualified path to the file to work with." Think about that for a while.
/// <summary>
/// Summary of LoadXMLFromFile.
/// </summary>
/// <param name="FilePath">Description of FilePath parameter.</param>
public void LoadXMLFromFile(string FilePath)
That is a basic C# XML comment (that is autogenerated with me adding the text between the tags). If you find that hard to read or pushing the comment delimited 3 times to auto-gen the XML to hard to do, you might want to choose a different hobby.
Any good developer today should be able to view XML and understand it. But since you don't, I suppose you have a better idea for a markup language to use to give context and meaning to programming comments. You can't be a true badass programmer until you have dismissed, without a reason, the ideas that teams of computer scientists and computer engineers have put way more thought in to that you have.
> Visual Studio makes the XML trivial as it adds it for you, you only need to provide the content.
I didn't disagree with that. I said the hard part is adding the content- something that automatic documentation has made harder by removing incentive, not easier.
> Parameter names should be self evident, but they can't always be.
Prove it, cock for brains.
> If a function takes a path to a file name, and it has to be a fully qualified path do you name it "strPathName"?
Straw man. Don't make an API that requires a fully qualified path, duh.
I'm still waiting... Maybe you can try an argument that doesn't depend on such a weak strawman next time.
> Any good developer today should be able to view XML and understand it.
Why set the bar so low?
Good developers can eat XML and shit strawberries!
Wow, I am seriously seeing a pattern develop here. You really have a hard time understanding these simple concepts.
>something that automatic documentation has made harder by removing incentive, not easier
Yes, automating a task will remove incentive to do that task. Brilliant! And this whole time automation is used as incentive to do some task, but you have turned that whole idea on its head with your brilliance.
>Prove it, cock for brains.
Did, you didn't understand.
You claim straw man argument, but fail to even prove you used the correct word there. I chose a simple example that you see in many APIs on many platforms. So what I said was not a fallacy (hence no straw man claims to be made).
>Don't make an API that requires a fully qualified path, duh.
Depending on the scope of an API that is not always reasonable. And given that there is no standard, one can't know what they should expect by default.
How is one supposed to know if the argument is a fully qualified path, or a relative path to some other directory? If it is relative, from what directory are we starting? This is all answered in documentation, not paramnames. And if that documentation has some way of identifying that a certain piece of it refers to the pa ram in question, it can be more effectively utilized by tools (most notably IDE in this case) and be of greater use to the developer. Since creating the markup to make the documentation more useful is automated, it is no extra work for the developer to utilize.
I can't be more clear and I totally expect you to not understand that at all.
It is obvious you don't program enough of create sophisticated enough programs.
> Yes, automating a task will remove incentive to do that task.
So you agree that autodocumentation decreases the quality of good literate documentation, you simply disagree when I say bad autodocumentation is worse than no documentation?
> Depending on the scope of an API that is not always reasonable.
Wrong. Making a good and solid API is always reasonable, and sacrificing code quality and robustness causes other problems that your precious autodocumentation cannot fix.
> How is one supposed to know if the argument is a fully qualified path, or a relative path to some other directory?
That's insane. How does POSIX.1 open() know? How does Common-Lisp's make-pathname know? How does Boost.Filesystem know?
Pick a different example besides relative paths. This is a solved problem; a strawman at best, and a demonstration that your whole argument is without merit at worst.
> I can't be more clear and I totally expect you to not understand that at all.
Of course you do! You think "How could anyone hate those little yellow tooltips that say 'absolute path required'" and you know that those little yellow tooltips are what make you productive enough to handle tasks you could never handle before.
Grow up and re-read what I've been saying here. I am saying I would trade those little yellow tooltips for good documentation or a good api.
> It is obvious you don't program enough of create sophisticated enough programs.
Seriously. People wrote "sophisticated programs" before xml, syntax hilighting and Visual Studio. How naive are you to think that others don't need the crutches that you do?
Banner is definitely TextMate, Monaco non-anti-aliased 10px. Mac classic theme.
I love Sudden View, unfortunately it's rather archaic and Windows-only.
XML comment:
/// <summary>
/// Summary of LoadXMLFromFile.
/// </summary>
/// <param name="FilePath">Description of FilePath parameter.</param>
public void LoadXMLFromFile(string FilePath)
Non-XML comment
/* Summary of LoadXMLFromFile
*
* @param Filepath Description of FilePath parameter.
**/
public void LoadXMLFromFile(string FilePath)
Or, Python-style:
def LoadXMLFromFile(FilePath):
"""Summary of LoadXMLFromFile
.. describe:: FilePath
Description of FilePath parameter.
"""Notice the difference? With comments, you don't need a bunch of XML cruft obscuring the text.
>>95
And when it's that obvious from the function and variable names what's what, adding the comment at all actually reduces readability of the source.
Even a simple function like that needs documentation. Is FilePath absolute or relative? Should it be in Unicode, or the local filename encoding? What exceptions will be raised if the data cannot be loaded? Why is the return type "void" instead of the data, is it modifying private variables? If so, which ones?
When somebody says that a function's purpose is obvious, what they actually mean is "I'm too lazy/ignorant to figure out what that function does".
> Even a simple function like that needs documentation.
If it's a library function, and the source isn't available, I agree completely. However, that isn't a case for xml automatic documentation.
> Is FilePath absolute or relative?
If it matters, the function is wrong.
> Should it be in Unicode, or the local filename encoding?
If it matters, the function is wrong. This is more a symptom that the Windows API is designed by brain-damaged 3 year olds.
On windows: If it is a pathname, it should allow \\?\ and your programs should always begin all paths that they produce (but that the user does not produce) with \\?\
On unix: Doesn't fucking matter. Assume all paths are binary blobs unless you have to print them, at which point, they're utf-8.
There's a reason fchdir(open(".",O_RDONLY)) exists.
> What exceptions will be raised if the data cannot be loaded?
If it matters, the function is wrong. This demonstrates what is wrong with exceptions, and why they shouldn't be used by library code.
> Why is the return type "void" instead of the data,
> is it modifying private variables? If so, which ones?
That problem is orthogonal. Why isn't the return type "foop"? Why doesn't it read my mind?
This problem demands documentation, but doesn't demonstrate the value of XML autodocumentation.
> When somebody says that a function's purpose is obvious, what they actually mean is "I'm too lazy/ignorant to figure out what that function does".
I agree, but I don't think that's relevant.
> If it's a library function, and the source isn't available, I agree completely. However, that isn't a case for xml automatic documentation.
Why isn't it? Auto documentation, XML-based or not, is also used for documenting libraries.
>> Is FilePath absolute or relative?
> If it matters, the function is wrong.
In this case, document how relative paths are resolved. Common roots I've seen are the user's home directory, their desktop, the location of the application binary, filesystem root, etc.
> On unix: Doesn't fucking matter. Assume all paths are binary blobs unless you have to print them, at which point, they're utf-8.
At which point, everybody using a non-UTF8 locale can't read their files.
> If it matters, the function is wrong. This demonstrates what is wrong with exceptions, and why they shouldn't be used by library code.
Fine, have it your way. Which error codes does it return? Or, if you're a LISP guy, which conditions does it set? Any way you look at it, you need the function to be able to do something aside from exit the program when the file it's trying to load from doesn't exist, or is malformed. And that error behavior should be documented for when you revisit the code in a few months trying to find a bug.
> Why isn't it? Auto documentation, XML-based or not, is also used for documenting libraries.
That doesn't mean it's good at it. Read back in this thread, through >>80,82,83,85,86,87,88,90,91,92
Recap: Automatic documentation makes it easy to extract structured information. Unfortunately, that doesn't make it useful, and because people rely on automatic documentation, they have a tendency to let "the real" documentation slip.
As a result, sites that use autodocumentation, tend to have worse documentation than sites that don't.
> In this case, document how relative paths are resolved. Common roots I've seen are the user's home directory, their desktop, the location of the application binary, filesystem root, etc.
See POSIX.1 to see how relative paths are resolved. On UNIX, the current-directory is per-process, so this is a non-issue.
On Windows, the current-directory is per-session, so it should only be queried for paths entered directly by a user. Win32 is remarkably consistant in this regard; if you're not doing it like Win32 does it, you're doing it wrong.
Relative paths are a solved problem.
> > On unix: Doesn't fucking matter. Assume all paths are binary blobs unless you have to print them, at which point, they're utf-8.
> At which point, everybody using a non-UTF8 locale can't read their files.
I don't think you program on UNIX often enough, or well enough to understand what you're saying. Almost all UNIX desktops are UTF-8; those that aren't frequently display some file names wrong at worst, but it doesn't prevent the user access to their files. It just prints the name wrong.
Non-desktop UNIX users tend to use a limited set of us-ascii for filenames simply to make them easier to type.
Programs should not attempt to decode pathnames given to them; they shouldn't as a rule attempt to decode /'s or ..'s except as a reason to reject the path outright.
> Fine, have it your way. Which error codes does it return? Or, if you're a LISP guy, which conditions does it set? Any way you look at it, you need the function to be able to do something aside from exit the program when the file it's trying to load from doesn't exist, or is malformed. And that error behavior should be documented for when you revisit the code in a few months trying to find a bug.
That means we need documentation, which I agree with. It doesn't mean we need autodocumentation.
It's fine to hold up the strawman of documentation and say "if we need documentation, then surely autodocumentation is good".
It isn't. Autodocumentation is bad. Real documentation isn't. They aren't related. Using autodocumentation tends to produce awful real documentation.
And see here: Real documentation needs to be really good, and that's hard. Microsoft has a hard time keeping their documentation correct, so what could lead me to believe a computer can document things better than Microsoft? Shouldn't I suspect good, real documentation require at least as much effort as Microsoft puts into it?
Autodocumentation tends to make companies and organizations skimp out on the real documentation. Autodocumentation was a trick to try and get the programmers to write documentation, never mind the fact the programmers they hire aren't able to write.
autodocumentation is ok. if its good enough for python and qt its good enough for me.
kate and vi
I mostly use THE, but occasionally I also use vi (ex-vi in particular).
I actually really like se but it doesn't work on modern *nix. Maybe I should update and port it.
>>103
THE? se? Links.
>>103
THE? se? Links.
>>104,105
This place sucks :(
ed for the win.
>>104 >>105
THE: http://hessling-editor.sourceforge.net/
You can probably find the "se" source code in the comp.unix.sources archive.
Both are descended from XEDIT, an editor for IBM mainframes.
There's also a related editor that works on windows, Kedit.
vim!
> You can probably find the "se" source code in the comp.unix.sources archive.
http://isc.org/sources/editors/se-1.3.php
I actually really like se but it doesn't work on modern *nix. Maybe I should update and port it.
http://www.gifford.co.uk/~coredump/se.htm
it compiles without any changes on ubuntu 8.04, i managed to get to compile and run on freebsd 7 with some minor modifications (removing a couple incorrect function declarations, replacing #include <termio.h> with #include <termios.h>, linking with libcompat, etc.; easy stuff)
> You can probably find the "se" source code in the comp.unix.sources archive.
http://isc.org/sources/editors/se-1.3.php
> I actually really like se but it doesn't work on modern *nix. Maybe I should update and port it.
http://www.gifford.co.uk/~coredump/se.htm
it compiles without any changes on ubuntu 8.04, i managed to get to compile and run on freebsd 7 with some minor modifications (removing a couple incorrect function declarations, replacing #include <termio.h> with #include <termios.h>, linking with libcompat, etc.; easy stuff)
Autodocumentation is fine, but shitty autodocumentation is shitty.
Problem is, to add enough autodocs to turn API documentation into a usable manual, both formats (Javadoc proper and .NET XMLified crap) are inadequate as they add to much formatting cruft. It would be better if we could just write Markdown in there and not have to think about tags except when linking to another method...
Me, I usually write a small game to teach me a new language.
Learn how to use a library that interests you and do something with it, anything.
Like, learn SDL and make a little arcade game. Or a crappy music player using GTK. You get the point.
And keep some open source programs for reference (or use google's code search) when you get stuck at something.
>>115
Uhh, that post was supposed to go into another thread.
I've used first Visual Studio, then Emacs, then vim for a few years. Then I switched to nano and never looked back.
I use GEdit occasionally, too.
>do you name it "strPathName"
No, you establish proper hungarian notation standards for your project and/or company, and name it fqfnRequestedFile (or cfn for canonical filename after resolving links, etc), because the compiler doesn't need you to name the variable "str" to know that it's a string, and you're looking at the function definition where the parameter is declared as a string so a sane human wouldn't need the name to know that either.
Also to the people griping about how caring about relative vs absolute paths is wrong: consider the case of server applications with permissions on given directories, and you need to know what directory your file is actually in.
On topic: vim
I use TECO.
I'm not even joking. It's a steep learning curve and it takes a little while to get used to, but so much power in so little space... literally every string of characters you can type on a standard US keyboard is a valid TECO command sequence. And yet the whole thing is small enough to fit on the tiniest embedded system!
Why yes, I am a total geek, how could you tell?
>>117man 3 realpath
ITECO isn't that hard$>>118
this TECO?
@^UB#@S/{^EQQ,/#@^UC#@S/,^EQQ}/@-1S/{/#@^UR#.U1ZJQZ\^SC.,.+-^SXQ-^SDQ1J#@^U9/[]-+<>.,/<@:-FD/^N^EG9/;>J30000<0@I/
/>ZJZUL30000J0U10U20U30U60U7@^U4/[]/@^U5#<@:S/^EG4/U7Q7;-AU3(Q3-91)"=%1|Q1"=.U6ZJ@i/{/Q2\@i/,/Q6\@i/}/Q6J0;'-1%1'
>#<@:S/[/UT.U210^T13^TQT;QT"NM5Q2J'>0UP30000J.US.UI<(0A-43)"=QPJ0AUTDQT+1@I//QIJ@O/end/'(0A-45)"=QPJ0AUTDQT-1@I//
QIJ@O/end/'(0A-60)"=QP-1UP@O/end/'(0A-62)"=QP+1UP@O/end/'(0A-46)"=-.+QPA^T(-.+QPA-10)"=13^T'@O/end/'(0A-44)"=^TUT
8^TQPJDQT@I//QIJ@O/end/'(0A-91)"=-.+QPA"=QI+1UZQLJMRMB\-1J.UI'@O/end/'(0A-93)"=-.+QPA"NQI+1UZQLJMRMC\-1J.UI'@O/en
d/'!end!QI+1UI(.-Z)"=.=@^a/END/^c^c'C>Though, in TECO's defence, brainfuck interpreters look like that in every language.
At work: VisualStudio + VisualAssist + nFringe
It just makes life much easier :P
At home: Notepad++ (Windows), CodeBlocks (Windows, Linux)
I seem to be the only one who uses Smultron, though I only use it on my Mac laptop (obviously).
Everywhere else I use good old vim.
I've used many editors and now I use emacs. I never looked back or doubted this choice.
gedit
C/C++ on windows I use bloodshed dev-c++ but on linux I use the gnome text editor or pico
Source code in the title is dcraw.c.
I like emacs on Linux/OS X, but I use Vim if I must
>>129
What do you mean "if I must"? When do you have to use vim in place of emacs? (btw, are you aware of the vi-emulation mode of emacs? M-x vi-mode)
>>130 + tramp mode
I recently spent some time using ed, so much power in that small thing. You also learn much more about vi/vim by using it.
Other than that, vim. I'd use emacs if it weren't for the whole hand strain thing. Maybe at some point I'll make the switch to emacs+viper-mode, mostly because vimscript isn't as cool looking as elisp.
>>132
try yi. oatmeal with toenail clippings in it isn't as cool looking as haskell.
>>132
I get much more strain trying to capitalize with shift rather than using the ctrl key. Just find a way to press it without using your pinky (I prefer using my palm). The hand strain thing is not even an issue if you don't write much anyway.
I use PSPad
I really like its FTP mode. I haven't seen any other editor that works like that.
TextMate and/or the editor built in Coda on Mac.
jgrasp or notepad++ on windows, vim or emacs on linux (I still haven't decided which one I like better)
notepad++ on windows, (g)vim or gedit on linux
notepad++/nano on windows, gedit/nano on linux
gedit, elvis, emacs on linux, depending on which computer.
gvim plus a crapton of scripts to make it much less vimmish on windows.
Notepad2 on Windows. Kate, vim and gVim on Linux. MacVim on Mac.
vi/vim
everything else is for fags.
Notepad++ on Windows, Textmate or nano on Mac, Gedit or nano on Linux.
Emacs
Do we really have 144 programmers visitting this board or are you guys replying multiple times to this thread?...
Are there any free editors for windows that can properly indent LISP code besides emacs?
>>146
JazzScheme's editor seems able to handle CL as well. I don't know how well that works though.
http://en.wikipedia.org/wiki/Sam_%28text_editor%29
Rules them all.
gtkemacs
gVim for both Windows and Unix. If I really needed to compile something on my Windows box, I have Cygwin installed with g++.
Is anyone Harverd or MIT?
Emacs
EditPadPro
qwe
Dunno if anyone's mentioned it, but you can change your keyboard bindings to switch the caps-lock key with the control key. It takes a little bit to get used to, but it makes much more sense, when you think about it. When's the last time you used caps lock (other than for cruise control) anyway?
nvi, for editing in general.
>i've just discovered this: http://ex-vi.sourceforge.net/
>it's much more lightweight than vim, and has the one feature i really wanted that nvi doesn't have: support for utf-8.
>i've been using nvi, but the lack of utf-8 support meant that i had to use some other editor (usually mined 2000) whenever i wanted to edit a utf-8 encoded file.
nvi has had UTF-8 support since 2000:
https://en.wikipedia.org/wiki/Nvi
>Sven Verdoolaege added support for Unicode in 2000.[3]
>BSD projects continue to use nvi version 1.79 due to licensing differences between Berkeley Database 1.85 and the later versions by Sleepycat Software.
Fucking tools.
EditPad Lite.
If I've got to work in a *nix text mode, JOE.
VS a shit.
vim + http://vim.spf13.com/
Nedit, nvi, GNU Emacs/XEmacs and Xedit.
Get on my level scrub.
Sublime Text, vi on servers, Visual Studio is fine too.
Depends what I'm working on. If i'm working on some bloated e-commerce mess for a .net client, visual studio is opan obvious choice,
Everything else, ST or if unavailable vi
BSD vi, ed, mg on Unix. Sam and acme on Plan 9. Pe on Haiku.
I like vim with solarized dark colorscheme and the linter syntastic. All is very comfortable that way.
Well, I started with "vi" on my very first shell account (a SunOS 4.x box, back in 1995). No idea what exact version of vi it was, but I didn't have any colors or visual mode, or anything like that. Soon after that, I installed Slackware and started using "vi" there as well. And since I completely stayed away from Windows all these years (except when required for a job), I just kept using vi or vim.
Somewhere along the way I got the crazy idea to swap the Escape and CapsLock keys, using either xmodmap or its console equivalent (e.g. wsconsctl in OpenBSD). That made things a lot more comfortable...
Speaking of OpenBSD, their /usr/bin/vi program is a slightly enhanced version of nvi, because it allows you to split the screen and have several text windows displayed at once. I didn't even realize this until one of the developers mentioned it on openbsd.misc:
our vi has multiple windows.
:E new_file
then ^W to move from file to file.
:viusage
will give you some help.
Granted, the <Control-W> thing is explicitely mentioned in the manpage, but it doesn't explain the differences between the :e and :E commands. All it says is this:
[Ee][dit][!] [+cmd] [file]
[Ee]x[!] [+cmd] [file]
Edit a different file.But anyway, it's a nice feature to have (although I guess you could get similar functionality with tmux windows also).
I also know the basics of "ed", just in case - because at least /bin/ed is statically linked and might be the only thing available to edit files with if /usr is fubar, or the dynamic linker is broken. Well it's not like it's that much different from vi anyway...
Back in my home computer days, I mainly used Notepad on my Amiga 500 (it's the default editor there, but not identical to Windows Notepad). There was also uemacs (microemacs) on one of the Workbench floppies, but I didn't bother with it. I think AmigaBasic (the version shipped with Workbench 1.3) had its own IDE though. I played around with that, but didn't do much except write some character generators and other tools for our tabletop AD&D games.
Before that I had an Amstrad CPC and there of course just used the ROM BASIC screen editor. It works quite well, especially when you switch to 80-column mode (just typing "mode 2" at the prompt did the trick). Their BASIC dialect (Locomotive BASIC) was also fairly powerful, giving you access to many graphics and sound functions without needing to go through the PEEK/POKE mumbo-jumbo. That machine also shipped with CP/M disks, which contained an "ed" program but I didn't really bother with that.
>>164
there's no such thing as vi that doesn't have visual mode. perhaps you're thinking of ex?
>>165
Sorry I meant no visual block operations (select, copy, paste) like vim has. Yeah, the SunOS vi was running in regular full screen mode.
Now the "mail" or "mailx" programs, those dropped you into ed or maybe ex by default, for some reason. I mostly used Pine those days, and only occasionally mail in command line mode, e.g.:
mail -s "hi there" recipient@host < msg.txt
Later on when I started doing sysadmin work, I found myself just telnet'ing to SMTP and POP3 ports a lot (for testing purposes). Those interfaces are actually pretty simple; there's just no nice command-line editing/history or saving of messages to "sent-mail" folder or whatever (unless you're logging the session via typescript or whatever).
Emacs is love; Emacs is life.
mg
Been using textadept lately. Like it a lot.
>>171
I just started mg a few weeks ago after getting fed up once too often with emacs. It's certainly the best lite emacs out there. I wish it had:
- better support for unicode
- better documentation for binding things. Sometimes you have to put a \, sometimes a ^, and the examples are completely unhelpful.
I'd probably switch full time if it had syntax highlighting (yes, I'm weak) and if I had a good stand-alone LaTeX reformatter.
I tried Spacemacs after using Vim for years, and have now settled on neovim.
tbh, php is shit. java is pretty dank though