On 8/12/13, David A. Wheeler <dwhee...@dwheeler.com> wrote:
> On Sun, 11 Aug 2013 09:33:35 +0300, Beni Cherniavsky-Paskin
> <c...@users.sf.net> wrote:
>> A natural keystroke would be M-C-d / M-C-u (down/up-list) as if you were
>> really moving across a "(".
>> There should be visual feedback, a-la match-parens. With feedback I
>> think
>> you also want Right/Left to move across the virtual "(".
>
> Sounds sensible.
>
>> The deeper you go into the rabbit hole of pretending there is a paren,
>> the
>> harder it is to implement consistently - e.g. saving & restoring point
>> should preserve this state (including via save-excursions!) - except by
>> actually having an invisible char in the buffer.
>
> I don't think that's all that necessary, as long as there's visual feedback
> of the scope. In particular, invisible chars are nothing but trouble
> (you could store that info in a separate file without problems).
>
>> n-exprs present another ambiguity:
>> |foo(bar)
>> moves over foo or foo(bar)?
>
> Ah, excellent point. Basically, there are *two* ambiguities:
> * At the beginning of a t-expr that isn't a mono n-expr,
> do we mean the first n-expr or the whole t-expr?
> * At the beginning of an n-expr that has a tail,
> do we mean the prefix, the whole n-expr, or in between (partial tail)?
>
> I think a plausible default would be, if you're at the *very* first char
> of the expression, choose the longer one, and have a keystroke that
> can progressively change the scope (narrowing until you can't narrow more,
> and then cycling back).
Sounds good, but I doubt "cycle back" is a good idea; suppose that the
user has a sequence like so:
cond
! foo(bar) $ do-on-foo()
! qux(bar) $ do-on-qux()
! meow(bar) $ do-on-meow()
! bar $ do-on-non-false()
Now suppose the user wants to do some text editing on each of the
conditions in each clause, and it so happens that this editing
requires use of the scope-narrowing key a certain number of times.
This works on the first two cases (the user is able to correctly
select the whatever he or she wanted to select and to perform whatever
he or she wanted to transform) so the user "programs" his or her hands
to do tap the scope-narrowing key automatically the required number of
times on each clause.
However, the last clause fails because the scope-narrowing key cycles
back to (say) the full clause, which isn't what the user wanted.
User: Damn You Muscle Memory!
So, I think it's best for the scope-narrowing key to *not* cycle, but
instead, will saturate to the narrowest possible. The narrowing then
gets canceled on a cursor-movement command (is that possible in
emacs?) or escape key. The last possibility is a "unnarrow" key which
cancels all scope-narrowing (but I think it's best to allow cursor
movement to automatically unnarrow).
Sincerely,
AmkG
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
