Translated by sunoc

Added: 2, Deleted: 0, Modified: 0 (Conflicts: 0)
This commit is contained in:
sunoc 2024-10-28 23:49:28 +09:00
parent 95ccfeede2
commit 2e3ba0e62d

View File

@ -38647,6 +38647,14 @@ ok</note>
<seg>Comme le renvoi peut se produire au milieu dun mot, les lignes continues peuvent être difficiles à lire.</seg>
</tuv>
</tu>
<tu>
<tuv lang="en">
<seg>Since there are no more enclosing expressions to evaluate, the interpreter prints that value in the echo area.</seg>
</tuv>
<tuv lang="fr" changeid="sunoc" changedate="20241028T144924Z" creationid="sunoc" creationdate="20241028T144924Z">
<seg>Étant donné qu'il n'y a pas d'expression autour à évaluer, l'interpréteur imprime cette valeur dans la zone d'écho.</seg>
</tuv>
</tu>
<tu>
<tuv lang="en">
<seg>Since we are discussing customization, we should tell you about @dfn{variables}.</seg>
@ -48540,6 +48548,14 @@ de temps en temps comment le GNU Emacs Lisp diffère du Common Lisp.</seg>
<seg>Que trouvons-nous ici ?</seg>
</tuv>
</tu>
<tu>
<tuv lang="en">
<seg>What happens is that the Lisp interpreter first evaluates the inner expression, @code{(+ 3 3)}, for which the value 6 is returned; then it evaluates the outer expression as if it were written @code{(+ 2 6)}, which returns the value 8.</seg>
</tuv>
<tuv lang="fr" changeid="sunoc" changedate="20241028T144832Z" creationid="sunoc" creationdate="20241028T144832Z">
<seg>Ce qu'il s'est passé est l'évaluation de l'expression interne par l'interpréteur Lisp en premier, @code{(+ 3 3)}, pour laquelle la valeur 6 est retournée; ensuite il évalue l'expression externe comme si elle était écrit @code{(+ 2 6)}, ce qui retourne la valeur 8.</seg>
</tuv>
</tu>
<tu>
<tuv lang="en">
<seg>What height for the Y axis?</seg>