Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CLOSED] Add feature. Open line above/below the current line. #2588

Open
core-ai-bot opened this issue Aug 29, 2021 · 30 comments
Open

[CLOSED] Add feature. Open line above/below the current line. #2588

core-ai-bot opened this issue Aug 29, 2021 · 30 comments

Comments

@core-ai-bot
Copy link
Member

Issue by zeis
Wednesday Jan 30, 2013 at 23:52 GMT
Originally opened as adobe/brackets#2729


Keyboard shortcus are Ctrl-Enter and Ctrl-Shift-Enter


zeis included the following code: https://github.com/adobe/brackets/pull/2729/commits

@core-ai-bot
Copy link
Member Author

Comment by peterflynn
Wednesday Jan 30, 2013 at 23:59 GMT


I wonder if this feature is common enough that we'd want it in core, or if it'd be better to have it as an optional extension... It seems easy to move out into an extension if desired. It does seem to be in Sublime, though, so that's one data point in favor of core.

If we're going to take it in core, can you add unit tests?

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Thursday Jan 31, 2013 at 01:49 GMT


+1 this is actually a feature I miss regularly.

@core-ai-bot
Copy link
Member Author

Comment by zeis
Thursday Jan 31, 2013 at 10:54 GMT


This feature is common. It is also in Visual Studio (with the same key bindings), Vim and Emacs.

I've started writing unit tests.

But, I've a question: How do I set (or get) the number of spaces for indentation before I run my tests?
For example in the following code I use lines.splice(1, 0, "    "); to reproduce 4 spaces, but the test fails because strangely it seems like indentation is set to 1 space when running tests.

    describe("Open Line Above and Below", function () {
        beforeEach(setupFullEditor);

        it("should insert new line above if no selection", function () {
            // place cursor in middle of line 1
            myEditor.setCursorPos(1, 10);

            CommandManager.execute(Commands.EDIT_OPEN_LINE_ABOVE, myEditor);

            var lines = defaultContent.split("\n");
            lines.splice(1, 0, "    ");
            var expectedText = lines.join("\n");

            expect(myDocument.getText()).toEqual(expectedText);
            expectCursorAt({line: 1, ch: 1});
        });
    });

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Thursday Jan 31, 2013 at 13:05 GMT


There was a test in the test suite that was setting indentation to 1 space. I just removed that and it was merged yesterday morning. You might try merging from master and see if the problem clears up.

If I'm reading things right, you should be able to find out what the indentation is set to by calling myEditor.getIndentUnit.

@core-ai-bot
Copy link
Member Author

Comment by zeis
Thursday Jan 31, 2013 at 15:56 GMT


Thanks dangoor.

I've added unit tests.

@core-ai-bot
Copy link
Member Author

Comment by peterflynn
Thursday Jan 31, 2013 at 19:15 GMT


Two quick thoughts:

  • Editor commands often run into problems at the edge cases: first/last line in the file, and first/last visible line in an inline editor's range. Please test those cases carefully with both commands to make sure they do the right thing... and ideally, add unit tests for them too.
  • In the unit tests, the code that generates spaces is duplicated all over the place. I think you could simply compute that once and store it in the describe()'s closure for use in all the tests (or at the least, move the code to a shared utility function that every test calls).

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Thursday Jan 31, 2013 at 20:03 GMT


It's great to see all of those unit tests. Thanks!

One other note: someone on the Brackets core team noted that the Edit menu is getting rather long (and we don't have submenus yet to help with that). Because of that, we should probably land this with just key bindings and not menu entries.

@core-ai-bot
Copy link
Member Author

Comment by zeis
Friday Feb 01, 2013 at 09:25 GMT


@peterflynn
I didn't actually know of editrors with range, and now I fixed an unwanted behaviour with the inline editor.

  • Additional first/last line and inline editor's unit tests have been added.
  • Indentation is now generated once.
  • Feature's code refactored.

@dangoor

  • Removed menu entries and left strings in case they'll be used in future.

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Monday Feb 11, 2013 at 16:46 GMT


I noticed that opening a line below at the bottom of an inline (CSS) editor doesn't work. This is not a big deal, because you can't really add rules using the existing inline CSS editor, but I thought I'd mention it in case this is not expected behavior. (edit: also doesn't work in JS inline editor...)

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Monday Feb 11, 2013 at 17:09 GMT


