This FR is quite similar to bug #19970. I'm testing a fix at the moment, if it fails to read the preferences it falls back to the default settings and overwrites the broken preferences upon exit.

I personally feel GUI feedback is overkill so I won't add that, I leave it to you to decide whether my fix is enough or whether you want to keep the FR open for the dialogue.

When Wesnoth hits a WML parser error when reading the main preferences file, it will instantly quit without any visual indication. The most that it will do in this case is printing the parser error in stderr with the affected file referred to as "<unknown>".

This is a rather severe usability problem that has affected every version I can recall. Ideally, there should be no way for Wesnoth to corrupt its preferences file, but this can not only happen accidentally (filesystem failure, etc.), but also deliberately, such as by entering the command :alias =foo=bar in the in-game command line.

To solve it I would propose ignoring the preferences file every time it exists and can't be read, and warning the user with an in-game notification via GUI dialog with an option to discard the corrupted preferences file and overwrite it, as well as pointers to solve the issue without discarding it.

Since this is not so much a bug as it is missing functionality (a sane fallback and notification in case the preferences file cannot be parsed), I have submitted it as a feature request.

(If nobody wants to try solving this before 1.11.4 or so, I may look into it myself.)

Steps to reproduce:

- Open the preferences file, and insert a '=' character at the beginning so that the first line reads like this:

- Try starting Wesnoth. stderr should look like this:
Battle for Wesnoth v1.11.1+svn (55849) Started on Thu Dec 13 22:13:22 2012 Automatically found a possible data directory at /home/shadowm/src/wesnoth Unexpected characters at line start, value '=' at <unknown>:1