We are adding JAWS screen reader support into our existing web site and running into an issue with how JAWS is reading within IE11 (we are told to use IE11 for testing). I am using JAWS 2018 Professional.
With the following HTML markup when the JAWS user presses the Down arrow JAWS stops reading after the words "fifteen business" every time. Pressing Down arrow again it reads the remainder of the sentence.
<p>
Your confirmation request will be completed within 5 business days. Please note year end requests often take longer, please expect a ten to fifteen business day completion time.<br/>
Back to Top
</p>
Being a sighted, new-to-JAWS person myself I am wondering if using the Down arrow is the correct keystroke here. This was reported to us (I am a developer) by our testing team and they are using the Down arrow.
Is there different markup that I should be using? Or does JAWS default to reading just a certain amount of text each time? I also tested with NVDA in IE11 and it also stops reading but after the word "requests".
Thanks!
The down arrow is for reading the next line. I'm guessing there's some word wrapping going on that makes all but the last few words sit on the same line. Check out this manual for key commands.
Related
Here's how a text document in Apple Pages might be structured:
CHARACTER #1: Dialogue
CHARACTER #2: Dialogue
CHARACTER #1: Dialogue
Action description.
CHARACTER #1: Dialogue
My question:
Using Applescript, is there a way to detect that the last two dialogue entries stem from the same character, even though there is an action description in between?
CHARACTER names are defined by a paragraph style and always appear in ALL CAPS.
Many thanks for your time!
Disappointingly, the more recent versions of Pages (like 5.5.2, which I have right now) are very limited in AppleScript support. One should be able to access specific properties of paragraphs, including paragraph style (this seemed to be possible in past versions, 5-6 yrs ago), but this is not possible. You'd be better off exporting as an rtf (for example) and using a more complete script-able app -- but guess what? Pages doesn't even support exporting to RTF.
A quick bit of advice: If you do end up exporting as Word document, use the older "doc" version instead of the "docx" (under 'Advanced' setting in export), or at least test between them. docx can kill screenplay-formatted documents (which you seem to be working with).
I'd also suggest that you be more specific with your question, like what the style consists of, and any code you've actually tried (which is considered basic form here on StackOverflow).
I am writing a Visual Studio extension which provides intelliSense for a certain content type.
The problem that I am facing now is the effect of "Auto Indent" that Visual Studio provides on empty lines when user types a character.
Here a completion session started on an empty line (over virtual spaces):
Notice the tab symbols on the other lines and no tab on the line with caret on it.
Now when use starts typing, VS automatically and correctly adds necessary tab characters to the line:
Now the problem is those Added tabs apparently become part of the user input and as a result CurrentSession.SelectedCompletionSet.SelectBestMatch() or Filter() method cannot find the current item which starts with "C" here (thinking user has typed \t\tC instead).
If I start the session on anywhere else which does not require auto indent everything works fine.
Any idea?
Edit (more information): I used a code flow very similar to:
Ook here
vsLua here
vsClojure here
In Lua and Clojure you wouldn't face this problem because they never provide intelliSense on virtual spaces (meaning they always start after a certain set of characters) and if you start after a character virtual spaces are already turned into real spaces.
Ook on the other had has the same problem.
Revised Answer:
Ah, I see. I interpreted your question thinking that you were referring to completion triggering via typing, not from the explicit command. If you enable "show whitespace" for the C# editor, you can see what we do here: when you trigger the "show completion" command, we explicitly realize the whitespace so you're no longer floating around in virtual space. You should probably do this as well. (Alternatively, you could detect the scenario and fix it up on the first typing by adjusting your ApplicableTo span, but that's probably not worth the trouble.)
You can get the whitespace that should be inserted from IEditorOperations. So MEF import an IEditorOperationsFactoryService, and then do:
var editorOperations = editorOperationsFactoryService.GetEditorOperations(textView);
var whitespace = editorOperations.GetWhitespaceForVirtualSpace(textView.Caret.Position.VirtualBufferPosition);
if (whitespace.Length != 0)
{
textView.TextBuffer.Insert(textView.Caret.Position.BufferPosition, whitespace);
}
(Funny aside: as I answered this, I was curious to see how we handled this in the Roslyn C# and VB editors. The answer was "not", but filtering still worked by pure luck later in the code.)
Original Answer:
I suspect by your description of the problem that you are implementing your completion like this: you know a character is about to be typed (either via a keyboard filter or IOleCommandTarget) and you trigger an ICompletionSession, where the tracking span is an empty span on the current caret position.
The best approach to fixing this is to not trigger the session before the key is pressed and goes into the editor, but rather after it. This is what we do in the Roslyn implementation for C# and VB completion. Then, when you are in your AugmentCompletionSession call and creating your CompletionSet, compute the "applicable to" span which consists of the non-whitespace characters around your caret. The easiest way to compute this might just be to call GetWordExtent from the text structure navigator.
This allows for other scenarios to work right. Consider scenarios where the user types C, presses escape, and then continues to type your identifier. If you want to trigger completion again, you'd have to do the math to ensure that the "C" is counted as part of your span anyways.
I've been using BBEdit for years, but I've just started using TextMate because I find it has better support for Ruby on Rails than BBEdit (please don't start a flame-war over this!).
One thing I really miss is that BBEdit can add 1/2 or 1/1 page of empty space below the document (without adding lines to the actual document). This means that I will never have to write code at the very bottom of the window/screen, but I can always scroll the page to get the current line at a comfortable hight on the screen, even if it is the last line in the document.
Now, this might seem minor, but after using TextMate for a few days, missing this feature is really starting to bug me.
On the off chance that there is a setting I missed, or that there is a plugin or something out there, I thought I'd throw the question out here. If you know of any way to replicate this behaviour in TextMate, please share!
There is now an option in TextMate 2 to scroll past the end of the document.
This might be rather a late answer but i am posting b/c this question is high in google. Looking for the same issue i found:
PageFeed
PageFeed is a TextMate plugin that allows one to scroll past the last line of a document.
Its not perfect but for most cases its all you need: https://github.com/ampt/PageFeed
I don't think I've ever witnessed a flame war involving BBEdit.
No, TextMate doesn't allow that.
You could create a macro/snippet to add a bunch of \n at the bottom of the file.
Vim, Emacs and Sublime Text all allow this and have better RoR support than BBEdit.
Lacking a scrolling margin, especially at the bottom, when searching in text, is the most frustraing thing in Notepad, Word, Excel, etc. and is enough by itself to make me hate the products on almost a daily basis. EDT, TPU, etc, were great text editors which had this feature (maybe they introduced it) and, now that I've found Emacs emulates them, I use it all the time, and text editing life is good again. I can't understand how most of the world accepts the crazy situation of using a text editor that is worse than those in vogue 20 years ago.
For those who aren't clear about the concept or benefits of a scrolling bottom margin, it is not just about adding empty space below the document, but it also lets you see the context of text found in a search. Without a scrolling margin, the cursor is almost invariably positioned at the bottom line of the screen on the item found, and then to see what comes next you have to manually scroll further down. With a scrolling margin, the cursor and found text are repositioned above the bottom of the screen by the margin amount, letting you see the found text and all the text surrounding it. With repeated searches of the same text, this is a huge timesaver.
Is there anybody who knows the history of appearance of Ctrl+Enter ↵ hotkey which means "Send"? It is pretty "classic" now. I remember that for the first time I've met that hotkey in ICQ 99, but now almost every IM have such hotkey and many popular social networking sites. Some time ago I was surprised that in the "Commit" dialog of eclipse IDE that hotkey also available with the same meaning.
I think Ctrl+Enter ↵ doesn't mean "Send". It means, "double-click", or "do the default".
In email clients Ctrl+Enter ↵ was the shorcut for finish-editing-and-send. I remember using it in Microsoft Internet Mail and News back in Win95 days. Probably Mirabilis copied it for ICQ and others copied from ICQ.
Of course, it's impossible to answer something like this for certain, but I'll offer myself as a candidate for creating this standard.
In the summer of 1992, I was a junior programmer at America Online (AOL), working on what was to be version 1.0 of the Windows AOL client software. Part of my duties included refining many of the UI forms, including E-mail composition and Instant Message composition. Like many techies of that era, I was a keyboard jockey... using a mouse just slowed me down. I wanted a way to send messages quickly. Some of my colleagues suggested that I could just hit TAB until input focus was on the "Send" button, then hit the spacebar to activate the button. That was true enough, but for me the problem was that every composition form was structured differently... maybe the E-mail form needed Tab ↹ Tab ↹ Tab ↹ Space , while the IM form needed Tab ↹ Tab ↹ Space . Sometimes it even varied for new messages vs. replies. Yuck.
One day I became tired of the inconsistency, and decided to add a consistent keyboard shortcut for "Send" to all composition forms. My first choice was actually the Enter key on the numeric keypad. Seemed easy enough, but I soon realized that many people used the numeric keypad to move the input cursor, and would sometimes mistakenly hit the Enter key, prematurely sending their message. Not good. Next beta release, I changed all those shortcuts to Ctrl+Enter ↵, with the idea that it was virtually impossible to press Ctrl+Enter ↵ by mistake, but quite easy to hit that key combo with one hand if that was your intention.
There were no reported complaints about that shortcut, nor did I explicitly document it anywhere. However, before long, various "guides to America Online" had published the shortcut, and it remains to this day, AFAIK. At the time I selected that shortcut, I was not aware of any other software that used Ctrl+Enter ↵ to mean "Send".
Over the following few years, the Windows America Online client was arguably the single most popular way to send online messages, and I know the Ctrl+Enter ↵ shortcut became very popular amongst power users. This solidly predated Windows 95 and its related apps. Was this the true genesis of the shortcut? I don't know for sure, but I like to think so. :)
I think the first, and probably still most obvious, use for Ctrl+Enter ↵ was to insert a new line, in a text box where usually you don't need more than one line, and thus the simple Enter is used to confirm the entry.
In applications where you do need to enter many lines, such as e-mail clients, it comes natural to do the opposite, that is assign Ctrl+Enter ↵ to the function normally associated with simple Enter (usually confirm the entry, which can be regarded as send the message in an e-mail client).
I don't have historic references, so I can't say for sure, but I saw Ctrl+Enter ↵ used for line inserting a lot earlier than seeing it used to send a message.
The thing is that it's usually an hidden use, in that you rarely need it and is rarely documented, but if you try you'll see a lot of apparently single-line text boxes accepting a Ctrl+Enter ↵ to insert a new line, and that often turns out as a big time-saver and a major increase in the usefulness of the functionality.
The shortcut is probably harmed significantly by the use of Alt+Enter ↵ in Excel to enter new lines, with Ctrl+Enter ↵ left for a more obscure functionality (and probably just as a side-effect for confirming the entry without moving to another cell). It's likely that more people know about this than the (to my knowledge) much more widely used Ctrl+Enter ↵.
Of course it's also possible that Alt+Enter ↵ came first, I'm not really a software historian
The scrollbar scrolls way past the end of my class. Is there any way to adjust this? Is it just the VS convention? I can't delete the space, so it isn't carriage returns.
The reason I don't like this is that I keep accidentally scrolling past the end of my class!
I'd especially like to hear from people who actually have Visual Studio 2008 installed ;)
Either you have extra newlines (the cr/lfs Jim Anderson was talking about) in which case you can just select all the blank lines and hit delete to get rid of the extra space. The other possibility is that what you think is blank space is just the IDE letting you scroll down one page past the end of the file (until the last line of the file is at the very top of the screen). This is to let you scroll to the bottom of the file and start typing without causing the screen to scroll every time you start a new line.
Edit:
A quick glance at the other editors on my computer shows that this sort of thing is common - CodeWright will let you keep scrolling down as far as you want (pages and pages past the end of text) - although it does show the scroll bar as being all the way to the bottom when the bottom of the file is in the middle of the screen of text.
Even basic tools like Query Analyzer have this.
This is a feature (no, not a bug relabeled a "feature").
Reboot? No seriously, more information is needed.
I am guessing you have CR/LFs you you need to delete.