search

formulahendry / vscode-auto-rename-tag

Automatically rename paired HTML/XML tag
https://marketplace.visualstudio.com/items?itemName=formulahendry.auto-rename-tag
MIT License
259 stars 36 forks source link

Does not handle multi-line starting tags #19

Open kylpo opened 7 years ago

kylpo commented 7 years ago

Given code like:

<View
  prop1="1"
>
  <Button />
</View>

Renaming <View will not rename </View>

However, it will be correctly renamed with code like:

<View prop1="1">
  <Button />
</View>

Thanks for this extension! Seems like an idea subtle and good enough to become standard in future editors. I look forward to using it!

formulahendry commented 7 years ago

Currently, this extension does not handle multi-line tags, since it may produce unexpected renaming tag if we do not handle well. I will investigate if it is possible to handle that well.

kylpo commented 7 years ago

Got it - thanks. Really appreciate your work on this!

yerol commented 7 years ago

this is especially important with html templating such as angular templates where we have a lot of attributes/directives on most elements. Great extension but only works half the time because of this limitation.

jessejanderson commented 6 years ago

Any progress on this? I love the idea of this plugin, but since I work in React where many of my tags are multiline, using it actually puts me into a false sense of security because I forget to change the closing tags every single time I edit a multiline tag.

sirius0xff commented 6 years ago

I would suggest an experimental feature that enable multi-line support first.

Adding the following regex to the original start tag regex should solve most of the problem: (?:^\s*(?:<!--\s*)?<(\w)+| ....... )

99% of the time multi-line tag would be the first of the line. It is very unlikely, and probably shouldn't be, that a line is start with < but not a tag. Finding closing bracket is not necessary in this case. It also avoid dueling with attributes that contains <> .

One potential trouble is from comments, but any mess can be written in comments anyway.

Not pretty, but it should cover most of the use case. I believe most users would gladly take the trade.

sunew commented 6 years ago

actually this is related to a hamful bug - if you have a multiline div inside another div, and rename the outer div, the matching is wrong, and the inner closing

is renamed, causing your document structure to break.

example: renaming the first div, causes the closing tag of the <div class="article-text" to be renamed

      <div *ngIf="!submitted_backend">
        <header>
          <h1 class="article-title h2">{{ context.title }}</h1>
          <h5>{{ context.description }}</h5>
        </header>

        <div class="article-text"
             *ngIf="text"
             [innerHTML]="text | transformlinks | safehtml">
        </div>

        <sf-form [schema]="schema"
                 [model]="model"
                 [actions]="actions"
                 [validators]="validators"></sf-form>

        <div *ngIf="formError"
             class="alert alert-danger submit-alert">Fejlene ovenfor skal rettes før formularen kan sendes ind.
        </div>

      </div>
jessejanderson commented 6 years ago

@sunew I've been unable to use this plugin because of this. 😞

I keep an eye on hoping for a fix because I love the plugin, but the projects I work on have a lot of nested multiline divs which causes this to break often.

olee commented 5 years ago

Same here - this is quite the bummer

GiancarlosIO commented 5 years ago

👀

devnoel commented 5 years ago

This is also the case for me. This is an excellent plugin and I absolutely love it, but I can't use it because of this issue.

scriptcoded commented 5 years ago

I would suggest an experimental feature that enable multi-line support first.

Adding the following regex to the original start tag regex should solve most of the problem: (?:^\s*(?:<!--\s*)?<(\w)+| ....... )

99% of the time multi-line tag would be the first of the line. It is very unlikely, and probably shouldn't be, that a line is start with < but not a tag. Finding closing bracket is not necessary in this case. It also avoid dueling with attributes that contains <> .

One potential trouble is from comments, but any mess can be written in comments anyway.

Not pretty, but it should cover most of the use case. I believe most users would gladly take the trade.

@sirius0xff you don't happen to have a fork with this change?