Rev 585d2f4 improves abbreviations

[Edward K. Ream]

This rev makes minimal changes to the existing (very complex) code.

Please report any problems immediately.

Here are the highlights:

• Match longest prefix first: e;; no longer interferes with date;;
• Predefine 'x' as the empty string before executing abbreviation scripts.
• Split @data abbreviations-subst-env into separate nodes.
  
• Defined do() and insert() functions in @data abbreviations-subst-env as follows:
  

def do(commandName):
    '''Execute a command by name.'''
    c.k.simulateCommand(commandName,event=None)

def insert(s):
    '''Insert the string s in the current widget.'''
    try:
        w = c.abbrevCommands.w
        if w:
            i = w.getInsertPoint()
            w.insert(i,s)
    except AttributeError:
        pass

Note:  Because of a glitch in how abbreviations scripts are created, you can't do::

    do(['command1','command2'])

even though c.k.simulateCommand allows list arguments.  Instead, do this::

    do('command1');do('command2');

The following abbreviations insert matching characters (no need to do x='' in them)::

    (={|{insert('()');do('back-char')}|}
    [={|{insert('[]');do('back-char')}|}
    {={|{insert('{}');do('back-char')}|}

This is an implementation of auto-close-quotes, done entirely with abbreviations! For example, typing '(' inserts '()' and puts the cursor between the parens.

I personally dislike these abbreviations.  I find it harder to skip past the ')' than to type it later.  ymmv.

Your comments please, Amigos.

Edward

[Edward K. Ream]

On Tuesday, April 28, 2015 at 11:22:00 AM UTC-5, Edward K. Ream wrote:

This rev makes minimal changes to the existing (very complex) code.

Drat.  There are some serious problems with restoring the insert point.  I'll attempt a fix immediately, but I don't recommend pulling the latest revs just yet.

EKR

[Terry Brown]

In the unrelated code I just pushed I noticed this works:

w.setAllText(txt)
c.p.b = txt
w.setInsertPoint(i+1) # must come after c.p.b assignment

whereas this doesn't

w.setAllText(txt)
w.setInsertPoint(i+1)
c.p.b = txt

Cheers -Terry

[Edward K. Ream]

Fixed in recent revs.  It was an unrelated issue.  However, somehow it looks like I reverted Terry's push.  I have no idea what git is doing here.

EKR

[Edward K. Ream]

On Tue, Apr 28, 2015 at 11:59 AM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

In the unrelated code I just pushed I noticed this works:

         w.setAllText(txt)
         c.p.b = txt
         w.setInsertPoint(i+1)  # must come after c.p.b assignment

whereas this doesn't

         w.setAllText(txt)
         w.setInsertPoint(i+1)
         c.p.b = txt

​Heh.  That's the drawback of properties: they aren't what they seem.

c.p.b = txt isn't an assignment.  It is really c.setBodyString(p,val) which does a lot.

Otoh, c.p.v.b = txt just sets v._bodyString, which may be what you want, but probably isn't :-)

In general, p.aProperty can be very different than p.v.aProperty. In particular, p.setDirty() is much more expensive than p.v.setDirty().  The former does a redraw, the latter doesn't.

EKR​

 

[Edward K. Ream]

On Tue, Apr 28, 2015 at 11:30 AM, Edward K. Ream <edre...@gmail.com> wrote:

Drat.  There are some serious problems with restoring the insert point.  I'll attempt a fix immediately, but I don't recommend pulling the latest revs just yet.

​I was a bit crazed when I was working on these commits.  I was trying to get them done before an appointment, with the expected (in hindsight) results.

All appears well now.

EKR