-
Notifications
You must be signed in to change notification settings - Fork 14
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
Ranged elements #27
Ranged elements #27
Conversation
For future reference, this is how a long list with ranged elements would look like. I feel that allowing for whitespace between the list items is easier on the eyes. However, it depends on how empty lines straight after the delimiting modifiers are treated. I have assumed that the delimiting modifier only resets after the first non-empty line in which it appears. (Otherwise would it be the case of using
I think that the above does not look very bad on the eyes, but the excessive use of Another option would be to use a similar rule that is used for heading. The list only breaks after
|
Thanks for the input! The final syntax will definitely be closer to your second example because all the intermediate |
Lists and Quotes are now a subtype of detached modifiers with actually allow an entire `paragraph` node (instead of just `paragraph_segment`) to be placed inside of them. This has the benefit of allowing `_line_break` which means we can avoid an excessive use of the (soon to be introduced) ranged segments.
A proof of concept idea. Bound to change!
src/scanner.cc
Outdated
/* TODO: what is this? | ||
auto can_have_modifier = [&]() | ||
{ | ||
return !m_ActiveModifiers[(VERBATIM_OPEN - BOLD_OPEN) / 2]; | ||
}; | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vhyrro do we really need this?
src/scanner.cc
Outdated
{ | ||
if (can_have_modifier()) | ||
m_ActiveModifiers.set((found_attached_modifier->second - BOLD_OPEN) / 2); | ||
// if (can_have_modifier()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was used here but it was causing issues when implementing ranged modifiers and removing it didn't seem to break anything..
// TODO(mrossinek): I do not see the need for this. If we do | ||
// need it, we need to extract it into _paragraph again because | ||
// having it here would cause the ends of detached modifiers | ||
// like quotes and lists to break. | ||
// optional( | ||
// $._paragraph_break, | ||
// ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vhyrro what's your take on this?
We need to be a bit stricter on how to close the ranged attached modifiers. Currently, the following will be closed prematurely:
Instead of the EDIT: Fixed in c0c4002 |
This allows us to write what would normally be non-ranged attached modifiers inside of ranged-modifiers without affecting their range. This is very useful because it allows us to write verbatim attached modifiers within ranged verbatim attached modifiers without messing up their range. For example: |` In Neorg, verbatim text is written like so: `This is verbatim.` `|
Currently, the following case of nested modifiers is broken:
The |
Ported implementation from #27.
Now that the ranged attached modifiers and the newest indent segment implementation have both been ported to #35 I am closing this PR. All previously commented issues have been resolved, too 👍 |
Adds the ranged element syntax discussed on Discord.
|
to!
|*/ ranged bold + italic /*|