I used vim to open a file event.txt and show me some search results. This worked fine, but since I did a change in the _vimrc it displays the file content with #-signs so that it is unreadable. See image below.
What I did change in _vimrc was
set fileencoding=utf-8
but I commented it. So it should not affect vim.
"set fileencoding=utf-8
The file is still displayed unreadable. With other editors I can open the file and view it normally. I had this behaviour some time ago, but I vanished somehow. I can't remember.
The event.txt file is the windows event file which I generate through the powershell:
get-eventlog -logname system > event.txt
Something tells me it's not the change in the _vimrc and perhaps something else, but this is the last change I remeber I did and after this it did not work.
How can I view in vim the windows event file event.txt normaly? Without #-signs.
That ÿþ at the beginning is a byte order mark (BOM), typical for Windows Unicode text. The ^# is Vim's representation of a NUL value, and it (roughly) appears as every second character. So, you have a (mostly) ASCII-text file, encoded in UCS-2 little endian: each character is represented by two bytes (16 bit), the lower one comes first.
You can open that file with
:edit ++enc=ucs2-le event.txt
But it's better to set up Vim correctly so that it automatically detects it. Since you're using GVIM on Windows, I would recommend to put
:set encoding=utf-8
at the start of your ~/.vimrc. This will automatically set your 'fileencodings' to a good default of ucs-bom,utf-8,default,latin1. Note the first element; that should help detect the file.
Do not set 'fileencoding' in your ~/.vimrc! That is a buffer-local setting, and it will be automatically set by Vim on opening of the file. The 'fileencodings' (note the plural) is the right option to influence the detection.
Related
I am trying to open a .log file while in Sublime Text 3 (v3.2.2, Build: 3211) installed on Mac OS Catalina and I see that it opens with plain hex numbers.
This is a small snippet:
205b 6465 6275 675d 2031 3631 3736 2330
3a20 6570 6f6c 6c20 7469 6d65 723a 202d
I am not sure why this happens but I am not able to see any quick link for the same anywhere for this issue.
This is an indication that Sublime thinks that the file that you tried to open is a binary file; it's controlled by this setting (which as seen here defaults to true):
// Files containing null bytes are opened as hexadecimal by default
"enable_hexadecimal_encoding": true,
When this is turned on, the file is opened using the Hexadecimal encoding as a warning to you that the file is (or seems to be) a binary file. If the file is actually binary, then you probably don't want to be editing it with a text editor.
On the flip side, if the file is actually a text file with something in it that makes it detect as binary, then it's possible that the detection of what encoding the file is actually using may not work the way you expect, which can cause other issues. So in that case the setting opens the file in Hexadecimal as a warning to you that you need to tell Sublime what encoding it should be using.
If you're sure the file is actually a text file (probably a good guess for a .log file), then you can use File > Reopen with encoding to tell Sublime that it should be using a different encoding, for example utf-8. You can also try turning off the above setting so that this doesn't happen, although in that case as mentioned the encoding that's selected may be incorrect.
Related to this, there's another setting that can come in handy:
// Display file encoding in the status bar
"show_encoding": false,
This one defaults to false, but when you turn it on the encoding of the current file appears in the status bar on the right hand side, near where you see the indent settings and the type of the current file.
If this is turned on, you can easily verify exactly what encoding is currently being used, and you can also click there to get a menu that lets you change the encoding of the current file or quickly re-open it using a different encoding.
ASCII character code 0x07 is a beep character.
Opening CMD and clicking ALT + 007 yields :
And when I click ENTER - I hear a beep. This is fine.
I've searched how to add a beep in the end of a batch file, and I found that this is the solution : (I'm pasting it as an image becuase SO doesn't show the round bullet after editing) :
This does work and does make a sound. When examined with a HEX viewer (with beyond compare) on ECHO, the round bullet is:
But if I manually add ALT+7 to the document , I see this:
Which is a 95 as a hex - and it's not a Beep. In addition, I went to the working batch file and added a new line with my ALT+7 :
But looking via HEX viewer :
Question:
I'm a bit confused. Clicking Alt+65 does yields A everywhere.
So why does the beep different and doesn't work when saved in Windows GUI?
In the console, if I click ALT+007 I get ^G (it does beep), but when I click ALT+7 I get the circle, which is not a beep:
Here are both:
Another interesting observation via notepad++ :
I think it's related to encoding, etc, but I don't understand the inconsistency.
I have a workaround to suggest. Put this in your script:
forfiles /p "%~dp0" /m "%~nx0" /c "cmd /c echo 0x07"
For every file in your script's directory matching your script's filename (e.g. 1 time), it will echo ASCII character 7, and will make noise. From the forfiles /? documentation:
To include special characters in the command line, use the hexadecimal code for the character in 0xHH format (ex. 0x09 for tab). Internal CMD.exe commands should be preceded with "cmd /c".
forfiles is a handy utility to abuse whenever you need a non-printable or extended character.
As for my speculation for why Alt+007 doesn't behave as expected, I believe the console works on a different codepage from windowed applications (console = 437, windowed = 1252 for en-US, IIRC). I've struggled with this issue as well for reasons, ultimately resorting to hard coding the symbols used for console characters 1 through 31 in that JavaScript project.
This is not really an answer, but it would be too large for a comment.
The "manually adding ALT+7 to the document" part produced strange results which it should not have produced. The result should have been a single 0x07 character. It may be that your editor did something funny when you pressed ALT+7.
The problem with this kind of troubleshooting is that the tools you are working with have complex behavior that distorts the experiment. The tools also have strange modes and strange states. For example, what is the encoding of your console subsystem?
I tried this: copy con x.bat typed echo followed by Alt+7 and then Ctrl+Z and got a beeping batch file. The character looked like a bullet.
Then I tried with Alt+007 and I also got a beeping batch file, but the character was ^G now.
At the C:\> prompt, I typed echo followed by Alt+7, a bullet was also produced, but there was no beep. But an Alt+007, looking like a ^G did produce a beep. Go figure.
I would say ignore the inconsistencies that occur when you are trying to input a control character, because there is a lot of software involved in doing so which is beyond your control and apparently works in mysterious ways. (I know, not an answer.)
To beep in a cmd file :
Solution 1
C:\>rundll32 user32.dll,MessageBeep -1
Solution 2
C:\>echo ^G>beep.txt
C:\>type beep.txt
NB :
^G is obtained by pressing Ctrl+G and you can see the character by editing beep.txt
I'm using windows 10. I've been trying to change my font and font size to be easier on the eyes for gvim, and all my settings (syntax, ruler, numbers) work normally from my _vimrc file. I currently have
set guifont=Consolas:h12:cANSI
set guifont=Consolas\ 12
in both my _vimrc and _gvimrc files (both in $HOME). When I load :scriptnames, it shows that ~/_vimrc is loaded first and ~/_gvimrc loaded last. I have also tried
set guifont=Consolas:h12
instead of
set guifont=Consolas:h12:cANSI
Still, everytime I open vim or gvim everything is displayed in that horrid size 7 Fixedsys font. Only when I manually go to Edit->Select Font... can I actually effect a change on the font, but the next time I open vim/gvim the changes are not saved. The funny thing is when I enter :set guifont? it tells me that
guifont=Consolas 12
but the font is definitely still at Fixedsys 7. What is going on?
What worked for me is embedded in #nperson325681's answer but not made explicit. In W10 the correct font setting turns out to be your first instruction
set guifont=Consolas:h12:cANSI
but not
set guifont=Consolas\ 12
(although the latter works for me in Linux, and is what I've seen in Vim documentation and help files). So, as #nperson325681 implicitly suggests, take out the second set guifont in your _vimrc. What your set guifont? shows does correctly reflect what your _vimrc has instructed; it simply isn't what works in W10. What I ended up doing is:
if has('win32') || has('win64')
set guifont=Consolas:h10:cANSI:qDRAFT
else
set guifont=Consolas\ 10
endif
Hope that helps.
If you have two set guifont lines in your rc, the last will win. Try with the first line only.
After you have selected a font using the dialog, you can copy-paste the exact and correct line to your gvimrc by typing in insert-mode <C-r>=&guifont<CR>
In the Open with menu of a .cs file there's Csharp editor and Csharp editor with encoding. I opened a solution with both and didn't see a difference.
What's the difference between them?
Unless your .cs file includes characters outside of the normal ASCII range, you won't see a difference in the actual contents of the file. The difference is whether or not the editor tries to detect the character encoding you saved your file with when you open it again, or asks you specifically.
By default, when you save a new .cs file, VS uses the current ANSI code page to encode the characters. (You can switch this to use UTF-8 by default with the appropriate options.) However, you can instead chose to "Save with Encoding...", which will prompt you for the specific character encoding you want to save it.
Internally, your code is being handled as UTF-16, since that's what Windows deals with as it's native string format. On-disk, however, UTF-16 would most likely blow up your source files to double their size, since most of the C# code you write probably fits into a single byte. So, when writing to disk, VS writes out your data in a particular code page that defines how to convert the UTF-16 characters into some other, possibly 8-bit character set.
When you reload a file in VS, it attempts to figure out what encoding that file was in, and if it can't, it will fall back on the current ANSI code page. (You can force it to fall back to UTF-8 via some options, but it won't ever fall back to a different encoding.)
When you reload a file "With Encoding", you get the same prompt as when you saved the file, asking you which encoding was used. This way, if Studio gets it wrong, you can fix it.
Unless you do a lot of internationalized programming, where you have foreign-language strings embedded in your .cs file from a language other than the default, you probably don't need to use the explicit "with encoding" save or loads. But, they are there if you need them.
If you open with encoding you can save with whatever character encoding is appropriate for your culture or region.
I'm trying to use the < C-a> (CTRL+A) shorcut under vim to increment a variable under the cursor. This works fine under vim running on Linux. However when I try to do this in gvim under windows it "selects all" (i.e. highlights or visually selects all text in the current window). How can I change this behaviour or alternatively how can I recover the increment variable functionality (e.g. perhaps with a different key mapping)?
This is because of mswin.vim that is sourced by the default _vimrc generated when you install vim.
Just override your _vimrc with the .vimrc you are using under *nix, or delete mswin.vim.
I know I'm late to the party, but I thought I'd share the following:
nnoremap <kPlus> <C-a>
nnoremap <kMinus> <C-x>
This remaps increment to the + key on the numeric keypad and decrement to the - key. It's the solution I've used in my own _vimrc file on Windows. It keeps the Windows compatibility and is easier to remember than the original Ctrl+A/Ctrl+X as well.
Vim on Windows has specialized key mappings by default to make shortcuts more "windows-y". These are specified in the $VIMRUNTIME\mswin.vim file, which is loaded via your vimrc unless you disabled it. You can edit the mswin.vim file (you may want to edit a copy instead, changing your vimrc to use your edited copy instead).
I'm not entirely sure it's a default Vim mapping, since the only reference I can find on Ctrl+A in the help file is this, which doesn't seem to do what you are referring to:
*c_CTRL-A*
CTRL-A All names that match the pattern in front of the cursor are
inserted.
so you may want to check your Linux box to see if any plugins or anything change the key mapping. (Of course, it may be that I just can't find the appropriate part of the Vim help.)
in the current version of mswin.vim provided with gvim, the file checks for the value of a global named skip_loading_mswin; If set, the rest of the file is skipped; thus it is sufficient to add
let skip_loading_mswin=1
to $HOME/_vimrc and normal vim bindings will be restored the next time you start vim.
If you just do not like CtrlA behaviour but are fine with other windows behaviours in VIM (like CtrlZ for undo), just disable that specific line:
Edit said file (c:\Program Files\Vim\vim73\mswin.vim for me)
Find the paragraph starting with CTRL-A is Select all
Prepend all (6) lines of that paragraph with opening brackets (")
Reopen your GVIM windows.
You can still "select all" by typing ggVG (position cursor at first line, select entire line, select until the last line of the document).
Happy incrementing!