Re: XML tag completion script

From: <briancsch....at.gmail.com>
Date: Tue, 13 Apr 2010 23:22:41 -0700 (PDT)

New version uploaded here: http://caladbolg.net/textadeptwiki/index.php?n=Main.Xmlcomplete

It now runs from the beginning of the document to the cursor's current
line. This fixes a few bugs by itself. I also fixed the lua pattern
because it wasn't properly handling some tags.

I do, however, refuse to make it handle <br>. It should be <br/>.
<br></br> is, therefore, a valid output of my script. Other silly
behaviors are possible (read: likely) bugs.

- Brian

On Apr 12, 8:05 pm, phayz <russelldicken....at.gmail.com> wrote:
> On Apr 13, 6:35 am, phayz <russelldicken....at.gmail.com> wrote:
>
>
>
> > > On Apr 11, 3:41 pm, phayz <russelldicken....at.gmail.com> wrote:
>
> > > > On Mar 24, 12:59 pm, phayz <russelldicken....at.gmail.com> wrote:
>
> > > > > On Mar 17, 1:10 pm, Brian Schott <briancsch....at.gmail.com> wrote:
>
> > > > > > The line that says "require 'common.xmlcomplete'" is what ties the
> > > > > > commands to the functions themselves. For this to work you need to place
> > > > > > thexmlcomplete.lua in a location that can be found by Textadept. I put
> > > > > > mine in ~/.textadept/modules/common (Thus the "common" in the require
> > > > > > statement My argument being that this code is common to xml, html, and
> > > > > > javadoc comments)
>
> > > > > > - Brian
>
> > > > > > On 03/15/10 20:00, phayz wrote:
>
> > > > > > > I am still unsure of how I enable this script but I need to RTFM a
> > > > > > > little more, also peek and poke around Textadept's directories.
>
> > > > > > > As I understand I have a Lua script, which needs to be run when
> > > > > > > certain key sequences are pressed, and the latter is where the
> > > > > > > "commands.lua for xml (placed in ~/.textadept/modules/xml/
> > > > > > > commands.lua)" comes into play). What I am still struggling with is
> > > > > > > knowing how these two are linked.
>
> > > > > > > Regards,
>
> > > > > > > Russell Dickenson (AKA phayz)
>
> > > > > Brian,
>
> > > > > You have been a great help to myself, other TA users also, I expect.
> > > > > Could you please help me just a little more? I need a dummies guide to
> > > > > enabling this functionality because I have tried many combinations and
> > > > > permutations and just can't seem to get it right.
>
> > > > > Regards,
>
> > > > > Russell Dickenson
>
> > > > Brian et al,
>
> > > > I am seeing odd behaviour from the xmlcomplete script. While editing a
> > > > hypertext document I added a new "<h3>" tag and instead of the closing
> > > > "</h3>" being inserted, a "</td>" was inserted instead. I tried
> > > > throughout the document to insert several different tags and in most
> > > > cases, an "</td>" tag was inserted. The exception was when I put the
> > > > cursor at the very end of the file and typed in an "<head>" tag, when
> > > > the correct closing tag of "</head>" was inserted. Thinking that the
> > > > problem was with this document I created a new sample hypertext file
> > > > and inserted a few standard tags. In this file I couldn't recreate the
> > > > problem, so it looked to be the original document. I then opened one
> > > > of the Textadept manual files, in hypertext format, and again did some
> > > > tests. Again, Textadept was inserting the wrong tag - most often a "</
> > > > td>", sometimes a "</p>" tag. As an example, I open
> > > > "1_Introduction.html", go to the blank line after the unordered list
> > > > for "<h1>Manual</h1>", type in a "<h3>" tag and a "</p>" tag is
> > > > automatically inserted.
>
> > > > This is occurring under both Linux (with latest official Textadept
> > > > release) and Windows (with Textadept 2.2 beta).
>
> > > > I'll do a little more investigation and see what I can find.
>
> > > > Regards,
>
> > > > Russell Dickenson
>
> > > > > On Apr 13, 3:21 am, "briancsch....at.gmail.com" <briancsch....at.gmail.com> wrote:
> > > > > That's a bug. I'll have to figure out what triggers it. Probably the
> > > > > lua pattern not detecting tags correctly. The script scans through the
> > > > > file and builds a stack, pushing when an open tag is found, popping
> > > > > when a close tag is found, and doing nothing when a tag like <this/>
> > > > > is found. Using the auto-complete looks at the stack and inserts a
> > > > > closing tag for whatever is on top. I won't be able to work on this
> > > > > much until Tuesday evening.
>
> > > > > - Brian
>
> > Brian,
>
> > Thanks for your feedback. I have done some diagnostics but haven't yet
> > found the reason for the error. My troubleshooting method is very
> > crude, so it may take me a while.
>
> > Regarding when you can work on this, please take your time. I'm sure
> > that, like me, you have many other priorities. The XML autocompletion
> > script is a great addition to Textadept but life will carry on without
> > it. Thanks again for all your help with this and other aspects of
> > Textadept.
>
> > Regards,
>
> > Russell Dickenson
>
> I have done some further testing but still don't know for certain the
> cause of the problem. My current theory is that you're expecting the
> buffer's contents to be valid XML/HTML with all tags opened and closed
> (if required) in the correct sequence. Of course this is not
> unreasonable, since this is a basic requirement for the validity of
> such formatting methods. However let's say the document is a work in
> progress and that the author makes several mistakes with tags. It
> seems that the script then gets confused.
>
> I have also used a similar non-official plugin for gedit, named
> xmlhelper.py (written, obviously, in Python). If I remember correctly,
> that script started searching the active buffer/file BACKWARD through
> the file, starting from where the caret was located. It looked for the
> most recently opened tag and inserted into the active buffer/file the
> matching closing tag. I'm honestly not sure which is the "best" method
> but I thought it was worth mentioning. No doubt this is one situation
> where there are many methods of achieving the same goal.
>
> Regards,
>
> Russell Dickenson
Received on Wed 14 Apr 2010 - 02:22:41 EDT

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 11:38:54 EST