Nice implementation and I appreciate all of the tests. (I'm looking forward to having this myself!)

Looking at all of that test code, I kept thinking "there's got to be a way to boil this down a bit", but looking at the code that varies between tests there's really only a couple of lines that are truly duplicated from test to test, so it may be best as it is, which is nice and straightforward.

Thanks for pulling this together!

@core-ai-bot
Copy link
Member Author

Comment by zeis
Tuesday Feb 12, 2013 at 00:42 GMT


What do you mean when you say "opening a line below at the bottom of an inline (CSS) editor doesn't work"? How can I reproduce the problem? That problem should have already been fixed in the second to last commit (9d4a186).
Now, before the last commit, I've rebased against upstream/master and tested again. To me it seems to work as expected. Maybe, there's an unexpected behavior with something that appears normal to me... can you explain better?

In order to make unit tests are a bit lighter, the following 3 lines could be put within a function which would take the slice() input parameters. But I'm not really sure if it is a nicer solution, so I'm not going to changed that before hearing your opinion.

var lines = defaultContent.split("\n");
lines.splice(1, 0, indentation);
var expectedText = lines.join("\n");

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Tuesday Feb 12, 2013 at 21:00 GMT


Thanks for the update.

Regarding the tests, I came to the same conclusion you did: it's not worth trying to extract those 3 lines into a function.

Here is how you can reproduce the (minor) issue that I see:

  1. open test/smokes/citrus completed/index.html
  2. go to the tag (put the cursor inside the tag)
  3. press ctrl/cmd-E (to open the inline editor)
  4. go to the last line
  5. press ctrl/cmd-enter to open a line below
  6. a line is added at the correct place in the file, but the inline editor does not change height so you can't see the new line unless you go to a full editor for that CSS file

Like I said, though, this is a small thing and the feature generally works well for me.

I'm not going to merge it in right now, because we're gearing up for the next release and I don't want to introduce risk. There's a big change coming into the repo (codemirror v3) which may require a bit of merging for this.

One tip: once you've pushed to a public repo, it's better to not rebase. It's fine rebasing until your code is public, merge as necessary after that.

@core-ai-bot
Copy link
Member Author

Comment by zeis
Tuesday Feb 12, 2013 at 22:59 GMT


This is definitely an issue.
I didn't notice it before because I've been using a html page with a single css file to test it. And I figured out that maybe it doesn't happen if you have only one css file (see code below).

But that's really strange, because while trying to figure out what could the real problem be I also tested the MoveLine command and noticed a strange behavior as well:

  1. Open test/smokes/citrus completed/index.html
  2. Open the inline editor
  3. Move one line down until it reaches the bottom of the inline editor. Now the inline editor automatically closes.

But, if you repeat the steps with the following code it doesn't happen and the inline editor doesn't close.
Could you confirm that it's a strange behavior?
And if not, does this issue with the last line of an inline editor affect only the OpenLine code?

HTML:

<!doctype html>
<html>
<head>
    <title>Testing</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <div class="myclass"></div>
</body>
</html>

CSS:

.myclass {
    height: 30 px;
    width: 50 px;
}

@core-ai-bot
Copy link
Member Author

Comment by TomMalbran
Tuesday Feb 12, 2013 at 23:08 GMT


There is already an issue for the Move Line Up/Down in the inline editors adobe/brackets#1933. I tried a fix on that one by not allowing to move past the last line. There seems to be an issue in the inline editors when replacing beyond the last/first line.

@core-ai-bot
Copy link
Member Author

Comment by zeis
Wednesday Feb 13, 2013 at 00:44 GMT


Thanks@TomMalbran. So I'll wait for@dangoor's confirmation that the problem is not related to my code.

By the way, thanks@dangoor for the rebase tip. Actually, I had some troubles pushing the last commit. But, apart from your notes I don't recall of any actual new changes to the repo until that moment... what went wrong?

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Thursday Feb 14, 2013 at 13:32 GMT


There's a change coming to CodeMirror that will likely alter some of how inline editors work. I don't know if that will automatically correct problems at the boundaries of inline editors, but it may.

@zeis I can't say what may have gone wrong beyond the rebase. I was able to get your code running on my machine so I wasn't too worried about it. Now that sprint 20 has ended (and codemirror v3 has landed), I'm going to merge this change.

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Thursday Feb 14, 2013 at 13:36 GMT


@zeis actually, before I can merge your change, we need to have a contributor license agreement from you. Can you fill this out for us? http://dev.brackets.io/brackets-contributor-license-agreement.html

Thanks!

@core-ai-bot
Copy link
Member Author

Comment by zeis
Thursday Feb 14, 2013 at 14:04 GMT


@dangoor done.

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Friday Feb 15, 2013 at 14:11 GMT


I was just about to merge this and then ran into a problem... This could be related to the CodeMirror v3 integration, which happened between the time you created this feature and now.

Here are my steps to reproduce:

  1. open test/smokes/citrus completed/css/desktop.css (I usually quickopen "citdes")
  2. go to the middle of any line
  3. press cmd/ctrl-enter to open a line
  4. press cmd/ctrl-z to undo
  5. the cursor goes to the old position
  6. press cmd/ctrl-z again
  7. the new line is removed

There were some changes in CodeMirror 3 with respect to undo and multiple operations. Do you think you can look into this?

@core-ai-bot
Copy link
Member Author

Comment by zeis
Friday Feb 15, 2013 at 15:01 GMT


This morning I merged with upstream and tested both OpenLine and MoveLine again. CodeMirror3 doesn't correct the problem. So I decided to refactor the OpenLine code to work around it.

Regarding the new ctrl-z problem, it is related to the CodeMirror v3 integration. And I was already working on it.

In my last implementation ctrl-z removes the inserted line and indentation in one single step, and the cursor is positioned back at the end of the upper line. At the moment I have no idea whether any efficient way to bring the cursor back at the exact position from before exists.

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Friday Feb 15, 2013 at 15:08 GMT


Hmm... In the copy that I have, prior to the changes you made, undo actually did restore the cursor position (on the first undo). As I understand it CodeMirror 3 is a bit saner in its undo handling, with respect to selections and such.

@core-ai-bot
Copy link
Member Author

Comment by zeis
Saturday Feb 16, 2013 at 10:03 GMT


In my previous implementation the operation was handled in 2 different steps: insert a new line using replaceRange() and indent using _codeMirror.indentLine(), this solution worked with CodeMirror2. While in CM3 it is necessary to press ctrl-z two times to undo the whole edit.

In my last implementation the 2 steps are: setCursorPos() to end/start of the line and then insert a new line (already indented) using cm.execCommand("newlineAndIndent"). Ctrl-z works, but the cursor is moved to the actual last position that the last setCursorPos() call set.

At the moment I don't see any effective solution to insert a new line and correctly indent it in a single atomic step (or remove the indentation step from the undo history). I don't exclude that probably I'm not using the right APIs, so I'm open for any good suggestions.
For now, dropping the indentation step is the only simple solution that comes into my mind and would fix the ctrl-z issue.

Also, having tried several workarounds, it must be said that for now the inline editor problem prevents any implementations from being fully working with the edge case of the last line of the inline editor (at least until it is fixed).

So, before I go any further I'll be waiting for your suggestions/decisions.

UPDATE:
I've started a discussion in CodeMirror group, I'll keep you updated.

@core-ai-bot
Copy link
Member Author

Comment by zeis
Monday Feb 18, 2013 at 00:14 GMT


My new attempt fixes the undo history, but unexpected behaviors with the inline editors persist.
It seems they do not reload text correctly soon after inserting the new line. Again, I suspect that probably this is not due to OpenLine. Please can you have a look at the code and let me know?

@core-ai-bot
Copy link
Member Author

Comment by dangoor
Tuesday Feb 19, 2013 at 15:54 GMT


Hmm... when I open line in an inline editor now, it positions the cursor at the end of the line following the newly opened line. Is that behavior you're seeing?

I hate to say it, but we're working on some tight timelines for getting some new features in over the coming weeks. Because of that, I don't really have time to delve deeper into the problems here. You may be right about there being something else going on with the inline editors, especially now that we've switched to CM3. If you find a case that is broken outside of the new open line command, please file a separate issue on it because that would be higher priority for us than adding openline. I do, personally, want to see this command land, but don't have the time right now to dig in. (I also don't have much experience with the intricacies of inline editors, otherwise the answer might be there in front of me.)

One other comment after glancing at your latest code:@njx has looked into CM 3.1's doc/view split. I don't know for sure, but it seems plausible that if inline editors switched to using the new mechanisms there, the behavior may change (for the better).

Thanks again for your persistence with this.

@core-ai-bot
Copy link
Member Author

Comment by zeis
Tuesday Feb 19, 2013 at 22:15 GMT


@dangoor yes, it is that behavior. The newline is inserted properly, but it seems like the text within the inline editor is not synced properly, so the cursor moves there as it doesn't 'see' the new line.

I hope future changes to inline editors could help with this problem.
Anyway, thank you for the collaboration and patience!

@core-ai-bot
Copy link
Member Author

Comment by zeis
Thursday Mar 14, 2013 at 08:56 GMT


Issue #1933 has been closed. So I merged with master. There are no new changes.

@core-ai-bot
Copy link
Member Author

Comment by TomMalbran
Thursday Apr 11, 2013 at 06:28 GMT


With those 2 changes, I think this should work well, since the selection was one of the last broken things, and from some of the testing I did and the tests from the request, everything seems to work well.

@core-ai-bot
Copy link
Member Author

Comment by zeis
Thursday Apr 11, 2013 at 09:51 GMT


I already tried it before, but something has been changed and now it works! Thanks@TomMalbran

@core-ai-bot
Copy link
Member Author

Comment by njx
Tuesday Apr 16, 2013 at 21:25 GMT


Marking [OPEN] for committers to review.@TomMalbran - since you've already been involved in this, would you like to do the final review and merge?

@core-ai-bot
Copy link
Member Author

Comment by TomMalbran
Tuesday Apr 16, 2013 at 21:42 GMT


Sure, i'll give it a final review. I think the code works good now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant