Warning: this is an htmlized version!
The original is across this link,
and the conversion rules are here.
#######
#
# E-scripts com vários textos em português (documentação escrita
# para a CIPSGA).
#
# Note 1: use the eev command (defined in eev.el) and the
# ee alias (in my .zshrc) to execute parts of this file.
# Executing this file as a whole makes no sense.
#
# Note 2: be VERY careful and make sure you understand what
# you're doing.
#
# Note 3: If you use a shell other than zsh things like |&
# and the for loops may not work.
#
# Note 4: I always run as root.
#
# Note 5: some parts are too old and don't work anymore. Some
# never worked.
#
# Note 6: the definitions for the find-xxxfile commands are on my
# .emacs.
#
# Note 7: if you see a strange command check my .zshrc -- it may
# be defined there as a function or an alias.
#
# Note 8: the sections without dates are always older than the
# sections with dates.
#
# This file is at <http://angg.twu.net/e/cipsga.e>
#           or at <http://angg.twu.net/e/cispga.e.html>.
#        See also <http://angg.twu.net/emacs.html>,
#                 <http://angg.twu.net/.emacs[.html]>,
#                 <http://angg.twu.net/.zshrc[.html]>,
#                 <http://angg.twu.net/escripts.html>,
#             and <http://angg.twu.net/>.
#
#######



Índice geral dos textos
-----------------------

 Um outro manifesto do eev (versão de junho de 2001, em andamento)
# «.eevm»	(to "eevm")
# «.eevm1»	(to "eevm1")



 Emacs e eev.el, ou: como automatizar quase tudo
 (um tutorial sobre Emacs com uma diferença importante:
 esse é escrito do ponto de vista certo! :)
# «.emacs_e_eev»	(to "emacs_e_eev")

# «.lisp_hiperlinks»	(to "lisp_hiperlinks")
# «.code-c-d»		(to "code-c-d")
# «.eev»		(to "eev")
# «.blocos_delimitados»	(to "blocos_delimitados")
# «.eeg»		(to "eeg")

# «.ancoras»		(to "ancoras")
# «.mkto_dff_inn»	(to "mkto_dff_inn")
# «.variaveis»		(to "variaveis")
# «.glyphs»		(to "glyphs")
# «.demos_eeg2»		(to "demos_eeg2")






# «eevm»  (to ".eevm")


  Um outro manifesto do eev (versão de junho de 2001, em andamento)
  =================================================================

0)

Quando eu era garoto e comecei a brincar com computadores, no início
da década de 80, a gente tinha que aprender tudo sozinho, pelos
manuais em inglês -- aliás, eu comecei a aprender inglês técnico
exatamente tentando ler os manuais, passei pra inglês de verdade
quando comecei a jogar Zork, vários anos depois; mas isso é outra
história. Bom, voltando: eu era fascinado por computadores, e eles
eram vendidos como máquinas que podiam ser programadas pra fazer tudo
que fosse programável; e era evidente que algumas pessoas sabiam
usá-los desse modo, já que existiam programas grandes fantásticos,
como por exemplo os jogos de fliperama e de Atari (quem pegou essa
época provavelmente sabe do que eu estou falando: comparando com os
jogos de hoje os jogos de Atari e de flipper correspondem a
experiências psicodélicas, enquanto os de hoje correspondem a TVs de
24 polegadas) -- e depois de pensar o suficiente sobre como os jogos
eram feitos eu comecei a perceber como linguagens de programação eram
coisas maravilhosas também, já que a linguagem perfeita permitiria que
a gente programasse um jogo em tempo recorde e exatamente como a gente
o tinha imaginado, sem precisar fazer muitas concessões por causa de
detalhes técnicos... pois bem, então eu era fascinado por jogos e por
linguagens como ferramentas pra fazer jogos, e jogos de computador
eram mais poderosos do que filmes, músicas e livros: uma pessoa sem
preparo e sem sensibilidade não entende uma obra de arte, mas na minha
cabeça de melão TODO MUNDO entendia um jogo de computador. Acho que eu
não preciso explicar mais nada, né? Se eu conseguisse programar os
jogos de computador que apareciam nos meus sonhos todos os meus
problemas estariam resolvidos.

Mas o tempo foi passando e apesar dos meus esforços eu nunca conseguia
programar nada que prestasse; eu me perdia se tentava fazer programas
com mais de 30 linhas, por exemplo. Era óbvio que as pessoas que
faziam os jogos e as linguagens de programação estavam usando truques
e modos de pensar que eu não conhecia, e eu não estava conseguindo
aprender essas coisas só pelos livros e por mexer nos programas a que
eu tinha acesso... e quando eu lia as revistas "cabeça" daquela época,
como Byte e Dr. Dobb's, eu via que os autores dos artigos vinham de
meios que fervilhavam de idéias e onde parecia não haver uma distância
muito grande entre ter uma idéia e implementá-la num programa...
droga, e eu nem tinha nenhum amigo que programasse, e o máximo que eu
consegui, depois de muitos anos, foi ficar amigo de um amigo do meu
pai o suficiente pra que eu pudesse telefonar pra ele de vez em quando
quando eu tinha dúvidas de C. Bom, eu pensava, quando eu entrar na
universidade eu vou cair num ambiente parecido com o dos caras da Byte
e da Dr. Dobb's... só que eu acabei indo fazer arquitetura, porque eu
vi que as pessoas de ciências exatas eram insuportáveis, e quando eu
desisti da arquitetura e mudei pra matemática (matemática não é uma
ciência exata; matemática é uma espécie de ioga sem a caretice e com
muito mais adrenalina) eu vi que não era nada daquilo: os
administradores dos laboratórios de computadores nos tratavam como se
nós (usuários) fôssemos hackers em potencial e nos davam o mínimo de
informações e de acesso às máquinas: em 94 ou 95 a gente tinha direito
de ocupar 300KB de espaço em disco e de usar uma máquina (rodando AIX,
eu acho, e com pouquíssimos programas instalados) uma hora por dia; o
acesso a manuais era pífio, estudantes de graduação não tinham direito
a tirar livros da biblioteca da Informática, e pra conseguir me
entrosar com os usuários que sabiam um pouco mais no laboratório eu
aparentemente precisaria me interessar pelas coisas que eles faziam,
que eram bater papo no IRC, falar besteira na sala ao mesmo tempo, e
depois ir tomar cerveja e falar mais besteira. Ou seja, eu estava
ferrado. Bom, chega. Isso é muito deprimente, não quero falar sobre
isso agora.

Em 95 eu depois de mil peripécias consegui comprar um PC-AT com 386 e
CD-ROM e um CD de Linux ("Yggdrasil Plug & Play Linux - Summer '94").
Vou pular a parte de como é que eu concluí que era pelo Linux que eu
devia começar e ir direto pro que aconteceu assim que eu já tinha ele
instalado.

# «eevm1»  (to ".eevm1")

1)

O Linux tinha uma interface de linha de comando parecida com a do DOS,
mas muitíssimo mais bem-feita e mais conveniente; a impressão geral
que dava era de que toda vez que alguém vinha com uma boa idéia para
um "feature" novo esse feature era adicionado. A manpage do shell -- o
shell é o programa que cuida dessa interface de linha de comando, e as
manpages são uma das formas de documentação de um programa num sistema
*NIX -- listava todos esses features, e eram tantos que não dava nem
pra saber por onde começar... ainda por cima havia vários shells
diferentes, o que indicava que várias vezes tinha acontecido de alguém
não gostar do design dos shells que já existiam e resolver fazer um
novo. E também não havia, pelo menos à primeira vista, nada que
indicasse que os shells tais e tais eram os mais importantes e os
outros eram secundários.

