10000 Softwrap should match indent · Issue #1125 · atom/atom · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Mar 3, 2023. It is now read-only.

Softwrap should match indent #1125

Closed
cameronmcefee opened this issue Nov 19, 2013 · 45 comments · Fixed by #5567
Closed

Softwrap should match indent #1125

cameronmcefee opened this issue Nov 19, 2013 · 45 comments · Fixed by #5567
Labels
atom editor-rendering enhancement

Comments

@cameronmcefee
Copy link

Ok, this one may be a personal preference, but it drives me nuts that softwrap doesn't match the indent.

screen shot 2013-11-18 at 5 18 17 pm
@izuzak izuzak mentioned this issue May 26, 2014
Closed
@bobrocke
Copy link
bobrocke commented Jun 8, 2014

This one looks dead. Were there any solutions?

@cameronmcefee
Copy link
Author

I believe this has been resolved.

@cameronmcefee
Copy link
Author

Mm, nope, sorry. Still a thing.

@cameronmcefee cameronmcefee reopened this Jun 8, 2014
@kelhusseiny
Copy link

@cameronmcefee Did you fix this issue? I still can not solve this!

@cameronmcefee
Copy link
Author

@Azzurrio Sorry, I'm not working on this issue, I just reported it.

@batjko batjko mentioned this issue Aug 2, 2014
Closed
@trevordmiller
Copy link

Would greatly appreciate this being added as an option or as the default wrapping functionality. Having wrapped lines start back at the far left is confusing because it doesn't keep the indent level of the line that belongs to which throws off the entire file structure.

@benogle benogle self-assigned this Aug 5, 2014
@jescalan
Copy link
jescalan commented Aug 6, 2014

Just ran into this today as well. This is super confusing to deal with when you run into it. It essentially drop any indentation as soon as a line is soft wrapped, but still keeps the indent on the next line. But this only happens visually, technically the code works fine (ran into this with a whitespace significant language and although it looked messed up it compiled correctly. An example (this one is jade)

screen shot 2014-08-06 at 12 27 32 pm

Here's what the code actually looks like:

.some_div
  a(href='http://www.areallyreallyreallyreallyreallyreallyreallyreallylonglink.com')
  .another_div

@jeffreylees
Copy link

+1 This is the only thing really stopping me from moving over full time, it's driving me nuts. Such a small thing, but yeah.

@lokarlhorst
Copy link

+1 Please fix it...it's annoying

@crazymykl
Copy link

Although I am very much for this feature, and would have it turned on, a co-worker of mine has expressed disdain for it. Therefore, it'd be best if it were optional (but probably on by default).

@wanderingcrow
Copy link

Atom looks awesome, but this is a deal breaker for me. Is there any movement on this?

@kevinsawicki
Copy link
Contributor

@javaporter Sorry, no movement on this yet.

@fungilation
Copy link

This along with atom/tabs#76. My biggest grips for Atom, great otherwise!

@douglasdollars
Copy link

+1

@qwo
Copy link
qwo commented Sep 15, 2014

+1 even though its mostly an aesthetic issue shouldn't it be tagged as a bug as its not in the expected behavior?

@valdelama
Copy link

+1

1 similar comment
@HectorMorlet
Copy link

+1

@afknapping
Copy link

+1. this might seem like a detail or aesthetic preference at first but the behavior is really confusing when using significant whitespace syntaxes (coffee, sass, jade, slim, haml...).

@ChristinWhite
Copy link

+1, this is the primary reason I haven't switched from Sublime to Atom as my full time editor yet for any kind of markup (that contains long lines) and any languages with significant whitespace like filtercake mentioned.

@benogle benogle mentioned this issue Sep 30, 2014
Closed
25 tasks
@mrmitchboyer
Copy link

+1

3 similar comments
@lkoelman
Copy link
lkoelman commented Oct 5, 2014

+1

@aaronransley
Copy link

+1

@brantwedel
Copy link

+1

@ChristinWhite
Copy link

That's awesome, thanks @izuzak!

@yuergen
Copy link
yuergen commented Oct 29, 2014

I just want to chime in. I hope this crucial feature makes it into 1.0. Hopefully it will be integrated soon. :)

@Marco85180
Copy link

I hope too! Thanks @izuzak.

@tedyun
Copy link
tedyun commented Nov 10, 2014

+1

2 similar comments
@connorwyatt
Copy link

+1

@kmisiunas
Copy link

+1

@thedaniel
Copy link
Contributor

This is already in the tracking issue for 1.0, so we agree that it is important. Your voices have been heard, no need to add +1 comments.

