I always feel a bit “beginner-ish”, but for most quick file edits I use nano (or gnome-text-editor if it’s more extensive and user-accessible). For my Python development I use PyCharm.
3 Likes
@andreas I’d say you cover quite a broad range with those three editor choices. I know that nano is very modest, perfect for those quick edits. I don’t know what the gnome-text-editor link will provide; more than likely it’s either gedit or some other full-featured editor that’s present in your GNOME configuration. I’ve tried PyCharm, but I don’t really need it because I’m not a heavy Python developer and the editors I do use are at least capable of highlighting Python syntax and follow Python conventions; I never dug into PyCharm enough to know whether it would snag an entire Python module or code block, but based on how big it was when I tried it, I’m sure it provides plenty of Python goodies.
Maybe when you get a few minutes you can describe a few of the features that PyCharm provides when you’re coding or updating Python code.
3 Likes
Of course! The features I heavily use in PyCharm are:
- Its excellent (and easy to setup) debugger—I’m really used to (and probably spoiled with) that one;
- Its type checking (and whether my type annotations are in accordance with what the functions actually return);
- “Digging” through functions: it’s very simple to dig through source code that way, even for imported packages (unfortunately, it happens quite often I have to inspect what a package I’m using is doing exactly);
- Refactoring of any thing, variable names, file names, folder names;
- I like that you can set it up to have quite strict Python warnings (e.g., for variable initialisation outside of
__init__, cases where a variable might not exist, typing, PEP8, etc.).
But I think the debugger is really the main reason I stick with it. I often have to trace bugs through other packages as well, and the PyCharm debugger allows me to do that quite conveniently.
3 Likes
Thanks @andreas! Given how “heavy” the PyCharm editor seemed to be back when I installed it to go through many of the editors listed in the @hydn article, your detailed explanation, particularly about the debugger, adequately explains this.
As I explained, the main reason I didn’t stick with it is that the only Python stuff I do is pretty simple - mainly code I copy from elsewhere, alter slightly, for small tasks or tools, and I haven’t done any of that recently, hence no personal need. Nevertheless, being a fan of technology, I most definitely appreciate your explanation and reasoning, so thanks again for noting your usage particularly concerning the debugger!
3 Likes
Of course, you’re very welcome!
I agree with you that PyCharm is rather heavy, I also don’t use it for simple scripts or small tasks. However, with bigger projects, its power does come in handy.
3 Likes
I am rust developer, The code editors I use are VScode and NeoVim, Those 2 code editors suit my needs, very well
5 Likes
Welcome to the community @Jakarta2, thanks for joining us! 
2 Likes
@Jakarta2 Greetings and welcome to the forum!
I find applications with a lot of Rust code tend to generate extra heat on my systems, especially the older ones. My Lenovo Thinkpad T14 Gen 3 handles it better but it heats up too, but it finishes what it’s doing and cools back down.
I tried VScode when @hydn shared his original post; it works fine but it’s not my style. Neovim works fine for me. I do use it, but I actually prefer Doom Emacs, which adds a Space leader group of key bindings and extra functions that allow Emacs to easily handle all development tasks; it also has vi key bindings which would be familiar to you.
When you get a chance, tell us more about your work with Rust. Perhaps you can create an article about it.
4 Likes
I dropped neovim and my current primary is flow
*reason : neovim getting slower & bigger.
3 Likes
Gonna give flow a try. This is cool:
Toggle the Mode: Press
F4while the editor is open to cycle through the keybinding presets until you reach Vim mode
2 Likes
I’ve been using Neovim for the past 3(ish) years. I will definitely be giving this a look, thank you for sharing!
4 Likes
I don’t use it much but I keep notepadqq in case I need to interact with windows users.
4 Likes
UPDATE: While I’m still using and liking Zed overall, I certainly haven’t yet “put it through it’s paces”, but I’ve not found anything that made me question this move --until today.
Context: I generally use Claude Code to validate my ideas, strengthen my business rules, etc. (Working solo, it is a useful resource to verify my approach and ideas.). I only let it write code in very controlled circumstances.
Issue: Zed team has switched to using ACP instead of native Claude Code CLI. (ACP is Agent Client Protocol which Zed team has pioneered. It is growing in popularity but not fully feature-complete and not officially adopted yet by Anthropic.) So, it’s somewhat hobbled compared to the CLI. Of course, I can switch back to using the CLI in a terminal but without that in-editor integration, it feels I’ve lost something from what I had.
Importantly, using ACP does not actually use my subscription so it doesn’t “cost” anything. But it does limit to only 120-200K tokens before compression sets in. My subscription gives me 1M tokens before hitting compression. That matters for me because I tend to have long, extended chats.
2 Likes
If I still worked in an office, maybe chat windows would matter, but chances are that in jobs where I had to chat, I probably was given a current generation Windows laptop. I remember having a Thinkpad in one job where I did have a lot of communication taking place, and I’ll give them credit; the laptop had solid specs and the servers I was connected to had redundancy, high performance and were never, not even a single time, a source of any problem. I doubt that we would be using Zed even today in such a scenario. Any other editing concerns? How about navigating through fairly large files? Good searching facilities? How about word by work, paragraph and page navigation? Are you using arrow keys and page presses, navigation bar movement, or some efficient mechanisms other than these?
2 Likes
Understand, I’m referring to the chat with Claude not chatting with other people.
2 Likes
Oh, sorry. You mentioned both editors, but I didn’t detect that it was Claude that provided the chat “name” or features.
3 Likes
I’m adding some stuff today that I wrote as a bit of a historical journey with some of the text editors that profoundly influenced the path of my professional career and turned a poor typist (me) into someone capable of writing some halfway decent prose and occasionally a solid technical contribution, so what follows might be edited and applied into it’s own article about text editor history!
Even though the GNU Emacs integrated development environment, perhaps the most complete and diverse IDE around, and though the original GNU Emacs made it’s first full release way back in 1984, don’t let that dissuade you, any more than using either an old vi or a new Vim or Neovim should dissuade you from using any of them. The Gritter packaging of the original Vi (now at version 4.0), not all that widely available, but it CAN be found in this thread (or ask @brgs or me for the info) is around the size of Nano but it can do SO much more than Nano, though it’s a more challenging tool to learn (whoever let THAT stop them!).
Emacs, on the other hand, is so much more than JUST a text editor that you can’t even compare it to vi or Vim – besides, there are key bindings available that allow vi users to use it if they prefer vi bindings.
Today my interests brought me back to an article, probably one of the ones that I used in some of my graduate Computer research:
Emacs - Wikipedia is not the research itself, but it refers back to several things I looked at back then:
“Emacs development began during the 1970s at the MIT AI Lab, whose PDP-6 and PDP-10 computers used the Incompatible Timesharing System (ITS) operating system that featured a default line editor known as Text Editor and Corrector (TECO). Unlike most modern text editors, TECO used separate modes in which the user would either add text, edit existing text, or display the document. One could not place characters directly into a document by typing them into TECO, but would instead enter a character (‘i’) in the TECO command language telling it to switch to input mode, enter the required characters, during which time the edited text was not displayed on the screen, and finally enter a character () to switch the editor back to command mode. (A similar technique was used to allow overtyping.) This behavior is similar to that of the program ed.”
I’ve talked about TECO more than once, and I’m among those who have actually used it!
“Multics Emacs is an early implementation of the Emacs text editor.[1] It was written in Maclisp by Bernard Greenberg at Honeywell’s Cambridge Information Systems Lab in 1978, as a successor to the original 1976 TECO implementation of Emacs and a precursor of later GNU Emacs.[2]”
I used the Multics Emacs too, actually BEFORE I ever saw TECO – I didn’t see that until LATER when I worked at Digital Equipment Corporation. I used Multics for several months when I was working in a Hourly Personnel Systems support organization. I also did a little bit of COBOL maintenance programming but that didn’t scratch my itch. Though the system wasn’t that fast, MULTICS and MULTICS Emacs were quite interesting to me, so when I saw Richard Stallman had implemented GNU Emacs a year or two later, when I joined Digital, that was one of the first things I snagged.
I really wasn’t that good with the default key bindings found in Emacs and that’s why the handy tools in Emacs were so useful to me.
GNU Emacs had (and still has) an EDT mode and I did know EDT, but Digital also had a word processor called WPS and variations of it called WPS Plus, so to learn Emacs better I looked at the EDT emulation mode and wrote my own WPS mode based on the EDT mode; that helped me get better at writing Emacs Lisp.
Later I used the 12 and 24 function key terminals at Digital and wrote key bindings for several of the keys, turning GNU Emacs into an EASY tool for several people in my group. I also wrote a few tutorials on getting started with our organization and of course that included how to obtain and use those handy Emacs key bindings!
I have a copy of those in my collection of notes that I keep in my archives.
Alas, most of my current laptops don’t use the function keys very efficiently, but I still have a few handy bindings, at least for some quick Vim/Neovim and optional Emacs bindings. Meanwhile, I’ve found Spacemacs, Doom Emacs, and now “Meow”; each of which have their own distinctive “take” on how to use easy to use bindings that don’t HURT your fingers and arms, and allow you to harness many of the fantastic features of these tools.
Sure, for the “average” individual, some of this stuff is so “far over the top” that it simply may not make sense for everyone, but for those who see the value of a truly advanced, genuinely INTEGRATED development environment, and you either want to leverage some of the work that people have done, perhaps remapping, altering, extending, or making your very own variation at some time – THEN all of this stuff suddenly makes a GREAT DEAL of sense indeed!
The Craft of Text Editing: Emacs for the Modern World, By Craig A. Finseth, has a lot to say about some of the original ground breaking text editors. The book was written in 1991, but some of the really great foundational text editors were written in the 1970s, right around the time when I was still pursuing my undergraduate degree in Computer Science, so I didn’t actually get my hands on any of the really good stuff until late 1982, but in 1983-84 I got to take a few classes, including an introductory course about Unix followed by a course in C.
It was in the first course in C that I got my first look into vi. During the class I started doing some of the exercises using the command-based ed editor. It gets the job done, but it’s not that great unless you’re a master of substitution exercises, such as what you’d learn or know with sed (or if you get advanced, Awk, Gawk, or Perl). I can use all of them to some degree, though to this day I’m not what I’d call an expert, so as you might expect, ed was not a very efficient way for me to work. Fortunately someone there showed me vi, and just enough vi commands, such as i to insert, Esc to return to “edit mode”, and a few others. It didn’t take me long to learn more; that was way better than ed for me!
Given that I’d seen what something like Emacs could do, needless to say, that interested me, and when I found some systems more capable of actually using these tools, that set me in motion in the Unix world, all half a decade before Linux came into being. Better still, as I was using Unix in a company of engineers known for finding and using handy tools, we had what we called a “Contrib” area where engineers would either install or submit requests to have handy tools installed. Guess what often ended up on “Contrib”? You may have guessed: GNU tools, including GNU Emacs, a GNU version of tar, and plenty of other GNU tools. By the time Linux came into being, I already was well experienced in most of the common GNU tools and I was certainly conversational in the use of multiple vendor implementations of Unix – NCR Tower Unix, Altos Xenix, HPUX, IBM AIX, Sun OS, Sun Solaris, Digital Ultrix and Digital UNIX; by the time DEC added 64-bit UNIX I was working on that team – a project that became Tru64 UNIX. I left shortly after it came out and brought my expertise in testing into the Financial Services industry.
Anyway, put all of that together and that’s why I spend so much time, often in a historical context, examining the tools we have today, but especially those that still exist that have a long, productive history of use!
4 Likes
TECO (text editor) - Wikipedia has more interesting history about TECO. I’m trying to see if I can locate the original set of escape sequences to get in and out of TECO, to save files and do some other interesting stuff.
People have made all kinds of jokes about TECO, including the ones from ancient days about acoustic coupler “line noise”. That’s when you’re on a bad connection and you start seeing tilde and other unusual characters appearing in the middle of your WORK!
I thought I remembered the line noise joke: here’s an actual quote about it!
" The obscurity of the TECO programming language is described in the following quote from “[Real Programmers Don’t Use Pascal]”(Real Programmers Don't Use Pascal - Wikipedia)", a letter from Ed Post to Datamation, July 1983:
It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text. One of the more entertaining games to play with TECO is to type your name in as a command line and try to guess what it does. Just about any possible typing error while talking with TECO will probably destroy your program, or even worse - introduce subtle and mysterious bugs in a once working subroutine.[28]
Also:
There’s a newer program called UltraEdit that is really useful when viewing or editing XML on Windows. Notepad++ also does a nice job on Windows with XML. The only reason I know that is 8-9 years ago in my final professional job I was a test engineer creating XML test data for a re-engineered enterprise application.
2 Likes