Jest coś takiego jak Katalog Polskiej Muzyki Akordeonowej (KPMA), który powstaje przy wykorzystaniu cutting edge technologii: jest redagowany jako plik XML w edytorze strukturalnym.

Na początku KPMA był plikiem TeXowym, później (2002 r.) został przerobiony na XML i odtąd był redagowany w Emacsie, w trybie psgml. Struktura dokumentu była/jest opisana za pomocą stosownego DTD, które psgml potrafi interpretować.

W tzw. międzyczasie tryb psgml stał się obsolete na rzecz nXML. Można wprawdzie dalej używać psgml (działa bez problemów) i być może dałoby się skonfigurować Emacsa, w taki sposób iż dokumenty KPMA byłby redagowane w psgml a inne dokumenty XML w trybie nXML, ale koniec końców zdecydowałem się na zmianę.

Aby zmienić DTD na RNC, wystarczy posłużyć się trangiem:

trang -I dtd -O rnc lkompc.dtd lkompc.rnc

Teraz należy dodać schemat do konfiguracji nXML. Wystarczy w tym celu wczytać plik Kompozycje.xml a następnie wybrać XML→Set Schema→File. Wybrać plik lkompc.rnc. W katalogu z dokumentem XML (tj. Kompozycje.xml w tym konkretnym przypadku) zostanie zapisany plik schemas.xml, zawierający:

<?xml version="1.0"?>
<locatingRules xmlns="http://thaiopensource.com/ns/locating-rules/1.0">
  <uri resource="Kompozycje.xml" uri="lkompc.rnc"/>
</locatingRules>

Od tego momentu Kompozycje.xml będzie edytowany z nastawami schematu określonymi w lkompc.rnc.

Aparat PTP

Od ręki nie działa. Próbowałem rozwiązać problem instalując następujące pakiety:

yum install  gphoto2 gvfs-gphoto2 gtkam digikam gthumb geeqie

Geeqie to zamiennik gqview, które używałem do tej pory. DigiKam nie działa (gryzie się z XFce). Wydaje mi się, że większość tego co zainstalowałem nie jest potrzebna -- istotne jest geeqie, dzięki któremu mogę wygodnie zaimportować zdjęcia z aparatu na komputer (lądują w katalogu ~/Pictures).

Wysyłanie fotek na flickr.com za pomocą Emacsa

Prawie działa. Problem stanowią słowa kluczowe zawierające polskie znaczki. Trzeba nieco zmodyfikować skrypty generujące bazę słów kluczowych tj. flickr_getalltags, i inne.

Cała procedura odświeżania tagów i innych metadanych jest uruchamiana skryptem flickr_update_kb, który w uproszczeniu wygląda następująco:

#!/bin/bash
# Get list of public photos with 'flickr.people.getPublicPhotos
flickr_getphotolist.pl -u hr.icio

# Refreshing information on tags/sets/geolocs"
# Get information on sets defined by the user:
flickr_getsets && \
# Get tags from flickr for current user
flickr_getalltags && \
# Get information on groups to which one can add photos
flickr_getgroups && \
## For flickr_xml2el we need _special treatment_ otherwise UTF is spoiled
PERL_UNICODE=S flickr_xml2el > ~/.flickr/hr.icio.el

cd ~/.knows &&  make 2flicker && \
cd ~/.flickr && make check

Z nieustalonych powodów cześć komunikatu zwracana przez flickra jest teraz kompresowana (a nie była -- nowsza wersja pakietu Perla?). Z tego też powodu konstrukcja (ze skryptu flickr_getalltags.pl -- w innych skryptach podobnie):

my $xm = $xmlp->XMLin($response->{_content}, forcearray=>[raw]);

została zamieniona na:

## zmienione 15.08.2011 (gzip as content-encoding)
## ustalenie w jakim `content_encoding' jest _content
my $content_encoding = $response->{_headers}->{'content-encoding'} ;
my $plain_content;
if ($content_encoding =~ /gzip/ ) {## jeżeli gzip to odpakować:
    $plain_content = Compress::Zlib::memGunzip( $response->{_content});
} else { $plain_content = $response->{_content};  }

Powyższe załatwia problem z (nie) działaniem skryptów flickr_getphotolist.pl, flickr_getsets, flickr_getalltags, flickr_getgroups.

Konwersja plików XML do formatu Emacsa za pomocą skryptu flickr_xml2el daje w rezultacie las komunikatów Wide character in print at... a plik wynikowy jest błędnie kodowany. Problem ciągle wraca a ja ciągle nie wiem czemu. Zaślepkowo pomogło dodanie PERL_UNICODE=S (zaklęcie to należy wstawić w odpowiednie miejsce także do pliku Make w katalogu ~/.knows).

Po tych wszystkich ww. zabiegach (które zajęły mi pół dnia) jestem w stanie odświeżyć bazę metadanych z mojego konta na flickr.com. Sukces:-)

Poniższe przypisuje zmiennej current-year napis zawierający numer bieżącego roku:

(setq current-year (number-to-string (nth 5 (decode-time (current-time)))))

Bez number-to-string zmienna current-year zawierałaby liczbę. Ale wtedy byłby problem jeżeli coś takiego byłoby argumentem funkcji concat.

Od 29 lipca 2009 najnowszą wersją Emacsa jest 23.1. Warto zmienić wersję 22 na 23, bo ta ostatnia potrafi m.in. korzystać z fontów TrueType.

Skrypt Erika Möllera , którego używałem do ładowania zdjęć na WikiCommons przestał działać. Konsultacja na stronie wykazała, że jest outdated and should be considered deprecated and useless. Program proponowany w zamian nie podoba mi się. Może i jest dobry, ale zbytnio się różni od poprzedniego a ja nie mam czasu go rozgryzać. Znalazłem za to poprawioną wersję skryptu Möllera, która działa, tutaj (lub tutaj).

