LaTeX: Introduzione e Risorse

Guide introduttive

Il principale riferimento italiano per tutto ciò che riguarda LaTeX è il Gruppo Italiano di Utilizzatori TeX dove sono disponibili numerose guide. Nello stesso sito è anche disponibile uno stile per scrivere una tesi di laurea.

Per quanto riguarda la documentazione in inglese, il documento decisamente più utilizzato è The not so Short Introduction to LaTeX di cui esiste anche una traduzione in italiano che, purtroppo, non è stata aggiornata di recente.

Informazioni generali

Bisogna sempre ricordarsi che LaTeX è fondamentalmente un linguaggio di programmazione specializzato per la tipografia. Quindi si scrive un programma che viene poi tradotto, da un programma apposito, in un file che può essere stampato o visto su schermo.

Inizialmente questo file visualizzabile era in formato dvi, il quale poteva poi trasformato in un file Postscript per essere stampato. Più recentemente ci si è standardizzati sulla generazione di un file PDF direttamente dal file LaTeX, utilizzando il programma pdflatex.

Per scrivere un file LaTeX è sufficiente utilizzare un qualsiasi editor di testi. La pagina di Wikipedia Comparison of TeX editors riporta vari editor confrontando le loro caratteristiche legate a LaTeX. Per chi vuole un approccio più semplice possibile, consiglio Lyx, mentre chi desidera avere un controllo maggiore del file LaTeX è preferibile un editor di testi per programmatori con un plugin per LaTeX (ad esempio Emacs con AucTex oppure Eclipse con TeXlipse)

Siccome TeX è un linguaggio di programmazione, sono disponibili molte estensioni o pacchetti (package). I più importanti vengono inclusi nell’installazione di LaTeX: in ogni caso sono disponibili sul CTAN (Comprehensive TeX Archive Network). La Breve guida ai pacchetti più comuni ne descrive i principali. A questi vanno aggiunti sicuramente memoir (per controllare completamente gli aspetti tipografici di un libro o di una tesi), beamer (per le presentazioni), tikz/pgf (per i grafici) e Sweave (per integrare LaTeX e programmi in R).

Risorse aggiuntive

TikZ and PGF examples. Disegnare figure con TikZ è piuttosto complicato, ma i risultati sono eccellenti. Alcuni esempi possono aiutare a capire come fare.

Tex.Sx. Il Forum su LaTeX più attivo.

Advertisements

Change hotkey to activate Dash in Unity 2D

I am a big fan of Unity 2D. Yes, I really like that, esr’s opinion notwithstanding. Compared to standard unity, it is much smoother and without annoying eye-candy animations. The only problem is the lack of a simple tool to configure Unity 2D.

The only option I really want is to change the hotkey for activating the Dash; the default is the Super key (that usually means the Win key), which is not ok with me, as I remapped the Win key to the Meta key (much more used inside Emacs).

After a bit of googling I reached a relevant Ask Ubuntu thread which, unfortunately, refers to an older version of Unity-2D. After some investigation I found that the new command that must be associated to the hotkey is

dubs-send --type=method_call --dest=com.canonical.Unity2d.Dash /Dash com.canonical.Unity2d.Dash.activateHome

To choose the hotkey you can follow the path System settings -> keyboard settings and finally set the desired shortcut.

Clarified Artistic License

For some reasons that are totally unkown to me, some websites keep linking to my older website for a text of the Clarified Artistic License, so I decided to report it here.
In 1998 I wrote the implementation of the Reduce-Expand algorithm for solving the LCS (Longest Common Subsequence) problem. At the time my understanding of free software licenses was pretty naive, so I settled for the Clarified Artistic License, which was the ncftp license with a few very minor rewordings.
Today I feel quite a pain when I see a new software license, as I think that the fragmentation of the various license is a small but totally unnecessary hurdle towards world domination. As a consequence, I support only GPL/LGPL/AGPL. I understand that somebody might prefer adoption to preserving software freedom and consequently chooses a BSD license, but that is not my choice. Especially after the JMRI trial I believe that copyleft licenses should really be the default option, so I changed the license of my implementation to the GPL.

Anyway, in case you find it useful, the text of the Clarified Artistic License is below.

Preamble

The intent of this document is to state the conditions under which a Package may be copied, such that the Copyright Holder maintains some semblance of artistic control over the development of the package, while giving the users of the package the right to use and distribute the Package in a more-or-less customary fashion, plus the right to make reasonable modifications.

Definitions:

