From my iPhone application I'm outputting data from text to a file. When opened with windows notepad, the data is all on one line and where there should be a new line a block character is present (showing that it's an unrecognized character or something). When opened with windows wordpad, it displays just fine. Would there be something wrong in my code? I'm simply output '\n' when i want a new line.
NOTE : It's working fine with other editors like textedit, MS Word on mac as well as on windows.
Windows default is to use \r\n as end-of-line marker. Notepad only recognises that, other text editors may know about other line-end styles and render correctly.
EDIT
As VonC answers Notepad had an update (in 2018) where it now can recognize non-Windows end-of-line sequences.
I'm simply output '\n' when i want a new line.
And starting May 2018 (6 years later), you will get a newline!
See "Introducing extended line endings support in Notepad" by Michel Lopez (and his tweet)
For many years, Windows Notepad only supported text documents containing Windows End of Line (EOL) characters - Carriage Return (CR) & Line Feed (LF). This means that Notepad was unable to correctly display the contents of text files created in Unix, Linux and macOS.
Today, we’re excited to announce that we have fixed this issue!
Starting with the current Windows 10 Insider build, Notepad will support Unix/Linux line endings (LF), Macintosh line endings (CR), and Windows Line endings (CRLF) as usual.
New files created within Notepad will use Windows line ending (CRLF) by default, but it will now be possible to view, edit, and print existing files, correctly maintaining the file’s current line ending format.
Also note that the status bar indicates the detected EOL format of the currently open file.
See an .bashrc finally displayed correctly!
This is because \n does not represent a full line break in Windows. Using \n is "the Unix" way of doing line breaks.
On Windows, there are text-editors like Notepad++ which handle both, but Notepad is really dumb in that respect.
I suggest you create a setting in your iPhone application where the user can choose between Windows and Unix line endings - then it's his responsibility :-)
Recently ran into this issue and I was convinced that it was my code which is doing this but turns out Notepad has problems rendering the file in the right format.
How do we fix this?
There is no fix available of this behavior of notepad but here is a list of workarounds that can be performed in order to read the contents correctly.
Workaround
You can use Windows WordPad to open the file or just paste the contents of the file into WordPad and back into Notepad . This should fix the problem .
You can also use Notepad++ to open the files which is a third-party text reader and can be installed on a windows system.
Microsoft recently (October 2018) announced that Notepad has been fixed in Windows 10 version 1809 so updating your system to windows 10 should resolve this issue (Windows versions before 1809 are impacted)
Microsoft fixed this after 33 years !!! Gee thats a long time to fix the issue aint it ?
Related
After I restarted my computer, VSCode started to behave oddly. When I open any file:
The cursor's style seems to be "block", although in the settings it's "line".
If I type any character, the character doesn't get written into the file - VSCode actually deletes the character located where the cursor is
After that, I can finally write new characters and the cursor returns back to normal (a line)
Here's how it looks:
Does anyone know if this is bug on their end? I'm using VSCode#1.45.1.
Nevermind, it seems that this was caused by the Vim extension I recently installed. There's a thread opened about it.
I am trying to figure out why VSCode sometimes decides to randomly insert "non-breaking spaces" U+00A0 instead of regular spaces, and how to stop this from happening?
This is a different type of space character which is causing issues, as seen in my previous question GitHub markdown not rendering and git detecting changes when no changes
This is happening to me on both Mac OS and Windows, and others have experienced this issue too. Although this question is about VSCode, this also happens on the online GitHub markdown editor.
How do I solve this problem?
Steps to reproduce
Edit a markdown .md file in VSCode for a while.
Put in lots of headings such as # my heading or ## my sub-heading.
If you have the markdown extension you can CTRL/CMD + SHIFT + P and Open preview to the side.
You should eventually notice that one of the headings doesn't render, and if you open the file in a hex editor such as HxD you'll notice that there is a non-breaking space instead of a regular space after the # character.
Possible causes
The backtick ` character on Windows can be combined with a letter on your keyboard for example a which results in à. Maybe the use of backticks is causing the space character to turn into a non-breaking space? However this wouldn't explain the problem on Mac OS, because backticks can't be combined with other characters.
I have this a lot too on Mac OS, but it turns out I am still holding the option key slightly (or perhaps shift on your keyboard) when typing the space after just having used the modifier key to type #
I've installed https://marketplace.visualstudio.com/items?itemName=viktorzetterstrom.non-breaking-space-highlighter&ssr=false#overview to spot my mistakes early.
I just spent quite a lot of time trying to figure out why a "mv foo bar" command I copy and pasted from VScode was returning command not found. Turned out the space in between mv and foo was a non-breaking space which I only determined by pasting it into a unicode text converter. I would really like to know why this is happening and if it's a setting I can disable. I am using Windows 10 so I don't think it's just a Mac issue.
I have faced this trouble several times when copy/pasting code from Microsoft Skype or Microsoft OneNote. Both programs convert regular spaces into special Unicode spaces when pasting into it.
By the way, since version 1.63, Visual Studio Code automatically highlights these special spaces.
I ran into this too, but I'm sure I unwittingly inserted the non-breaking spaces using the spacebar alone. I found the hexdump plugin useful for diagnosing the problem. I still don't know how to avoid it.
I have set up a small AutoHotkey script that uses hotstrings to allow me to type a few emoji and other special characters:
#SingleInstance force
#Hotstring * ?
::–::–
::†::†
::π::𝜋
::&shrug;::¯\_(ツ)_/¯
::&tm;::™
::&c;::©
::&r;::®
::&tableflip;::(╯°□°）╯︵ ┻━┻
::&music;::♫
::&piano;::🎹
::&cmark;::✓
::&xmark;::✗
::&hourglass;::⌛
The script is also available on PasteBin.
It all works in my text editor:
However, some replacements don't work everywhere, for example in Telegram Desktop:
Both emoji were originally copied from Telegram Desktop, so they are definitely supported in it.
Why isn't this working as expected?
I'm running AutoHotkey Unicode 64-Bit in version 1.1.23.3 on Windows 10 (version 1511), Sublime Text 3 (3103) and Telegram Desktop 0.9.28.
I answered a similar question in the past: Autohotkey Replace 2 specific character with one
I don't really know what the problem was, but we managed to get around the problem by making use of the clipboard. Maybe the same method can be used for your scenario.
I used AutoHotKey for months with no issues, but now some (not all) of my shortcuts no longer work.
Any shortcut used to open a browser tab and go right to a site still work. For example, this…
#a::Run www.autohotkey.com
…will still bring a new tab into focus and load the AutoHotKey site when you press WIN+A. Similarly, everything I have to launch programs still works. But I was mostly using AHK to access accented letters or special characters on a laptop without a numpad. This…
!c::Send,ç
…used to produce a ç but now when you press ALT+c it generates this: ç
It doesn't seem to be tied exclusively to the ALT key. Even if I remap to avoid the ALT key I have the same issue. Below are (I believe) the affected bits in my *.ahk file.
Thanks to anyone who has ideas as to why this worked great and then one day stopped working! I would love to be able to use AutoHotKey again.
!a::Send,à
!b::Send,ß
!e::Send,è
#!e::Send,é
!i::Send,ï
!c::Send,ç
#!c::Send,Ç
!d::Send,·
!g::Send,?
!h::Send,?
!m::Send,—
!n::Send,ñ
!p::Send,¶
+!p::Send,þ
!s::Send,§
!x::Send,×
!'::Send,«
#!'::Send,»
!2::Send,²
!3::Send,³
!4::Send,¢
!7::Send,£
!=::Send,±
!/::Send,÷
+!/::Send,¿
!.::Send,…
What version of AutoHotkey are you using? Always use AutoHotkey and its documenatation from http://ahkscript.org/ (current uptodate version, new official website)! AutoHotkey and its documentation from autohotkey.com is outdated and you may have some problems using them!
Try to launch script with admin rights.
Turn of antivirus software and try if script works.
Check other software. Maybe some of them is using same shortcut?
Loading of UTF-8 macros containing national charactes doesn't work correctly if you have US keyboard active during the process. Switch to national keyboard, then reload the macro file.
For example, I'm using these locale/keyboards combinations and AHK script loads fine only with two:
When keyboard is switched to ENG-US, instead of success I get the following error (file is always the same, encoded in UTF-8):
---------------------------
AutoHotkey.ahk
---------------------------
Error at line 332.
Line Text: #ú::Send {Browser_Back}
Error: Invalid hotkey.
The script was not reloaded; the old version will remain in effect.
---------------------------
OK
---------------------------
With some other national characters, you don't get above error, but without a warning from AHK you get strange effects in interpretation of some UTF-8 characters.
AHK version: 1.1.16.05 (ahkscript.org)
Update: This only occurs when I access the particular server from a Windows machine
With emacs tramp (plink) I'm logging on to 2 different servers, and am experiencing a problem in one of them with find-file.
If I do tab completion in a directory, all file names have ^M appended to them, e.g.:
Click <mouse-2> on a completion to select it.
In this buffer, type RET to select the completion near point.
Possible completions are:
-name^M ../^M
./^M .bash_history^M
.git/^M .gitconfig^M
.gitignore^M .lesshst^M
.ssh/^M .subversion/^M
and when I tab-complete the file name, it completes with the ^M suffix, which is the filename of a nonexistent file:
/plink:user#myserver.com:/home/me/.gitignore^M
Anyone experience a similar problem? ^M is ungoogleable!
^M really is the carriage return part of a carriage return/line feed (hex 0x0d, oct 015). You probably need to configure your server to use linefeeds as line endings. There might be a way to fix this in emacs, but I don't know offhand.
In a way, it's MS Windows (carriage return/line feed) vs. Linux (line feed) issue. However, it's not really that simple and boths types of line endings are there for a historically good reason.
As mentioned elsewhere, ^M is the CR character, which makes up the first half of a CR LF pair used as a line terminator in DOS. Unix/Linux just uses the LF, so the ^M is displayed as an extra character.
When I see this in vim, I remove it by searching for ^M and replacing it with nothing. To specify ^M I press ctrl-V then M
I'm sure emacs has some way to do the same thing.
Try
(add-hook 'comint-output-filter-functions
'shell-strip-ctrl-m nil t)
(add-hook 'comint-output-filter-functions
'comint-watch-for-password-prompt nil t)
or maybe even
'(ansi-color-for-comint-mode-on)
'(ansi-color-for-comint-mode-filter)
^M is Enter.
It could has to do with DOS vs. Unix line break.
DOS: (13, 10)
Unix: (10)
So when you want to write lines using DOS style, a Unix style renderer will say:
your like(char13)
another line
Check your terminal and stuff like that...
And... if you are writing a batch file for Unix in DOS happens the same. You have to convert it using dos2unix filename to remove the extra 13's in your file.