Jest ciągle problem z kodowaniem (używam domyślnie ISO-8859-2), bo po przesłaniu na WC tekst jest niepoprawnie zakodowany. Metodą prób i błędów ustaliłem, że działa dopisanie na początku skryptu czegoś takiego:

binmode( STDOUT, ':utf8' );
use open IN => ':encoding(iso-8859-2)'; ## I am using legacy encoding, ha!
use open OUT => ':utf8'; ## write utf8

Opis zdjęcia w pliku tekstowym jest w ISO, po przesłaniu na WC kodowanie jest OK. Próbowałem wysyłać pliki kodowane jako UTF-8, ale to też nie działało (mój perl jest w wersji v5.8.8).

Rysunek obok znalazłem przypadkiem. Ktoś skopiował moje zdjęcie z flickr.com na WC dodając zabawny opis...

Przy okazji ustaliłem jak przejść do ,,trybu UTF'' otwierając nowy plik w Emacs: C-x C-m f utf-8

Opisany wcześniej skrypt uruchamiam ,,spod'' Emacsa działającego w trybie BibTeX. Konkretniej poniższa funkcja bibtex-adjust-pdf-filename pobiera wartości pól author, title, year oraz tp:keywords, a następnie przekazuje te wartości w postaci argumentów ww. skryptu uruchamianego jako polecenie systemowe. Mam nadzieję dzięki temu mieć większy porządek w przechowywanych dokumentach pobranych z różnych archiwów elektronicznych.

(defun bibtex-adjust-pdf-filename (file)
"Dla bieżącego rekordu bibtexa modyfikuje plik zawierający relewantny dokument PDF 
(dodaje co trzeba do słownika Info oraz modyfikuje nazwę). Oryginalna nazwa pliku
PDF jest podana z minibufora. Modyfikacja jest dokonywana przez zewnętrzny skrypt. 
Cała ta procedura jest po to żeby można łatwiej później odszukać plik na dysku...."
  (interactive "fNazwa pliku: ")
  (save-excursion
    (bibtex-beginning-of-entry)
    (let* ( (author (bibtex-text-in-field "author"))
	    (year (bibtex-text-in-field "year")) 
	    (keywords (bibtex-text-in-field "tp:keywords")) 
	    (title (bibtex-text-in-field "title")) 
	    (command (format "%s -rename -f \"%s\" -t \"%s\" -a \"%s\" -k \"%s\" -y \"%s\""
			  (executable-find "pdf_set_info.pl") ;; script name
			  (expand-file-name file) title author keywords year)) )
      (progn  (shell-command command)
	      (previous-line)
	      (beginning-of-line)
	      (insert (concat "%% patched with pdf_set_info.pl %%" ))))))

Przy okazji namiar na bloga anonimowego użytkownika Emacsa zawierającego parę ciekawych rzeczy.

W nazwiązaniu do poprzedniego wpisu. W dokumencie o XPath pojawia się taki oto fragment:

[predykat]*]]>

Co ma oznaczać, że wyrażenie ścieżkowe XPath składa się z  osi i testu oraz opcjonalnego predykatu, który może być powtórzony wielokrotnie (stąd *). Teraz standardowo szablony XSL Docbook (aka XSLDB) zamieniają ww. fragment XML na coś takiego:

oś::test[[predykat]*]

Niezręczność polega na tym, że nawiasy kwadratowe raz są używane do oznaczania części opcjonalnej a raz oznaczają, że należy je wstawić literalnie. W XSLDB znaki wstawiane wokół elementu optional są sparametryzowane -- są to mianowicie: arg.choice.opt.open.str oraz arg.choice.opt.close.str. Zamiast `[' i `]' zdecydowałem się na U+27E8 (Mathematical left angle bracket) oraz U+27E9 (Mathematical right angle bracket) Teraz próba uruchomienia:

xsltproc --stringparam arg.choice.opt.open.str "⟨" \
   --stringparam arg.choice.opt.close.str" select="⟩" ...

Kończy się błędem basha... Ciekawe czemu? Można podać ww. znaki binarnie -- wtedy wszystko działa. Ale UTF-8 w Makefile? Miałem opory, dodałem więc do arkusza uruchamiającego transformację XML → XHTML:

<xsl:param name="arg.choice.opt.open.str" select="'&#x27e8;'" />
<xsl:param name="arg.choice.opt.close.str" select="'&#x27e9;'" />

Teraz omawiany fragment wygląda mniej dwuznacznie:

oś::test⟨[predykat]*⟩

BTW w trybie nxml wpisanie ⟨ powoduje, że automagicznie kształt znaku pojawia się za średnikiem (ale nie jest wstawiany do tekstu -- po prostu jest to podpowiedź Emacsa, jak wygląda kształt znaku.) Dodatkowo po najechaniu myszą na encję wyświetlana jest nazwa znaku (w oknie podpowiedzi zwanym tooltip). Te ułatwienia są fajne w środowisku jednobajtowym--a ja póki co używam jako domyślnego kodowania ISO-8859-2.

Przy okazji użyteczne zestawienie znaków Unicode -- odpowiedników różnych TeXowych symboli matematycznych. Wystarczy zaznaczyć myszą i wkleić do Emacsa a następnie C-x = (what-cursor-position) wyświetli co zacz, w tym numer znaku.

Można używać nxml-mode do tworzenia schematów XSD. To odkrycie jest wynikiem szukania edytora/IDE ułatwiającego projektowanie Schemy. Oczywiście jest XMLSpy ale tylko dla MSW. Jest też jakiś moduł do netBeans, którego nie próbowałem... Niezbędny dla działania nxml-mode schemat do schemy w formacie RNG/RNC jest dostępny ze strony www.relaxng.org. W związku z tym odkryciem zmieniłem konfigurację emacsa:

