<?xml version="1.0" encoding="utf-8" ?>

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:thr="http://purl.org/syndication/thread/1.0">
<channel xml:lang="">

	<title>&#91;Geekographie Ma&#239;eulesque&#93; titre page forum suivi RSS Eledform</title>
	<link>http://geekographie.maieul.net/103</link>
	<description></description>
	<language></language>
	
	<item>
		<title>Eledform</title>
		<link>http://geekographie.maieul.net/103#comment489</link>
		<guid isPermaLink="true">http://geekographie.maieul.net/103#comment489</guid>
		<dc:date>2012-10-12T07:16:22Z</dc:date>
		<dc:format>text/html</dc:format>
		<dc:language>fr</dc:language>
		<thr:in-reply-to type="text/html"
			ref="http://geekographie.maieul.net/489"
			href="http://geekographie.maieul.net/489" />
		<dc:creator>Pierre ChPr</dc:creator>
		<description>&lt;p&gt;Salut Ma&#239;eul,
J'avais lu ton pr&#233;c&#233;dent article (sur la formalisation) qui m'avait fort int&#233;ress&#233;, tu t'en doutes.
J'ai pomp&#233; sans vergogne ta fa&#231;on de faire des listes de manuscrits en &lt;span class=&#034;caps&#034;&gt;CSV&lt;/span&gt; dans les commandes. En revanche, je ne suis pas convaincu par ta commande \var. &#192; mon avis, ce n'est pas cela dont nous avons besoin. D'abord, la syntaxe ne me para&#238;t pas simplifier beaucoup celle de \edtext. Ensuite et surtout, je crois que nous perdons en souplesse. Les variantes textuelles, et g&#233;n&#233;ralement tout ce qu'il faut indiquer dans un apparat, sont malheureusement de types bien trop vari&#233;s et les cas particuliers qui ne manqueront pas de se pr&#233;senter seront difficilement traitables dans \var.
Du coup, j'ai pris le parti de cr&#233;er plusieurs commandes, qui me permettent d'introduire de la formalisation, sans mettre la mati&#232;re dans un carcan. J'ai une commande pour les omissions, une pour les additions, une pour les variantes, une pour les notes marginales port&#233;es dans le manuscrit, etc.&lt;small class=&#034;fine d-inline&#034;&gt;&#160;&lt;/small&gt;; et je continue de mettre &#231;a dans \edtext.
Par exemple&#160;:&lt;/p&gt;
&lt;div class=&#034;precode&#034;&gt;&lt;pre dir=&#034;ltr&#034; style=&#034;text-align:left;&#034;&gt;&lt;code&gt;\edtext{Lorem \edtext{ipsum}{\Cfootnote{\habet{D,F,M} \mutat{A,C}{eum} \inmargineadd{G} \omittit{B}; eum \Vulgata}} dolor sit amet, consectetur adipiscing elit.}{\lemma{lorem -- elit}\Afootnote{\bibleverse{IIKings}(8:32)}}&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;
&lt;p&gt;Il y a une le&#231;on que j'ai prise (et je m'aper&#231;ois que plusieurs chercheurs autour de moi en sont &#224; peu pr&#232;s au m&#234;me point) en m'acharnant ces derni&#232;res ann&#233;es sur la formalisation informatique des donn&#233;es dans ma mati&#232;re&#160;: c'est que point trop n'en faut&#8230; Parce que nos donn&#233;es sont trop instables par nature. Elles sont irr&#233;m&#233;diablement prises dans de la p&#226;te humaine, trop humaine&#160;: il arrive toujours un moment o&#249; le formulaire dont la formalisation informatique a besoin est pris en d&#233;faut, parce que (par exemple) le copiste de tel manuscrit a fait une v&#233;ritable &#226;nerie unique en son genre, ce genre de choses.
Du coup, je me rabats sur un mi-chemin de la formalisation. Il est ind&#233;niablement utile de pouvoir lister les manuscrits, les rassembler et les s&#233;parer quand ils portent la m&#234;me variante, de pouvoir changer la mise en forme des sigles en quelques clics sur tout le document, ce que LaTeX fait admirablement. En revanche, trop de formalisation risque de me faire t&#244;t ou tard tomber dans un pi&#232;ge&#8230; Je pr&#233;f&#232;re m'en pr&#233;server en utilisant une syntaxe un peu plus &#171;&lt;small class=&#034;fine d-inline&#034;&gt;&#160;&lt;/small&gt;bateau&lt;small class=&#034;fine d-inline&#034;&gt;&#160;&lt;/small&gt;&#187; certes, mais plus esclave de mes instructions, plus susceptible de recevoir un ordre qui ne concernera pas les autres occurrences.&lt;/p&gt;</description>
	</item>

</channel>
</rss>