Por sorte muitos dos programas do Linux eram arquivinhos de texto com
indicações de que o sistema precisa invocar um determinado programa
para executá-los; se um arquivo desses (eles são chamados de
"scripts") começava com a linha "#!/bin/bash" deduzia-se que o resto
do seu texto seria interpretado pelo bash, que é um dos shells -- e
portanto a sintaxe desse script deveria ser bem parecida com a sintaxe
que a gente usa na linha de comando quando usa o bash como shell; não
exatamente igual, porque muitos comandos acabam só sendo usados quando
a gente usa o bash interativamente, batendo os comandos à mão, e
outros quase só são úteis pra escrever esses programinhas. Bom, mas já
era um começo: lendo esses scripts (que eram cheios de comentários,
aliás) dava pra aprender um monte de jeitos de usar os shells, 

# (find-node "(bash)Comments")







# «emacs_e_eev»  (to ".emacs_e_eev")


  Emacs e eev.el, ou: como automatizar quase tudo
  ===============================================

Parte 1: Emacs, Lisp e hiperlinks
---------------------------------

# «lisp_hiperlinks»  (to ".lisp_hiperlinks")

Em geral as pessoas acham que o Emacs é um editor de texto. Isso não é
bem verdade, e seria mais correto dizer que ele é um ambiente Lisp que
é usado na maior parte do tempo como editor de texto.

# (find-elnode "Command Loop")

Cada tecla que você aperta é interpretada pelo Emacs ou como um
comando inteiro ou como um prefixo para um comando mais longo, que
toma várias teclas; por exemplo, C-a (isto é, "control-a") geralmente
corresponde à função `beginning-of-line', que move o cursor para o
início da linha; C-x é um prefixo, e C-x C-e é um comando completo --
`eval-last-sexp', que executa a expressão em Lisp que está logo antes
do cursor. Um outro exemplo um pouco mais estranho é a tecla M-x
("meta-x"; na maior parte das configurações isso é o mesmo que
"alt-x"), que permite executar comandos pelo nome -- M-x
eval-last-sexp é o mesmo que C-x C-e.

# (find-enode "Keys")
# (find-enode "Moving Point" "`beginning-of-line'")
# (find-enode "User Input" "Meta")
# (find-enode "User Input" "<ALT> which is really a <META> key")
# (find-enode "M-x")
# (find-enode "Completion")
# (find-enode "Minibuffer")
# (find-enode "Key Help")

Digamos que você esteja editando a versão em texto deste artigo. Se
você puser o cursor logo depois do "(+ 1 2)" daqui de baixo e bater
C-x C-e você vai ver um "3" aparecer na última linha da tela (no
espaço chamado de "minibuffer"); o que aconteceu foi que você executou
a expressão em Lisp "(+ 1 2)", o que não teve nehuma conseqüência
muito interessante, e a expressão retornou o valor 3 -- a soma de 1 e
2.

    (+ 1 2)

# (find-elnode "Lists as Boxes")
# (find-elinode "Run a Program")
# (find-enode "Lisp Eval")
# (find-elnode "Functions for Key Lookup" "Function: key-binding")
# (key-binding "\C-x\C-e")

Se você executa uma das expressões abaixo (também com C-x C-e,
obviamente) o Emacs abre o arquivo /etc/inittab, no primeiro caso, e o
"arquivo" ~/ -- o seu home directory -- no segundo; como o ~/ é um
diretório e não um arquivo normal o Emacs vai mostrar o conteúdo do
diretório de uma forma que faça sentido e entrar no modo "Dired", em
que certas teclas vão ser interpretadas de modos especiais; por
exemplo o "q" sai do modo Dired, e o Enter abre o arquivo ou
subdiretório que está na linha em que o cursor está. Como a função
find-file está associada à seqüência de teclas C-x C-f, teria sido
equivalente bater C-x C-f /etc/inittab ou C-x C-f ~/.

    (find-file "/etc/inittab")
    (find-file "~/")

# (find-enode "Dired")
# (find-enode "Visiting" "`find-file'")

Se você tiver carregado no seu Emacs a biblioteca eev.el
(possivelmente seguindo as instruções de instalação que estão no
apêndice) então várias outras funções vão estar definidas, e passa a
ser bastante conveniente usar essas funções para fazer hiperlinks em
arquivos de texto; as funções find-enode, find-elnode e find-elinode,
que já apareceram acima sem grandes explicações, abrem páginas da
documentação em formato "info" do Emacs -- do próprio manual do Emacs,
do manual do Lisp do Emacs, e de um outro manual chamado "Introduction
to Emacs Lisp", respectivamente.

