What's your experience with using % for accessing object members?

[Harper]

@NormanKirkby is quite right. F2023 6.3.2.2 says blanks may be inserted between tokens, and 6.2.1 says % is a token. Things like a%b and a % b both occur many times in the standard.

[eelis]

I tried now the solution provided by @Euler-37. I think it works perfectly.

ettaka/toolsrc/blob/master/nvim-lua/plugin/fortran-settings.lua

One thing that is probably good to mention: there is an editor option conceallevel that seems to have a default value 0. I needed to set it 1 for the conceal feature to have an effect.

Here is an example rendering with my options (on left is the default rendering, on the right is the concealed rendering):

One can also conceal with the more conventional symbol .:

Or some emoji :

Notice how the cursor line remains unconcealed. This is due to the concealcursor option that allows to concealment of the matches at cursor line. However, I was not able to alter the default behavior. If Anyone has an idea, let me know.

[Beliavsky]

I’m glad you were able to create a text editor mode that displays code the way you want, but I think that as one gains experience with a language one gets used to its syntax, and I wonder if configuring an editor so that code looks different from what it really is inhibits learning the syntax of a language. Personally I am fine with the % separator, but tastes vary.

[eelis]

You might have a point there. I don’t know if I am going to keep it.
I just think this new editor technology is very interesting, maybe a different rendering is useful for someone who has trouble to to read % in between the component names.

Btw. An interesting hack: I noticed if I conceal with

 autocmd FileType fortran syntax match FortranConceal '%' conceal cchar=%

(that essentially is ‘%’ - > ‘%’), I get the behavior suggested by @RonShepard in the beginning of the thread. This happens because, in neovim, concealed characters are colored differently from other characters:

[jacobwilliams]

Frankly, setting up an editor to display one character to look like a totally different character that is also a valid token is just a terrible idea!

Learn to love the %. Like we have to learn to love the _wp. There are better things to complain about!

[samharrison7]

@jacobwilliams

learn to love the _wp

Never!

@eelis

Or some emoji

Why not go the whole way: https://www.emojicode.org/

[aerosayan]

@Beliavsky

as one gains experience with a language one gets used to its syntax,

Yes.

I originally created the thread, because at that time, % was too jarring to me, but now I’m okay with using it.

So, % doesn’t feel bad to me anymore.

The main reasons I used to dislike % is, surprisngly not because of its looks. I thought I disliked how it looked, but after some introspection, it became clear to me, tha I disliked it because of:

• Having to use the shift key to type %. It used to break my concentration, and make me feel sick.
  • The solution for this, was for me to configure my editor to type % when I type --. Since -- is not used in Fortran, this configuration allows me to type % very easily.
  • For example, If I type mpi--rank, it will be written to my code editor as mpi%rank

I think I will one day write more on how to configure editors for better experinece with coding Fortran, because that’s the only way to be productive.

[rwmsu]

I propose we replace the % with the “middle finger” emoji . Which is my usual response to all that want to turn Fortran into C++.

[epagone]

@aerosayan

I disliked it because of:

• Having to use the shift key to type %. It used to break my concentration, and make me feel sick.
  • The solution for this, was for me to configure my editor to type % when I type --. Since -- is not used in Fortran, this configuration allows me to type % very easily.
  • For example, If I type mpi--rank, it will be written to my code editor as mpi%rank

I think that this is an excellent idea. Maybe @gnikit and others working on the Modern Fortran VSCode extension might be interested in including this option, as opt-in only.

[eelis]

I had a mapping with a similar idea to yours in vim: jj to <Esc> because with a modern keyboard escape is far away at the left corner. It was surprisingly annoying when I actually had to type “jj” in a string. “jj” is very rare but, back in the day, I could not live with the idea of having to pause when I needed to type it . So I ended up swapping my caps-lock and escape buttons.

Now I think mapping jj to <Esc> is not that bad because of rarity of “jj”. But in your case I would recommend not to map --. It doesn’t look like something extremely rare.

I think in your opening post you made another good point about the difficulty of reading % in between variable names. I think it is relevant. I think this issue can be mitigated using the rendering to a completely new symbol (but not a valid token like ., as mentioned by @jacobwilliams ) or maybe even better, just changing the color as suggested by @RonShepard.

[aerosayan]

@eelis

I had a mapping with a similar idea to yours in vim: jj to <Esc>

I have a better solution for you fren.

Instead of pressing Esc, I press F2 , which both goes out of insert mode, saves the file, and formats the code with LSP (if you’ve enabled a LSP)

