eas-lab@absamail.co.za wrote:
>> > Key-board vs. 'heads up flying' is a separate issue; where 'heads up'
>> > allows you to position the cursor to a different task-window
>> > immediately
>> > [for a serious poplog session, I end up with 6 terminals - got to take
>> > notes & search existing files etc.]
>>
Chris Dollin <kers@hpl.hp.com> wrote:
>> 6 terminals or 6 windows?
>
> Terminals because I don't like xved.
Oh. Weird. Why? I like my ved windows to be sharing state.
>> Also, I don't know what your "heads up flying" distinction is about.
>
> The 'air force', who know what they are doing, have rightly realised
> that the best way is not to have to look down to the instrument panel,
> but to "just control the cursor which is in the same 'view' as the rest
> of the data". See the analogy ?
No.
>> > I don't even KNOW about <completion>.
>>
>> It's whatever you have to type to do completion in the editor. I don't
>> have it, but it would be easy to implement in ved (pick a boring key
>> sequence, bind it to a function that looks left for a word, looks it
>> up in a completion table, and fills in the found template.)
>>
> Yes I know WHAT completion means; just not that it's available for poplog
> ? If I've missed the availability of 'completion' for ved, imagine what
> else I've missed !
Of *course* it's "available"; you can extend Ved with user-defined code.
If you want it, you can have it. As I briefly noted, you just have to
bind a procedure [or name] to a key-sequence and have it poke around
in the Ved buffer.
>> > If there are < 6 possible choices at some stage of the source text,
>> > I don't want to have to think/remember, but just select.
>>
>> Are there such places? Not many of them, surely.
>>
> Indeed many. Look at the 'branching points' on the syntax diagrams.
Pop doesn't *have* syntax diagrams. We are talking Pop here, aren't we?
Examples.
>> >> You certainly *want* some syntax-oriented operations in an editor.
>> >> That's a far cry from forcing them on people.
>> >
>> > Sure. After a bit of practice, one doesn't look at the menues
>> > when pounding the key-board for spreadsheets
>>
>> I wouldn't know. Are these mouse-menus or key-menus? 'Cos, you see,
>> when someone says "menu" I assume "mouse menu". Mice menus are evil
>> because mousing is a distraction. Key menus are just typing.
>>
> As clearly stated previously "menu is not dependant on mouse" !
I missed that. So the menus are just extended key-sequences, right?
> The essential attribute of a menu is: "able to select from a LIMITED
> set; vs. input a potentially infinite vocabulary from permutations
> of 100 odd keys".
They're just ways of encoding the longer sequences into short ones,
to make them easier to type (when you've learned them) and easier to
learn (I'm assuming visual feedback as required if you go slowly
enough).
> More choice = more error.
Either you type the sequences by reflex, in which case I don't see
that choice-reduction helps, or you wait for the menu to prompt you.
I don't think the equation of choice with error is helpful.
> Save your creativity for higher aspects of designing/programming.
Menus don't save me any creativity. They may (or may not) help with
flow. In general, whether using clunky old ved or whizzy new Eclipse
(ha), the *typing* aspect is the least of my worries. ["How the frell
do I do this perfectly sensible thing in Java?", now *that* is a
concern.]
--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
|