Se uma chamada a uma função dessas tiver um parâmetro extra além do
nome da página, ele é interpretado como um string que o Emacs tem que
procurar no texto; o cursor é posto logo depois da primeira ocorrência
desse string. Se você estiver lendo esta página em formato HTML isso
não vai funcionar: o seu browser vai abrir a página certa, mas não vai
localizar a posição indicada.

# (find-angg "eev.el" "find-")
# (find-angg ".emacs" "new_goto-position")

A função `find-fline', definida no eev.el, é uma versão do `find-file'
que aceita o parâmetro extra que diz por que string procurar; ela tem
esse nome porque quando eu comecei a escrever essas funções (lá pelos
idos de 1995) o parâmetro extra era sempre um número, que era
interpretado como um número de linha. Hoje em dia o parâmetro numérico
ainda é aceito, mas é bem mais conveniente usar strings, já que um
link para string em geral continua fazendo sentido quando o arquivo é
alterado.

# «code-c-d»  (to ".code-c-d")

O eev.el também define muitos outros tipos de hiperlinks: para
arquivos, para tags, para documentação em HTML, e para manpages; os
para manpages (e outros tipos mais estranhos) precisam dos truque da
próxima seção para serem utilizados. Além disso o eev.el também define
a função `code-c-d', que funciona como uma fabriquinha de funções de
hiperlink: uma simples chamada ao `code-c-d' como a abaixo

  (code-c-d "grub" "/usr/src/grub-0.5.95/" "grub")

