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

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