I wanted to type cd~ into PowerShell to move to my home directory, however when I pressed SHIFT and the tilde keys the output is cd˜, so instead of the big regular tilde symbol ~, I got small superscript tilde symbol ˜ I can type the tilde symbol in other applications, the problem only occurs when I use PowerShell or cmd.exe, I'm using ENG(Canada) US Keyboard, Window 8.1 and PowerShell version 4.0
The closest topic I found on the site that cover a problem similar to mine is this one Tilde not recognized in Mac terminal but it's for MAC and I am using Window 8.1
Any suggestion on how I can fix the problem?
This is probably caused by your keyboard settings ( input services in control panel ). You need to find offending service and remove it.
Until you find it, you can fix this with AHK hotstrings :
::˜::~
Related
I've recently upgraded PowerShell to version 7.3.0 version and now, when I type a command, I see its suggestions like when I'm typing pip it adds list like in this image. Or when I type start of the command it suggests its full name.
The problem is that when I press Tab it doesn't complete the command, instead it just starts listing current directories, i.e. here is an image after pressing Tab once.
Also even when I start typing the full name of the command like pip li it still shows the ending, but when pressing Tab it just does nothing.
I expected this to complete the current command with the suggestion after Tab is pressed.
I've tried to google this problem but haven't found the exact same case I have with 7.3.0 version.
Just press -> (right arrow) key
If you want to change key bindings:
source: https://devblogs.microsoft.com/powershell/announcing-psreadline-2-1-with-predictive-intellisense/
Key Bindings for Predictions
Key bindings control cursor movement and additional features within the prediction. To support users running Predictive IntelliSense on multiple platforms, key bindings are user-settable from the command line or your profile script.
PSReadLine contains functions to navigate and accept predictions. As an example, to accept a displayed prediction, PSReadLine contains functions:
AcceptSuggestion – Accept the current inline suggestion
AcceptNextSuggestionWord – Accept the next word of the inline suggestion
AcceptSuggestion is built within ForwardChar, which by default is bound to RightArrow. Pressing RightArrow accepts an inline suggestion when the cursor is at the end of the current line.
AcceptNextSuggestionWord is built within the function ForwardWord, which can be bound with Ctrl+f by Set-PSReadLineKeyHandler -Chord "Ctrl+f" -Function ForwardWord. Pressing Ctrl+f accepts the next word of an inline suggestion when the cursor is at the end of current editing line.
As a user, you can bound other keys to AcceptSuggestion and AcceptNextSuggestionWord for similar functionalities. Search for ForwardCharAndAcceptNextSuggestionWord in SamplePSReadLineProfile.ps1 for an example to make RightArrow accept the next word from inline suggestion, instead of the whole suggestion line.
List of additional suggested key bindings defined in PSReadLine SamplePSReadLineProfile.ps1
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 am trying to use org-mode and whenever I press Crtl+return emacs does C-J instead. I know this because when I use c-h k and then press crtl+return, emacs shows:
"It is bound to C-j."
Is there anyway I can make it register ctrl+return so I can insert headings?
I am using emacs23 through the terminal on ubuntu 12.04 x64. When I do this on my windows machine it does insert a new heading.
Possibly. As #phils says, C-Enter is usually not a valid sequence for the vast majority of terminal emulators. This is because when you press a key, or key combination, the terminal sends a sequence of characters to the relevant application. Pressing a sends a, whereas Enter sends CR - carriage return (otherwise known as ^M, \r or \015).
What sequences are actually implemented in modern terminals is mostly just a hang-over from the earlier, physical, terminals that they emulate (notably the VT-100). These machines didn't allow the use of Ctrl in conjunction with every key, such as the function keys, for example, so C-F1 was not possible and didn't have an escape sequence defined. Similarly, there is no control sequence for C-Enter, so when you press it, the terminal ignores the Ctrl and just sees the Enter.
You may, however, be able to define your own escape sequences in your terminal, which you can then bind to the correct key combinations in emacs. See here, for example. I was able to use this method to be able to use C-Enter. Unfortunately, this is still a bit of a pain, as it requires a lot of configuration and you may still be unable to use some sequences (C-M-% doesn't work in konsole for me). As with #phils, I've taken to using the GUI, but I'd love to have better integration with my terminal.
That's not a valid sequence for most terminals, I'm afraid, so they simply can't send it to Emacs.
If you run GUI Emacs instead, the key bindings will work.
Thomas Dickey's xterm is the only terminal software I know of which can (I think) support all the normal Emacs bindings. If you're okay with compiling that, then you could try it with the following .Xdefaults-(hostname) (or .Xresources if you re-merge after editing) to get basic support working:
XTerm*metaSendsEscape: true
XTerm*modifier: meta
XTerm*modifyOtherKeys: 1
You actually need XTerm*modifyOtherKeys: 2 to fully extend the sequences (otherwise you still can't type the likes of C-M-%), but by default that setting will break most key sequences, and right now I couldn't tell you how to configure things correctly for that setting (the only example I've seen -- xterm-extras.el as mentioned on the wiki and available in the easymacs download -- didn't work for me).
I mostly use GUI Emacs, but I'd love to get this working properly, so if anyone has had success with xterm-extras.el or similar, please do speak up.
If you're willing to install an Emacs package and configure your terminal, I wrote an Emacs package which can teach Emacs and terminals how to properly recognize all PC keyboard keys and modifier key combinations:
https://github.com/CyberShadow/term-keys
Its default configuration enables encoding the CtrlReturn combination, which allows Emacs to distinguish it from CtrlJ.
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)