Re: [ jEdit-devel ] Why electric keys need separate modes in their effect?

[Jarek C. <jar...@po...>]

Hi Kazutoshi

W dniu 2012-05-21 03:13, Kazutoshi Satoda pisze:
> Patch A: fails with 02.py
> This is true. But I'm proposing this (DIT) patch as an option to
> achieve sooner release (5.0.x and/or 4.5.x).
>
> And I think 02.py case is a bit unrealistic: the colon after "else" is
> highly likely typed just after "else" and before manual indentation.
> I remember no such case submitted as a bug.

2012-04-18 rick-r in #2332140
https://sourceforge.net/tracker/index.php?func=detail&aid=2332140&group_id=588&atid=100588

>
>> Patch B: I don't understand it. Could you describe the algorithm in
>> words so that I could point its weak sides?
> In the patch, electric keys take effect only when the current level of
> indent is same with the level of auto indent.
Current level means "the level before inserting an electric key". I
missed it first, my fault. Quite a good idea. If it was provided as an
additional mode it could fall into trunk at once. Now you said that you
will commit, when I agree on the design. This is fair, but we could make
things going quicker if you made it the way I suggested. Probably
ambitional background is involved here. Ok. Please give me 2 days to
think it over.

> (...)
> You said ...
> (...)
>   - ... the various modes are necessary to provide different behavior
>     for different user activities.
>     For that, I said manual selection of modes won't fit well into
>     short and often switching between the activities you listed.
It requires only 3 steps: entering global options, choosing the mode,
pressing ok. Not much for me. If too much for an advanced user, he may
set up a macro for that. Other quick switching options may also be provided.
>
>   - ... "brackets only" is necessary to provide a way to effectively
>     remove electric keys without hacking the mode file.
>     For that, I said we should provide an edit box for electric keys
>     for that needs. This is agreed, but the actual implementation can
>     be prioritized lower.
Not only editing the keys, but also ability to revert to original value,
hardcoded in the mode file. So it needs 2 controls in the option pane. A
text field an a checkbox or a button. I thought you were trying to
minimize configuration options.
>   - ... "off" mode is necessary because they were easy to implement
>     and safe.
>     For that, I said nothing. But to be frank, I see this illogical.
>     I'm assuming we can drop this mode if other modes were dropped.
If that is wrong, why haven't you said this earlier? There is a ticket
from 2012-04-02 announcing the change. You didn't comment on that.
https://sourceforge.net/tracker/?func=detail&aid=3514076&group_id=588&atid=350588

The earlier you object and the earlier you show interest in the subject,
the greater the chances to avoid wasting resources. You act only when
the changes you don't like fall in trunk. Not very comfortable for the
others, but well... If after all the best solution is applied, good for
jedit.

Jarek