@ioquatix
Copy link
ioquatix commented Dec 7, 2014

I think people adding +1 is just a way of easily subscribing and registering their interest. Perhaps there needs to be a +1 button on GitHub and a counter like Reddit.

@chodorowicz
Copy link

there's a subscribe button already
image

@kevincoleman
Copy link

Nope, pretty sure they’re adding +1 because they want it to be an issue that gets addressed sooner than later. Putting it on a list for the next release is great (don’t get me wrong—not complaining), but I know several people are holding off on using Atom until it’s fixed. Since there’s no promise date for the next major release, I’d bet they’re hoping that adding +1 will get it addressed sooner.

@bobrocke
Copy link
bobrocke commented Dec 7, 2014

This must be a more difficult problem than it would appear on the surface. It is promised for v1, which is good. But if it were "easy," I suspect the team would have added this already.

@timscott
Copy link
timscott commented Dec 7, 2014

+1

This is getting closer to breaking the deal for me.

@ioquatix
Copy link
ioquatix commented Jan 5, 2015

+1.0

@joshrowley
Copy link

+1, just showing my support for this, great work team!

@as-cii
Copy link
Contributor
as-cii commented Feb 13, 2015

I would like to tackle this (or, at least, offer my help), but I need guidance in order to get started. This should affect only rendering, therefore my understanding of the code led me to TokenizedLine.

In particular, softWrapAt(column) contains the code which converts one TokenizedLine into a left fragment (the line which will fit the current row) and a right fragment (the line which, probably, needs further splitting because it doesn’t fit the current line). The process repeats until no overflowing characters are found.

I have noticed also that TokenizedLine accepts an indentLevel parameter which, unfortunately, doesn’t have any effect on the resulting rendering (I assume this is why the issue hasn’t been solved yet, otherwise it would have been too simple 😉).

Thus, as far as I understand, we would need a way to move the rightFragments towards right. However, this should be just a visual effect: even though my knowledge of the codebase is relatively limited, I’d say this change should not involve any modification in TokenizedLine’s tokens or text.

Now, a couple of questions:

  1. Do you agree with my last assertion (e.g. indenting should be only a visual effect)?
  2. Is there anyway to position a tokenized line arbitrarily (or in a way that could fit our purpose, e.g. renderFromColumn: 2)?
  3. If we treat this just as a rendering issue, though, we couldn't be able to wrap lines correctly (e.g. if we indent the lines next to the first one, those lines will have less space and thus they should wrap earlier). An alternative could be to place a “fake” (read: special) token in front of the rightFragments (which would contain as many spaces as leftFragment’s indentation). Ideally this shouldn't be selectable and the cursor should refuse to lie on it (displayBuffer#clipScreenPosition may handle this).
  4. Is there any other pitfall which I am totally ignoring and that causes this to be tricky?

Thanks in advance to anybody who will help me out 🙏

@thedaniel
Copy link
Contributor

Pinging @atom/core re @as-cli's questions

@nathansobo
Copy link
Contributor

Do you agree with my last assertion (e.g. indenting should be only a visual effect)?

Yes, but we model it. The DisplayBuffer is responsible for the non-linear relationship between lines/characters on screen and lines/characters in the buffer, dealing with folds and soft-wraps.

Is there anyway to position a tokenized line arbitrarily (or in a way that could fit our purpose, e.g. renderFromColumn: 2)?

No, you're going to need to insert a phantom token. More details below.

An alternative could be to place a “fake” (read: special) token in front of the rightFragments (which would contain as many spaces as leftFragment’s indentation).

Check out how we handle hard tab characters, which map multiple spaces in screen coordinates to a single character in the buffer. This should be similar, but would map to zero characters in the buffer causing the cursor to skip that leading whitespace.

Is there any other pitfall which I am totally ignoring and that causes this to be tricky?

I think your phantom token approach sounds promising and was what I had in mind. It's hard to say what kind of issues might crop up with our coordinate mapping going from multiple characters on screen to zero in the buffer since we've never done that... with tab we map to one character in the buffer. So that could be interesting. You'll just have to see what emerges I guess.

< CCD1 /div>
@as-cii as-cii mentioned this issue Feb 15, 2015
Merged
@Josiah
Copy link
Josiah commented Feb 26, 2015

🏆 Awesome - really wanted this feature!

@lock
Copy link
lock bot commented Jan 22, 2019

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

@lock lock bot locked as resolved and limited conversation to collaborators Jan 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
atom editor-rendering enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Indent soft wrap
0