On syntax decoration of identifiers containing underscore and statements word [f90]

On syntax decoration of identifiers containing underscore and statements word [f90]

[Angelo Graziosi]

I noticed that in f90-mode, identifiers of variables like

  a_close = 0
  a_read = 0
  a_open = 0
  ...

are decorated with "a_" in black and the statement word (close, read, 
open..) in magenta.

While identifiers of variables like

   a_clos = 0
   a_program = 0
   a_if = 0
   ...

are all in black. Shouldn't they be all in black?


Ciao,
   Angelo.

Re: On syntax decoration of identifiers containing underscore and statements word [f90]

[Stefan Monnier]

> I noticed that in f90-mode, identifiers of variables like
[...]
> are all in black. Shouldn't they be all in black?

Indeed.  I installed the patch below which should fix those problems.


        Stefan


=== modified file 'lisp/progmodes/f90.el'
--- lisp/progmodes/f90.el	2013-05-15 00:52:07 +0000
+++ lisp/progmodes/f90.el	2013-05-17 00:34:20 +0000
@@ -319,6 +319,8 @@
 ;; User options end here.
 
 (defconst f90-keywords-re
+  (concat
+   "\\_<"
   (regexp-opt '("allocatable" "allocate" "assign" "assignment" "backspace"
                 "block" "call" "case" "character" "close" "common" "complex"
                 "contains" "continue" "cycle" "data" "deallocate"
@@ -342,10 +344,13 @@
                 ;; F2008.
                 "contiguous" "submodule" "concurrent" "codimension"
                 "sync all" "sync memory" "critical" "image_index"
-                ) 'words)
+                 ))
+   "\\_>")
   "Regexp used by the function `f90-change-keywords'.")
 
 (defconst f90-keywords-level-3-re
+  (concat
+   "\\_<"
   (regexp-opt
    '("allocatable" "allocate" "assign" "assignment" "backspace"
      "close" "deallocate" "dimension" "endfile" "entry" "equivalence"
@@ -363,7 +368,8 @@
      ;; "concurrent" is only in the sense of "do [,] concurrent", but given
      ;; the [,] it's simpler to just do every instance (cf "do while").
      "contiguous" "concurrent" "codimension" "sync all" "sync memory"
-     ) 'words)
+      ))
+   "\\_>")
   "Keyword-regexp for font-lock level >= 3.")
 
 (defconst f90-procedures-re
@@ -428,6 +434,8 @@
   "Regexp matching intrinsic operators.")
 
 (defconst f90-hpf-keywords-re
+  (concat
+   "\\_<"
   (regexp-opt
    ;; Intrinsic procedures.
    '("all_prefix" "all_scatter" "all_suffix" "any_prefix"
@@ -447,10 +455,13 @@
      "align" "distribute" "dynamic" "independent" "inherit" "processors"
      "realign" "redistribute" "template"
      ;; Keywords.
-     "block" "cyclic" "extrinsic" "new" "onto" "pure" "with") 'words)
+      "block" "cyclic" "extrinsic" "new" "onto" "pure" "with"))
+   "\\_>")
   "Regexp for all HPF keywords, procedures and directives.")
 
 (defconst f90-constants-re
+  (concat
+   "\\_<"
   (regexp-opt '( ;; F2003 iso_fortran_env constants.
                 "iso_fortran_env"
                 "input_unit" "output_unit" "error_unit"
@@ -482,7 +493,8 @@
                 "integer_kinds" "iostat_inquire_internal_unit"
                 "logical_kinds" "real_kinds" "real32" "real64" "real128"
                 "lock_type" "atomic_int_kind" "atomic_logical_kind"
-                ) 'words)
+                 ))
+   "\\_>")
   "Regexp for Fortran intrinsic constants.")
 
 ;; cf f90-looking-at-type-like.

Re: On syntax decoration of identifiers containing underscore and statements word [f90]

[Angelo Graziosi]

Ciao Stefan,

Il 17/05/2013 2.37, Stefan Monnier ha scritto:
>> I noticed that in f90-mode, identifiers of variables like
> [...]
>> are all in black. Shouldn't they be all in black?
>
> Indeed.  I installed the patch below which should fix those problems.
>

It works very well! Thanks..

..but I have to flag another little issue..

In the code

   public ExitProcess
   interface
      subroutine ExitProcess(uExitCode) bind(C,name='ExitProcess')
        import
        !GCC$ ATTRIBUTES STDCALL :: ExitProcess
        integer(UINT_T), intent(in), value :: uExitCode
      end subroutine ExitProcess
   end interface

