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

Already on GitHub? Sign in to your account

New Paragraph on Enter event (with sleep) #233

Merged
merged 6 commits into from May 17, 2012

Conversation

Projects
None yet
2 participants
Contributor

hallahan commented May 16, 2012

pair programming at PIE

enter button with paragraphs produces another text area and gains focus

@WardCunningham WardCunningham merged commit 4a0c727 into WardCunningham:master May 17, 2012

Owner

WardCunningham commented May 17, 2012

@hallaha showed this during our video chat last wednesday. He and I got together here in Portland Wednesday to walk through the code and get it in shape for a pull request. In doing so we arrived at two important realizations:

  • At the point that one paragraph is closed and another is opened we find ourselves sending two asynchronous requests to the server to process these two events. The results were sometimes corrupted to where a page could not be later displayed without throwing exceptions. We also showed that by inserting sub-second delays we could process these requests in either order and get reliable results. We've left the more logical of these in place. However, we feel that the proper solution would be to serialize the requests via callbacks in the client code, OR, recognize in the client that the two requests are really just one (an add, not an add + edit) and do only one request.
  • Although we were offered interesting alternatives for signaling a paragraph break (blank line vs. single return) and when that signal would be interpreted (on keystroke vs. on save), we agreed that we were allowed to try what we considered the simplest approach especially because the decision could be easily reversed after gaining some experience. This freedom does not apply for decisions that leave a trail in the database. This mod is only a keyboard shortcut to functionality already present.
Contributor

hallahan commented May 17, 2012

After playing around with the new functionality, the noop when we press
enter and the caret is at position 0 doesn't seem right. I think this would
work the best:

At position 0:
Enter -> New Paragraph as if caret was at end
Backspace -> Edit end of preceding item.

Could some of you try out the new functionality and agree or disagree with
this suggestion?

Owner

WardCunningham commented May 17, 2012

Are you thinking that if I were to hit a series of return keystrokes then I should have created a series of empty paragraphs?

One might do this if they wanted a lot of blank space on the page.

Right now we consider saving an empty paragraph as a request to have the item deleted.

Contributor

hallahan commented May 18, 2012

Nah, I see no reason to have a bunch of white space. I'm talking about if the caret is at 0 and we have text in the box after it. This is useful if I double click on a paragraph and I want to make a new paragraph after it.

Owner

WardCunningham commented May 18, 2012

Maybe what is required is to have the caret placed at the end of a paragraph when one is double-clicked?

Contributor

hallahan commented May 18, 2012

I agree, however, a backspace should still go to the last item... I have found a strange bug. The flag is this weird parallel line glyph in Chrome in Windows 7. On mouse over, it is a rectangle. It's interesting to see. Boot up Windows and have a look. It is more fork like, but less country like... I like using the symbols for icons, but I think we need to load in an explicit font so that things are the same everywhere.

Owner

WardCunningham commented May 19, 2012

Handing the backspace in a consistent way would seem similar to the split-at-the-caret functionality we currently have. The preconditions for special backspace handling would be:

  • The TextEditor is editing an item of type==paragraph.
  • The caret is at postion 0 (beginning)
  • The preceding item is also type==paragraph

A backspace in this situation would:

  • Concatenate the text from both paragraphs
  • Remove the second paragraph (tell server)
  • Replace the text of the first paragraph with the concatenation (tell the server, if changed)
  • Open the TextEditor on the first paragraph
  • Position the TextEditor caret at the point where the joined texts meet.

Note that the paragraphs joined by this mechanism need not have been previously split. A reasonable refactoring would be to split a paragraph, drag something into the gap, then join the pieces back together.

Admittedly, a common case will be that of hitting return by habit, recognizing that it was unintentional, and then backspacing to return to the desired state.

Contributor

hallahan commented May 19, 2012

That last step of positioning the caret at the end of the text after a backspace concatenation may be weird. This will mean that the caret will jump from where it was to the end. Maybe just concatenate but leave the caret where it is? I'll have to implement this and try out both.

Owner

WardCunningham commented May 19, 2012

@hallahan's right. The cursor should go to exactly the point between the joined texts. (What was I thinking?)

Contributor

hallahan commented May 30, 2012

done, see pull request.

Owner

WardCunningham commented May 30, 2012

Awesome. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment