Commit Graph

4 Commits

Author SHA1 Message Date
Ryan Prichard
5a65fdc11c Use more sensible executable flags for source files
My motivation at the moment is that I'm trying to share a
git checkout between multiple VMs using VirtualBox's Shared
Folders feature.  git in the guest VM isn't able to see the
executable bits from the host due to the VirtualBox/SMB/CIFS
layer.  Instead, it thinks text files are non-executable,
unless they have a shebang line.  That's a sensible way to
set the flags anyway, so set them like that.

With this commit, there's still one file that isn't handled:
src/shared/GetCommitHash.cmd.  It's still marked executable,
but it lacks a shebang line, so the guest thinks it's
non-executable.  I'm not sure it should be changed.
2016-04-20 21:44:44 -07:00
Ryan Prichard
d72f4a44f8 Get many misc test programs compiling again after the src reorg 2016-01-15 03:08:10 -06:00
Ryan Prichard
d4640890cf Rewrite resize logic, introduce "direct mode", and tweak scroll scraping.
* Unfreeze the console while changing the buffer size.  Changing the
   buffer size hangs conhost.exe.  See:
    - https://github.com/rprichard/winpty/issues/31
    - https://wpdev.uservoice.com/forums/266908-command-prompt/suggestions/9941292-conhost-exe-hangs-in-win10-if-setconsolescreenbuff

 * Detect buffer size changes and switch to a "direct mode".  Direct mode
   makes no attempt to track incremental console changes.  Instead, the
   content of the current console window is printed.  This mode is
   intended for full-screen apps that resize the console.

 * Reopen CONOUT$, which detects apps that change the active screen buffer.
   Fixes https://github.com/rprichard/winpty/issues/34.

 * In the scroll scraping (scrollingScrapeOutput), consider a line changed
   if the new content is truncated relative to the content previously
   output.  Previously, we only compared against the line-buffer up to the
   current console width.  e.g.

   If this:
      |C:\Program|

   turns into:
      |C:\Prog|
      |ram    |

   we previously left |C:\Program| in the line-buffer for the first line
   and did not re-output the first line.

   We *should* reoutput the first line at this point so that, if the line
   scrolls upward, and the terminal is later expanded, we will have
   output an "Erase in Line" CSI command to clear the obscured "ram" text.

   We need to update the line-buffer for the sake of Windows 10 combined
   with terminals like xterm and putty.  On such a terminal, if the
   terminal later widened, Windows 10 will restore the console to the
   first state.  At that point, we need to reoutput the line, because
   xterm and putty do not save and restore truncated line content extending
   past the current terminal width.
2015-09-29 02:32:49 -05:00
Ryan Prichard
95fe71a501 Add a few more experiments 2015-08-22 20:56:24 -07:00