Just a few quick comments: Dennis wrote: > On Sep 16, 2008, at 7:42 PM, [EMAIL PROTECTED] wrote: > > > On 15-Sep-2008, at 23:14, NZIBIS wrote: > >> I'd like to see an option that allows the competion to only work on > >> text within the tags. > > > > I would be happy if I could disabled dictionary completion, full stop.
I don't think its dictionary completion as such, but rather from words already in the document. Try a small document and see what happens. I checked this, as this is what you'd expect to complete identifiers, etc. in (say) Java, C, etc. > I really *like* the dictionary completion, so disabling it would have > to be optional. I find the little icons to the left of the completion > matches go a long way in helping me quickly choose an appropriate item. My suggestion was for it to be optional, but for the option to be matched against the document type. I'd want it off in HTML, on for C coding, for example. You could in principle take this further select what portions words are to be collated from (comments, plain text, print strings, etc.) The icons to the left are nice. > >> But long HTML documents can get an awful lot of English (etc.) > >> words, which then "crowd out" the tags or attributes and their > >> values which, to my mind, overwelms it. > > > > On a very long document (I was in one that was 10K lines long) the > > completion can seriously bog down the process of editing as well. > > Hmm, I'm not having any problems in this area. When you say "bog > down", do you mean a performance issue or that there are simply too > many choices in the list? > > I just tried auto-completion in a log file of some 200K lines and > performance seemed perfectly acceptable, although perhaps a bit less > responsive than a smaller file. I also had no problem with the number > of matches in the list, but maybe that has more to do with the type of > content rather than the number of lines. I don't think a log file is a good choice: log files need to just a limited collection of phrases. You really want to test with something that uses "plain" English. Some of the completions I have must have 30-40+ possible completions! With a long HTML document, it does slow things down and I find myself constantly getting "trapped" inside the completion menu, resulting in frustrating attempts to try break out of it. A problem here may be that completion effectively takes control off the user's use of some of the keys otherwise used for editing text. There might be a need for, say, ctrl-down arrow to be used, rather than just a down arrow, so that the conventional text-editiing use of these keys can be retained by those who use them extensively. > >> I'm also finding that it is offering "words" containing character > >> entities, e.g. "that’s", which I'm in two minds about. > > > > That is one thing that I do like, since otherwise fixing those things > > is a matter of an extra grep > > Yes, I like the current behavior as it is too. I wrote that I had mixed feelings about this, not that its wrong ;-) I need to explore BBEdit more, but I can't yet find a way generate character attributes by just typing the character through a translation mechanism or the like. The reason I mention this, is I'd prefer to see the entities "rendered" in the list as the character, not as the code and have any translating to entities later. Reading the coded form of the entities forces you to "reverse interprete" the entity (e.g. ’) to figure out what it is. They're fairly hard to read, especially as they lie within a string of characters, and you're forced to memorise the entity codes to know what they are. I do happen to know most of the main ones I use, but if they were presented as the character I wouldn't have to, which would be easier on newer coders and for the more obscure entities. Once you have a few of these it slow you down trying to figure out which character entity is meant. For this to work well though it may need an accompanying translation feature, though. > >> I can see that this will be a better fit when you don't also have a > >> lot of English (or whatever), as in the case of programming in, > >> Java, C or whatever, where the words already in the file or project > >> are mostly identifiers, etc., which is no doubt the original > >> thinking. (Here, I think you'd want to ignore words in comments and > >> perhaps the text arguments of "print" statements.) > [ ... ] > So far, I've used completion in PHP, JavaScript, HTML, and in writing > prose, and I've been very happy with it in all cases. While I can see > why some might like to be able to turn off dictionary or plain english > inclusion, I'm pretty happy with the way it works now. > > Although, I must admit that I did increase the automatic completion > trigger to 1.0 seconds. The default 0.5 was a little too aggressive > for my typing style. I may get around to trying this, but the "trapping" behaviour I'm getting will still be there if I just happen to pause while typing so I consider the "underlying" scheme to be where I'd focus my attention. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BBEdit Talk" group. To post to this group, send email to bbedit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/bbedit?hl=en If you have a specific feature request or would like to report a suspected (or confirmed) problem with the software, please email to "[EMAIL PROTECTED]" rather than posting to the group. -~----------~----~----~----~------~----~------~--~---