“Package” refers to the collection of files distributed by the Copyright Holder, and derivatives of that collection of files created through textual modification.
“Standard Version” refers to such a Package if it has not been modified, or has been modified in accordance with the wishes of the Copyright Holder as specified below.
“Copyright Holder” is whoever is named in the copyright or copyrights for the package.
“You” is you, if you’re thinking about copying or distributing this Package.
“Distribution fee” is a fee you charge for providing a copy of this Package to another party.
“Freely Available” means that no fee is charged for the right to use the item, though there may be fees involved in handling the item. It also means that recipients of the item may redistribute it under the same conditions they received it.

  1. You may make and give away verbatim copies of the source form of the Standard Version of this Package without restriction, provided that you duplicate all of the original copyright notices and associated disclaimers.
  2. You may apply bug fixes, portability fixes and other modifications derived from the Public Domain, or those made Freely Available, or from the Copyright Holder. A Package modified in such a way shall still be considered the Standard Version.
  3. You may otherwise modify your copy of this Package in any way, provided that you insert a prominent notice in each changed file stating how and when you changed that file, and provided that you do at least ONE of the following:
    1. place your modifications in the Public Domain or otherwise make them Freely Available, such as by posting said modifications to Usenet or an equivalent medium, or placing the modifications on a major network archive site allowing unrestricted access to them, or by allowing the Copyright Holder to include your modifications in the Standard Version of the Package.
    2. use the modified Package only within your corporation or organization.
    3. rename any non-standard executables so the names do not conflict with standard executables, which must also be provided, and provide a separate manual page for each non-standard executable that clearly documents how it differs from the Standard Version.
    4. make other distribution arrangements with the Copyright Holder.
    5. permit and encourge anyone who receives a copy of the modified Package permission to make your modifications Freely Available in some specific way.
  4. You may distribute the programs of this Package in object code or executable form, provided that you do at least ONE of the following:
    1. distribute a Standard Version of the executables and library files, together with instructions (in the manual page or equivalent) on where to get the Standard Version.
    2. accompany the distribution with the machine-readable source of the Package with your modifications.
    3. give non-standard executables non-standard names, and clearly document the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version.
    4. make other distribution arrangements with the Copyright Holder.
    5. offer the machine-readable source of the Package, with your modifications, by mail order.
  5. You may charge a distribution fee for any distribution of this Package. If you offer support for this Package, you may charge any fee you choose for that support. You may not charge a license fee for the right to use this Package itself. You may distribute this Package in aggregate with other (possibly commercial and possibly nonfree) programs as part of a larger (possibly commercial and possibly nonfree) software distribution, and charge license fees for other parts of that software distribution, provided that you do not advertise this Package as a product of your own. If the Package includes an interpreter, You may embed this Package’s interpreter within an executable of yours (by linking); this shall be construed as a mere form of aggregation, provided that the complete Standard Version of the interpreter is so embedded.
  6. The scripts and library files supplied as input to or produced as output from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whoever generated them, and may be sold commercially, and may be aggregated with this Package. If such scripts or library files are aggregated with this Package via the so-called “undump” or “unexec” methods of producing a binary executable image, then distribution of such an image shall neither be construed as a distribution of this Package nor shall it fall under the restrictions of Paragraphs 3 and 4, provided that you do not represent such an executable image as a Standard Version of this Package.
  7. C subroutines (or comparably compiled subroutines in other languages) supplied by you and linked into this Package in order to emulate subroutines and variables of the language defined by this Package shall not be considered part of this Package, but are the equivalent of input as in Paragraph 6, provided these subroutines do not change the language in any way that would cause it to fail the regression tests for the language.
  8. Aggregation of the Standard Version of the Package with a commercial distribution is always permitted provided that the use of this Package is embedded; that is, when no overt attempt is made to make this Package’s interfaces visible to the end user of the commercial distribution. Such use shall not be construed as a distribution of this Package.
  9. The name of the Copyright Holder may not be used to endorse or promote products derived from this software without specific prior written permission.
  10. THIS PACKAGE IS PROVIDED “AS IS” AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A  PARTICULAR PURPOSE.

Emacs development

The message http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01268.html by Eric Raymond has pointed out some of the main fallacies of the development process of Emacs:

  1. use of an outdated version control system, that is cvs.
  2. lack of a modern (or fashionable) interface between core developers and users/non-core developers
  3. long time between releases.

A long thread started from there, involving most of the well-known Emacs core developers. I have found that message (and the whole thread) really interesting, especially since ESR wrote the “curse of the gifted” message that sparked the discussion on using a version control system for the Linux kernel.
I want to point out my point of view on the matter, as I am quite far from a typical (or good) Emacs contributor, while using Emacs a lot and occasionally lurking on emacs-devel. I believe that Emacs contributors can be divided in a few categories:

  1. core developers (a few dozens) who know the intricacies of the C part and the most important Lisp parts.
  2. important developers: they are more specialized to some Lisp parts of the project, but their work is completely integrated in Emacs (ESR is now a good example of the category with his recent work on VC),
  3. external developers: like category (2), but the parts they are working on is not integrated within Emacs, therefore their release schedule does not follows Emacs’s. Some of those parts might be integrated into Emacs sometime in the future, and the developer might be actively working in that direction. (Stefan Reichör is an example of such category, with his work on PSVN and DVC).
  4. contributors: they are not really in charge of any code, but they can fill bug reports, update documentations, occasionally send a patch.
  5. users: they might send a bug report.

