If one tries to save a file with characters not belonging to chosen encoding, he gets
an error message:
Cannot save: java.io.CharConversionException: Failed to encode the character
Is it necessary to truncate the file at this moment? I switched off all backup helpers
because I think I can take care of my files myself and don't need an assist in this.
But it seems I need to protect my files from jEdit itself. Ok, jEdit is still being
developed, I understand. Ignore this remark if you intend to fix the issue I had.
When I had problems with saving mentioned file I decided to reloaded it. Oops. Maybe
a warning should appear when user tries to reload an empty file. It would be a good
assecuration for similar cases.
jEdit 4.4.1.
Steps to reproduce:
0. disable two-stage save, set max number of backups to 0 (in saving & backup opts)
1. create new file, choose buffer encoding us-ascii
2. type some characters, save
3. add an international character, like ą
4. try to save, see the file gets truncated
Submitted | jarekczek - 2011-08-11 - 08:30:50z | Assigned | k_satoda |
---|---|---|---|
Priority | 3 | Category | None |
Status | Open | Group | None |
Resolution | Invalid | Visibility | No |
2011-08-11 - 17:14:54z k_satoda |
> Is it necessary to truncate the file at this moment? It seems necessary under settings where two stage save and backup are both disabled. If you expect any other good bahavior, please describe it. > Maybe a warning should appear when user tries to reload an empty file. jEdit shows a warning when a dirty buffer is going to be reloeded. I think that warning is enough for this case because the buffer is kept dirty if a save request failed. |
---|---|
2011-08-13 - 07:00:08z k_satoda |
Pending, because nothing can be done without clarification of expected behavior. |
2011-08-14 - 08:55:32z jarekczek |
Clarifying: 1. truncating The file should not be truncated. The exception message is clear enough to understand the file could not be saved. So I expect the old version of file to remain. That's from user point of view. From programmers point of view I think the file should be checked against encoding problems before starting i/o operations. 2. warning on reload empty file If something wrong and unexpected happens there is an empty file on disk, while the user, say I, thinks the old version is kept. So if press "reload" I expect to get the old file version, not to loose the file completety. To prevent such unexpected accidents it would be enough to give just one warning that "you try to reload an empty file". I can't imagine a situation where user really wants to reload an empty file. It rather denotes a serious error happened and the warning seems necessary to me. |
2011-08-22 - 17:12:51z k_satoda |
Thank you for the clarification. > 1. truncating If you expect the old version to remain on failure, two-stage save is likely the best solution, isn't it? "Checking before I/O" maybe another solution, but it is suboptimal (doubles the cost of encoding operation on normal case), and possible on user side by a macro or a plugin. Thus, I don't want it as a core behavior. > 2. warning on reload empty file I think that such assumption "empty file indicates something wrong happened" is not so general that a text editor can assume. I can imagine some false positive if jEdit had such a warning. For example, reloading a job list, error list, etc which is likely empty as usual. I remember the following feature request, as a hopefully better solution for your problem. Undo "File reload" action http://sourceforge.net/support/tracker.php?aid=2879957 |
2011-08-24 - 08:49:05z jarekczek |
Let's go back to the roots. What I do is: 1. disable two-stage save, set max number of backups to 0 (in saving & backup opts) 2. open an important file using encoding us-ascii 3. add an international character, like ą 4. try to save 5. reload - get a warning, but I know the buffer is dirty, so I reload thinking I'm reloading the old version, but I get an empty file The result is I loose an important file. Because I did nothing silly a good editor should not destroy the file. The last answer to "File unload feature request", by shlomy, dated 2010-01-03, is negative to this idea. And I agree with it. Since no one replied to it, the idea is dead and won't be implemented. My solution to current problem is less expensive. No memory cost, and in worst case time cost of about 30% saving time (when a file is too big to fit in memory). If "Checking before I/O" is still in play, then it may be done conditionally. When two-stage save is disabled. The priority of this problem is not high (I changed it to 3), but I think the discussion should be finished with a reasonable solution. |
2011-08-24 - 15:16:39z k_satoda |
Now I propose another solution: Arrange "Cannot save" message so that it clearly shows the possibility of file truncation if two-stage save was disabled, and recommends two-stage save and/or backup options. I think this can prevent "reload thinking I'm reloading the old version" after the error was shown. It also covers the case when the file is truncated at the middle (file is not empty, but incomplete), and more cases of many other errors. |
2011-08-25 - 07:10:46z jarekczek |
The identical idea came to me last evening :) |