(load "rng-auto.el")
;; http://www.emacswiki.org/emacs-en/NxmlMode
(add-to-list 'auto-mode-alist (cons (concat "\\." 
  (regexp-opt '("xml" "xsd" "rng" "xslt" "xsl" "svg" "rss") t) "\\'")
  'nxml-mode))

Należy teraz ,,zarejestrować'' schemat do schemy w pliku konfiguracyjnym pakietu nxml-mode (schema/schemas.xml):

  <uri pattern="*.xsd" typeId="XML Schema"/>
  <namespace ns="http://www.w3.org/2001/XMLSchema" typeId="XML Schema"/>
  <typeId id="XML Schema" uri="xmlschema.rnc"/>

Oryginalny schemat powoduje błąd: regular expression too big in xmlschema.rnc. Na tej stronie jest to dokładnie opisane i jest udostępniony plik .diff, tyle że nie byłem w stanie go zastosować uruchamiając patch. Poprawiłem plik ręcznie. Nie ma 100% gwarancji, że poprawka jest OK, ale dla kilku schematów nxml-mode działał poprawnie, więc szanse są, że tak jest. Poprawiony plik .rnc jest tutaj

Teraz wszystkie pliki XML (w tym szablony XSLT oraz schematy XSD) mogę edytować w trybie nxml (dowód w postaci zrzutu ekranu obok).

Zainstalowałem Emacsa w wersji 23 z plików rpm przygotowanych przez Brada Walkera (cf. rpm.bradmwalker.com/). Wygląda na to, że rpm miał być przygotowany w taki sposób, żeby dodawał nową wersję emacsa do systemu bez usuwania starej (poprzez polecenie alternatives). Ale coś nie wyszło: u mnie usunął starego, a nowy został zainstalowany w katalogu /usr/bin pod nazwą: emacs-23.0.60. Ręcznie zatem dodałem:

/usr/sbin/alternatives --config emacs

Wpis dotyczący Emacs 23 już był--nie trzeba była uruchamiać alternatives --install. Dodałem też wpis do /etc/X11/Xresources:

Emacs.font: Monospace-10

Można też to samo wpisać do ~/.Xresources, ale wtedy nie będzie system wide.

Emacs 22 działa z UTF-8 out-of-the-box. Miałem dziwny problem, cały bufor zmienił się w drobną kaszkę (co widać obok--musiałem go odtworzyć via Google btw). Podejrzewałem moją funkcję do wstawiania niełamliwej spacji.

(defun insert-nbspace()
  "Insert character 160, no-break space "
  (interactive) 
  (insert " ") )

Okazało się jednak, że ww. funkcja nie powoduje problemów a teraz nawet nie mogę odtworzyć błędu, który wtedy wystąpił. Tak czy owak, pliki UTF-8 są otwierane jako UTF-8, a te kodowane jednobajtowo jako ISO-8859-2. W Gnus 5.11 też to wszystko działa, do tego smilies sa w full kolorze. Rewelacja. Tim Bray (ten od XML) też używa Emacsa.

Do pisania skryptów w Perlu używam trybu cperl. Aby cperl był domyślnym trybem (zamiast perl-mode) trzeba wpisać do .emacs:

(defalias 'perl-mode 'cperl-mode)

Tryb cperl ma użyteczną funkcję: cperl-info-on-command (C-c C-h F). Wystarczy ustawić kursor na nazwie funkcji/polecenia nacisnąć C-c C-h F aby została wyświetlona pomoc z podręcznika Perla. Konkretnie jest wyświetlana strona w formacie .info. Dokumentację do Perla w tym formacie musiałem ściągnąć samodzielnie i umieścić w katalogu, w którym system oczekuje plików .info (u mnie jest to /usr/local/share/info/). Podręcznik jest dostępny pod adresem:

CPAN/doc/manual/info/perl5-old/perl5-info.tar.gz

Tyle, że stary (wersja 5.6 Perla). Ewentualnie można samemu wygenerować strony nowego podręcznika w formacie .info za pomocą pod2texi. Są one dostępne pod adresem:

CPAN/doc/manual/info/perl5/pod2texi-0.1.tar.gz

Tryb cperl zwolnił dramatycznie w Emacsie 22 zainstalowanym na laptopie. Po wpisaniu w google emacs+22+cperl+slow dotarłem do dyskusji na ten temat. Podmiana oryginalnego cperl.el z dystrybucji Emacsa na wersję ściągniętą z tej strony pomogła. W PC poprawnie działa oryginaly cperl, problem jest zatem z gatunku magicznych.

Magicznie też zmienił mi się program do sprawdzania pisowni. Ponieważ aspell był wolny i nic nie wnosił za pomocą niewielkiego haka używałem dalej ispella. W Emacs 22 znowu zaczął być używany aspell. Dopisałem zatem do .emacs:

(setq-default ispell-program-name "ispell")

Ale to już chyba ostatni raz. Wprawdzie aspell dalej jest wolniejszy, ale już można z nim normalnie pracować. Przy następnej zamianie systemu już mi się nie będzie chciało kompilować ispella.

Emacs 22 nie współpracuje z pakietem session.el, który służy do zapisania do pliku na potrzeby następnej sesji iluś tam ostatnio wykonanych poleceń, otwartych plików itp. Ćwicząc Emacs 23 już to przerabiałem i na taką okoliczność wstawiłem do plików startowych tryb desktop-save:

(if (< emacs-major-version 22)
(progn
  (require 'session)
  (add-hook 'after-init-hook 'session-initialize))
(progn
  (desktop-save-mode 1)
  (setq history-length 250)
  (add-to-list 'desktop-globals-to-save 'file-name-history)))

O tych wszystkich nastawach zdążyłem już zapomnieć. A że Emacs na starcie czyta kilkanaście plików to nie od razu doszedłem czemu wraz z przejściem na Emacsa 22 przestał działać session.el a włączyło się coś innego. (Ten blog jest w dużej części po to, aby takich sytuacji uniknąć w przyszłości:-)

Tryb desktop-save nie podoba mi się: przy starcie Emacsa ładuje się kilkadziesiąt plików, większość z nich zupełnie niepotrzebnie. Najgorzej wygląda sprawa z plikami edytowanymi poprzez trampa. Emacs łączy się z odległą maszyną. Nie wiem czemu robi to kilkakrotnie. Wszystko to trwa oczywiście a próba okiełznania desktop-save nie dała zadowalającego rezultatu. W dokumentacji jest zresztą niewiele na ten temat. Spróbowałem przykładowo ustawić zmienną desktop-restore-eager, ale to niewiele pomogło. Faktycznie Emacs szybciej startował, ale jak tylko chwilę nie dotykałem klawiatury zaczął otwierać resztę buforów. Nie szło tego przerwać... Jednym słowem mulił, tylko że nie na początku.

W ,,sprawie trampa'' wyczytałem w odpowiedzi na żale jakiegoś użytkownika żeby dać sobie z nim spokój i działać na maszynie odległej przez fuse-sshfs. Czy ja wiem? Jak przed uruchomieniem nie zamontuję odległego katalogu, to co zrobi desktop-save? To chyba nie jest dobre rozwiązanie.

Ostatecznie przełączyłem się na standardowy tryb savehist. Działa z grubsza jak session.el. Czemu ja w ogóle zacząłem używać tego ostatniego--nie pamiętam. Tryb desktop-save wyłączyłem.

W temacie AWK też pojawił się problemik. Dawno, dawno temu (ca 1994 mówiąc konkretnie) zrobiłem skrypcik do podliczania moich rocznych finansów. Działał. Aż w tym roku przestał (a może przestał wcześniej, tylko nie zwróciłem na to uwagi). Zaczęło się od komunikatu division by zero.

Miałem od dawna świadomość, że jakiś mądry tak przerobił gawka, iż przy ustawieniu lokali na PL traktuje on jako kropkę dziesiętną przecinek a nie kropkę. Po co to zrobiono--nie wiem. Wydaje mi się, że zrobiono bez sensu. Ponieważ mój skrypt był uruchamiany via skrypt basha, wystarczyło dopisać LANG=C:

#!/bin/bash
LANG=C exec gawk -f $AWKDIR/foo.awk $*

I działa znowu.

Dopisane 19 marca 2008: fuse_sshfs jest jednak świetnym rozwiązaniem. Ostatecznie nie pracuję na dziesiątkach maszyn, tylko na dwóch. W razie potrzeby montuję odległy katalog i już. Super wygodnie, nie tylko w połączeniu z Emacsem. Pakietu tramp już nie używam.

Funkcja browse-url wyświetla w przeglądarce WWW stronę o podanym adresie URL. Takie tam drobne ułatwienie: nie trzeba wklejać adresu do przeglądarki; wystarczy ustawić ,,na nim'' kursor i wywołać funkcję za pomocą M-x lub uprzednio zdefiniowaną kombinacją klawiszy. Wtedy Emacs uruchomi przeglądarkę, a ta z kolei wyświeli żądaną stronę.

Domyślną przeglądarką jest Mozilla; u mnie np. jest to Mozilla 1.7.12. Wraz z przejściem na wersję 22 Emacsa wróciłem do sprawy skonfigurowania Emacsa z Firefoksem i spróbowałem nastaw podanych na emacswiki.org:

(setq browse-url-browser-function 'browse-url-firefox
   browse-url-new-window-flag  t
   browse-url-firefox-new-window-is-tab t)
(global-set-key (kbd "C-c C-L") 'browse-url) 

Działa ale wyświetla każdą kolejną stronę w nowej karcie Firefoxa podczas gdy Mozilla pokazuje nową stronę w starym oknie. Wolę sposób działania Mozilli, więc pozostanę przy domyślnych ustawieniach.

W uczuciach jestem stały, nie lubię zmian i związanego z nimi zamieszania i ryzyka. Ale wreszcie po latach pożegnałem Telekomunikację Polską na rzecz firmy UPC. Bo UPC jest tańsze. Prawdę powiedziawszy to wcale nie będę płacił o wiele mniej -- ponieważ wybrałem dość szybkie łącze -- ale gdybym takie coś zamówił w TP to by wyszło znacząco drożej. W związku ze zmianą trzeba było kupić nowy modem, którego konfiguracja była jeszcze prostsza od tego poprzedniego, używanego z Neostradą.

Internet z UPC działa sprawnie za to firma denerwuje mnie swoją absolutnie fatalną stroną WWW. Sprawa o tyle mnie dotyczy, że w ramach umowy mam opłacać faktury via ww. stronę. Z mojego zatem punktu widzenia jej funkcjonalność sprowadza się wyłącznie do możliwości pobrania plików PDF z formularzem faktury. Wydawać by się mogło, że nie można spartaczyć tak prostego zadania. A jednak w globalnej korporacji wszystko jest możliwe: jakiś ,,myśliwy'' wymyślił, że strona będzie wykorzystywała flasha. Po co? Nie wiadomo. Za to nie działa w moim L-systemie. Być może w jakimś bardziej up-to-date by działało ale nie będę sprawdzał. Anyway sprawa jest kuriozalna...

Jest coś śmiesznego w zaufaniu tzw. przeciętnego człowieka do tzw. wielkich firm... Wracając zaś do tematu, w UPC mam mieć ten sam numer co w TP. Zobaczymy co z tego wyjdzie, bo mam niejasne przeczucie, że z tym też będzie problem.

Kontynuując temat migracji: założyłem konto looseheadprop1 na gmail i teraz jest to moja główna skrzynka. Włączyłem IMAP. Na tym etapie doszło zresztą do pewnego nieporozumienia, bo na relewantnych stronach google nie jest napisane wprost, że IMAP jest dostępny wyłącznie dla kont w języku angielskim. Innymi słowy, aby włączyć IMAP trzeba zmienić Gmail display language na English US inaczej można czekać na włączenie się IMAP ad mortem defecatus. No cóż, widocznie ten co pisał ww. stronę założył, że jak dokument jest w j. angielskim to tylko Anglosasi go przeczytają. Taka sobie logika... Problem zresztą być może już nie istnieje, albo zniknie wkrótce.

W związku z powyższym zacząłem korzystać z Thunderbirda (poprzednio używałem pine), który skonfigurowałem według wskazówek ze strony google i wszystko działa doskonale. Doinstalowałem kilka wtyczek: Attachment Extractor, Display Mail User Agent, Enigmail, Quick Locale Switcher oraz Virtual Identity. Na razie tylko korzystam z Display Mail User Agent:-). Więc jeżeli ktoś nie chce wyjść w moich oczach na buraka używającego Outlooka, to przynajmniej niech usunie z nagłówka wiersz X-Mailer (do was m.in. piję w tej chwili kol. BL:-). Wtyczka Quick Locale Switcher przyda się jak będę większego coś w języku wysyłał. Trochę mi się nie podoba sposób jej działania, ale podobna wtyczka Dictionary Switcher nie działa wcale -- i to nie tylko u mnie -- co widać po komentarzach na ww. stronie.

Tak się rozochociłem tą zmianą, że -- idąc za ciosem -- skonfigurowałem też gnusa jako alternatywę do czytania poczty. Nie wchodząc w szczegóły po co mi to, uruchomienie gnus wymagało zainstalowania Emacsa w wersji 22, bo zarówno sam pterodactyl jak i niezbędne do współdziałania z gmailem biblioteki są w wersji 21 raczej dated. W FC5 nie ma -- z tego co mi się wydaje -- wersji 22 Emacsa zatem przygotowałem pliki rpm z archiwum źródłowego. Na marginesie: w swoim czasie skompilowałem i uruchomiłem Emacsa 23, ale... Ale to jest wersja alfa. Niby działa tyle, że co pewien czas następuje crash, zatem do pracy raczej kłopotliwe narzędzie. Od dziś zamiast wersji 21 będę miał 22. Wersja 23 zaś będzie służyła promocji Emacsa w tym, a zwłaszcza, powalaniu niewtajemniczonych na kolana:-)

Zawartość plików ~/.gnus.el oraz ~/.imap-authinfo skopiowałem z bloga Aleksieja Simakowa. Ale to było za mało żeby działało. Poza tym chciałem skonfigurować gnusa do czytania grup nowości, czegu u Simakowa nie ma. Dodałem zatem:

(setq gnus-select-method '(nntp "news.task.gda.pl" ))

A do konfiguracji konta pocztowego wykorzystuję zmienną gnus-secondary-select-methods:

(setq gnus-secondary-select-methods '((nnimap "imap.gmail.com"
     (nnimap-address "imap.gmail.com")
     (nnimap-server-port 993)
     (nnimap-authinfo-file "~/.imap-authinfo")
     (nnimap-stream ssl))))

Ponieważ gnus, z niewiadomych powodów, wstawiał błędne nagłówki, ustawiające kodowanie na us-ascii, dodałem wpisy:

(setq message-default-charset 'iso-8859-2)
(setq gnus-default-charset (quote iso-8859-2)) 
(setq gnus-default-posting-charset (quote iso-8859-2))

Prawie OK. Tzn. w buforze *Groups* widać grupy nowości, mogę je przeglądać i wysyłać wiadomości. Niestety nie widać nigdzie folderów z gmaila. Zaś bufor *Messages* nie zawiera informacji o jakichkolwiek błędach--wygląda, że się z gmailem łączy i wszystko jest OK. Zatem guglamy dalej. No i jest odpowiedź: magiczny klawisz ^, po naciśnięciu którego faktycznie pokazują się foldery i można czytać listy. Niestety, nie można wysyłać -- wyświetlany jest błąd: Sending failed; SMTP protocol error. Znowu google. I jest wskazówka: potrzebne jest zainstalowanie: gnutls-cli. Myślałem, że już to mam, bo locate gnutls coś tam wyświetlało... Zatem:

yum install -y gnutls-utils

I wreszcie (prawie) wszystko działa.

Na koniec wrócę do Emacs jako takiego. Problemy z migracją do wersji 22 są na razie drobne i łatwe do usunięcia. Nie działa ess. Na razie wstawiłem po prostu ; przed (require 'ess-site). Nie działa zapis /ssh::~/public_html (dotyczy biblioteki tramp), należy wpisać w pełnym brzmieniu /ssh:tomasz@gnu.univ.gda.pl:~/public_html. Funkcja My-flickr-images-init z mojej biblioteki do ładowania zdjęć na flickr.com wyświetliła wspaniałe okno dialogowe a la MS Windows zamiast skromnie wyświetlić pytanie w minibuforze. Nie tylko wybranie katalogu trwa kilka razy dłużej, ale na dodatek szukane są tylko istniejące pliki. To ostatnie to akurat zapewne mój błąd: parametrem interactive było "fdir: ", a powinno być:

(interactive "Fdir: ")

Tyle, że oba ustawienia działają w ,,trybie minibufora''. Na szczęście nawet deweloperzy Emacsa mieli widocznie wątpliwości co do tego czy w tym wypadku nowe jest lepsze, bo już w ww. oknie dialogowym jest podpowiedź jak wrócić do starych sprawdzonych rozwiązań:

(setq use-file-dialog nil)

Kolejny drobny problem, to nieznana funkcja compile-internal. Faktycznie w dokumentacji jest oznaczona jako obsolete ze wskazaniem compilation-start jako zamiennika. Także i w tym przypadku modyfikacja też była bardzo prosta.

Reasumując: po raz kolejny się okazało, że wszystko poszło w miarę sprawnie. No ale ja z natury jestem panikarz.

Zrezygnowałem wreszcie z używania do komunikacji z GPSem programu GPSman na rzecz GPSBabela. Ten pierwszy jest programem interaktywnym a przez to niezbyt wygodnym bo trzeba się trochę naklikać żeby przegrać zawartość pamięci Geko na PC. GPSBabel działa w trybie wsadowym, dzięki czemu można oszczędzić dużo (cennego) czasu:

#!/bin/bash
TODAY=`date +"%Y%m%d"` # zapisz do pliku yyyymmdd.gpx
gpsbabel -t -r -w -i garmin -f /dev/ttyS0 -o gpx -F "$TODAY.gpx" 

Przyznać muszę, że podchodziłem do tego GPSBabela jak do jeża bo przy poprzednich próbach coś mi tam nie działało. A niesłusznie -- wystarczyło przeczytać dokumentację.

Najwięcej czasu straciłem zresztą na podłączeniu Garmina do komputera. Mój Geko 301 jest podpięty do PC standardowym ,,fabrycznym'' kablem pn. RS232 serial port connector (part number: 010-10310-00). Port szeregowy, tj. /dev/ttyS0 w nomenklaturze Linuksa, w FC5 jest dostępny tylko dla superużytkownika. BTW mam poczucie, że wcześniej był dostępny dla wszystkich. Kłopot ten rozwiązałem w sposób przedstawiony tutaj:

ls -l /dev/ttyS0
crw-rw---- 1 root uucp 4, 64 gru 18  2007 /dev/ttyS0
/usr/sbin/usermod -G uucp tomek # dodanie tomka do grupy uucp

Uwaga: program usermod działa tak, że jeżeli użytkownik jest obecnie członkiem grupy, której nie podano na liście--wartości opcji -G, to zostanie z niej usunięty. Lepiej więc zwyczajnie uruchomić vi i dopisać co trzeba do /etc/groups.

Mając już zgrany ślad (track) i punkty (waypoints) zacząłem kombinować co dalej z tym robić. Sposób w jaki publikuję moje ślady korzysta z biblioteki gpx-viewer Kaza Okudy. Każdy punkt z pliku GPX jest przedstawiony w postaci standardowej ,,pinezki'' znanej z google maps. Pinezka po kliknięciu zamienia się w okienko zawierające zawartość elementów-dzieci elementu wpt (tj. ele, name, cmt, desc oraz sym) oraz atrybuty tego elementu (lat i lon), np.:

<wpt lat="54.443087485" lon="18.540491704">
  <ele>69.340332</ele>
  <name>168</name>
  <cmt>168</cmt>
  <desc>168</desc>
  <sym>Flag</sym>
</wpt>

Gdyby ww. element zawierał element extension, to pokazana by była tylko zawartość extension. W przykładach ze strony Okudy extension zawiera element img zawierający z kolei zdjęcie zrobione w tym właśnie miejscu:

<wpt lat="49.237919" lon="-122.760106">
  <ele>4.0</ele>
  <name>Photo 2</name>
  <extensions><html><![CDATA[
       <a href="http://okuda.blogspot.com/2005/07/traboulay-poco-trail.html" target="_blank">
         <img src="blog/2005-07/IMG_2370-01.jpg" />
       </a>
    ]]></html></extensions>

Teraz mała dygresja: odsyłacze do zdjęć na flickr.com są tworzone według pewnego schematu. Strona główna zdjęcia ma adres http://www.flickr.com/tprzechlewski/<photo_id>/, gdzie <photo_id> oznacza identyfikator zdjęcia. Plik ze zdjęciem ma zaś następujący URL:

http://static.flickr.com/<server>/<photo_id>_<secret>_<size>.jpg

Wartości <server> oraz <secret> można ustalić np. poprzez wykonanie metody flickr.people.getPublicPhotos. Wartościami size są s (square), t (thumbnail), m (small), b (large), o (original). Oznaczają one odpowiednio pliki o wielkościach 75, 100, 200, 1024 pikseli i wielkość oryginalną. Rysunek typu square to kwadrat, pozostałe to prostokąty o dłuższym boku równym podanej licznie pikseli. Prostokąt o dłuższym boku równym 500 pikseli to wielkość zdjęcia, która jest wyświetlana na stronie głównej zdjęcia. Ta wielkość jest wybierana jeżeli URL nie zawiera części _<size>.

Ja chciałem żeby element img wewnątrz extension w pliku GPX wskazywał na zdjęcie w rozmiarze thumbnail na flickr.com a element a odsyłał na stronę główną tego zdjęcia. Żeby nie wpisywać kodu ręcznie wymyśliłem to następująco.

Za pomocą skryptu flickr_getphotolist.pl pobieram informacje nt. wszystkich zdjęć (publicznych, ale to ograniczenie akurat jest OK). Skrypt zapisuje informacje w postaci następującej listy haszy:

@photos = (
{'owner' => '20425995@N00','isfriend' => '0','ispublic' => '1','secret' => '95826dcd42',\
 'farm' => '3','title' => 'dscf1209','server' => '2343','id' => '1747402167','isfamily' => '0'},
...

do pliku ~/.flickr/hr.icio.ph. Prosty skrypt zwraca kompletne adresy URL po podaniu tytułu zdjęcia (działa przy założeniu, że tytuły są unikatowe):

#!/usr/bin/perl
require "$ENV{HOME}/.flickr/hr.icio.ph" ;
$photo_title = shift;
for (@photos) { if ($photo_title eq $_->{title} ) {
print "<extensions><html><![CDATA[
       <a href=\"http://www.flickr.com/tprzechlewski/$_->{id}/\" target=\"_blank\">
         <img src=\"http://static.flickr.com/$_->{server}/$_->{id}_$_->{secret}_t.jpg\" />
       </a> ]]></html></extensions> \n";
  }
}

Teraz wystarczy dopisać w .emacs funkcję, która w miejscu wywołania albo zapyta o tytuł zdjęcia, albo pobierze go sama z wiersza gdzie jest kursor po czym wstawi to co wypluje ww. skrypt do Emacsowego bufora. Genialne:-) Na próbę dodałem zdjęcia do śladu wygenerowanego 16. 12. 2007 r.

BTW patrząc na ten dziwny ślad nie mogę się powstrzymać od sarkazmu, mając w pamięci opinię niejakiej squishy z forum flickr.com: ... it's smaller than many cell phones and I think it's fabulous. I just turn it on and toss it in a backpack, then download the track log later to sync with photos... Gdzie ona mieszka? Na pustyni Gobi? Albo pracuje w Garminie... Albo to sync with photos jest plus/minus 10 kilometers. Bo mój geko 301 prawie zawsze zgubi ślad w trudnym terenie typu las, duże budynki, głębokie doliny itp...

Znacząco poprawiłem swój tryb do dodawania zdjęć na flikr.com. Teraz wszystko się dzieje wewnątrz Emacsa łącznie z uruchomieniem wysyłania plików na serwer. W starej wersji pliki konfiguracyjne czytał Emacsowy moduł xml.el co było może i eleganckie ale odbywało się przeraźliwie wolno. W nowej wersji plik konfiguracyjny jest plikiem lispowym wygenerowanym skryptem Perla z plików XML. Jak to działa opisałem na oddzielnej stronie. Jedna sprawa jest tajemnicza:

#!/usr/bin/perl -w
require 'login2flickr.rc';
require 'flickr_utils.rc';

my @tmpx = get_sets_ids();
my @tmpy = get_pools_ids();

W plikach login2flickr.rc oraz flickr_utils.rc są zdefiniowane procedury, który czytają plik z dysku i zwracają zmienne. W szczególności flickr_utils.rc zawiera dwie prawie identyczne procedury (get_sets_ids oraz get_pools_ids), czytające różne pliki konfiguracyjne. Kurcze... na jednym komputerze perl zwraca błąd: Undefined subroutine &main::get_pools_ids called at... a na drugim działa. Ten sam perl, ta sama wersja FC5, jedna procedura z pliku dołączanego poleceniem require jest zdefiniowana druga nie... Wystarczy zmienić kolejność poleceń require żeby powyższe działało w obu systemach. Nic mi do głowy nie przychodzi...

Domyślne ustawienia w moim Emacsie zmieniają właściciela pliku podczas zapisu (konkretnie grupę). Przykładowo Elka edytuje plik, który należy do grupy family, a jak go zapisze, to plik już nie należy do family tylko do grupy elka. W dokumentacji Emacsa nie mogłem odszukać co trzeba ustawić, ale znalazłem tutaj:

(setq backup-by-copying-when-mismatch t)

Przy okazji pisania o ustawianiu Emacsa wspomnę także o tym jak nakazać tworzenie kopii w katalogu ~/.emacs-backups/, co zapobiega zaśmiecaniu dysku plikami ,,z tyldą'':

;; polecam szczególnie użytkownikom pakietu tramp
(defun make-backup-file-name (file)
  (concat "~/.emacs-backups/" 
    (file-name-nondirectory file) "~")) 

Powyższe nastawy należy oczywiście umieścić w pliku ~/.emacs.

R to środowisko do obliczeń statystycznych i wchodzi w skład każdej praktycznie dystrybucji Linuksa. Zainstalować można go bez problemu używając yuma, jeżeli już wcześnie nie został zainstalowany domyślnie. Dokumentację w formacie html odnaleźć można w katalogu /usr/lib/R/html/.

Emacs ma wsparcie do R w postaci pakietu ESS. Instalowanie ESS jest proste: należy rozpakować i dodać do plików startowych Emacsa następujące dwa wiersze (katalog ~/.emacs-local/ess/lisp oczywiście należy dopasować do własnych ustawień):

(add-to-list 'load-path "~/.emacs-local/ess/lisp")
(require 'ess-site)

Uruchamianie ESS jest jakby nieco mniej oczywiste; być może nawet to co opisałem poniżej jest nieoptymalne. Startuję R z wnętrza Emacsa za pomocą M-x R Enter. Zostanie wyświetlone w minibuforze pytanie o katalog roboczy, np.:

ESS [S(R): R] starting data directory ...

Należy wybrać odpowiedni katalog. Po pewnej chwili Emacs przejdzie do bufora *R*, który umożliwia interaktywną pracę z R. W buforze *R* można działać w środowisku R z wnętrza Emacsa dzięki czemu pracuje się wygodniej: działa dopełnienie (Tab) oraz help (C-c C-v). Tyle, że w buforze *R* polecenia R i wyniki obliczeń są przemieszane i szybko można się pogubić. Lepiej pisać program (skrypt) R w osobnym buforze a wyniki oglądać w buforze *R* (ogólnie *R:numer-procesu*, jeżeli działamy z więcej niż jednym skryptem, tj. dla drugiego skryptu zostanie utworzony bufor *R:2*, dla trzeciego *R:3*, itd.). Aby to osiągnąć należy otworzyć (nowy) plik za pomocą standardowego polecenia C-x C-f. Plik powinien mieć rozszerzenie .r. Bufor przejdzie do trybu ESS co zostanie zasygnalizowane pojawieniem się napisu ESS w wierszu trybu (modeline).

W tym buforze także działa pomoc (C-c C-v) i dopełnianie (C-c C-Tab). Pojedynczy wiersz ze skryptu R można uruchamiać za pomocą ess-eval-line (C-c C-j; uwaga: polecenia podzielone na wiersze wymagają naciśnięcia C-c C-j dla każdego wiersza); cały blok poleceń zaś za pomocą ess-eval-region (C-c C-r). Drobna niedogodność to przechodzenie pomiędzy różnymi oknami: tematów pomocy, R oraz bufora ze skryptem R (ESS otwiera/zamyka okna mało ,,intuicyjnie''). Ponieważ skrypty R są krótkie dobrym pomysłem jest podział ekranu na pół (C-x 2) i wyświetlanie w drugim oknie bufora *R*.

Prosty przykład wykorzystania R do określenia związku między poziomem korupcji a sposobem głosowania w sprawie zaakceptowania przez ISO specyfikacji OOXML można znaleźć w Corrupt countries were more likely to support the OOXML document format (Kai Puolamäki). Rysunek obok pokazuje wykonanie skryptu R z ,,wnętrza'' Emacsa (jak widać nawet okno zawierające histogram też się ładnie wyświetliło).

W nawiązaniu do tekstu nt. Emacsa, kol. Wanted podpowiedział, że oprócz Bitstream Vera, który faktycznie nie ma za dużo diakrytyków, jest klon tego fontu z dużą liczbą znaków pn. DejaVu (DejaVu fonts). Spróbowałem to zainstalować wpisując yum install dejavu-fonts, ale się nie udało:

Error: dejavu-fonts conflicts with fontconfig >= 2.3.0

Hmm, dziwne. Żeby czegoś nie popsuć wolałem działać ostrożnie. Rozpakowałem archiwum .rpm:

rpm2cpio dejavu-fonts-2.18-1.rf.noarch.rpm | cpio -idv

W środku nie było nic nazwyczajnego. Pliki ttf + dokumentacja. Pliki .ttf umieściłem ręcznie w /usr/share/fonts/dejavu/. Na wszelki wypadek uruchomiłem w tym katalogu mkfontdir i mkfontscale. Uruchomiłem Emacsa w następujący sposób:

/usr/local/emacs23/bin/emacs-23.0.0 --font "DejaVuSansMono-14" --multibyte

Wygląda, że działa. Przy okazji i zupełnie przypadkowo wygooglałem informację nt. projektu fontów STIX. Z tego co wyczytałem ma to być podobna do Times New Roman rodzina bogatych w diakrytyki fontów. Na dniach mają być gotowe i upublicznione. Zobaczymy, być może będzie to coś ciekawego.

Kierując się wskazówkami ze strony www.emacswiki.org skompilowałem Emacsa 23, wersja alfa. Ten Emacs umie wreszcie korzystać z dobrej jakości fontów TrueType dzięki wsparciu Xft. Zatem:

cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co -r emacs-unicode-2 emacs
./configure --with-gtk --enable-font-backend --with-xft --prefix=/usr/local/emacs23
make
mkdir /usr/local/emacs23 
chown tomek:tomek /usr/local/emacs23

Na wszelki wypadek dociągnąłem jeszcze yum install giflib-devel, bo ./configure zgłosił błąd (po co mi gify?). Oczywiście nie chcę zmieniać starego emacsa na wersję alfa, stąd pomysł zainstalowania wszystkiego w katalogu /usr/local/emacs23. Będę miał dwa The one true editor -- prawdziwie skumulowana potęga.

Teraz uruchamiam:

emacs --font "Bitstream Vera Sans Mono-10"

Krój Vera fajnie wygląda, ale polskich ogonków nie ma, i nawet nie jest to wina Emacsa tylko po prostu nie ma ich w foncie (Bitstream Vera Fonts).

Spróbowałem zatem z innym ustawieniem, i po dłuższym kombinowaniu czemu zamiast polskich znaków widzę coś zupełnie innego udało się:

## emacs-23 zdaje sie działać:
/usr/local/emacs23/bin/emacs-23.0.0 --font "Monospace-13" --multibyte

Na etapie rozruchu dodałem jeszcze --debug-init, dzięki czemu szybko ustaliłem co się gryzie ze starego .emacs i innych plików startowych z nowym Emacsem. Nie było tego dużo: hscroll-global-mode, pakiety session, tramp i jde. Zamiast session w dystrybucji Emacsa jest desktop.el; tramp.el też jest już w dystrybucji -- konflikt dotyczył starej wersji. Dodałem zatem kilka warunków w stylu:

(if (< emacs-major-version 22)
(progn (require 'session)
  (add-hook 'after-init-hook 'session-initialize))
(progn (desktop-save-mode 1)
  ;; Customization follows below
  (setq history-length 250)
  (add-to-list 'desktop-globals-to-save 'file-name-history)) )

Emacs faktycznie używa fontu TrueType. Można to sprawdzić, np. za pomocą sposobu podanego w CSE HUJI Emacs Fonts HOWTO:

(frame-parameter nil 'font)

Wpisujemy powyższe do dowolnego bufora, ustawiamy kursor za zamykającym nawiasem a następnie C-x C-e. W minibuforze pojawi się:

"-b&h-luxi mono-medium-r-normal--15-*-*-*-*-*-fontset-startup"

Wygląda zatem, że to luxi mono Charlesa Bigelowa i Krisa Holmesa.

Jakość (czytelność) tekstu jest faktycznie znacząco lepsza, ale z wyświetlaniem poszczególnych znaków (na pierwszy rzut oka) jest różnie: niektóre znaczki jakby trochę są krzywe:-). Może to kwestia fontu? Sprawa wymaga dalszego zbadania. Poniżej dwa przykładowe ekrany (jak się kliknie to będą większe):