ffes / nppfilesettings

GNU General Public License v2.0
0 stars 0 forks source link

[FEATURE REQUEST] add "coding/encoding" property from modeline #1

Open pryrt opened 2 years ago

pryrt commented 2 years ago

As I mentioned in the EditorConfig issue, it would be nice to have a plugin for Notepad++ that would support various modeline styles for setting the file encoding.

The example I used there was -*- encoding: "IBM850" -*- and # encoding=ibm850. Those were the examples I used, because those are the ones I've mostly seen in Python scripts, though PEP 263 allows the vim-style modelines as well.

If the NppFileSettings plugin were to add the encoding modeline (especially if it handled multiple of the modeline syntaxes) and be published, then I would start using it myself, and would recommend it in conversations like this one

(Sorry for spamming the EditorConfig issue. I wasn't sure where such functionality would be best implemented: but yes, this plugin seems a better fit for the modeline charset parsing. ;-) Thanks for the redirect.)

ffes commented 2 years ago

Thanks for adding the additional information here about PEP 263. I am not a Python dev myself, so I was not aware of that. The # encoding notation is not Emacs or vim but a specific PEP 263 feature. It should not be to difficult to add that though.

But I will first release the plugin in its current state, add it to the npp plugin admin.

Once that is done I will try and see if I can get the encoding to work, first for vim notation because that is already there. After that I can see if I can add the Emacs and PEP 263 notation.

ffes commented 10 months ago

I am busy adding support for the encoding for vim modelines, since modelines are already supported by the plugin. See b3e4e2b1a8eda7f7411e85fd9a50f3a7fc555915. I hope to release that any time soon.

Before I invest time in adding support for Emacs File Variables and PEP 263 I did some research and found this: https://sourceforge.net/p/docutils/patches/194/ It seems to me docutils have removed PEP 263 support because it was a Python 2 thing and Python 3 should always use utf-8. Any comments on that?

Another thing is that there is no list of supported encoding mentioned in PEP 263, so I have no idea what the common used encodings are these days if I were to support that.

I have no problem adding basic Emacs support, but I have absolutely no experience with Emacs. I find the docs of Emacs very confusing. Every time I think I found something it shows a lot of LISP code that needs to be added somewhere to get things done. So I need some experienced Emacs user to explain Emacs File Variables a bit better.

pryrt commented 10 months ago

docutils have removed PEP 263 support because it was a Python 2 thing

Well, most of my Python coding is for Notepad++'s PythonScript plugin, and that plugin still distributes with Python 2.7. Thus, all my scripts PEP-263 type of modeline, so I personally would like it in there. But I understand Python 2.7 has been not-recommended for years, so I won't complain if you choose to ignore the PEP-263-specific nomenclature. (If it doesn't get supported, I'll probably switch to the vim-style # vim: set fileencoding= syntax until PythonScript releases a non-alpha Python 3.x version).

I have no idea what the common used encodings are these days if I were to support that.

I like the idea of including the iso-8859-n and cpnnnn listed in the vim docs that you had in your commit... but I actually doubt most people use those encoding-lines in Python or any other modern language. If doing a regex to extract iso-8859-(\d{1,2}) or cp(\d{3,4}) isn't easy to implement, the four you already listed in that commit are reasonably sufficient.

I have absolutely no experience with Emacs

Nor do I. Probably they support at least the ones in that vim-based list, so whatever subset of those you implement should also work for editing most files that used Emacs modelines.

ffes commented 10 months ago

I see what you mean with PEP 263.

Know that in vim modelines there is a difference between fileencoding what was added recently and encoding which isn't there.

The former adjusts the way a file is actually saved. It uses the N++ builtin menu commands in the Encoding menu that start with Convert to to get the job done.

The latter I will not support, because the vim docs clearly states:

This option cannot be set from a |modeline|. It would most likely corrupt the text.

If you want to test the current master branch (with fileencoding support) you can download the dll from the GitHub Actions Artifact. Simply replace the existing one with the new. I want to release this any time soon.

Also know that I opened #3 and #4 to add support for the other formats.