Clearly those categories are not that disjoint: for example David Kastrup is in category (1), but his work on AucTeX would be in (3) – at least until AucTeX is integrated into Emacs.
I summarize some of the peculiarities of Emacs’s development process:

  1. all code is review in the emacs-devel mailing list.
  2. the bugs reports are collected in the bug-gnu-emacs mailing list
  3. the guideline states that, in order to send a bug report to bug-gnu-emacs, only a vanilla version of Emacs (that is compiled from original sources and invoked without any .emacs file) can be used. This rules out any version of Emacs found in a major Linux distribution.
  4. One of the goal of Emacs development is the advance of free software. RMS has used that argument for rejecting some feature requests. This is not abad idea per se, but it clearly slows down development.
  5. All copyrights regarding the code must be assigned to the FSF.
  6. A considerable number of the core developers have stated that batch processing of Emacs-related issues is a necessity. RMS has stated that only emails fulfill his needs for bugs handling and code review.

Why have I decided to write this post?

Because Emacs is one of the very few programs that really improve my productivity. The only other software I could not give up using is the LaTeX suite. I could probably adapt to use any major OS (but I am sold on Ubuntu for the foreseeable future), any major browser and ail reader (ditto for Firefox and Thunderbird). I don’t use anything else hat much.

In which category do I fall?

Right now only (5). What is relevant to this post is hat I will likely, within the right environment, escalate to (4). It is much less likely, though not impossible, to go up to rank (3).

My main points are:
1. Emacs would benefit from a good integrated package manager (ELPA is an adequate starting point).
2. A modern, web-based, bug tracker is indispensable for increasing the number of people in categories (3) and (4).
3. The bug tracker must include also bugs from vendor-packaged versions of Emacs as well as different Emacs-related external packages.
4. Using a distributed version control system would help in increasing development speed, especially for external packages.

I now elaborate my main points and give some proposals.
1. Emacs would benefit from a good integrated package manager.

I don’t think this is controversial. The emergence of ELPA and XEmacs history is already a proof that this is a good idea. The only real reason for not already having such a system integrated into Emacs, is that RMS has opposed to the idea as it would enable (or ease) the possibility of using non-free extensions of Emacs.

In my opinion such concern is only partially correct; while I agree that a package manager would lower the technical efforts for using a non-free extension, I do not see any widespread non-free extensions, so there would not be many (if any at all) users switching to some non-free programs.

If any user/developer would be that determined to use some non-free extensions, it should not be too difficult to modify ELPA to include a different repository including non-free extensions; this makes even less meaningful the idea of rejecting a package manager altogether.

My proposal is to integrate ELPA (or a similar program) into Emacs, hardcoding two package repositories: one from savannah.gnu.org and the other from savannah.nongnu.org. Both repositories must contain only GPL packages, so that
no harm is done to the FSF cause. Almost all the people in category (3) – the one involved in a package system – aim at a possible integration into Emacs and/or a spot in the daylight: I believe that the possibility of becoming at least a de facto standard component of Emacs (even if not officially integrated into it) would be strong motivation for external developers.

2. A modern, web-based, bug tracker is indispensable.

Indispensable is strong word, but it is what I believe and it is true for me. I have sometimes contributed some bug reports, mainly through the Debian bugs tracking system. I would surely do the same for Emacs, assuming that I am able
to find a bug in Emacs. Actually I have a nagging problem in Emacs, regarding scrolling pressing the cursor-down key, but I have never reported it for a couple of reasons: the gnu.emacs.bugs mailing list is populated by Emacs ubergeeks and this fact can be quite intimidating, it is too easy to send a bogus bug report and receive an embarassing response; the second reason is that I would have to test if the bug is still there in a vanilla emacs.

If a bogus report could be simply dismissed by a developer closing the bug report, then the bar would be lowered.

Notice that web-based doesn’t mean web-based-only. Integration with email is possible and welcome. At the same time web-based bug tracking can be ugly; I still cannot stand bugzilla and I have some problems with launchpad, for
example. I think that the Debian bug tracking is a much better starting point: already integrated with email (bugs can be
closed by email), a clean interface which is suitable to text-based browsers, good defaults for severity, good integration with changelogs (bugs can be closed by uploading a revision with the appropriate changelog).

The real advantage of a public web-based bugs tracking system is priorityzing and classifying bugs; it is clear to everybody which are the important bugs and which are the bugs that can be solved by a wanna-be Emacs developer. Documentation issues can be clearly marked as such and could be a good starting point for a newbie.

My proposal: customize the Debian BTS, including a bidirectional gateway to/from the BTS to each major distribution BTS for dealing also with distribution-specific issues.

3. The bug tracker must include also bugs from vendor-packaged versions of Emacs as well as different Emacs-related external packages.

I have already advocated the idea of including bugs from different GNU/Linux distributions. The main reason for including also the external packages is that of giving more importance their developers: keep in mind that they contribute greatly to making Emacs a wonderful editor for a number of people (I would not use Emacs without AucTeX).

4. Using a distributed version control system would help in increasing development speed, especially for external packages.

The advantages of disconnected operations are becoming evident to most developers: commuting or long-distance flights are quite common among programmers. Any distributed version control system stores locally the entire project history, allowing all operations even without net access. Notice that in the same conditions even a simple cvs/svn log is impossible.