the identifier "ExitProcess" after "public" (first line) has: "Exit" in 
magenta and "Process" in cyan. Shouldn't it be all in 
black?("ExitProcess" after "subroutine" is all in blue as expected)


Sorry if I flag this a piece at the time, but only when I notice that I 
can flag... :(


Ciao,
  Angelo.

bug#14442: On syntax decoration of identifiers containing underscore and statements word [f90]

[Stefan Monnier]

> ..but I have to flag another little issue..

Please report these as bug (i.e. via report-emacs-bug or to
bug-gnu-emacs@gnu.org).

> In the code

>   public ExitProcess
>   interface
>      subroutine ExitProcess(uExitCode) bind(C,name='ExitProcess')
>        import
>        !GCC$ ATTRIBUTES STDCALL :: ExitProcess
>        integer(UINT_T), intent(in), value :: uExitCode
>      end subroutine ExitProcess
>   end interface

> the identifier "ExitProcess" after "public" (first line) has: "Exit" in
> magenta and "Process" in cyan. Shouldn't it be all in black?("ExitProcess"
> after "subroutine" is all in blue as expected)

At least this problem was not introduced by my recent change.  It was
already present in Emacs-24.2 (among other versions).

The patch below seems to fix it, but I don't know enough the rules of
Fortran syntax to be sure it's the right thing to do.  There are
probably other cases, by the way (the patch below also fixes one other
case for "implicitreal").


        Stefan


=== modified file 'lisp/progmodes/f90.el'
--- lisp/progmodes/f90.el	2013-05-17 00:36:33 +0000
+++ lisp/progmodes/f90.el	2013-05-22 22:16:01 +0000
@@ -641,16 +641,16 @@
 forall\\|block\\|critical\\)\\)\\_>"
       (2 font-lock-constant-face nil t) (3 font-lock-keyword-face))
     ;; Implicit declaration.
-    '("\\_<\\(implicit\\)[ \t]*\\(real\\|integer\\|c\\(haracter\\|omplex\\)\
+    '("\\_<\\(implicit\\)[ \t]+\\(real\\|integer\\|c\\(haracter\\|omplex\\)\
 \\|enumerator\\|procedure\\|\
 logical\\|double[ \t]*precision\\|type[ \t]*(\\(?:\\sw\\|\\s_\\)+)\\|none\\)[ \t]*"
       (1 font-lock-keyword-face) (2 font-lock-type-face))
-    '("\\_<\\(namelist\\|common\\)[ \t]*\/\\(\\(?:\\sw\\|\\s_\\)+\\)?\/"
+    '("\\_<\\(namelist\\|common\\)[ \t]*/\\(\\(?:\\sw\\|\\s_\\)+\\)?\/"
       (1 font-lock-keyword-face) (2 font-lock-constant-face nil t))
     "\\_<else\\([ \t]*if\\|where\\)?\\_>"
     '("\\(&\\)[ \t]*\\(!\\|$\\)"  (1 font-lock-keyword-face))
     "\\_<\\(then\\|continue\\|format\\|include\\|stop\\|return\\)\\_>"
-    '("\\_<\\(exit\\|cycle\\)[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)?\\_>"
+    '("\\_<\\(exit\\|cycle\\)[ \t]+\\(\\(?:\\sw\\|\\s_\\)+\\)?\\_>"
       (1 font-lock-keyword-face) (2 font-lock-constant-face nil t))
     '("\\_<\\(case\\)[ \t]*\\(default\\|(\\)" . 1)
     ;; F2003 "class default".

bug#14442: On syntax decoration of identifiers containing underscore and statements word [f90]

[Angelo Graziosi]

Ciao Stefan,

Il 23/05/2013 0.20, Stefan Monnier ha scritto:
>
> The patch below seems to fix it, but I don't know enough the rules of

yes, it fixes that issue.. Thanks!

> Fortran syntax to be sure it's the right thing to do.  There are
> probably other cases, by the way (the patch below also fixes one other

I Think it is almost impossible to fix all the corner cases that may 
come to mind. Example:

program foo
   implicit none
   integer :: if
   if = 5
   print *, if
end program foo

At line 4, "if" is in magenta as for the IF statement but, being a 
variable, it should be black (at lines 3 and 5 the "if" decoration is 
right: say brown (3) and black (5))


Anyway, many thanks... :)


