!vVDCbufQqGEdAdfclU:matrix.org

neorg treesitter

574 Members
3 Servers

Load older messages


SenderMessageTime
2 Jan 2024
@_discord_548711395131129888:t2bot.ioslobby_bobby joined the room.04:39:21
@_discord_750666437420384297:t2bot.ioboltless free-03 case gets really interesting
*word *|word|*

current output: one open_conflict starting from column 0

first * is parsed bold_open
second * can’t be bold_open as not_close right after whitespace has higher precedence & we actually opened bold before
as second * is not bold_open, are remaining punctuations become just punctuation without special meaning
10:09:33
@_discord_750666437420384297:t2bot.ioboltless nvm fixed by giving bold_open higher precedence 10:17:31
@_discord_750666437420384297:t2bot.ioboltless conflict conflict bold in *word /*word* may be parser friendly and it is definitely possible.
but error on unclosed is way parser friendly in that context. it just feels like a unintuitive edge case for LTR.

I would prefer bold containing one or two conflict for this as it makes more sense, and is also possible
+ as scanner knows the order of opened modifiers, it would be easier to fix edge cases discovered in the future
11:54:45
@_discord_750666437420384297:t2bot.ioboltless hmmm how can I make test case for this:
`/word`

parser success with single verbatim for this case, but it did successfully parsed version of two open_conflict as well, but just didn’t selected it for select earlier symbol rule
14:27:05
@_discord_750666437420384297:t2bot.ioboltless we need stack for attached modifiers anyways
*/word|*

parser doesn’t know if bold was opened as free-form or not, so it can’t determine if |* would be valid free_form_close or not
16:49:23
@_discord_750666437420384297:t2bot.ioboltless * we need stack for attached modifiers anyways
*/word|*

parser doesn’t know if bold was opened as free-form or not, so it can’t determine if |* would be valid free_form_close or not when parsing _fail_close
16:50:19
@_discord_982653006266908692:t2bot.iorilplus joined the room.21:11:20
@_discord_886677059307442236:t2bot.iosantiagomunevar joined the room.22:05:05
3 Jan 2024
@_discord_750666437420384297:t2bot.ioboltless note about current spec:

parser will prefer earlier open/close modifiers (LTR)
even verbatim can fallback to punctuation with this rule (e.g. *`word* is bold with punctuation and word)
but when user opened free-form attached modifier, parser will continue parsing
so while *|/word|* is bold, */|word* isn’t as there is valid free-form-italic open after bold open
03:52:19
@_discord_750666437420384297:t2bot.ioboltless .vhyrro do you think this is ok? 03:53:03
@_discord_783655191953670214:t2bot.io.vhyrro Yeah I see no issues with that 07:25:53
@_discord_750666437420384297:t2bot.ioboltless
*|/|*|/|*

now I feel non-verbatim free-form attached modifier is just bad design
as free-form opener and free-form closer can be conflicted in various cases
10:27:04
@_discord_750666437420384297:t2bot.ioboltless another free-form edge case is:
`*|`

as we allows bold_open inside verbatim in case it fails, parser thinks this as unclosed verbatim with unclosed free-form bold inside (which is an error)
10:36:33
@_discord_750666437420384297:t2bot.ioboltless * another free-form edge case is:
`*|`

as we allow bold_open inside verbatim in case it fails, parser thinks this as unclosed verbatim with unclosed free-form bold inside (which is an error)
10:36:55
@_discord_750666437420384297:t2bot.ioboltless .vhyrro how do you think removing non-verbatim free-form attached modifiers 👀
I think this is fixable, but it would be really v1-style
10:39:42
@_discord_750666437420384297:t2bot.ioboltless or disallow any nested markups inside both verbatim/non-verbatim free-form attached modifiers 10:48:46
@_discord_750666437420384297:t2bot.ioboltless this would be useful for usecases like vim modeline 10:50:31
@_discord_379038912380928011:t2bot.iomerole joined the room.11:10:55
@_discord_783655191953670214:t2bot.io.vhyrro in this case i'd take the left-first approach. If it looks like an opener, it's an opener, always 12:18:58
@_discord_783655191953670214:t2bot.io.vhyrro i've been considering ways of fixing the whole idea of free-form modifires 12:19:29
@_discord_783655191953670214:t2bot.io.vhyrro but so far I haven't managed to figure out anything truly coherent 12:19:35
@_discord_783655191953670214:t2bot.io.vhyrro if mrossinek ever comes back to life perhaps we could discuss ;) 12:19:48
@_discord_750666437420384297:t2bot.ioboltless another thing really bothers me building precedence rules is linkables. How can we prevent injections made by linkables?
I’ve written some examples in edge case thread in norg-spec repo.
12:22:04
@_discord_750666437420384297:t2bot.ioboltless I think Norg is left-close-first
so first closing modifier precedes than any opening modifiers
this also explains how unclosed attached modifiers work; parent markup’s closing modifier comes earlier than unclosed one.
also with that, user can never make “ /“ bold
12:51:13
4 Jan 2024
@_discord_387036585033465856:t2bot.iontbbloodbath set a profile picture.02:42:26
@_discord_387036585033465856:t2bot.iontbbloodbath changed their profile picture.06:30:34
@_discord_588593622233120778:t2bot.ioavrsarma joined the room.07:11:29
@_discord_713708178663145563:t2bot.io.cayuse changed their display name from Cayuse to .cayuse.16:48:47
5 Jan 2024
@_discord_387036585033465856:t2bot.iontbbloodbath changed their profile picture.04:04:40

Show newer messages


Back to Room ListRoom Version: 9