white spaces before comments, how to configure

[szaghi]

Dear @pseewald

sorry for the stalking...

I found that the handling spaces before comments is somehow obscure for me, e.g. applying fprettify on a FLAP files I obtain

baseline code

module flap_utils_m
!-----------------------------------------------------------------------------------------------------------------------------------
!< FLAP utils.
!-----------------------------------------------------------------------------------------------------------------------------------
use penf
!-----------------------------------------------------------------------------------------------------------------------------------
...

pretty-formatted code

module flap_utils_m
!-----------------------------------------------------------------------------------------------------------------------------------
!< FLAP utils.
!-----------------------------------------------------------------------------------------------------------------------------------
   use penf
!-----------------------------------------------------------------------------------------------------------------------------------
...

Comparing the two versions the comments have not been touched, but this is not true for procedures contained into the module, e.g.

baseline code

contains
  elemental function count_substring(string, substring) result(No)
  !---------------------------------------------------------------------------------------------------------------------------------
  !< Count the number of occurences of a substring into a string.
  !---------------------------------------------------------------------------------------------------------------------------------
  character(*), intent(in) :: string    !< String.
  character(*), intent(in) :: substring !< Substring.
  integer(I4P)             :: No        !< Number of occurrences.
  integer(I4P)             :: c1        !< Counters.
  integer(I4P)             :: c2        !< Counters.
  !---------------------------------------------------------------------------------------------------------------------------------
...

pretty-formatted code

contains
   elemental function count_substring(string, substring) result(No)
      !---------------------------------------------------------------------------------------------------------------------------------
      !< Count the number of occurences of a substring into a string.
      !---------------------------------------------------------------------------------------------------------------------------------
      character(*), intent(in) :: string !< String.
      character(*), intent(in) :: substring !< Substring.
      integer(I4P)             :: No !< Number of occurrences.
      integer(I4P)             :: c1 !< Counters.
      integer(I4P)             :: c2 !< Counters.
      !---------------------------------------------------------------------------------------------------------------------------------
...

All the comments have been moved.

To me, it seems that only the comments starting at the very first character remain untouched, while the others are moved. This can be fine, but I would like to configure this behavior. In particular, I like that the inline comments after variables remain at the same relative distance they have, thus if you move variables the comment moves accordingly.

Cheers

[pseewald]

Dear Stefano

Unindented comments are not moved intentionally. This feature exists because especially for larger comments or comment boxes it is useful to have comments spanning the whole page.

I understand that for proper alignment of documentation, whitespaces between line and comment should not be removed. This is easy to implement, and I'll make this an option.

Feel free to report any features you'd like to have. In the future, I'd like to make fprettify as configurable for the user as possible, allowing for different coding conventions.

[szaghi]

Unindented comments are not moved intentionally. This feature exists because especially for larger comments or comment boxes it is useful to have comments spanning the whole page.

Yes, I agree. I guessed it, but I prefer to ask you.

Feel free to report any features you'd like to have. In the future, I'd like to make fprettify as configurable for the user as possible, allowing for different coding conventions.

Indeed, I have tons of coding conventions, see this and this other, I am not sure you will be happy to be stalked by me 😄

Cheers

[pseewald]

@szaghi
Please let me know if fprettify violates any of your coding conventions 😟. I had a look and could not find any major disagreements 😅.

Are there other cases where you would like that fprettify does not override manual alignment? I think it is better if I implement a general solution than a solution that works just for comments. As you noticed, fprettify always removes space characters and thus overrides manual alignment (except for spaces around ::).

As a general solution, I'd propose this feature:
Whenever fprettify encounters n or more consecutive space characters in a line, it does not remove them. Of course space characters at beginning of line are always removed and replaced by the right indentation. The activation of this feature and the number n are command-line options (by default, n=2). Do you think this is useful?

[szaghi]

@pseewald Great! Thank you very much for your work!

Whenever fprettify encounters n or more consecutive space characters in a line, it does not remove them. Of course space characters at beginning of line are always removed and replaced by the right indentation. The activation of this feature and the number n are command-line options (by default, n=2). Do you think this is useful?

All sound very very good.

Soon I'll try again your linter with my codes, but this day and the next are very busy.

Cheers

[dbroemmel]

@pseewald
To add my 2ct, I'm also in favour of leaving n or more consecutive space characters as they are. I see codes with statements like

integer, parameter :: b_halo = 7
integer, parameter :: laser  = 8
integer, parameter :: egy    = 9

which I think profit from the extra readability (Unless I missed an easier or already available method of not changing those).
However, this might be interfered with by the whitespace rules for adding spaces in formulas?

[pseewald]

However, this might be interfered with by the whitespace rules for adding spaces in formulas?

Yes in the current implementation, whitespace is always overridden by the rules. But I'm planning to change that such that n consecutive spaces are always respected.

[pseewald]

@dbroemmel and @szaghi
My initial idea to respect n consecutive spaces was harder to implement than I thought and I never found time to take care of this issue.

I now committed a simpler fix:

• whitespaces before comments are not stripped by default (unless argument --strip-comments is given).
• whitespace formatting can be disabled by --disable-whitespace option (in this case, fprettify fixes indentation only)