Is there a way to nest VT100 escape sequences? For example, if I want a bold faced word within red text as below:
is there a straightforward way to do it? If I do the following, the first \e[m intended to close the bold face would also close the red color.
"\e[31mfoo \e[01mbar\e[m baz\e[m"
No - they do not "nest". As a rule, video modes can be set or reset. Some resets affect multiple modes, e.g., \e[m which resets bold, underline, reverse, etc.
The DEC VT100 implemented a subset of an ANSI standard, while also providing extensions. The corresponding standard was made obsolete by ISO-6429, which is readily available as ECMA-48.
A close reading of the standard may demonstrate that some of it is ambiguous, i.e., can be read as alluding to different types of behavior. For instance, there is no enumeration of the possible video attributes in the SGR (set graphic rendition) section, and how they may be interrelated. Because of this ambiguity, there exist terminals using "VT100 escape sequences" which have noticeably different color behavior (see for example the ncurses FAQ My terminal shows some uncolored spaces).
Because the standard does not specify everything, we rely upon common practice and conventions to determine what a terminal emulator can be expected to do, and where one might develop a new feature which extends the standard. For instance, ECMA-48 does not mention the VT100 scrolling feature, which is widely used. Also, it does not actually say that SGR 0 resets color. While existing terminal emulators happen to do this, early on before the convention was common, it was possible to have terminal emulators which relied on different escape sequences to reset color. (The dynamic colors feature in xterm is an example of this).
As noted, it is possible to provide extensions. ECMA-48 outlines encoding for private use (implementation-dependent) control sequences. Someone could (no one has...) design a terminal which provides the type of feature suggested. If that did not fill a perceived need by many people, or if it were cumbersome to use, it would be ignored. Because this type of escape sequence differs from existing practice, there is no support for it in curses and similar libraries. That would make it cumbersome to use.
This does not say that it is impossible to provide such a feature. As an example, xterm since patch #251 has provided a feature (incorporated into GNU screen) which sidesteps the longstanding problem of retrieving window titles (viewed as a security problem) by adding a mode where titles are saved on a stack. GNU screen uses this feature where it exists to automatically restore the original window title on exit.
\e[m resets all graphical rendition options, including color. To clear the bold option only, you can use \e[22m, although not all terminals support this sequence.
Related
I'm currently developing a console application with a text-based user interface, in python, which is meant to be an open-source, UNIX alternative for a series of industry standard software and to minimize, in my opinion, the hardware/software requirements for a software of such scale.
However, I do not prefer using curses/ncurses in order to understand the principles of how such libraries work and implement them for my own purposes. For that I've been - let's say - experimenting with ANSI Escape Sequences, for a while.
At some point, I've felt the need that I should split (or to describe in UNIX terminology, multiplex) my terminal into sessions, windows or panes as in GNU Screen or tmux. However, for the reasons I mentioned above, instead of using them in my project I tried to discover their source to get inspired. But the truth is that they both require an extensive knowledge of C, at least for me at this point, and searching through the source codes is exhaustive.
I've recenlty found out that GNU Screen documentation refers to ECMA 48 and ANSI X3.64.
Screen User's Manual
Each virtual terminal provides the functions of the DEC VT100 terminal
and, in addition, several control functions from the ISO 6429 (ECMA
48, ANSI X3.64) and ISO 2022 standards (e.g. insert/delete line and
support for multiple character sets). There is a scrollback history
buffer for each virtual terminal and a copy-and-paste mechanism that
allows the user to move text regions between windows.
I also checked ECMA 48 and ANSI X3.64 for what I want to achieve, couldn't find a clue.
My questions actually arise at this point.
How can I find out which coded character sets in those standards are implemented? For example in §8.3.123 of ECMA 48 refers to DEVICE COMPONENT SELECT MODE, which I could found no signs of implementation or use thereof.
What is the working principle of Screen or tmux in creating a window and pane? What kind of path do they follow for creating windows or panes.
The time I've spent for the second question is quite a lot, and took me nowhere. I thought they may be sweeping the whole screen, drawing borders, delimiting lines or columns with coded characters each time there needs to be an update (resizing, creating a new pane etc.). I considered this option may be a basic but frustrating solution. And I could not be sure that screen or tmux works in that way. But I am pretty sure that I am missing a critical point here.
Any help, opinion or recommendations are appreciated.
What are the syntactical features of current languages that prove problematic for screen readers or braille readers? What symbols and constructs are annoying to hear or feel? To the blind programmers out there, if you were to design a programming language which was easier for other blind people to work with, what would it be like?
Although it is a very interesting question, it is highly a matter of personal preferences and likings, so I'll answer as if you asked me personally.
Note: My working system is Windows, so I'll focus on it. I can write cross-platform apps, of course, but I do that on a Windows machine.
Indentation, White Spaces
All indentation-related things are more or less annoying, especially if the indentation is made with multiple spaces, not tabs (yes yes, I know the whole "holy war" around it!). Python did teach me to indent code properly even in languages that don't require it, but it still hurts me to write proper Python because of these spaces. Why so? The answer is simple: my screen reader tells me the number of spaces, and the actual nesting level is four times less. Each such operation (20 spaces, aha, dividing by 4, it is fifth nesting level) brings some overhead to my mind and makes me spend my inner "CPU" resources that I could free for debugging or other fancy stuff. It is a wee little thing, you'd say, and you'd be right, but this overhead is on each and single line of my (or another person's!) code I must read or debug! This is quite a lot.
Tabs are much better: 5 tabs, fifth nesting level, nice and well. Braille display here would be also a problem because, as you probably know, a Braille display (despite the name) is a single line of text, usually 14 to 40 characters long. I.e., imagine a tiny monitor with one single line of text that you pan (i.e., scroll), and nothing besides that. If 20 chars are spaces, you stay with only 20 chars left for the code. A bit more, if you read in Grade 2 Braille, but I don't know whether it would be appropriate for coding, I mostly use speech for it, except some cases.
Yet more painful are some code styling standards where you have to align code in the line. For instance, this was the case with tests in moment.js. There the expected values and messages should match their line position so, for example, the opening quote would be in column 55 on every line (this is beautiful to see, I admit). I couldn't get my pull request accepted for more than a week until I finally understood what Iskren (thank him for his patience with me!), one of the main developers, was trying to tell me. As you can guess, this would be completely obvious for a sighted person.
Block Endings
A problem adjacent to the previous one: for me personally it is very nifty when I know that a particular code block ends. A right brace (as in C) or the word end (as in Ruby) are good, indentation level change (as in Python) is not: still some overhead on getting knowing that the nesting level has abruptly changed.
IDEs
Sorry to admit it, but there is virtually no comfortable IDE for the blind. The closest to such an IDE is Microsoft Visual Studio, especially the latest version (gods bless Jenny Lay-Flurrie!), Android Studio seems also moving towards accessibility starting with version 2. However, these are not as usable, nifty and comfortable as they are for the sighted users. So, for instance, I use text editors and command-line tools to write, compile and debug my code, as do many blind people around me.
Ballad of the snake_case, or Another Holy War
Yet another thing to blame Python about: camelCase is far more comfortable to deal with then snake_case or even PascalCase. Usually screen readers separate words written in camelCase as if they were separated with spaces, so I get no pain readingThisPartOfSentence.
When you write code, you have to turn your punctuation on, otherwise you'll miss something really tiny and "unimportant", such as a quote, a semicolon or a parenthesis. Then, if your punctuation is on, and you read my_very_cool_descriptive_variable_name, you hear the following: "my underline very underline cool underline.... underline underline underline!!!" (bad language and swears censored). I tried even to replace underlines with sounds (yes, my screen reader gives such an opportunity), but the sounds can't be so well synchronized because of the higher speech rate I use. And it is quite a nightmare when dealing with methods and properties like __proto__ (aha, there are two underscores on both sides, not one, not three - well, got it right, I think!), __repr__ and so on, and so forth. Yes, you might say, I can replace the word "underline" with something really short like "un" (this is also possible), but some overhead is still here, as with white spaces and code nesting.
PascalCase is far better but it implies a bit more concentration, also, since we need to remember putting the first capital letter (oh, I'm too fastidious now, let it be PascalCase, but not those under... oh well, you got it already). This was the reason I gave up with Rust, btw.
Searching for Functions
As I have already told you, IDEs are not good for us, so text editor is our best friend. and then, you need to search for functions and methods, as well as for classes and code blocks. In certain languages (not Python this time), there are no keyword that would start a function (see, for example, C or Java code). Searching for functions in these conditions becomes quite painful if, for example, you do know that you have a logical error somewhere in the third or fourth function in the file, but you don't exactly remember its name, or you skim through someone's code... well, you know, there are lots of reasons to do that. In this particular context, Python is good, C is not.
Multiple Repeating and Alike Characters
This is not a problem per se, but a circumstance that complicates debugging, for example, regular expressions or strongly nested operations like ((((a + ((b * c) - d) ** e) / f) + g) - h. this particular example is really synthetic, but you get what I mean: nested ternary operators (that I love, btw!), conditional blocks, and so on. And regular expressions, again.
The Ideal Language
The closest to the ideal blind-friendly language as for me is the D language. The only drawback it has is absence of the word function except for anonymous functions. PHP and Javascript are also good, but they have tons of other, blind-unrelated drawbacks, unfortunately.
Update about Go
In one of his talks Rob Pike, the main developer of the Go language said that no one likes the code style imposed by the Gofmt utility. Probably, no one — except me! I like it, I love it so much, every file in Go is so concise and good to read, I'm really excited about the language because of that. The only slightly annoying thing for a blind coder is when a function has several pairs of parentheses in its definition, like if it is actually a struct method. the <- channel operator still gives me moments to think about what I'm doing, sending or receiving, but I believe it's a matter of habit.
Update about Visual Studio Code
Believe it or not, when I was writing this answer and the first update to it, I wasn't working as a full-time developer — now I am. So many circumstances went favorably for accessibility and me in particular! Slack, that virtually every business uses, became accessible, and so became Microsoft Visual Studio Code (again, gods bless Jenny and her team!). Now I use it as my primary code editor. Yes, it's not an IDE per se, but it's sufficient for my needs. And yes, I had to rework my punctuation reading: now I have shorter and often artificial names for many punctuation signs.
So, calling from end of January 2021, I definitely recommend Visual Studio Code as the coding editor for blind people and their colleagues. What is even more amazing is that LiveShare, their pair programming service, is also accessible! Yes, it does have some quirks (for now you can't tell what line in the file your colleague is editing if you're blind), but still it's an extremely huge step forward.
I've a friend who wants to learn web programming. He's a physically handicapped person. Actually he uses computer with a trackball and he can press keys one by one and only with one hand. So, I think that his greatest problem will be trying to write special characters that require the use of two hands (such as >,!,#, etc.). First I thought in Visual Studio (Intelissense can be a great help) but does anybody know about tools that can make even easier programming?
I know is an odd question but I'll really appreciate if someone could give me a hand here :)
Thanks in advance
Several companies make programmable keyboards, keypads and footswitches that would make for easy access to those characters normally accessed with the shift key. Some are used as supplements to a standard keyboard, others replace the standard keyboard.
They're designed so you can apply your own labels to the keys according to the functions you assign. Some have software that lets you assign multi-step macros to single keys.
Lots of examples of such products here: http://www.fentek-ind.com/program.htm (just the first page I found with Google)
Another feature worth being aware of is Sticky Keys - on Windows, hit SHIFT 5 times in a row fairly rapidly to turn it on. When Sticky Keys is on, modifier keys like SHIFT, CTRL, and ALT 'stick' until the next key is pressed: so if you want to type the ! character, you can do so by pressing SHIFT and then pressing 1, without having to press both at the same time.
(Note that Sticky Keys turns itself off automatically if you do hold down SHIFT and another key at the same time - but you can turn this feature off so that it stays on all the time via the control panel.)
Not sure how useful speech-to-text will be; it tends to be fine-tuned for English words that you'd find in a dictionary, I'm not sure that it would cope very well with either the heavy use of symbols or the use of non-english text found in most languages (eg printf!).
This answer may seem a bit late, but I hope it will be usefull to many:
A very good program to know, allowing one to input with only 2 movement (be it with a mouse, a joystick, a finger, a toe, the head, eyeballs, etc), and which could allow one to type quite fast once used to it : dasher (wikipedia page), that you can find on : dasher official site
It's surprisingly easy to learn and get into : you "aim" for the next letter, and it grows while going toward your pointer. Once you enter it, on the far side you see the next letters appear, with the most probable ones much bigger than the others (ex: "e" is usually the biggest for the first letter, but once in it, "n" will be quite big as it's a probable next letter. When you have crossed through "ente", "r" will be very big and easy/fast to aim. If you "exit" (by going above or below or by going back) the current letter, it deletes it and therefore you can select another one to replace it. See the wikipedia page for a nice animation showing how it's done.
You can have Dasher use (and train on) specialized dictionnaries to have the most useful letters bigger and therefore easier to "type" (usefull if you intend to do programming, for example. By default the dictionnary is to write letters/mails/etc)
I'm writing a parser to parse CSS.
I started by modifying the CSS reference grammar, to use whichever grammar and lexer syntax are supported by the 3rd-party parser generator tool which I'm using.
I think that I've finished coding the grammar: the parser-generator is able now to generate state transition tables for/from my grammar.
The result (the output from the parser-generator) is approximately 116 "rules", which correspond to 116 cases in a switch statement. Examples of these rules/switch statements are:
Stylesheet begins with specifying a charset
Stylesheet begins without specifying a charset:
Stylesheet is empty
Stylesheet begins with whitespace
...etc...
The parser-generator has done all it can for me, and now I'm begining to write (by hand) the various cases of the switch statements, which will build what I think people call an 'abstract syntax tree'.
My question is about how to test this. I think that what I want is a set of CSS files which exercise the various combination and possibilities: e.g. one CSS file which specifies a charset; another file which doesn't specify a charset; etc.
Is there general a way to auto-generate this set of input data, for an arbitrary grammar or set of rules?
Alternatively, is there a set of specifically CSS files, whose purpose is to cover the combination and possibilities allowed by the standard CSS grammar?
Feel free to comment too if I'm going about this all wrong.
At the moment I don't need:
Files to test handling of illegal input (i.e. of files which don't conform to the grammar)
Testing of how various browsers render based on their parsing of CSS
Microsoft made a set of many thousands of CSS tests for IE8 compliance with the CSS spec.
http://samples.msdn.microsoft.com/ietestcenter/css.htm
While they are focused on testing browser compliance, possibly you could adapt them.
There are also the older W3C test suites, which are not as complete, but might serve your purpose:
http://www.w3.org/Style/CSS/Test/
A context free grammar implicitly proposes an infinite set of (parse) trees. Each proposed tree has a set of leaves which make a concrete sentence in the language accepted by that grammar. By exploring the the set of proposed trees (e.g, by expanding each nonterminal according to it possible alternatives), you can generate any arbitrary instance of the language. You can generate a set of tests by walking the tree proposals and making random choices. A more focused approach would be to use iterative deepening search to generate sentences ordered by size. With any interesting grammer, you're likely to get a huge number of instances, but hey, that's what automated testing is for.
What I wouldn't do is generate such sentences from your production grammar, because the sentences you generate will be, by definition, the ones it accepts :-{ What you should do is construct your sentence generator using the reference grammar, to exploit the fact that you what it accepts and what you've implemented might be different.
4 years late for OP but SimonSapin/css-parsing-tests seems like a decent test suite for parsers.
I try to externalize all strings (and other constants) used in any application I write, for many reasons that are probably second-nature to most stack-overflowers, but one thing I would like to have is the ability to automate spell checking of any user-visible strings. This poses a couple problems:
Not all strings are user-visible, and it's non-trivial to spearate them, and keep that separation in place (but it is possible)
Most, if not all, string externalization methods I've used involve significant text that will not pass a spell checker such as aspell/ispell (eg: theStrName="some string." and comments)
Many spellcheckers (once again, aspell/ispell) don't handle many words out of the box (generally technical terms, proper nouns, or just 'new' terminology, like metadata).
How do you incorporate something like this into your build procedures/test suites? It is not feasible to have someone manually spell check all the strings in an application each time they are changed -- and there is no chance that they will all be spelled correctly the first time.
We do it manually, if errors aren't picked up during testing then they're picked up by the QA team, or during localization by the translators, or during localization QA. Then we lodge a bug.
Most of our developers are not native English speakers, so it's not an uncommon problem for us. The number that slip through the cracks is so small that this is a satisfactory solution for us.
Nothing over a few hundred lines is ever 100% bug-free (well... maybe the odd piece of embedded code), just think of spelling mistakes as bugs and don't waste too much time on it.
As soon as your application matures, over 90% of strings won't change between releases and it would be a reasonably trivial exercise to compare two versions of your resources, figure out what'ts new (check them first), what's changed/updated (check next) and what hasn't changed (no need to check these)
So think of it more like I need to check ALL of these manually the first time, and I'm only going to have to check 10% of them next time. Now ask yourself if you still really need to automate spell checking.
I can think of two ways to approach this semi-automatically:
Have the compiler help you differentiate between strings used in the UI and strings used elsewhere. Overload different variants of the string datatype depending on it's purpose, and overload the output methods to only accept that type - that way you can create a fake UI that just outputs the UI strings, and do the spell checking on that.
If this is doable of course depends on the platform and the overall architecture of the application.
Another approach could be to simply update the spell checkers database with all the strings that appear in the code - comments, xpaths, table names, you name it - and regard them as perfectly cromulent. This will of course reduce the precision of the spell checking.
First thing, regarding string externalization - GNU GetText (if used properly) creates string files that are contain almost no text other then the actual content of the strings (there are some headers but its easy to cause a spell checker to ignore them).
Second thing, what I would do is to run the spell checker in a continuous integration environment and have the errors fed externally, probably through a web interface but email will also work. Developers can then review the errors and either fix them in the code or use some easy interface to let the spell check know that a misspelling should be ignored (a web interface can integrate both the error view and the spell checker interface).
If you're using java and are storing your localized strings in resource bundles then you could check the Bundle.properties files and validate the bundle strings. You could also add a special comment annotation that your processor could use to determine if an entry should be skipped.
This method will allow you to give a hint as to the locale and provide a way of checking multiple languages within the one build process.
I can't answer how you would perform the actual spell checking itself, though I think what I've presented will guid you as for the method of performing the spell checking.
Use aspell. It's a programme, it's available for unixoids and cygwin, it can be run over lots of kinds of source code. Use it.
First point, please don't put it into you build process. I would be a vengeful coder if I (meaning my computer) had to spell check all the content on the site every time I tried to debug or build a new feature. I don't even think this kind of operation belongs as a unit test (you're testing a human interface, not a computerised one).
Second point, don't write a script. You're going to have so many false positives fall through the cracks that people will stop reading the reports and you are no better off than when you started.
Third point, this is probably most easily solved by having humans do it: QA team, copy writers, beta testers, translators, etc. All the big sites with internationalised content that I've built had the same process: we took the copy from the copy writers, sent it to the translating service/agency, put it into the persistence layer, and deployed it. Testers (QA, developers, PMs, designers, etc.) would find spelling or grammatical mistakes and lodge bug reports. There is just too much red tape and pairs of eyes for that many spelling/grammar errors to slip through.
Fourth point, there will always be spelling and grammar mistakes on your page. Even major newspaper web sites haven't gotten around this and they have whole office buildings filled with editors.