Geany does Fortran just fine. Failing that, good old Emacs works. Micro also has a syntax file for it.
Will any of these editors understand either type-bound or object-bound procedures well enough to provide āgoto definitionā?
Geany and Emacs do, though the latter is going to need a TAGS file.
Could be worse. Could have said Do you mean Notepad+ ![]()
With VSCode I manage to do that, here a screen shot on the json-fortran library by @jacobwilliams
The āGo to Implementationsā takes me to the subroutine, and I can also do āPeekā to open a quick window in the current context:
Wow! Is that your own plug-in? Or a feature of the modern fortran plug-in? Thanks for sharing, perhaps it really is time for me to move on from edlin?
No, thatās with the standard setup using the Modern Fortran plug-in and fortls. I did nothing special.
First, a thank you to all who have contributed to this thread. I have installed and experimented with most of the suggestions. My resulting impressions are:
vi/vim: All linux/unix users probably know how to use these. They have one fatal flaw. You have to remember whether you are in command made or insert mode. Over the last forty odd years I have discarded so many edits after typing text into command mode by mistake, and all kinds of exciting things have happened. Useful for small jobs and sedit scripts. For me, not for program development.
emacs: Very powerful but idiosyncratic. I found that ^C and ^V didnāt cut and paste (perhaps it can be taught?). I used it 40 years ago but have forgotten.
sublime_text was suggested by one contributor. We have it and it is good. We didnāt find it as powerful as uex.
vscode: This I like. The issues I found may be easy to fix:
- The syntax colouring only works in lower case. In most of our code library (many millions of lines) the keywords are in upper case.
- Some important, if non-standard, keywords are not handled by the syntax colouring I found. I can cope without DICTIONARY, DO UNTIL and EXTENDED DUMMY, but STRUCTURE MAP and UNION are common and in some programs essential.
- I would like to extend the list of file extensions handled as Fortran. We have thousands of include files which are .inc, and hundreds which are .i90 . fpt output files, by default, are .fpt and .fpi . I am sure there are others.
- The indentation rulers are in the wrong place for much of the code in our libraries. I need to be able to move (or at least remove) them.
uex (ultra-edit): No-one suggested this but it is the best text editor we have found, with good syntax colouring. I started this thread because uex crashes on our systems. I am now working with the support team to find out what I have done to deserve this and to correct it.
Again, many thanks.
If vim ceased to exist, I would quit programming.
In my experience the secret to effective use of vim is to completely turn off both capslock and tabs if you can. also having a unix specific keyboard (if you can find one) helps a lot.
Me too. I can safely say āI vim therefore I amā ![]()
Probably because Emacs is older than Microsoft Windows (where Ctrl-C/V/X were de facto standardized in early 1980s)
I guess vim does not recognize them either.
You can teach Emacs practically anything you want, though particularly with Ctrl-C and Ctrl-X it would require quite an effort as both these keys introduce multi-key sequences (Ctrl-C does it per-major-mode to make thinks even harder).
I also remap Caps Lock to Escape on all computers (Linux, macOS, Windows), which I found essential to not have pain in my pinky.
I donāt understand your take on vim/vi. In my experience - in the beginning - you are always in normal mode, then you do something and you go immediately back to normal mode. I have never heard anyone spending more time than necessary in some other mode, so you donāt really have to āremember itā. It is like taking stuff from fridge: you have the door closed - that is your normal mode - you open the door, take stuff, and close it. Even in the night time - when you donāt see - you donāt normally have to remember the āmodeā of the fridge door because you know it is the normal mode.
I think I understand, because it took me numerous attempts before I finally settled on Vim, even though by the time I first tried it, I hadnāt used Windows for ~10 years⦠itās like Ctrl+C/V/X was so ingrained that I couldnāt see past it.
IIRC, it was something like:
- Visual Studio (Windows, until 2006 I guess)
- Gedit (Linux, until GNOME 3 came out)
- Netbeans (got tired of Geditās plugins breaking after every GNOME upgrade)
- Vim (got tired of Netbeans sucking all the RAM)
- Eclipse (I wonder why I switched to it)
- Vim (better, but didnāt take)
- Geany (it randomly misbehaved)
- Atom (in terms of RAM, it behaved like Netbeans; with this one, I discovered its Ctrl+P mode was actually inspired by a Vim extension)
- Vim (much better, still didnāt take)
- Sublime (it was great until you needed to configure anything extra; then it was nightmarish)
- Vim (I think tpopeās extensions were what finally helped me get settled)
Iāve used VSCode (which is just Atom with better performance) and the IntelliJ IDEs from time to time (always with a Vim modes extension), but the experience always felt subpar to Vim.
Last summer I wrote this about Vim:
If you want to try Vim, keep in mind that the hard part isnāt learning which keys to press; in fact itās easier than in other editors. But Vim requires a mental shift: it separates writing from editing with a flaming sword. You have to come at it with a kind of back-and-forth, snicker-snack motion. That takes an adjustment, but is also rewarding once you figure out the trick.
The need to mentally switch context all the time is what makes it challenging in my opinion. Some people will love it, others will hate it. I just ended up working better with a non-modal editor, be it Emacs or something with a CUA interface (though that requires a different kind of context switching). Then again itās easier for me to pick one because I donāt care much for IDE features. Either way, Fortran is thankfully well-supported, so thereās an ample selection of available editors.
I was curious when this convention was first invented, and I found this article: Cut, copy, and paste - Wikipedia which credits work done at Xerox starting in 1974. It was then incorporated into the Apple Lisa project starting in 1979 (released in January 1982), and next into the Apple Macintosh project starting in 1982 (released in January 1984). From there, it migrated to the MS Windows project, the first version of which was released as a shell on MS DOS in December 1985.
I routinely combine Cmd-c,v,x on Mac computers within emacs in a terminal window. Emacs has its own yank, kill, and copy commands with its own internal kill ring. I expect this would be confusing to most new programmers, but it is certainly possible to do, you just have to avoid confusing the operations on the MacOS clipboard with those in the Emacs environment. For those who like complications, you can also use Emacs within the X-Windows environment on MacOS (XQuartz); it uses the mouse buttons to select, copy, and paste text within its own environment too. So there are three different places you can copy text to and three different places to copy text from, all at the same time.
I should also have mentioned previously that the reason I started using Emacs (about 1984) was because it worked on many different versions of Unix and also on DEC Vax computers at that time. Otherwise, DEC EDT did not work on unix machines, and unix vi (later vim) did not work on Vax computers, so by learning Emacs (which has a long steep learning curve) I could more or less move freely among many of the computers I was using at the time.




