Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside the Windows Console

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

31–40 of 259 posts

Re: Inside the Windows Console

#31

Post by mastazi »

merinowool wrote: post #18
zadjii wrote: post #10

Earlier quoted context omitted.

Have you tried enabling QuickEdit mode in the Properties (right click on the titlebar)? Quick edit lets you use the mouse for selecting, and in Insider's releases we've even added support for Ctrl+Shift+C/V for copy paste (even in wsl!). We've been working on not only tons of bugs, but adding plenty of new features, including support for VT sequences, 256/RGB color, improving our unicode support, enhanced accessibili…

Why do you need to select quick edit to be able to copy? That makes no sense.

You don't need to but it makes it easier

Re: Inside the Windows Console

#32

Post by pjmlp »

flabbergast wrote: post #4
thomastjeffery wrote: post #2

> The Windows Console code-base is currently (July 2018) almost 30 years old ... older, in fact, than the developers who now work on it! Which really shows, especially since you still can't use a TTF-font without editing the registry .

Yeah, this 30 years old code-base.. besides it is questionable only dev's below 30yr old are working on it (age discrimination, or accidental?), hardly anything changed. If I want to copy something I still have to do the ancient mark and copy sequence from the right click menu! What are they working on then? Still fixing bugs?

What about learning to use the OS?

Quick edit for UNIX style copy-paste with the mouse goes all the way back to Windows 9X.

The only issue is that it was always disabled by default, until they changed to be enabled by default with the latest set of changes.

Spending a couple of seconds after logging in to enable it, for the very first time on a new system, was never a big deal.

Re: Inside the Windows Console

#33

Post by Karliss »

zadjii wrote: post #14
gmueckl wrote: post #11

So they have been working on uograding this since 2014? So far, the visible results seem a bit underwhelming for the invested time and effort. How big is the team? What am I missing here?

Well, the team is small, we're up to three whole devs now. Since 2014 we've been doing a lot of work o help bring our VT implementation up to par (to help enable WSL), as well as implementing new features such as 256/RGB color support, improved accessibility features, and we're even releasing a pty-like API for Windows. Not only that, but since the team was founded we discovered that conhost was not the only console…

Pty-like API sounds great. I assume you are referring to what's discussed here https://github.com/Microsoft/console/issues/57 .

Re: Inside the Windows Console

#34

Post by komali2 »

zadjii wrote: post #14
gmueckl wrote: post #11

So they have been working on uograding this since 2014? So far, the visible results seem a bit underwhelming for the invested time and effort. How big is the team? What am I missing here?

Well, the team is small, we're up to three whole devs now. Since 2014 we've been doing a lot of work o help bring our VT implementation up to par (to help enable WSL), as well as implementing new features such as 256/RGB color support, improved accessibility features, and we're even releasing a pty-like API for Windows. Not only that, but since the team was founded we discovered that conhost was not the only console…

Are you able to speak at all to the labor assignment? Microsoft is big, why only put 3 engineers on this project?

Re: Inside the Windows Console

#35

Post by chungy »

Technical errors regarding how UTF encodings work:

* UTF-8 is at maximum four bytes per codepoint (which aren't characters, since multiple codepoints can make up a single character... see combining diaretics or ZWJ emoji things). "additional 1-4 bytes" should be "additional 1-3 bytes" (Historically, UTF-8 did support 5- and 6-byte sequences, and if you read up on it, the implementation is obvious, but that was before Unicode settled on U+10FFFF[1] being the maximal codepoint for backwards compatibility reasons with UCS-2...)

* It says UTF-16 extends UCS-2 (which is correct) by incorporating a 4-bit encoding... which probably was intended to be a "4-byte encoding" instead. The surrogate pairs reserve their first six bits for an additional 10 bits making up half of the codepoint being stored (whose value is later added to by 0x10000 to get the actual codepoint). Also, it provides 16 additional planes to the BMP. 17 total including the BMP.

[1] Actually, U+10FFFD is the maximum legal codepoint, the last two codepoints on every plane are reserved and declared as noncharacters. Few parsers are really so strict.

Re: Inside the Windows Console

#36

Post by Stratoscope »

zadjii wrote: post #12
angelsl wrote: post #3

I'm not sure why the author is so excited! But it makes the article a bit difficult to read!

That's Rich for you - He's pretty passionate about everything we do :)

I want to work with more people like Rich! Whatever they may lack in English convention, they more than make up for it in enthusiasm!

Re: Inside the Windows Console

#37

Post by threeseed »

komali2 wrote: post #34
zadjii wrote: post #14

Earlier quoted context omitted.

Well, the team is small, we're up to three whole devs now. Since 2014 we've been doing a lot of work o help bring our VT implementation up to par (to help enable WSL), as well as implementing new features such as 256/RGB color support, improved accessibility features, and we're even releasing a pty-like API for Windows. Not only that, but since the team was founded we discovered that conhost was not the only console…

Are you able to speak at all to the labor assignment? Microsoft is big, why only put 3 engineers on this project?

This is bizarre to me.

You simply can not attract developers to your platform without a first rate console experience.

Why even bother with Powershell, Linux Subsystem etc without getting this crucial component working perfectly ?

Re: Inside the Windows Console

#38

Post by ilikehurdles »

m_st wrote: post #24

I tried using PowerShell or Hyper. But these are just so slow to start. So I'm always coming back to cmd.exe. It is fast and serves my basic needs just perfect. When I need more, I just type 'bash'. And bash also starts faster than PowerShell or Hyper. So I don't see why they now change WIN+X and Explorer to use PowerShell rather than cmd.exe. Keep improving cmd.exe. But please don't make it bloated.

Do you have something custom going on in powershell? I’m not a power user of windows shells but it opens very quickly for me. So much so that I never thought about the speed of either terminal.

Re: Inside the Windows Console

#39

Post by nailer »

m_st wrote: post #24

I tried using PowerShell or Hyper. But these are just so slow to start. So I'm always coming back to cmd.exe. It is fast and serves my basic needs just perfect. When I need more, I just type 'bash'. And bash also starts faster than PowerShell or Hyper. So I don't see why they now change WIN+X and Explorer to use PowerShell rather than cmd.exe. Keep improving cmd.exe. But please don't make it bloated.

Powershell 5 is slow.

Powershell 6 preview is much faster (not as fast as bash but does more)

Re: Inside the Windows Console

#40

Post by electricEmu »

m_st wrote: post #24

I tried using PowerShell or Hyper. But these are just so slow to start. So I'm always coming back to cmd.exe. It is fast and serves my basic needs just perfect. When I need more, I just type 'bash'. And bash also starts faster than PowerShell or Hyper. So I don't see why they now change WIN+X and Explorer to use PowerShell rather than cmd.exe. Keep improving cmd.exe. But please don't make it bloated.

I'm not sure how often you start and stop your shells, but start time is seldom a concern.

I enjoy you chose Hyper.js, which uses electron. I'm not sure what speed you were expecting there. You might try ConEmu https://conemu.github.io/.

Post reply on HN