Forum Replies Created
- AuthorPosts
- September 14, 2017 at 2:11 am in reply to: Vertical / horizontal scrollbar indicators not properly aligned at end #22439atnakParticipant
Brilliant! I can confirm both problems are resolved in v17.1.4. Thanks!
September 11, 2017 at 8:20 pm in reply to: Vertical / horizontal scrollbar indicators not properly aligned at end #22427atnakParticipantThank you. However, I have tried v17.1.3 and there appears to be a slight mishap.
Because if I scroll all the way down, nib moves past its bottom boundary and buries itself into the bottom button of the vertical scrollbar.
The problem can be reproduced by having a document containing a large number of lines relative to the window size. For example, 8000 lines with the window height of 800px.
I think it may be related to the fact that there’s a minimum height of 16px beyond which the nib will not shrink.
June 23, 2016 at 7:10 pm in reply to: External Tools > Input "Document" adds extra garbage at the end of input #20944atnakParticipantSome old programs need the EOF character (0x1a),
That’s something I never knew of! Thanks for the explanation.
Regards,
P.S.
I did some searching on this mysterious 0x1A character that I’ll share here in case someone else is interested.- “Some early disk operating systems like CP/M actually did use a physical 0x1A (ASCII SUB character) to indicate EOF” — http://stackoverflow.com/a/3061174/1036728
- “There was a long long time ago an End Of File marker but it hasn’t been used in files for many years.” — http://stackoverflow.com/a/24992477/1036728
- “I encountered a couple of text files with a trailing ^Z back in the days of DOS 3” — http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/msg202401.html
June 22, 2016 at 10:02 pm in reply to: External Tools > Input "Document" adds extra garbage at the end of input #20940atnakParticipantTo work around this, you can select the “Custom” for the Input, and then enter “$(DocText)” for the “Custom” text box, and make sure the “Add EOF” check box is cleared.
Thanks for the update and workaround. I can confirm it works correctly with Custom input of “$(DocText)”.
On the next version, I will make the “Add EOF” check box enabled even when “Selection” or “Document” is selected.
I’m not altogether certain what the purpose of this is, since a real EOF is received by the external program when EmEditor closes the pipe.
I tested with this program to confirm EmEditor is properly closing the pipe. I get the output “
a$
” to the input “a
” when “Add EOF” is off, and “a<0x1a>$
” when it’s checked.static class Program { static void Main(string[] args) { for (int c; (c = System.Console.Read()) != -1;) { System.Console.Write((char)c); } System.Console.Write("$"); } }
At the very least, I think the checkbox is ill-named as it can be confused with the real EOF (closing of an input stream) which that checkbox has nothing to do with. Maybe a name such as “Add &1AH (Ctrl-Z) byte” can avoid this confusion.
June 20, 2016 at 6:34 pm in reply to: External Tools > Input "Document" adds extra garbage at the end of input #20933atnakParticipantcat command probably produces the EOF
cat
is really only an example. (Although what I said above is true for thecat.exe
that I have.)The outcome is the similar with various other commands:
SqlFormatter.exe
regurgitates the0x1A
to the output.python.exe -m json.tool
complains about “Extra data” at the exact line and column where that0x1A
byte is expected to be.This simple C# program will output the
0x1A
on the end if specified through EmEditor’s “External Tools”. It will not do this if called through command prompt such as ‘Program.exe <a.txt >b.txt
‘.static class Program { static void Main(string[] args) { for (int c; (c = System.Console.Read()) != -1;) { System.Console.Write((char)c); } } }
atnakParticipantPlease go to Configuration Properties, File tab, New Files button, and select “LF Only (UNIX)” from the Return Method.
Strange, I can’t get this to resolve the issue.
I’m using “EmEditor Professional (64-bit) Version 13.0.6” and my system’s default encoding is “日本語 (シフトJIS)”.
Properties for Current Configuration (txt) shows:
- New Files… > Return Method: LF Only (UNIX)
- Saving… > Return Method: No Change
My test file is “Untitled.txt” (Return Method = LF Only (UNIX)) containing:
a
b
cImportant: EmEditor should be closed once after creating this file before attempting to reproduce.
To reproduce, I simply open “Untitled.txt” from Explorer, check that the status bar shows “LF Only (UNIX)”, then hold down Ctrl and type A, C, V.
atnakParticipantAnd only until I press Enter one time after the ‘c’, then it switch to “LF Only (UNIX)”
Oops, an amendment: You need to close & reopen the document between steps 3 and 4. Then, it’s not temporary.
The “Tools > Customize… > Status > Return Method” has nothing to do with this situation at all as it seems.
It has nothing to do with the cause. But you’ll be hard pressed to see the problem if you can’t see what the Return Method is in the status bar.
atnakParticipantAlternate steps to clarify the problem:
1. “Tools > Customize… > Status > Return Method” should be checked
2. Create a new document and type “a<Enter>b”
3. Save the document, selecting “LF Only (UNIX)” as the Return Method in the Save dialog.
4. Notice the Status Bar shows “LF Only (UNIX)”
5. Ctrl-A to Select All, then type “c” (or alternatively, hit Ctrl-C to Copy followed by Ctrl-V to Paste)
6. Notice the Status bar now shows “CR+LF (Windows)” <– Problem hereatnakParticipantPreserve (CR/LF) returns on Clipboard check box
Thanks for the advice. However, I don’t think this helps.
- AuthorPosts