CI: fixing the files to be complient with pre-commit hooks

components/esp_modem/docs/Doxyfile

@@ -2522,4 +2522,3 @@ DOT_CLEANUP            = YES
 #DOT_GRAPH_MAX_NODES  = 100
 #MAX_DOT_GRAPH_DEPTH  = 0
 #DOT_TRANSPARENT      = YES
-

components/esp_modem/docs/README.md

@@ -1,14 +1,14 @@
 # ESP MODEM
 
 This component is used to communicate with modems in the command mode (using AT commands), as well as the data mode
-(over PPPoS protocol). 
+(over PPPoS protocol).
 The modem device is modeled with a DCE (Data Communication Equipment) object, which is composed of:
 * DTE (Data Terminal Equipment), which abstracts the terminal (currently only UART implemented).
 * PPP Netif representing a network interface communicating with the DTE using PPP protocol.
 * Module abstracting the specific device model and its commands.
 
 ```
-   +-----+   
+   +-----+
    | DTE |--+
    +-----+  |   +-------+
             +-->|   DCE |
@@ -16,17 +16,17 @@ The modem device is modeled with a DCE (Data Communication Equipment) object, wh
    | Module|--->|       |
    +-------+    |       |o--- send_commands
              +->|       |
-   +------+  |  +-------+ 
-   | PPP  |--+ 
+   +------+  |  +-------+
+   | PPP  |--+
    | netif|------------------> network events
-   +------+ 
+   +------+
 ```
 
 ## Modem components
 ### DCE
 
 This is the basic operational unit of the esp_modem component, abstracting a specific module in software,
-which is basically configured by 
+which is basically configured by
 * the I/O communication media (UART), defined by the DTE configuration
 * the specific command library supported by the device model, defined with the module type
 * network interface configuration (PPPoS config in lwip)
@@ -52,7 +52,7 @@ Users interact with the esp-modem using the DCE's interface, to basically
 * Switch between command and data mode to connect to the internet via cellular network.
 * Send various commands to the device (e.g. send SMS)
 
-The applications typically register handlers for network events to receive notification on the network availability and 
+The applications typically register handlers for network events to receive notification on the network availability and
 IP address changes.
 
 Common use cases of the esp-modem are also listed as the examples:

components/esp_modem/docs/advanced_api.rst

@@ -46,4 +46,3 @@ a custom DTE object and supply it into :ref:`the DCE factory<dce_factory>`. The
 - Create the DTE which uses the custom Terminal
 
 Please refer to the implementation of the existing UART DTE.
-

components/esp_modem/docs/api_docs.rst

@@ -6,7 +6,7 @@ C API Documentation
 
 The C API is very simple and consist of these two basic parts:
 
-- :ref:`lifecycle_api` 
+- :ref:`lifecycle_api`
 - :ref:`modem_commands`
 
 The Typical application workflow is to:
@@ -54,4 +54,4 @@ Configuration structures
 
 
 .. doxygengroup:: ESP_MODEM_CONFIG
-   :members:
+   :members:

components/esp_modem/docs/conf.py

@@ -2,11 +2,6 @@
 #
 # English Language RTD & Sphinx config file
 #
-import os
-import os.path
-import re
-import subprocess
-import sys
 
 # General information about the project.
 project = u'esp-modem'
@@ -18,11 +13,12 @@ language = 'en'
 
 extensions = ['breathe', 'recommonmark']
 
-
 breathe_projects = {'esp_modem': 'xml'}
 
-breathe_default_project = "esp_modem"
+breathe_default_project = 'esp_modem'
 
 source_suffix = ['.rst', '.md']
 
-source_parsers = {'.md': 'recommonmark.parser.CommonMarkParser', }
+source_parsers = {
+    '.md': 'recommonmark.parser.CommonMarkParser',
+}

components/esp_modem/docs/cxx_api_docs.rst

@@ -41,4 +41,4 @@ Destroy the DCE
 ---------------
 
 The DCE object is created as ``std::unique_ptr`` by default and as such doesn't have to be explicitly destroyed.
-It simply gets destroyed and cleaned-up automatically if the object goes out of the block scope.
+It simply gets destroyed and cleaned-up automatically if the object goes out of the block scope.

components/esp_modem/docs/internal_design.md

@@ -5,16 +5,16 @@
 * Use C++ with additional C API
 
 * Use exceptions
-  - Use macro wrapper over `try-catch` blocks when exceptions off (use `abort()` if `THROW()`) 
+  - Use macro wrapper over `try-catch` blocks when exceptions off (use `abort()` if `THROW()`)
 
 * Initializes and allocates in the constructor (might throw)
   - easier code with exceptions ON, with exceptions OFF alloc/init failures are not treated as runtime error (program aborts)
   - break down long initialization in constructor into more private methods
 
 * Implements different devices using inheritance from `GenericModule`, which is the most general implementation of a common modem
-  - Internally uses templates with device specialization (modeled as `DCE<SpecificModule>`) which could be used as well for some special cases, 
+  - Internally uses templates with device specialization (modeled as `DCE<SpecificModule>`) which could be used as well for some special cases,
   such as implantation of a minimal device (ModuleIf), add new AT commands (oOnly in compile time), or using the Module with DTE only (no DCE, no Netif) for sending AT commands without network
-  
+
 ## DCE collaboration model
 
 The diagram describes how the DCE class collaborates with DTE, PPP and the device abstraction

components/esp_modem/docs/internal_docs.rst

@@ -115,8 +115,3 @@ Modem types
 
 .. doxygengroup:: ESP_MODEM_TYPES
    :members:
-
-
-
-
-