Atom Editor line length wraps at 500 chars on 1.15


#1

I’m using Atom 1.15 x64 on Ubuntu 16.10.

Prior to the 1.15 update, I believe there was no limit on line length.

After the 1.15 update, it seems that lines automatically wrap at 500 characters, even if Soft Wrap is off.

Am I doing something wrong, or is this a bug (or feature)?


1.14 - 1.16 is forcing a line wrap even with soft wrap toggled off
New wrapping feature or am I blind?
#2

This is the expected behavior and was done for performance reasons. See the release blog post for v1.15 for details.


#3

Okay. I didn’t see anything about that in the release blog post for v1.15 or the release notes. The closest thing I could find was this mention in the release notes:

  • Improvements to line tokenization to improve editor performance when opening files with large, uninterrupted lines, like minified JavaScript. Opt out of this behavior from certain grammars like language-gfm,

which references this PR: https://github.com/atom/atom/pull/13820, and this commit: https://github.com/atom/atom/pull/13820/commits/f50b197c5869d50e8fb88c7bbf3763a47b8eddd0

It looks like the max line length before wrapping was changed from Infinity to 500 characters due to poor rendering performance.

I can understand why that was done, although I would have preferred to have had MAX_SCREEN_LINE_LENGTH set via a user-setting, rather than a hard-coded limit.

In my particular case, I have XML files with many repeated elements, each element having a number of attributes, some of which have several long-ish strings (100+ chars or so). I find it a lot easier to read when each element and its attributes takes up a single line, and I can scroll horizontally to look at the attributes for an element I’m interested in.

Is there a way to opt of this behavior on a language-specific basis, so that I can have my XML lines as long as I want?


#4

To my knowledge, no there isn’t. I understand your use case but the research that the team did showed that there were multiple performance implications the wider the DOM’s visual representation gets. The benefit to Atom being open source is that you can always build your own copy and change the hard coded constant to whatever you want. We’re not going to support it though :grinning:


#5

The benefit to Atom being open source is that you can always build your own copy and change the hard coded constant to whatever you want.

I was able to build my own copy of Atom and change the max line length, so now it works the way I want.

Thanks for your help.


#6

Hi!, I’m using Atom 1.15 x64 on Windows 7 Enterprise SP1.

I’m facing the same issue, 500 characters line wrap. I have a similar use than “Belltown”, but in my case, editing PL/SQL queries and data record files.
A language-specific option will solve my issue too, but looks like it is not possible.

I’m not sure about if I will be able to build my own copy of Atom like “Belltown”, maybe I do not have enough knowledge. But, if i do that, will I need to rebuild my own copy on every main update?. Or there are any other way, maybe building a package?.

I have migrated from Sublime Text recently, mainly for open source reasons, and everything is working fine, even ftp plugins!. So i was very happy with Atom. But I think that “Belltown” and my case of uses are not so infrequent.

Thanks for your help.


#7

Yes, you would need to do so.

Yes, that’s true. But this is a trade off between having something that is inconvenient for certain use cases versus Atom being unusable for some other use cases. Neither of them are infrequent, so we had to go with making Atom usable for more people.


#8

OK leedohm, I understand the difficulty of your decisions.
Hope to see an configurable option someday (with a great notice about performance).

Thanks a lot for your time :slight_smile:


#9

It wasn’t too hard to follow the instructions in https://github.com/atom/atom/tree/master/docs/build-instructions. All I needed to do (on Linux) was install on an older version of npm and follow the instructions, and it just worked. It may be harder on other platforms, or if you don’t have experience building software. And yes, you’ll have to do this every time you want to get the latest updates.

Another option is to use Visual Studio Code as your editor (or use both). Like Atom, it’s a cross-platform (Windows, MacOS, Linux) editor, similar in many ways to Sublime Text and Atom. I’ve been switching between VSCode and Atom recently, and I’m finding that VSCode works much better as an editor than Atom. I keep running into annoying gripes with Atom (like the 500 char line limit, like the randomness of how many tab stops the tab/back-tab keys want to move, like the way two quotes instead of one are automatically inserted when I don’t want them to be especially if I’m trying to add a closing quote to a string that already has quote at the beginning, … and the list goes on). Atom just seems rather “new”. GitHub as a lot of very smart people working on the project and are making really good progress. But Microsoft’s VSCode is based on an editor they’ve been developing and using in other MS products for over 5 years, so they’ve already figured out how to do all the basic editing stuff. Atom does have a larger package ecosystem for now, and I’m using some packages I developed for Atom that I haven’t had the time to re-write for VSCode, which is why I’m still using it.


#10

Imo this is ridiculous, why not at least give the option to remove any type of line break as it (to me) is un-expected behavior? The performance of atom is ultimately an issue for the user (plugins and themes you install), and if the user want full lines and no breaks it should an option in the settings.

Heres example where the code looks broken because it’s suddenly wrapping:

I head what you’re saying about making your own atom build, but I want stuff to behave like I’m used if I didn’t make an active choice to change a settings. And not not suddenly see unexpected things in my code. Some of us have better things to spend their time on than building their own versions of atom while enjoying it at the same time.

End rant. I just hate other developers make choices that affect the collective based on stupid reasons.


#11

Hi there,

thanks a lot for making atom faster and more stable! Unfortunally this 500-character-line-wrap-thingy is not a goog solution in my case!

I have some tables in markdown which are looooong. There are for rendering html-files with this feature/ bug I am not able to edit this table in a convenient way any more. I have to switch to another editor.

Or give me a hint, how to edit this:

Compiling atom is not an option for me, because of missing time and knowledge. I really would appreciate, having this option turning on or off by the user! I think about guys editing csv-files, markdown-files, html etc…

Please rethink this decision at least for turning it on or off (may be depending on filetype…)

Greetings
MAW


#12

I definitely agree with you, even before the 1.15 release, I used to need to used a package to increase the token limit and right now with the 500 chars limit I need to use other editors to work with the files that doesn’t get the correct syntax highlight, and IMHO build Atom just to change a line in a file is not the answer to this problem, please make this configurable for the user.


#13

This is breaking syntax highlighting and making the editor darn close to unusable.


#14

I don’t understand how providing a customisable value (with your preferred 500 char line length as default) instead of a hardcoded one is better. By allowing customisation you don’t have to trade off anything. By default it would work in the cases where atom would become unusable, and those of us, who prefer no soft wrapping could turn it off, and everyone would be happy.


#15

Just plain lazy. This should be a user setting, with a performance warning if necessary. With a hard-coded 500 char limit Atom is totally unusable for me - why are developers setting arbitrary and unchangeable limits? Furthermore, the user should be made aware of this limitation when they “turn off” wrapping.


#16

The Devs should take another look at this, I’ve seen minimal performance impact when manually making the editor 5,000 characters wide. The issue is probably with the tokenizing algorithm, not with DOM width.


#17

Just make it a customisable setting. people who change it will have to risk in a minor performance decrease, but for some projects performance issues are unnoticeable, while this wrapping thing makes them impossible to work on using Atom.


#18

The setting is Settings > Editor > Max Screen Line Length.


#19

Thank you! This should be pinned to the top of the thread and all other not-useful-jabber be deleted.