vai definir `find-grubfile', `find-grubnode', `find-grubw3',
`find-grubtag' e algumas outras funções e variáveis para uso interno,
bem menos interessantes; pra quem sabe Lisp e quer os detalhes
técnicos, o que acontece quando rodamos o `code-c-d' acima é que o
Emacs gera e executa os comandos abaixo:

  (setq ee-grubdir "/usr/src/grub-0.5.95/")
  (setq ee-grubtagsfile "/usr/src/grub-0.5.95/TAGS")
  (defun ee-grubfile (str)
    (concat (substitute-in-file-name ee-grubdir) str))
  (defun ee-use-grub-tags ()
    (setq tags-file-name ee-grubtagsfile))
  (defun find-grubfile (str &rest pos-spec-list)
    (ee-use-grub-tags)
    (apply 'find-fline-nosubst (ee-grubfile str) pos-spec-list))
  (defun find-grubtag (str)
    (ee-use-grub-tags) (find-tag str))
  (defun find-grubw3 (furl &rest pos-spec-list)
    (apply 'find-w3 (ee-grubfile furl) pos-spec-list))
  (setq ee-temp-code "grub" ee-temp-infofile "grub")

  (defun find-grubnode (nodename &rest pos-spec-list)
    (find-node2 "grub" nodename pos-spec-list  "grub")))

O último `defun' não teria sido gerado se tivéssemos omitido o
último parâmetro do `code-c-d'.

# (find-angg "eev.el" "code-c-d")
# (find-elinode "defun")




Parte 2: Blocos de código no meio de um texto qualquer
------------------------------------------------------

# «eev»  (to ".eev")

Considere o bloco abaixo:

rm -Rv /tmp/c/
mkdir  /tmp/c/
cd     /tmp/c/
cat > demo.c <<'---'
#include <stdio.h>
main() {
  int sum, i;
  for(sum=0, i=0; i<10; ++i)
    sum += i;
  printf("Sum: %d\n", sum);
}
---
gcc -E demo.c > demo.E 
gcc -S demo.c
gcc -S demo.c -g -o demog.s
gcc -c demo.c
gcc -c demo.c -g -o demog.o
gcc    demo.c -o demo -v	2>&1 | tee ogv
gcc    demo.c -o demog -g -v	2>&1 | tee ogvg
diff ogv ogvg
./demo

que é uma série de comandos para o shell (bash ou zsh) que criam um
diretório "/tmp/c/" e um pequeno arquivo em C lá chamado "demo.c", e
depois chamam o gcc de vários modos para processar esse arquivo,
gerando vários formas intermediárias entre o ".c" e o executável, para
as quais nós geralmente não damos a menor bola...

Há vários modos de executar um bloco desses para ver na prática o que
ele faz. Poderíamos usar o mouse e pastar (:-) todas as linhas dele
para um shell, ou simplesmente batê-las à mão; poderíamos também
gravar o bloco para um arquivo, chamado digamos "/tmp/xxx", usando o o
comando `write-region' do Emacs, e depois executá-lo com "bash
/tmp/xxx" ou ". /tmp/xxx"...

# (find-enode "M-x")
# (find-enode "Misc File Ops")

O eev.el implementa dois modos muitos mais rápidos de executar um
bloco desses. O primeiro modo -- o segundo modo será descrito na
próxima seção -- é selecionar o bloco e bater `M-x eev'; isso grava o
bloco num determinado arquivo temporário (por default "~/tmp/ee.sh"),
e se você der o comando "ee" num shell (e se tudo tiver sido instalado
corretamente, veja o apêndice) então o shell vai executar o bloco em
"verbose mode" na shell corrente -- o que quer dizer principalmente
que cada comando é mostrado antes de ser executado e que os comandos
que mudam o estado da shell -- como "cd" e "set" -- funcionam como
esperaríamos: se batêssemos as cinco linhas abaixo

tac <<'---'
  first
  second
---
cd /tmp/

à mão num shell veríamos algo como:

/home/edrx(edrx)# tac <<'---'
>   first
>   second
> ---
  second
  first
/home/edrx(edrx)# cd /tmp/
/tmp(edrx)#

e com `M-x eev' e "ee" o que nós vemos é:

/home/edrx(edrx)# ee
tac <<'---'
  first
  second
---
  second
  first
cd /tmp/
/tmp(edrx)#

que é parecido o suficiente; para um modo de "enganar" perfeitamente a
shell e outros programas e obter exatamente o mesmo resultado que se
cada linha tivesse sido batida à mão veja a seção [eeg e Expect], mais
adiante.

Repare (ou lembre!) que linhas começadas com "#" são tratadas pelo
shell como sendo comentários, o que significa que elas não são
executadas, não importa o que contenham; podemos pôr hyperlinks em
Emacs Lisp nos comentários e o shell não vai perceber nada, e quando
formos editar um script desses no Emacs poderemos seguir esses
hiperlinks...

Imagine que temos alguns arquivos de anotações, cada um contendo uma
mistura de texto, links e blocos de código shell; os links apontam
para pontos relevantes em outros dos nossos arquivos de anotações, e
também para outros lugares com documentação importante, e para alguns
scripts que nós escrevemos; esses scripts provavelmente começaram como
blocos de código shell nos arquivos de anotações, e quando nós os
transformamos em scripts nós resolvemos manter os links que eles
continham, já que não havia motivo para tirá-los... bom, com isso o
Emacs acaba virando um ambiente fantástico: cada coisa que escrevemos
aponta para outros lugares relacionados, e seguir os links é facílimo,
e quando os seguimos continuamos dentro do Emacs, de onde os links
continuam funcionando... tudo fica muito próximo e muito acessível.
Para um exemplo realista de quão linkadas as coisas podem ficar, veja
<http://angg.twu.net/>.




Parte 3: Blocos delimitados
---------------------------

# «blocos_delimitados»  (to ".blocos_delimitados")

Se você tiver feito a instalação "completa" (veja o apêndice) a tecla
F3 estará associada a um comando do Emacs chamado `ee-bounded', cuja
ação default é rodar o comando `eev-bounded', que por sua vez funciona
como uma espécie de `eev' que nos dispensa de marcar o bloco
explicitamente: ao invés de gravar a "região corrente" do Emacs (i.e.,
o trecho do buffer corrente que está entre o `point' e a `mark') o F3
grava o trecho em torno do cursor que vai até certos "delimitadores"
configuráveis; por default o `eev-bounded' usaria como delimitadores
strings "\n#-\n" (ou seja, linhas que só contêm "#-"), mas eu
normalmente prefiro "\n#*\n"; o "*" é simplesmente um caracter 15, que
vai aparecer na sua tela como uma estrela vermelha ou como "^O". Para
inserir um desses caracteres no seu texto bata `C-q C-o'.

A seção [glyphs] explica como fazer o caracter 15 aparecer como uma
estrela vermelha; a seção [variables] explica como o Emacs percebe que
neste arquivo o delimitador tem que ser "\n#*\n" e não "\n#-\n".

# (find-enode "Inserting Text" "* `C-q'")
# (find-angg "eev.el" "eev")
# (find-angg "eev.el" "bounded")

Exemplo:

#*
# (eev-bounded)
# (eev-bounded 'once)
tac <<'---'
  um
  dois
---
#*
rev <<'---'
  um
  dois
---
#*

Note que dá pra executar o bloco acima todo de uma vez (i.e.,
ignorando que há um delimitador que o separa em dois bloquinhos
F3-záveis) marcando-o do jeito usual e batendo `M-x eev'; a linha "#*"
do meio vai ser considerada como comentário pelo shell e não vai
atrapalhar na execução.

O eev não é o único comando que tem uma versão com delimitadores; o
eelatex também tem, e o eeg (que nós ainda não vimos) também. Exemplo:
se você rodar `M-x eelatex-bounded' dentro do bloco abaixo o Emacs vai
gravar um script temporário que quando executado com "ee" num shell
vai interpretar o bloco gravado como um texto em LaTeX.

%*
% (eelatex-bounded)
% (eelatex-bounded 'once)
Um texto em \LaTeX

%*

Se você tiver preguiça de bater `M-x eelatex-bounded' você pode
executar uma das linhas `eelatex-bounded' acima (`eev-bounded' no
exemplo anterior); os comandos eexxx-bounded admitem um parâmetro
opcional, que se estiver presente vai indicar que a função
eexxx-bounded deve ser rodada "uma vez só", i.e., não deve se tornar o
default para o F3. Um modo alternativo de passar esse parâmetro
adicional é batendo, por exemplo, `M-1 M-x eelatex-bounded'.

# (find-enode "Completion")
# (find-enode "Arguments")

Em TeX e LaTeX o caracter que indica comentário é o "%", não o "#", e
daí faz mais sentido usar delimitadores começados com "%". Os
delimitadores usados para LaTeX também podem ser controlados pelos
truques da seção [variables].




Parte 4: A interface genérica: eeg
----------------------------------

# «eeg»  (to ".eeg")

Se você souber o suficiente de programação em shell você deve ser
capaz de controlar boa parte dos programas interativos usando "pipes".
Um exemplo simples:

#*
echo 1+2 | bc
bc <<'---'
2+3
3+4
---
#*

Só que muitos programas interativos se comportam de modo diferente
quando percebem que o input está vindo de um pipe, e muitas vezes você
gostaria de fazer aparecer na tela exatamente o que o programa
responderia interativamente, mas sem ter que digitar tudo
manualmente... A "interface genérica do eev", que consiste em um
programinha em Expect chamado "eeg" e dois comandos de Emacs, `M-x
eeg' e `M-x eeg-bounded', cuida disso. `M-x eeg' funciona parecido com
`M-x eev', só que o texto do bloco marcado no Emacs é gravado num
outro arquivo temporário, por default ~/bin/ee.generic; numa
instalação adequada a variável de shell $EEG contém o nome desse
arquivo, e portanto em

#*
cat > $EEG <<'---'
2+3
3+4
quit
---
eeg bc
#*

o "cat" vai funcionar como se tivéssemos marcado as três linhas entre
os "---"s manualmente no Emacs e dado `M-x eeg'.

O truque é que quando chamamos o bc "através do eeg", como na linha
"eeg bc", o bc roda normalmente, em modo interativo, com quase todas
as teclas que o usuário bate sendo mandadas diretamente para o bc, sem
nenhum tratamento; só uma é "traduzida" de modo especial: a cada vez
que o usuário bate `M-l' o eeg manda pro bc uma das linhas do arquivo
$EEG, seguida de um `<enter>', e se todas as linhas já foram mandadas,
o eeg descarta o `M-l' e não faz nada. Daí, se executamos o bloco
acima com `ee' num shell e batemos `M-l asfdg <enter> M-l M-l', vemos
algo como:

/home/edrx(edrx)# ee
cat > $EEG <<'---'
2+3
3+4
quit
---
eeg bc
bc 1.05
Copyright 1991, 1992, 1993, 1994, 1997, 1998 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
2+3
5
asdfg
0
3+4
7
quit
/home/edrx(edrx)#

O Expect é capaz de controlar qualquer programa que se comunique via
terminal (i.e., via stdin, stdout, stderr e /dev/tty), o que inclui
programas "muito interativos" como ssh, telnet, adduser, emacs, vi,
etc, e praticamente só exclui os programas que só rodam em X. A idéia
é que "tudo" (se a gente fingir que as interfaces gráficas não
existem!) pode ser controlado pelo Expect e pelo eeg.

Para alguns programas pode ser mais conveniente usar uma variação do
eeg que não se restrinja a mandar uma linha (terminada por CR) de cada
vez. Eu estou escrevendo uma variação dessas:

# (find-angg "EXPECT/eeg3")

Ela já funciona, mas a sintaxe do arquivo $EEG que ela usa ainda é
muito ruim.





Parte 5: âncoras e links locais
-------------------------------

# «ancoras»  (to ".ancoras")

(...)

# (find-angg "eev.el" "find-anchor")
# (find-angg "eev.el" "to_and_back")





Parte 6: links para informações sobre um pacote num sistema Debian
------------------------------------------------------------------

# (find-angg "eev.el" "find-anchor")
find-status





Parte 7: truques para inserir links num texto
---------------------------------------------

# «mkto_dff_inn»  (to ".mkto_dff_inn")

# (find-angg "eev.el" "inn")
# (find-angg "eev.el" "dff")
# (find-angg "eev-extras.el")

(Falar também algo sobre gravar macros)




Parte 7: variáveis
------------------

# «variaveis»  (to ".variaveis")
# (find-enode "Variables")
# (find-elinode "Variables")
# (find-elnode "Variables")




Parte 8: glyphs
---------------

# «glyphs»  (to ".glyphs")




Apêndice: criando demos com eeg2
-------------------------------

# «demos_eeg2»  (to ".demos_eeg2")










# (find-es "anatocc" "cdecl")

find-status
find-vldifile xxx.list

# (find-es "anatocc" "cdecl")
".e"s

# (find-es "anatocc" "dlopen")

alias pro bash



;; (describe-function 'find-fline)
;; (describe-function 'find-node)
;; (describe-function 'ee-goto-position)
;; (describe-function 'eev)
;; (describe-function 'eeman)
;; (describe-function 'eecd)
;; (describe-function 'eeg)
;; (describe-function 'eev-bounded)
;; (describe-function 'eelatex)
;; (describe-function 'eelatex-bounded)
;; (describe-function 'eeg-bounded)
;; (describe-function 'end-of-line-then-eval-last-sexp)
;; (describe-function 'ee-bounded)
;; (describe-function 'code-c-d)
;; (describe-function 'inn)
;; (describe-function 'dff)











Apêndice I: Instalando o eev.el num sistema Debian
--------------------------------------------------

# (find-es "escripts")
# (find-es "escripts" "copy_of_edrxs_home_LR")
# (find-angg "README")


Apêndice __: Rodando um demo em eeg2



Rodando no X
instalar rxvt
corrigir o eeg pra ele aceitar +128?

echo 'kover::0:0:kover:/home/edrx:/usr/bin/zsh' >> /etc/passwd






#  Local Variables:
#  coding:               no-conversion
#  ee-delimiter-hash:    "\n#*\n"
#  ee-delimiter-percent: "\n%*\n"
#  ee-anchor-format:     "«%s»"
#  ee-charset-indicator: "Ñ"
#  End: