<commit_before># Error Message Concept

The purpose of this file is solely to better comment on in a Pull Request and gather feedback.

## Findings/ Motivation

1. Too many errors in the [specification](src\error\specification) (210 errors/warnings)
2. Many duplicate or redundant errors
3. Description/ Reason are very similar
4. Potential file splitting (1327 LOC)

## Some facts

1. Some errors have the same text but are duplicated because one is `warning` and the other one is `error`/`fatal` 
(#153 + #154, #128 + #129, #120 + #41, #44 + 45 , #66 + #67, etc.)
2. Some errors might be duplicated just because they belong to different plugins (or the dev neglected to lookup a similar in the specification) 
(#29 + #57 + #72 + #169, #10 + #61, etc.)
3. Many errors are very similar or could be summarized and are differentiated via the reason field 
(#54 + #55, #31 - #33, #93 + #7 + #17, #74 + #75, #77 + #10 + #61, etc.)
4. Some errors are marked as unused (#22 + #48 + #58 + #66 + #67 + #68)<commit_msg>error: some work<commit_after># Error Message Concept

The purpose of this file is solely to better comment on in a Pull Request and gather feedback.

## Findings/ Motivation

1. Too many errors in the [specification](src\error\specification) (210 errors/warnings)
2. Many duplicate or redundant errors
3. Description/ Reason are very similar
4. Potential file splitting (1327 LOC)

## Some facts

1. Some errors have the same text but are duplicated because one is `warning` and the other one is `error`/`fatal` 
(#153 + #154, #128 + #129, #120 + #41, #44 + 45 , #66 + #67, etc.)
2. Some errors might be duplicated just because they belong to different plugins (or the dev neglected to lookup a similar in the specification) 
(#29 + #57 + #72 + #169, #10 + #61, etc.)
3. Many errors are very similar or could be summarized and are differentiated via the reason field 
(#54 + #55, #31 - #33, #93 + #7 + #17, #74 + #75, #77 + #10 + #61, etc.)
4. Some errors are marked as unused (#22 + #48 + #58 + #66 + #67 + #68)

## Some considerations

### Error/Warning/Fatal etc. splitting

I would suggest to remove this concept from the specification and let the developer use a respective method to indicate if it is a warning/error/etc.
The macros ELEKTRA_SET_ERROR, ELEKTRA_ADD_WARNING ... should be enough to make developers cautious of wrong method usage.
What I have seen is that the return code is the only matter if it is an error or not.
{'fraction_non_alphanumeric': 0.10220768601798855, 'fraction_numerical': 0.07195421095666395, 'mean_word_length': 3.8842315369261478, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5283961', 'n_tokens_mistral': 838, 'n_tokens_neox': 705, 'n_words': 382}