From: lkcl Date: Thu, 23 Jan 2020 12:52:41 +0000 (+0000) Subject: (no commit message) X-Git-Tag: convert-csv-opcode-to-binary~3769 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=5fbdb2e3628d5fbd24c532000435125ec729aa27;p=libreriscv.git --- diff --git a/HDL_workflow.mdwn b/HDL_workflow.mdwn index 75c6674f8..9c847d01f 100644 --- a/HDL_workflow.mdwn +++ b/HDL_workflow.mdwn @@ -28,6 +28,8 @@ At the point where such fullscreen users commit code with line lengths well over Where the problems occur with fullscreen editor usage is when a project is split into dozens if not hundreds of small files (as this one is). At that point it becomes pretty much essential to have as many as six to eight files open *and on-screen* at once, without overlaps i.e. not in hidden tabs, next to at least two if not three additional free and clear terminals into which commands are regularly and routinely typed (make, git commit, nosetests3 etc). +(hint/tip: fvwm2 set up with "mouse-over to raise focus, rather than additionally requiring a mouseclick, can save a huge amount of cumulative development time here, switching between editor terminal(s) and the command terminals). + Once this becomes necessary, it it turn implies that having greater than 80 chars per line - and running editors fullscreen -is a severe hindance to an essential *and highly effective* workflow technique. Additionally, care should be taken to respect that not everyone will have 200 column editor windows. They may only have a 1280 x 800 laptop which barely fits 2 80x60 xterms side by side. Consequently, having excessively long functions is also a hindrance to others, as such developers with limited screen resources would need to continuously page-up and page-down to read code even of a single function, in full.