Buggy live editing - unintended backwards editing

[MickeyKay]

I've recently been encountering the following issue, which may be related to newer updates to Chrome. When editing in ST2 (perhaps not an issue in ST3), my changes are reflected in Chrome, however suddenly Sublime will jump to the very end of the file with some strange edit I never made. It's as if Livestyle is somehow picking up changes in Chrome as I'm editing in Sublime, and the two are looping back and forth.

Here's a screencast: http://www.youtube.com/watch?v=OoPgOBUhIpw&feature=youtu.be The problem is most obvious at about 0:55

I'm using: Chrome 32.0.1700.77 Sublime 2.0.2, Build 2221

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3981889-buggy-live-editing-unintended-backwards-editing?utm_campaign=plugin&utm_content=tracker%2F305388&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F305388&utm_medium=issues&utm_source=github).

[sergeche]

Can you enable debug mode as described here and give me some log from ST when this issue occurs?

[MickeyKay]

Hi there,

I keep trying to repeat the issue with debugging enabled, but all I'm getting is:

[MickeyKay]

reloading /Users/Mickey/Library/Application Support/Sublime Text 2/Packages/User/Fetch.sublime-settings Writing file /Users/Mickey/Sites/ANJ - Anjani/wp-content/themes/harmony-child/style.css with encoding UTF-8 Writing file /Users/Mickey/Sites/ANJ - Anjani/wp-content/themes/harmony-child/style.css with encoding UTF-8 Writing file /Users/Mickey/Sites/ANJ - Anjani/wp-content/themes/harmony-child/style.css with encoding UTF-8 Writing file /Users/Mickey/Sites/ANJ - Anjani/wp-content/themes/harmony-child/style.css with encoding UTF-8 Writing file /Users/Mickey/Sites/ANJ - Anjani/wp-content/themes/harmony-child/style.css with encoding UTF-8

[ktml]

I have the same problem with ST3

[bradfloodx]

I'm having this same issue with SublimeText3

[MaxLeo]

I have the same problem with ST2 portable

[MickeyKay]

Additionally, I notice that the extension will often re-order my styles in ST - as far as I can tell this issue occurs at the same time as the previously noted issue. Any progress on this one?

[banderazz]

same problem with ST2 and Chrome 32.0.1700.107 m

[CaptainYarb]

This problem has caused me to turn off livestyle entirely. It completely pisses me off. I love your product, but it's the type of problem that makes you want to find a punching bag at your gym and go to town.

Rather than complaining can I offer a solution?

The problem appears (in my opinion) to be a problem where we are adding styles to the server, the server sends them to chrome, and the chrome developer see's our code and tries to add it with it's live editing tool. Often when we send the data it sends incomplete data such as "background-colo" and discards the data causing the chrome dev tool to instantly publish a change back to the server, which is sent back to your client. Bad grammer in explaining what happened aside it's clear there needs to be a buffer between two clients talking in quick succession.

Solution one: Soft Delays Rather than issuing the changes to the server INSTANTLY you might wait to see if the client has not typed for a variable delay that is configurable in the livestyle console or editor. This way the server or the client has a delay before it takes changes into account. The problem appears to be the conflict between chrome's console auto-complete in style adjustments vs your editor. Perhaps if we are given a chance to complete the line it might be more accurate. At least a half second delay and configurable up to 3-5 seconds for extreme cases.

Solution two: Read Only clients The ability to set a client to read only might be highly beneficial. Chrome's interface is nice for quick style adjustments, but I still always prefer my text editor. By turning off chrome's dev tools for adjustments this might prevent the code from being sent back.

Solution three: File Save only for text editors Giving us a quick second to hit our hotkey to save might give us the ability to control when we send to the server. Sure the instant change isn't there, but it wouldn't bother me personally. Could be an option to enable.

Thanks for creating awesome software.

[MickeyKay]

+1 for these solutions.

On Thu, Feb 20, 2014 at 12:12 PM, Jonathan Yarbor notifications@github.comwrote:

This problem has caused me to turn off livestyle entirely. It completely pisses me off. I love your product, but it's the type of problem that makes you want to find a punching bag at your gym and go to town.

Rather than complaining can I offer a solution?

The problem appears (in my opinion) to be a problem where we are adding styles to the server, the server sends them to chrome, and the chrome developer see's our code and tries to add it with it's live editing tool. Often when we send the data it sends incomplete data such as "background-colo" and discards the data causing the chrome dev tool to instantly publish a change back to the server, which is sent back to your client. Bad grammer in explaining what happened aside it's clear there needs to be a buffer between two clients talking in quick succession.

Solution one: Soft Delays Rather than issuing the changes to the server INSTANTLY you might wait to see if the client has not typed for a variable delay that is configurable in the livestyle console or editor. This way the server or the client has a delay before it takes changes into account. The problem appears to be the conflict between chrome's console auto-complete in style adjustments vs your editor. Perhaps if we are given a chance to complete the line it might be more accurate. At least a half second delay and configurable up to 3-5 seconds for extreme cases.

Solution two: Read Only clients The ability to set a client to read only might be highly beneficial. Chrome's interface is nice for quick style adjustments, but I still always prefer my text editor. By turning off chrome's dev tools for adjustments this might prevent the code from being sent back.

Solution three: File Save only for text editors Giving us a quick second to hit our hotkey to save might give us the ability to control when we send to the server. Sure the instant change isn't there, but it wouldn't bother me personally. Could be an option to enable.

Thanks for creating awesome software.

Reply to this email directly or view it on GitHubhttps://github.com/emmetio/livestyle-sublime/issues/100#issuecomment-35663718 .

[sergeche]

@blazedd thanks for your suggestions, but these are not solutions for LiveStyle. Because it will be just another pointless LiveReload/CodeKit clone.

The problem is that I can’t reproduce this issue by myself. I need some assistance from you guys to find a solution. Can anyone connect with me via TeamViewer so I can debug this issue?

[CaptainYarb]

@sergeche I would gladly assist with debugging this issue, however I fail to see my solution as a degradation of the product itself. Truth be told I was actually looking for these settings before I even started using the product.

Perhaps my explanation wasn't clear enough, but the changes would merely allow us to set a delay between refreshes that would be reset with any changes made to a client and clearly not a reload timer. This means that I can be given a chance to finish my style changes before the browser attempts to render. Personally; it's stressful for me to try to finish code before the browser reloads.

Furthermore solution 2 is already something offered by a similar software that, while unrelated to style editing, allows for very similar operations. http://floobits.com allows you to code at the same time as another programmer, however this creates very similar issues with your editing client. By adding a delay or a read only client this fixes almost all issues.

I lastly think that a save only write is the only option I've given you close to a livereload, however this seems like a preference for the user over anything else.

Perhaps this is my own personality in how I work on things. I am a completionist. I prefer to finish something, but only one thing at a time. I prefer to completely finish it and often I don't really want to be distracted by changes make instantly. There are often times where I am working on a design without any mock-up and I am live-styling, and this is where livestyle shines.

It is a little unusual that a product designed to be a purchased and paid for system wouldn't have features to support a users' preference on the basis of the creator's personal beliefs. It would seem like this would only add to the flexibility of a given system. Not only do these features not have to be enabled by default, but they give developers a sense of control. For those developers that moonlight as designers it's something we really want. It's your product, but it's just not something I'd pay for without a little more control. I'm not trying to be hateful or mean and please do not take this as that.

[sergeche]

@banderazz no, your comment isn’t hateful, I love user’s feedback, even it tells that I doing something wrong :) Here’s what I think about it.

I’ve created LiveStyle because every other live edit tool out there is broken. And broken tools introduce broken workflow.

I receive a lot of requests “Add feature X” from users which are based on broken tools and workflows. I don’t want to add a delay because it’s a workaround, not a solution of the problem. Every single feature introduce complexity to the product and requires explanation for the users. So instead of enjoying live editing that “just works” users will have to struggle with settings and hidden options to workaround problems that tool developers don’t want/can’t fix.

Such buggy live editing in LiveStyle is caused by some unexpected changes trigged by either Chrome or ST. This happens for a small amount of users and I can’t reproduce it. Currently, I’m working on LESS and SCSS support for LiveStyle, and it also introduce a new way to send changes to browser. Maybe it will fix the problem, and if not, I’ll need help from users to debug the problem.