Another weird EOL question from me.

gstavi

One point to consider is that it is really a good idea for “file open” to keep the file unmodified.
So if someone is to consider such a feature it should be strongly “disabled by default” and only enabled by a very specific user request that “cannot be done by mistake”.
In general if you need such feature you will probably be happier with external tool for batch conversion rather than notepad++. Obviously a Linux bash command of find -name '*.reg' | xargs unix2dos jumps to mind.

Scott Sumner

@SalviaSage

Why not just adapt the Pythonscript code for line-ending handling that was “off-topic” in this thread for the current purpose?

Such a change should check the extension of the file being saved during the notification callback, and then act accordingly…in other words, if the extension is a “known type” (from your example, “.reg”) then override the default line-ending type, otherwise proceed with the default.

dinkumoil

@SalviaSage

I wrote a plugin that allows you to create file classes which are defined by related filename extensions. For every file class you can provide the EOL format to which should be converted to when the plugin detects that the active Notepad++ document is a member of this file class.

Files are not automatically saved after the EOL format has been converted by the plugin, you are always able to discard the changes by reloading the file.

The plugin can be downloaded here.

@gstavi

if someone is to consider such a feature it should be strongly “disabled by default” and only enabled by a very specific user request

This makes no sense, the only “specific user request” could be clicking on Edit (menu) -> EOL Conversion -> <One-of-the-EOL-formats>. This wouldn’t simplify anything.

chcg

@dinkumoil Is it ok for you to add AutoEOLFormat and CustomLineNumbers
Plugins to the PluginManager List?

dinkumoil

@chcg

Is it ok for you to add AutoEOLFormat and CustomLineNumbers Plugins to the PluginManager List?

Feel free to do that.

If you didn’t notice already: The XML control files for 32 bit plugin admin system are part of both repositories, have a look at the dictionaries _pluginmanager/Win32.

guy038

Hi, @dinkumoil, and All,

Just tested the 32 bits version of your plugin and its works fine. Just noticed a tiny bug, when entering parameters !

UPDATE : Seemingly, I was wrong about the sequence of operations ! Just see the next Dinkumoil post, to memorize the correct sequence ;-))

Apparently, the logical method, to enter the parameters, is :

Enter a name in the Group name field
Enter one ( or several ) extension(s), in the New filename extension(s) field
Choose the EOL format in the drop-down list

=> The left + button becomes active

Click on the left + to add this group, in the list, above

=> The right + button becomes active

Click on the right + to add this extension, in the list, above

However, I noticed that, if you select the EOL format, before filling characters, in the New filename extension(s) field, the left + button becomes, again, inactive, as soon as you enter an extension !. If so :

Enter all your extension(s) required, in the New filename extension(s) field, first
And, to get the left+ active, again, either :
- Re-select the EOL format, previously chosen
- Add any char, in the Group name field and delete it, immediately

Cheers,

guy038

dinkumoil

@guy038

If extensions are entered and there is no group selected in the left pane the GUI is in an inconsistent state. Instead of dealing with illegal user input my intention was to avoid illegal user input by blocking the GUI. And if you think about what a user can do with this tiny GUI (with groups: create, rename, change EOL format and delete incl. related extensions; with extension lists: create, extend and reduce) this is no trivial job.

The correct sequence for entering parameters is:

Enter a name in the Group name field.
Choose the EOL format in the drop-down list.
Save the group by clicking on the left + button.
Enter one (or several) extension(s), in the New filename extension(s) field.
Save the extension list by clicking on the right + button.

In short: At first define and save a group, then define and save its members.

But I will have a look on it if I have some spare time. Since I could reuse most of the code of my AutoCodepage plugin for the AutoEOLFormat plugin it was not time consuming to write it. In contrast, improving the GUI operations is a difficult and long lasting thing (as I know from writing the AutoCodepage plugin).

Scott Sumner

@gstavi said:

One point to consider is that it is really a good idea for “file open” to keep the file unmodified.

@dinkumoil

This makes no sense, the only “specific user request” could be clicking on Edit (menu) -> EOL Conversion -> <One-of-the-EOL-formats>. This wouldn’t simplify anything.

I think I understand @gstavi 's point with this. The user might be disconcerted if a file is modified simply by the act of opening it. Maybe a popup stating what happened in such a case? (@dinkumoil, I didn’t try your plugin, so I don’t actually know what happens in this case, with it; I’m just speaking in general). What should happen if the file opened is read-only (quiet failure? quiet success? popup?)

@dinkumoil , congratulations on the plugin. It looks like a nice solution.

dinkumoil

@Scott-Sumner

The plugin sends a message to Notepad++ to simulate a click on Edit (menu) -> EOL Conversion -> <One-of-the-EOL-formats>. Thus the behaviour of the plugin is determined by Notepad++.

If the file is write protected when it’s opened simply nothing happens (its tab icon is grey then). If it’s writeable the EOLs are converted if neccessary but the file is not saved, it remains in a “changed” state (its tab icon is red).

In my opinion the plugin’s usefulness would suffer if it wouldn’t convert the EOLs when opening a file. With the current behaviour one can virtually batch-convert a bunch of files by simply opening them with Notepad++ and then click on “Save all”.

The question is: What would be the benefit of the plugin without auto-converting EOLs when opening a file?

The plugin also converts EOLs after saving a file, it remains in a “changed” state then, too. I’m sure there are people which also don’t like this behaviour. But hey, it’s a plugin, nobody is forced to install it. ;-)

SalviaSage

@dinkumoil oh wow lol. you already made a plugin that can set the EOL of a file based on its file extension.

Special thanks!