fix highlight issue (#495)

Co-authored-by: Federico Perini <[email protected]>

Author: LXYan2333

source/conf.py

@@ -213,3 +213,5 @@
 post_auto_excerpt = 2
 
 gettext_compact = "index"
+
+copybutton_exclude = '.linenos, .gp, .go'

source/learn/building_programs/compiling_source.md

@@ -28,7 +28,7 @@ the GNU compiler collection. To compile a simple program like the one
 above, that consists of one source file, you run the following command,
 assuming the source code is stored in the file "hello.f90":
 
-```shell
+```console
 $ gfortran -c hello.f90
 ```
 
@@ -40,7 +40,7 @@ leave it out, then the default action of the compiler is to compile the
 source file and start the linker to build the actual executable program.
 The command:
 
-```shell
+```console
 $ gfortran hello.f90
 ```
 
@@ -55,7 +55,7 @@ Some remarks:
   not get an object file or an executable program. For instance, if
   the word "program" was inadvertently typed as "prgoram":
 
-```shell
+```console
 $ gfortran hello3.f90
 hello.f90:1:0:
 
@@ -78,7 +78,7 @@ again.
   Otherwise the link step will complain about a missing "symbol", something
   along these lines:
 
-```shell
+```console
 $ gfortran hello2.f90
 /usr/lib/../lib64/crt1.o: In function `_start':
 (.text+0x20): undefined reference to `main'

source/learn/building_programs/distributing.md

@@ -75,13 +75,13 @@ end module user_functions
 
 - Provide a basic build script with a command like:
 
-```shell
+```console
 gfortran -o functions.dll functions.f90 -shared
 ```
 
 or:
 
-```shell
+```console
 ifort -exe:functions.dll functions.f90 -dll
 ```
 

source/learn/building_programs/include_files.md

@@ -35,7 +35,7 @@ tabulate/
 
 Compiling the file "functions.f90" with the commands
 
-```shell
+```console
 $ cd sub
 $ gfortran -c functions.f90
 ```
@@ -55,7 +55,7 @@ tabulate/
 To successfully compile and subsequently build the program we need to
 tell the compiler where it can find the file "user_functions.mod":
 
-```shell
+```console
 $ cd main
 $ gfortran -c tabulate.f90 -I ../sub
 $ gfortran -o tabulate tabulate.o ../sub/functions.o

source/learn/building_programs/linking_pieces.md

@@ -55,7 +55,7 @@ program. Because the program "tabulate" depends on the module
 "function", we need to compile the source file containing our module
 first. A sequence of commands to do this is:
 
-```shell
+```console
 $ gfortran -c functions.f90
 $ gfortran tabulate.f90 functions.o
 ```

source/learn/building_programs/managing_libraries.md

@@ -9,7 +9,7 @@ create your own libraries.
 Libraries contain any number of object files in a compact form, so that
 the command-line becomes far shorter:
 
-```shell
+```console
 $ gfortran -o tabulate tabulate.f90 functions.o supportlib.a
 ```
 
@@ -20,7 +20,7 @@ Linux and Linux-like platforms. On Windows the extension ".lib" is used.
 Creating your own libraries is not that complicated:
 on Linux, you can achieve this using a utility like `ar`:
 
-```shell
+```console
 $ gfortran -c file1.f90 file2.f90
 $ gfortran -c file3.f90 ...
 $ ar r supportlib.a file1.o file2.o
@@ -29,7 +29,7 @@ $ ar r supportlib.a file3.o ...
 
 or on Windows using the `lib` utility:
 
-```shell
+```console
 c:\...> ifort -c file1.f90 file2.f90
 c:\...> ifort -c file3.f90 ...
 c:\...> lib /out:supportlib.lib file1.obj file2.obj
@@ -75,15 +75,15 @@ like `ar` or `lib`.
 
 On Linux:
 
-```shell
+```console
 $ gfortran -fpic -c file1.f90 file2.f90
 $ gfortran -fpic -c file3.f90 ...
 $ gfortran -shared -o supportlib.so file1.o file2.o file3.o ...
 ```
 
 On Windows, with the Intel Fortran compiler:
 
-```shell
+```console
 $ ifort -c file1.f90 file2.f90
 $ ifort -c file3.f90 ...
 $ ifort -dll -exe:supportlib.dll file1.obj file2.obj file3.obj ...
@@ -136,14 +136,14 @@ Also, no import library is generated.
 Since our dynamic library can be built from a single source file, we
 can take a shortcut:
 
-```shell
+```console
 $ gfortran -shared -o functions.dll functions.f90
 ```
 
 This produces the files "functions.dll" and "user_functions.mod". The
 utility `nm` tells us the exact name of the function `f`:
 
-```shell
+```console
 $ nm functions.dll
 ...
 000000054f9d7000 B __dynamically_loaded
@@ -160,7 +160,7 @@ other routine "f" that might be defined in another module.
 
 The next step is to build the program:
 
-```shell
+```console
 $ gfortran -o tabulate tabulate.f90 functions.dll
 ```
 
@@ -189,7 +189,7 @@ real function f( x )
 
 Again we take a shortcut:
 
-```shell
+```console
 $ ifort -exe:functions.dll functions.f90 -dll
 ```
 

source/learn/building_programs/runtime_libraries.md

@@ -4,7 +4,7 @@ To illustrate that even a simple program depends on external run-time
 libraries, here is the output from the `ldd` utility that reports such
 dependencies:
 
-```shell
+```console
 $ ldd tabulate.exe
         ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff88f2b0000)
         KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ff88e450000)

source/learn/quickstart/gotchas.md

@@ -8,7 +8,7 @@ All code snippets are compiled with gfortran 13.
 Implicit typing
 ---------------
 
-```
+```{play-code-block} fortran
 program foo
     integer :: nbofchildrenperwoman, nbofchildren, nbofwomen
     nbofwomen = 10
@@ -25,7 +25,7 @@ Wait... Fortran is unable to multiply two integer numbers?? Of course not... The
 
 Implicit typing is as old as Fortran, in times where there was no explicit typing. Although it can still be convenient for quickly writing some test code, this practice is highly error prone and is discouraged. The strongly recommended good practice is to always disable implicit typing by stating `implicit none` (introduced in Fortran 90) at the beginning of all program units (main program, modules, and standalone routines):
 
-```
+```{play-code-block} fortran
 program foo
 implicit none
     integer :: nbofchildrenperwoman, nbofchildren, nbofwomen
@@ -45,7 +45,7 @@ Error: Symbol 'nbofchildrem' at (1) has no IMPLICIT type; did you mean 'nbofchil
 Implied save
 ------------
 
-```
+```{play-code-block} fortran
 subroutine foo()
 implicit none
     integer :: c=0
@@ -64,7 +64,7 @@ implicit none
 end program
 ```
 People used to C/C++ expect this program to print 5 times `1`, because they interpret `integer :: c=0` as the concatenation of a declaration and an assignment, as if it was:
-```
+```fortran
 integer :: c
 c = 0
 ```
@@ -77,19 +77,19 @@ c = 0
 5
 ```
 `integer :: c=0` is actually a one-shot **compile time initialization**, and it makes the variable persistent between calls to `foo()`. It is actually equivalent to: 
-```
+```fortran
 integer, save :: c=0   ! "save" can be omitted, but it's clearer with it
 ```
 The `save` attribute is equivalent to the C `static` attribute used inside a function to make a variable persistent, and it is *implied* in the case the variable is initialized. This is a modernized syntax (introduced in Fortran 90) compared to the legacy (and still valid) syntax:
-```
+```fortran
 integer c
 data c /0/
 save c
 ```
 Old fortraners just know that the modernized syntax is equivalent to the legacy one, even when `save` is not specified. But as a matter of fact the *implied save* can be misleading to newcomers who are used to the C logic. That's why it is generally recommended to **always** specify the `save` attribute.
 
 *Note: an initialization expression of a derived type component is a fully different case:*
-```
+```fortran
 type bar
     integer :: c = 0
 end type
@@ -101,7 +101,7 @@ Floating point literal constants
 ---------------------------------
 
 The following code snippet defines a double precision constant `x` (which is on most systems a IEEE754 64 bits floating point, with 15 significant digits):
-```
+```{play-code-block} fortran
 program foo
 implicit none
     integer, parameter :: dp = kind(0d0)
@@ -116,7 +116,7 @@ The output is:
 So, `x` has 15 significant digits as expected, and still the printed value is wrong from the 8th digit. The reason is that floating point literal constants have implicitely the default real kind, wich is usually the IEEE754 single precision floating point (with about 7 significant digits). The real number $9.3$ has no exact floating point representation, so it is first approximated to single precision up to the 7th digit, then casted to double precision before being assigned to `x`. But the previously lost digits are obviously not recovered.
 
 The solution is to explicitly specify the kind of the constant: 
-```
+```fortran
 real(kind=dp), parameter :: x = 9.3_dp
 ```
 And now the output is correct up to the 15th digit:
@@ -128,7 +128,7 @@ Floating point literal constants (again)
 ---------------------------------
 
 Suppose now you need a floating point constant that is 1/3 (one-third). You may write:
-```
+```{play-code-block} fortran
 program foo
 implicit none
     integer, parameter :: dp = kind(0d0)
@@ -143,7 +143,7 @@ Then the output is (!):
 The reason is that `1_dp` and `3_dp` are **integer** literal constants, despite the `_dp` suffix that is *supposed* to represent a floating point kind. Consequently the division is the integer division, with 0 as a result. The gotcha here is that the standard allows compilers to use identical kind values for `REAL` and `INTEGER` types. For instance with gfortran, on most platforms the value $8$ is both the double precision kind AND the 64 bits integer kind, so that `1_dp` is a fully valid integer constant. In constrast, the NAG compiler uses by default unique kind values, such that in the example above `1_dp` would produce a compilation error.
 
 The right way to denote floating point constants is to **always** include the point: 
-```
+```fortran
     real(dp), parameter :: onethird = 1.0_dp / 3.0_dp
 ```
 Then the ouput is:
@@ -154,23 +154,23 @@ Then the ouput is:
 Leading space in prints
 -----------------------
 
-```
+```{play-code-block} fortran
 program foo
 implicit none
     print*, "Hello world!"
 end program
 ```
 Ouput:
-```
+```console
 % gfortran hello.f90 && ./a.out
  Hello world!
 ```
 Note the extra leading space, which is not present in the string of the source code. Historically, the first character was containing a [carriage control code](https://en.wikipedia.org/wiki/ASA_carriage_control_characters) for the early printers, and it was not printed per se. The space " " was instructing the printer to perform a CR+LF sequence before printing the content, and was automatically prepended by the Fortran `print*` statement. Some compilers still do that, although the modern output devices do neither intercept nor use the control character, which is hence "printed". If this leading blank is a problem (it rarely is), then instead of the `*` (which means "let the compiler decide how to format the output") we can code an explicit format:
-```
+```fortran
     print "(A)", "Hello world!"
 ```
 In this case, the compiler does no longer prepend the leading space:
-```
+```console
 % gfortran hello.f90 && ./a.out
 Hello world!
 ```
@@ -179,7 +179,7 @@ Filename extension
 ------------------
 
 Suppose we put the above "Hello world" program in the source file `hello.f`. Most compilers will produce many compilation errors:
-```
+```console
 % gfortran hello.f
 hello.f:1:1:
 

source/learn/quickstart/hello_world.md

@@ -22,7 +22,7 @@ On Windows, you can get native binaries [here](http://www.equation.com/servlet/e
 
 To check if you have _gfortran_ setup correctly, open a terminal and run the following command:
 
-```shell
+```console
 $> gfortran --version
 ```
 
@@ -48,7 +48,7 @@ end program hello
 
 Having saved your program to `hello.f90`, compile at the command line with:
 
-```shell
+```console
 $> gfortran hello.f90 -o hello
 ```
 
@@ -57,7 +57,7 @@ $> gfortran hello.f90 -o hello
 
 To run your compiled program:
 
-```shell
+```console
 $> ./hello
 Hello, World!
 ```

source/learn/quickstart/organising_code.md

@@ -176,7 +176,7 @@ use my_mod, only: printMat=>print_matrix
 
 An advantage of placing subroutines and functions in modules is that they can have ```optional``` arguments. In a procedure with an argument declared optional, the ```present``` function is used to test if the argument was set in the caller. Optional arguments that are not present may not be accessed within the procedure. Here is a generalization of the ```vector_norm``` function that can use powers other than 2 to compute the Lp norm.
 
-```
+```{play-code-block} fortran
 module norm_mod
   implicit none
   contains