You seem to be missing my point on a number of things, so I've tried to clarify below. Some portions deleted to save some bandwidth.
On Sep 18, 6:19 am, Dennis <[EMAIL PROTECTED]> wrote: > On Sep 17, 2008, at 2:59 AM, NZIBIS wrote: > > > 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! > > So your issue is not with completion parsing performance (which is > what I was testing with a large log file), but rather with the number > of matches showing up in the completion list? No, both of these things. I *am* seeing slower performance when working with completion on. > Have you tried typing a > few more characters of the term you're looking for? > Often, just one or > two more characters will greatly narrow-down the number of matches. Forgive for this sarcasm, but "well, d'oh, you don't say!" :-) Its a little obvious ;-) Its not the point I'm making. > I've tried the completion feature on a variety of documents with a > large amount of plain english, and I don't really see any problems. > But it's a personal thing, based largely on individual preferences and > work style. Performance and spending time getting out of completions isn't *just* a personal thing as you suggest. The former affects anyone and the latter is, as I wrote, effectively taking away a person's normal way of working with a document, a point I don't think you're "getting"--more on this below. > > 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. > > Hmm, I've never really felt "trapped" by the completion menu. Have you > tried hitting the Return or Esc key? Of course, and its actually an example of I'm talking about: not a solution, but an example of the problem. The Return has a normal editing function, why should that use be taken away from me? And likewise, why should I even have to enter Esc. I think you are completely misunderstanding my point (read on first). Apple has a "positive action" concept with user interfaces, based around the USER having control. If the user wants something done, they do a positive action to evoke it. You try avoid putting users into an "action" then force them to do a negative action to get out of it. Here I'm being put into an action I didn't ask for via a positive action of mine and now have to "escape" it. On top of that it messes up use of several widely-used normal editing keys because they now have differing meanings dependent on a time-evoked event out of my control, e.g.: up-arrow, down-arrow and Return. If, for example, the completion pops up in the fraction of a second before I press one of these keys, the effect is that these editing keys do not have the meaning I am intending them to have. The do not, respectively, move me up, down or start a new line of text. In fact, in cases they will change the document in way I then have to undo. The delay is a red herring: forget it. Increasing the delay before completion starts will reduce, but not eliminate these issues, as the underlying issues are still there. The issue to me comes down to that there is no single positive action from the user that says "I want to enter completion". Rather, you are placed in it whether you want it or not, then have to get out of it. This works OK(ish) if you type space or a punctuation character is it lets you "out" in a fairly natural way, but it conflicts horribly with the characters used to move around the document, as they're also used to work on the completion list. It seems to me that, ugly as it might be to some, it may need a unique character that is NOT a character routinely used in editing the text of the document that says "I want to enter the completion list" now. Positive action. Alternatively, the characters used to move around the completion should ones not used in editing the main text so that ALL of the "natural" editing keys let you "out" and have their normal effect. You can do the latter, but if you are going to have a feature working "automatically" like this, you need to be very careful its not taking control away from the user, or forcing them into "negative" actions to get the behaviour they want. Users don't like losing control or having a program force on them want are to them unnecessary steps. > > 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. > > That's an interesting idea, but I think I still prefer to see the > entity itself rather than the rendered value. After all, I am editing > the source of the document. :-) I think you're missing my point about the appropriate place for translations. In needs a bigger viewpoint looking at several otherwise unrelated things & I'm out of time to explain it right now. > One option that might work for your idea, however, is to create a > variety of HTML entities as clippings, using the entity for the > inserted value and the "rendered" character for the name of the > clipping. > > I'm not sure how well that would work, but the completion list seems > to favor clippings, sorting them at the top. I guess it might not help > in cases where an entity is embedded in an existing word, but this > approach might help in inserting new HTML entities. I was really thinking more along the lines of something build-in, leaning on the fact that its generally easy to type most of the characters concerned on a Mac, e.g. type alt-k for the degree symbol, or to enter them via the character palette and it ought to be simple enough to have BBEdit replace these on-the-fly with their entities without the user's intervention. (In principle this could even be behind the scenes, with the disk copy having the entities and the screen showing the characters as rendered, but that raises issues of its own and conflicts somewhat with the role of a source-level editor if not optional.) --~--~---------~--~----~------------~-------~--~----~ 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. -~----------~----~----~----~------~----~------~--~---