Ciao,
  Angelo.

bug#14442: On syntax decoration of identifiers containing underscore and statements word [f90]

[Glenn Morris]

Stefan Monnier wrote:

> At least this problem was not introduced by my recent change.  It was
> already present in Emacs-24.2 (among other versions).

No, it is extremely long-standing behaviour that I am in no hurry to
change. ( Like the syntax thing. :) )

> The patch below seems to fix it, but I don't know enough the rules of
> Fortran syntax to be sure it's the right thing to do.

Indeed there are some cases where spaces are optional (eg "else if" ==
"elseif"), and some where they are not. This is probably why there are
lots of "[ \t]*" in f90.el.

> -    '("\\_<\\(implicit\\)[ \t]*\\(real\\|integer\\|c\\(haracter\\|omplex\\)\
> +    '("\\_<\\(implicit\\)[ \t]+\\(real\\|integer\\|c\\(haracter\\|omplex\\)\

Probably correct, since I think the space is required in this case.

> -    '("\\_<\\(namelist\\|common\\)[ \t]*\/\\(\\(?:\\sw\\|\\s_\\)+\\)?\/"
> +    '("\\_<\\(namelist\\|common\\)[ \t]*/\\(\\(?:\\sw\\|\\s_\\)+\\)?\/"

Unrelated cosmetic change? You missed the final "\/" BTW.

> -    '("\\_<\\(exit\\|cycle\\)[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)?\\_>"
> +    '("\\_<\\(exit\\|cycle\\)[ \t]+\\(\\(?:\\sw\\|\\s_\\)+\\)?\\_>"

Breaks highlighting of plain "exit" (the following label is optional).

bug#14442: On syntax decoration of identifiers containing underscore and statements word [f90]

[Stefan Monnier]

>> -    '("\\_<\\(exit\\|cycle\\)[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)?\\_>"
>> +    '("\\_<\\(exit\\|cycle\\)[ \t]+\\(\\(?:\\sw\\|\\s_\\)+\\)?\\_>"
> Breaks highlighting of plain "exit" (the following label is optional).

Obviously, I'm out of my depth, so I'll let you take it from there,


        Stefan

bug#14442: On syntax decoration of identifiers containing underscore and statements word [f90]

[Angelo Graziosi]

Il 23/05/2013 1.48, Angelo Graziosi ha scritto:
> Ciao Stefan,
>
> Il 23/05/2013 0.20, Stefan Monnier ha scritto:
>>
>> The patch below seems to fix it, but I don't know enough the rules of
>
> yes, it fixes that issue.. Thanks!

As noticed by Glenn, now "cycle" and "exit" statements are in black... 
The fix looks worse than the "bug"... ;-)

We can stay with a two-tone "ExitProcess"... :-)


Ciao,
  Angelo.

bug#14442: On syntax decoration of identifiers containing underscore and statements word [f90]

[Lars Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

>> -    '("\\_<\\(implicit\\)[ \t]*\\(real\\|integer\\|c\\(haracter\\|omplex\\)\
>> +    '("\\_<\\(implicit\\)[ \t]+\\(real\\|integer\\|c\\(haracter\\|omplex\\)\
>
> Probably correct, since I think the space is required in this case.

I've now done this change in Emacs 29.

>> -    '("\\_<\\(exit\\|cycle\\)[ \t]*\\(\\(?:\\sw\\|\\s_\\)+\\)?\\_>"
>> +    '("\\_<\\(exit\\|cycle\\)[ \t]+\\(\\(?:\\sw\\|\\s_\\)+\\)?\\_>"
>
> Breaks highlighting of plain "exit" (the following label is optional).

And I've fixed this by making it into two cases.  My test case (included
below) now highlights both exits correctly, and doesn't highlight
"public ExitProcess".

public ExitProcess
interface
   subroutine ExitProcess(uExitCode) bind(C,name='ExitProcess')
     import
     !GCC$ ATTRIBUTES STDCALL :: ExitProcess
     integer(UINT_T), intent(in), value :: uExitCode
   end subroutine ExitProcess
end interface

do 100 i=1,1000
      xarray(i)=indata(i)*a
      k = k+1
      if (xarray(i).eq.0.or.k.eq.kmax) then 
         exit
      else if (i.gt.1)
         results(i)=xarray(i)+xarray(i-1)
         exit foo
      else
         results(i)=xarray(i)
      end if   
100 continue
    if (i.lt.1000) print *, 'Exited loop early'


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no