Editorin älykkäät menut

Nykyinen tilanne

Moni editorin menuvalinnoista tuottaa vain "tyhmän" merkkijonon kursorin kohtaan. Tämä on helppo tapa koodin puolesta ja auttaa sellaisia kirjoittajia, jotka tietävät mitä on tekemässä.

Kuitenkin esimerkiksi menutoiminto Fields | Settings | älä näytä View-näkymässä tuottaa merkkijonon

   visible="%% False | isview%%" nocache="true"

jota olisi tarkoitus käyttää osana lohkon attribuutteja eli kokonaisuudessaan minimissään

  #-  {visible="%% False | isview%%" nocache="true"}

riippuen siitä, millaista lohkoa ollaan aloittamassa.

Virhekäyttömahdollisuuksia:

ei itse huomata lisätä #- {}, mikäli sitä ei jo ennestään ole
lisätään muualle kuin lohkon alkuun
jos pohjatekstinä on jo esimerkiksi

- {defaultplugin="numericfield" readonly="view" .fieldCell}

ja lisättäessä kursori on vaikka sanan readonly keskellä, tulee tuosta tavaton sotku

Tavoitetila

Olisi sopiva abstraktio menujen määrittelyyn (=menukieli), missä voidaan sanoa, miten jono pitää sijoittaa. Esimerkin tapauksessa pitäisi varmistaa

jos kursori ei ole lohkon attribuuttiosan sisällä eikä muokattavassa lohkossa ole mitään lohkon aloitusta lisätään jono lohkon alkuun sisältäen myös #- {}
jos kursori on lohkon aloittavassa attribuuttiosassa, etsitään kursorille paikka sulun } vierestä ja lisätään jono välilyönnin kanssa (tässä tapauksessa etuvälilyönti voisi turvallisesti olla osa jonoa)
mikäli kursoririvillä on jo trimmattuna ko jono, se poistetaan (toggle-ominaisuus)

Toinen vastaava käyttötapaus on fields attribuutit esimerkiksi tyyliin:

 {#kentta cols: 4#}

jossa tuo cols: 4 saadaan menusta.

Tuota lisättäessä pitäisi tarkistaa

ollaan fields-määrityksen sisällä, jos ei niin varoitus
jos on ennestään attribuutteja, niin lisätään pilkku ja välilyönti (",") `#} eteen ja sen perään menussa oleva jono
jos jono on ennestään poistetaan se (poisto pitäisi "menukielessä nyt sanoa sopivasti regexpillä niin, että poistetaan myös cols: 23 jos käyttäjä on vaihtanut lukua

Menukieli

Jotta tuosta saataisiin riittävän yleiskäyttöinen, pitäisi määritellä menukieli, joka olisi yhteensopiva nykyisen menujen esityksen kanssa. Tai sitten korvataan jo löytyvät menut tällä kielellä. "Kieli" voisi olla ihan YAMLia tyyliin:

menupos: "Fields | Settings"
menutext: Kentän leveys
menuinsert: "cols: 4"
cursor_must_be_inside: "{#.*#}"
not_inside_warning: Kursorin pitää olla fields-määrityksen sisällä
remove_if_exists: "(cols: [0-9]*,)|((, cols: [0-9]*)|(cols: [0-9]*)"
insert_before: "#}"    # jos puuttuu, niin kursorin kohtaan
add_before: ", "
add_before_if: "{#.* .*:.*#}"

Vastaavalla tavalla pitäisi kokeilla miten saisi sanottua tuon ensimmäisen käyttötapauksen joka on tämän osalta monimutkaisempi.

# määrittely kesken...
menupos: "Fields | Settings"
menutext: Lohko ei näy View-näkymässä
menuinsert: " visible=" %% False | isview%%" nocache="true""
cursor_must_be_inside: "(#- {.*})|(##* {.*})|(``` {.*})"
if_not_inside: INSERT_BEFORE_BLOCK
if_not_inside_insert_before: "#- {"
if not_inside_insert_after: "}"
remove_if_exists: MENUINSERT
insert_before: "}"    # jos puuttuu, niin kursorin kohtaan

Toki voisi miettiä voisivatko menut olla ihan "Plugineja", joissa on JS tai Typescript koodi mitä pitää tehdä ja sopivasti "kirjastokutsuja" asian helpottamiseksi. Riskinä on tietysti noiden turvallisuus silloin. Sama koskee myös toki YAML-tyylistä, sillä aina kun joku saa kirjoittaa regexpin, sen voi kirjoittaa niin monimutkaiseksi että se vie kaiken prosessoriajan.

TIM-JYU / TIM