tolstoyevsky / gits Goto Github PK

Now the Terminal has two public methods: write and dumphtml.
Such API doesn't provide the clear interface to the Terminal and it's not obvious what the write method is actually does.

The PR #84 provides all methods of the Terminal with the docstrings, but the write doesn't have it, because of the future rework that will be done in this issue.

According to the specification[1], cub1 moves the cursor left by 1 position. However, the current implementation of the capability moves the cursor one line up. Moreover, it has a bug: cub1 moves the cursor one line up when the cursor is not at the left-most position.

[1] http://pubs.opengroup.org/onlinepubs/7908799/xcurses/terminfo.html

• bold text support

• blink text support

• underscore text support

The dl capability is more difficult than it may seem, so its docstring should be expanded.

It would be good to have some info about the running server (e.g. port, host).

It's painful each time to write:

1. Start the server: env PYTHONPATH=`pwd` ../gits-env/bin/python bin/server
2. Run the tests: env PYTHONPATH=`pwd` ../gits-env/bin/python gits/test/terminal_test.py

Can we have some helper shell script for this?

• ConfigReader

  Loads configuration files related to matching escape sequences to capabilities.

• Screen

  Contains data for renderer. Will contain rules about setting, updating the screen cell (color, attribute).

• HTMLRenderer

  Gets data from Screen and ConfigReader and builds HTML.

• CommandExecutor

  Matches the raw escape sequence to the capability and executes this capability.

• Terminal

  High level logic, a facade, under the HTMLRenderer, CommandExecutor, ConfigReader, Screen. As a result, only the terminal should be able to the wide world.

cup is a combination of vpa and hpa.

Such programs like vi may send something like \E[23;80H (set the vertical and horizontal positions of the cursor to y and x). The current implementation of cup will set _eol to True in this case and _echo will write a character on the next line. It's obviously a bug.

Now, we only run tests for gits for one platform. Need to test, built, run gits for following platforms:

• fedora
• debian
• ubuntu - 14.04
• ubuntu - 16.04
• centos 5
• centos 7

There is an agreement that all methods names that represent capabilities should have the following format _cap_{capability_name}, but there are some methods that don't match this format.

E.g., _cap_set_color.

The existing implementation uses the hardcoded screen size (24x80).

Each time an interactive program runs, it tells the terminal to hide the cursor. When it exits, the cursor should be restored.

During a building gits for varios platforms I've realized that living with a python and nodejs at the same time is a big pain in the ass.

Let's begin with Linux Mint:

• It doesn't have a setuptools on a startup.
• nodejs has a different location, that's why we need to create a symlink to make our npm run start works.

Fedora 24:

• A zero problem with an installation (of course it's a good point).
• Broken htop, vim, nano, man (I won't provide a screenshot demonstrating it, but all console oriented tools work incorrectly)
• Also I have a short dance with a tambourine with installing pip, virtualenv properly

MacOS:

• SSH daemon is always turn off on a start up and I always forget to turn it on and spend some time to figure it out WTF with our login util, that's why I think we need to mention that SSH daemon should be started before running gits.

I specify only a little problems above, because I didn't notice all problems and forgot some of them.

Overall wishes:

• We need to rework CI by adding different platforms (#95).
• We need to provide a more simple interface for running gits (I think we should have something like gits start and that's it, user doesn't care about running a client at first, that running a server), we can achieve this by providing a tool, that will operate our low-level python lib and npm package.
• We need to provide a make file with set of simple targets: build, test. By build target I mean that user will have a ready tool to run gits on any platform (except windows). By test target I mean a simple way of running all gits test (now we don't have it).

Can we move our doc back to github from readthedoc? It's a personal experience, but it's more convenient to have all stuff about gits in a one place.

• PyLint
• code coverage

The terminal should have the possibility to interact with a computer mouse.

The methods

• are not connected with colors
• must be stubs.

• ability to change background color

• ability to choose the font family

• ability to change the font size

Try to delete the whole line with the cap_dch capability, but got the error.

How to reproduce:

self._check_cap_dch(['f'] * term._right_most, term._right_most)

See also: #40.