My muscle memory is insanely fast, and now pressing F2 is faster than jj or Esc.

-- Save file after pressing F2 in both NORMAL and INSERT mode
vim.keymap.set('n', '<F2>', "<cmd>w<cr>", { silent = true })
vim.keymap.set('i', '<F2>', "<esc><cmd>w<cr>", { silent = true })

-- Save file and format file with LSP after pressing F2 in both NORMAL and INSERT mode
vim.keymap.set('n', '<F2>', "<cmd>w<cr><cmd>Format<cr><cmd>w<cr>", { silent = true })
vim.keymap.set('i', '<F2>', "<esc><cmd>w<cr><cmd>Format<cr><cmd>w<cr>", { silent = true })

[certik]

I remap Caps Lock to ESC, then Vim is very comfortable to use.

[rwmsu]

I do the same. I also have a couple of Sun Unix keyboards that are my daily drivers that have the keys in the places the Creator intended them to be

[eelis]

I will think about creating a “C++ syntax for Fortran a la rwmsu” (that was a funny one :D). And for the record: I don’t like C++ syntax.

Sorry if I am committing a blasphemy here: I could not resist but try concealing call with a phone (toolsrc/nvim-lua/plugin/fortran-settings.lua at master · ettaka/toolsrc · GitHub):

For me it renders gray for some reason (I would have wanted red). But I kinda like the phone icon there

[eelis]

Where do you get those? I am interested.

For this exact reason I both myself a “Moonlander” ZSA Moonlander: Next-gen Ergonomics, so I can put the keys where I want them. Moreover, I like the ortholinear layout + ergonomy in general.

[Beliavsky]

The thread

Syntax of interactive Fortran

LFortran can compile a Fortran source file as other compilers do, but for interactive use it allows some extensions that one would expect in an interpreted language. You can enter an expression such as 2+3 instead of print*,2+3. You don’t need an end program foo statement to have a script run. You can redefine a function. Here are some thoughts on how it should work. I wonder what others think. Currently you must declare variables before using them. For interactive use, I suggest that LFortran…

discussed making call optional and other syntax changes that could convenient in interactive mode. It’s OK to experiment as long as actual source files that are saved are proper Fortran.

[rwmsu]

One I got on Ebay, the other is from a circa 2007 Sun Opteron (remember those) workstation I used to own. Look for a Sun Type 7 Unix USB keyboard. I bought the second one off Ebay because I got saddled with one of those Dell chicklet key keyboards that lie virtually flat at work. Man I hate those things. A day of typing on one felt like someone had stepped on my hands. The Sun part number is 320-1367-02. My Linuxmint (Ubuntu based) distro recognizes it as a supported keyboard. The big advantage of the Unix keyboard layout is I find it plays a little nicer with Vim (at least for me) than the “standard” layout.

[eelis]

I agree with you 100%.

Just to be clear: what we are doing in this Vim conceal (probably many other editors can do the same), is just changing the rendering of the actual code. I consider it a bit like when we write mathematical formulas in Latex, we write code that is not so nice to read but when rendered, it looks beautiful.

And actually, here we could do the same. I remember at SC23 BoF at Denver, Damian Rousson displayed code that had an operator .laplacian. and I was really impressed by that beautiful demonstration of Fortran capabilities. I don’t remember exactly what was written, but I try to write a pseudo code here to demonstrate a bit the capabilities of conceal for what we could do on top of code like that.

On the left is the code that I actually type in my editor (the default rendering that I get with :set conceallevel=0) and on the right I have the same code rendered with the conceal on (:set conceallevel=1)

So you can see that it looks even more mathematical than it was before.
I consider this conceal also a bit like syntax highlighting: we are trying to improve the readability by making the code clearer. So even if I have mapped '%'->digraph, 'call'->phone and '.laplacian.'->Delta, I still type the code and not those unicode symbols (they are only representatives of what is written).

I also agree with what you said earlier: this might be bad for learning the actual tokens… Also I could imagine that this can get out of hand pretty easily and become a huge mess! I would draw the line somewhere in the operators (if one can find good and conventional symbols for them). However, note that when I put my cursor on the line I want to work on, it is displayed as the actual code:

[eelis]

Thanks! I will have to look for those. I would like to have a more conventional keyboard but with the buttons in correct places, as you wrote, where the Creator intended them to be.

[Beliavsky]

Now you have Fortran code looking like Julia Since the two languages are used in the same domains, that may be a good thing.