Author Topic: Improved access to macro programming  (Read 763 times)

Margaret

  • Community Member
  • Posts: 70
  • Hero Points: 0
Improved access to macro programming
« on: October 17, 2016, 03:44:45 pm »
There are a couple of features that I'd Really Really Like To Have: 
  • Aliases that expand even in a populated line

    Currently aliases can only be used on an empty line.  Presumably that's so they don't get triggered promiscuously.  But there's a workaround for that:  prepend a trigger char (or substring) selected on a per-filetype basis to create an improbable combination.  E.g., I start my aliases with '<' except in HTML files.  So [space]<[unique_start_of_alias_name][space] avoids crazy-making false positives in non-HTML files.  The choice between current (empty line) and enhanced (prepend, any line) behavior could be a preference item. 
     
  • Hilighting all delimiter pairs, not just parens.

    It should even be possible to declare html tags as delimiters.  If I'm using complex nesting, as I frequently do, it can be a genuine pain in the dupa to figure out who's paired with whom.  And of course it's so much fun to get an "unexpected end of file" because there's an orphaned '}' somewhere.

I'd think these should be standard features because everyone would use them, but maybe not.  So I'd be willing to write them myself---iff I could do so without first spending a month or two studying the not-quite-comment-free macro sources.  I thought I might be able to quickly wedge some code into the alias.e routines to get them to expand wherever they were, but after spending a few hours I really wasn't that much the wiser, and decided that I simply don't have the time to spare.

So I'd like much-improved access to macro development (maybe some routines in addition to say(), perhaps even a primitive ide, plus better commenting and possibly clearer organisation of the files (e.g., there seem to be about 376 different "expand_alias" variants in alias.e and I've still almost no clue about which gets called when).

And it'd still be very nice not to have to write those really-really routines myself.