| 1 | Parsing. il motivo principale è mantenere i paragrafi, senza doverli marcare esplicitamente nel testo. Stanco di dover usare il caratterino inutile, e poi dovermi ricordare quando il caratterino invece non ci vuole, perchè devo non-chiudere il paragrafo, o chiuderlo dopo.
|
|---|
| 2 |
|
|---|
| 3 | Quindi, parsing e generazione automatica dei paragrafi. Un paragrafo inizia quando inizia il testo, e finisce con una riga vuota, seguita da altro testo. Più righe vuote, o righe vuote che non sono seguite da testo (quindi comandi), non generano una fine del paragrafo.
|
|---|
| 4 |
|
|---|
| 5 | Alternative usate altrove:
|
|---|
| 6 | - paragrafi per il comando "gq" di vim
|
|---|
| 7 | un paragrafo finisce quando l'ultimo carattere prima di \n NON
|
|---|
| 8 | è un whitespace.
|
|---|
| 9 | Ogni paragrafo che si intende continuante ha un whitespace in fondo
|
|---|
| 10 | - paragrafi yaml: |
|
|---|
| 11 | yaml limita tutto con l'indentazione, ma la cosa interessante è
|
|---|
| 12 | l'utilizzo di un carattere diverso all'inizio del paragrafo per
|
|---|
| 13 | indicare un blocco di testo in cui i newline abbiano ("|") o meno
|
|---|
| 14 | (">") valore
|
|---|
| 15 | - paragrafi reST: (pydoc)
|
|---|
| 16 | praticamente quelli descritti: linea vuota -> nuovo paragrafo.
|
|---|
| 17 | il resto mancia.
|
|---|
| 18 |
|
|---|
| 19 | Cose che devono esserci:
|
|---|
| 20 |
|
|---|
| 21 | - Titoli e sezioni
|
|---|
| 22 | La prima riga dovrebbe essere il titolo della pagina, così ci metto poco a caricarlo. Il titolo dovrebbe finire nella variabile %%titolo%% per poter essere utilizzato nel template, ed è l'unico che si merita H1/H2? (controllare fatto ^1) Sarebbe bello poter mettere anche altri titoli nella pagina, ma questi sarebbero ad un livello superiore cmq, H(x+1), e quindi gestiti dai normali comandi.
|
|---|
| 23 |
|
|---|
| 24 | [1] Mike: H1 nome sito, H2 articolo
|
|---|
| 25 | Dave: H1 nome sito, H2 articoli (alcuni più piccoli)
|
|---|
| 26 | Mark: H1 nome sito, H1 sezione `Journal`?, H2 articoli, H3 sottosezioni
|
|---|
| 27 | Jason:
|
|---|
| 28 | home: niente H1?, H2 titolo + link all'articolo, ma anche sezioni nell'articolo
|
|---|
| 29 | pagine articoli: H1 titolo articolo, H2 sezioni come sopra
|
|---|
| 30 |
|
|---|
| 31 | * mi sembrava che XHTML cristasse se non c'era un H(x-1) prima di un Hx...
|
|---|
| 32 |
|
|---|
| 33 | Proposte per sintassi dei titoli:
|
|---|
| 34 | Wikimedia/pedia: =Titolo H1= ==Titolo H2== etc.
|
|---|
| 35 | Pro: veloce da battere
|
|---|
| 36 | Con: si son visti testi più chiavabili
|
|---|
| 37 | reST:
|
|---|
| 38 | Titolo
|
|---|
| 39 | ======
|
|---|
| 40 |
|
|---|
| 41 | dove l'underline può essere fatto con uno di tot caratteri
|
|---|
| 42 | a piacere tra cui "-" "=" "#" "^" ed altri
|
|---|
| 43 | ci può essere anche un OVERLINE (NON semanticamente rilevante)
|
|---|
| 44 |
|
|---|
| 45 | sematica complessa: il primo stile usato diventa SEMPRE h1
|
|---|
| 46 | gli altri a seguire h2, h3 etc
|
|---|
| 47 |
|
|---|
| 48 | Pro: geniale
|
|---|
| 49 | Con: a bitch to parse (been there, tried, got tired - ambiguità)
|
|---|
| 50 |
|
|---|
| 51 | Personalmente, uso la sintassi wikipedia ovunque mi capiti
|
|---|
| 52 |
|
|---|
| 53 | Direi che userò una cosa simile a wikimedia, ma da un lato solo, che da due mi ha sempre disturbato, ed è inutile e pars-fastidiosa. L'H1 è fisso direi, gli altri preceduti da trattini, che è la "sintassi" che uso di solito nei miei txt
|
|---|
| 54 |
|
|---|
| 55 | -- Sezione
|
|---|
| 56 | --- sotto sezione
|
|---|
| 57 |
|
|---|
| 58 | Z/// Depreco fortemente la scelta
|
|---|
| 59 |
|
|---|
| 60 | - Paragrafi
|
|---|
| 61 | Questi sono semplici, ma sono il motivo per cui il parsing completo è necessario - due (o più) ritorni a capo consecutivi, cioé una riga vuota (o più), iniziano un nuovo paragrafo, a meno di non essere in un qualche comando. Il primo paragrafo è marcato no-indent (più capital letter?), così come 'paragrafi' che sono necessari solo perché stiamo scrivendo in html; questi dovrebbero essere scritti subito dopo comandi, senza lasciare righe vuote in mezzo.
|
|---|
| 62 |
|
|---|
| 63 | - Sostituzioni
|
|---|
| 64 | Sostituzioni semplici, di caratteri o combinazioni nel testo: virgolette, grassetto, m-dash. Questi non dovrebbero essere strettamente collegati ad un singolo simbolo di escape, ma potrebbe essere comodo (e semplificare il parsing).
|
|---|
| 65 |
|
|---|
| 66 | Al momento, esistono le seguenti sostituzioni:
|
|---|
| 67 | /testo/ blocco italico
|
|---|
| 68 | \-testo\- blocco mdash
|
|---|
| 69 | \- singolo mdash
|
|---|
| 70 | \" \" virgolette inglesi
|
|---|
| 71 | \< \> doppi angoli
|
|---|
| 72 |
|
|---|
| 73 | che potrebbero essere convertite in qualcosa di più simil-latex (che non è sempre migliore, ma è più facile ricordarsi una sintassi sola). Pur apprezzando /italics/, dubito che si possa mantenere; in effetti funzionava anche se c'erano spazi in mezzo però... sarebbe bello avere code/em/strong/? disponibili con pochi caratteri.
|
|---|
| 74 |
|
|---|
| 75 | A proposito, possibili sintassi:
|
|---|
| 76 | /testo/ questa richiede di marcare tutti i caratteri permessi, e se iniziano ad esserci trattini, virgole od altro, diventa troppo; potrei però metterla come scorciatoia?
|
|---|
| 77 | \em{testo} questa è molto latex, e richiede \ e { } come simboli
|
|---|
| 78 | {em testo} questa richiede solo { }, ma \ è già protetto per altri comandi
|
|---|
| 79 |
|
|---|
| 80 | Proposta alternativa:
|
|---|
| 81 | **BOLD**
|
|---|
| 82 | ''Italic''
|
|---|
| 83 | --mdash-- (non so perchè serva un concetto di BLOCCO mdash, peraltro=)
|
|---|
| 84 | <<double angle brackets>> (« » se serve)
|
|---|
| 85 | le virgolette inglesi prima vorrei vederle per esprimermi ma probabilmente
|
|---|
| 86 | ``virgolette inglesi``
|
|---|
| 87 |
|
|---|
| 88 | mi piacerebbe avere cose del genere, ma non vorrei riempire di "simboli chiave" che poi diventa difficile scrivere. *bold*, /italic/ e _underline_ sono quelli che uso di solito, quando non penso di scrivere codice, ma testo ---che è un po' il mio scopo qua. Questo punto va meditato assai.
|
|---|
| 89 |
|
|---|
| 90 | E perciò eccomi che medito:
|
|---|
| 91 | ideale: *bold* /italic/ _underline_ #code#
|
|---|
| 92 | problema: simboli rubati all'agricoltura, soprattutto /
|
|---|
| 93 |
|
|---|
| 94 |
|
|---|
| 95 | Virgolette inglesi: usare `` `` vuol dire che devo vedere il primo, leggere la stringa aspettando il secondo, poi sostituire: SUX. `` '' vuol direi che vedo il primo e sostituisco “, poi vedo il secondo e sostituisco ” senza sbattermi. Non sto pensando in espressioni regolari qua - ho lottato anni per farle convivere decentemente ed ho scoperto che -non si può-, a livello di prova matematica. E' per questo che sto scrivendo il parser, per non dover soffrire più (oltre al fatto che masochisticamente mi diverto a scrivere parser).
|
|---|
| 96 |
|
|---|
| 97 | Z // senza regexp non posso che informarti che lavori col freno a mano tirato, ma è un opinione OVVIA dal mio fronte. E no, non so nemmeno da dove iniziare a studiare la situazione a livello di lookup secco. Cioè lo so, ma è una violenza da cui Ginevra mi dovrebbe manlevare.
|
|---|
| 98 |
|
|---|
| 99 | oltretutto prevederei degli help per i latini privi di tastiera acconcia:
|
|---|
| 100 |
|
|---|
| 101 | a' à
|
|---|
| 102 | e' è
|
|---|
| 103 | e` é
|
|---|
| 104 | i^ î
|
|---|
| 105 | etc
|
|---|
| 106 |
|
|---|
| 107 | in fine parola, ovviamente
|
|---|
| 108 | Problema: in italiano aiutano, in francese NO (tutti in mezzo alla parola)
|
|---|
| 109 |
|
|---|
| 110 | Direi quindi di usare brutalmente la sintassi latex, che implica
|
|---|
| 111 |
|
|---|
| 112 | alcuni simboli direttamente: `` '' --- ~
|
|---|
| 113 | simboli speciali preceduti da uno slash: \\ \{ \} \- \< \>
|
|---|
| 114 | comandi preceduti da uno slash, seguiti da una non lettera: \comando
|
|---|
| 115 | comandi preceduti da uno slash, con uno o più parametri fra parentesi graffe: \comando{parametro}{parametro}
|
|---|
| 116 | comandi contenuti fra parentesi graffe, con un parametro: {comando parametro}
|
|---|
| 117 |
|
|---|
| 118 | Z// ah, ehm, ODIO la sintassi latex in genere, lamport andrebbe impalato.
|
|---|
| 119 | Z// argomentazione: troppi {} degenerano rapidamente in line noise e non di rado arrivano a dei livelli di clutter tali da generare piccoli buchi neri
|
|---|
| 120 |
|
|---|
| 121 | Tutto sta nell'evitare troppi {}. Poi latex porta la cosa alla pazzia estrema, vero, io cercherò di evitare e fermarmi alla pazzia semplice.
|
|---|
| 122 |
|
|---|
| 123 | Z// attento brother, qui mi ragioni da utente, non da language designer.
|
|---|
| 124 | certo, essere un good mannered user davanti a sistemi composti fondamentalmente di merda secca è auspicabile e lodevole, ma apprestarsi a definire un linguaggio dicendo "fornisco altra merda secca ad un mondo che non ne ha abbastanza, tanto so che con una certa fatica si può usare senza impazzire" è uhm, irresponsabile?
|
|---|
| 125 |
|
|---|
| 126 | F// quanti em/strong vuoi annidare?
|
|---|
| 127 |
|
|---|
| 128 | blocco decomandificante, introdotto da parentesi graffa più simbolo, termina con simbolo seguito da parentesi graffa: {#....#}
|
|---|
| 129 |
|
|---|
| 130 | solo dentro un blocco fra graffe è possibile inserire altri blocchi?
|
|---|
| 131 |
|
|---|
| 132 | Purtroppo sta diventando Turing-completo, ed è sempre una cosa da evitare.
|
|---|
| 133 | Z// qui ci troviamo d'accordo - e la seconda versione E' t-completa temo
|
|---|
| 134 |
|
|---|
| 135 | Alla fine non sono necessarie cose incredibili, ma alcune si:
|
|---|
| 136 |
|
|---|
| 137 | inserimenti di caratteri/sequenze
|
|---|
| 138 | inserimento di testo circondato da comandi
|
|---|
| 139 | riempimento di template usando parametri
|
|---|
| 140 | inserimento di testo che contiene caratteri speciali
|
|---|
| 141 |
|
|---|
| 142 | I caratteri speciali non dovrebbero "combattere" con l'html, così posso inserirlo inline senza problemi, quindi niente < > &, anzi, tutto quello che è in mezzo dovrebbe essere copiato pari pari ---che è un ottimo metodo per permettere l'uso di caratteri speciali.
|
|---|
| 143 |
|
|---|
| 144 | Z//Lasciare l'html libero e felice ha il suo senso, ma è anche fonte di magnificente slack nelle sintassi. Accade in wikipedia, dove non è mai stata creata una sintassi leggibile per le tavole con la scusa che tanto c'è <table><tr><td>...
|
|---|
| 145 |
|
|---|
| 146 | potresti usare qualche forma di bounding leggero dell'html tipo:
|
|---|