Skip to content
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.

Closing tag with namespace prefix #217

Closed
ruv opened this issue Feb 25, 2016 · 2 comments
Closed

Closing tag with namespace prefix #217

ruv opened this issue Feb 25, 2016 · 2 comments
Labels

Comments

@ruv
Copy link

ruv commented Feb 25, 2016

Any start-tag that contains a prefix is closed incorrectly.

For example, Ctrl+Alt+. command after <p:name> produces </p>.

bracket-matcher version 0.79.0

@winstliu winstliu added the bug label Feb 25, 2016
@Platzer
Copy link

Platzer commented Apr 15, 2016

Hi i was not able to create a pull request: because apm install fails: node-oniguruma
. So i had a look into the code, i think its in tag-finder.coffee in line 134 function tagsNotClosedInFragment. I think a xml specification fulfilling regex would solve this one:

@parseFragment fragment, [], /<((?![0-9]|[xX][mM][lL])\w[-.:\w]*)|<\/((?![0-9]|[xX][mM][lL])\w[-.:\w]*)/, -> true.

I hope this helps.

@MoritzKn
Copy link
Contributor

In the mean time this was addressed by #229, however the regex used in this PR (/<(\w[-\w]*(?:\:\w[-\w]*)?)|<\/(\w[-\w]*(?:\:\w[-\w]*)?)/) is simpler and may leave out some cases.

MoritzKn referenced this issue in MoritzKn/bracket-matcher Feb 26, 2017
Also:
- Fix a bug in an existing spec concerning the matching of self
  closing tags (wrong cursor position)
- Add specs for self-closing tags after the cursor

The problem that is addressed here is that `<foo bar=">"/>` was
previously catched as a normal opening tag. Therfore `(?![^>]*\/>)`
was replaced with `(?:\"[^\"]*\"|'[^']*'|[^>\\/\"'])*>` and to remove
redundency and coplexity the function generateTagStartOrEndRegex was
introduced to generate the affected regexes.

Because we (@ruv and I discussed the regex in the PR) decided to stop
using a negative lookahead in favor of performance and simplicity,
this changed the behavior of the function tagsNotClosedInFragment when
it encounters malformed XML and broke an existing spec that verified
this. However because this behavior was already criticized as not
desirable, I decided to remove the spec.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants