나무마크 파서를 만들고 있음.

옟날에는 오픈나무, 병아리 엔진(?)이라 불리는거 처럼 정규식을 이용하였는데, 컴파일 언어랑[1] 인터프리터 언어[2]의 성능이 비슷한 것을 보고 갈아 엎음.[3]

두 번째 파서는 토크나이징을 하고 파싱을 하려 했는데
]]랑 ]를 구분 못하는 문제가 발생해서 갈아 엎음

세 번째 파서는 파싱 과정을 총 3단계에 걸처서 진행함[* 원래 이러고 싶지 않았는데 우선순위서열정리를 할 마땅한 방법이 생각나지 않음. 성능이 정규식만큼 구려지면 접자. 안되 내 7개월

아 그리고 갑자기 프론트 삘이 돌아서 잠시 버림.

아 그리고 누가 CRATES.IO에서 namumark 먹었던데 뭘 먹어야할까난...

그리고 if문. Namumark에 비해 파싱이 쉬울듯. 파서를 따로 만들어서 하는 것이 좋을듯함. [4]

AST만 뽑는 크레이트로 만들 생각이기 때문에 렌더링은 Fe에서 할 예정.

어... 웬지 모르겠지만 리버티, 부마에서만 정상작동함.

Wiklim[5]에서는 작동 안하는 버그 발견 plugin이 <Nuxt>를 리버티, 부마는 <Nuxtpage>로 치환하는 과정이 일어나서 그런듯. 그런데 Wiklim을 쓰면 Nuxt3 대응하니까 플러그인 레벨에서 치환을 안함. => 뭔가 랜더 시 데이터의 부족으로 문제 발생?으로 추정.[6]

Middleware 단에서 하면 안되는 이유:스킨이 먼저 반응함 + page 다운로드 중에 바뀌면 기존 UI가 고장남.

plugin에서는 router.afterEach로 구현. 분명 리버티에서는 잘 됐음. 내 생각에는 page가 store를 접근하기 전에 실행해야 함. 그 타이밍 전에 적용시키는 것이 중요함

Lifecycle hooks를 후킹해서 page:start에 추가하면 됨
page:finish를 후킹하였더니 정상작동 확인. 현제 디자인을 제탕하고

최근토론을 만들고 있는데 스킨이 문젠지[7]UI가 문젠지...

파서는? => 아 그냥 파서나 할까

메크로 완료

주석 완료

리다이렉트 완료

{{{+ {{{- {{{#248790
1. 리스트

이랑