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-gn...@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".

[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.

[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).

[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

[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.