VirtualBox

Ticket #3805: minfail

File minfail, 8.8 KB (added by Fran, 15 years ago)

Text file that can be used to reproduce the bug

Line 
1Parsing. 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
3Quindi, 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
5Alternative 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
19Cose che devono esserci:
20
21- Titoli e sezioni
22La 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
33Proposte 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
61Questi 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
64Sostituzioni 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
66Al momento, esistono le seguenti sostituzioni:
67 /testo/ blocco italico
68 \-testo\- blocco mdash
69 \- singolo mdash
70 \" \" virgolette inglesi
71 \< \> doppi angoli
72
73che 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
75A 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
80Proposta alternativa:
81**BOLD**
82''Italic''
83--mdash-- (non so perchè serva un concetto di BLOCCO mdash, peraltro=)
84<<double angle brackets>> (&laquo; &raquo; se serve)
85 le virgolette inglesi prima vorrei vederle per esprimermi ma probabilmente
86``virgolette inglesi``
87
88mi 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
90E perciò eccomi che medito:
91 ideale: *bold* /italic/ _underline_ #code#
92 problema: simboli rubati all'agricoltura, soprattutto /
93
94
95Virgolette 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 &ldquo;, poi vedo il secondo e sostituisco &rdquo; 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
97Z // 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
99oltretutto prevederei degli help per i latini privi di tastiera acconcia:
100
101a' &agrave;
102e' &egrave;
103e` &eacute;
104i^ &icirc;
105etc
106
107in fine parola, ovviamente
108Problema: in italiano aiutano, in francese NO (tutti in mezzo alla parola)
109
110Direi 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
118Z// ah, ehm, ODIO la sintassi latex in genere, lamport andrebbe impalato.
119Z// argomentazione: troppi {} degenerano rapidamente in line noise e non di rado arrivano a dei livelli di clutter tali da generare piccoli buchi neri
120
121Tutto sta nell'evitare troppi {}. Poi latex porta la cosa alla pazzia estrema, vero, io cercherò di evitare e fermarmi alla pazzia semplice.
122
123Z// attento brother, qui mi ragioni da utente, non da language designer.
124certo, 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
126F// 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
132Purtroppo sta diventando Turing-completo, ed è sempre una cosa da evitare.
133Z// qui ci troviamo d'accordo - e la seconda versione E' t-completa temo
134
135Alla 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
142I 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
144Z//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
146potresti usare qualche forma di bounding leggero dell'html tipo:

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy