PreviousNextTracker indexSee it online !

(98/231) 2989448 - "Hide final end of line" doesn't takes effect immediately

I'm using jEdit in XP and it incorrectly shows one less newline at the end of files.

So I have a file like this (ignore quotes) (works correctly in notepad):

"START OF FILE
This is a test to see if the function GetContentsOfFile() works.

It should get this text from this file.
END OF FILE <--- so basically there is a new line here.
"

But jEdit shows this:

"START OF FILE
This is a test to see if the function GetContentsOfFile() works.

It should get this text from this file.
END OF FILE" <--- the newline doesn't show in jEdit


I believe this to be a bug... it may seem minor but it has caused issues when editing PHP files, as PHP doesn't always like trailing newlines after the end ?> tag. It also caused an issue with my unit tests because the contents of the file that I created in jEdit had one more newline that I thought. I have therefore classified it as a 'normal' bug rather than minor as it's knock on effect can have quite an impact... but feel free to reset to 'minor' as I can see your point of view on that decision if that's what you decide to do :)

Can anyone confirm this behaviour?

Submitted Anonymous - 2010-04-19 - 16:14:55z Assigned kpouer
Priority 5 Category editor core
Status Open Group normal bug
Resolution None Visibility No

Comments

2010-04-19 - 16:34:24z
I've just unchecked 'hide final end of line (if any)' in Global Options... but this did not fix the issue. Indeed I believe I've found a bug in this feature.

After unchecking this option jEdit still hides the final end of line! However the EOL is still there. If I save the file then nothing is fixed, however if I add an extra newline in jEdit and then delete it... it NOW correctly shows the correct number of newlines actually in the file! This is quite unpleasant functionality! I think it needs re-thinking.

I would recommend the following:
1) Default 'hide final end of line (if any)' to unchecked (and definitely for PHP files).
2) When a user checks and unchecks this option (and of course applies or ok's the dialog) then the buffer should reflect the appropriate change (i.e. either show the now not hidden newline, or vice versa.

That would be sweet!
2010-04-19 - 16:45:53z
Note the issue regarding 'hide final end of line (if any)' not showing any change relates to currently open buffers only.
2010-04-19 - 17:19:37z
shlomy
How about Global Options -> Text Area -> Hide final end of line?
2010-04-19 - 17:30:46z
rschwenn
As already said, the issue is that "Global Options -> Text Area -> Hide final end of line" doesn't takes effect immediately. The buffer seems to be need a reload for the change to take effect, which is surprisingly for me, too.

jEdit 4.3.1
SUN JRE 1.6.0_19
Windows XP SP3
2010-04-20 - 18:28:53z
shlomy
I think the location of this option is wrong. The way it is implemented, the last EOL is dropped from the contents of the buffer when the buffer is loaded - it has nothing to do with the text area itself. Maybe this would resolve the confusion?
2010-04-20 - 20:40:03z
It doesn't seem clear to me what you are suggesting shlomy.

The EOL hide option DOES have something to do with the text area... lol how could it not!? The EOL is displayed in the text area after all ;)

The only confusion that needs resolving is to design this option correctly as per my suggestion. i.e. default to WYSIWYG (i.e. display the EOL if it's actually in the file, otherwise don't). This is far better from a users perspective, i.e. it's only fair to expect a text editor to actually display the file 'as is'... to default to non-WYSIWYG is not a good idea! ;)
2010-04-21 - 06:05:26z
shlomy
The way it is implemented, it is not directly related to the text area. Of course it is reflected in the text area as well, but it's not just hiding the last EOL from the user in the text area. The actual buffer content is changed during the entire editing. E.g. if you use macros that retrieve the text of the buffer, this final EOL will also be missing.
So by "nothing to do with the text area" I meant that it's not a text area related feature, it's a buffer content feature that is visible in other functionality as well.

Hence, I was suggesting to move this option from the "Text-area" category to another category, so users don't get to think it's only hidden from the text area, and also change the description of this option to match its actual functionality.

Attachments

2010-04-19 - 16:14:55z
get_contents_of_file_test.txt

Contents of file test