Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix loading the default open encoding option #1326

Merged
merged 1 commit into from Apr 14, 2019

Conversation

Projects
None yet
3 participants
@b4n
Copy link
Member

commented Nov 28, 2016

This got broken by 907a792 back in 2011 as encoding names started to be compared more permissively, leading to "none" matching the "None" encoding.

This shouldn't be too much of a problem as trying the None encoding first should not cause any issue, but fix loading of the option anyway.

This however won't restore settings from existing configuration files that used the previous code, as there is no way to tell whether the user selected the None encoding voluntarily or not.


To reproduce the issue, go to the file preferences, and deactivate the Use fixed encoding when opening non-Unicode files. Save the setting, and restart Geany: you'll see the setting is activated again.

Fix loading the default open encoding option
This got broken by 907a792 back in
2011 as encoding names started to be compared more permissively,
leading to "none" matching the "None" encoding.

This shouldn't be too much of a problem as trying the None encoding
first should not cause any issue, but fix loading of the option anyway.

This however won't restore settings from existing configuration files
that used the previous code, as there is no way to tell whether the
user selected the None encoding voluntarily or not.

@b4n b4n added this to the 1.30 milestone Nov 28, 2016

@elextr

This comment has been minimized.

Copy link
Member

commented Nov 28, 2016

LGBI

@eht16

This comment has been minimized.

Copy link
Member

commented Dec 4, 2016

Looks good after testing (I forgot @elextr fancy abbreviations 😄 )

@elextr

This comment has been minimized.

Copy link
Member

commented Dec 4, 2016

@b4n, not sure, but I think this is affected by the problem I raised on IRC, the encoding used to load a file, and which will therefore be stored in prefs, might not be one in our list of encodings, so encodings_get_from_charset() will give null. Have I missed somewhere in the spaghetti that is encodings where the saved string is used for loading the file?

@elextr

This comment has been minimized.

Copy link
Member

commented Feb 23, 2017

Unresolved questions, moved to 1.31

@elextr elextr modified the milestones: 1.31, 1.30 Feb 23, 2017

@b4n b4n modified the milestones: 1.31, 1.34, 1.35 Dec 9, 2018

@b4n

This comment has been minimized.

Copy link
Member Author

commented Apr 14, 2019

@elextr I'm not 100% sure but I can't see how an encoding outside our list can end up here, it's not like we detect it with a regex. So I don't think it's a problem, and if there is one indeed it's a separate issue and this still fixes the problem at hand and doesn't introduce a new one. So, feel free to report a separate bug if needed.

@b4n b4n merged commit 405f772 into geany:master Apr 14, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

b4n added a commit that referenced this pull request Apr 14, 2019

Merge pull request #1326 from b4n/default-open-enc
Fix loading the default open encoding option
@elextr

This comment has been minimized.

Copy link
Member

commented Apr 14, 2019

@b4n, can't remember, that was years ago, as I said above LGBI so I will take your word for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.