Skip to content

modifies smart_lists #21

Open
wants to merge 4 commits into from

3 participants

@vovkkk
vovkkk commented Apr 8, 2013

adds non-lists patterns:

  • block quotes (>);
  • line block (|);
  • title block (%);

marker of ordered list may be enclosed in parentheses or followed by a single right-parentheses;
(optionally) list item may contain multiple paragraphs (i.e. empty list bullet is converted to whitespaces)


non-list pattern breaks after triple press enter, e.g.:

> This is a block quote.
> 
>

become:

> This is a block quote.

vovkkk added some commits Apr 8, 2013
@vovkkk vovkkk modifies smart_lists
adds non-lists patterns: block quotes (>); line block (|); title block
(%);
marker of ordered list may be enclosed in parentheses or followed by a
single right-parentheses;
list item may contain multiple paragraphs (i.e. empty list bullet is
converted to whitespaces)
d07262c
@vovkkk vovkkk new line should have the same indent as prev
ST does it by default, so SM should too
bb1bb76
@alehandrof

I think this is buggy, or maybe I don't understand what you're trying to do:

When I press enter here:

- Item
- |

I get this:

- Item
  |

Shouldn't the caret go back to the first column?

It happens not because of this code.

Look at line 37.
The point of this feature is that list item may contain multiple paragraphs (which supposed to be indented)

Do you think we need option for it?

Oh, I see! Well, it's confusing enough that I thought it was a bug :)

We need something because right now there's no way to distinguish what the user wants. The "tight" list seems to be a more common use than the "loose" list, so that should be the default. Again, though, I'm not sure how you would distinguish between the two.

Edit: at least, that's what my use like, which largely consists of e-mail & note taking, rather than long technical documents.

Edit #2: if you agree that the "tight" list is more common, would there be a way of doing that while triggering the "loose" list with a keybinding? I thought of Ctrl+Space but I'm pretty sure you won't like it :D What's shift doing these days?

It's not about tight or loose; it's about few 'lines' in one item (either tight or loose), e.g.

* first item \
  still first item on new line
* second item

My initial thought was that if user want to stop list (as in upstream SM) s/he would press ctrl+enter, but now I see that sometimes it wouldn't work as desired.

So I think, I will just add option "empty_list_item" (do you have better name for option?) and it will be false by default.

Keybinding needs command, and command supposed to be a class, and that means we need a new class.
It seems like this feature is useful only for me, I can live with option and without keybinding.

Also I'm going to rollback this code which right there on top of this page, since user can accomplish this action with ctrl+enter.

Approve?

BTW, I'm not sure what shall happen with our comments if I rollback this commit, so waiting reply.

Interesting. I'm not sure what will happen, either. In retrospect, maybe this wasn't the best place to open this conversation :)

If you want to keep the history, you can create a branch based on an earlier commit and then merge the branch into develop. (There's probably a more elegant way of doing this.)

Incidentally, I thought you were trying to achieve this:

+ List item with two paragraphs.

  This being the second paragraph.

+ Second list item.

   Et cetera.

I generally avoid hard-wrapping, so I can't speak as to usefulness of what you're proposing: it didn't even occur to me.

Keybinding needs command, and command supposed to be a class, and that means we need a new class. It seems like this feature is useful only for me, I can live with option and without keybinding.

I see what you mean. It might be worth binding Ctrl+Enter to to a class that sets a variable before calling SmartListCommand. This would allow more behaviors to be quickly accessible. Or maybe this is just heinously complicated. It's too late in the day for me to think through this well :)

Edit: oh, and yeah, feel free to roll back and kill the comments (if that's what ends up happening).

@alehandrof

There's a related issue with the >, | and %.

If I write a >, I enter "blockquote mode" that I can't escape from except by erasing the last >, which is a little inelegant. (It's less like writing and more like editing, if this makes sense.) I find the "mode" useful, but I wish there was an easier way to come out of it.

The only thing I've thought of is interpreting Enter on two consecutive blank >s as a command to return to normal paragraph mode. For example,

> First quoted paragraph
> 
> Second quoted paragraph
> 
> |

Pressing Enter at the caret's location (indicated by the |) would remove the last two >. The caret would remain on the same line (the 6th in the example).

All this sound good (to me) in theory. In practice, it may turn out to be cumbersome. And I'm not sure how convoluted it is to implement.

What do you think?

@vovkkk vovkkk adds break for non-lists patterns
if current line and previous one are empty (viz. [%>|]\s), enter erases
content of those lines;
cursor remains on the same line
a4ae200
@vovkkk
vovkkk commented Jun 16, 2013

There's a related issue with the >, | and %.

fixed

@alehandrof

Cool! It feels a little strange, but I don't see any problems with how it works :) I'm guessing you liked this as an idea?

@vovkkk
vovkkk commented Jun 16, 2013

Yes, more than two empty blockquote lines makes no sence for pandoc (it ignores these like there is only one empty line, assume others does the same).
Line block (|) - same.
Title block in general supposed to have only three lines so maybe I should remove it, because a snippet for this seems more suitable.

Anyway, behaviour you suggested really does make sence if user understand what gonna happen after converting markdown to html or other format.

@mgaitan
mgaitan commented Jun 17, 2013

I've forget to mention that I used this patch in sublime-rst-completion . Thanks
https://github.com/dbousamra/sublime-rst-completion/blob/master/smart_list.py

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.