Problemas de Emacs por solucionar

Ej: abc → def. Eso cambia la frase „cosa de prueba“ a „fosd de prueed“

(yes-or-no-p "¿? ")
(y-or-n-p "¿? ")

No puedo cambiar de ventana en y-or-n-p y es muy molesto (ej: para C-x v u). Al menos tendría que poderse usar la rueda del ratón, o deslizarse por teclado, para poder ver el búfer Diff que crea C-x v u.

O sea: si abro un fichero de 4 Gb, que no intente poner esos 4 Gb en memoria, sino sólo unas cuantas páginas, y a medida que me muevo, que descarte lo que ya no se ve y cargue de disco lo que se quiere ver.

Ha habido muchos intentos de hacer esto, bajo el nombre de „very large files“. Ejemplo: http://www.emacswiki.org/emacs/vlf.el

Puntos difíciles: la colorización se ha de hacer basándose en sólo el trocito visible.

• Por ejemplo para cuando estoy en log4j-mode; me interesa no poder cambiar a otros
• O también para trabajar más en openTrends.org.
• También para poder abrir eshell como si fuera un urxvt normal: una ventana de shell que no puede convertirse en editor a ratos, sino que sigue siendo una terminal hasta morir. (Quiero sustituir urxvt por eshell)

Es una restricción por ventana.

Desactivadas:

• find-file
• switch-to-buffer

Activado:

• kill-this-buffer

No sé si hay forma mejor que desactivar teclas.

Lo puedo hacer junto con un modo xkb (xkb-mode).

En x-resource-generic-mode, iluminar comentarios con color distinto.

Igual que el modo para xmodmap, pero para Xkb, más moderno.

• [ ] buscar gramática
• [ ] usar define-generic-mode para listar expresiones, etc
• [ ] probarlo

<22.m08.2008> El:

(defun rcirc-activity-string (buffers).........

podría hacer que al hacer clic en el nombrecito se cambiare al búfer de chat clicado.

• CONCLUSIÓN escrita el <14.m10.2009 09:49>
  ya está en Emacs 23.2

Julio 2008. Yo sólo quería más documentación…

Se dejó para más adelante.

Email from Juri Linkov: Re: & and M-& to run programs asynchronously

• CONCLUSIÓN escrita el <02.m10.2012 00:02>
  se puede con: M-/ M-espacio M-/

Para permitir ir alante y atrás en la ejecución de una macro

• CONCLUSIÓN escrita el <02.m10.2012 00:03>
  ya está

Con „!“ Y en lo de ejecutar comando, en general…

Quiero que esas operaciones empiecen ya sugiriendo en el minibúfer no sólo el directorio actual, sino también el nombre del fichero. O sea, al mover cos.txt, quiero ver escrito cos.txt para retocarlo p.ej. a cosa.txt

Se podría usar dired-dwim-target para elegir el comportamiento de la elección del destino sugerido.

• representación gráfica de los bloques que componen un fichero
• ocupa toda la pantalla o menos, pero nunca más
• parecido a filelight pero para el interior de un fichero en vez de el interior de un directorio
• si no existe el concepto de „bloque interior“ dentro del fichero, mostrar simplemente las líneas, en un tamaño de fuente muy pequeño
• „bloque interior“: el definido por inicios y finales de secciones, cabeceras (org-mode), definiciones de funciones (prog-mode), etc.
• el tamaño de cada bloque interior ha de dar una indicación de su extensión
• igual que una sección (org) puede tener subsecciones, un bloque puede mostrar subbloques
• puede ir perfecto para poder ver cómo de grande es cada sección (cuántas líneas de contenido hay bajo cada cabecera) en org
• [ ] probar extensión „minimap“ (está en elpa) pues lo hace; aunque no sé si delimita bloques

¡Que esto se integre en algún paquete de Emacs

; Encontrado por ahí, en http://osdir.com/ml/help-gnu-emacs-gnu/2009-11/msg00484.html (defun sublist (list from &optional to) "Return a sublist of LIST, from FROM to TO. If END is omitted, it defaults to the length of the sequence. Counting starts at 0. Like `subseq' and `substring' but solely for lists." (let ((start (nthcdr from list))) ;start reference (if to (butlast start (- (+ from (length start)) ;if extract list at the end this makes it much faster to)) start)))

Como C-n pero que salte todos los caracterese iguales al actual, hasta encontrar uno diferente.

Ej. si estoy en la „u“ del primer „/run/“, bajará hasta la „i“ del primer „/lib32“:

/run/initramfs
/run/initramfs/fsck-root
/run/initramfs/fsck.log
/lib32
/lib32/libresolv.so.2
/lib32/libcrypt-2.22.so

Y luego, para confundir un poco… ¡hacer este comportamiento el inicial para todos los usuarios!. Creerán que las teclas flechita se han atascado.

• http://lists.gnu.org/archive/html/emacs-devel/2018-05/msg00103.html
• quiero que el rename-file me dé el nombre actual, no el nombre de un búfer cercano sugerido como destino
• https://emacs.stackexchange.com/questions/12656/how-to-complete-the-original-name-in-helm-dired-rename
  • ooooooh, apretando M-n ya se encuentra el nombre que busco

Lisp Backtrace: "re-search-forward" (0x7bdb33d8) "org-font-lock-add-priority-faces" (0x7bdb3748) "font-lock-fontify-keywords-region" (0x7bdb3c00) "font-lock-default-fontify-region" (0x7bdb3fb8) "font-lock-fontify-region" (0x7bdb42a8) 0x37de3cf0 PVEC_COMPILED "run-hook-wrapped" (0x7bdb46c0) "jit-lock–run-functions" (0x7bdb4a40) "jit-lock-fontify-now" (0x7bdb4e98) "jit-lock-function" (0x7bdb5238) "redisplay_internal (C function)" (0x0)

— SIGPROF {si_signo=SIGPROF, si_code=SI_TIMER, si_timerid=0, si_overrun=2, si_value={int=81205448, ptr=0x564c04d718c8}} — rt_sigreturn({mask=[]}) = 94885258459412 — SIGPROF {si_signo=SIGPROF, si_code=SI_TIMER, si_timerid=0, si_overrun=5, si_value={int=81205448, ptr=0x564c04d718c8}} — rt_sigreturn({mask=[]}) = 87 — SIGPROF {si_signo=SIGPROF, si_code=SI_TIMER, si_timerid=0, si_overrun=3, si_value={int=81205448, ptr=0x564c04d718c8}} — rt_sigreturn({mask=[]}) = 24 — SIGPROF {si_signo=SIGPROF, si_code=SI_TIMER, si_timerid=0, si_overrun=6, si_value={int=81205448, ptr=0x564c04d718c8}} — rt_sigreturn({mask=[]}) = 1 — SIGPROF {si_signo=SIGPROF, si_code=SI_TIMER, si_timerid=0, si_overrun=2, si_value={int=81205448, ptr=0x564c04d718c8}} — rt_sigreturn({mask=[]}) = 72 — SIGPROF {si_signo=SIGPROF, si_code=SI_TIMER, si_timerid=0, si_overrun=6, si_value={int=81205448, ptr=0x564c04d718c8}} — rt_sigreturn({mask=[]}) = 94885599648922

• [X] está jump-char.el pero no hace esto; sólo hace izquierda/derecha (le falta arriba/abajo). Y tampoco permite decir „el 1º distinto“. Y no es muy cómodo
• en lo que quiero yo, no hace falta ni siquiera decir a dónde hay que moverse; simplemente se mueve hasta encontrar algo distinto (o hasta que se acaba el camino en esa dirección)
• probablemente es útil algo así para editar dibujos en ASCII

• por ejemplo, si me pongo en la s de security.d y pido ir abajo, quiero acabar en la c de classpath

  /etc/java/security/security.d
  /etc/java/security/security.d/1003-gnu.javax.net.ssl.provider.Jessie
  /etc/java/security/security.d/1000-gnu.java.security.provider.Gnu
  /etc/java/security/security.d/1001-gnu.javax.crypto.jce.GnuCrypto
  /etc/java/security/security.d/1004-gnu.javax.security.auth.callback.GnuCallbacks
  /etc/java/security/security.d/2000-org.bouncycastle.jce.provider.BouncyCastleProvider
  /etc/java/security/security.d/1002-gnu.javax.crypto.jce.GnuSasl
  /etc/java/security/classpath.security
  /etc/java/cacerts-gcj
  

• pruebo algo. Vaya, ELisp es más molesto que lo quiero. Pero esto ya es una „prueba del concepto“

  (defun movu-ĝis-trovi-alian-leteron (&optional io) 
    (interactive "P")
    (let ((letero (following-char)))
      (message "Nun en: %s, %s" (point) (line-number-at-pos))
      (message "Movos ĝis trovi ion malsaman al «%s» (%s)" letero (get-char-code-property letero 'name))
      (next-line)
      (while (eq (following-char) letero)
        (next-line)
        )
      ;; plu ĉi tie. ẽ ebligu salti tra pluraj tipoj de spacoj
      )
    )
  

• veo: spatial-navigate, parece hacer una parte de lo que busco. Por probar
• ah, veo que visidata lo hace bien, con < y >, es lo que buscaba. Pero lo quiero para cualquier modo de texto, no sólo CSV
  • mmmmm… puedo abrir cualquier .txt como si fuera un CSV de 1 columna

• CONCLUSIÓN escrita el <02.m10.2012 00:04>
  ya no pasa

<28.m04.2008>

1. edita
2. busca: C-s LE1_PROG
3. dale más a C-s
4. no encuentra más resultados, aunque los hay

El fallo sólo pasa si global-hl-mode está activo

• CONCLUSIÓN escrita el <02.m10.2012 00:05>
  lo arreglaron

Mandé el fallo el <12.m04.2009 04:03>

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2966

(make-directory)

Está en simple.el, función shell-command. Sale al abrir con & un .pdf mediante evince y luego hacer (shell-command "xeyes &"). Por lo visto no quiere tener dos tareas de fondo a la vez.

• [ ] debería decir algo como "Command evince is running. Kill it and open xeyes?"
• [ ] hay que permitir varias tareas en segundo plano a la vez; se ha de solucionar con un parche como el de M-& para ejecutar comandos en segundo plano

Hay que buscar o una solución general o un evite de cada problema.

Mandado a -pretest-bugs el <09.m02.2009 18:18>.

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2250

Cuando está en dos líneas, falla:

(setq b '(
(c d )))

Ponte entre c y d (¡en lisp-interaction-mode!) y C-M-x Da: Lisp error: (void-function c) En 2012, veo: eval-defun: Wrong type argument: listp, ***

Me doy cuenta el <31.m10.2010> en ali con .org; sólo pasa en modo texto y es debido al invento que me hice con xsel (encontrable en Internet, supongo).

Quizás se debe a esto en xsel.c, línea 2040:

/* Get the maximum incremental selection size in bytes */
/*max_req = MAX_SELECTION_INCR (display);*/
max_req = 4000;

Curioso que diga „4000 bytes“ pues yo conté „4000 caracteres“.

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-width(nil)
  tmm-get-keymap(nil nil)
…
  tmm-menubar()
  x-menu-bar-open(nil)
  menu-bar-open()

Y pasa excepto si comento la línea (rcirc-track-minor-mode 1) de mi .emacs. Debe de ser por los ganchos a post-command-hook…

Se me ocurre:

• que ese modo sólo se active al entrar en rcirc, y se desactive al salir. Se minimiza el problema
• usar ERC envez
• corregirlo

Temporal: M-x rcirc-track-minor-mode lo desactiva y el menú vuelve a ir

El <10.m02.2011>, js.el de Emacs de Bazaar. Ej.

// this fails: the 3rd line is shown in font-lock-string-face (it should be font-lock-comment-face)
// something, /
// this line is wrong (but it is corrected if you type here. Type again the / above to restore the misbehaviour)

Muchos lo han visto antes:

• http://joost.zeekat.nl/2007/10/31/javascript-regex-en-string-literal-highlighting-in-emacs/ ← parecido mas distinto fallo (que ya no está)

Quizás es por hibernar. Es por matar X. Desde mucho tiempo he estado abriéndolo de nuevo cada vez. Me pasa desde m9.2011 mínimo (y en m9.2012 sigue pasando).

Ver strace.

Pasa de vez en cuando. Sobre todo me lo encuentro al volver a abrir emacsclient tras abrir X (las veces en que emacsd no ha muerto por cerrar X).

dc       31992  2.1  0.1   4712  2148 ?        Rs   Sep24  30:31 /usr/bin/openssl s_client -quiet -host imap.gmail.com -port 993 -verify 1 -CApath ~/.emacs.d/datos-w3m/

Una traza dice poco:

(gdb) bt
#0  0xb77f5424 in __kernel_vsyscall ()
#1  0xb7525c3d in select () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#2  0x08082977 in ?? ()
#3  0x0805ca00 in ?? ()
#4  0x0805c430 in ?? ()
#5  0xb7476e46 in __libc_start_main () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#6  0x0805c6a1 in ?? ()
Backtrace stopped: Not enough registers or memory available to unwind further

En efecto, está en select:

select(4, 0xbfd931a0, 0xbfd93220, 0, 0 <unfinished ...>
  SYS__newselect(4, 0xbfd931a0, 0xbfd93220, 0, 0)                                                 = 1
<... select resumed> )                                                                            = 1
SSL_version(0x8dedfd8, 0xbfd931a0, 0xbfd93220, 0, 0)                                              = 768
SSL_get_fd(0x8dedfd8, 0xbfd931a0, 0xbfd93220, 0, 0)                                               = 3
SSL_get_fd(0x8dedfd8, 0xbfd931a0, 0xbfd93220, 0, 0)                                               = 3
SSL_write(0x8dedfd8, 0x8de4950, 0, 0, 0)                                                          = 0
SSL_get_error(0x8dedfd8, 0, 0, 0, 0)                                                              = 5
SSL_version(0x8dedfd8, 0, 0, 0, 0)                                                                = 768
SSL_state(0x8dedfd8, 0, 0, 0, 0)                                                                  = 3
SSL_pending(0x8dedfd8, 0, 0, 0, 0)                                                                = 0
fileno(0xb75b6440)                                                                                = 0
fileno(0xb75b6440)                                                                                = 0
SSL_get_fd(0x8dedfd8, 0, 0, 0, 0)                                                                 = 3
SSL_get_fd(0x8dedfd8, 0, 0, 0, 0)                                                                 = 3
select(4, 0xbfd931a0, 0xbfd93220, 0, 0 <unfinished ...>
  SYS__newselect(4, 0xbfd931a0, 0xbfd93220, 0, 0)                                                 = 1
<... select resumed> )                                                                            = 1

Por si acaso desactivo gnus (con su gnus-demon).

Pero ¡me pasó sin ni siquiera haber abierto el correo! (Ni gnus ni wanderlust). Y yo sólo escribí imap.gmail.com en mi .emacs aquí:

(setq elmo-imap4-default-server "imap.gmail.com")

Así que es por elmo, que es usado por Wanderlust para mi cuenta de Gmail principal.

• [ ] elegir bien entre openssl y starttls; creo que starttls es poco seguro

En concreto:

print "hola"""

(vc-responsible-backend "/home/dc/repoweb")

Debería dar Hg, da git. Quizás porque /home/dc es git.

Vaya, debería detectar esta imbricación y dar el cdv más interno, no el primero que encuentra.

∴ Cambiar vc-handled-backends.

Ej. cuando >1M caracteres por línea, el coloreado es muy lento. Como protección, debería autoapagarse.

• ~~~ https://emacs.stackexchange.com/questions/9955/how-do-i-turn-off-syntax-coloring-for-lines-that-exceed-the-word-limit-in-prelud
• ~~~ https://github.com/clojure-emacs/cider/issues/1115

De momento, desactivarlo manualmente: M-x font-lock-mode

(buffer-name)

" *Minibuf-0*"

Pruebo:

• (kill-buffer (buffer-name))
• (kill-buffer " Minibuf-0") → nil
• ∴ (kill-buffer " Minibuf-2") ← ∴ esto me lo ha arreglado alguna vez
• (buffer-list), me ayudó

Tras tener un error (intentando usar exit-minibufer) salió backtrace, y creo que este backtrace me arregló el problema original.

• esto ya se lía: a partir del apóstrofe, queda todo en amarillo (el resto de esa línea, y la línea siguiente). No debería

  {% if a < 0 %}
  <p>
  {# It's the apostrophe #}
  Something
  

• es debido al signo <. Alguien se cree que está empezando etiqueta HTML

• esto me pasa <12.m01.2023>, con: GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2023-01-05, y creo que antes no pasaba
• „ẽ“ lo toma de: ftcr:-PfEd-Terminus-medium-normal-normal-*-12-*-*-*-c-*-iso10646-1 (#x2D1)
• „S“ lo toma de: x:-xos4-terminus-medium-r-normal--20-200-72-72-c-100-iso8859-1 (#x53)

• Debugger entered--Lisp error: (wrong-type-argument "integer-or-marker-p nil")
    signal(wrong-type-argument ("integer-or-marker-p nil"))
    tramp-error((tramp-file-name "su" "so" nil "ocrb" nil "/home/so/billing/src/steps/reversal_invoice/__init..." nil) wrong-type-argument "integer-or-marker-p nil")
    tramp-signal-hook-function(wrong-type-argument ("integer-or-marker-p nil"))
    signal(wrong-type-argument ("integer-or-marker-p nil"))
    tramp-handle-insert-file-contents("/su:so@ocrb:/home/so/contract/src/get_or_create_contract.py" t nil nil t)
    tramp-sh-file-name-handler(insert-file-contents "/su:so@ocrb:/home/so/contract/src/get_or_create_co..." t nil nil t)
    apply(tramp-sh-file-name-handler insert-file-contents ("/su:so@ocrb:/home/so/contract/src/get_or_create_co..." t nil nil t))
    tramp-file-name-handler(insert-file-contents "/su:so@ocrb:/home/so/contract/src/get_or_create_co..." t nil nil t)
    revert-buffer-insert-file-contents--default-function("/su:so@ocrb:/home/so/contract/src/get_or_create_co..." nil)
    revert-buffer--default(nil t)
    revert-buffer(nil t)
  
  

• tramp-handle-insert-file-contents("/su:so@ocrb:/home/so/contract/src/get_or_create_contract.py" t nil nil t)
  (tramp-handle-insert-file-contents "/su:so@ocrb:/home/so/contract/src/get_or_create_contract.py" t nil nil t)
  

  • hago eso decenas miles de veces seguidas y me va bien. No parece ser que un % de veces falle

    (loop for i from 1000 downto 1 do (tramp-handle-insert-file-contents "/su:so@ocrb:/home/so/contract/src/get_or_create_contract.py" t nil nil t))
    

  • me miro tramp-handle-insert-file-contents, es largo

• Por ejemplo, en „Trần“, el ầ aparece mucho más pequeño
  • está eligiendo para ầ: x:-mutt-clearlyu-medium-r-normal–17-120-100-100-p-123-iso10646-1 (#x1EA7)
  • mientras que para la n elige: x:-xos4-terminus-medium-r-normal–32-320-72-72-c-160-iso8859-1 (#x6E)
• ∴ en modo texto (-nw) va bien
• en terminal (urxvt) va bien; elige otras fuentes
• estoy usando --with-x-toolkit=lucid, GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2023-08-10

En: GNU Emacs 23.1.1 (2009-09-14)

1. Dividir el marco en 4 ventanas
2. En una de ellas hacer C-x v v
3. Se usa una de las otras para escribir el comentario (en vez de crear una nueva)
4. C-c C-c
5. Se cierra esa ventana usada, cosa que es un error, pues no fue abierta por vc, sino por el usuario, y por tanto la quiere mantener

Soluciones:

• o siempre abrir ventana nueva para el comentario de la entrada
• o matar el búfer pero no la ventana

Se pueden hacer ambaas. En la 1ª solución, partir la ventana actual en dos, en vez de irse a buscar una otra ventana cualquiera.

Lo 2º se controla con la variable vc-delete-logbuf-window, por lo que hay mucho trozo hecho. Le falta una opción: matar búfer pero no ventana (esto es diferente de „enterrar búfer“, que mantiene una ventana vieja pero funcional). Además, si se queda la ventana vieja por ahí, en cada comentario de los siguientes „C-x v v“ se ve el texto del anterior.

Por ahora usar (setq vc-delete-logbuf-window nil)

• me dice a veces: rx--translate-bounded-repetition: rx ‘**’ range error

  • Warning (org-element-cache): org-element–cache: Org parser error in .emacs::1944. Resetting. The error was: (error "rx ‘**’ range error") Backtrace: " backtrace-to-string(nil) org-element-at-point() org-cycle(nil) funcall-interactively(org-cycle nil) call-interactively(org-cycle nil nil) command-execute(org-cycle) "

  • no veo nada especial en 1944 (move-text-down). Excepto que quizás hay mucho texto hasta ahí; quizás estaba buscando algo antes, no lo ha encontrado, y se ha paseado por miles de líneas en vano, y es la cantidad lo que le hace fallar
  • ah, 1944 es el byte, no la línea. Es cuando empieza el esquemado
• quizás tengo mal la sintaxis en alguna de las secciones, o en la cabecera
• quizás mi .emacs es demasiado grande

• aparentemente se llama a rx–translate-bounded-repetition con name="**"

  rx--translate-bounded-repetition(** (1 0 "*"))
  

  • está en org-element–parse-to(1944)

  • rx-to-string((seq line-start (** 1 0 "*") " "))
    

  • ya falla: (org-element–parse-to 1944)

• pasa con:

  ;; -- mode: emacs-lisp; mode:outline-minor; hs-minor-mode: nil; outline-regexp:";;;; [^ ]" -*-

  ;;; hola ; a ;;;; h1 ; b

• funciona fatal; ni siquiera esto va, y hace cosas muy raras:

  ;; -- mode: emacs-lisp; mode:outline-minor; outline-regexp:";+" --

  ; hola (a) ;; h1 (b) ;; h2 (c)

  ; segundo

• ∴ de momento no lo uso y no lo necesito, pues conozco la estructura de mi .emacs, y el outline-mode me ha hecho perder demasiadas horas durante años. Pero me gustaría que alguien lo arreglara

• CONCLUSIÓN escrita el <12.m10.2011 18:52>
  parece que ya no pasa; de todas formas otros no pudieron reproducirlo, así que se ha cerrado el informe

Tiene algo que ver con el cursor. Fallo muy viejo (me ha acompañado años). Quizás ya está arreglado.

Mandado a: http://debbugs.gnu.org/db/30/3090.html

• [ ] mirarme la entrada 100999 de Bazaar, puede haber corregido algo
• [ ] encontrar la forma de causarlo sin icicles ni tabbar (pues no los uso y me ha pasado alguno vez)

Recuerdo que podía desbloquear Emacs de alguna forma, aunque no siempre con éxito (a veces hizo SIGSEGV).

Con versión „GNU Emacs 24.0.90.4 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2011-10-12 on ali“ esto hace petar:

(setq ov (make-overlay 1 2))
(overlay-put ov 'after-string "\n111\n2" )

(gdb) bt
#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb7393be6 in kill () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#2  0x081288e8 in abort () at emacs.c:386
#3  0x08083497 in find_row_edges (max_bpos=2, max_pos=2, min_bpos=2, min_pos=2, row=0x882e008, it=0x586b) at xdisp.c:18713
#4  display_line (it=0x586b) at xdisp.c:19310
#5  0x08087b5f in try_window (window=141028573, pos=..., flags=1) at xdisp.c:15896
#6  0x0809c920 in redisplay_window (window=141028573, just_this_one_p=0) at xdisp.c:15440
#7  0x0809e3d1 in redisplay_window_0 (window=141028573) at xdisp.c:13563
#8  0x08199617 in internal_condition_case_1 (bfun=0x809e3b0 <redisplay_window_0>, arg=141028573, handlers=138771190, hfun=0x8068970 <redisplay_window_error>)
    at eval.c:1537
#9  0x0806ca4f in redisplay_windows (window=<optimized out>) at xdisp.c:13543
#10 0x08088960 in redisplay_internal () at xdisp.c:13120
#11 0x081339b7 in read_char (commandflag=1, nmaps=2, maps=0xbffff210, prev_event=138789130, used_mouse_menu=0xbffff308, end_time=0x0) at keyboard.c:2443
#12 0x08135b69 in read_key_sequence (keybuf=0xbffff378, prompt=138789130, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1, bufsize=30)
    at keyboard.c:9282
#13 0x081373f7 in command_loop_1 () at keyboard.c:1447
#14 0x081994ed in internal_condition_case (bfun=0x8137260 <command_loop_1>, handlers=138820138, hfun=0x812d7c0 <cmd_error>) at eval.c:1499
#15 0x0812c2c5 in command_loop_2 (ignore=138789130) at keyboard.c:1158
#16 0x08199409 in internal_catch (tag=138818114, func=0x812c2a0 <command_loop_2>, arg=138789130) at eval.c:1256
#17 0x0812d2fa in command_loop () at keyboard.c:1137
#18 recursive_edit_1 () at keyboard.c:757
#19 0x0812d5ee in Frecursive_edit () at keyboard.c:821
#20 0x08054deb in main (argc=4, argv=Cannot access memory at address 0xa
) at emacs.c:1706
(gdb) quit

Encontré el fallo cuando intentaba usar http://www.randomsample.de/profile-dotemacs.el.

• [X] Enviado a emacs: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9738
• [X] corregido; ambos parches enviados por Eli funcionan. Ha sido una corrección muy rápida

• me ha quitado espacios a final de línea
• me ha cambiado espacios por tabuladores al inicio de citas
• me ha separado de otra manera las etiquetas en cabeceras
• los CLOCK los ha cambiado a TAB también

Mmm… tiene pinta de que no ha sido org-mode, sino un whitespace-cleanup mal hecho

[76488.909530] emacs[4995]: segfault at 5612084b ip b3007781 sp bf9b05c0 error 4 in libgcc_s.so.1[b2ff3000+1b000] [78003.210008] emacs[30959]: segfault at 2159f504 ip 0813332d sp bf8ca3c4 error 4 in emacs-24.3.50[8048000+264000] [81138.280177] emacs[2698]: segfault at 2a3607c4 ip 0813332d sp bf9ebcb4 error 4 in emacs-24.3.50[8048000+264000] [82635.248673] emacs[19470]: segfault at 10cf0334 ip 08133459 sp bfd63ef4 error 4 in emacs-24.3.50[8048000+265000]

• recompilé, y lo mismo
• creo que es por algo nuevo de estos días (<11.m11.2013>)
• tuve que pasar a emacs 23.4 (sin helm)
• y usar vim por el camino (¡incómodo!)
• seguí un tiempo con 23 pues ya iba bien
• [X] esperar arreglo, volver a 24 ← parece que el <16.m01.2014> ya no falla

#9332 0x00000000005984ee in mark_object (arg=16408162) at alloc.c:6243 #9333 0x00000000005988ba in mark_object (arg=16649030) at alloc.c:6355 #9334 0x00000000005984ee in mark_object (arg=12843890) at alloc.c:6243 #9335 0x0000000000597c8b in mark_vectorlike (ptr=0xc221b8 <buffer_defaults>) at alloc.c:5894 #9336 0x0000000000597e00 in mark_buffer (buffer=0xc221b8 <buffer_defaults>) at alloc.c:5945 #9337 0x000000000059747c in Fgarbage_collect () at alloc.c:5637 #9338 0x00000000005206db in maybe_gc () at lisp.h:4522 #9339 0x00000000005b6fff in Ffuncall (nargs=2, args=0x7fffbaf6c300) at eval.c:2766 #9340 0x00000000005b6c47 in call1 (fn=12883202, arg1=212844253) at eval.c:2614 #9341 0x000000000052c916 in timer_check_2 (timers=384952022, idle_timers=384952070) at keyboard.c:4515 #9342 0x000000000052ca2e in timer_check () at keyboard.c:4582 #9343 0x0000000000602747 in wait_reading_process_output (time_limit=37, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=12843890, wait_proc=0x0, just_wait_proc=0) at process.c:4386 #9344 0x0000000000419ea1 in sit_for (timeout=148, reading=true, display_option=1) at dispnew.c:5805 #9345 0x0000000000529553 in read_char (commandflag=1, map=73056374, prev_event=12843890, used_mouse_menu=0x7fffbaf6cd9f, end_time=0x0) at keyboard.c:2811 #9346 0x0000000000534bd4 in read_key_sequence (keybuf=0x7fffbaf6cf80, bufsize=30, prompt=12843890, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9084 #9347 0x0000000000526821 in command_loop_1 () at keyboard.c:1452

• con emacs 24.3.1 y el de <03.m06.2014>
• no pasa con: ∅←Δߪ∩ŝ…
• pasa con ∴∀∃
• ∀ es de esta fuente:

xft:-unknown-TeX Gyre Termes Math-normal-normal-normal-*-20-*-*-*-*-0-iso10646-1 (#xEFE)

Eso es porque actualicé hace poco:

-fonts-texgyre 2.004.2-4 +fonts-texgyre 20140520-1

Las desinstalo… Y me queda otra:

xft:-unknown-FreeMono-normal-normal-normal-*-20-*-*-*-m-0-iso10646-1 (#x9EC)

Que ya funciona y me da esos glifos.

(condition-case nil nil nil)

Mandado informe, 22675: http://lists.gnu.org/archive/html/bug-gnu-emacs/2016-02/msg00875.html Corregido.

helm-files.el:1632:26:Warning: ‘(sum (with-temp-buffer (insert-file-contents-literally file) (secure-hash algo (current-buffer))))’ is a malformed function

(require 'cl-lib)

Debido a:

commit 2f85993b5a455d5633f42c7e1a0a1cb429b2c09b Author: Thierry Volpiatto <thierry.volpiatto@gmail.com> Date: Tue May 2 14:28:53 2017 +0200

Helm requires async from now and use it in helm-ff-checksum.

• helm-files.el (helm-ff-checksum): Use async-let.

Era por versión vieja de async.

Esto tras recompilar.

• http://lists.gnu.org/archive/html/emacs-devel/2018-12/msg00116.html
• ¡me toca actualizar todas las llamadas a emacsclient…!

Intento esto, no va:

dc; ~/.emacs.d ; ln -s ~/.xdg-runtime-mío/emacs/ server 

(lo hice porque veo que lo busca ahí. Pero lo busca tras fallar, no antes).

Esto sí que va pero no me gusta:

ln -s ~/.xdg-runtime-mío/emacs/ /tmp/emacs1000

De momento cambio invocaciones.

∴ Al final lo arreglaron, y mi problema era que estaba usando emacsclient vieja. Ya no me hace falta lo de /tmp/emacs1000

Tenía dos pruebas.html abiertos, uno de ellos viene de pruebas.org. Reexporto un trozo de este org, y se culega cada vez, con pila de decamiles.

Lisp Backtrace: "Automatic GC" (0x0) "file-name-nondirectory" (0x43cf7658) "uniquify-get-proposed-name" (0x43cf7990) "uniquify-rationalize-conflicting-sublist" (0x43cf7c58) "uniquify-rationalize-a-list" (0x43cf7ea8) "uniquify-rationalize-conflicting-sublist" (0x43cf8188) "uniquify-rationalize-a-list" (0x43cf83d8) "uniquify-rationalize" (0x43cf8768) "uniquify-rationalize-file-buffer-names" (0x43cf8a88) "uniquify–rename-buffer-advice" (0x43cf8c88) "apply" (0x43cf8d88) "rename-buffer" (0x43cf8fa0) "set-visited-file-name" (0x43cf9300) "write-file" (0x43cf95a0) "org-export-to-file" (0x43cf9a08) "org-html-export-to-html" (0x43cf9c50) "org-export-dispatch" (0x43cf9fa0) "funcall-interactively" (0x43cf9f98) "call-interactively" (0x43cfa2c0) "command-execute" (0x43cfa558)

Otra vez, meses más tarde, abriendo varios README.md (que iban quedando README.md<1>, README.md<2> etc.:

"directory-file-name" (0x25e00b08) "uniquify-get-proposed-name" (0x25e00f20) "uniquify-rationalize" (0x25e01378) "uniquify-rationalize-file-buffer-names" (0x25e01788) "uniquify–create-file-buffer-advice" (0x25e01b50) "apply" (0x25e01b48) "create-file-buffer" (0x25e01e68) "find-file-noselect" (0x25e02408) "view-file" (0x25e02758) "dired-view-file" (0x25e02be0) "funcall-interactively" (0x25e02bd8) "call-interactively" (0x25e02cf0) "command-execute" (0x25e03068)

Para salir del paso: M-x toggle-uniquify-buffer-names

• Parece que se ha corregido con el emacsclient nuevo (es que estaba usando uno desfasado).
• creo que es que alguien me la redefine
• ∴ por lo visto es el helm-git-grep.elc original (el .elc). Borrarlo
• añado pitidos para ver dónde pasa cada cosa

• Debugger entered--Lisp error: (error "No buffer named *helm*")
    helm-get-current-source()
    helm-attr(base-directory)
    (let ((it (helm-attr 'base-directory))) (if it (let ((default-directory it)) (apply 'start-process "git-grep-process" nil "git" (helm-git-grep-args))) 'nil))
    helm-git-grep-process()
    funcall(helm-git-grep-process)
    do-after-load-evaluation("/home/dc/.emacs.d/elpa/helm-git-grep-20170614.1411...")
    load-with-code-conversion("/home/dc/.emacs.d/elpa/helm-git-grep-20170614.1411..." "/home/dc/.emacs.d/elpa/helm-git-grep-20170614.1411..." nil t)
    command-execute(helm-git-grep)
  
  

• y es que mi defun para redefinir esa función no está teniendo efecto. ¿Por qué? Estoy cansándome de que cosas tan básicas no funcionen

• aaaaaah, ya falla el eval-after-load

  Debugger entered–Lisp error: (error "No buffer named helm") helm-get-current-source() helm-attr(base-directory) (let ((it (helm-attr 'base-directory))) (if it (let* ((default-directory it) (handler (find-file-name-handler (directory-file-name default-directory) 'make-process))) (make-process :name "git-grep-process" :buffer "búfpro3" :command (append '("git") (helm-git-grep-args)) :file-handler handler)) 'nil)) (helm-aif (helm-attr 'base-directory) (let* ((default-directory it) (handler (find-file-name-handler (directory-file-name default-directory) 'make-process))) (make-process :name "git-grep-process" :buffer "búfpro3" :command (append '("git") (helm-git-grep-args)) :file-handler handler)) 'nil) helm-git-grep-process() eval-after-load("helm-git-grep" helm-git-grep-process) elisp–eval-last-sexp(nil)

• esto en versión compilada, GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2020-09-16
• hace pocos meses no pasaba

• "Automatic GC" (0x0) "garbage-collect" (0x3833bcc0) "semantic-fetch-tags" (0x3833c0d0) "semantic-idle-scheduler-refresh-tags" (0x3833c480) "semantic-idle-core-handler" (0x3833ca70) "semantic-idle-scheduler-function" (0x3833cea0) "apply" (0x3833ce98) "timer-event-handler" (0x3833d228)

• tenía sólo 196 búfers abiertos: org y 4 python y nada más
• ∴ esperar (y C-g) es efectivo, y lo recupero

• en alloc.c, está ejecutando esto, y se pasa mucho rato en sweep_conses, luego consigue avanzar

  * Sweep: find all structures not marked, and free them. * static void gc_sweep (void) { sweep_strings (); check_string_bytes (!noninteractive); sweep_conses (); sweep_floats (); sweep_intervals (); sweep_symbols (); sweep_buffers (); sweep_vectors (); pdumper_clear_marks (); check_string_bytes (!noninteractive); }

• además me ha pasado que (ẽ al hacer „fetch“ en magit de emacs) empieza a consumir mucha memoria, >10 Gb
• [X]

  probar a ejecutarlo con límite de memoria

  ulimit -v 5000123; demacs # emacs -Q
  

  • lo pongo en demacs
  • ayuda

• está iterando continuamente en file:///w/emacs/src/alloc.c#org3538176

  while (*tem) { if (*tem >= (struct ablock *) abase && *tem < atop) { i++; *tem = (*tem)->x.next_free; }

  • eso es lisp_align_free
• quizás el pasarse rato en sweep_conses es razonable, y el problema está en haber consumido tanta memoria. O sea, quizás el problema es una fuga de memoria

hint: Waiting for your editor to close the file… Waiting for Emacs… ERROR: Wrong number of arguments: (1 . 4), 5 error: There was a problem with the editor 'opt/dc/emacs/bin/emacsclient –socket-name=/home/dc.xdg-runtime-m\ío/emacs/server'. Please supply the message using either -m or -F option.

• quizás es por: .git/hooks/pre-commit ← no creo, no ha cambiado

• Debugger entered–Lisp error: (wrong-number-of-arguments (1 . 4) 5) server-switch-buffer–with-editor-server-window-alist(#f(compiled-function (&optional next-buffer killed-one filepos this-frame-only) "Switch to another buffer, preferably one that has a client. NEXT-BUFFER is a suggestion; if it is a live buffer, use it.-ONE is t in a recursive call if we have already killed one-file server buffer. This means we should avoid the final\"switch to some other buffer\" since we've already effectively that. specifies a new buffer position for NEXT-BUFFER, if we NEXT-BUFFER in an existing window. If non-nil, it should a cons cell (LINENUMBER . COLUMNNUMBER)." #<bytecode 0x43092dd55890222>) #<buffer COMMIT_EDITMSG> nil nil nil) […] server-execute-continuation(#<process server <55>>) server-process-filter(#<process server <55>> "-dir home/dc/opencraft/edx-platform -current-fra…")

• es por file:~/.emacs.d/elpa/with-editor-20191024.1905/with-editor.el
  • lo actualizo

• <28.m04.2022> compilé (GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2022-04-28) y se estropeó esta tecla
• produzco el número apretando „3“ y „Enter“ a la vez. Entiendo que esto es algo poco común: aparte de esa extraña elección de teclas que sólo hago yo, está el añadido de que tanto el „3“ como el „Enter“ son para mí modificadores, que no escriben nada sino que son para producir otras letras. Probablemente Emacs ha decidido que „un modificador + otro modificador, apretados a la vez, no pueden producir ningún signo“. En realidad sí que pueden, pues cuando aprieto „3“, el „Enter“ deja de ser un modificador. Esto me va en todos los demás programas, durante muchos años
• no encuentro eso de hacer que emacs me diga la tecla que ha leído; ẽ ahora me dice que ha visto „á“ en vez de „translated frorm AltGr+a“ o algo así
  • aún lo veo en lisp/help.el, en help-key-description, pero no sé lo que hace aún
  • (help–read-key-sequence 'no-mouse-movement) ← no me lo detecta
  • (read-key-sequence "Describe the following key, mouse click, or menu item: " nil nil 'can-return-switch-frame) ← no me la detecta
  • [BROKEN LINK: No match for fuzzy expression: DEFUN ("read-key-sequence", Fread_key_sequence, Sread_key_sequence, 1, 5, 0,]
• [X] biseccionar para encontrar dónde se estropeó → ∴ es 15910e5da3
  • sospecho de:
    • bbbb47704f „Fix detection of modifier keys on XInput 2“, <08.m03.2022>. Pero no
    • 0a9c8855b0 „Don't decode text within XIM callbacks or handle_one_xevent“, <16.m02.2022>
    • f1d535da1e „Decode keyboard input as latin-1 whenever appropriate“ etc. <16.m02.2022>
  • la de <28.m04.2022> fallaba
  • probaré ec464789df, de <02.m04.2022>

    • no compila

      Loading window (source)… Loading /w/emacs/lisp/files.el (source)…

      Error: void-function (string-lines) mapbacktrace((closure (t) (evald func args _flags) (let ((args args)) (if evald (progn (princ " ") (prin1 func) (princ "(")) (progn (princ " (") (setq args (cons func args)))) (if args (while (progn (prin1 (car args)) (setq args (cdr args))) (princ " "))) (princ ")

  • pruebo f2047fdca4, de <22.m03.2022>, compila bien. Pero aún falla; no hay siete
  • pruebo b1c6d5f2b7, de <16.m03.2022>, aún falla
  • pruebo d0d7765f23, de <08.m03.2022>, justo antes de bbbb47704f. También falla
  • pruebo 6410b6ada0, de <23.m02.2022>. También falla
  • pruebo eb0680bd57, de <16.m02.2022>. Falla y ¿me detecta menos teclas? ← no, quizas es por teclado „frío“
    • curioso, luego la probé otra vez y no fallaba
  • pruebo a6df8f9f99, de <10.m02.2022>, sí que va el 7
  • limito a una más cercana: 68b3273214, de <13.m02.2022>, sí que va
  • limito a una más cercana: d43ca38556, de <14.m02.2022>
  • limito a una más cercana: 2d573afecb, de <15.m02.2022>, sí que va
  • así que de 2d573afecb..eb0680bd57 se estropeó
  • pruebo en a654e37349 (viene tras 2 entradas de teclado, sospechosas) (supongo que ya fallará) ← pero no falla
  • así que de a654e37349..eb0680bd57 se estropeó
  • pruebo 3b7d55a801 „Speed up count_size_as_multibyte“, sí que va
  • así que de 3b7d55a801..eb0680bd57 se estropeó. Extraño
  • pruebo e389da74d5, „Fix recent change in xwidget.c“. Aquí me pierdo pues todo esto parece funcionar (eb0680bd57 también). Quizás mal probado
  • pruebo otra vez: (empiezo de nuevo): 86ebc88cd8 va, 8a7df412a6 falla, ecaedf2117 va, 51e51ce2df va.
  • otro intento: 7a699e79f6 va, y alguno de los posteriores cercanos lo rompe
  • ∴ es por 15910e5da3 | Ignore modifier keys early when handling X key press events junto con d7fc7bdd81 | master Fix typo in last change, de <20.m02.2022>
• parece que 15910e5da3 está algo relacionado con pgtk, ver ahí notas
• veo algo relacionado: https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg00761.html
• enviar fallo
  • por ahora no tengo tiempo de meterme en esto de pgtk/xinput2 etc. El desarrollo de Emacs necesita bastante tiempo
  • y mi caso es muy extraño y específico y difícil de replicar
• [X] encuentro solución parche para mi configuración

  • „simplemente“ comentar esta línea (que añadí yo mismo) en mi .xkb:

    modifier_map Mod4 { <RTRN> };
    

  • no creo que estuviera mal esa línea, pues el RTRN es un modificador (es mi AltGr), así que no sé por qué tengo que esconderlo. Sigo creyendo que el problema está en Emacs (es lo que se estropeó)
  • ∴ comentándolo, va
• esquives ← ya no me hacen falta tras la solución del Mod4
  • ¿volver a versión anterior? (de hace ~2 meses)
  • quizás buscarme otra combinación de teclas para poner número siete
  • ¿quizás evitar mencionarlo? Ya hay mucha gente hablando del siete
  • el „seis coma nueve periódico“ es lo mismo
  • apretar 6 y 8 a la vez… y que ponga la media… Lo malo es que aún necesito apretar la tecla etiquetada „3“ para conseguir el 6 y el 8… Qué lío
  • puedo usar wmii para capturar las teclas que emacs no ve, y hacer que envíe un „7“
  • M-x siete, ver mi .emacs

• (gdb) finish Run till exit from #0 syntax_property_entry (c=c@entry=115, via_property=true) at syntax.h:105 syntax_property_with_flags (via_property=true, c=115) at syntax.h:121 121 return CONSP (ent) ? XFIXNUM (XCAR (ent)) : Swhitespace; Value returned is $1 = (struct Lisp_X *) 0x7f73aa94eceb (gdb) finish Run till exit from #0 syntax_property_with_flags (via_property=true, c=115) at syntax.h:121 scan_sexps_forward (state=state@entry=0x7ffe67bea310, from=<optimized out>, from_byte=<optimized out>, end=end@entry=19427, targetdepth=targetdepth@entry=-9223372036854775808, stopbefore=stopbefore@entry=false, commentstop=0) at syntax.c:3410 3410 c_code = SYNTAX (c); (gdb) finish Run till exit from #0 scan_sexps_forward (state=state@entry=0x7ffe67bea310, from=<optimized out>, from_byte=<optimized out>, end=end@entry=19427, targetdepth=targetdepth@entry=-9223372036854775808, stopbefore=stopbefore@entry=false, commentstop=0) at syntax.c:3410 Fparse_partial_sexp (from=<optimized out>, to=<optimized out>, targetdepth=<optimized out>, stopbefore=0x0, oldstate=<optimized out>, commentstop=0x0) at syntax.c:3610 3610 SET_PT_BOTH (state.location, state.location_byte); (gdb) finish Run till exit from #0 Fparse_partial_sexp (from=<optimized out>, to=<optimized out>, targetdepth=<optimized out>, stopbefore=0x0, oldstate=<optimized out>, commentstop=0x0) at syntax.c:3610 0x000055bb7c3d4eab in exec_byte_code (fun=0x2, args_template=94263985235299, nargs=5, args=0x7f73aa1f1730) at bytecode.c:809 809 val = funcall_subr (XSUBR (call_fun), call_nargs, call_args); Value returned is $2 = (struct Lisp_X *) 0x55bb8b5ae563 (gdb) finish Run till exit from #0 0x000055bb7c3d4eab in exec_byte_code (fun=0x2, args_template=94263985235299, nargs=5, args=0x7f73aa1f1730) at bytecode.c:809

• tuve que matarlo. Luego cada vez que se abría volvía a pasar
• GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2022-05-04

• esto en feature-mode

• esto en „GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2022-12-28“. Pero hace unos días iba

• ■ Warning (magit): "Magit cannot find Git on host #(\"/su:so@ocrb:\" 1 3 (helm-ff-file t helm-ff-dir t) 4 6 (helm-ff-file t helm-ff-dir t) 7 11 (helm-ff-file t helm-ff-dir t)).

  Check the value of `magit-remote-git-executable' using `magit-debug-git-executable' and consult the info node `(tramp)Remote programs'."

  Running "git –version" failed with output:

  bin/sh: 374: cd: can't cd to ~/billing

• No sé qué es el número; va aumentando:

  /bin/sh: 404: cd: can't cd to ~/billing/
  /bin/sh: 410: cd: can't cd to ~/billing/
  /bin/sh: 416: cd: can't cd to ~/billing/
  /bin/sh: 422: cd: can't cd to ~/billing/
  /bin/sh: 428: cd: can't cd to ~/billing/
  /bin/sh: 434: cd: can't cd to ~/billing/
  /bin/sh: 440: cd: can't cd to ~/billing/
  

  • no es ID de proceso pues no le afectan otros procesos que creo
• si creo como dc un ~/billing, sigue pasando
• pasé a „GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2022-11-18“, y ¡¡aún pasa!! No entiendo porqué. Antes no pasaba, con ese mismo emacs

• veo que hace

  timer_settime(0, TIMER_ABSTIME, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=1672647664, tv_nsec=341572062}}, NULL)                                                         = 0
  timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=1672647664, tv_nsec=341572062}}, NULL)                                                   = 0
  write(17, "( cd \\~/billing/ && env INSIDE_EMACS\\=30.0.50\\,magit\\,tramp\\:2.6.0-pre git --no-"..., 279)                                                                          = 279
  timer_settime(0, TIMER_ABSTIME, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=0, tv_nsec=0}}, NULL)                                                                          = 0
  timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={tv_sec=0, tv_nsec=0}, it_value={tv_sec=0, tv_nsec=0}}, NULL)                                                                    = 0
  alarm(0)                                                                                                                                                                            = 0
  

• ∴ ¿será que intenta entrar a directorio llamado ~/billing, con el ~ literalmente?

  • pruebo

    so@ocrb:~$ mkdir -p \~/billing so@ocrb:~$

  • sí, es eso. El error cambia tras es
• me está volviendo loco. Está yendo a directorios extraños tipo /su:so@ocrb:~/. y luego quejándose con /bin/sh: 477: cd: can't cd to ~/./
• aún no sé si el problema es tramp o magit. tramp lo abre bien
  • eshell funciona bien, ẽ /su:so@ocrb:~/billing $ ls va bien

• instalo magit nuevo

  Version: 20221208.1848

  Other versions: 20221101.2214 (installed), 3.3.0 (nongnu).

  • ∴ no hizo falta

• ∴ por cierto, el primer fallo fue

  Debugger entered–Lisp error: (cl-assertion-failed ((equal (directory-file-name dirname) dirname) nil)) cl–assertion-failed((equal (directory-file-name dirname) dirname)) uniquify-get-proposed-name("" #("/su:so@ocrb:~/" 7 11 (tramp-default t)) nil #("/su:so@ocrb:~/" 7 11 (tramp-default t))) uniquify-rationalize((#s(uniquify-item :base "" :dirname #("su:so@ocrb:~" 7 11 (tramp-default t)) :buffer #<buffer <3>> :proposed nil :original-dirname #("/su:so@ocrb:~/" 7 11 (tramp-default t))))) uniquify-rationalize-file-buffer-names("" #("su:so@ocrb:" 7 11 (tramp-default t)) #<buffer <3>>) uniquify--create-file-buffer-advice(#<buffer ~<3>> #("/su:so@ocrb:" 7 11 (tramp-default t))) create-file-buffer(#("/su:so@ocrb:~" 7 11 (tramp-default t))) dired-internal-noselect(#("/su:so@ocrb:~" 7 11 (tramp-default t)) nil) dired-noselect(#("su:so@ocrb:~" 7 11 (tramp-default t))) run-hook-with-args-until-success(dired-noselect #("su:so@ocrb:~" 7 11 (tramp-default t))) find-file-noselect("su:so@:/home/so" nil nil nil)

  • esto es la causa. Me estaba creando búfers llamados ~ y cosas raras ~<2> etc., y creo que por esto se liaba cuando llegaba uno nuevo por tramp
  • ∴ cerré esos búfers, reintenté y ya fue

• mandado <24.m05.2024 20:49>
• https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-05/msg01548.html
• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71176

• para reproducir:

  for j in `seq 30`; do for i in `seq 10`; do urxvt -e emacsclient '-nw' '-e' '(dired "~")' &; done; sleep 1 && killall emacsclient; done
  

• descubro

  The minimal .emacs needed to reproduce it has these 2 lines:

  (setq garbage-collection-messages t) (set-face-foreground 'default "#bbb")

  If I comment any of them, it doesn't crash.

  So it seems it's GC-related. When GC runs while some face is being set up AND the GC tries to display a message (by using that face?), it crashes.

• [X] ya lo arregló Eli, en 74b8043e60d, „Prevent crashes due to redisplay while realizing the default face“

• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71177

• pasa con -Q
• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71223
• el nuevo parche de Stefan va bien

  • metido en:

    0d7d835902d server.el: Avoid nested runs of process filters (bug#71223)
    

• pasa con -Q
• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71224
• pude 2 veces
• grabé core dump
• tras el parche de Stefan para 71223, aún pasa. Aunque le causé yo el max-lisp-eval-depth bajo; quizás eso ayudó

• añado, sin saber mucho lo que hago

  fprintf(stderr, "Allocated frame glyph matrix, window %s, frame %s, x/y %d/%d\n", window, f, x, y);
  

• file:///w/emacs/src/term.c#orgb4941aa

• no mando esto, no hace falta ya. Ver lo que mandé a Eli, es mucho más sencillo

  I could reproduce it but only once! with a combination of this : emacs –fg-daemon -Q (setq max-lisp-eval-depth 100) ;; not sure how important (setq garbage-collection-messages t) ;; not sure if needed (defun recurse () (recurse)) (recurse) ;; not sure if needed I see the Lisp backtrace inside Emacs. I don't close it with "q". Then: for j in `seq 100`; do for i in `seq 10`; do urxvt -e emacsclient '-nw' '-e' '(dired "~")' &; done; sleep 3 && killall emacsclient; done And wait around 15 seconds. I think then I manually opened still another frame; not sure.

  Then I saw:

  Process server <441> not running: connection broken by remote peer

  Lisp nesting exceeds ‘max-lisp-eval-depth’

  Program received signal SIGSEGV, Segmentation fault. 0x00005555555ac8a3 in init_iterator (it=0x7ffffffe5440, w=0x5555562cb760, charpos=-1, bytepos=-1, row=0x0, base_face_id=MODE_LINE_ACTIVE_FACE_ID) at xdisp.c:3225 3225 row = MATRIX_MODE_LINE_ROW (w->desired_matrix); (gdb) bt #0 0x00005555555ac8a3 in init_iterator (it=0x7ffffffe5440, w=0x5555562cb760, charpos=-1, bytepos=-1, row=0x0, base_face_id=MODE_LINE_ACTIVE_FACE_ID) at xdisp.c:3225 #1 0x00005555555ebf64 in display_mode_line (w=0x5555562cb760, face_id=MODE_LINE_ACTIVE_FACE_ID, format=XIL(0x7ffff1d38143)) at xdisp.c:27366 #2 0x00005555555a913c in pos_visible_p (w=0x5555562cb760, charpos=-1, x=0x7ffffffeb74c, y=0x7ffffffeb748, rtop=0x7ffffffeb75c, rbot=0x7ffffffeb758, rowh=0x7ffffffeb754, vpos=0x7ffffffeb750) at xdisp.c:1732 #3 0x0000555555606480 in Fpos_visible_in_window_p (pos=XIL(0x30), window=XIL(0), partially=XIL(0x30)) at window.c:2018 #4 0x0000555555770ab5 in funcall_subr (subr=0x555555eb3500 <Spos_visible_in_window_p>, numargs=3, args=0x7ffff0dff4a0) at eval.c:3165 […] #436 0x000055555568fc21 in recursive_edit_1 () at keyboard.c:754 #437 0x000055555568fe4d in Frecursive_edit () at keyboard.c:837 #438 0x000055555568b8b4 in main (argc=3, argv=0x7fffffffdf08) at emacs.c:2625 (gdb) (gdb) xbacktrace "pos-visible-in-window-p" (0xf0dff4a0) "line-move-partial" (0xf0dff3a8) "line-move" (0xf0dff338) "next-line" (0xfffebfb0) "funcall-interactively" (0xfffebfa8) "call-interactively" (0xf0dff2a0) "command-execute" (0xfffecbb8) "recursive-edit" (0xfffed000) "debug" (0xf0dff220) "eval-expression–debug" (0xfffed708) "recurse" (0xfffeda70) "recurse" (0xfffedcf0) "recurse" (0xfffedf70) "recurse" (0xfffee1f0)

• ∴ así lo reproduzco:

  After a few hours of debugging and learning. I found a very simple formula to produce the SIGSEGV. No GC involved, and no automated window opening/resizing. To reproduce it:

  emacs –fg-daemon -Q emacsclient -c

  Open a buffer with this code in it: (defun recurse () (recurse)) (recurse)

  And eval the defun. Don't call (recurse) yet.

  Do: M-x debug This opens the backtrace window. Use C-x o to go away from the backtrace window and back to that buffer with the Lisp code. Now eval (with C-x C-e) the call to (recurse) You get a message in the minibuffer: cl-prin1, excessive-lisp-nesting, and the backtrace window is updated. Don't close that backtrace window.

  Open a new frame, as before: emacsclient -c The daemon crashes with SIGSEGV.

• luego no puedo abrir emacsclient
  • 9cd182dae88, va bien
  • bef514de4d3: va bien. No me lo esperaba. ∴ Quizás es recompilar lo que me lo ha arreglado
  • 19806248167: también va bien

• 71473
• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71475
• corregido

• file:///w/emacs/src/keyboard.c#org782f3de
• 71474
• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71474
• no lo corregirán (aún). No me gusta tener que vivir con comandos que se sabe que pueden petar el servidor. Pero tendré que acostumbrarme

• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71243

• interesante el

  (gdb) frame 1 #1 0x0000555555668663 in realize_face (cache=0x555557a04a40, attrs=0x7fffffba6500, former_face_id=13) at xfaces.c:6060 6060 uncache_face (cache, former_face); (gdb) list 6055 6056 if (former_face_id >= 0 && cache->used > former_face_id) 6057 { 6058 * Remove the former face. * 6059 struct face *former_face = cache->faces_by_id[former_face_id]; 6060 uncache_face (cache, former_face); 6061 free_realized_face (cache->f, former_face); 6062 SET_FRAME_GARBAGED (cache->f); 6063 } 6064 (gdb) p former_face $5 = (struct face *) 0x0 (gdb) p former_face_id $6 = 13 (gdb) p cache $7 = (struct face_cache *) 0x555557a04a40 (gdb) p cache->used $8 = 19 (gdb) p cache->faces_by_id[19] $9 = (struct face *) 0x0 (gdb) p cache->faces_by_id[18] $10 = (struct face *) 0x5555569d45c0 (gdb) p cache->faces_by_id[17] $11 = (struct face *) 0x5555572c26d0 (gdb) p cache->faces_by_id[16] $12 = (struct face *) 0x5555569825f0 (gdb) p cache->faces_by_id[15] $13 = (struct face *) 0x555556c11db0 (gdb) p cache->faces_by_id[14] $14 = (struct face *) 0x5555575bc180 (gdb) p cache->faces_by_id[13] $15 = (struct face *) 0x0 (gdb) p cache->faces_by_id[12] $16 = (struct face *) 0x555557490a10 (gdb) p cache->faces_by_id[11] $17 = (struct face *) 0x5555569c0da0 (gdb) p cache->faces_by_id[10] $18 = (struct face *) 0x55555693fab0 (gdb) p cache->faces_by_id[9] $19 = (struct face *) 0x555557607cd0 (gdb)

• lo arregló Eli

• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71274

• le añado

  fprintf(stderr, "At point 1, w->window_end_valid is %d\n", w->window_end_valid);
  

  • útil, veo cosas como

    Allocated frame glyph matrix, window (null), frame à
    , x/y 0/50
    Allocated frame glyph matrix, window (null), frame à
    , x/y 0/50
    Allocated frame glyph matrix, window (null), frame à
    , x/y 0/50
    Garbage collecting...
    When done with this frame, type C-x 5 0
    Allocated frame glyph matrix, window (null), frame à
    , x/y 0/50
    At point 1, w->window_end_valid is 1
    At point 2, w->window_end_valid is 1
    At point 3, w->window_end_valid is 1
    At point 1, w->window_end_valid is 1
    At point 2, w->window_end_valid is 1
    At point 3, w->window_end_valid is 1
    At point 4, w->window_end_valid is 1
    At point 5, w->window_end_valid is 1
    At point 1, w->window_end_valid is 1
    At point 2, w->window_end_valid is 1
    At point 3, w->window_end_valid is 1
    At point 1, w->window_end_valid is 1
    At point 2, w->window_end_valid is 1
    At point 3, w->window_end_valid is 1
    At point 1, w->window_end_valid is 1
    At point 2, w->window_end_valid is 1
    At point 3, w->window_end_valid is 1
    Allocated frame glyph matrix, window (null), frame à
    , x/y 0/50
    

  • patrones raros

    • tras abrir wanderlust y ponerlo en otro lado. Normalmente hace 12345123123, sólo ahora llega a puntos nuevos

      Allocated frame glyph matrix, window (null), frame à , x/y 0/52 At point 1, w->window_end_valid is 1 At point 2, w->window_end_valid is 1 At point 3, w->window_end_valid is 1 At point 4, w->window_end_valid is 1 At point 5, w->window_end_valid is 1 At point 6, w->window_end_valid is 1 At point 7, w->window_end_valid is 1 At point 8, w->window_end_valid is 1 At point 9, w->window_end_valid is 1 At point 11, w->window_end_valid is 1 At point 12, w->window_end_valid is 1 At point 1, w->window_end_valid is 1 At point 2, w->window_end_valid is 1 At point 3, w->window_end_valid is 1 At point 4, w->window_end_valid is 1 At point 5, w->window_end_valid is 1 At point 1, w->window_end_valid is 1 At point 2, w->window_end_valid is 1 At point 3, w->window_end_valid is 1

• apunto sobre try_window_id

• lo vi fallar

  At point 7, w->window_end_valid is 1 At point 8, w->window_end_valid is 1 At point 9, w->window_end_valid is 0 At point 11, w->window_end_valid is 0

  —

  At point 8.3, w->window_end_valid is 1 At point 8.4, w->window_end_valid is 0 At point 9, w->window_end_valid is 0 At point 11, w->window_end_valid is 0

  ---

  At point ccc1, w->window_end_valid is 1 At point ccc1, charpos 20, bytepos 20 At point ccc1.5, w->window_end_valid is 1 At point ccc1.5, charpos 20, bytepos 20 At point ddd0, w->window_end_valid is 1 At point ddd1, w->window_end_valid is 1 At point ddd2, w->window_end_valid is 0 At point ddd3, w->window_end_valid is 0

• más cosas que no digo aún

  It happens inside: init_iterator (it, w, charpos, bytepos, NULL, DEFAULT_FACE_ID);

  ---

  I also see that try_window_id is called many times in succession for some reason (with my ~/.emacs which includes timers, font-lock etc). Maybe the first call reaches this point and leaves things in a bad state for the other run.

  Now, after reading that comment about "some package" I'm growing suspicious of Wanderlust and its font-lock

  Is it possible that something external changed while running those lines, e.g. a window manager focus change, or moving the mouse, or holding or releasing a key. My Emacs is very slow now (-O0, glyph checks), so it makes race conditions more likely to happen :-)

  I saw this bug 2 times yesterday, both times unexpectedly, e.g. while just typing in a buffer. No scim involved, no Python mode. One of them I went to try_window_id and ran call dump_glyph_matrix (w->current_matrix, 1), and I saw that now it's Wanderlust's "Summary" window listing my e-mails. I wasn't even looking at it. After my debug fprintfs I see that the try_window_id is also called every minute (by a timer?) so this may be the cause.

  > Any ideas, even crazy ones, are welcome.

  1. Maybe it's because I have (setq garbage-collection-messages t), which interrupted the code somewhere in the middle and changed the display. I don't know if GC can do that.
  2. More crazy: maybe Emacs lost (or my window manager didn't send) some notifications about changes in window size or configuration, and therefore the window changed without Emacs realizing it. I mention this because I know TTY Emacs has a certain redisplay problem. Since I started using it a few weeks ago, I see that sometimes it doesn't detect window changes, and it only refreshes when I press a key or move the mouse. It happens when I focus a frame just after having killed another frame. This not-noticing-window-changes may be a sign that here too an outside change wasn't seen by Emacs. It may also be a bug in my window manager (wmii) since I know it has some bugs related to focusing windows. I can reliably reproduce this non-refresh bug but I'll need some more time to document it and report it (I'm reporting too many bugs…). While researching it I found still another one (when will it end?), …………………
  3. Another crazy idea: maybe it's actually ok to have w->window_end_valid == false? That is, it's the assert what's wrong, not the rest of the code. I mention this because while exploring my variables in a working Emacs, I saw some of them being false. (Note that I don't know what I'm looking at):

  (gdb) frame 9 #9 0x00005555556a67ff in read_key_sequence (keybuf=0x7fffffffd8f0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false, disable_text_conversion_p=false) at keyboard.c:10728 10728 key = read_char (prevent_redisplay ? -2 : NILP (prompt), (gdb) p ((struct window *)interrupted_frame->root_window)->window_end_valid $12 = false

  ---

  It's further below, i.e. after the call to find_first_unchanged_at_end_row. But maybe the same argument holds, and this "giving up on optimization" must be done earlier? (Actually I would prefer doing it in a better way, i.e. not silently becoming slower as a punishment, but showing a warning message).

  -—

  I should try setting a breakpoint that only activates in the particular case I'm looking for. This is still hard to reproduce; it just happens some times a week.

• sobre el init_iterator, ver ahí
• creo que he de parar al inicio de init_iterator, y ahí añadir watchpoint para vigilar w->window_end_valid, y avisarme justo en punto en que pase a 0
• parece que arreglado

• lo mando a https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71343
• C-l
• ¿SIGWINCH?
• es debido a abrir un marco nuevo mover el foco a un marco distinto. Eso congela los anteriores; congela el tiempo (ẽ para tetris) y las actualizaciones
  • no pasa si abro urxvt (y luego la aparto)
  • ¿quiero congelar el tiempo (ẽ tetris) en marcos no enfocados? ¿o hacer que sigan corriendo?
    • me va bien congelarlo, pero al menos me gustaría que minibúfer etc. se actualicen ante SIGWINCH
  • en general pasa con las „ventanas“ también: abandonar ventana de tetris lo congela
• reproducir
  • forma de reproducirlo: abrir varios marcos uno tras otro. Luego cerrarlos. La línea de modo pasa de ser 1 línea de alto a ser 2. Cuando toco tecla (o muevo ratón mínimamente) se refresca y es 1
  • cuando pasa esto (no se ha actualizado ventana), puedo luego cambiar el tamaño de ventana cuanto quiera, y sigue sin actualizarse; sigue sin arreglarse solo. Sólo se arreglará solo al apretar una tecla luega
  • por tanto ¿está ignorando los SIGWINCH?
  • forma ~mejor de verlo: poner tetris. Las piezas dejan de caer, pero si muevo el ratón sigue el juego
  • ∴ una más fácil:
    1. poner 1 emacsclient a la izq, una terminal a la derecha
    2. puedo cambiar tamaño (izq./der.) de ventana. Va bien
    3. moverme a la parte derecha de pantalla
    4. abrir emacsclient (se abre a la derecha)
    5. cerrarlo
    6. moverme a la parte izquierda
    7. cambiar tamaño (izq./der.) de ventana. Ya no va
• dicho de otra forma: al apuntar con wmii a un marco, aún no le ha dado el foco (emacs aún no se ha enterado de que lo he apuntado). Si pito tras cada post-command-hook, no pita. Sólo al mover el ratón para apuntar, o al tocar tecla, se da cuenta de que lo apuntan (y pita, dos veces)
• todo esto (no se entera de que lo han enfocado, no se entera de que lo han desenfocado) apunta a problemas debido a wmii
  • probar con otro gdv
• me pasa desde que uso emacs -nw
• ¿pasa en -Q? Sí
• ¿puedo simularlo? (xdotool etc). Sí

• no digo

  Making a TTY wider creates more space: lines can be longer now. Isn't this considered a change in the buffer text? The buffer text isn't changing due to edits. I may not have use the right word (redisplay); what I mean is that a SIGWINCH should cause a refresh of the window, to adapt things to the new size (minibuffer, scroll bars, line length, …). Right now it's not happening: in this particular case (emacsclient, immediately after closing a frame) Emacs sees the SIGWINCH but doesn't refresh the contents. In all other cases (including non-daemon emacs) it works.

  –

  maybe X always tells the terminal that it got focus, and the X terminal always relays the signal to the running program, independently of which program it is. But maybe it doesn't work that way. I'm just imagining possibilities, with no knowledge of X, so please discard the ideas that don't make sense.

  –

  Because there may be no other way to detect whether they need a redisplay, or which ones need it. I'm thinking about cases, like in a tiling X window manager in which closing a TTY frame will affect the size of the other frames. Anyway, redisplaying everything „just in case“ feels bad; I hope there are ways to detect.

  — There's still this other scenario in which I open 2 frames and close the 2nd one and the focus goes to the 1st one without Emacs realizing (until I press any key), but there's nothing wrong with that; the frame wouldn't require any repainting/refreshing because the frame size doesn't change. But the moment the frame size changes, then I expect a repainting.

  — This is important now that there are ways to see many TTY frames at the same time (e.g. through X). Maybe in the past we expected to only Although there may be reasons to do so.

  By ensuring that Emacs repaints the frame contents after the frame size changed, it would already improve the situation. I think we don't need to think about X focus change; we're dealing with TTYs anyway.

  –

  Since I might have used the wrong terms, let me rephrase (redisplay→redraw): I'm concerned about preventing cases in which the lack of redraw_frame can cause larger problems like garbled text.

  I haven't seen the garbled text lately. When it happened it was continuous and couldn't be fixed by a single action (like pressing C-l). But that's another issue.

  —

  We mentioned X focus, but I think it's not very important. More important is reacting to frame size changes. If we just change focus from one frame to another and forget to repaint the newly focused frame, I expect there will be only very minor differences (e.g. some face used in the minibuffer that changes color depending on whether a frame is active). But if we forget to repaint a frame after resizing it, that's when all the contents may drastically change and it looks bad when no repaint happened at all.

  Eli mentioned: > Emacs switches to reading input from a > different terminal/keyboard when there's actually some input from that > terminal's keyboard.

  My proposal is that it should repaint a frame whenever the frame size changed. Independently of whether there has been recent keyboard input or not. Emacs is able to detect the size change and I don't see why it should „delay the repainting until there's keyboard activity“. I guess it comes from the assumption that users could only use a TTY frame at the same time. But nowadays they can see more than one at the same time, e.g. through X terminals.

  -—

  > > I'm concerned about preventing cases in which the lack of redisplay > > can cause larger problems like mangled text. > > Lack of redisplay cannot possibly produce garbled text because only > displaying something can do that.

  Ok. Then I'm concerned about a badly done redisplay (or frame redraw, which may be triggered via redisplay_internal→clear_garbaged_frame→redraw_frame) which constantly garbles the text, e.g. doesn't clear garbaged frames, doesn't redraw, etc. Anyway that's another bug, and luckily I didn't see garbled text happen recently.

  I agree then that this report (71343) is of minor priority. It's just a very noticeable minor cosmetic issue.

• 719 new_inner_height = (new_native_height (gdb) 722 new_text_height = FRAME_PIXEL_TO_TEXT_HEIGHT (f, new_native_height); (gdb) 723 new_text_lines = new_text_height / unit_height; (gdb) 790 if (CONSP (frame_size_history)) (gdb) 803 if ((XWINDOW (FRAME_ROOT_WINDOW (f))->pixel_top (gdb) info locals unit_width = 1 unit_height = 1 old_native_width = 72 old_native_height = 50 new_native_width = 61 new_native_height = 50 min_inner_width = 2 min_inner_height = 4 r = 0x62100022d130 old_inner_width = 72 old_inner_height = 49 new_inner_width = 61 new_inner_height = 49 old_text_cols = 72 old_text_lines = 49 new_text_cols = 61 new_text_lines = 49 old_text_width = 72 old_text_height = 49 inhibit_horizontal = true inhibit_vertical = true frame = XIL(0x621000181105) (gdb)

  —

  (gdb) list 4934 4929 window_pixel_to_total (r->frame, horflag ? Qt : Qnil); 4930 } 4931 } 4932 } 4933 4934 if (FRAME_HAS_MINIBUF_P (f) && !FRAME_MINIBUF_ONLY_P (f)) 4935 { 4936 m = XWINDOW (mini); 4937 if (horflag) 4938 { (gdb) n 4936 m = XWINDOW (mini); (gdb) 4937 if (horflag) (gdb) 4939 m->total_cols = new_size; (gdb) p m->total_cols $59 = 61 (gdb) p new_size $60 = 72 (gdb)

• ŭ1 es de redraw_frame, ver ahí
  • sospecho de file:///w/emacs/src/xdisp.c#orgaeefff3

• (gdb) adjust_frame_glyphs_for_frame_redisplay (f=0x6210000175b8) at dispnew.c:2092 2092 if (matrix_dim.width != FRAME_TOTAL_COLS (f) (gdb) 2093 || matrix_dim.height != FRAME_TOTAL_LINES (f)) (gdb) 2108 eassert (matrix_dim.width == FRAME_TOTAL_COLS (f) (gdb) 2120 if (display_completed (gdb) p display_completed $62 = true (gdb) n 2121 && !FRAME_GARBAGED_P (f) (gdb) p FRAME_GARBAGED_P (f) $63 = true (gdb)

  (gdb) n 2138 adjust_glyph_matrix (NULL, f->desired_matrix, 0, 0, matrix_dim); (gdb) 2139 adjust_glyph_matrix (NULL, f->current_matrix, 0, 0, matrix_dim); (gdb) 2140 SET_FRAME_GARBAGED (f); (gdb) n 2120 if (display_completed (gdb) 2035 { (gdb) 2156 } (gdb)

  —

  (gdb) frame #0 clear_garbaged_frames () at xdisp.c:13341 13341 redraw_frame (f); (gdb) list xdisp.c:13335 13330 struct frame f = XFRAME (frame); 13331 13332 if (FRAME_REDISPLAY_P (f) && FRAME_GARBAGED_P (f)) 13333 { 13334 if (f->resized_p 13335 / It makes no sense to redraw a non-selected TTY 13336 frame, since that will actually clear the 13337 selected frame, and might leave the selected 13338 frame with corrupted display, if it happens not 13339 to be marked garbaged. */ (gdb) 13340 && !(f != sf && (FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f)))) 13341 redraw_frame (f); 13342 else 13343 clear_current_matrices (f); 13344 13345 #ifdef HAVE_WINDOW_SYSTEM 13346 if (FRAME_WINDOW_P (f) 13347 && FRAME_RIF (f)->clear_under_internal_border) 13348 FRAME_RIF (f)->clear_under_internal_border (f); 13349 #endif (gdb) p f $98 = (struct frame *) 0x6210000175b8 (gdb) p sf $99 = (struct frame *) 0x6210000175b8 (gdb) p FRAME_TERMCAP_P(f) $100 = 1 (gdb)

• lo normal

  Breakpoint 2, adjust_frame_size (f=0x6210000175b8, new_text_width=61, new_text_height=49, inhibit=5, pretend=false, parameter=XIL(0x40e0)) at frame.c:646 646 int unit_width = FRAME_COLUMN_WIDTH (f); (gdb) cont Continuing.

  Breakpoint 3, clear_garbaged_frames () at xdisp.c:13334 13334 if (f->resized_p (gdb) cont Continuing.

  Breakpoint 4, redraw_frame (f=0x6210000175b8) at dispnew.c:3185 3185 eassert (f->glyphs_initialized_p); (gdb) cont Continuing.

  • pero con este fallo

    Breakpoint 2, adjust_frame_size (f=0x6210000175b8, new_text_width=61, new_text_height=49, inhibit=5, pretend=false, parameter=XIL(0x40e0)) at frame.c:646 646 int unit_width = FRAME_COLUMN_WIDTH (f); (gdb) c Continuing.

• ∴ es porque cree que es marco inicial
• por mirar por qué es inicial

• más, no digo

  It seems that under normal Emacs operation, the emacs daemon creates an initial frame which has no output_data->tty. In addition there are non-initial frames, created by make_terminal_frame; one for each frame opened by the user.

  Here's a hypothesis: the problem isn't that the frame being resized was wrongly initialized (i.e. make_terminal_frame didn't run); the problem is that the resizing operation or some previous operation chose the initial frame as the frame to resize, instead of the other, non-initial frame. There were 2 frames: the initial one (which I can't resize because it's invisible to me) and the non-initial one. I resized the non-initial one and Emacs tried to resize the initial one.

• conxterm.core
• mandado <21.m06.2024 13:47>: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71693

• me espero a poder investigarlo más. No tengo tiempo ahora mismo
• mandado <21.m06.2024 13:47>: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71694

• usé:

  -fsanitize=undefined,address,bounds-strict,float-cast-overflow ''
  

  • se supone que undefinde+address no van bien

• quizás mandar

  I opened some frames with urxvt, then others with xterm. I got a few different crashes, including this one.

• ==9677==ERROR: AddressSanitizer: heap-use-after-free on address 0x625000123b30 at pc 0x55555695b2c9 bp 0x7fffffff9900 sp 0x7fffffff98f8 READ of size 1 at 0x625000123b30 thread T0 #0 0x55555695b2c8 in tty_defined_color /w/emacs/src/xfaces.c:1115 #1 0x55555695c2fb in load_color2 /w/emacs/src/xfaces.c:1260

  • resto lo mando por correo
• grabo datos de compilación en ~/n/heap…datos

• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71289

• a decir

  In the meantime, I found a very similar error, it seems that it's due to terminal processing during GC; backtrace below. Not sure if related. I see many bugs with (setq garbage-collection-messages t) in TTY, so I may as well disable it to focus on the more important TTY bugs.

• me pide Eli

  > But sometimes I can't reproduce it at all with this method! > And never could I in emacs -Q

  So maybe you could bisect your init files and find the customization(s) which make the reproduction possible? Because I cannot reproduce any of this here, no matter what I try.

• no digo

  > That hypothesis needs to be explained. Which is why I asked to > investigate what happens when the SIGWINCH handler is called.

  I don't know how to do this; I'll have to find a better way to reproduce this. Right now, I have to constantly resize the window until it randomly crashes, sometimes after a few minutes. That's a lot of SIGWINCH to verify. I'll try to learn more about it and track the variables you mention. Maybe seeing those variables before the crash I can't debug each SIGWINCH operation and I don't know which one is the last one before it fails.

• y ver el 71289v2 de abajo
• [X] ∴ informar del 71289v2 y cerrar éste: 73022

• mandado: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73022
• [X]

  creo que esto siguiendo este comentario

  Right now if I run the C-x 2 and resize scenario, I get this other backtrace with build_frame_matrix_from_leaf_window

  ---

  That's another problem. There seems to be some disconnect, time-wise, in reallocating frame matrices and sub-allocating window matrices from the frame matrices, and the crash happens when the check is done in-between those two.

• en versión de <19.m08.2024> pasa

• 1. open emacs -Q
  2. open ~/.emacs ← just to be able to find the window
  3. EC=$(xdotool search –name '^gdb src/emacs') && echo $EC && while :; do for height_px in `seq 275 -25 10`; do xdotool windowsize $EC $((height_px+5)) $height_px; sleep 0.001; done; for height_px in `seq 1 25 400`; do xdotool windowsize $EC $((height_px+5)) $height_px; sleep 0.1; done; sleep 0.3 && done
  4. While it's being resized in a loop, use C-x 2 to do a top/bottom window split
  5. It crashes

• [X] por informar, quizás aparte: 73022

• por cierto, traduzco con alias de struct cm:

  p (tty)->Wcm->cm_curY p (tty)->Wcm->cm_rows-1 p (tty)->Wcm->cm_curY < (tty)->Wcm->cm_rows-1 # assertion must be true

• me molesta lo incómodo que es depurar código C → ver depuración; trazarlo, investigar lo que hace. Quiero facilitarlo. C es incómodo de depurar

• si trazo variables con „display“, cuáles mirar

  break cmcheckmagic display curY (tty) display FrameRows (tty) - 1 display curY (tty) >= FrameRows (tty) - 1 display frame_size_change_delayed (XFRAME (tty->top_frame)) || (curY (tty) >= FrameRows (tty) - 1)

  display curX (tty) display FrameCols (tty) display curX (tty) == FrameCols (tty)

  • y si lo que tengo es „frame“

    break dispnew.c:5325 display curY(f->terminal->display_info->tty) display FrameRows(f->terminal->display_info->tty) display (f->terminal->display_info->tty)->Wcm->cm_curY < (f->terminal->display_info->tty)->Wcm->cm_rows-1 # assertion must be true

• ~ esto me permite pararme justo antes de llamar a un tty_write_glyphs que creo que a veces puede petar. Sin embargo se activa más veces que las que quiero (cada vez que reduzco algo ventana). Se activa también en veces que no peta

  (gdb) list dispnew.c:5326 5321 5322 * Write the contents of the desired line. * 5323 if (nlen) 5324 { 5325 cursor_to (f, vpos, 0); 5326 write_glyphs (f, nbody, nlen); 5327 } 5328 5329 /* Don't call clear_end_of_line if we already wrote the whole 5330 line. The cursor will not be at the right margin in that (gdb)

  break dispnew.c:5326 if !((f->terminal->display_info->tty)->Wcm->cm_curY < (f->terminal->display_info->tty)->Wcm->cm_rows-1) # assertion must be true

• <05.m10.2024> por ahora no puedo responder nada ni contribuir a la discusión. Sigo aprendiendo de Emacs, y cuesta mucho entender lo que hace este código, y sus limitaciones. Quizás sigo más adelante

• hice bucle para causar (redisplay) continuamente, otro para abrir/cerrar marcos, e hice F10
• por simplificar
• <11.m06.2024> por ahora no lo informo aún porque es muy raro y porque no uso menú

• Fatal error: glibc detected an invalid stdio handle

  Program received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007ffff54a9e8f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #2 0x00007ffff545afb2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff5445472 in __GI_abort () at ./stdlib/abort.c:79 #4 0x00007ffff549e430 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff55b807e "%s") at ../sysdeps/posix/libc_fatal.c:155 #5 0x00007ffff549e462 in __GI___libc_fatal (message=message@entry=0x7ffff55ba668 "Fatal error: glibc detected an invalid stdio handle") at ../sysdeps/posix/libc_fatal.c:164 #6 0x00007ffff549ec95 in _IO_vtable_check () at ./libio/vtables.c:72 #7 0x00007ffff549edb2 in IO_validate_vtable (vtable=0xffffffffffffffff) at ./libio/libioP.h:946 #8 __GI___fflush_unlocked (fp=0x55555600295c) at ./libio/iofflush_u.c:38 #9 0x00005555556740b2 in tty_menu_activate (menu=0x555556fda220, pane=0x7fffffffc904, selidx=0x7fffffffc900, x0=1, y0=1, txt=0x7fffffffc8f8, help_callback=0x55555567424c <tty_menu_help_callback>, kbd_navigation=true) at term.c:3483 #10 0x0000555555675084 in tty_menu_show (f=0x555556fe8368, x=1, y=1, menuflags=7, title=XIL(0x7ffff1b13b4c), error_name=0x7fffffffca30) at term.c:3853 #11 0x00005555555fd316 in x_popup_menu_1 (position=XIL(0x555558110633), menu=XIL(0x7ffff1dc6e6b)) at menu.c:1411 #12 0x00005555555fd395 in Fx_popup_menu (position=XIL(0x555558110633), menu=XIL(0x7ffff1dc6e6b)) at menu.c:1476 #13 0x0000555555770ad1 in funcall_subr (subr=0x555555eb1dc0 <Sx_popup_menu>, numargs=2, args=0x7ffff0dff0f8) at eval.c:3163 #14 0x00005555557cce29 in exec_byte_code (fun=XIL(0x7ffff1c2a995), args_template=1025, nargs=4, args=0x7ffff0dff080) at bytecode.c:812 #15 0x0000555555771123 in funcall_lambda (fun=XIL(0x7ffff1dd517d), nargs=2, arg_vector=0x7fffffffd2e0) at eval.c:3252 #16 0x00005555557704bd in funcall_general (fun=XIL(0x7ffff1dd517d), numargs=2, args=0x7fffffffd2e0) at eval.c:3044 #17 0x000055555577077a in Ffuncall (nargs=3, args=0x7fffffffd2d8) at eval.c:3093 #18 0x0000555555764da7 in Ffuncall_interactively (nargs=3, args=0x7fffffffd2d8) at callint.c:250 #19 0x0000555555770d0a in funcall_subr (subr=0x555555ec3d00 <Sfuncall_interactively>, numargs=3, args=0x7fffffffd2d8) at eval.c:3184 #20 0x0000555555770471 in funcall_general (fun=XIL(0x555555ec3d05), numargs=3, args=0x7fffffffd2d8) at eval.c:3040 #21 0x000055555577077a in Ffuncall (nargs=4, args=0x7fffffffd2d0) at eval.c:3093 #22 0x000055555576fc23 in Fapply (nargs=3, args=0x7fffffffd470) at eval.c:2765 #23 0x00005555557651b9 in Fcall_interactively (function=XIL(0x2aaa9be8f448), record_flag=XIL(0), keys=XIL(0x5555563249a5)) at callint.c:342 #24 0x00007ffff19aeb8d in F636f6d6d616e642d65786563757465_command_execute_0 () from opt/dc/emacs/bin../lib/emacs/30.0.50/native-lisp/30.0.50-cd05323a/preloaded/simple-fab5b0cf-c39c6ea4.eln #25 0x0000555555770b3f in funcall_subr (subr=0x7ffff22dfec0, numargs=1, args=0x7fffffffda98) at eval.c:3167 #26 0x0000555555770471 in funcall_general (fun=XIL(0x7ffff22dfec5), numargs=1, args=0x7fffffffda98) at eval.c:3040 #27 0x000055555577077a in Ffuncall (nargs=2, args=0x7fffffffda90) at eval.c:3093 #28 0x000055555569155c in command_loop_1 () at keyboard.c:1550 […]

  Lisp Backtrace: "x-popup-menu" (0xf0dff0f8) "popup-menu" (0xf0dff060) "menu-bar-open" (0xffffd2e0) "funcall-interactively" (0xffffd2d8) "command-execute" (0xffffda98)

• quizás relacionado: https://lists.gnu.org/archive/html/emacs-devel/2024-09/msg00436.html
  • ¿qué es „child frame“? Ver notas en struct frame

• igual que el anterior
• fácil de reproducir
• <11.m06.2024> por ahora no lo informo aún porque es muy raro y porque no uso menú

• [Detaching after vfork from child process 27847] [Detaching after vfork from child process 27848]

  Program received signal SIGSEGV, Segmentation fault. 0x00007ffff549ed7b in __GI___fflush_unlocked (fp=0x442d3d534e4f4954) at ./libio/iofflush_u.c:38 38 ./libio/iofflush_u.c: No such file or directory. (gdb) bbt Undefined command: "bbt". Try "help". (gdb) bt #0 0x00007ffff549ed7b in __GI___fflush_unlocked (fp=0x442d3d534e4f4954) at ./libio/iofflush_u.c:38 #1 0x00005555556740b2 in tty_menu_activate (menu=0x5555561c0c30, pane=0x7fffffffc904, selidx=0x7fffffffc900, x0=1, y0=1, txt=0x7fffffffc8f8, help_callback=0x55555567424c <tty_menu_help_callback>, kbd_navigation=true) at term.c:3483 #2 0x0000555555675084 in tty_menu_show (f=0x55555608e4d0, x=1, y=1, menuflags=7, title=XIL(0x7ffff1b13b4c), error_name=0x7fffffffca30) at term.c:3853 #3 0x00005555555fd316 in x_popup_menu_1 (position=XIL(0x7ffff0ca2c13), menu=XIL(0x7ffff1dc6e6b)) at menu.c:1411 #4 0x00005555555fd395 in Fx_popup_menu (position=XIL(0x7ffff0ca2c13), menu=XIL(0x7ffff1dc6e6b)) at menu.c:1476 #5 0x0000555555770ad1 in funcall_subr (subr=0x555555eb1dc0 <Sx_popup_menu>, numargs=2, args=0x7ffff0dff0f8) at eval.c:3163

  (gdb) frame 1 #1 0x00005555556740b2 in tty_menu_activate (menu=0x5555561c0c30, pane=0x7fffffffc904, selidx=0x7fffffffc900, x0=1, y0=1, txt=0x7fffffffc8f8, help_callback=0x55555567424c <tty_menu_help_callback>, kbd_navigation=true) at term.c:3483 3483 fflush (tty->output); (gdb) list 3478 } 3479 * Both tty_menu_display and help_callback invoke update_end, 3480 which calls tty_show_cursor. Re-hide it, so it doesn't show 3481 through the menus. * 3482 tty_hide_cursor (tty); 3483 fflush (tty->output); 3484 } 3485 3486 sf->mouse_moved = 0; 3487 screen_update (sf, state[0].screen_behind); (gdb) p tty $1 = (struct tty_display_info *) 0x555556084660 (gdb) p tty->output $2 = (FILE *) 0x442d3d534e4f4954

  (gdb) p *tty $4 = { next = 0x555556ab8a90, name = 0x555556086648 "", type = 0x5555566340c0 ".", input = 0x504f5f4156414a5f, output = 0x442d3d534e4f4954, output_buffer_size = 6009336224923547489, termscript = 0x4641416d65747379, old_tty = 0x6974746553746e6f, term_initted = false, reference_count = 28271, terminal = 0x5555566340e0, Wcm = 0x5500766e652d, top_frame = XIL(0x555556634100), […]

  (gdb) p tty->output $7 = (FILE *) 0x442d3d534e4f4954 (gdb) x 0x442d3d534e4f4954 0x442d3d534e4f4954: Cannot access memory at address 0x442d3d534e4f4954 (gdb) xpr Lisp_String $8 = (struct Lisp_String *) 0x442d3d534e4f4950 Cannot access memory at address 0x442d3d534e4f4968 (gdb)

• • unicode -x 44 2d 3d 53 4e 4f 49 54
    

    • D-=SNOIT

  • unicode -x 50 4f 5f 41 56 41 4a 5f
    

    • PO_AVAJ_
  • ay, qué misteriosas cadenas…

• (gdb) p tty $10 = (struct tty_display_info *) 0x555556084660 (gdb) x 0x555556084660 0x555556084660: 0x56ab8a90 (gdb) x/20 0x555556084660 0x555556084660: 0x56ab8a90 0x00005555 0x56086648 0x00005555 0x555556084670: 0x566340c0 0x00005555 0x56414a5f 0x504f5f41 0x555556084680: 0x4e4f4954 0x442d3d53 0x2e747761 0x53657375 0x555556084690: 0x65747379 0x4641416d 0x53746e6f 0x69747465 0x5555560846a0: 0x3d73676e 0x00006e6f 0x566340e0 0x00005555 (gdb) x/20s 0x555556084660 0x555556084660: "\220\212\253VUU" 0x555556084667: "" 0x555556084668: "Hf" 0x55555608466f: "" 0x555556084670: "\300@cVUU" 0x555556084677: "" 0x555556084678: "_JAVA_OPTIONS=-Dawt.useSystemAAFontSettings=on" 0x5555560846a7: "" 0x5555560846a8: "\340@cVUU" 0x5555560846af: "" 0x5555560846b0: "-env" 0x5555560846b5: "U" 0x5555560846b7: "" 0x5555560846b8: "" 0x5555560846b9: "AcVUU" 0x5555560846bf: "" 0x5555560846c0: "-env" 0x5555560846c5: "" 0x5555560846c6: "" 0x5555560846c7: "" (gdb)

• https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71521

• #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:443 #1 0x000055555573533c in die ( msg=0x55555584e4e8 "FRAME_INITIAL_P (f) || noninteractive || !initialized || !f->terminal->name || (f->current_matrix && f->current_matrix->nrows > 0 && f->current_matrix->rows && f->desired_matrix && f->desired_matrix->"…, file=0x55555584e231 "dispnew.c", line=1851) at alloc.c:8082 #2 0x0000555555589ee4 in adjust_frame_glyphs (f=0x5555567f84e8) at dispnew.c:1851 #3 0x0000555555617ff8 in apply_window_adjustment (w=0x555556295448) at window.c:7848 #4 0x000055555560c1a2 in set_window_buffer (window=XIL(0x55555629544d), buffer=XIL(0x5555561bf575), run_hooks_p=false, keep_margins_p=false) at window.c:4189 #5 0x00005555556e131e in zip_minibuffer_stacks (dest_window=XIL(0x55555629544d), source_window=XIL(0x555555fde315)) at minibuf.c:160 #6 0x00005555556e170a in move_minibuffers_onto_frame (of=0x555555fdde58, frame=XIL(0x5555567f84ed), for_deletion=false) at minibuf.c:209 #7 0x000055555559ae29 in do_switch_frame (frame=XIL(0x5555567f84ed), track=0, for_deletion=0, norecord=XIL(0)) at frame.c:1569 #8 0x000055555559b1fc in Fhandle_switch_frame (event=XIL(0x7ffff0a2e363)) at frame.c:1656 #9 0x0000555555770aaa in funcall_subr (subr=0x555555eb00e0 <Shandle_switch_frame>, numargs=1, args=0x7ffffff00640) at eval.c:3161

• guardo core
• mando <12.m06.2024 16:57>

• no mando

  (no es cierto, pasa sin):

  I remember I enabled (setq enable-recursive-minibuffers t) in one test but I don't remember if it was in this one.

  In addition, during the loop I pressed C-c to interrupt some of the emacsclient processes while they were being opened/closed, to interrupt the half-openend emacsclient.

• estaba haciendo cosas como abrir marcos y cambiarles el tamaño, a mano y poco a poco
• repetible

• intervals.c:619: Emacs fatal error: assertion failed: relative_position <= TOTAL_LENGTH (tree)

  Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:443 443 signal (sig, SIG_DFL); (gdb) bt #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:443 #1 0x0000555556c04d91 in die (msg=0x55555727a1a0 "relative_position <= TOTAL_LENGTH (tree)", file=0x555557279e20 "intervals.c", line=619) at alloc.c:8082 #2 0x0000555556eafb5a in find_interval (tree=0x619000062100, position=393) at intervals.c:619 #3 0x0000555556ee6edd in verify_interval_modification (buf=0x7ffff0590768, start=393, end=393) at textprop.c:2220 #4 0x0000555556ac59b7 in prepare_to_modify_buffer_1 (start=393, end=393, preserve_ptr=0x0) at insdel.c:2037 #5 0x0000555556ac68f2 in prepare_to_modify_buffer (start=393, end=393, preserve_ptr=0x0) at insdel.c:2078 #6 0x0000555556e4f73e in read_and_insert_process_output (p=0x621000200ff8, buf=0x63100026c800 "\033[1mfns.c:4971:7:\033[1m\033[31m runtime error: \033[1m\033[0m\033[1mnull pointer passed as argument 2, which is declared to never be null\033[1m\033[0m\033[1mfns.c:4977:7:\033[1m\033[31m runtime error: \033[1m\033[0m\033[1mnull pointer p"…, nread=410, process_coding=0x616000019e80) at process.c:6404 #7 0x0000555556e50b2b in read_and_dispose_of_process_output (p=0x621000200ff8, chars=0x63100026c800 "\033[1mfns.c:4971:7:\033[1m\033[31m runtime error: \033[1m\033[0m\033[1mnull pointer passed as argument 2, which is declared to never be null\033[1m\033[0m\033[1mfns.c:4977:7:\033[1m\033[31m runtime error: \033[1m\033[0m\033[1mnull pointer p"…, nbytes=410, coding=0x616000019e80) at process.c:6481 #8 0x0000555556e4c116 in read_process_output (proc=XIL(0x621000200ffd), channel=22) at process.c:6266 #9 0x0000555556e48809 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=XIL(0), wait_proc=0x0, just_wait_proc=0) at process.c:5947 #10 0x00005555569b57da in kbd_buffer_get_event (kbp=0x7fffffffca50, used_mouse_menu=0x7fffffffd4f0, end_time=0x0) at keyboard.c:4079

• volqué „core“ pero se colgó; >800 Mb. Lo maté

• CONCLUSIÓN escrita el <13.m04.2009 23:58>
  Por fin acabé; era sólo una introducción. Pero me gusta para CLISP

Ahora que Icicles está corregido

file:~/.emacs.d/lisp/pruebascl.lisp

Se llamaba algo de „shadow“. Lo necesito para openTrends: para el Eclipse+Emacs al editar JSPs.

De momento unison va bien.

Ver file:///home/dc/.emacs al principio. ; para que arranque en 1s: http://www.emacswiki.org/cgi-bin/wiki.pl?DumpingEmacs

<12.m10.2008> Peta aquí, también con versión de CVS. SIGSEGV.

0x81ac22b is in unexec (unexelf.c:953).
948    */
949	
950		  memcpy (NEW_SECTION_H (nn).sh_offset + new_base,
951			  (caddr_t) OLD_SECTION_H (n).sh_addr,
952			  new_data2_size);
953		  nn++;

Me tarda más de 5 segundos para buscar un texto, moverse. Necesito depurarlo más.

• está cache-long-scans, que dicen que si se pone a t acelera las largas (pero enlentece las cortas)
• cache-long-line-scans ya lo tengo a t
• https://www.emacswiki.org/emacs/SoLong
  • versión más nueva: http://git.savannah.nongnu.org/cgit/so-long.git/plain/so-long.el?h=wip
• longlines.el, file:/w/emacs/lisp/obsolete/longlines.el
  • ~ corta visualmente las líneas para poder moverse mejor
  • ∴ ya es muy bueno
  • activarlo a mano
• la situación en 2018 sigue siendo muy mala incluso con so-long: http://lists.gnu.org/archive/html/emacs-devel/2018-10/msg00497.html
• ẽ file:///w/edx-platform/common/lib/xmodule/xmodule/assets/word_cloud/src/js/d3.min.js
• muevo ciertas cosas a fichero aparte, para evitar tenerlas ẽ en org

Creo que es por el autograbado, quizás se ejecuta miles de veces para compensar todas las veces que no se ejecutó mientras dormía.

… #21165 0x000000000060922c in exec_byte_code (bytestr=50574609, vector=51514541, maxdepth=12, args_template=12888946, nargs=0, args=0x0) at bytecode.c:1163 #21166 0x00000000005c6ea6 in funcall_lambda (fun=51514621, nargs=0, arg_vector=0xc4ab72) at eval.c:2956 #21167 0x00000000005c6666 in Ffuncall (nargs=1, args=0x7fff8abf1618) at eval.c:2772 #21168 0x00000000005c5e97 in call0 (fn=50469426) at eval.c:2568 #21169 0x000000000053345e in safe_run_hooks_1 (nargs=2, args=0x7fff8abf16c0) at keyboard.c:1885 #21170 0x00000000005c380b in internal_condition_case_n (bfun=0x53343b <safe_run_hooks_1>, nargs=2, args=0x7fff8abf16c0, handlers=12888994, hfun=0x533460 <safe_run_hooks_error>) at eval.c:1426 #21171 0x00000000005336b6 in safe_run_hook_funcall (nargs=2, args=0x7fff8abf17c0) at keyboard.c:1937 #21172 0x00000000005c5db1 in run_hook_with_args (nargs=2, args=0x7fff8abf17c0, funcall=0x533669 <safe_run_hook_funcall>) at eval.c:2539

#21173 0x0000000000533713 in safe_run_hooks (hook=17037026) at keyboard.c:1958 #21174 0x00000000005787e6 in Fdo_auto_save (no_message=12888946, current_only=12888946) at fileio.c:5557 #21175 0x0000000000534ef3 in read_char (commandflag=1, map=122778342, prev_event=12888946, used_mouse_menu=0x7fff8abf1e1f, end_time=0x0) at keyboard.c:2831 #21176 0x0000000000540a84 in read_key_sequence (keybuf=0x7fff8abf2000, bufsize=30, prompt=12888946, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9171 #21177 0x0000000000532152 in command_loop_1 () at keyboard.c:1462

#21178 0x00000000005c3391 in internal_condition_case (bfun=0x531d97 <command_loop_1>, handlers=12940418, hfun=0x53165d <cmd_error>) at eval.c:1344 #21179 0x0000000000531af1 in command_loop_2 (ignore=12888946) at keyboard.c:1197 #21180 0x00000000005c2b6d in internal_catch (tag=12936338, func=0x531acb <command_loop_2>, arg=12888946) at eval.c:1105 #21181 0x0000000000531a9f in command_loop () at keyboard.c:1176 #21182 0x0000000000531255 in recursive_edit_1 () at keyboard.c:786 #21183 0x00000000005313c5 in Frecursive_edit () at keyboard.c:857 #21184 0x000000000052f2ad in main (argc=2, argv=0x7fff8abf2468) at emacs.c:1623

• https://www.emacswiki.org/emacs/IbufferMode

Por ejemplo en:

/su:labx@localhost:/home/labx:

• esto el <22.m05.2019> con emacs GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars) of 2019-04-25, lleva 25 días abierto, 1009 búfers simultáneos abiertos (884 ficheros), y consumiendo 2'2 Gb RES

• trazo; esto es en fichero .org de 4'5 Mb

  - command-execute                                                1419  90%
   - call-interactively                                            1418  90%
    - funcall-interactively                                        1029  65%
     - isearch-printing-char                                        526  33%
      - isearch-process-search-char                                 526  33%
       - isearch-process-search-string                              526  33%
        - isearch-search-and-update                                 526  33%
         - isearch-update                                           524  33%
          - window-max-chars-per-line                               509  32%
             window-font-width                                      509  32%
          + isearch-lazy-highlight-new-loop                          10   0%
          + pos-visible-in-window-group-p                             5   0%
           isearch-push-state                                         2   0%
     + isearch-delete-char                                          441  28%
     + isearch-forward                                               61   3%
     + execute-extended-command                                       1   0%
    + byte-code                                                     389  24%
  - timer-event-handler                                             151   9%
   - apply                                                          151   9%
    + auto-revert-buffers                                            97   6%
    + semantic-idle-scheduler-function                               28   1%
    + isearch-lazy-highlight-start                                    2   0%
  

• mmmm… sí, (window-max-chars-per-line) es muy lenta
• [ ] quizás puedo volver a (window-body-width), se nota mucho más rápida que (window-max-chars-per-line) y parece dar el mismo resultado en la mayoría de casos (excepto si no hay „fringe“, pues entonces da ẽ 90 vs 89)
  • lo pruebo, es rapidísimo y aparentemente funciona igual
  • [ ] quiero tenerlo como opción
  • ∴ de momento cambiarlo a mano
  • ¿preguntar en lista de emacs?
  • pero window-max-chars-per-line hace más cosas (ẽ tiene en cuenta tamaño)
  • podría usar (- (window-body-width) 1) si veo que siempre da un resultado 1 mayor
  • de todas maneras uso „fringe“ así que no me da problemas

• cambiaron a window-max-chars-per-line por:

  +2016-04-26

  • Fix bug#22891: wrong terminal width when a fringe width is zero.
  • When either fringe width is zero, Emacs reserved one column for a
  • continuation glyph. Terminal windows does not take this into
  • account when the frame is resized.
  • * lisp/window.el (window-adjust-process-window-size): Use
  • `window-max-chars-per-line' instead of `window-body-width'.

  • https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22891

  • […] it was a function in window.el used to by terminal windows to track the window width that didn't take the continuation glyph into account. (The continuation glyph is visible when the width of a fringe is zero.)

• [ ] aaaah, (window-font-width) ya es problema, ya es muy lenta (sólo para decir ẽ 10)
  • quizás porque llama a (font-info (face-font 'default))
    • quiere (aref (font-info (face-font 'default)) 11)
  • font-info es ya algo gordo
  • [ ] ¡¡¡+window-font-width+ face-font debería ser instantáneo a menos que la fuente haya cambiado!!! Tiene que haber alguna caché
  • iría en file:///w/emacs/src/font.c#org0dbf3b7
• [ ] isearch no debería estar pidiendo el nº de caracteres repetidamente…
  • claro que alguien podría estar cambiando la fuente mientras isearch está activo… pero aceptaría fallar en ese caso para tener búsqueda rápida en el resto de casos

• "mailcap-parse-mailcap-extras" (0xc6d6f748) "mailcap-parse-mailcap" (0xc6d6fba0) "mailcap-parse-mailcaps" (0xc6d6ff98) "mailcap-mime-info" (0xc6d70330) "setq" (0xc6d704a0) "if" (0xc6d70570) "while" (0xc6d70650) "let" (0xc6d707c0) "defvar" (0xc6d708a0) "eval-buffer" (0xc6d70a90) "load-with-code-conversion" (0xc6d70e98) "require" (0xc6d712c0) "eval-buffer" (0xc6d714a0) "load-with-code-conversion" (0xc6d718a8) "load" (0xc6d71ca8) "startup–load-user-init-file" (0xc6d720c0) "command-line" (0xc6d72a48) "normal-top-level" (0xc6d72ee0)

• (require 'mailcap)
• (mailcap-mime-info "text/plain")
• (mailcap-parse-mailcaps nil t)
• (mailcap-parse-mailcaps "~/.mailcap" t)
• (mailcap-parse-mailcaps "/etc/mailcap" t)

• es por w3m, creo

  Debugger entered–Lisp error: (void-variable w3m-use-symbol) default-toplevel-value(w3m-use-symbol) custom-initialize-reset(w3m-use-symbol (when (and (featurep 'mule) (eq w3m-type 'w3m-m17n)) (if (eq w3m-output-coding-system 'utf-8) (and (w3m-mule-unicode-p) (or (featurep 'xemacs) (< emacs-major-version 23)) 'w3m-device-on-window-system-p) t))) custom-declare-variable(w3m-use-symbol (when (and (featurep 'mule) (eq w3m-type 'w3m-m17n)) (if (eq w3m-output-coding-system 'utf-8) (and (w3m-mule-unicode-p) (or (featurep 'xemacs) (< emacs-major-version 23)) 'w3m-device-on-window-system-p) t)) "Non-nil means replace symbols that the <_SYMBOL> …" :group w3m :type boolean :require w3m-symbol) eval-buffer(#<buffer *load-460691> nil "home/dc.emacs.d/emacs-w3m-cvs/w3m.el" nil t) ; Reading at buffer position 53574 load-with-code-conversion("home/dc.emacs.d/emacs-w3m-cvs/w3m.el" "home/dc.emacs.d/emacs-w3m-cvs/w3m.el" nil t) require(w3m) eval-buffer(#<buffer *load*> nil "home/dc.emacs" nil t) ; Reading at buffer position 468445 load-with-code-conversion("home/dc.emacs" "home/dc.emacs" t t) load("~/.emacs" noerror nomessage)

• w3m hace:
  • (mailcap-parse-mailcaps nil t)
  • (mailcap-parse-mimetypes nil t)
• pasa así: (require 'w3m)
• [] entender por qué lo hace
• [X] ya de paso, actualizar y simplificar w3m
• ∴ al actualizar al w3m de git (m10.2020), ya no pasa. Usaba el ~m1.2019 de CVS

$  for a in `seq 1 20`; do echo -n "vez $a: "; emacsclient -e '(message "hola")' ; sleep 0.2 ; done

A veces devuelve algo, otras no:

vez 1: "hola"
vez 2: "hola"
vez 3: vez 4: "hola"
vez 5: "hola"
vez 6: vez 7: "hola"
vez 8: vez 9: "hola"
vez 10: "hola"
vez 11: vez 12: vez 13: vez 14: "hola"
vez 15: "hola"
vez 16: vez 17: "hola"
vez 18: "hola"
vez 19: "hola"
vez 20: "hola"

Esto es muy feo.

Visto el <25.m02.2011> con Emacs reciente de Bazaar.

Pero va todo bien.

• [X] conseguir reproducir
• [X] corrijo lo del color-80
• candidatos no es por esto:
  • creo que es por file:~/.emacs.d/color-theme-6.6.0/color-theme.el, (if (and (consp face) (eq (car face) 'quote))

• (org-get-category) en Lisp.org, me da "opencraft.org"
• y en agenda sale mal listado
• creo que es porque moví algo opencraft→Lisp.org
• (get-text-property (point) 'org-category)
• (org-refresh-category-properties)
• (org-get-at-eol 'org-category 1) también
• luego empezó a mostrármelo bien, pero agenda mal
• ∴ solución: ponerme en el búfer .org fallante y hacer (org-refresh-category-properties)
  • „fallante“ es el que sale en agenda y no debería salir; en ése toca hacerlo
  • esto arregla agenda
• [ ] no sé por qué pasó
• no puedo fiarme de org-agenda-log-mode por ahora
  • suerte que de momento uso otros sistemas (cromonetrados-org.el para exportar, y luego Python)
• otra solución: cerré emacs y volví a abrir, y ya iba
• recargué org-mode y compilé, no ayuda

• lo hace semantic-idle-scheduler-mode
• no ralentizan ni molestan pero distraen

• Save Error: "Unbalanced parentheses": /home/dc/.emacs.d/cedet-caché/!home!dc!Downloads!semantic.cache
  Parsing Sprint - Serenity - Agile Board - OpenCraft-bonificado.html (HTML)... 
  Parsing Sprint - Serenity - Agile Board - OpenCraft-bonificado.html...done
  Save Error: "Unbalanced parentheses": /home/dc/.emacs.d/cedet-caché/!home!dc!Downloads!semantic.cache
  
  […]
  Error running timer ‘semantic-idle-scheduler-function’: (scan-error "Unbalanced parentheses" 29487 856661)
  

• parece que es por HTML raro ¿o inválido? o lioso, tipo <![endif]-->; en alguno se lía
• cerrar el fichero afectado, eso ayuda

• ∴ mmmmmm… es porque le he activado semantic-show-parser-state-mode. Pruebo a desactivarlo y ya se calla

  (global-semantic-show-parser-state-mode 0) ← justo esto no va, pero lo desactivé de otra forma
  

• ∴ ah, no me lo perdió, estaba en #nombre.org#, es que lo recuperó mal
• igualmente, me está fallando mucho, por el error de garbage-collect (sweep_conses) y otros
• ¿quizás debido a que intenté por error una versión de hace 10 años? No sé en qué afecta
• por si acaso, subo la frecuencia del coseguador (el porsifalla)

• no sé si por overlays
• lleva pasando años
• ẽ con: Org mode version 9.3.7 (release_9.3.7-708-g5417e3.dirty @ w/org-mode/lisp)

• por ejemplo, como usuario dc entro a /su:usu@:/home/usu/ (eso entra a través de usuario usu). Y ahí, git grep no va; sigue pensando que soy el usuario dc mirando el repositorio de home/dc, no el /home/usu. Quiero el otro repositorio (/home/usu)
• no ayuda:
  • „Helm Git Grep Base Directory“: lo quiero siempre a RootDirectory. Pero he probado ambos y no cambia nada
  • …

• el comando que ejecuta (es: helm-git-grep-submodule-grep-command)

  Result: "git grep -n --no-color -i   -e ho  | sed s!^!$path..."
  
  ("git" "--no-pager" "submodule" "--quiet" "foreach" "git grep -n --no-color -i   -e ho  | sed s!^!$path...")
  

• lo llama con start-process. Lo pruebo aquí: (apply 'start-process "prueba-de-proceso" "búfpro1" '("id"))
  • y luego mirar búfer
  • veo que start-process, a diferencia de shell-command, no sabe de tramp. ẽ no se da cuenta de que el directorio actual es otro

  • a ver, lo compruebo: lo fuerzo a estar en algo con tramp

    (let ((default-directory "/su:so@ocrb:/home/so")) (apply 'start-process "prueba-de-proceso" "*búfpro1*" '("id")))
    

  • y veo que no usa tramp

  • a diferencia de esto, que sí que usa tramp:

    (let ((default-directory "/su:so@ocrb:/home/so")) (shell-command-to-string "id"))
    

  • experimento:

    (let ((default-directory "/su:so@ocrb:/home/so")) (funcall 'tramp-file-name-handler 'shell-command "id" nil nil))
    

  • propuestas: ver abajo
• o quizás puedo hacer que helm-git-grep no use async-process…
• o modificar ẽ helm-git-grep-process, para que haga un „su“ antes e invoque el comando git como otro usuario

From: Daniel Clemente <…>
Newsgroups: gmane.emacs.devel
Subject: Re: Summer of Code 2009
References: <18797.40998.179248.71695@kahikatea.snap.net.nz>
X-Draft-From: ("gmane.emacs.devel" 107842)
Date: Thu, 15 Jan 2009 11:10:59 +0100
Message-ID: <87k58wg9qk.fsf@CPU107.opentrends.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)
Cancel-Lock: sha1:Ijrv9J5osjSMaMC8HUEupzBz/SE=
--text follows this line--


Hi,
  I think this is a very good opportunity to tackle the big projects which have been around for a long time and which would improve Emacs considerably.


  As examples:

1. Integrate CEDET into Emacs
-----------------------------
  This will ease support for other languages and integrate features like code completion, syntax checking, project handling, ... Some other tools like JDEE (Java support) or ECB could also be included.


2. Good multithreading support for Emacs
----------------------------------------
  This is much wanted, specially for background processes like checking mail. It is necessary to profit from multicore processors, very common nowadays.
  There were already attempts to do this.


3. Version control system and bug tracker
-----------------------------------------
  This would include:
- setting the Bazaar repository, migrating from CVS to Bazaar
- web interface to the bug tracker, similar to the other projects like Bugzilla and Launchpad, where you could see reports, send a new bug, query for bugs, ...
- and at the same time, mail interface, where you can issue all commands just via mail
- integration between VC and bug tracker; similar to what Bundle Buggy (in Launchpad) does: patch tracking, asking for automatic merges from the mailing list, patch approval, ...
- some other infrastructure tasks could be added, like automatic building (continuous integration), breakage detection (get noticed when code doesn't compile), validation at commit time, ...



  There are for sure more ambitious projects; and I'm sure that many students would apply for them. Emacs needs mentors first.


  Greetings,

Daniel

In the Emacs mailing list they are discussing participating in Google's „Summer of code". Since CEDET will be an important part of Emacs, have you considered presenting some of these or bigger projects? Maybe the first project would be to integrate CEDET into Emacs.

• CONCLUSIÓN escrita el <23.m01.2009 12:24>
  http://www.emacswiki.org/emacs/SummerOfCode2009

Título: SummerOfCode2009

#+BEGIN_EXAMPLE

In Google's [http://code.google.com/soc Summer of Code] program, students receive some help while they work for 3 months on the free software project they choose. Several organizations have taken part in the last 4 years, including GNU ([http://www.gnu.org/software/soc-projects/ideas.html ideas for SOC 2009]). GNU Emacs could also take part this year; this page is an informal discussion about ideas. Feel free to edit this page! ([[HowToEdit]]).


== How to participate; the basics ==
Detailed info here: [http://code.google.com/opensource/gsoc/2008/faqs.html]
Use also the chat channel <code>#gsoc</code> on FreeNode.

=== Dates and deadlines ===
In 2008: the program announcement was on 25th February; the start date of applications submission from the mentoring organizations was on 3rd March
In 2007 it started in 5th March.

In 2009... we still (22th Jan.) don't know.

The dates in 2008 were the following: [http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline]
There were 9 days to submit the ideas list, 14 to register as students, and almost 3 months to code.

=== People ===

We need:
,* mentors, which follow students' progress and help them. Each project needs a mentor.
,* students which have interest on a particular project. They must be taking official studies. They will work approx. from May to August.

=== Legal ===
Since students will write code for [[GnuEmacs]], they must sign first an agreement with the FSF. See [[LegalMatters]].

== Firm list of ideas (with mentors) ==

If you can guide a student in a particular project, write your name and the project here.

Requisites for the proposals:
,* the goal is to write code, not documentation
,* adapt the difficulty to 12 weeks of work
,* they should fit the GNU project; that means: they should steer people to use free plattforms and programs
,* please list here only the projects with mentor; for loose ideas and brainstorming, see the next section

After a proposal is here, consult with the community and then send to [http://www.gnu.org/software/soc-projects/ideas.html GNU project's ideas list]. That is the page which will be shown to Google.


=== shell and script debuggers and Emacs ===
(From [http://www.gnu.org/software/soc-projects/ideas.html#shelldbg]):

In the last couple of years, a large number of Integrated Development Environments (IDE's) has emerged. So far, none has come close to the editing capabilities of Emacs, but on the debugger side, Emacs has been surpassed.

As many people still use Emacs as their preferred editor, an ideal situation would be that Emacs also would be used as a debugger front-end with windows for, say, the call stack, local variables, and breakpoints.

Some work in this area has been done, most notably gdb-ui.el, which provides a multi-window debugging environment for C and C++ and gdb. In addition, the ruby-debug project is doing similar work for Ruby. This project would:

,* define guidelines for the look and feel for multi-window debugger Emacs environments.
,* refactor and unify the existing code base (gdb-ui and rdebug), to make it easier to implement support for other debuggers.
,* Analyze the underlying Emacs layers [1], and maybe restructure parts. Especially, the gud.el layer is a candidate for this.
,* Implement support for other languages and/or debuggers, for example Bash and Python. 

For more information, contact R. Bernstein and Anders Lindgren. 


== Loose ideas and discussion ==

If you know about these topics and you want to help people to improve Emacs, please adapt it, add yourself as a mentor and move the heading to the previous section.

Other sources for ideas are:
,* the [[WishList]]. You can extract and define a project based on the wishes there
,* [[EmacsIDEWishList]], particularly important improvements
,* [[EmacsBugs]]
,* [[EmacsTodo]]: fixing a subset of those tasks would be instructive and helpful


=== Make Scheme an Emacs extension language ===
See [[GuileEmacs]]. At least goal 1 can be aimed.

=== Integrate CEDET into Emacs ===
See [[CEDET]]; this is already planned for Emacs 24.
This will ease support for other languages and integrate much wanted features like code completion, syntax highlighting, syntax checking, project handling, ... Some other tools like [[JDEE]] (Java support) or [[ECB]] could also be included.
Lots of things must be done to make Emacs a better IDE, and this is one of them.

=== Improve VC (version control system) ===
How about also having a proposal for improving VC?
,* implement vc-pull / vc-push
,* improve dealing with branches
,* add other features that are needed for modern version control systems.

=== Good multithreading support for Emacs ===
This is much wanted, specially for background processes like checking mail. It is necessary to profit from multicore processors, very common nowadays.
There were already attempts to do this. See [[ConcurrentEmacs]] and messages in the mailing list (Giuseppe Scrivano, 29 Nov 2008).

=== Create an usable shell interface ===
There is M-x term, ansi-term, shell, eshell: too many shells, and no one is good enough to please most users.
,* [[AnsiTerm]] and [[ShellMode]] could be merged so that we have just 2 types of shell: an Elisp one ([[Eshell]]) and an interface to your other shell (like bash).
,* Eshell could also have all good things by default: colors, completion, globbing, ... See [[EshellWishlist]]
,* Compatibility should be checked so that all programs work normally; just like in bash inside an xterm
,* Performance issues: cat, ls, find, ... should run fast

=== Integrated version control system and bug tracker to be used in Emacs project ===
Emacs has unfinished and sometimes rudimentary tools to track its development. A new GNU project could be established (or existing ones extended) to improve the tools which will serve to sustain Emacs' coding infrastructure. This could include:
,* setting the Bazaar repository, migrating from CVS to Bazaar and adapting Bazaar so that it fits Emacs
,* web interface to the bug tracker, similar to the other projects like Bugzilla and Launchpad, where you could see reports, send a new bug, query for bugs, ...
,* and at the same time, mail interface, where you can issue all commands just via mail
,* integration between VC and bug tracker; similar to what Bundle Buggy (in Launchpad) does: patch tracking, asking for automatic merges from the mailing list, patch approval, ...
,* some other infrastructure tasks could be added, like automatic building (continuous integration), breakage detection (get noticed when code doesn't compile), validation at commit time, ...

=== Finer dimensions for window and frame sizes ===
Another change we should ask Google to support is to eliminate the requirement for window and frame sizes to be integral numbers of characters and lines.

=== Multiple major modes ===
Integrate [[MuMaMo]] into Emacs so that it is easy to have more than one major mode in a buffer; for instance: Java and HTML (that's .jsp) or [[OrgMode]]+C/Lisp/Python/Java/...

Hi, I wrote in EmacsWiki the list of ideas which have appeared on the mailing list with relation to Summer of Code 2009: http://www.emacswiki.org/emacs/SummerOfCode2009

Anyone can add more; and please restructure the page if you want. I will also try to keep the list consistent and update it. Please add some deadlines to your org-modes so that you don't miss the dates to submit proposals! :-) We can collect ideas until March, so there's still time to discuss and choose the project.

Remember: we don't only need ideas, we need also mentors (people who can help the students and track their progress).

Greetings, Daniel

jdee-devel@lists.sourceforge.net

Hi, this is a good opportunity to boost JDEE's progress and maybe integrate it with CEDET and Emacs. Are there big projects (for 12 weeks of work) which could be done to improve in JDEE? You can add your ideas to this page I started: http://www.emacswiki.org/emacs/SummerOfCode2009

We need also mentors (people to help the students).

I hope Emacs becomes soon a better IDE for Java coding. Greetings,

Daniel

• CONCLUSIÓN escrita el <09.m02.2009 01:30>
  nada especial

Hay alguna nueva… nada en especial.

Aprovechar para decir fechas

From: Daniel Clemente <…>
Newsgroups: gmane.emacs.xemacs.beta,gmane.emacs.sxemacs.devel,gmane.emacs.devel
Subject: Re: Emacs-Lisp Bill-Board
References: <49881BE3.6090907@online.de>
X-Draft-From: ("gmane.emacs.devel" 108667)
Date: Wed, 04 Feb 2009 11:27:41 +0100
Message-ID: <87vdrqo5sy.fsf@CPU107.opentrends.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)
Cancel-Lock: sha1:wi9h55SzNJSprxYYTetVRkZeYSE=
--text follows this line--

  EmacsWiki was suggested as the natural place to share code snippets, but not appropriate because of possible unwanted edits and because it doesn't integrate well with our tools (version control, Emacs, ...).

  I propose to reimplement EmacsWiki using org-mode pages. Org-mode ( http://orgmode.org/ ) is an oficial Emacs mode to take notes, define tasks to do, schedule appointments and deadlines, publish to several formats, and more. It uses just a plain text file with as much markup as you want. Version control works thus very well with .org files.

  This combination would do it:
- a Bazaar repository. This is where access control is done
- several .org files in it; including global pages with Emacs information and also personal pages with information and the each user's task list if they want.
- a script which export these pages to HTML (this is already done; see below)
- a web interface so that users can edit pages in a web browser

  A special branch or directory with restricted access could be used to hold the accepted code for inclusion with Emacs. Emacs could then branch this directory. Either this is restricted to people who signed the FSF papers, or some script is included in Emacs to download this branch at will.
  There can be a global section and also personal pages, where each users tracks their Emacs-related tasks (schedules, deadlines, TODOs, links to discussions, ...). Hey, even bugs could be discussed and fixed in Org better than in a bug tracker! Note that you get all the typical Emacs eye-candy while you are editing .org files: gnus, remember, bbdb, vc, diary, appt, ...

  Of course, other files could also be tracked and shared, like export scripts. Org-mode even includes an attachment system which can help organize files and add any metadata you want. Source code can be edited in place (with syntax colouring) or attached in files.


  This is not an utopia; this is already being used in Worg, a repository of pages related to Org-mode.
  Its main page is: http://orgmode.org/worg/
  You can fetch this branch (read-only) with: git clone git://repo.or.cz/Worg.git

  Registered users can push to that branch easily, can fork from that branch, merge again, etc.

  What is missing is a web interface to that repository which allows to commit each change that. But I understand that this is already what EmacsWiki does, since it commits everything to a repository (http://www.emacswiki.org/emacs/SVN_repository). The new EmacsWiki branch could even import this Subversion branch.


  Many users have been contributing to Worg and it has been useful. It is a working demo of what EmacsWiki could do; in the future, maybe Worg is just a part of the greater EmacsWiki...


  Greetings,
Daniel

• CONCLUSIÓN escrita el <02.m10.2012 00:45>
  ya no pasa

(org-id-update-id-locations)

A veces va bien… Pero otras detecta ej "lápices.org" y "l\200\33pices.org" (o los códigos que sean) como distintos, cuando son el mismo.

Es por el org-id-files que es el último componente del (append) que acaba en files, en org-id-update-id-locations. Ése y no otro es el que tiene caracteres raros.

Por tanto la solución de momento es:

(setq org-id-files nil)

Y entonces llamar a (org-id-update-id-locations) para ver si se corrige el fichero ~/.emacs.d/.org-id-locations

• ej. éste, cee9b461-afbd-4974-81b5-142ad00afe28
• estaba en ~/wiki/MF_Autónomo.org
• esto falla:
  • (org-id-open "cee9b461-afbd-4974-81b5-142ad00afe28")
• ∴ org-id-update-id-locations lo arregla

(org-id-update-id-locations)

Se cuelga en:

Finding ID locations (4/155 files): /home/dc/org/semana.org

Lisp Backtrace: "Automatic GC" (0x0) "line-end-position" (0x58dd8628) "org-element-clock-parser" (0x58dd8a00) "org-element–current-element" (0x58dd8f90) "org-element–parse-to" (0x58dd9578) "org-element-at-point" (0x58dd98b0) "org-element-context" (0x58dd9f38) 0x557a2e20 PVEC_COMPILED "org-entry-properties" (0x58dda980) "org-cached-entry-get" (0x58ddac30) "or" (0x58ddad90) "org-string<>" (0x58ddaec0) "and" (0x58ddaf80) "or" (0x58ddb040) "progn" (0x58ddb100) 0x501dfc60 Lisp type 3 "org-scan-tags" (0x58ddb998) "org-map-entries" (0x58ddbe50) "org-id-update-id-locations" (0x58ddc3b0) "funcall-interactively" (0x58ddc3a8) "call-interactively" (0x58ddc4c0)

(el "Automatic GC" (0x0) es lo que peligra, pues me mete en pila de más de 20k niveles)

• [ ] ¿es por emacs o por org-mode?
  • actualicé emacs, parece que sigue fallando
• [ ] bisección
• [X] perfilar
  • ẽ durante un minuto

  • CPU:

    • command-execute 7841 55%
    • … 6187 44%
    • redisplay_internal (C function) 2 0%
    • timer-event-handler 2 0%

    ---

    MEM:

    • command-execute 799,957,974 99%
    • redisplay_internal (C function) 7,630 0%
    • timer-event-handler 3,843 0%
    • eldoc-schedule-timer 16 0% … 0 0%

  • más detallado:

    CPU:

    • org-cached-entry-get 6705 47%
      • org-entry-properties 6705 47%
        • #<compiled 0x15582053df31> 6684 47%
          • org-element-context 6673 47%
            • org-element-at-point 6661 47%
              • org-element–parse-to 6495 46%
                • org-element–current-element 5447 38%
                  • org-element-clock-parser 2944 20%
                  • org-get-limited-outline-regexp 840 5%
                  • org-at-heading-p 191 1%
                  • org-element-drawer-parser 94 0%

    ---

    MEM:

    • org-element-context 725,795,015 90%
      • org-element-at-point 722,675,648 90%
        • org-element–parse-to 720,933,473 90%
          • org-element–current-element 706,848,867 88%
            • org-element-clock-parser 530,370,966 66%
              • org-element-timestamp-parser 417,505,018 52%
                • org-parse-time-string 287,207,457 35% match-string 286,913,316 35% string-to-number 108,512 0% match-string-no-properties 34,606,710 4%

  • [X] ¿qué hay en el org-parse-time-string? ¿por qué ocupa tanto?
    • nada especial dentro, está analizando fechas. Pero veo bucle inf., ver abajo
• hay bucle infinito

  • miro el org-parse-time-string, le pongo mensaje de depuración, veo ẽ esto en línea de mi registro nº 198, y 424, y 652, y 880, o sea, (- 424 198) cada ~ 228 fechas se está repitiendo. (- 652 424) 228, …

    Me piden analizar esta cadena: «[2016-09-10 Sat 21:45»
    Me piden analizar esta cadena: «[2016-09-10 Sat 22:05]»
    Me piden analizar esta cadena: «[2016-09-07 Wed 22:17»
    Me piden analizar esta cadena: «[2016-09-07 Wed 22:28]»
    
    

  • [ ] ¿por qué?

  • veo en org

    C…LOCK: <09.m08.2016 19:25>–<09.m08.2016 19:50> => 0:25 C…LOCK: <09.m08.2016 17:00>–<09.m08.2016 18:50> => 1:50 C…LOCK: <15.m07.2016 23:15>–<15.m07.2016 23:45> => 0:30 C…LOCK: <27.m04.2016 01:00>–<27.m04.2016 01:59> => 0:59

  • pero analiza:

    Me piden analizar esta cadena: «[2016-08-09 Tue 19:25» Me piden analizar esta cadena: «<09.m08.2016 19:50>» Me piden analizar esta cadena: «[2016-08-09 Tue 17:00» Me piden analizar esta cadena: «<09.m08.2016 18:50>» Me piden analizar esta cadena: «[2019-11-05 Tue 03:05» Me piden analizar esta cadena: «<05.m11.2019 03:21>» Me piden analizar esta cadena: «[2019-11-03 Sun 19:35»

  • y en ese punto vuelve a saltar al inicio. No sé porqué. Es la cabecera „cosas sueltas, repeticiones, ya vistas, vídeos, …“
  • (- 3401 3286)115 líneas aprox. de cronómetros → sí, son las ~230 fechas que veo
  • [ ] ¿por qué bucla por esas líneas? No les veo nada especial
  • quizás no es por los tiempos, sino por org-element. ẽ quizás hay dos líneas que casualmente dan misma caché, o algo así

  • añado a org-element--current-element:

    (message "Analizando %i en %s" (point) (buffer-name) )
    

  • oh on, descubro que parece no un bucle infinito, sino un bucle muy ineficiente y lento, pasando varias veces por los mismos sitios, pero avanzando un poco

  • ¿y es que no hay caché?

    org-element-use-cache is a variable defined in ‘org-element.el’. Its value is nil

    Documentation: Non-nil when Org parser should cache its results.

    WARNING: for the time being, using cache sometimes triggers freezes. Therefore, it is disabled by default. Activate it if you want to help debugging the issue.

    • (setq org-element-use-cache nil)
    • ∴ (setq org-element-use-cache t), esto lo acelera mucho, tarda cerca de 1 minuto ahora

• ẽ al hacer C-m m

• > I….org
  > org-capture-set-target-location: Cannot find target ID "notas-sueltas-de-lo-que-sea"
  

• pero desde otros va
• org-update-id-locations lo arregla. Pero tarda varios minutos porque es lento y mis ficheros son grandes

• es nuevo, de <09.m04.2024> o poco antes
• • enlazo al ID jgg8k741eue0
  • va porque estoy en mismo fichero
• enlazo a ID de otro fichero: c5m2je81pue0: soluciones temporales para descubrir cuál es

• me queda:

  +<li>enlazo a ID de otro fichero: <code>c5m2je81pue0</code>: <a href="conkeror.html#ID-id:c5m2je81pue0">soluciones temporales para descubrir cuál es</a></li>
  

• eso es inútil, porque el ID real de la sección es:

  <h4 id="soluciones-temporales-para"><span class="section-number-4">3.1.4.</span> soluciones temporales para descubrir cuál es</h4>
  

• por tanto me esperaba:

  …<a href="conkeror.html#soluciones-temporales-para">soluciones temporales para descubrir cuál es</a>…
  

• con un org de dentro de emacs, y sin mi confi, queda:

  +<li>enlazo a ID de otro fichero: <code>c5m2je81pue0</code>: <a href="conkeror.html#ID-c5m2je81pue0">soluciones temporales para descubrir cuál es</a></li>
  

• quizás tiene que ver con el ajuste que yo hice
  • file:///home/dc/.emacs.d/lisp/org-exportar-mejores-ids.el
  • pero está funcionando, al menos al generar el ID que toca
  • quizás falla (le falta) el tomar ese ID
  • pruebo a desactivarlo
• pasa también al exportar una sola sección
• org-html--id-attr-prefix es „ID-“
  • ¿qué es esto? No lo quiero
  • estoy leyendo org-html-link, que lo usa. Qué horror. Lisp es muy guarro y lioso

  • parece que en org-html-link, esto es lo que los une (ID-id)

    (let ((fragment (concat org-html--id-attr-prefix path))
    

  • ¿por qué le toca esto?
  • veo que en 5e9953fa0ea9023786e62d83e12653d4aadfa869 (m10.2022) cambió esto de ID-
    • esto fue tras mi implementación de org-exportar-mejores-ids.el

• simulo

  (org-html-link prueba1-link prueba1-desc prueba1-info)
  

• ah, veo org-html-prefer-user-labels, ¿qué es? → ver pruebas.org. Ya me va bien a nil
• <09.m04.2024 19:27> lo mando a lista de correo de org-mode
• lo corrigió Ihor. Creo que yo tenía otros problemas, pero éste está solucionado

Ej: pó da error.

El código lo parte en org.el, buscar por CONSTANTS.

Casi el mismo error que el anterior.

Visto con org-mode de <28.m11.2010>.

• cuáles no van: a/b ∀i a+c l*c (etiqueta) etc. Pasa con caracteres que no son alfanuméricos.
• no se lee tras C-c C-c
• no actualiza sino que añade al final
• no se resaltan
• yo quiero libertad para usar nombres de etiqueta; para mí es una necesidad real pues encontré este fallo al necesitar usar „∀idioma“ como etiqueta. Entiendo que mucha gente ni siquiera tiene „∀“ en su teclado, y por eso me cuesta que otros den importancia a correcciones como ésta.

Busco expregu que falla:

• C-c C-c empieza en org-set-tags
• (org-get-tags-string) ya lo lee mal (da "")
  • debido a: (looking-at (org-re ".*[ ]\[ ]*$"))
• lo malo es que esta expregu está en muchos lados de org (buscar por „alnum“). Tocará refactorizar algo para compartir expregus
• clases de caracteres: http://www.gnu.org/software/emacs/elisp/html_node/Char-Classes.html

Qué hay que pedir a org:

• I suggest to expand the character ranges in tags to allow some punctuation and symbol characters, including /.()[]{} and Unicode symbols (∴∀…∃→← etc) but excluding colon (:) and colon-equivalents (+,). This should allow tags like gnu/linux, with_friend(s), ∀day, version1.3, etc.
• [ ] pedir

Pues si deja la absoluta, hay probabilidad de que salga exportada. org-publish es listo y quita la ruta si coincide con la ruta real del fichero, pero si se ha movido de sitio el fichero para exportarlo (cosa que yo hago: lo muevo a otra rama), entonces eso fallará.

Lo que debería hacer es: si uso C-u C-c C-l y tecleo org.org para tener un enlace a org.html, tendría que grabar file:org.org en vez de una ruta absoluta.

No sé cómo creé el enlace, pero se me coló una ruta absoluta. Tengo que reproducir esto.

Tener varias secciones con el mismo ID es habitual si se tiene el mismo contenido replicado en varias ramas.

Ej: en index.html de rama ofinial me encontré este enlace:

(<a href="../../hacer/hacer/emacs.html#kp6lbta0yxe0">o emacs, que también puede</a>).

cuando debía ser realmente:

(<a href="emacs.html#kp6lbta0yxe0">o emacs, que también puede</a>).

Lo que pasa es que ha ido a buscar el fichero con ID kp6lbta0yxe0 a la rama „hacer“ en vez de a la actual („estructura“)

Para detectar salidas a otro proyecto, usar:

grey -r "../../hacer/" .

Soluciones posibles (ideas):

• en caso de id repetido, elegir el del fichero más cercano al fichero que se exporta ahora.
• pedirle a org manualmente antes de exportar que olvide todos los IDs de las otras ramas

Ej. un enlace a file:///home/dc/.emacs queda como:

<p>Ver <a href="/home/dc/.emacs">file:~/.emacs</a> al principio.</p>

Tres problemas:

• se está grabando y difundiendo la ruta real de ~. No sólo no quiero, sino que en cada ordenador donde lo exporte va a ser distinta, mientras que ~/.emacs es válido para todos
• si fuera un enlace a fichero debería llevar el file://
• cuando se exporta para Internet, lo más normal es no querer usar este tipo de enlaces. Pero no hay forma de desactivarlos, creo

Ej: este búfer.

one
<2010-04-23 vie>
* two

Entonces apretar C-c a L (~show timeline) y dice:

Debugger entered--Lisp error: (error "Before first headline at position 6 in buffer c.org")
  signal(error ("Before first headline at position 6 in buffer c.org"))
  error("Before first headline at position %d in buffer %s" 6 #<buffer c.org>)
  (condition-case nil (outline-back-to-heading invisible-ok) (error (error "Before first headline at position %d in buffer %s" ... ...)))
 org-back-to-heading(t)

Enviado a org el <23.m04.2010 19:58>

Ejecuto agact para mi agenda (200 ficheros, 76k líneas, 3'6 Mb, 1600 tareas abiertas en <23.m04.2010>):

• normal: 1m35s
• con bzr y git desactivados: 11s
• en otro ordenador: 1m7s vs 11s

Ya tengo una triquiñuela para acelerarlo; ver abajo mi mensaje a la lista.

No me sale a cuenta trabajar mucho para acelerar 1 minuto algo que uso semanalmente; ya llevo más de 5 horas investigando este tema y el límite son 4 h con un horizonte de 5 años.

• CONCLUSIÓN escrita el <12.m08.2013 10:50>
  „sticky agenda“, ya lo implementaron y va bien

Ahora mis ficheros .org no pasan de 10 Mb en 200 ficheros, pero ya empieza a ir lenta la agenda.

Con ficheros .org muy grandes (ej. 65 Mb. en 200 ficheros), me tarda unos 50 segundos en abrirse; incluso dos veces sucesivas. Debería ir más rápido las siguientes veces. Por ejemplo:

• [ ] [#A] detectando que muchos búfers no han cambiado últimamente (mirando el tiempo de última modificación y comparando con la hora de la última agenda)
  • hace falta caché
    • ¿en memoria o en disco?
• [#C] decidiendo voluntariamente no releer algunos ficheros grandes que han cambiado hace poco, a menos que se fuerce (ej. con prefijo)
  • esto ya se puede hacer con diferentes vistas de agenda, unas incluyendo esos ficheros, otras no

Proceso:

• [] buscar
• [] intentar acelerar la carga saltándose ficheros no cambiados
• [] sugerir en lista org
• ∴ ya lo implementaron; „sticky agenda“

Por ejemplo identifiqué esto como fallante:

*** un                                                  :taskjuggler_project:
**** dos
******* IS tres

En cambio quitándole un asterisco al „tres“ ya iba. El error era más o menos: "Not a valid effort"

Luego descubrí que cerrando el fichero y volviéndolo a abrir ya iba. Con cualquier fichero.

Pues son erróneos según TaskJuggler.

Ej.

task int_ "INT: interfície web per connectar-se al servidor de mapes" {
  effort 84h
  start 2010-10-05

task configurar "configurar openLayers per fer de visor" {

}

…

Esto da error

/home/dc/.mirp/taskj.tjp:18: Container task 'parts.int_' may not have a duration criteria in 'plan' scenario

Y es porque int_ es un contenedor y por eso no puede definir ni effort ni start, aunque yo lo hice en org (sí que puedo y me va bien). O bien TaskJuggler debería aceptarlo, o bien org no exportarlo.

Ej: esto falla (nil):

(org-publish-get-project-from-filename "~/repoweb/hacer/hacer/conkeror.org")

El fichero existe y el proyecto está definido; lo que pasa es que acaba haciendo una expregu del estilo:

"^/home/dc/repoweb/hacer/.+\\.\\(\\)$"

Que no ligará porque ningún fichero mío acaba en punto. El fallo es debido a no haber definido :base-extension en la definición del proyecto

Parche mandado a lista:

diff --git a/lisp/org-publish.el b/lisp/org-publish.el
index b387e7b..a50cf56 100644
--- a/lisp/org-publish.el
+++ b/lisp/org-publish.el
@@ -466,7 +466,7 @@ matching filenames."
 	  ;; [[info:org:Selecting%20files]] shows how this is supposed to work:
 	  (let* ((r (plist-get (cdr prj) :recursive))
 		 (b (expand-file-name (plist-get (cdr prj) :base-directory)))
-		 (x (plist-get (cdr prj) :base-extension))
+		 (x (or (plist-get (cdr prj) :base-extension) "org"))
 		 (e (plist-get (cdr prj) :exclude))
 		 (i (plist-get (cdr prj) :include))
 		 (xm (concat "^" b (if r ".+" "[^/]+") "\\.\\(" x "\\)$")))

http://patchwork.newartisans.com/patch/112/

Ver si lo incluyen. Sí, aceptado el <07.m07.2010>.

• [X] „Symbol's value as variable is void: org-list-automatic-rules“, mandado a lista el <07.m09.2010>, es por fd16515b4a88d48362223b19c511c4973cdbc84c. http://thread.gmane.org/gmane.emacs.orgmode/29968 ← más bien problema de la sintaxis que usé
• [X] etiquetas radio no van por ejemplo ésta, si hay algún carácter detrás (ej. la coma en ese ejemplo)
  • es por ce8819f18d9d2be000fb70fc4d74b5d96fe07a83, en org-element
  • avisado y corregido
• [X] etiquetas radio demasiado enlazadas, concuerdan hasta dentro de palabra (ej „c“ dentro de „casa“)
• [X] etiquetas radio iluminan los espacios en blanco de alrededor
• [X] se me cuelga con un fichero de agenda
• [X]

  avl-tree.el tenía fallo, mandé este parche

  (if (version< emacs-version "24") (defmacro avl-tree–root (tree) ;; Backport fix for older versions due to missing comma in ,tree `(avl-tree–node-left (avl-tree–dummyroot ,tree))) )

• informado el <05.m12.2014 20:03> a lista. http://lists.gnu.org/archive/html/emacs-orgmode/2014-12/msg00091.html
  • sigue: http://lists.gnu.org/archive/html/emacs-orgmode/2015-01/msg00189.html
• el <09.m01.2015> mando 2 propuestas que creo que se acercan mejor a soluciones aceptables por ambos
• afecta al org-shiftmetaright, o sea al „R“ de speed-commands

• cambio nuevo de <31.m10.2021>
• por mirar: org-cycle-emulate-tab

• esto en un búfer HTML que no tiene relación con org

  <tab> runs the command orgtbl-hijacker-command-102 (found in orgtbl-mode-map), which is an interactive Lisp function.

  It is bound to <tab>.

  (orgtbl-hijacker-command-102 ARG)

  In tables, run ‘orgtbl-tab’. Outside of tables, run the binding of ‘<tab>’ or ‘TAB’.

• en efecto me alínea tablas. ¡Pero no quiero meter tablas org en un .html directamente!

• CONCLUSIÓN escrita el <06.m08.2014 13:49>
  corregido en emacs

Qué absurdo. Tras el (require 'tramp-cache) org-babel deja de funcionar. Es por esto:

(add-hook 'kill-buffer-hook 'tramp-flush-file-function)

• bug#18095: http://lists.gnu.org/archive/html/bug-gnu-emacs/2014-07/msg00736.html

,#+TITLE: Custom time stamps don't work
,#+DATE: seen today with Org-mode version 7.4 (release_7.4.553.g83b7), Emacs 24.0.50.1 from december 2010

Open this file and use =C-c e H=. Review and accept the usage of the 2 BIND values in this buffer. See timestamps in HTML output.

# This doesn't work (the time stamps remain intact: <2011-02-28> instead of 28.m2.2011):
#
,#+BIND: org-time-stamp-custom-formats ("<%d.m%m.%Y>" . "<%d.m%m.%Y %H:%M>")
# An invalid value produces no error; try this:   #+BIND: org-time-stamp-custom-formats 42
#
# I think this was needed:
,#+BIND: org-display-custom-times t
#
# This works if activated: it shows the custom time stamp while editing (but not on export)
# #+STARTUP: customtime



One timestamp: <2011-02-28 lun>. No

Another:

<2011-02-28 lun>

• [X] enviado a lista. http://permalink.gmane.org/gmane.emacs.orgmode/38489
• probado en 2 equipos, fallan ambos

• bisección

  • desde 52b07a584c1b6ee7444065497acdf100716d6701 hasta efa562c1ee7cd857d3cf8c3e47d44b9ae1bb25d4.
  • Resultado (mandado a lista):

  163cd58ffd6461c98a96b1b63a3cf082b2825a52 is the first bad commit
  commit 163cd58ffd6461c98a96b1b63a3cf082b2825a52
  Author: David Maus <dmaus@ictsoc.de>
  Date:   Fri Jan 14 06:37:52 2011 +0100
  
      Handle timestamps after handling links
  

• [X] lo corrigen el <13.m03.2011>, ya funciona bien

Ej. en index.html

-<li><a href="#txt2tags">3.2.1 txt2tags </a></li> -<li><a href="#dislines">3.2.2 dislines </a></li> -<li><a href="#schart">3.2.3 schart.pl (va de malabares) </a></li> +<li><a href="#sec-3_2_1">3.2.1 txt2tags </a></li> +<li><a href="#sec-3_2_2">3.2.2 dislines </a></li> +<li><a href="#sec-3_2_3">3.2.3 schart.pl (va de malabares) </a></li>

Bisecciono:

• org-mode el 23.m3 iba bien → e5340a365022f19a12e7424d781d688889e191f8 más o menos es bueno
• actual, c4737ae48b84308e1ac201531aca392a81529974 es malo
• ∴ es obviamente por 438536f6157794101ce0957e39cad6bf70580751, „Change underscores to hyphens in section labels“, de <19.m05.2011>
• [X] avisado a org-mode el <12.m06.2011 00:42>
• [X] llega parche; va

• CONCLUSIÓN escrita el <02.m12.2017 01:43>
  de hace años, y parece que no pasa ya

Lo mandé el <22.m10.2011>:

Hi,
  with org-mode from today I created a file miso.org with this content:
---------------------------------------------------
,* aaa
  :PROPERTIES:
  :CATEGORY: bbb
  :END:
,** TODO ccc
----------------------------------------------------

  Then I used an ~/.emacs which said:
----------------------------------------------------
(progn (add-to-list 'load-path "/w/org-mode/lisp") (require 'org-install) (require 'org) (require 'org-agenda))
(org-agenda-get-day-entries "/home/dc/miso.org" '(10 22 2011) :todo)
----------------------------------------------------


  And after running „emacs“ I got:
----------------------------------------------------
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("^ +" nil)
  (if (string-match "^ +" txt) (setq txt (replace-match "" nil nil txt)))
  (progn (if (string-match "^ +" txt) (setq txt (replace-match "" nil nil txt))) (setq txt  …
  (unwind-protect (progn (if (string-match "^ +" txt) (setq txt (replace-match "" nil nil tx…
  (let ((save-match-data-internal (match-data))) (unwind-protect (progn (if (string-match "^ +" txt) …
  (save-match-data (if (string-match "^ +" txt) (setq txt (replace-match "" nil nil txt))) (setq …
  org-format-agenda-item("" nil #("bbb" 0 3 (fontified nil org-category "miso")) nil)
  (setq marker (org-agenda-new-marker (match-beginning 0)) category (org-get-category) txt (match-string 1) …
  (catch :skip (save-match-data (beginning-of-line) (setq beg (point) end (save-excursion (out…
  (while (re-search-forward regexp nil t) (catch :skip (save-match-data (beginning-of-line) (se…
  (let* ((props (list (quote face) nil (quote done-face) (quote org-agenda-done) (quote org-not…
]*\\)")) marker priority category tags todo-state ee txt beg end) (goto-char (point-min)) (whil…
  org-agenda-get-todos()
  (setq rtn (org-agenda-get-todos))
  …
----------------------------------------------------


  The second time I ran the code from .emacs I got it right:
----------------------------------------------------
(#("TODO ccc" 0 8 (org-category #("bbb" 0 3 ...) fontified nil tags nil org-highest-priority 65 org-lowest-priority 67 prefix-length 0 ...)))
----------------------------------------------------

  Which seems to be inappropriate, as in previous versions I get:
----------------------------------------------------
(#("TODO ccc" 0 8 (fontified nil org-category nil tags nil org-highest-priority 65 org-lowest-priority 67 prefix-length 0 ...)))
----------------------------------------------------



  Via git bisect I traced the bug to:
----------------------------------------------------
ca733df0d41eccced5f8f1abb85d525cb12dd21f is the first bad commit
commit ca733df0d41eccced5f8f1abb85d525cb12dd21f
Author: Carsten Dominik <carsten.dominik@gmail.com>
Date:   Mon Jan 3 13:12:42 2011 +0100

    Move the category property refresh to org-get-category where possible
----------------------------------------------------



  Greetings,

Daniel

Espero respuesta

• CONCLUSIÓN escrita el <03.m12.2013 13:54>
  ya pasé todo a v8, ya va bien

• [X] org-publish-org-to-html es llamado con demasiados argumentos argumentos en orden que no toca
  • mandé a emacs-orgmode@gnu.org el <27.m11.2013 11:59> un mensaje
• nuevas variables
• [X] org-display-custom-times ya no va, ox-html no lo usa
  • sí que lo usa: ox-html llama a org-translate-time
  • está en 4 lados (schedule/deadline/closed/CLOCK), pero falta en marcas de tiempo comunes
  • está también org-timestamp-translate, que lo hace
  • [X] org-translate-time está fallando
    • es porque org-display-custom-times == nil, porque de hecho lo quiero para exportación sólo
    • ∴ no falla, sino que está añadiendo <> a mi formato, ẽ <12.m2.2013>
    • [X] aceptar que tendré <> y reexportar así
    • pero en exporta-org va
  • [X] parece que los #+BIND no van, pongo error y no peta → nueva var.
    • [X] nueva var
    • [X] los lee porque ahora da error si intento t=nil
    • [X] probar más
• [X] {{{input-file}}} dentro de #+MACRO no va (fuera, sí) → lo cambio/quito
• [X] actualizado hasta {{{date(%e.m%m.%Y)}}} no va → usar time
• [X] „[TABLE-OF-CONTENTS]“ no va
  • [X] ahora hay #+TOC, http://orgmode.org/manual/Table-of-contents.html
  • [X] creo que no necesito índice
• [X] no publica bien porque al exportar un trozo C quiere activar flymake
• [X] añadir mi JS (menú, esquemadorg), para eso necesito exportar con org-publish, creo
  • [X] quizás necesito sistema nuevo para decir preámbulo/postámbulo
    • http://orgmode.org/manual/HTML-preamble-and-postamble.html
    • no, parece que preámbulo va bien, y post no hay
  • [X] aparte, cabecera de página
    • ya no es :style, ahora… mejor usaré #+HTML_HEAD_EXTRA: y así lo saco de org-publish y lo dejo dentro de .org
• [X] probar con JS
• [X] reexportar hasta que salga lo mismo que ya tenía, y luego entrarlo
• [X] peta exportación por usar la palabra funcall_lambda (se queja de „lambda“) y Fcall_interactively (se queja de „interactively“)
• [X] exportar lo nuevo y comprobar que tampoco da error

Hi, in ox-html.el there's a line with an assert (the only one):

(assert (org-uuidgen-p path))

1. I have some IDs like "o5y98600aze0" which don't conform to that uuidgen format; they were created by early versions of org. Should only UUIDs be accepted as ID?

2. I think the ID should be editable by hand to what you like, as long as they are unique. If you don't need to export it you don't need a CUSTOM_ID, and having both ID and CUSTOM_ID is not the simplest way.

   So I think that assert is too strict. My short IDs seem as good as the long UUIDs.

• [X] avisado a org
• se corrigió

• mandé mensaje a lista el <12.m08.2013>
• org-agenda-ignore-properties
• [X] mandado parche el <23.m08.2013>
• Carsten añadió org-agenda-ignore-drawer-properties
• [X] mirarlo, comprobarlo
  • [X] en agenda normal va, la reduce 1'60 segundos
  • [X] en agenda normal no lo noto, ¿por qué? De 54 a 54 (o sea, los dos van rápida, e igual de rápido)
    • he vuelto a versión anterior, y no lo puedo reproducir
    • deduzco que lo que ha cambiado ha sido mi agenda → por tanto es muy difícil probar esto. No importa, el cambio es a mejor
• [] escribir en Worg ← lo hizo Carsten
• [X] añadir a mi configuración

: dc; ~/repoweb/hacer ; g ' nil[A-Z]'
bazaar.html
189:46:<li><a href="#sec-1-2">1.2. <span class="done nilIS">IS</span> Primera contribución: documentación</a>

∴ Postprocesado eficaz:

find . -type f -name '*.html' | xargs sed -i 's/nil\([A-Z]\+\"\)/\1/'

Me he tenido que hacer un tipo de enlace nuevo. No sé si funciona del todo…

Unknown cross-reference "return" in file "/w/conkeror/modules/element.js"
Unknown cross-reference "return%20make_uri%20read_from_x_primary_selection%20spec" in file "/w/conkeror/modules/element.js"

Y luego:

-Tocar esto: <a href="file:///w/conkeror/modules/element.js#return%20make_uri%20read_from_x_primary_selection%20spec"><a href="file:///w/conkeror/modules/element.js#return">file:///w/conkeror/modules/element.js#return</a> make_uri read_from_x_primary_selection spec</a> +Tocar esto: <a href="file:///w/conkeror/modules/element.js#MissingReference"><a href="file:///w/conkeror/modules/element.js#MissingReference">file:///w/conkeror/modules/element.js#MissingReference</a> make_uri read_from_x_primary_selection spec</a>

Es por: org-publish-resolve-external-link

∴ Da igual, me puede dejar el MissingReference.

Con esto:

<<<a>>>
a-bug

Mandé informe: http://lists.gnu.org/archive/html/emacs-orgmode/2016-10/msg00395.html

Esto el <27.m07.2017> al actualizar.

15:00̠ϨҰոـ܈ߐ ATENDAS

Lo dejo, queda bonito. Pero parece memoria corrompida; quizás esos datos son por zona horaria o algo así.

user-error: Cannot modify an area being edited in a dedicated buffer

Es culpa mía, pero quiero poder arreglarlo.

∴ Hacerlo a mano en región:

(remove-overlays)

Y es porque el búfer „*Clock Task Select*“ contiene un texto con propiedad read-only.

There are text properties here:
  :org-clock-minutes   922
  :org-clock-minutes-today 40
  face                 org-level-6
  fontified            t
  org-category         "Vojaĝe"
  read-only            "Type ‘e’ to edit property"

Quizás el fallo está en org-clock-insert-selection-line

El título en concreto no tiene read-only ni propiedades.

1. Doble clic un algo con utf-8 en urxvt.
2. Esto ya falla: (x-get-selection 'PRIMARY)

∴ Aaaaah, esto va: (x-get-selection 'PRIMARY 'UTF8_STRING)

Sólo pasa en mi implementación.

• [X] ∴ me gustaría con propiedad tipo HTML_HEAD pero no hay
  • quiero una propiedad (local a cabecera exportada) que defina la cabecera a usar
  • ∴ veo que hay algo llamado EXPORT_HTML_HEAD. Funciona
• file:///home/dc/org/desa/bug-localstyle.html para probar
• creo que es por diseño: https://orgmode.org/guide/Export-options.html dice que estas líneas se pueden poner en cualquier lugar del fichero
  • esto es poco intuitivo, aunque la alternativa quizás es peor
• ¿y qué hay entonces para decir el estilo de una cabecera?
• mmmmmmmmmmmmm… esto me fuerza a usar un mismo CSS para todos mis ficheros. No es tan malo (me enseñaría a mantener un poco el diseño), pero es cutre y complejo.
• usar BEGIN_EXPORT html en vez de esto. Es cutre tener que hacer esto, y no puedo usar „<link>“
  • sólo funciona si quería meter un <style> directamente
  • pero no puedo hacer <style src"…">=, eso necesita un <link>
• está lo de definir un proyecto (org-publish), etc.
  • pero muy manual
• me puedo adaptar con esta combinación
  • si quiero algo local, usar BEGIN_EXPORT (nunca HTML_HEAD), y usar sólo <style> con todo el CSS metido dentro (nunca <link>)
  • o sea: prohibido usar un fichero externo que estila una cabecera local ← es mala práctica, es incómodo, pero es pasable
  • sin embargo, puedo (y me iría bien) un fichero externo pueso en <link> en un HTML_HEAD, que afecta a todas las cabeceras
• escribir a org-mode

Lisp Backtrace: "re-search-forward" (0x25e01d70) "org-find-open-clocks" (0x25e020a8) "org-resolve-clocks" (0x25e02430) "org-clock-in" (0x25e02ac0) "funcall-interactively" (0x25e02ab8) "call-interactively" (0x25e02cf0) "command-execute" (0x25e03068)

• org-find-open-clocks, podría usar caché
  • ẽ (org-find-open-clocks "~/org/pruebas.org")
• lo puedo acelerar mucho si me salto el org-resolve-clocks. No lo necesito para presentar un menú
• mmm… algo ya hace alguna caché, pues luego es más rápido

• CONCLUSIÓN escrita el <09.m11.2019 00:07>
  ver siguiente apartado. Y probablemente se corrigió con el gpg2

Lisp Backtrace:
"accept-process-output" (0xda824720)
"epg-wait-for-status" (0xda824a80)
"epg-start-decrypt" (0xda824e08)
"epg-decrypt-string" (0xda825168)
"org-decrypt-entry" (0xda825670)
"funcall-interactively" (0xda825668)
"call-interactively" (0xda825780)
"command-execute" (0xda825b28)
"execute-extended-command" (0xda825fd0)
"funcall-interactively" (0xda825fc8)
"call-interactively" (0xda826230)
"command-execute" (0xda8265a8)

dc 14180 0.0 0.0 154692 3200 ? SNsl Nov07 0:00 gpg-agent –homedir home/dc.gnupg –use-standard-socket –daemon dc 6284 0.0 0.0 6664 3428 ? SNL 01:20 0:00  pinentry –display :0

Es:

(epg-error "Encrypt failed" "Exit")

Pasa en: (org-encrypt-string "hola holita" "") es lo que da error.

¿La clave debería ser ""? Parece que no. Lo es porque (org-crypt-key-for-heading) devuelve "". ¿No debería preguntar una?

(epg-list-keys (epg-make-context nil t t) "" ; crypt-key )

Probando otras cosas descubro:

Error while encrypting with "gpg1": gpg: Invalid option "–pinentry-mode"

∴ Aaaaaaah, creo que era por esto, lo había toqueteado:

epg-pinentry-mode is a variable defined in ‘epg-config.el’. Its value is ‘loopback’ Original value was nil

De todas formas actualicé cosas para usar más gpg2 en otros lados.

cl--assertion-failed: Assertion failed: (or (equalp format 'html) (equalp format 'ascii))

∴ Era por mi exporta-enlace-org-nntp sin implementar.

• aquí se colgaba

  "org-element--cache-compare" (0xa9a172d8)
  "avl-tree--do-delete" (0xa9a176c8)
  "avl-tree--do-delete" (0xa9a17ab8)
  "avl-tree--do-delete" (0xa9a17ea8)
  "avl-tree--do-delete" (0xa9a18298)
  "avl-tree--do-delete" (0xa9a18670)
  "avl-tree-delete" (0xa9a189f8)
  "org-element--cache-process-request" (0xa9a194c0)
  "org-element--cache-sync" (0xa9a19880)
  "org-element--cache-submit-request" (0xa9a19ef8)
  "org-element--cache-after-change" (0xa9a1a2e8)
  "insert-file-contents" (0xa9a1e860)
  "revert-buffer-insert-file-contents--default-function" (0xa9a1ebf0)
  "revert-buffer--default" (0xa9a1efb8)
  "revert-buffer" (0xa9a1f2a8)
  "vc-revert-buffer-internal" (0xa9a1f5b0)
  "vc-resynch-window" (0xa9a1f8f0)
  "vc-resynch-buffer" (0xa9a1fc18)
  "vc-revert-file" (0xa9a20000)
  "vc-revert" (0xa9a20570)
  

• me pasa mucho en Zeitmanagement.org, no en otros
  • ¿quizás porque uso lo de „capture“ para colocar entradas ahí?
• me ha pasado que veces repetidas hacen este problema (desordenar la lista): lo puedo repetir ẽ 10 veces. Incluso teclear algo, y al empezar a cronometrar ya lo desordena
• pasa ¿sólo? en una sección mía, agenda para hoy, donde tengo >360 CLOCK
  • me pasó otra vez en ésa y rato después en día equilibrado (1ª vez que me pasa en otra), que tiene muy pocos cronómetros (<30)
• pasa cuando aprieto I en la cabecera. Pasa también con C-cxi, no sólo con I
• pasa sólo cuando llevaba un rato largo sin usar org-mode, ẽ justo tras deshibernar. Pero pasa cuando llevo horas trabajando en otros ficheros (grabando, cronometrando, escribiendo, …) y luego voy al agenda para hoy

• cuando pasa, pasa esto:

  "org-element–current-element" (0xdd56ce80) "org-element–parse-to" (0xdd56d478) "org-element-at-point" (0xdd56d7c0) "org-indent-region" (0xdd56dd18) "org-indent-region" (0xdd56e228) "org-clock-find-position" (0xdd56e6a0) "org-clock-in" (0xdd56ed30) "funcall-interactively" (0xdd56ed28) "call-interactively" (0xdd56ef38) "org-self-insert-command" (0xdd56f3e0) "funcall-interactively" (0xdd56f3d8) "call-interactively" (0xdd56f610) "command-execute" (0xdd56f988)

• si deshago y repito, va
• Org mode version 9.3.7 (release_9.3.7-708-g5417e3.dirty @ /w/org-mode/lisp/)

• parece que cree que esto es necesario:

  ;; When a clock drawer needs to be created because of the ;; number of clock items or simply if it is missing, collect ;; all clocks in the section and wrap them within the drawer.

  • tengo (setq org-clock-into-drawer "CLOCK")
• [ ] aún me falta poder reproducir esto
• [ ] esto es sospechoso pero no creo que esté relacionado: org-log-states-order-reversed
• ¿me pasa con otras cabeceras que tengan muchas entradas?
• tengo otras secciones con más de 3000 cronómetros y no pasa
• en situación en que probablemente iba a pasar:
  • [X] pruebo a copiar+pegar esa cabecera a otro fichero y cronometrarla en el otro, no me falla. Justo después en Z….org, y falla
  • [X] pruebo a borrar todo lo anterior a esa cabecera; entonces no pasa
  • [ ] pruebo a borrar todo lo siguiente a esa cabecera. Lo probé 1 vez y no pasaba. Por reprobar

  • me ha pasado incluso al borrar todo, con un documento tan sencillo como una sola línea: * cabecera. Al empezar a cronometrar, se cuelga

    "org-element–cache-compare" (0xc61d8668) "avl-tree–do-delete" (0xc61d8a58) "avl-tree–do-delete" (0xc61d8e48) "avl-tree–do-delete" (0xc61d9238) "avl-tree–do-delete" (0xc61d9610) "avl-tree-delete" (0xc61d9998) "org-element–cache-process-request" (0xc61da460) "org-element–cache-sync" (0xc61da7f8) "org-element-at-point" (0xc61dab40) "org-indent-region" (0xc61db080) "org-clock-find-position" (0xc61db500) "org-clock-in" (0xc61dbb90) "funcall-interactively" (0xc61dbb88) "call-interactively" (0xc61dbd98)

  • [ ] he de probar a grabar ese fichero sencillo (1 sola línea) con otra línea y abrirlo en fresco, y ver si pasa. Así evito cachés
• quizás me pasa por ser la 1ª operación en mucho rato
  • y por tanto si hago otra (ẽ añadir letra, borrarla y entonces cronometrar) ya no pasará

• lo puedo reproducir con:

  (org-element--cache-sync (current-buffer))
  

  • y también con:

    (org-element--parse-to 694818 t '(92111111111111111111111111111111 . 56294995342131200000000))
    

  • por cierto, esa posición es la línea que dice desde [2018-05-01 Tue] lo apunto

  • eso da:

    (wrong-type-argument integer-or-marker-p nil)
    

  • es por esta línea en org-element--parse-to:

    (goto-char (or next cbeg))
    

    • ambos (next, cbeg) son nil
  • no investigué por qué. Cambié un poco el orden de las líneas, para ver si ayuda. Probando…

Curioso pues ya tengo:

(setq org-id-link-to-org-use-id 'create-if-interactive-and-no-custom-id)

Se ha estropeado al actualizar.

e7f625d42 org-contacts.el: Fix org-store-link error caused by org-contacts

Eso lo arregló.

• (org-encrypt-entries)
• esto trabajando con búfer grande (9'5 Mb)
• y sólo si estoy puesto en el búfer
• „org-crypt: Re-encrypting all decrypted entries due to auto-save.“, es esto lo lento
• org-crypt-disable-auto-save
• mmmmm… cierto. Si dejo activado auto-save, se pueden exfiltrar secciones que he descifrado temporalmente

• ∴ por ahora: comprobar que no quedan secciones descifradas, entonces ir a búfer concreto, y hacer M-x:

  (setq auto-save-hook nil)
  

• "org-element-cache-map" (0x8b67d678) "org-element-cache-map" (0x8b67d388) "org-agenda-get-deadlines" (0x8b67d310) "org-agenda-get-day-entries" (0x7fdfbfc8) "apply" (0x8b67d250) "org-agenda-list" (0x7fdfc180) "funcall-interactively" (0x7fdfc178) "call-interactively" (0x8b67d118) "org-agenda" (0x7fdfc440) "funcall-interactively" (0x7fdfc438) "call-interactively" (0x8b67d070) "command-execute" (0x7fdfc6d8) $2 = "Fin de xb…" [Inferior 1 (process 352) detached]

• org-mode se está burocratizando… No sé lo que está haciendo org-element-cache; no hace lo que quiero; me ralentiza; produce alertas; causa pequeñas desincronizaciones; se pone a hacer cosas contrarias a las que pido (ej. empieza a computar cosas durante minutos cuando le pido cerrar Emacs. ¡Como si fuera Windows!); y no veo que acelere nada. Espero que encuentren mejores formas de acelerar Emacs

• otros errores incomprensibles que veo mucho:

  Warning (org-element-cache): org-element--cache: Warning(X.org): (org-cycle) Cached element is incorrect in X.org. (Cache tic up to date: "yes") Resetting.
  If this warning appears regularly, please report the warning text to Org mode mailing list (M-x org-submit-bug-report).
  

  • ¿si aparece poco no es malo? Discrepo. Este mensaje no ha de salir nunca, y lo que hay que hacer es corregir eso de „Cached element is incorrect“. Quizás ayuda el explicar por qué pasa

• Org mode version 9.5.3 (release_9.5.3-465-g82a09b.dirty @ /w/org-mode/lisp/)

• ej. de <06.m05.2022 12:45>

  "generate-new-buffer-name" (0xd2c39320)
  "generate-new-buffer" (0xd2c392a0)
  "org-string-width" (0xd2c39228)
  "org-table-align" (0xd2c39138)
  "org-table-next-field" (0x13f9f870)
  "funcall-interactively" (0x13f9f868)
  "call-interactively" (0xd2c390f0)
  "org-cycle" (0x13f9fa00)
  "funcall-interactively" (0x13f9f9f8)
  "call-interactively" (0xd2c39070)
  "command-execute" (0x13f9fc98)
  

• org-string-width es función muy compleja. No sé por qué tiene que generar un búfer…

• otra vez

  "Automatic GC" (0x0)
  "functionp" (0xd2c39548)
  "switch-to-prev-buffer" (0xd2c394c8)
  "replace-buffer-in-windows" (0x13f9f308)
  "kill-buffer" (0xd2c39470)
  0x43bf0a68 PVEC_COMPILED
  "org-string-width" (0xd2c39390)
  "org-table--align-field" (0x13f9f598)
  "apply" (0xd2c39330)
  "cl--mapcar-many" (0xd2c39298)
  "cl-mapcar" (0xd2c39230)
  "org-table-align" (0xd2c39138)
  "org-table-next-field" (0x13f9f870)
  

• otra vez

  "font-lock-fontify-keywords-region" (0xd2c39610)
  "font-lock-default-fontify-region" (0xd2c39550)
  "org-fold-core-fontify-region" (0xd2c394c0)
  "font-lock-fontify-region" (0xd2c39450)
  0x66ed2648 PVEC_COMPILED
  "run-hook-wrapped" (0xd2c393d8)
  "jit-lock--run-functions" (0xd2c392f8)
  "jit-lock-fontify-now" (0xd2c39290)
  "org-font-lock-ensure" (0xd2c391a0)
  "org-table-align" (0xd2c39138)
  "org-table-next-field" (0x13f9f870)
  

• más

  "version-to-list" (0xd2c39328)
  "version<" (0xd2c39290)
  "org-string-width" (0xd2c39228)
  "org-table-align" (0xd2c39138)
  "org-table-next-field" (0x13f9f870)
  "funcall-interactively" (0x13f9f868)
  "call-interactively" (0xd2c390f0)
  "org-cycle" (0x13f9fa00)
  "funcall-interactively" (0x13f9f9f8)
  "call-interactively" (0xd2c39070)
  "command-execute" (0x13f9fc98)
  

• 11300 90% - command-execute 11300 90% - call-interactively 11300 90% - funcall-interactively 11266 90% - orgtbl-hijacker-command-6 11266 90% - if 11197 89% - call-interactively 11197 89% - funcall-interactively 11197 89% - org-table-insert-row 11005 87% - org-table-align 5399 43% - cl-mapcar 5387 43% - cl–mapcar-many 5331 42% - org-table–align-field 4432 35% - org-string-width 1508 12% + version< 1292 10% + #<compiled -0x1c8b1fbe74e16a3f> 700 5% generate-new-buffer 444 3% + #<compiled -0x461035e5c5f10a0> 408 3% + record-window-buffer 4488 35% + org-string-width 4 0% + font-lock-ensure 4 0% + org-table–list-shrunk-columns 4 0% + #<compiled -0x221d3aeb5947b5c> 12 0% + org-table-clean-line 8 0% + org-fold-core–fix-folded-region 8 0% + org-table-fix-formulas 4 0% + org-element–cache-after-change 69 0% + org-at-table-p

• ver hilo „Table refresh very slow“ de <23.m12.2022> en lista org-mode

• luego veo que es por element-cache

  7040  81% - command-execute
  7040  81%  - funcall-interactively
  3389  39%   + undo
  2859  32%   - org-metaright
  2794  32%    - call-interactively
  2794  32%     - funcall-interactively
  2770  31%      - org-table-move-column
  1974  22%       - org-element--cache-after-change
  1838  21%        - org-element--cache-submit-request
  1726  19%         - org-element--cache-for-removal
  1407  16%          - org-element-headline-parser
     4   0%           + rx-to-string
     4   0%             replace-regexp-in-string
    15   0%            org-at-comment-p
     4   0%            org-element-set-element
     4   0%            org-element--cache-find
    92   1%          org-element--cache-before-change
    12   0%        + run-with-idle-timer
   332   3%       + org-table-align
   240   2%       + org-fold-core--fix-folded-region
    68   0%         org-element--cache-before-change
     8   0%         org-at-table-hline-p
     8   0%       + jit-lock-after-change
     4   0%       + org-table--list-shrunk-columns
     4   0%       + org-table-fix-formulas
    65   0%    + org-at-table-p
  

  • no tengo ganas de investigar tanto org-element. Ya me da muchos problemas por otros lados

• de m4.2022:

  "Automatic GC" (0x0)
  "buffer-modified-tick" (0xcd39a418)
  0x3dc27a40 PVEC_COMPILED
  "org-persist--normalize-associated" (0xcd39a320)
  "org-persist-write" (0xcd39a2b0)
  "org-persist-write-all" (0xcd39a248)
  0xcdba1bf0 PVEC_COMPILED
  "run-hook-wrapped" (0xcd39a208)
  "run-hook-query-error-with-timeout" (0x95ae0098)
  "kill-emacs" (0x95ae0160)
  "funcall-interactively" (0x95ae0158)
  "call-interactively" (0xcd39a1a8)
  "command-execute" (0xcd39a108)
  "execute-extended-command" (0x95ae0410)
  "funcall-interactively" (0x95ae0408)
  "call-interactively" (0xcd39a070)
  "command-execute" (0x95ae0698)
  

• <10.m11.2022> pasa, con versiones nuevas

• aquí se atasca

  "org-element-clock-parser" (0x2525508) "org-element–current-element" (0x25259a8) "org-element–parse-to" (0x2525b18) "org-element–cache-verify-element" (0x2525e80) "org-element-at-point" (0x2525f78) "org-clock-sum" (0x2526288) "org-clock-sum-current-item" (0x2526358) "org-clock-in" (0x2526470) "funcall-interactively" (0x2526468) "call-interactively" (0x69e70040) "org-self-insert-command" (0x2526740) "funcall-interactively" (0x2526738) "orgtbl-self-insert-command" (0x25269f0) "funcall-interactively" (0x25269e8) "command-execute" (0x2526cc8)

• maldita caché de org-element… ¡Tarda más con caché que sin! Tengo que probar a desactivarla

• otra vez

  "match-string-no-properties" (0x2524f18) "org-element-timestamp-parser" (0x25252b0) "org-element-clock-parser" (0x2525508) "org-element–current-element" (0x25259a8) "org-element–parse-to" (0x2525b18) "org-element–cache-verify-element" (0x2525e80) "org-element-at-point" (0x2525f78) […]

• <28.m12.2022 11:50> tras actualizar emacs y org:

  6762 82% - command-execute 6523 80% - funcall-interactively 6504 79% - org-self-insert-command 6504 79% - call-interactively 6504 79% - funcall-interactively 6504 79% - org-clock-in 5712 70% - org-clock-sum-current-item 5676 69% - org-clock-sum 5584 68% - org-element-at-point 5556 68% - org-element–cache-verify-element 5456 66% - org-element–parse-to 4500 55% - org-element–current-element 1876 23% - org-element-clock-parser 876 10% - org-element-timestamp-parser 412 5% org-parse-time-string 40 0% org-element-section-parser 28 0% + org-get-limited-outline-regexp 8 0% org-element-headline-parser 4 0% #<compiled 0xad42f194f400f> 12 0% + org-element–cache-sync 8 0% org-element–parse-to 80 0% + org-time-string-to-seconds 8 0% #<compiled 0xad42f194f400f> 772 9% - org-resolve-clocks 12 0% - org-files-list 8 0% + org-agenda-files 4 0% mapcar 8 0% + org-indent-line 4 0% + org-get-heading 4 0% + org-in-item-p 4 0% + insert-and-inherit

• esto el <07.m12.2022> en búfer grande (3'8 Mb) (aunque no tan grande como los otros que tengo)

• perfilado de cpu

  45,018,289 98% - command-execute 45,018,289 98% - call-interactively 37,768,329 82% - funcall-interactively 33,393,363 72% - org-self-insert-command 33,315,267 72% - self-insert-command 31,848,807 69% - org-element–cache-after-change 31,378,572 68% - org-element–cache-submit-request 500,624 1% - org-element–cache-for-removal 288,952 0% - org-element-headline-parser 142,144 0% + replace-regexp-in-string 24,552 0% + rx-to-string 17,408 0% org-element–parse-objects 83,400 0% org-at-comment-p 4,168 0% + run-with-idle-timer 555,296 1% + org-fold-core–fix-folded-region 106,096 0% + jit-lock-after-change 96 0% + undo-auto–undoable-change 33,776 0% org-fix-tags-on-the-fly 21,552 0% org-at-table-p 2,048 0% run-hook-with-args-until-success 3,870,951 8% + execute-extended-command 504,015 1% + org-return 7,249,960 15% + byte-code 879,642 1% + redisplay_internal (C function) 4,144 0% internal-echo-keystrokes-prefix 296 0% + timer-event-handler

  • esto en: Org mode version 9.6 (release_9.6-3-ga4d38e @ w/org-mode/lisp)
• otra vez digo: maldita caché. Muchas cosas parecen más lentas con caché que sin
• ¿por qué org-element--cache-after-change es llamada por self-insert-command?
  • no lo tengo en post-self-insert-hook
  • ∴ ah, es por after-change-functions
    • tiene: '(org-element–cache-after-change jit-lock-after-change org-fold-core–fix-folded-region t)

• ah, perfilado de CPU muestra otra visión:

  2084 74% - command-execute 1163 41% - funcall-interactively 943 33% - org-self-insert-command 819 29% - org-fold-core–fix-folded-region 4 0% org-fold-core-get-folding-spec 4 0% + org-fold-core-next-folding-state-change 4 0% org-fold-core-region-folded-p 108 3% + org-element–cache-after-change 4 0% + org-element–cache-before-change 122 4% + org-delete-backward-char 34 1% + org-return 31 1% + org-kill-line 15 0% + execute-extended-command 2 0% + org-beginning-of-line

• otra captura

  4626 86% - command-execute 3377 63% - funcall-interactively 2438 45% - org-self-insert-command 2438 45% - apply 2398 45% - #<subr org-self-insert-command> 2370 44% - org-element–cache-after-change 2344 44% - org-element–cache-submit-request 2270 42% - org-element–cache-for-removal 2238 42% org-element-org-data-parser 8 0% - org-element-headline-parser 8 0% - org-element–parse-objects 4 0% org-element–parse-objects 4 0% - org-element–cache-before-change 4 0% #<compiled 0xadec16c0ad88f> […]

• el uso de memoria también asusta. Esto es por teclear una 20 palabras y borrarlas

  98,258,812  99% - command-execute
  92,025,932  92%  - funcall-interactively
  73,528,698  74%   + save-buffer
  14,541,612  14%   - org-self-insert-command
  14,541,612  14%    - apply
  10,580,394  10%     - #<subr org-self-insert-command>
   8,742,290   8%      - org-element--cache-after-change
   8,057,144   8%       - org-element--cache-submit-request
   3,260,888   3%        - org-element--cache-for-removal
   1,385,232   1%         - org-element-org-data-parser
     169,952   0%            file-name-sans-extension
     888,680   0%         - org-element-headline-parser
     323,536   0%          - org-element--parse-objects
     153,584   0%           - org-element--object-lex
       8,184   0%              org-element-radio-target-parser
       8,184   0%            replace-regexp-in-string
          48   0%       + run-with-idle-timer
     411,648   0%      + jit-lock-after-change
     137,216   0%        org-at-table-p
  
  

• voy a desactivar org-element-use-cache un tiempo. Me decepciona
  • pero entonces algunas operaciones tardan más de 5 minutos…
• pruebo en ficheros: ∴ Le (3'9 Mb). o op (11'1 Mb)
• todo esto lo estoy probando con 73134cfbf
• veo <03.m07.2023> que hay opciones nuevas en org-element: „deferred“ etc. Y un nuevo asintador. Y veo también que org-element se está „comiendo“ muchas funcionas de org (pasan a estar implementadas mediante org-element), de forma que org-element deja de ser opcional. Por tanto es necesario que funcione perfectamente
  • iría bien si realmente se retrasa todo lo de org para que no pase justo al teclear
  • aún no he probado la versión nueva. Aún tiene fallos nuevos. ∴ Esperar un poco
• actualicé org más adelante <24.m07.2023>, y nuevo emacs (revisión git 89558533683)
  • por probar, a ver si hay diferencia apreciable
  • sigue pasando. En algunos ficheros (ẽ uno de 2'5M) hay latencia de ŭ1 250-500 ms tras cada tecla
  • <02.m08.2023> veo que sigue
• org-element-headline-parser, ¿por qué la llama tantas vecse (ẽ 2671 veces mientras tecleaba frase de ~100 letras)
  • es org-element–cache-for-removal
• [X] veo que hay org-element–cache-avoid-synchronous-headline-re-parsing para acelerar cosas, lo activo. Probarlo un tiempo
  • parece que va bien, y mejor

• esto el <26.m01.2024>, en Zeitmanagement.org, al teclear al final de cabecera de nivel 3 que está por el 59% del fichero

• desde emacsclient gráfico

  20765 88% - redisplay_internal (C function) 80 0% - jit-lock-function 80 0% - jit-lock-fontify-now 76 0% - jit-lock–run-functions 76 0% - #<compiled -0x7399baae27627e7> 76 0% - font-lock-fontify-region 48 0% + c-font-lock-fontify-region 28 0% + font-lock-default-fontify-region 4 0% put-text-property 16 0% redisplay–pre-redisplay-functions 8 0% - eval 8 0% - if 4 0% frame-parameter 4 0% or 4 0% mode-line-default-help-echo 1125 4% - command-execute 802 3% + funcall-interactively

• desde emacsclient -nw; se nota menos retardo, pero aún así hay

  39230 64% - redisplay_internal (C function) 62 0% - redisplay–pre-redisplay-functions 17 0% - run-hook-with-args 8 0% - redisplay–update-region-highlight 4 0% #<compiled -0x5eaf05e30c61bb0> 2 0% window-buffer 43 0% - jit-lock-function 39 0% - jit-lock-fontify-now 35 0% - jit-lock–run-functions 35 0% - #<compiled -0x74fcfff394729e7> 35 0% - font-lock-fontify-region 35 0% - font-lock-default-fontify-region 27 0% - font-lock-fontify-keywords-region 8 0% - org-do-emphasis-faces 8 0% looking-at 4 0% - org-activate-links 4 0% - org-activate-links–text-properties 4 0% re-search-forward 4 0% org-activate-target-links 4 0% org-do-latex-and-related 3 0% lisp–match-hidden-arg 4 0% + font-lock-unfontify-region 4 0% match-data 4 0% #<compiled 0x164681ebe0832> 32 0% + eval 8 0% + mode-line-default-help-echo 1 0% file-remote-p 8649 14% - command-execute 7455 12% - funcall-interactively 5455 8% + projectile-find-file

• desactivo font-lock mode y aún pasa
• con GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2024-01-08
• me leo redisplay_internal, es doloroso pero bonito documento histórico (hay trozos de hace más de 30 años, y otros recientes), y me sorprende que funcione

• muy extraño: minutos más tarde, vuelvo a X y tecleo en mismo sitio, y ahora es rápido (hay latencia algo molesta, pero de pocos milisegundos). Y ahora

  83438 50% - redisplay_internal (C function) 3051 1% - jit-lock-function 2993 1% - jit-lock-fontify-now 2882 1% + jit-lock–run-functions 34 0% text-property-any 24 0% put-text-property 8 0% make-closure 4 0% + #<compiled 0xb556bb42fa4cf> 1556 0% + redisplay–pre-redisplay-functions 706 0% + eval 276 0% file-remote-p 80 0% + mode-line-default-help-echo 34 0% + tty-color-desc 24 0% + #<compiled 0x785e047d2419034> 14 0% + wl-summary-after-resize-function 4 0% + window–adjust-process-windows 4 0% + rcirc-window-configuration-change 54507 32% - timer-event-handler 54418 32% - apply 45250 27% - jit-lock-stealth-fontify 20740 12% - jit-lock-fontify-now 20556 12% - jit-lock–run-functions 20556 12% - #<compiled -0x73947c51e79f1e7> 18250 10% - font-lock-fontify-region 11243 6% - c-font-lock-fontify-region

  • (lo de c-font-lock-fontify-region es por otro búfer no relacionado. Sólo estuve en el de org en esta prueba)

• me pasó en lerni latvan per anki, creo

• "Automatic GC" (0x0) "org-parse-time-string" (0xef427ef8) "org-element-timestamp-parser" (0xef428200) "org-element-clock-parser" (0xef428458) "org-element–current-element" (0xef4288f8) "org-element–parse-to" (0xef428a00) "org-element-at-point" (0xef428b08) "org-clock-sum" (0xef428fe8) "org-clock-sum-current-item" (0xef4290b8) "org-clock-in" (0xef429150) "progn" (0xef429210) "unwind-protect" (0xef4292f0) "let" (0xef429420) "save-window-excursion" (0xef4294d0

• desactivo la caché porque hace casi todo más lento (ver sección anterior). Pero no esperaba que sin caché fuera tan malo todo

• es algo reciente, de ~m9.2022
• no pasa con emacs -Q así que le afecta algún ajuste mío
• ¿se ejecuta 2 veces el org-timestamp-change? La 1ª va (deja el cursor donde toca), la 2ª no
  • ~~~ de hecho parece que hace 1 pase para la fecha final, 1 para la inicial, y otra vez la final
  • por mirar mejor

• lo reproduzco con un .emacs que contiene sólo:

  (add-to-list 'load-path "/w/org-mode/lisp") (require 'org)

• bisecciono y

  dc; /w/org-mode ; git bisect bad
  

  5bc6741a5abd42e8305bb0fcfe78801813309640 is the first bad commit commit 5bc6741a5abd42e8305bb0fcfe78801813309640 Author: Ihor Radchenko <yantar92@posteo.net> Date: Tue Nov 1 15:52:25 2022 +0800

  org-clock-update-time-maybe: Update the containing timestamps as well

  • lisp/org-clock.el (org-clock-update-time-maybe): Update the

  containing timestamps inside the clock, not only the clock sum.

  Reported-by: Bruce E. Robertson <brucer42@gmail.com> Link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53393

  lisp/org-clock.el | 35 ++------–— 1 file changed, 24 insertions(+), 11 deletions(-)

• <02.m12.2022 06:17> lo mando a lista de org-mode, „[BUG] Shift-up/down move the cursor to end of timestamp“
• ∴ <07.m12.2022> ¡Ihor lo arregló! Ya funciona

• byte-code: Org version mismatch.  Make sure that correct ‘load-path’ is set early in init.el
  

• no me había pasado antes
• pruebo a cargar con L en dired (los .elc) y no ayuda
• org-version dice: Org mode version 9.6-pre (release_9.5.5-1135-gaed553.dirty @ /w/org-mode/lisp/)
• no puedo hacer org-reload para cargar la nueva, qué irónico
• de momento añado algunos mensajes a mi .emacs para investigar esto

• unir, quizás escribí
• <28.m12.2022 10:46> mandé respuesta a lista org-mode: ver: „Radio links work only in small numbers“
  • ahí explico mi sistema
  • lo podría publicar en algún lado

  • […]

    1. I created a helm menu, that offers me all the radio links. I compute the list of radio links myself, through grep, by looking for <<<. It's easier than it seems, and very fast. The code (no explanations) is my configuration, functions: anythingyhelm-fuente-etiquetas-radio-org, precarga-etiquetas-radio-de-wiki-para-helm

    […]

• sólo esto ya basta para petar emacs -Q:

  (add-to-list 'load-path "/w/org-mode/lisp") (require 'org) (org-tags-expand "+cable")

• Debugger entered–Lisp error: (wrong-type-argument syntax-table-p "Syntax table including \"@\" and \"_\" as word constit…") org-tags-expand("+cable") (progn (org-tags-expand "+cable")) elisp–eval-last-sexp(nil) eval-last-sexp(nil) funcall-interactively(eval-last-sexp nil)

• mmmmmmmmmmm, la variable org-mode-tags-syntax-table parece ser realmente la cadena "Syntax table including \"@\" and \"_\" as word constituents."
  • debería ser otra cosa
• alguien se ha dejado hacer todo esto: (setq org-mode-tags-syntax-table (make-syntax-table org-mode-syntax-table))
• no se está ejecutando lo de org.el

• pruebo:

  (add-to-list 'load-path "/w/org-mode/lisp") (require 'org) ; (load-file "/w/org-mode/lisp/org.el") (org-tags-expand "+cable")

• GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2023-05-23
• org:
  • oficial: Org mode version 9.6.6 (release_9.6.6 @ opt/dc/emacs/share/emacs/30.0.50/lisp/org)
  • la de w: Org mode version 9.7-pre (release_9.6.5-385-gfa058f.dirty @ w/org-mode/lisp)
• pruebo a borrar los .elc, y pasa

• creo que es por:

  commit 6e6354c074a323780f103aabf45be74104ce3ecf Author: Ihor Radchenko <yantar92@posteo.net> Date: Mon May 8 13:23:15 2023 +0200

  org-tags-expand: Do no modify buffer's syntax table by side effect

  • lisp/org.el (org-mode-tags-syntax-table): New variable holding

  syntax table for tags. (org-mode): Initialize tag syntax table. (org-make-tags-matcher): Match tags using appropriate syntax table. (org-tags-expand): Do no modify syntax table by side effect.

  Reported-by: Mattias Engdegård <mattias.engdegard@gmail.com> Link: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63225#68

• envío aviso a lista de org-mode
  • <27.m05.2023 12:18> lo envío a lista org-mode, „[BUG] wrong-type-argument syntax-table-p "Syntax table including \"@\" and \"_\" as word constituents.“
  • <29.m05.2023 19:14> compruebo que Ihor lo ha arreglado

• Publishing file home/dc/repoweb/hacer/conkeror.org using ‘org-html-publish-to-html’ No haré org-update-radio-target-regexp pues es lentísimo; me pierdo los subrayados azules en radios y la posibilidad de seguir enlaces radio. cl-no-applicable-method: No applicable method: semanticdb-create-database, semanticdb-project-database-file, "/w/conkeror/modules"

• ∴ reexportar y va

• <26.m01.2024> con todo.org de 91 Mb. Exportando a txt (UTF-8) ya pasa, tras 50 segundos

• ah, es por

  Debugger entered–Lisp error: (invalid-regexp "Regular expression too big") org-update-radio-target-regexp() org-export–annotate-info(#s(org-export-backend :name ascii :parent nil […] org-export-as(ascii nil nil nil (:ascii-charset utf-8)) org-export-to-buffer(ascii "Org ASCII Export" nil […]

• obvio, pues hay unos 14k radios en ese fichero
• redefino el org-update-radio-target-regexp tal como hago en mi .emacs. Ahora no lo tuve activo porque hice org-reload
• <26.m03.2024> probé a actualizar, pues creo que han pasado a partir la expregu en cachos. Pero tarda minutos en cargar algunos .org, así que seguiré desactivando radios

• <13.m05.2024 12:05>

  Lisp Backtrace:
  "string-width" (0x24dde1a0)
  "org-element--list-struct" (0x24dde3a8)
  0xcefb3dd0 PVEC_SUBR
  "org-element--parse-to" (0x24ddea38)
  "org-element-at-point" (0x24ddeb00)
  "org-src-preserve-indentation-p" (0x24ddec40)
  "org-src-font-lock-fontify-block" (0x24ddf098)
  "org-fontify-meta-lines-and-blocks-1" (0x24ddf150)
  "org-fontify-meta-lines-and-blocks" (0x24ddf298)
  "font-lock-fontify-keywords-region" (0x24ddf508)
  "font-lock-default-fontify-region" (0x24ddf5d8)
  "font-lock-fontify-region" (0x673ff040)
  0xdb5e7bf8 PVEC_CLOSURE
  "jit-lock--run-functions" (0x24ddf888)
  "jit-lock-fontify-now" (0x24ddf9a8)
  "jit-lock-function" (0x24ddfab8)
  "redisplay_internal (C function)" (0x0)
  

• le mandé SIGSUR2
  • eso causó montones de GC, durante minutos, y no paraba
  • cada varios semiminutos procesaba mis C-n y lo veía avanzar una línea
• lo maté y lo reinicié. Pero esto renacimiento estilo Fénix no lo hace mejor

• mandado a lista <21.m05.2024 09:13>

• a	b	percent of a in b
  10	20	#ERROR
  20	30	#ERROR

• corregido, revirtió el cambio

Pruebo tabla grande vacía: