I noticed this earlier, but hadn't really quantified it. Sigil is inserting hard line breaks into content so that no line can go beyond the 100 character mark.

Needless to say this isn't particularly desirable even if it's invisible in the final output. Worst impact I've stumbled upon is that when search and replace is added this is going to break some intended searches. I just discovered this the hard way when I copied some code from Sigil into a standard text editor to do a quick regex find/replace - the hard line wraps created a number of situations where my regex no longer matched.

Clarification - apparently the hard wraps are only inserted when opening an HTML source file. Not sure under what other situations they are inserted. Sigil seems fully capable of supporting long lines otherwise.

Clarification - apparently the hard wraps are only inserted when opening an HTML source file. Not sure under what other situations they are inserted. Sigil seems fully capable of supporting long lines otherwise.

I'm sure Valloric would say, please open an issue and attatch a sample HTML source file that shows this problem.

I noticed this earlier, but hadn't really quantified it. Sigil is inserting hard line breaks into content so that no line can go beyond the 100 character mark.

Needless to say this isn't particularly desirable even if it's invisible in the final output. Worst impact I've stumbled upon is that when search and replace is added this is going to break some intended searches. I just discovered this the hard way when I copied some code from Sigil into a standard text editor to do a quick regex find/replace - the hard line wraps created a number of situations where my regex no longer matched.

During development of Sigil, I noticed that editing in Code View with a really large document loaded was somewhat painful. Performance suffered because of automatic line wrapping. Wrapping a 5000 line document live, while the user is typing, is very CPU-intensive. I planed on addressing this issue at a later time after I analysed possible solutions. But honestly I don't think there's a good way of doing this that would please everyone.

Hard line breaks were the solution. Back then at least. You could edit in large docs even on lower end computers, which is important. As I've said, I'll look into adding some sort of fast wrapping, but I doubt it will be possible.

You'll probably just get an option to switch from line wrapping to hard line breaks.

I'm sure Valloric would say, please open an issue and attatch a sample HTML source file that shows this problem.

Thanks for this. :)

And pdurrant is right: create an issue for this. No need to attach a source file since this is not a bug but a design decision.

I had a hunch it might be a design decision. I guess that reasoning makes sense, note the option I'd prefer is just to not wrap lines at all. Disabling wrapping completely is usually the first preference I enable in my editors.

It should be possible to make wrapping less intensive, I know a lot of editors I use don't seem to have problems, even with really large documents.

I'll open a case.

It's probably safest to add linebreaks after block elements (<p>, <hX>...), then soft-wrap the contents.

It's probably safest to add linebreaks after block elements (<p>, <hX>...), then soft-wrap the contents.

This was what the first implementation looked like. As I said, it was slow on old hardware.