Re: Lightweight Emacs for container?

[tomas]

On Mon, May 06, 2024 at 04:19:32PM -0400, Stefan Monnier wrote:
> > Is there some package, or a simple workaround, that will allow me to use
> > a basic Emacs without all the cruft?
> 
> I think the usual answers look like:
> 
> - Use Zile (or some other small Emacs-inspired editor).
> - Use Tramp (i.e. run Emacs outside the container and access the
>   container's files as a kind of remote host).

Tramp is the way to go, for a bunch of other reasons. You carry around
your set of customizations. You have less instances to keep up to date
and to care-and-feed.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Lightweight Emacs for container?

[Jeffrey Walton]

On Mon, May 6, 2024 at 6:45 PM Dr. Jennifer Nussbaum 
wrote:

> I usually use Emacs on full-blown Debian distributions, so I don't pay
> much attention to how large it is. But I'm now starting to
> play around with lightweight LXC containers, obviously headless, and would
> like to keep using Emacs in these, but just for basic
> text editing and so forth, I don't need a whole IDE environment. But to my
> surprise, even emacs-nox is a gigantic installation,
> that even wants to pull in MySQL, for heaven's sake.
>
> Is there some package, or a simple workaround, that will allow me to use a
> basic Emacs without all the cruft?
>

To expand on what Stefan said, see <
https://www.emacswiki.org/emacs/EmacsImplementations>.

And you can build it from sources, and really leave out the stuff you don't
want: <https://superuser.com/q/617468>.

Jeff

Re: Lightweight Emacs for container?

[Michael Kjörling]

On 6 May 2024 16:19 -0400, from monn...@iro.umontreal.ca (Stefan Monnier):
>> Is there some package, or a simple workaround, that will allow me to use
>> a basic Emacs without all the cruft?
> 
> I think the usual answers look like:
> 
> - Use Zile (or some other small Emacs-inspired editor).

mg and jove might be other alternatives; all of these appear to have
minimal dependencies.

On a fairly small Bookworm installation (standard and ssh-server tasks
installed, and otherwise out-of-the-box):

# apt-get -s install zile
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libgee-0.8-2
The following NEW packages will be installed:
  libgee-0.8-2 zile
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Inst libgee-0.8-2 (0.20.6-1 Debian:12.5/stable [amd64])
Inst zile (2.6.2-2+b1 Debian:12.5/stable [amd64])
Conf libgee-0.8-2 (0.20.6-1 Debian:12.5/stable [amd64])
Conf zile (2.6.2-2+b1 Debian:12.5/stable [amd64])
# apt-get -s install mg
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  mg
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst mg (20221112-1 Debian:12.5/stable [amd64])
Conf mg (20221112-1 Debian:12.5/stable [amd64])
# apt-get -s install jove
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  aspell ctags | emacs-bin-common
The following NEW packages will be installed:
  jove
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst jove (4.17.5.1-2 Debian:12.5/stable [amd64])
Conf jove (4.17.5.1-2 Debian:12.5/stable [amd64])
#

You could also try with --no-install-recommends --no-install-suggests
to apt-get install; but there's no denying that present-day Emacs is
fairly heavy-weight.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Lightweight Emacs for container?

[David Wright]

On Mon 06 May 2024 at 19:37:39 (+), Dr. Jennifer Nussbaum wrote:
> I usually use Emacs on full-blown Debian distributions, so I don't pay much 
> attention to how large it is. But I'm now starting to
> play around with lightweight LXC containers, obviously headless, and would 
> like to keep using Emacs in these, but just for basic 
> text editing and so forth, I don't need a whole IDE environment. But to my 
> surprise, even emacs-nox is a gigantic installation, 
> that even wants to pull in MySQL, for heaven's sake.
> 
> Is there some package, or a simple workaround, that will allow me to use a 
> basic Emacs without all the cruft?

Are you allowing APT to install Recommends and/or Suggests?

If you haven't yet installed emacs-nox, it might be interesting
to see the list of packages you get listed if you:

 $ apt-get -s --no-install-recommends install emacs-nox

as a /user/.

Or OTOH, if you have installed emacs-nox:

 $ apt-get -s purge 

as a /user/, where  is the names of the mysql packages
you're complaining about.

The only mysql package I have (on bullseye, I'm afraid)
is mysql-common (which is very small), and that shows:

$  apt-get -s purge mysql-common
NOTE: This is only a simulation!
  apt-get needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  gsasl-common guile-2.2-libs libgsasl7 libntlm0 mailutils-common
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  libmailutils7* libmariadb3* libreoffice-sdbc-mysql* mailutils* 
mariadb-common* mysql-common*
0 upgraded, 0 newly installed, 6 to remove and 0 not upgraded.
Purg mailutils [1:3.10-3+b1]
Purg libmailutils7 [1:3.10-3+b1]
Purg libreoffice-sdbc-mysql [1:7.0.4-4+deb11u8]
Purg libmariadb3 [1:10.5.23-0+deb11u1]
Purg mariadb-common [1:10.5.23-0+deb11u1]
Purg mysql-common [5.8+1.0.7]

(I have emacs-gtk installed, rather than -nox.)

Cheers,
David.

Re: Lightweight Emacs for container?

[Stefan Monnier]

> Is there some package, or a simple workaround, that will allow me to use
> a basic Emacs without all the cruft?

I think the usual answers look like:

- Use Zile (or some other small Emacs-inspired editor).
- Use Tramp (i.e. run Emacs outside the container and access the
  container's files as a kind of remote host).


Stefan

Lightweight Emacs for container?

[Dr. Jennifer Nussbaum]

I usually use Emacs on full-blown Debian distributions, so I don't pay much 
attention to how large it is. But I'm now starting to
play around with lightweight LXC containers, obviously headless, and would like 
to keep using Emacs in these, but just for basic 
text editing and so forth, I don't need a whole IDE environment. But to my 
surprise, even emacs-nox is a gigantic installation, 
that even wants to pull in MySQL, for heaven's sake.

Is there some package, or a simple workaround, that will allow me to use a 
basic Emacs without all the cruft?

Re: emacs 27.1 from Buster work on Bookworm?

[tomas]

On Fri, Mar 15, 2024 at 06:56:15PM -0700, John Conover wrote:
> 
> Can emacs 27.1 from Debian 11 Buster be installed on Debian 12 Bookworm?

Hm. libc6 hasn't changed /that/ much and is known to handle ABI
compatibility pretty well. I fear the other libs aren't as friendly.

The package system will try to prevent you doing that (for a good
reason), but you can talk it into doing it anyway.

Your best bet seems to be to download the package source and build
deps and re-build for bookworm (and see what breaks).

Not for the faint of heart, but not a research project either. What
are you trying to achieve?

Cheers
-- 
t


signature.asc
Description: PGP signature

emacs 27.1 from Buster work on Bookworm?

[John Conover]

Can emacs 27.1 from Debian 11 Buster be installed on Debian 12 Bookworm?

Thanks,

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)

[Md]

Le mercredi 23 novembre 2022 à 08:50 +0100, Jean-Philippe Georget a écrit :
> Bonjour,
> 
> Tout d'abord, je remercie tous les participants à ce fil de discussion qui 
> m'ont permis de trouver une solution seulement aujourd'hui et après une bonne 
> petite heure de recherche et de tests (car, oui, je n'ai pas trouvé tout de 
> suite la solution ;-)
> 
> 
> *Le problème*
> 
> Des caractères accentués de certains noms de fichiers sont codés sur deux 
> caractères malgré le fait que ce soient des caractères Unicode.
> Par exemple "é" est codé avec "e" et un accent aigu, "à" est codé avec "a" et 
> un accent grave.
> 
> Cela cause des bizarreries quand on veut les renommer (il faut effacer deux 
> caractères au lieu d'un, le curseur ne se positionne pas au bon endroit) ou 
> les rechercher (on ne les retrouve pas, par exemple r?f.pdf ne permet pas de 
> retrouver réf.pdf alors que r??f.pdf permet le retrouver).
> 
> 
> *Une solution*
> 
> Convertir le nom du fichier de utf-8 à utf-8 en respectant la norme NFC
> 
> convmv -f utf-8 -t utf-8 --nfc --notest filename
> 
> 
> On peut aussi traiter récursivement une hiérarchie de dossiers/fichiers en 
> ajoutant un "-r".
> 
> convmv -r -f utf8 -t utf8 --nfc --notest path/
> 
> 
> 
> *Une explication*
> 
> Les noms de fichier avec lesquels j'ai des problèmes proviennent 
> d'ordinateurs fonctionnant sous MacOs.
> 
> Effectivement, le système de fichiers HFS (ou HFS+) de MacOs utilise une 
> forme d'Unicode spécifique (no comment :-]), la forme NFD (NFC normalization 
> form D). Or Linux utilise la forme NFC (normalization form C).
> 
> https://fr.wikipedia.org/wiki/Normalisation_Unicode
> - Norme NFD (MacOs) : les caractères diacritiques sont codés sous une forme 
> décomposée ("é" est en fait "e" + l'accent aigu)
> - Norme NFC (Linux) : les caractères diacritiques sont codés sous une forme 
> composée ("é" est un seul caractère unicode)
> 
> 
> Quand on enregistre sur un ordinateur Linux un fichier créé sur MacOs, il n'y 
> a pas de conversion entre les normes. Le nom de fichier codé en NFD reste en 
> NFD, il n'est pas transformé en NFC. En particulier, deux noms de fichiers 
> identiques à l'affichage peuvent donc cohabiter dans le même dossier alors 
> que ces noms sont différents puisque codés avec des caractères différents.
> 
> Intérêt des deux normes (pour ce que j'ai compris ;-)
> NFC : un code par caractère affiché, pratique pour identifier de manière 
> unique des lettres, des mots, etc.
> 
> NFD : pratique pour faire des recherches/comparaisons sans tenir compte des 
> caractères diacritiques (accents, trémas, etc.). Une recherche sur le mot 
> "education" (sans accent) permet aussi de retrouver "éducation".
> 
> 
> Linus Torvalds déplore l'utilisation de la NFD pour le système de fichier HFS+
> https://www.cio.com/article/251059/linus-torvalds-apples-hfs-is-probably-the-worst-file-system-ever.html
> 
> 
> Et moi aussi, je le déplore ! ;-)
> Jean-Philippe 
> 
En tout cas, ton explication  claire et détaillée t'honore Merci.

Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)

[Sébastien NOBILI]

Bonjour,

Le 2022-11-23 08:50, Jean-Philippe Georget a écrit :

*Une explication*


Merci pour l'explication :)

Sébastien

Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)

[Jean-Philippe Georget]

Bonjour,

Tout d'abord, je remercie tous les participants à ce fil de discussion qui 
m'ont permis de trouver une solution seulement aujourd'hui et après une bonne 
petite heure de recherche et de tests (car, oui, je n'ai pas trouvé tout de 
suite la solution ;-)


*Le problème*

Des caractères accentués de certains noms de fichiers sont codés sur deux 
caractères malgré le fait que ce soient des caractères Unicode.
Par exemple "é" est codé avec "e" et un accent aigu, "à" est codé avec "a" et 
un accent grave.

Cela cause des bizarreries quand on veut les renommer (il faut effacer deux 
caractères au lieu d'un, le curseur ne se positionne pas au bon endroit) ou les 
rechercher (on ne les retrouve pas, par exemple r?f.pdf ne permet pas de 
retrouver réf.pdf alors que r??f.pdf permet le retrouver).


*Une solution*

Convertir le nom du fichier de utf-8 à utf-8 en respectant la norme NFC

convmv -f utf-8 -t utf-8 --nfc --notest filename


On peut aussi traiter récursivement une hiérarchie de dossiers/fichiers en 
ajoutant un "-r".

convmv -r -f utf8 -t utf8 --nfc --notest path/



*Une explication*

Les noms de fichier avec lesquels j'ai des problèmes proviennent d'ordinateurs 
fonctionnant sous MacOs.

Effectivement, le système de fichiers HFS (ou HFS+) de MacOs utilise une forme 
d'Unicode spécifique (no comment :-]), la forme NFD (NFC normalization form D). 
Or Linux utilise la forme NFC (normalization form C).

https://fr.wikipedia.org/wiki/Normalisation_Unicode
- Norme NFD (MacOs) : les caractères diacritiques sont codés sous une forme 
décomposée ("é" est en fait "e" + l'accent aigu)
- Norme NFC (Linux) : les caractères diacritiques sont codés sous une forme 
composée ("é" est un seul caractère unicode)


Quand on enregistre sur un ordinateur Linux un fichier créé sur MacOs, il n'y a 
pas de conversion entre les normes. Le nom de fichier codé en NFD reste en NFD, 
il n'est pas transformé en NFC. En particulier, deux noms de fichiers 
identiques à l'affichage peuvent donc cohabiter dans le même dossier alors que 
ces noms sont différents puisque codés avec des caractères différents.

Intérêt des deux normes (pour ce que j'ai compris ;-)
NFC : un code par caractère affiché, pratique pour identifier de manière unique 
des lettres, des mots, etc.

NFD : pratique pour faire des recherches/comparaisons sans tenir compte des 
caractères diacritiques (accents, trémas, etc.). Une recherche sur le mot 
"education" (sans accent) permet aussi de retrouver "éducation".


Linus Torvalds déplore l'utilisation de la NFD pour le système de fichier HFS+
https://www.cio.com/article/251059/linus-torvalds-apples-hfs-is-probably-the-worst-file-system-ever.html


Et moi aussi, je le déplore ! ;-)
Jean-Philippe 

Re : Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)

[nicolas . patrois]

Le 28/10/2022 10:30:41, Sébastien NOBILI a écrit :

> Pareil ici en lisant ton e-mail via Roundcube dans Firefox.

Pareil avec Balsa.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)

[Sébastien NOBILI]

Bonjour,

Le 2022-10-28 06:51, Jean-Philippe Georget a écrit :

Autre bizarrerie, un affichage du contenu du répertoire sous midnight
commander (mc) affiche les deux noms de fichiers correctement. J'ai
l'impression que les "é" sont affichés de la même manière à moins que
ls différences soient très subtiles.


Pareil ici en lisant ton e-mail via Roundcube dans Firefox. Mais ce 
n'est que de l'affichage car si
je copie les noms de fichier et les passe dans `hexdump`, alors on voit 
bien que les caractères sont

différents.

Tu pourrais peut-être essayer `convmv` : 
https://packages.debian.org/bookworm/convmv


Sébastien

Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)

[Haricophile]

Le Fri, 28 Oct 2022 07:55:47 +0200 (CEST),
Bernard Schoenacker  a écrit :

> Bonjour,
> 
> Pour des raisons de commodités, je vous conseille de 
> passer par "detox" pour les noms de fichiers...

Oui et non. C'est très bien pour mettre sur un serveur web pas UTF8
dans les URL, mais je dois être trop bête pour comprendre comment ne pas
se retrouver avec des fichiers .txt au lieu de файл.txt et la
romanisation de mes fichiers locaux ne m'arrange pas du tout !

Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)

[Bernard Schoenacker]

Bonjour,

Pour des raisons de commodités, je vous conseille de 
passer par "detox" pour les noms de fichiers...

Documentation :

https://linux.die.net/man/1/detox

https://forum.ubuntu-fr.org/viewtopic.php?id=282633


Merci pour votre aimable attention

Bien à vous 

Bernard

Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)

[Jean-Philippe Georget]

Merci beaucoup pour cette première piste ! Oui, je pourrais renommer le 
fichier, c'est parfois ce que je fais, mais c'est assez fastidieux à faire à 
chaque fichier reçu ;-)


Comme proposé, j'ai essayé "mv r?f?rent.pdf référent.pdf", mais cela ne 
fonctionne pas.

Un simple "ls r?f?rent.pdf" m'indique "ls: impossible d'accéder à 
'r?f?rent.pdf': Aucun fichier ou dossier de ce type" alors que "ls r*.pdf" me 
renvoie bien le fichier.


Dans mon précédent message, j'avais copié-collé l'affichage obtenu dans chaque 
terminal.
Du coup, j'ai repris l'idée d'utiliser hexdump avec le même fichier dans un 
répertoire. Pour comparer, j'ai ajouté un fichier que j'ai créé moi-même avec 
la commande "touch référent.pdf".

Avec "ls | hexdump -C", j'obtiens :

  72 65 cc 81 66 65 cc 81  72 65 6e 74 2e 70 64 66  |re..fe..rent.pdf|
0010  0a 72 c3 a9 66 c3 a9 72  65 6e 74 2e 70 64 66 0a  |.r..f..rent.pdf.|
0020

La deuxième ligne (fichier que j'ai créé) me semble assez bizarre avec un 
espace devant le premier "r" !

Autre bizarrerie, un affichage du contenu du répertoire sous midnight commander 
(mc) affiche les deux noms de fichiers correctement. J'ai l'impression que les 
"é" sont affichés de la même manière à moins que ls différences soient très 
subtiles.



Le ven. 28 oct. 2022 11:10, Charles Plessy  a écrit:

> From: Charles Plessy 
> Subject: Re: Gestion de caractères accentués différentes entre xterm, 
> d'autres émulateurs de terminal, et Emacs (locales correctes)
> To: debian-user-french@lists.debian.org
> Mail-Followup-To: debian-user-french@lists.debian.org
> Resent-From: debian-user-french@lists.debian.org
>
> Le Fri, Oct 28, 2022 at 12:50:19AM +0200, Jean-Philippe Georget a écrit :
>> 
>> Sous xterm, ce fichier s'affiche correctement comme "référent.pdf" avec la 
>> commande "ls".
>> 
>> Par contre, sous xfce4-terminal, il s'affiche bizarrement comme 
>> "référent.pdf" (notez les accents décalés sur la droite des "e").
>
> Bonjour,
>
> c'est un problème de prise en charge d'Unicode.
>
> Sur mon terminal, je vois référent.pdf dans les deux cas.  Mais voici
> ce que je vois si je copie-colle le nom de ficher et le passe à hexdump.
>
> echo référent.pdf | hexdump -C
>   72 c3 a9 66 c3 a9 72 65  6e 74 2e 70 64 66 0a |référent.pdf.|
> 000f
>
> echo référent.pdf | hexdump -C
>   72 65 cc 81 66 65 cc 81  72 65 6e 74 2e 70 64 66  |re?.fe?.rent.pdf|
> 0010  0a|.|
> 0011
>
> Pour un peu plus de contexte, voici une version pure ASCII sans accents:
>
> echo referent.pdf | hexdump -C
>   72 65 66 65 72 65 6e 74  2e 70 64 66 0a   |referent.pdf.|
> 000d
>
> Et lettre par lettre:
>
> printf é | hexdump -C
>   c3 a9 |é|
> 0002
>
> printf e | hexdump -C
>   65|e|
> 0001
>
> printf é | hexdump -C
>   65 cc 81  |e?.|
> 0003
>
> Le dernier é, c'est un e auquel on ajoute ensuite un accent aigu.
>
> Le caractère Unicode U+0301 COMBINING ACUTE ACCENT est encodé cc81 en UTF-8.
>
> Je dois m'arrêter là car mon train arrive en gare, mais une solution
> pour contourner le problème pourrait être:
>
> mv r?f?rent.pdf référent.pdf
>
> Ceci change le nom de fichier pour utiliser la représentation la plus
> habituelle.
>
> D'autres abonnés à cette liste pourront t'indiquer des outils pour le
> faire automatiquement.
>
> Amicalement,
>
> Charles Plessy

Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)

[Charles Plessy]

Le Fri, Oct 28, 2022 at 12:50:19AM +0200, Jean-Philippe Georget a écrit :
> 
> Sous xterm, ce fichier s'affiche correctement comme "référent.pdf" avec la 
> commande "ls".
> 
> Par contre, sous xfce4-terminal, il s'affiche bizarrement comme 
> "référent.pdf" (notez les accents décalés sur la droite des "e").

Bonjour,

c'est un problème de prise en charge d'Unicode.

Sur mon terminal, je vois référent.pdf dans les deux cas.  Mais voici
ce que je vois si je copie-colle le nom de ficher et le passe à hexdump.

echo référent.pdf | hexdump -C
  72 c3 a9 66 c3 a9 72 65  6e 74 2e 70 64 66 0a |référent.pdf.|
000f

echo référent.pdf | hexdump -C
  72 65 cc 81 66 65 cc 81  72 65 6e 74 2e 70 64 66  |re?.fe?.rent.pdf|
0010  0a|.|
0011

Pour un peu plus de contexte, voici une version pure ASCII sans accents:

echo referent.pdf | hexdump -C
  72 65 66 65 72 65 6e 74  2e 70 64 66 0a   |referent.pdf.|
000d

Et lettre par lettre:

printf é | hexdump -C
  c3 a9 |é|
0002

printf e | hexdump -C
  65|e|
0001

printf é | hexdump -C
  65 cc 81  |e?.|
0003

Le dernier é, c'est un e auquel on ajoute ensuite un accent aigu.

Le caractère Unicode U+0301 COMBINING ACUTE ACCENT est encodé cc81 en UTF-8.

Je dois m'arrêter là car mon train arrive en gare, mais une solution
pour contourner le problème pourrait être:

mv r?f?rent.pdf référent.pdf

Ceci change le nom de fichier pour utiliser la représentation la plus
habituelle.

D'autres abonnés à cette liste pourront t'indiquer des outils pour le
faire automatiquement.

Amicalement,

Charles Plessy

Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)

[Jean-Philippe Georget]

Bonjour à tous,

Je n'arrive pas à régler deux problèmes (qui ont l'air liés) que j'ai depuis 
plusieurs mois avec Debian (testing, à jour).

Jusqu'à maintenant, je fais avec ces problèmes mais aujourd'hui je serais ravi 
de m'en débarrasser. J'ai fait des recherches sur le web en français et en 
anglais et sur la liste debian-french mais je n'ai pas trouvé de solutions. Je 
tente donc ma chance ici sur la liste.


On m'a envoyé un fichier "référent.pdf" que je prends comme exemple mais les 
mêmes problèmes décrits ci-dessous se produisent avec les fichiers qu'on 
m'envoie, pas avec ceux que je créée.


Sous xterm, ce fichier s'affiche correctement comme "référent.pdf" avec la 
commande "ls".

Par contre, sous xfce4-terminal, il s'affiche bizarrement comme 
"référent.pdf" (notez les accents décalés sur la droite des "e").

Quand j'édite le nom du fichier en ligne de commande sous bash, un backspace 
efface le caractère de gauche, normal. Quand j'arrive à la position juste à 
droit des accents, chaque "e" s'efface en même temps que son accent "associé".

Mais quand j'édite le nom de fichier sous le gestionnaire de fichier ranger 
(programmé en python), si je me mets par exemple à droite du "t" et que 
j'appuie sur backspace pour effacer cette lettre, il efface le "e" de "ent", 
soit 2 lettres à gauche de la position du curseur au lieu d'effacer le 
caractère juste à gauche. Le décalage similaire se produit quand j'utilise la 
touche DEL.

J'ai essayé d'autres émulateurs de terminal : gnome-terminal, terminator, et 
lxterminal. Je rencontre les mêmes problèmes.

Je pensais à un problème de locales. J'ai tenté un "sudo dpkg-reconfigure 
locales" mais sans que cela ne résolve aucun problème.
La commande "locale" me renvoie des informations qui m'ont l'air correctes, 
comme celles que j'ai trouvées sur le net.

LANG=fr_FR.UTF-8
LANGUAGE=fr_FR:en_US
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=


J'ai ensuite pensé à un problème de fonte. Mon xfce4-terminal utilisait 
"Monospace Regular", j'ai alors testé d'autres fontes. J'arrive à résoudre le 
problème d'affichage mais pas celui de l'effacement expliqué plus haut, il y a 
toujours un décalage de 2 caractères.


Sous Emacs 27.1, j'ai le même problème d'affichage et d'effacement de 
caractères sous dired. J'ai tenté de lancer "emacs -q" depuis le xterm 
puisqu'il n'y avait pas de problème sous xterm, mais je rencontre les mêmes 
problèmes sous dired.


J'ai aussi créé un nouvel utilisateur sous ma machine pour voir si cela ne 
viendrait d'un problème de configuration quelque part au niveau de mon profil 
utilisateur : les problèmes rencontrés sont les mêmes.


Si vous avez des idées de solution, je suis (très) preneur ! :-)
Jean-Philippe

Re: No emacs source files in Debian testing?

[Dekks Herton]

Charles Curley  writes:

> On Wed, 5 Oct 2022 08:40:14 -0400
> Haines Brown  wrote:
>
>> With an upgrade to testing, I get this warning when I load emacs:
>> 
>>   Warning (comp): Cannot look-up eln file as no source file was found
>>   for /home/haines/.emacs.d/elisp/ibus.elc
>
> Judging by the location (in your user directory) and by the fact that
> searching with apt-file on Bullseye turns up neither ibus.elc nor
> ibus.el, I don't think that ibus.elc or its source file, ibus.el is in
> Bullseye, and so likely not in Debian testing. Nor did I find anything
> by searching for an emacs ibus package. I suspect you got it from
> somewhere else. https://www.emacswiki.org/emacs/IBusMode I suspect you
> did a manual installation.
> https://www.emacswiki.org/emacs/IBusMode#h5o-4
>
>
>> 
>> I gather that with emacs version 28 the ibus.el source file is no 
>> longer installed, although it must found if the compiled ibus.enc
>> file is to load.

Testing is at 27.1 - 28.1 is in unstable and currently broken.

> Emacs can run byte-compiled files without having the source files
> handy. Did you mean ibus.elc here?
>
>> 
>> I tried to find a testing version of ibus.el but did not succeed. I
>> tied to use an old ibus.el file from Jul 2020, but it had obsolete
>> functions and so was not usable.
>> 
>> Can I just ignore the warning? If I do does it leave ibus
>> non-functional? Should I file a bug report?
>> 
>
> The acid test is whether you can run without the source file. I'm
> pretty sure you can ignore the warning. I would try it.
>
> As for filing a bug report, I don't know where you got ibus.elc, so
> can't advise you.
>

-- 
regards.

Thinkpad T60p 2.33Ghz 2GB SXGA+

Re: No emacs source files in Debian testing?

[Charles Curley]

On Wed, 5 Oct 2022 08:40:14 -0400
Haines Brown  wrote:

> With an upgrade to testing, I get this warning when I load emacs:
> 
>   Warning (comp): Cannot look-up eln file as no source file was found
>   for /home/haines/.emacs.d/elisp/ibus.elc

Judging by the location (in your user directory) and by the fact that
searching with apt-file on Bullseye turns up neither ibus.elc nor
ibus.el, I don't think that ibus.elc or its source file, ibus.el is in
Bullseye, and so likely not in Debian testing. Nor did I find anything
by searching for an emacs ibus package. I suspect you got it from
somewhere else. https://www.emacswiki.org/emacs/IBusMode I suspect you
did a manual installation.
https://www.emacswiki.org/emacs/IBusMode#h5o-4


> 
> I gather that with emacs version 28 the ibus.el source file is no 
> longer installed, although it must found if the compiled ibus.enc
> file is to load.

Emacs can run byte-compiled files without having the source files
handy. Did you mean ibus.elc here?

> 
> I tried to find a testing version of ibus.el but did not succeed. I
> tied to use an old ibus.el file from Jul 2020, but it had obsolete
> functions and so was not usable.
> 
> Can I just ignore the warning? If I do does it leave ibus
> non-functional? Should I file a bug report?
> 

The acid test is whether you can run without the source file. I'm
pretty sure you can ignore the warning. I would try it.

As for filing a bug report, I don't know where you got ibus.elc, so
can't advise you.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

No emacs source files in Debian testing?

[Haines Brown]

With an upgrade to testing, I get this warning when I load emacs:

  Warning (comp): Cannot look-up eln file as no source file was found
  for /home/haines/.emacs.d/elisp/ibus.elc

I gather that with emacs version 28 the ibus.el source file is no 
longer installed, although it must found if the compiled ibus.enc file 
is to load.

I tried to find a testing version of ibus.el but did not succeed. I
tied to use an old ibus.el file from Jul 2020, but it had obsolete
functions and so was not usable.

Can I just ignore the warning? If I do does it leave ibus
non-functional? Should I file a bug report?

-- 

 Haines Brown 
 /"\
 \ /  ASCII Ribbon Campaign
  Xagainst HTML e-mail 
 / \

Re: replace corrupted emacs aspell dictionary

[Gregor Zattler]

Hi Thomas, Russel,
*  [2022-08-13; 06:37]:
> On Fri, Aug 12, 2022 at 07:38:31PM +, Russell L. Harris wrote:
>> I managed to approve incorrect spellings for several words in the
>> Emacs aspell dictionary.
>>
>> How can I replace the corrupted dictionary with a pristine copy?
>
> Caveat: not a regular user of aspell here: all what I know I do from
> asking aspell's man page.
>
> I assume that the changes have been done to your "personal dictionary
> file", not to the global one. According to the output of "aspell config",
> the former is supposed to live in my home directory, under the name
> ".aspell..pws", where  is the language cookie of interest
> (i.e. "en_US", "it_IT" or whatever).

these files (in my case ~/.aspell.de.pws and
~/.aspell.en.pws) contain (besides a header line) a list of
hopefully correct words, each word on it's own line.  It's
in chronological order of your additions, meaning the last
added word is on the last line.

If you have many correct words and only few not correct words
in it, it might be worthwhile to rescue the correct words.
You may simply open the file in any editor, delete the
words which are not correct and save the file.


Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

Re: replace corrupted emacs aspell dictionary

[tomas]

On Fri, Aug 12, 2022 at 07:38:31PM +, Russell L. Harris wrote:
> I managed to approve incorrect spellings for several words in the
> Emacs aspell dictionary.
> 
> How can I replace the corrupted dictionary with a pristine copy?

Caveat: not a regular user of aspell here: all what I know I do from
asking aspell's man page.

I assume that the changes have been done to your "personal dictionary
file", not to the global one. According to the output of "aspell config",
the former is supposed to live in my home directory, under the name
".aspell..pws", where  is the language cookie of interest
(i.e. "en_US", "it_IT" or whatever).

So perhaps moving that file out of harm might suffice. Don't throw it
away yet -- most probably there is a way to dump/fix/reload it: one
would have to have a look at aspell's info pages.

Cheers
-- 
t


signature.asc
Description: PGP signature

replace corrupted emacs aspell dictionary

[Russell L. Harris]

I managed to approve incorrect spellings for several words in the
Emacs aspell dictionary.

How can I replace the corrupted dictionary with a pristine copy?

--
He turneth rivers into a wilderness, and the watersprings into dry
ground; a fruitful land into barrenness, for the wickedness of them
that dwell therein. - Psalm 107:33-34

Re: Re : emacs lisp et (- 0.07 0.18) et aussi SBCL

[Basile Starynkevitch]

On 25/10/2021 08:58, Marc Chantreux wrote:

salut,

Le Mon, Oct 25, 2021 at 08:14:04AM +0200, nicolas.patr...@gmail.com a écrit :

Tu utilises un langage où les flottants sont des décimaux (ça doit
bien exister) ou tu utilises Python avec le module decimal.

Puisqu'on est dans les scheme/lisp: c'est le cas de chicken:

dpkg -S $(realpath $(which csi ))

chicken-bin: /usr/bin/csi

<<.  csi
 (display (- 0.07 .11))
.

CHICKEN
(c) 2008-2020, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 5.2.0 (rev 317468e4)
linux-unix-gnu-x86-64 [ 64bit dload ptables ]
-0.04

mais pour faire des maths, j'ai une grosse préférence pour raku
(https://raku.org/)
* les fractions sont conservées sous la forme de fraction
* les metaoperators simplifient vraiment le boulot



Dans la veine Lispienne, j'aurais tendance à suggérer Bigloo.

http://www-sop.inria.fr/mimosa/fp/Bigloo/


C'est développé en France par Manuel Serrano et ses collègues.


--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: Re : emacs lisp et (- 0.07 0.18) et aussi SBCL

[Marc Chantreux]

salut,

Le Mon, Oct 25, 2021 at 08:14:04AM +0200, nicolas.patr...@gmail.com a écrit :
> Tu utilises un langage où les flottants sont des décimaux (ça doit
> bien exister) ou tu utilises Python avec le module decimal.

Puisqu'on est dans les scheme/lisp: c'est le cas de chicken:

dpkg -S $(realpath $(which csi ))

chicken-bin: /usr/bin/csi

<<.  csi
(display (- 0.07 .11))
.

CHICKEN
(c) 2008-2020, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 5.2.0 (rev 317468e4)
linux-unix-gnu-x86-64 [ 64bit dload ptables ]
-0.04

mais pour faire des maths, j'ai une grosse préférence pour raku
(https://raku.org/)
* les fractions sont conservées sous la forme de fraction
* les metaoperators simplifient vraiment le boulot

a+
-- 
Marc Chantreux
Direction du numérique
Pôle de Calcul et Services Avancés à la Recherche (CESAR)
http://annuaire.unistra.fr/p/20200

Re: Re : emacs lisp et (- 0.07 0.18) et aussi SBCL

[Basile Starynkevitch]

On 25/10/2021 08:14, nicolas.patr...@gmail.com wrote:

Le 25/10/2021 00:42:11, kaliderus a écrit :


J'imaginais ce genre de chose :-/
Et donc si quelqu'un veut faire par exemple du bancaire derrière, ou
juste avoir un calcul exact (ce qui est mon cas), que lui conseiller ?
J'imagine utiliser une librairie adéquate (je n'ai pas encore
chercher), ou existe-t-il une solution au niveau du langage ?

Tu utilises un langage où les flottants sont des décimaux (ça doit bien 
exister) ou tu utilises Python avec le module decimal.



Je n'y connais rien en informatique de gestion, mais j'aurais tendance à 
conseiller de représenter un montant en € par un nombre entier (sur 64 
bits, donc uint64_t en C) de centimes d'€.


Il me semble que 2 puissance 63 centimes d'€ c'est bien plus que la 
masse monétaire mondiale.



Les calculs sont alors justes, et on pourrait les prouver avec Frama-C 
(voir https://frama-c.com/ et prévoir d'annoter le code source avec des 
annotations en ACSL; bien sûr, ça a un coût humain) ou peut-être avec un 
greffon de GCC comme Bismon (voir https://github.com/bstarynk/bismon/ et 
le projet DECODER voir https://decoder-project.eu/ ...)



On pourrait aussi générer le code avec des outils tels que RefPerSys 
(voir http://refpersys.org/ ...)



N'hésitez pas à me contacter par courriel vers 
 et  pour avoir 
des détails et des contacts.


Librement.

--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re : emacs lisp et (- 0.07 0.18) et aussi SBCL

[nicolas . patrois]

Le 25/10/2021 00:42:11, kaliderus a écrit :

> J'imaginais ce genre de chose :-/
> Et donc si quelqu'un veut faire par exemple du bancaire derrière, ou
> juste avoir un calcul exact (ce qui est mon cas), que lui conseiller ?
> J'imagine utiliser une librairie adéquate (je n'ai pas encore
> chercher), ou existe-t-il une solution au niveau du langage ?

Tu utilises un langage où les flottants sont des décimaux (ça doit bien 
exister) ou tu utilises Python avec le module decimal.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: emacs lisp et (- 0.07 0.18) et aussi SBCL

[kaliderus]

> Si j'ai bonne mémoire, la norme Common Lisp impose le calcul en bignums
> ou nombres à précision arbitrairement grande.
>
> Alors que GNU emacs utilise des flottants IEEE754.
>
J'imaginais ce genre de chose :-/
Et donc si quelqu'un veut faire par exemple du bancaire derrière, ou
juste avoir un calcul exact (ce qui est mon cas), que lui conseiller ?
J'imagine utiliser une librairie adéquate (je n'ai pas encore
chercher), ou existe-t-il une solution au niveau du langage ?

> https://pages.lip6.fr/Christian.Queinnec/WWW/LiSP.html est une lecture
> conseillée.
>
Merci pour le lien !

Re: emacs lisp et (- 0.07 0.18) et aussi SBCL

[Étienne Mollier]

Bonjour,

Basile Starynkevitch, on 2021-10-24:
> On 24/10/2021 18:44, kaliderus wrote:
> > J'avais déjà remarqué ce phénomène, et voici ce que me donne le
> > résultat mentionné en objet
> > (- 0.07 0.18)
> > dans emacs : -0.10999
> > avec SBCL : -0.1101
[…]
> Si j'ai bonne mémoire, la norme Common Lisp impose le calcul en bignums ou
> nombres à précision arbitrairement grande.
> 
> Alors que GNU emacs utilise des flottants IEEE754.

Le petit programme ci-dessous permet de voir ce qu'il se passe :

#include 
int main(int argc, char *argv[])
{
printf("double: %0.32f\n", (double)0.07 - (double)0.18);
printf("float:  %0.32f\n", (float)0.07  - (float)0.18);
return (0);
}

Un fois compilé et exécuté, on retrouve les erreurs de précision
issues des arrondis flottants mentionnés par Basile :

double: -0.10998667732370449812
    float:  -0.110068545341491699218750

Empiriquement, emacs ferait donc ses calculs en virgule
flottante double précision, et SBCL en simple.

Bonne journée,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Re : emacs lisp et (- 0.07 0.18) et aussi SBCL

[nicolas . patrois]

Le 24/10/2021 18:44:28, kaliderus a écrit :

> J'avais déjà remarqué ce phénomène, et voici ce que me donne le
> résultat mentionné en objet
> (- 0.07 0.18)
> dans emacs : -0.10999
> avec SBCL : -0.1101

> Quelqu'un saurait-il me dire pourquoi ?

Et en Python 3 :
>>> 0.07-0.18
-0.10999

On dirait que SBCL utilise une moins grande précision dans la représentation 
des flottants.
Oui, le problème vient du fait que 0,07 n’est pas un nombre binaire à virgule 
(comme 1/3 n’est pas un nombre décimal).
Donc il y a une approximation.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: emacs lisp et (- 0.07 0.18) et aussi SBCL

[Basile Starynkevitch]

On 24/10/2021 18:44, kaliderus wrote:

Bonjour la liste,

J'avais déjà remarqué ce phénomène, et voici ce que me donne le
résultat mentionné en objet
(- 0.07 0.18)
dans emacs : -0.10999
avec SBCL : -0.1101

Quelqu'un saurait-il me dire pourquoi ?
Ce que je pourrai éventuellement comprendre avec des très grands
nombres par exemple, ou des valeurs franchement exotiques, mais avec
des valeurs qui doivent être réelles et qui ne dépassent pas la
capacité mémoire de la machine, chaque implémentation devrait me
semble-t-il donner le même résultat, et qui plus est exact...
Je suis apprenti en common lisp.

Merci à chacun.



Si j'ai bonne mémoire, la norme Common Lisp impose le calcul en bignums 
ou nombres à précision arbitrairement grande.


Alors que GNU emacs utilise des flottants IEEE754.

La lecture des codes sources respectifs devrait confirmer cette intuition.

Et le livre de Christian Queinnec 
https://pages.lip6.fr/Christian.Queinnec/WWW/LiSP.html est une lecture 
conseillée.





--
Basile Starynkevitch  
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

emacs lisp et (- 0.07 0.18) et aussi SBCL

[kaliderus]

Bonjour la liste,

J'avais déjà remarqué ce phénomène, et voici ce que me donne le
résultat mentionné en objet
(- 0.07 0.18)
dans emacs : -0.10999
avec SBCL : -0.1101

Quelqu'un saurait-il me dire pourquoi ?
Ce que je pourrai éventuellement comprendre avec des très grands
nombres par exemple, ou des valeurs franchement exotiques, mais avec
des valeurs qui doivent être réelles et qui ne dépassent pas la
capacité mémoire de la machine, chaque implémentation devrait me
semble-t-il donner le même résultat, et qui plus est exact...
Je suis apprenti en common lisp.

Merci à chacun.

Re: Strange emacs behavior after upgrade to bullseye

[Curt]

On 2021-04-20, Rainer Dorsch  wrote:
>
> Other editors (vi, kate) don't report any issue when performain an edit 
> operation. Is emacs trying to derive permissions in a different way?

There's this bug, which may or may not be pertinent.

https://gnu.emacs.bug.narkive.com/LoN17xVM/bug-37884-27-0-50-cannot-write-to-a-file-in-virtualbox-shared-directory

> Thanks
> Rainer
>


-- 

Re: Strange emacs behavior after upgrade to bullseye

[Rainer Dorsch]

Hi David,

I did some more testing, you can see the effect on bullseye without vboxsf even 
on a ext4 filesystem.

Am Mittwoch, 21. April 2021, 20:49:14 CEST schrieb David Wright:
[...deleted a lot of history]
> > -> buster emacs did not care at all about .# on filesystems which do not
> > support symlinks. Somehow the permissions changed while the system was on
> > buster, possibly by virtualbox or by me myself in an accidential or
> > intended chmod -R a-w  or something similar. I noticed the error but
> > reverted it only for the visible files. But since buster emacs did not
> > care nobody noticed.
> I can't reproduce that. I get locks (that are files) and autosave
> files, both these being listed in the usual manner in each user's own
> respective ~/.emacs.d/.saves--~ files.
> However, AIUI locks only get created by the user who owns the directory
> (I assume), and not by others. In your case, the owner was root, and
> you were not running emacs as root.
> 
> Also bear in mind that locks aren't created until a need arises.
> Opening a file in emacs is not enough: you have to modify the buffer.
> 
> Upon attempting to save a file being edited by several users, I get
> the expected response with the user@host and PID of any valid lock.
> I also observe the use of ~/.emacs.d/%backup%~ when an instance won't
> overwrite the normal backup file, filename~, which it realises it
> didn't write itself, perhaps.

I did go to a buster system with btrfs:

rd@master:~$ touch test.txt
rd@master:~$ touch .#test.txt
rd@master:~$ chmod a-w .#test.txt
rd@master:~$ emacs test.txt
 
works without emacs complaining about anything.

.# files are created as symlinks. I had no filesystem which does not support 
symlinks on that system.

> > -> bullseye emacs not does not create the .# files on file systems, if
> > they
> > don't have symlink support. But it finds them and puts the file in
> > read-only mode, if it is there. In addition, it tries to cleanup and
> > delete these files, which failed due to the wrong permission.
> > 
> > Even on a file system which supports symlinks, the problem can be easily
> > reproduced by
> > 
> > rd@h370:~$ touch test.txt
> > rd@h370:~$ touch .#test.txt
> > rd@h370:~$ chmod a-w .#test.txt
> > rd@h370:~$ emacs test.txt
> > 
> > What is somewhat ugly is that after toggling read-only mode and editing
> > the
> > file, I cannot leave emacs anymore, it hangs.
> > 
> > I am undecided if that is a bug and I should report it or a real corner
> > case which is not worth to invest more time.
> 
> When I start (buster) emacs with a fake, empty lock(file), even one
> that I own like the above, it's not refreshed, but merely ignored.
> Nor is the fake lock removed when emacs exits. I would assume that
> a lock only works if the information it holds is valid, as far as
> can be determined. I haven't bothered to check what happens with
> manifestly stale locks (ie holding verifiable information).
> 
> I don't know how vboxsf is implemented, but I think it would be
> necessary to disentangle the effects of the underlying components,
> filesystem, OS, access method, before attributing strange behaviour
> to emacs.

On the bullseye system with ext4 (but I do not expect that ext4 vs btrfs makes 
a difference):

rd@h370:~$ touch test.txt
rd@h370:~$ touch .#test.txt
rd@h370:~$ chmod a-w .#test.txt
rd@h370:~$ emacs test.txt
 
opens test.txt as read only and if I modify it and try to leave emacs it even 
hangs.

Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Re: Strange emacs behavior after upgrade to bullseye

[David Wright]

On Tue 20 Apr 2021 at 20:43:46 (+0200), Rainer Dorsch wrote:
> Am Dienstag, 20. April 2021, 17:08:57 CEST schrieb Stefan Monnier:
> > > Because the error says it cannot use LOCKS.
> > > Because you can't do Unix file locking on a non-Unix file system.
> > > The error does NOT say "Permission denied".
> > 
> > FWIW, the error comes from Emacs's own locking code which doesn't seem
> > to use unix file locking, so the problem comes from elsewhere.
> > 
> > Emacs implements its locking protocol using symlinks with names
> > that look like `.#` and whose content looks like
> > `u...@host.pid:BOOT_TIME`.
> 
> many thanks for that excellent diagnosis, that really helped to trace it down:
> 
> - indeed vboxsf does not support symlinks (at least if ntfs is shared). But 
> instead of the symlinks there were real files. I assume a prior version of 
> emacs created them and used this as backup if the symlinks did not work on a 
> filesystem

My comments are only on buster. I don't use vboxsf.

On a vfat USB stick, emacs can create locks and autosave files as
usual, where the lock, .#filename, is a file containing the target
of what would normally be a symlink.

(BTW I'd avoid using the term "backup", and say instead, perhaps,
"alternative method".)

> - These files had permission 555 instead of 777. Changing this back (?) to 
> 777 
> resolved the problem.

Write-protecting the contents of lockfiles seems reasonable in that
their username, hostname, PID, and process start time are invariant.
However, I've been testing on a single system with a vfat filesystem,
mounted so as to give 777 permissions (to test sharing), and haven't
observed them being set that way, or changing.

I have no idea what the role of vboxsf/Windows/NTFS would be, or
would have been at the time (2019, you say) these files were created.

> How that happened I cannot tell. I do not even understand what these 
> permissions mean on vboxsf, apparently they do at least something.
> 
> Maybe one explanation model:
> 
> -> I noticed that the timestamp of the .# lock files were super old (2019) on 
> the vboxsf file system even for files which I touched many times with emacs 
> since then
> -> I noticed that if I edit these files with emacs the .# lock files are not 
> created anymore on the vboxsf filesystem by bullseye's emacs, but they get 
> removed if I close bullseye's emacs
> 
> So I speculate
> 
> -> stretch emacs used .# files instead of .# symlinks, if the file system did 
> not support symlinks. The content of the file contains the information which 
> is 
> otherwise encoded in the symlink target

I don't think this is contentious.

> -> buster emacs did not care at all about .# on filesystems which do not 
> support symlinks. Somehow the permissions changed while the system was on 
> buster, possibly by virtualbox or by me myself in an accidential or intended 
> chmod -R a-w  or something similar. I noticed the error but reverted it only 
> for the visible files. But since buster emacs did not care nobody noticed.

I can't reproduce that. I get locks (that are files) and autosave
files, both these being listed in the usual manner in each user's own
respective ~/.emacs.d/.saves--~ files.
However, AIUI locks only get created by the user who owns the directory
(I assume), and not by others. In your case, the owner was root, and
you were not running emacs as root.

Also bear in mind that locks aren't created until a need arises.
Opening a file in emacs is not enough: you have to modify the buffer.

Upon attempting to save a file being edited by several users, I get
the expected response with the user@host and PID of any valid lock.
I also observe the use of ~/.emacs.d/%backup%~ when an instance won't
overwrite the normal backup file, filename~, which it realises it
didn't write itself, perhaps.

> -> bullseye emacs not does not create the .# files on file systems, if they 
> don't have symlink support. But it finds them and puts the file in read-only 
> mode, if it is there. In addition, it tries to cleanup and delete these 
> files, 
> which failed due to the wrong permission.
> 
> Even on a file system which supports symlinks, the problem can be easily 
> reproduced by
> 
> rd@h370:~$ touch test.txt
> rd@h370:~$ touch .#test.txt
> rd@h370:~$ chmod a-w .#test.txt
> rd@h370:~$ emacs test.txt
> 
> What is somewhat ugly is that after toggling read-only mode and editing the 
> file, I cannot leave emacs anymore, it hangs.
> 
> I am undecided if that is a bug and I should report it or a real corner case 
> which is not worth to invest more time.

When I start (buster) emacs with a fake, empty lock(file), even one
that I own like the above, it's not refreshed, but merely ignored

Re: Strange emacs behavior after upgrade to bullseye

[Rainer Dorsch]

Am Dienstag, 20. April 2021, 17:08:57 CEST schrieb Stefan Monnier:
> > Because the error says it cannot use LOCKS.
> > Because you can't do Unix file locking on a non-Unix file system.
> > The error does NOT say "Permission denied".
> 
> FWIW, the error comes from Emacs's own locking code which doesn't seem
> to use unix file locking, so the problem comes from elsewhere.
> 
> Emacs implements its locking protocol using symlinks with names
> that look like `.#` and whose content looks like
> `u...@host.pid:BOOT_TIME`.
> 
> 
> Stefan "still not sure exactly where it goes wrong"

Hi Stefan,

many thanks for that excellent diagnosis, that really helped to trace it down:

- indeed vboxsf does not support symlinks (at least if ntfs is shared). But 
instead of the symlinks there were real files. I assume a prior version of 
emacs created them and used this as backup if the symlinks did not work on a 
filesystem

- These files had permission 555 instead of 777. Changing this back (?) to 777 
resolved the problem.

How that happened I cannot tell. I do not even understand what these 
permissions mean on vboxsf, apparently they do at least something.

Maybe one explanation model:

-> I noticed that the timestamp of the .# lock files were super old (2019) on 
the vboxsf file system even for files which I touched many times with emacs 
since then
-> I noticed that if I edit these files with emacs the .# lock files are not 
created anymore on the vboxsf filesystem by bullseye's emacs, but they get 
removed if I close bullseye's emacs

So I speculate

-> stretch emacs used .# files instead of .# symlinks, if the file system did 
not support symlinks. The content of the file contains the information which is 
otherwise encoded in the symlink target

-> buster emacs did not care at all about .# on filesystems which do not 
support symlinks. Somehow the permissions changed while the system was on 
buster, possibly by virtualbox or by me myself in an accidential or intended 
chmod -R a-w  or something similar. I noticed the error but reverted it only 
for the visible files. But since buster emacs did not care nobody noticed.

-> bullseye emacs not does not create the .# files on file systems, if they 
don't have symlink support. But it finds them and puts the file in read-only 
mode, if it is there. In addition, it tries to cleanup and delete these files, 
which failed due to the wrong permission.

Even on a file system which supports symlinks, the problem can be easily 
reproduced by

rd@h370:~$ touch test.txt
rd@h370:~$ touch .#test.txt
rd@h370:~$ chmod a-w .#test.txt
rd@h370:~$ emacs test.txt

What is somewhat ugly is that after toggling read-only mode and editing the 
file, I cannot leave emacs anymore, it hangs.

I am undecided if that is a bug and I should report it or a real corner case 
which is not worth to invest more time.

Thanks again, that was a great help.
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Re: Strange emacs behavior after upgrade to bullseye

[Rainer Dorsch]

Am Dienstag, 20. April 2021, 13:50:14 CEST schrieb to...@tuxteam.de:
> On Tue, Apr 20, 2021 at 07:28:19AM -0400, Greg Wooledge wrote:
> > On Tue, Apr 20, 2021 at 12:39:13PM +0200, to...@tuxteam.de wrote:
> > > On Tue, Apr 20, 2021 at 12:00:05PM +0200, Rainer Dorsch wrote:
> > > > For me the crucial message is
> > > > 
> > > > basic-save-buffer-2: Unlocking file: Operation not permitted,
> > > > /mnt/dor1rt/Local/ Managed/sb.blog
> > > 
> > > Anyway, this is a good hint. See
> > > 
> > >   "18.3.4 Protection against Simultaneous Editing"
> > > 
> > > in the Emacs user manual (or, if you prefer reading in a browser,
> > > here [1].
> > > 
> > > But your permissions set up is... strange. The above behaviour
> > > doesn't look plausible to me. Unless rd is actually root.
> > 
> > Or /mnt/dor1rt/Local/ is on a non-Unix file system.  Perhaps it's a
> > removable USB device with an NTFS or FAT type file system.  Or perhaps
> > it's some sort of network file system whose underlying implementation
> > is not Unix-based.
> 
> Yes, non-Unix file system os definitely a reasonable option: the
> /mnt/ part (and the 777 modes everywhere) could be seen as a
> hint :-)

Yes, correct, its mounted through virtualbox (vboxsf) and the host is a window 
system which uses NTFS (I think). From a permission perspective 777 should be 
sufficient though. The question is why does emacs think that is not enough, and 
opens it as read-only? And even if I toggle the read-only mode, it complains 
while writing...

thanks
Rainer


-- 
Rainer Dorsch
http://bokomoko.de/

Re: Strange emacs behavior after upgrade to bullseye

[David Wright]

On Tue 20 Apr 2021 at 15:59:00 (+0200), Rainer Dorsch wrote:
> Am Dienstag, 20. April 2021, 13:50:14 CEST schrieb to...@tuxteam.de:
> > On Tue, Apr 20, 2021 at 07:28:19AM -0400, Greg Wooledge wrote:
> > > On Tue, Apr 20, 2021 at 12:39:13PM +0200, to...@tuxteam.de wrote:
> > > > On Tue, Apr 20, 2021 at 12:00:05PM +0200, Rainer Dorsch wrote:
> > > > > For me the crucial message is
> > > > > 
> > > > > basic-save-buffer-2: Unlocking file: Operation not permitted,
> > > > > /mnt/dor1rt/Local/ Managed/sb.blog
> > > > 
> > > > Anyway, this is a good hint. See
> > > > 
> > > >   "18.3.4 Protection against Simultaneous Editing"
> > > > 
> > > > in the Emacs user manual (or, if you prefer reading in a browser,
> > > > here [1].
> > > > 
> > > > But your permissions set up is... strange. The above behaviour
> > > > doesn't look plausible to me. Unless rd is actually root.
> > > 
> > > Or /mnt/dor1rt/Local/ is on a non-Unix file system.  Perhaps it's a
> > > removable USB device with an NTFS or FAT type file system.  Or perhaps
> > > it's some sort of network file system whose underlying implementation
> > > is not Unix-based.
> > 
> > Yes, non-Unix file system os definitely a reasonable option: the
> > /mnt/ part (and the 777 modes everywhere) could be seen as a
> > hint :-)
> 
> Yes, correct, its mounted through virtualbox (vboxsf) and the host is a 
> window 
> system which uses NTFS (I think). From a permission perspective 777 should be 
> sufficient though. The question is why does emacs think that is not enough, 
> and 
> opens it as read-only? And even if I toggle the read-only mode, it complains 
> while writing...

I would assume that, because the file is on a foreign system, emacs
wants to use file-locking to protect against two programs making
changes at the same time. For whatever reason, its attempts to lock
the file fail in such a way to (perhaps) think that the file is
already locked, or just open the file readonly out of an abundance
of caution (to use that trending phrase).

When you toggle the file to read/write, you're effectively overriding
either the lock or the caution. As pointed out, the complaint upon
writing is probably emacs trying to lock the file while it writes
the buffer, or to do the unlocking.

If you want to chase this down further, you could try strace, but
do send the output to a file because emacs polls continually,
which spews strace output even while you sit on your hands.

Cheers,
David.

Re: Strange emacs behavior after upgrade to bullseye

[Stefan Monnier]

>> Emacs implements its locking protocol using symlinks with names
>> that look like `.#` and whose content looks like
>> `u...@host.pid:BOOT_TIME`.
>
> Ah, good old dot-locking.  Well, perhaps the OP can test whether it's
> possible to create a symlink in that directory.

That's probably part of the problem, yet the error doesn't seem to come
from the code which would *create* the symlink but rather the one that
would delete it :-(


Stefan

Re: Strange emacs behavior after upgrade to bullseye

[Greg Wooledge]

On Tue, Apr 20, 2021 at 11:08:57AM -0400, Stefan Monnier wrote:
> > Because the error says it cannot use LOCKS.
> > Because you can't do Unix file locking on a non-Unix file system.
> > The error does NOT say "Permission denied".
> 
> FWIW, the error comes from Emacs's own locking code which doesn't seem
> to use unix file locking, so the problem comes from elsewhere.
> 
> Emacs implements its locking protocol using symlinks with names
> that look like `.#` and whose content looks like
> `u...@host.pid:BOOT_TIME`.

Ah, good old dot-locking.  Well, perhaps the OP can test whether it's
possible to create a symlink in that directory.

Re: Strange emacs behavior after upgrade to bullseye

[Stefan Monnier]

> Because the error says it cannot use LOCKS.
> Because you can't do Unix file locking on a non-Unix file system.
> The error does NOT say "Permission denied".

FWIW, the error comes from Emacs's own locking code which doesn't seem
to use unix file locking, so the problem comes from elsewhere.

Emacs implements its locking protocol using symlinks with names
that look like `.#` and whose content looks like
`u...@host.pid:BOOT_TIME`.


Stefan "still not sure exactly where it goes wrong"

Re: Strange emacs behavior after upgrade to bullseye

[Rainer Dorsch]

Just another update which makes emacs behavior even stranger:

Even though emacs reports when saving

basic-save-buffer-2: Unlocking file: Operation not permitted,
 /mnt/dor1rt/Local/ Managed/sb.blog

the file gets saved!

I think somehow emacs gets out of sync with the real system.

Rainer


Am Dienstag, 20. April 2021, 12:00:05 CEST schrieb Rainer Dorsch:
> Am Montag, 19. April 2021, 22:25:44 CEST schrieb to...@tuxteam.de:
> > On Mon, Apr 19, 2021 at 06:48:41PM +0200, Rainer Dorsch wrote:
> > > Hello,
> > > 
> > > I hit a strange emacs issue, which appeared after upgrading to bullseye
> > > (I
> > > think):
> > > 
> > > I have a virtualbox filesystem mounted using the standard virtualbox
> > > mechanisms:
> > > 
> > > rd@Testing:~$ mount |grep dor1rt
> > > dor1rt on /mnt/dor1rt type vboxsf (rw,nodev,relatime)
> > > rd@Testing:~$
> > > 
> > > rd@Testing:~$ ls -l /mnt/dor1rt/Local/Managed/sb.blog
> > > -rwxrwxrwx 1 root root 47086 Apr 19 13:40
> > > /mnt/dor1rt/Local/Managed/sb.blog
> > > rd@Testing:~$
> > 
> > Perhaps Emacs is trying to write a backup file to the directory.
> > Does it have write access to the containing directory?
> > 
> > Cf. the variable `make-backup-files' and those linked in its doc
> > (for this, do C-h v make-backup-files).
> 
> There is nothing which would not allow emacs to write a backup file in that
> directory
> 
> rd@Testing:~/local/Managed$ touch test.txt
> rd@Testing:~/local/Managed$ ls -l test.txt
> -rwxrwxrwx 1 root root 0 Apr 20 11:48 test.txt
> rd@Testing:~/local/Managed$ rm -rf test.txt
> rd@Testing:~/local/Managed$
> 
> For me the crucial message is
> 
> basic-save-buffer-2: Unlocking file: Operation not permitted,
> /mnt/dor1rt/Local/ Managed/sb.blog
> 
> (~/local is a symlink to /mnt/dor1rt/Local/)
> 
> What does this message exactly mean and what is emacs trying to do here?
> 
> Other editors (vi, kate) don't report any issue when performain an edit
> operation. Is emacs trying to derive permissions in a different way?
> 
> Thanks
> Rainer


-- 
Rainer Dorsch
http://bokomoko.de/

Re: Strange emacs behavior after upgrade to bullseye

[Greg Wooledge]

On Tue, Apr 20, 2021 at 03:59:00PM +0200, Rainer Dorsch wrote:
> > > > > basic-save-buffer-2: Unlocking file: Operation not permitted,
> > > > > /mnt/dor1rt/Local/ Managed/sb.blog

> Yes, correct, its mounted through virtualbox (vboxsf) and the host is a 
> window 
> system which uses NTFS (I think). From a permission perspective 777 should be 
> sufficient though. The question is why does emacs think that is not enough, 
> and 
> opens it as read-only? And even if I toggle the read-only mode, it complains 
> while writing...

Because the error says it cannot use LOCKS.

Because you can't do Unix file locking on a non-Unix file system.

The error does NOT say "Permission denied".

It says "Operation not permitted".  That's a COMPLETELY different thing.
It has nothing to do with Unix file permissions,  If you had an error
related to Unix file permissions, it would have said "Permission denied".

You get "Operation not permitted" whenever you try to do something you
can't do, for any reason OTHER than Unix file permissions.  For example,
if you try to listen on a port below 1024 when you don't have that
capability.  Or if you try to mount a file system when you don't have
that capability.

Or if you try to use Unix file locking on a non-Unix file system.

Re: Strange emacs behavior after upgrade to bullseye

[Rainer Dorsch]

Am Montag, 19. April 2021, 22:25:44 CEST schrieb to...@tuxteam.de:
> On Mon, Apr 19, 2021 at 06:48:41PM +0200, Rainer Dorsch wrote:
> > Hello,
> > 
> > I hit a strange emacs issue, which appeared after upgrading to bullseye (I
> > think):
> > 
> > I have a virtualbox filesystem mounted using the standard virtualbox
> > mechanisms:
> > 
> > rd@Testing:~$ mount |grep dor1rt
> > dor1rt on /mnt/dor1rt type vboxsf (rw,nodev,relatime)
> > rd@Testing:~$
> > 
> > rd@Testing:~$ ls -l /mnt/dor1rt/Local/Managed/sb.blog
> > -rwxrwxrwx 1 root root 47086 Apr 19 13:40
> > /mnt/dor1rt/Local/Managed/sb.blog
> > rd@Testing:~$
> 
> Perhaps Emacs is trying to write a backup file to the directory.
> Does it have write access to the containing directory?
> 
> Cf. the variable `make-backup-files' and those linked in its doc
> (for this, do C-h v make-backup-files).
> 

There is nothing which would not allow emacs to write a backup file in that 
directory

rd@Testing:~/local/Managed$ touch test.txt
rd@Testing:~/local/Managed$ ls -l test.txt
-rwxrwxrwx 1 root root 0 Apr 20 11:48 test.txt
rd@Testing:~/local/Managed$ rm -rf test.txt
rd@Testing:~/local/Managed$

For me the crucial message is

basic-save-buffer-2: Unlocking file: Operation not permitted, /mnt/dor1rt/Local/
Managed/sb.blog

(~/local is a symlink to /mnt/dor1rt/Local/)

What does this message exactly mean and what is emacs trying to do here? 

Other editors (vi, kate) don't report any issue when performain an edit 
operation. Is emacs trying to derive permissions in a different way?

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Re: Strange emacs behavior after upgrade to bullseye

[tomas]

On Tue, Apr 20, 2021 at 07:28:19AM -0400, Greg Wooledge wrote:
> On Tue, Apr 20, 2021 at 12:39:13PM +0200, to...@tuxteam.de wrote:
> > On Tue, Apr 20, 2021 at 12:00:05PM +0200, Rainer Dorsch wrote:
> > > For me the crucial message is
> > > 
> > > basic-save-buffer-2: Unlocking file: Operation not permitted, 
> > > /mnt/dor1rt/Local/
> > > Managed/sb.blog
> > 
> > Anyway, this is a good hint. See
> > 
> >   "18.3.4 Protection against Simultaneous Editing"
> > 
> > in the Emacs user manual (or, if you prefer reading in a browser,
> > here [1].
> > 
> > But your permissions set up is... strange. The above behaviour
> > doesn't look plausible to me. Unless rd is actually root.
> 
> Or /mnt/dor1rt/Local/ is on a non-Unix file system.  Perhaps it's a
> removable USB device with an NTFS or FAT type file system.  Or perhaps
> it's some sort of network file system whose underlying implementation
> is not Unix-based.

Yes, non-Unix file system os definitely a reasonable option: the
/mnt/ part (and the 777 modes everywhere) could be seen as a
hint :-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Strange emacs behavior after upgrade to bullseye

[Greg Wooledge]

On Tue, Apr 20, 2021 at 12:39:13PM +0200, to...@tuxteam.de wrote:
> On Tue, Apr 20, 2021 at 12:00:05PM +0200, Rainer Dorsch wrote:
> > For me the crucial message is
> > 
> > basic-save-buffer-2: Unlocking file: Operation not permitted, 
> > /mnt/dor1rt/Local/
> > Managed/sb.blog
> 
> Anyway, this is a good hint. See
> 
>   "18.3.4 Protection against Simultaneous Editing"
> 
> in the Emacs user manual (or, if you prefer reading in a browser,
> here [1].
> 
> But your permissions set up is... strange. The above behaviour
> doesn't look plausible to me. Unless rd is actually root.

Or /mnt/dor1rt/Local/ is on a non-Unix file system.  Perhaps it's a
removable USB device with an NTFS or FAT type file system.  Or perhaps
it's some sort of network file system whose underlying implementation
is not Unix-based.

Re: Strange emacs behavior after upgrade to bullseye

[tomas]

On Tue, Apr 20, 2021 at 12:00:05PM +0200, Rainer Dorsch wrote:
> Am Montag, 19. April 2021, 22:25:44 CEST schrieb to...@tuxteam.de:

[...]

> > Perhaps Emacs is trying to write a backup file to the directory.
> > Does it have write access to the containing directory?

[...]

> There is nothing which would not allow emacs to write a backup file in that 
> directory
> 
> rd@Testing:~/local/Managed$ touch test.txt
> rd@Testing:~/local/Managed$ ls -l test.txt
> -rwxrwxrwx 1 root root 0 Apr 20 11:48 test.txt
> rd@Testing:~/local/Managed$ rm -rf test.txt
> rd@Testing:~/local/Managed$

Strange setup: How does test.text belong to root if you are not root?
I'd understand that it belongs to group root, that's what the setgid
bit is for. But _user_ root?

> For me the crucial message is
> 
> basic-save-buffer-2: Unlocking file: Operation not permitted, 
> /mnt/dor1rt/Local/
> Managed/sb.blog

Anyway, this is a good hint. See

  "18.3.4 Protection against Simultaneous Editing"

in the Emacs user manual (or, if you prefer reading in a browser,
here [1].

But your permissions set up is... strange. The above behaviour
doesn't look plausible to me. Unless rd is actually root.

Cheers

[1] https://www.gnu.org/software/emacs//manual/html_node/emacs/Interlocking.html

 - t


signature.asc
Description: Digital signature

Strange emacs behavior after upgrade to bullseye

[Rainer Dorsch]

Hello,

I hit a strange emacs issue, which appeared after upgrading to bullseye (I 
think):

I have a virtualbox filesystem mounted using the standard virtualbox 
mechanisms:

rd@Testing:~$ mount |grep dor1rt
dor1rt on /mnt/dor1rt type vboxsf (rw,nodev,relatime)
rd@Testing:~$

rd@Testing:~$ ls -l /mnt/dor1rt/Local/Managed/sb.blog
-rwxrwxrwx 1 root root 47086 Apr 19 13:40 /mnt/dor1rt/Local/Managed/sb.blog
rd@Testing:~$

While e.g. the standard KDE editor has no problems opening, editing, and 
saving the file, emacs opens the file in read-only mode. I can disable 
read-only 
mode, but emacs refuses to write, I get "Unlocking file: Operation not 
permitted." Even worse, even if I try to save to ~/ I get the same unlocking 
error. 

Here is what I get in the *Messages* buffer:

Loading /etc/emacs/site-start.d/00debian.el (source)...done
Loading /etc/emacs/site-start.d/50asymptote.el (source)...done
Loading /etc/emacs/site-start.d/50autoconf.el (source)...done
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el 
(source)...done
Loading debian-ispell...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50festival.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...
Loading /usr/share/emacs/site-lisp/latex-cjk-common/cjk-enc.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...done
Loading /etc/emacs/site-start.d/50latexmk.el (source)...done
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...done
Loading /home/rd/.emacs.d/lisp/plantuml-helpers.el (source)...done
Loading /home/rd/.emacs.d/lisp/melpa.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
File exists, but cannot be read
funcall-interactively: Buffer is read-only: #
C-M-g is undefined
completing-read-default: Command attempted to use minibuffer while in minibuffer
Quit
Read-Only mode disabled in current buffer
You can run the command ‘read-only-mode’ with C-x C-q
Read-Only mode disabled in current buffer
Saving file /home/rd/local/Managed/sb.blog...
basic-save-buffer-2: Unlocking file: Operation not permitted, /mnt/dor1rt/Local/
Managed/sb.blog
set-visited-file-name: Unlocking file: Operation not permitted, /mnt/dor1rt/
Local/Managed/sb.blog
Mark set

Any idea or hint how to fix or work around this issue is welcome.

Thanks
Rainer


-- 
Rainer Dorsch
http://bokomoko.de/

Re: Strange emacs behavior after upgrade to bullseye

[tomas]

On Mon, Apr 19, 2021 at 06:48:41PM +0200, Rainer Dorsch wrote:
> Hello,
> 
> I hit a strange emacs issue, which appeared after upgrading to bullseye (I 
> think):
> 
> I have a virtualbox filesystem mounted using the standard virtualbox 
> mechanisms:
> 
> rd@Testing:~$ mount |grep dor1rt
> dor1rt on /mnt/dor1rt type vboxsf (rw,nodev,relatime)
> rd@Testing:~$
> 
> rd@Testing:~$ ls -l /mnt/dor1rt/Local/Managed/sb.blog
> -rwxrwxrwx 1 root root 47086 Apr 19 13:40 /mnt/dor1rt/Local/Managed/sb.blog
> rd@Testing:~$

Perhaps Emacs is trying to write a backup file to the directory.
Does it have write access to the containing directory?

Cf. the variable `make-backup-files' and those linked in its doc
(for this, do C-h v make-backup-files).

Cheers
 - t


signature.asc
Description: Digital signature

pdf-tools, doc-view and emacs 27.1 in bullseye is very slow

[Boyan Penkov]

Hello folks,

Just upgraded to bullseye, and pdf-tools and doc-view for the emacs
folks is very different:

-- startup is very slow, and emacs seems to stutter (like, pre-26,
pre-threading...) on conversion.

-- the place in the pdf is no longer reliably bookmarked

-- doc-view-fit-to-width is no longer reliable over restarts.

Anybody else seeing stuff like this?

Cheers!

-- 
Boyan Penkov

Emacs erreur de chemin vers clang-format.el

[benoit]

Bonjour à toutes et tous,
J'ai commencé à rédiger ce courriel comme une question, mais j'ai trouvé la 
solution en cour de rédaction :
Comment éviter de coder en dur 
"/usr/share/emacs/site-lisp/clang-format-11/clang-format.el" ?
dans mon ficher de config d'emacs j'ai indiqué ça :
(load "/usr/share/emacs/site-lisp/clang-format-11/clang-format.el")
(global-set-key [(meta f)] 'clang-format-buffer)

Après un mise à jour du paquet debian clang-format c'est passé de 9 à 11.
Emacs me disait qu'il ne trouvait pas clang-format.el dans :
"/usr/share/emacs/site-lisp/clang-format-9/clang-format.el"
J'ai longtemps cherché avant de m’apercevoir que c'est moi-même qui ai codé ce 
chemin en dur...
Au départ, j'ai fait comme indiqué ici,
https://stackoverflow.com/questions/59690583/how-do-you-use-clang-format-on-emacs-ubuntu
mais indiquer un chemin en dur c'est toujours mauvais.
Du coup il faut remplacer la première ligne :
;;(load "/usr/share/emacs/site-lisp/clang-format-11/clang-format.el")
(require 'clang-format)
(global-set-key [(meta f)] 'clang-format-buffer)

Par (require 'clang-format)
Emacs a le chemin vers clang-format.el dans la variable 'load-path

Comme indiqué ici :
https://www.emacswiki.org/emacs/LoadPath

Voila poser la question c'est y répondre, comme on dit ! ;-)

--
Benoit

Sent with [ProtonMail](https://protonmail.com) Secure Email.

[SOLVED] emacs problem: M-x write-abbrev-file does not seem to work.

[Default User]

On Thu, Mar 19, 2020 at 1:57 PM davidson  wrote:

> On Thu, 19 Mar 2020, davidson wrote:
> > On Wed, 18 Mar 2020, Default User wrote:
> [snip]
>
> >> dummy@dummy:~$ sudo aptitude show emacs
> >> [sudo] password for default:
> >
> > Just FYI, it would greatly surprise me if you actually needed root
> > privileges for aptitude's "show" command. I wager you could get the
> > same information with
> >
> >  dummy@dummy:~$ aptitude show emacs
> >
> > and save yourself a password entry.
> >
> > (I am wagering, not promising, because I use apt-get exclusively,
>
> *apt-get and apt-cache
>
> > never aptitude.)
> [big snip]
>
> > Then, in emacs, do
> >
> > M-x info
> >
> > This brings up a menu of info documentation properly installed on your
> > system. You'll want to traverse "Emacs" > "Abbrevs".
>
> I now see that GW Haywood has already pointed you to a version of the
> same document, posted on the web:
>
>
> https://lists.debian.org/msgid-search/alpine.deb.2.21.2003191433310.9...@piplus.local.jubileegroup.co.uk
>
> --
>   The day will come  |  Last words, August Spies (1855--1887).
>   When our silence will be   |  Hanged, by the U.S. state of Illinois,
>   More powerful than |  alongside fellow journalists
>   The voices you strangle today  |  Adolf Fischer and Albert Parsons.
>


Davidson, thank you for the link to the information.

1)  Yes,  "dummy@dummy:~$ aptitude show emacs" does work just fine. I guess
I just got into the habit of using "sudo" more than I really need to.

2)  The book is Second Edition (1996).  Almost a quarter of a century old,
but still quite useful, especially for a "mature" program like Emacs.

3)  I do have "emacs-common-non-dfsg" installed, and do have "non-free" in
my /etc/apt/sources.list.  I do use "info" from time to time, but I more
often use man pages, or just search online.

4)  The problem has been SOLVED.
I believe it was due to the insistence on Emacs on using
~/.emacs.d/abbrev_defs to store the saved abbreviations, instead of
~/.abbrev_defs as suggested in the book.
I am guessing this is due to the change in recent years to using ".d"
supplemental directories.

The fix was to change a section of".emacs" from this (in the book):

(setq-default abbrev-mode t)
(read-abbrev-file "~/.abbrev_defs")
(setq save-abbrevs t)

to this:

(setq-default abbrev-mode t)
(setq save-abbrevs t)
(setq abbrev-file-name  "~/.emacs.d/abbrev_defs") ;; tell emacs where to
read abbrev definitions from . . .
;; (read-abbrev-file "~/.emacs.d/abbrev_defs") This line may be obsolete
[from "Learning GNU Emacs"]

[Note: it seems to work either with or without (read-abbrev-file
"~/.emacs.d/abbrev_defs") being commented out].

So now "M-x write-abbrev-file" does seem to save the edited abbreviations
as it was supposed to all along.

I had mentioned that it was possible to manually
edit ~/.emacs.d/abbrev_defs to remove the entry, and then
save ~/.emacs.d/abbrev_defs, as a work-around.

But if I should be able "To delete any abbreviation, delete the line for
that abbreviation and save the file by
typing M-x write-abbrev-file.", then I should be able to do so.

Anyway, problem solved.
Thanks to all for the help.

Re: emacs problem: M-x write-abbrev-file

[Default User]

On Thu, Mar 19, 2020 at 10:54 AM G.W. Haywood <
debian-b...@jubileegroup.co.uk> wrote:

> Hi there,
>
> On Thu, 19 Mar 2020, Default User wrote:
>
> > I'm trying to learn Emacs, using:
> > "Learning GNU Emacs".
> > Old, but it would still seem to be a reputable and authoritative source.
>
> Well I used to use that book, but that was 25 years ago.  Try this instead:
>
>
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Abbrevs.html#Abbrevs
>
> --
>
> 73,
> Ged.
>


G.W., thanks for the link you provided to the Emacs information at
GNU.org.  I'm sure it will be quite helpful over time.

Re: emacs problem: M-x write-abbrev-file does not seem to work.

[davidson]

On Thu, 19 Mar 2020, davidson wrote:

On Wed, 18 Mar 2020, Default User wrote:

[snip]


dummy@dummy:~$ sudo aptitude show emacs
[sudo] password for default:


Just FYI, it would greatly surprise me if you actually needed root
privileges for aptitude's "show" command. I wager you could get the
same information with

 dummy@dummy:~$ aptitude show emacs

and save yourself a password entry.

(I am wagering, not promising, because I use apt-get exclusively,


*apt-get and apt-cache


never aptitude.)

[big snip]


Then, in emacs, do

M-x info

This brings up a menu of info documentation properly installed on your
system. You'll want to traverse "Emacs" > "Abbrevs".


I now see that GW Haywood has already pointed you to a version of the
same document, posted on the web:

  
https://lists.debian.org/msgid-search/alpine.deb.2.21.2003191433310.9...@piplus.local.jubileegroup.co.uk

--
 The day will come  |  Last words, August Spies (1855--1887).
 When our silence will be   |  Hanged, by the U.S. state of Illinois,
 More powerful than |  alongside fellow journalists
 The voices you strangle today  |  Adolf Fischer and Albert Parsons.

Re: emacs problem: M-x write-abbrev-file does not seem to work.

[davidson]

On Wed, 18 Mar 2020, Default User wrote:


Hey, been working on this emacs problem all day.


It would have taken me all day just to write up such a meticulous
account.

TLDR; I have never used the "abbrevs" functionality of emacs. So, (fair
warning) you will not find a direct answer to your question in what I
say below.


I'm running Unstable, up to date.
Cinnamon DE.
64-bit.

dummy@dummy:~$ sudo aptitude show emacs
[sudo] password for default:


Just FYI, it would greatly surprise me if you actually needed root
privileges for aptitude's "show" command. I wager you could get the
same information with

  dummy@dummy:~$ aptitude show emacs

and save yourself a password entry.

(I am wagering, not promising, because I use apt-get exclusively,
never aptitude.)


Package: emacs
Version: 1:26.3+1-1

[snip]


I'm trying to learn Emacs, using:
"Learning GNU Emacs".
Old, but it would still seem to be a reputable and authoritative source.


I am sympathetic to reading older, slightly out-of-date sources of
documentation. I frequently do it myself. So I know that it can be
informative (sometimes in unexpected ways), and I know that at times
it has downsides as well, can add an extra layer of confusion, etc.

That said, if I were you, and if I had not done so already, I would
enable the non-free component in your sources.list, and then install
the (non-free) package "emacs-common-non-dfsg":

| emacs-common-non-dfsg - GNU Emacs common non-DFSG items, including the core 
documentation
|  This package includes the core Emacs documentation: the Emacs Info
|  pages, the Emacs Lisp Reference Manual, and the Emacs Lisp Intro.
|  .
|  GNU Emacs is the extensible self-documenting text editor.  This
|  package contains the architecture independent infrastructure that
|  is not compliant with the Debian Free Software Guidelines.  In
|  particular, this includes some of the GNU Emacs info pages, as they
|  are covered under the GFDL, and specify invariant sections.  See
|  http://www.debian.org/vote/2006/vote_001 for more information.

This should give you the info pages version of the Emacs manual, which
contains a section on Abbrevs (under Advanced Features, I think).

Then, in emacs, do

 M-x info

This brings up a menu of info documentation properly installed on your
system. You'll want to traverse "Emacs" > "Abbrevs".

What little else I have to say would merely be bikeshedding or
poorly-informed speculation, so I'll stop here. Maybe I'll go read
about Abbrevs.

I hope this helps a little, while you're waiting for an emacs wizard
to show up.

Good luck with your project.

--
 The day will come  |  Last words, August Spies (1855--1887).
 When our silence will be   |  Hanged, by the U.S. state of Illinois,
 More powerful than |  alongside fellow journalists
 The voices you strangle today  |  Adolf Fischer and Albert Parsons.

Re: emacs problem: M-x write-abbrev-file

[G.W. Haywood]

Hi there,

On Thu, 19 Mar 2020, Default User wrote:


I'm trying to learn Emacs, using:
"Learning GNU Emacs".
Old, but it would still seem to be a reputable and authoritative source.


Well I used to use that book, but that was 25 years ago.  Try this instead:

https://www.gnu.org/software/emacs/manual/html_node/emacs/Abbrevs.html#Abbrevs

--

73,
Ged.

emacs problem: M-x write-abbrev-file does not seem to work.

[Default User]

Hey, been working on this emacs problem all day.

I'm running Unstable, up to date.
Cinnamon DE.
64-bit.

dummy@dummy:~$ sudo aptitude show emacs
[sudo] password for default:
Package: emacs
Version: 1:26.3+1-1
New: yes
State: installed
Automatically installed: no
Priority: optional
Section: editors
Maintainer: Rob Browning 
Architecture: all
Uncompressed Size: 76.8 k
Depends: emacs-gtk (>= 1:26.3) | emacs-lucid (>= 1:26.3) | emacs-nox (>=
1:26.3)
Provided by: emacs-gtk (1:26.3+1-1), emacs-lucid (1:26.3+1-1), emacs-nox
(1:26.3+1-1)
Description: GNU Emacs editor (metapackage)
 GNU Emacs is the extensible self-documenting text editor. This is a
metapackage that will always
 depend on the latest recommended Emacs variant (currently emacs-gtk).
Homepage: https://www.gnu.org/software/emacs/
Tags: devel::editor, role::dummy, role::metapackage, role::program,
suite::emacs, suite::gnu,
  use::editing

I'm trying to learn Emacs, using:
"Learning GNU Emacs".
Old, but it would still seem to be a reputable and authoritative source.

It says edit .emacs thus:

(setq-default abbrev-mode t)
(read-abbrev-file "~/.abbrev_defs")
(setq save-abbrevs t)

Emacs does NOT like that. It wants the read-abbrev-file to be in emacs.d
instead, and not a hidden file, so:

dummy@dummy:~$ ls ~/.emacs.d/abbrev_defs
-rw-r--r-- 1 dummy dummy 1020 Mar 18 16:38 /home/dummy/.emacs.d/abbrev_defs

and .emacs is like this:

dummy@dummy:~$ cat ~/.emacs
(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(ansi-color-faces-vector
   [default default default italic underline success warning error])
 '(ansi-color-names-vector
   ["black" "red3" "ForestGreen" "yellow3" "blue" "magenta3" "DeepSkyBlue"
"gray50"])
 '(column-number-mode t)
 '(custom-enabled-themes (quote (whiteboard)))
 '(display-time-mode t)
 '(save-place-mode t)
 '(size-indication-mode t))
(custom-set-faces
 ;; custom-set-faces was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(default ((t (:family "DejaVu Sans" :foundry "PfEd" :slant normal :weight
normal :height 181 :width normal)




;; insert date and time

(defvar current-date-time-format "%Y-%m-%d  %H:%M:%S  %Z  (%a)"
  "Format of date to insert with `insert-current-date-time' func
See help of `format-time-string' for possible replacements")

(defvar current-time-format "%H:%M:%S  (%a)"
  "Format of date to insert with `insert-current-time' func.
Note the weekly scope of the command's precision.")

(defun insert-current-date-time ()
  "insert the current date and time into current buffer.
Uses `current-date-time-format' for the formatting the date/time."
   (interactive)
   (insert (format-time-string current-date-time-format (current-time)))
   (insert "\n\n")
   )

(defun insert-current-time ()
  "insert the current time (1-week scope) into the current buffer."
   (interactive)
   (insert (format-time-string current-time-format (current-time)))
   (insert "\n\n")
   )

(global-set-key "\C-c\C-d" 'insert-current-date-time)
(global-set-key "\C-c\C-t" 'insert-current-time)


;; customizations manually added by me:

(setq column-number-indicator-zero-based nil)

(setq default-major-mode 'text-mode)
(add-hook 'text-mode-hook 'turn-on-auto-fill)

(setq-default fill-column 79)

(setq-default flyspell-mode t)

(setq-default abbrev-mode t)
(read-abbrev-file "~/.emacs.d/abbrev_defs")
(setq save-abbrevs t)


I re-start emacs in abbrev-mode (with .emacs, as above).
Now add a word abbreviation: C-x a i g [Enter]
teh [Enter]
the [Enter]
C-x C-c

Emacs saves it in ~/.emacs.d/abbrev_defs (not ~/.abbrev_defs, as shown in
book.)

Re-start emacs. It loads the word abbreviation from ~/.emacs.d/abbrev_defs,
and it works as expected.

BUT, now to REMOVE the word abbreviation from ~/.emacs.d/abbrev_defs . . .
The book says:
"You can edit the word abbreviation list by typing M-x edit-abbrevs
[Enter]".

Then (the book says):

"To delete any abbreviation, delete the line for that abbreviation and save
the file by
typing M-x write-abbrev-file."

So, do:
M-x edit-abbrevs [Enter]
then delete the entry in question,
then do:
M-x write-abbrev-file

It prompts with:
"Write abbrev file: ~/.emacs.d/"

At the prompt, I add "abbrev_defs" like this:
"Write abbrev file: ~/.emacs.d/abbrev_defs"
[Enter].

The prompt disappears, no error message. Good.
Then do:
C-x b to switch to default buffer.
Then do

Re: apt-get build-dep emacs-gtk: unmet dependencies

[Göktuğ Kayaalp]

> It looks as though you have installed from security.debian.org but now
> it's not in your sources.list. If you add a line like
>
> deb http://security.debian.org/  buster/updates main contrib non-free
>
> then do "apt-get update", does that help the "apt-get build-dep"?

This seems to have fixed the issue. I added the line and
updated, now I have this:

libtiff-dev:
  Installed: 4.1.0+git191117-2~deb10u1
  Candidate: 4.1.0+git191117-2~deb10u1
  Version table:
 *** 4.1.0+git191117-2~deb10u1 500
500 http://security.debian.org/debian-security stable/updates/main 
amd64 Packages
100 /var/lib/dpkg/status
 4.0.10-4 500
500 http://ftp.uk.debian.org/debian stable/main amd64 Packages

Thanks a lot!

-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Re: apt-get build-dep emacs-gtk: unmet dependencies

[Clive Standbridge]

> > $ apt-cache policy libtiff-dev libtiff5
> 
> The command (w/ libidn2-0 added) reports:
> 
> libtiff-dev:
>   Installed: (none)
>   Candidate: 4.0.10-4
>   Version table:
>  4.0.10-4 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
> libtiff5:
>   Installed: 4.1.0+git191117-2~deb10u1
>   Candidate: 4.1.0+git191117-2~deb10u1
>   Version table:
>  *** 4.1.0+git191117-2~deb10u1 100
> 100 /var/lib/dpkg/status
>  4.0.10-4 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
> libidn2-0:
>   Installed: 2.0.5-1+deb10u1
>   Candidate: 2.0.5-1+deb10u1
>   Version table:
>  *** 2.0.5-1+deb10u1 100
> 100 /var/lib/dpkg/status
>  2.0.5-1 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
> 

Your installed versions of libtiff5 and libidn2-0 are the same as the versions 
currently in the buster security updates. Contrast:

$ apt-cache policy libtiff-dev libtiff5 libidn2-0
libtiff-dev:
  Installed: 4.1.0+git191117-2~deb10u1
  Candidate: 4.1.0+git191117-2~deb10u1
  Version table:
 *** 4.1.0+git191117-2~deb10u1 990
990 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
 4.0.10-4 990
990 http://deb.debian.org/debian buster/main amd64 Packages
libtiff5:
  Installed: 4.1.0+git191117-2~deb10u1
  Candidate: 4.1.0+git191117-2~deb10u1
  Version table:
 *** 4.1.0+git191117-2~deb10u1 990
990 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
 4.0.10-4 990
990 http://deb.debian.org/debian buster/main amd64 Packages
libidn2-0:
  Installed: 2.0.5-1+deb10u1
  Candidate: 2.0.5-1+deb10u1
  Version table:
 *** 2.0.5-1+deb10u1 990
990 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
 2.0.5-1 990
990 http://deb.debian.org/debian buster/main amd64 Packages


It looks as though you have installed from security.debian.org but now it's not 
in your sources.list. If you add a line like

deb http://security.debian.org/  buster/updates main contrib non-free

then do "apt-get update", does that help the "apt-get build-dep"?

-- 
Cheers,
Clive

Re: apt-get build-dep emacs-gtk: unmet dependencies

[Göktuğ Kayaalp]

> You could try downgrading the two library packages explicitly:
>
> $ apt-get install libtiff5=1.0.10-4 libidn2-0=2.0.5-1

This is what I tried eventually, and it worked, thanks!

> That might result in other errors if doing this breaks versioned
> dependencies from other packages, but it's at least a starting point,
> and worth trying.

It luckily didn’t.

> The real questions are A: how you wound up with these newer versions
> installed in the first place, and B: whether there are similarly "newer
> than anything available in your-configured repos" versions of any
> *other* packages installed.

For A, well, my installation process is like this: use netinst (first I
had tried w/ 10.0, the last time I downloaded 10.2, because who knows,
but it persisted), usual stuff, partitioning (UEFI, rest is ext4, one
LVM vg which includes / and /home, separate /boot in primary partition),
then install, selecting print server, ssh server, and standard packages
(bottom three in tasksel screen).  Then, I reboot and run a script that
basically builds up an ‘apt-get install ...’ command with ~200 pkgs
(ends up installing >4k dependencies).  It uses usual debian stable
repos.  No local .debs, no other repos.  I don’t even use
backports. /etc/apt/preferences is empty.  FWIW, the mentioned
installation command is as follows:

,
| apt-get install -y apt-transport-https curl cups-bsd dnsutils equivs
| gawk gvfs-bin net-tools netcat-openbsd telnet traceroute bind9utils
| moreutils lftp libpam-cgroup libpam-cgfs bridge-utils qemu rsync
| openssh-server network-manager smartmontools entr docker.io snapd rar
| unrar dunst pasystray i3-wm i3status i3lock xinit libxrandr-dev
| network-manager-gnome dbus-x11 pulseaudio pulseaudio-utils pavucontrol
| alsa-oss alsa-utils alsamixergui pcmanfm ristretto xbacklight feh
| gvfs-backends gvfs-fuse okular cheese gimp gparted libreoffice
| libreoffice-gtk3 libreoffice-gnome mpv simple-scan transmission-gtk
| vokoscreen redshift-gtk suckless-tools laptop-mode-tools xclip xdotool
| xinput libnotify-bin devhelp audacity flameshot xfce4-clipman compton
| dconf-editor wmctrl arandr inkscape pdfsam xarchiver lmms libjansson-dev
| libpoppler-glib-dev libpoppler-private-dev spek praat python3-matplotlib
| python3-numpy python3-scipy python3-matplotlib python3-pandas
| python3-sympy python3-nose texlive-full perl-tk pass pv tmux units vim
| vorbis-tools vorbisgain w3m w3m-el webalizer whois syncthing libnss-mdns
| mailutils mairix mutt mpop msmtp procmail certbot dirmngr youtube-dl
| hugo inotify-tools pandoc fbi ddgr hledger jq djvulibre-bin gitit lynx
| pwgen gnupg2 qemu-utils qemu-system-x86 build-essential cvs git git-cvs
| git-email mercurial python-hglib python-dulwich python-fastimport
| python3-pip quilt rcs subversion autoconf autoconf-archive automake
| bmake libuniversal-isa-perl libimage-exiftool-perl libswitch-perl
| cpanminus liblocal-lib-perl perlbrew python python-pip python3-tk
| python3-venv ipython3 python3-notify2 r-base r-recommended r-doc-info
| r-cran-tidyverse r-cran-rio r-cran-psych ruby bundler ri
| haskell-platform haskell-platform-doc redis-server redis-tools gjs
| libgjs-dev gnome-js-common valac valadoc gnuplot feedgnuplot
| exuberant-ctags gdb strace make-doc gawk-doc apt-doc autoconf-doc
| bash-doc binutils-doc aspell-doc binutils-doc bzip2-doc cvs-doc
| debconf-doc diffutils-doc ffmpeg-doc gdb-doc gettext-doc git-doc
| glibc-doc gmp-doc gnuplot-doc gnutls-doc graphviz-doc grub-doc
| imagemagick-doc libtool-doc m4-doc mailutils-doc make-doc multiboot-doc
| ncurses-doc parted-doc pinentry-doc python-apt-doc python-certbot-doc
| python-doc python-numpy-doc python-setuptools-doc python3-doc
| readline-doc rsyslog-doc sgml-base-doc sharutils-doc sqlite3-doc tar-doc
| vim-doc libgtk-3-doc libcairo2-doc libxaw-doc libx11-doc libxcb-doc
| libglib2.0-doc iproute2-doc libasound2-doc docker-doc
| libreoffice-help-en-us
`


> Tracking those down and fixing them would definitely be possible, but
> honestly, if this system was installed so recently you're probably
> better off doing the reinstall and hoping whatever error it was doesn't
> happen this time.

I persistently got the same results after reinstalling twice (botched
one trying to use btrfs on root).  I suppose it could be a problem with
Debian reports.  Do you think I should report this as a bug?

In any case, I’ll try to reinstall on a VM in a few days, maybe this is
a temporary issue w/ package archives, or a packaging bug.


-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: apt-get build-dep emacs-gtk: unmet dependencies

[The Wanderer]

On 2020-02-02 at 17:57, İ. Göktuğ Kayaalp wrote:

>> In turn, please respond on-list only
> 
> I'll try, but I can't use my usual MUA ATM, so sorry if I fail at that.
> 
>> $ apt-cache policy libtiff-dev libtiff5
> 
> The command (w/ libidn2-0 added) reports:
> 
> libtiff-dev:
>   Installed: (none)
>   Candidate: 4.0.10-4
>   Version table:
>  4.0.10-4 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
> libtiff5:
>   Installed: 4.1.0+git191117-2~deb10u1
>   Candidate: 4.1.0+git191117-2~deb10u1
>   Version table:
>  *** 4.1.0+git191117-2~deb10u1 100
> 100 /var/lib/dpkg/status
>  4.0.10-4 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages

So apparently you have a newer version of libtiff5 installed (from
somewhere), but no matching newer version of libtiff-dev is available...

> libidn2-0:
>   Installed: 2.0.5-1+deb10u1
>   Candidate: 2.0.5-1+deb10u1
>   Version table:
>  *** 2.0.5-1+deb10u1 100
> 100 /var/lib/dpkg/status
>  2.0.5-1 500
> 500 http://ftp.uk.debian.org/debian stable/main amd64 Packages

...and similarly a newer version of libidn2-0; you didn't show
libidn-dev, but I'm guessing the same "no newer version available" holds
true there.

You could try downgrading the two library packages explicitly:

$ apt-get install libtiff5=1.0.10-4 libidn2-0=2.0.5-1

That might result in other errors if doing this breaks versioned
dependencies from other packages, but it's at least a starting point,
and worth trying.

The real questions are A: how you wound up with these newer versions
installed in the first place, and B: whether there are similarly "newer
than anything available in your-configured repos" versions of any
*other* packages installed.

Tracking those down and fixing them would definitely be possible, but
honestly, if this system was installed so recently you're probably
better off doing the reinstall and hoping whatever error it was doesn't
happen this time.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: apt-get build-dep emacs-gtk: unmet dependencies

[İ . Göktuğ Kayaalp]

> In turn, please respond on-list only

I'll try, but I can't use my usual MUA ATM, so sorry if I fail at that.

> $ apt-cache policy libtiff-dev libtiff5

The command (w/ libidn2-0 added) reports:

libtiff-dev:
  Installed: (none)
  Candidate: 4.0.10-4
  Version table:
 4.0.10-4 500
500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
libtiff5:
  Installed: 4.1.0+git191117-2~deb10u1
  Candidate: 4.1.0+git191117-2~deb10u1
  Version table:
 *** 4.1.0+git191117-2~deb10u1 100
100 /var/lib/dpkg/status
 4.0.10-4 500
500 http://ftp.uk.debian.org/debian stable/main amd64 Packages
libidn2-0:
  Installed: 2.0.5-1+deb10u1
  Candidate: 2.0.5-1+deb10u1
  Version table:
 *** 2.0.5-1+deb10u1 100
100 /var/lib/dpkg/status
 2.0.5-1 500
500 http://ftp.uk.debian.org/debian stable/main amd64 Packages


I don't have any holds in my prefs.  "showholds" shows none.

I'll probably try a reinstall and report if I still fail installing
emacs25 builddeps.

Cheers,
-gk.

-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: apt-get build-dep emacs-gtk: unmet dependencies

[İ . Göktuğ Kayaalp]

> In my experience with 8 and before, yes, it may be a sign of trouble
> ahead. Was there an apt-get process spinning on a CPU after that point
> in the install?

I didn't check, so IDK.

> IIRC the network-assisted install of a package may have failed because
> the pkg couldn't be found online (say, with sources.list in some certain
> state). Then the install asks for the next mount but fails quietly. It's
> a couple years since Ive had to deal with this.

And I was indeed using the netinst ISO, so it's highly likely it skipped
something.

Guess I just reinstall, that seems to be easier than tracking the cause
of this error.

Cheers,
-gk.

-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: apt-get build-dep emacs-gtk: unmet dependencies

[deloptes]

İ. Göktuğ Kayaalp wrote:

>> But libgnutls28-dev is in buster
> 
> They all are, the problem is that build-dep:emacs requires packages
> which seem to require some downgrades.  These are not major downgrades,
> but minor version or debian package version:
> 
> libtiff-dev : Depends: libtiff5 (= 4.0.10-4) but 4.1.0+git191117-2~deb10u1
> is to be installed
> 
> libgnutls28-dev : Depends: libidn2-dev but it is not going to be installed
> libidn2-dev : Depends: libidn2-0 (= 2.0.5-1) but 2.0.5-1+deb10u1 is to be
> installed
> 
> libmagick++-6.q16-dev : Depends: libmagickcore-6.q16-dev (=
> 8:6.9.10.23+dfsg-2.1) but it is not going to be installed
> Depends: libmagickwand-6.q16-dev (=
> 8:6.9.10.23+dfsg-2.1) but it is not going to be
> installed
> 
> libmagickcore-6.q16-dev : Depends: libtiff-dev but it is not going to be
> installed libmagickwand-6.q16-dev : Depends: libmagickcore-6.q16-dev (=
> 8:6.9.10.23+dfsg-2.1) but it is not going to be installed
> 
> So there's a minor version mismatch w/ libtiff5 and a debian patch
> version mismatch w/ libidn2-0.
> 
> Is there any way I resolve this w/o making a mess?

Don't know what you've done to your system, but here

root@debian10:~# apt-get install libtiff-dev libmagick++-6.q16-dev
libidn2-dev
The following NEW packages will be installed:
  autoconf automake autotools-dev bzip2-doc gir1.2-freedesktop
gir1.2-gdkpixbuf-2.0 gir1.2-rsvg-2.0 icu-devtools javascript-common
libblkid-dev
  libbz2-dev libcairo-gobject2 libcairo-script-interpreter2 libcairo2-dev
libcroco3 libdjvulibre-dev libdpkg-perl libexif-dev libexif-doc libffi-dev
  libfile-fcntllock-perl libfontconfig1-dev libfreetype6-dev
libgdk-pixbuf2.0-dev libglib2.0-bin libglib2.0-dev libglib2.0-dev-bin
libice-dev libicu-dev
  libidn2-dev libilmbase-dev libjbig-dev libjpeg-dev libjpeg62-turbo-dev
libjs-jquery liblcms2-dev liblqr-1-0-dev libltdl-dev liblzma-dev
  libmagick++-6-headers libmagick++-6.q16-8 libmagick++-6.q16-dev
libmagickcore-6-arch-config libmagickcore-6-headers libmagickcore-6.q16-dev
  libmagickwand-6-headers libmagickwand-6.q16-dev libmount-dev
libopenexr-dev libopenjp2-7-dev libpcre16-3 libpcre3-dev libpcre32-3
libpcrecpp0v5
  libpixman-1-dev libpng-dev libpng-tools libpthread-stubs0-dev librsvg2-2
librsvg2-common librsvg2-dev libselinux1-dev libsepol1-dev libsigsegv2
  libsm-dev libtiff-dev libtiffxx5 libtool libwmf-dev libx11-dev libxau-dev
libxcb-render0-dev libxcb-shm0-dev libxcb1-dev libxdmcp-dev libxext-dev
  libxml2-dev libxrender-dev libxt-dev m4 pkg-config uuid-dev
x11proto-core-dev x11proto-dev x11proto-xext-dev xorg-sgml-doctools
xtrans-dev zlib1g-dev
0 upgraded, 88 newly installed, 0 to remove and 0 not upgraded.
Need to get 43.1 MB of archives.
After this operation, 142 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Install the dependencies required and build.

Re: apt-get build-dep emacs-gtk: unmet dependencies

[Nicholas Geovanis]

On Sun, Feb 2, 2020, 9:51 AM İ. Göktuğ Kayaalp  wrote:

> Hi all,
> 
> Lastly, there was an error during installation yesterday, package
> installation was paused when I returned to my computer, so I restarted
> the installation process.  It downloaded one more package and installed
> it, and the rest was fine.  Could that have anything to do with the
> present situation?
>

In my experience with 8 and before, yes, it may be a sign of trouble ahead.
Was there an apt-get process spinning on a CPU after that point in the
install?
IIRC the network-assisted install of a package may have failed because the
pkg couldn't be found online (say, with sources.list in some certain
state). Then the install asks for the next mount but fails quietly. It's a
couple years since Ive had to deal with this.

Thanks in advance,
> -gk.
>
> --
> İ. Göktuğ Kayaalp / @cadadr / 
> pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427
>
>

Re: apt-get build-dep emacs-gtk: unmet dependencies

[The Wanderer]

(I'm replying both public and private in response to your request for
such in another message. In turn, please respond on-list only -
preferably to the copy transmitted via the list, if possible; the way
you replied to deloptes seems to have produced the desired effect, at
least by what is publicly visible.)

On 2020-02-02 at 11:55, İ. Göktuğ Kayaalp wrote:

>> But libgnutls28-dev is in buster
> 
> They all are, the problem is that build-dep:emacs requires packages
> which seem to require some downgrades.  These are not major downgrades,
> but minor version or debian package version:
> 
> libtiff-dev : Depends: libtiff5 (= 4.0.10-4) but 4.1.0+git191117-2~deb10u1 is 
> to be installed

What versions of libtiff-dev do you have available? In particular, what does

$ apt-cache policy libtiff-dev libtiff5

say?

> libidn2-dev : Depends: libidn2-0 (= 2.0.5-1) but 2.0.5-1+deb10u1 is to be 
> installed

Similarly here.

> So there's a minor version mismatch w/ libtiff5 and a debian patch
> version mismatch w/ libidn2-0.
> 
> Is there any way I resolve this w/o making a mess?

Almost certainly. You just have to figure out what is making it decide
not to upgrade libtiff5 and libidn2.

The most common reasons in my experience are package holds / pins; I
think there are other reasons possible, but I can't think of them
offhand.

Is there anything relevant in /etc/apt/preferences, or in files inside
/etc/apt/preferences.d/ ?

What does

$ apt-mark showhold

report?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: apt-get build-dep emacs-gtk: unmet dependencies

[İ . Göktuğ Kayaalp]

BTW I'd really appreciate if you could reply to me on-list instead of to
the list only, given I'm not subscribed to the list.

Thanks a lot in advance!

-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: apt-get build-dep emacs-gtk: unmet dependencies

[İ . Göktuğ Kayaalp]

> But libgnutls28-dev is in buster

They all are, the problem is that build-dep:emacs requires packages
which seem to require some downgrades.  These are not major downgrades,
but minor version or debian package version:

libtiff-dev : Depends: libtiff5 (= 4.0.10-4) but 4.1.0+git191117-2~deb10u1 is 
to be installed

libgnutls28-dev : Depends: libidn2-dev but it is not going to be installed
libidn2-dev : Depends: libidn2-0 (= 2.0.5-1) but 2.0.5-1+deb10u1 is to be 
installed

libmagick++-6.q16-dev : Depends: libmagickcore-6.q16-dev (= 
8:6.9.10.23+dfsg-2.1) but it is not going to be installed
Depends: libmagickwand-6.q16-dev (= 
8:6.9.10.23+dfsg-2.1) but it is not going to be installed

libmagickcore-6.q16-dev : Depends: libtiff-dev but it is not going to be 
installed
libmagickwand-6.q16-dev : Depends: libmagickcore-6.q16-dev (= 
8:6.9.10.23+dfsg-2.1) but it is not going to be installed

So there's a minor version mismatch w/ libtiff5 and a debian patch
version mismatch w/ libidn2-0.

Is there any way I resolve this w/o making a mess?

-- 
İ. Göktuğ Kayaalp / @cadadr / 
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: apt-get build-dep emacs-gtk: unmet dependencies

[deloptes]

İ. Göktuğ Kayaalp wrote:

> I follow Emacs' master branch for my day-to-day use, so I need to build
> it manually for my daily workflow.  Yesterday I did a fresh reinstall of
> Debian 10, after which I haven't been able to install build dependencies
> for emacs25 or emacs-gtk.  The error is as follows:
> 
> ,
> | Reading package lists... Done
> | Picking 'emacs' as source package instead of 'emacs25'
> | Reading package lists... Done
> | Building dependency tree
> | Reading state information... Done
> | Some packages could not be installed. This may mean that you have
> | requested an impossible situation or if you are using the unstable
> | distribution that some required packages have not yet been created
> | or been moved out of Incoming.
> | The following information may help to resolve the situation:
> | 
> | The following packages have unmet dependencies:
> | builddeps:emacs : Depends: libtiff-dev but it is not going to be
> | installed Depends: libgnutls28-dev but it is not going to be installed
> | Depends: libmagick++-6.q16-dev but it is not going to be installed
> | E: Unable to correct problems, you have held broken packages.
> `

But libgnutls28-dev is in buster

https://packages.debian.org/buster/amd64/libgnutls28-dev/download

perhaps you need to setup the sources properly and apt-get update/upgrade
and try again

same for libtiff-dev

https://packages.debian.org/buster/amd64/libtiff-dev/download

and libmagick++-6.q16-dev

https://packages.debian.org/buster/amd64/libmagick++-6.q16-dev/download

regards

apt-get build-dep emacs-gtk: unmet dependencies

[İ . Göktuğ Kayaalp]

Hi all,

I follow Emacs' master branch for my day-to-day use, so I need to build
it manually for my daily workflow.  Yesterday I did a fresh reinstall of
Debian 10, after which I haven't been able to install build dependencies
for emacs25 or emacs-gtk.  The error is as follows:

,
| Reading package lists... Done
| Picking 'emacs' as source package instead of 'emacs25'
| Reading package lists... Done
| Building dependency tree   
| Reading state information... Done
| Some packages could not be installed. This may mean that you have
| requested an impossible situation or if you are using the unstable
| distribution that some required packages have not yet been created
| or been moved out of Incoming.
| The following information may help to resolve the situation:
| 
| The following packages have unmet dependencies:
|  builddeps:emacs : Depends: libtiff-dev but it is not going to be installed
|Depends: libgnutls28-dev but it is not going to be 
installed
|Depends: libmagick++-6.q16-dev but it is not going to be 
installed
| E: Unable to correct problems, you have held broken packages.
`

The output for emacs-gtk is also identical.  My /etc looks like this:
https://github.com/cadadr/configuration/tree/master/systems/alpha/etc

When I investigate further, trying to "apt-get install" the packages
with unmet dependencies, my observation is that installing these
packages requires downgrading some dependencies.

Is this a temporary problem, or does it have anything to do with my
configuration?  If it's possible, how can I fix this?  I really need a
build of Emacs ASAP, so I'm willing to force downgrade or upgrade any
packages if they don't really pose a problem to the end user.

Lastly, there was an error during installation yesterday, package
installation was paused when I returned to my computer, so I restarted
the installation process.  It downloaded one more package and installed
it, and the rest was fine.  Could that have anything to do with the
present situation?

Thanks in advance,
-gk.

-- 
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[tomas]

On Thu, Jan 30, 2020 at 10:12:25AM +0200, Andrei POPESCU wrote:

[...

> It's a default in the most common packaging tool that saves work for 
> many maintainers (they don't need to explicitly mark files under /etc as 
> conffiles).
> 
> To me it's quite clear that conffiles are typically in /etc (the text 
> explicitly allows for other possibilities), but not every 
> (configuration) file in /etc is a conffile.

That's true, yes.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Andrei POPESCU]

On Mi, 29 ian 20, 08:41:41, to...@tuxteam.de wrote:
> On Wed, Jan 29, 2020 at 08:48:56AM +0200, Andrei POPESCU wrote:
> > 
> > It seems to me you are conflating dpkg conffiles[1] with files in /etc.
> > 
> > [1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html
> 
> Yep, but this [2] /strongly/ suggests that conffiles are exactly those
> living under /etc.

It's a default in the most common packaging tool that saves work for 
many maintainers (they don't need to explicitly mark files under /etc as 
conffiles).

To me it's quite clear that conffiles are typically in /etc (the text 
explicitly allows for other possibilities), but not every 
(configuration) file in /etc is a conffile.
 
> Cheers
> [2] https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles

The 3rd paragraph explicitly recommends *not* marking files as conffiles 
if they must be changed through other mechanisms (I believe cups does 
this, but am too lazy to check).

It then goes on about how to deal with having a configuration file (not 
conffile) in /etc that is not managed by dpkg.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[tomas]

On Wed, Jan 29, 2020 at 08:48:56AM +0200, Andrei POPESCU wrote:
> On Ma, 28 ian 20, 09:59:44, to...@tuxteam.de wrote:
> > On Mon, Jan 27, 2020 at 07:54:47PM -0600, Nate Bargmann wrote:
> > 
> > >  As that package apparently is required for the Mate desktop, it's
> > > likely that to resolve this that you'll need to comment the lines in
> > > that file as root and note that package upgrades may overwrite your
> > > commented file with the one supplied with the package.
> > 
> > This would be a Debian policy violation. /etc is taboo, sysadmin
> > overrides (you get asked at upgrade, though, so some vigilance is
> > in order).
> 
> It seems to me you are conflating dpkg conffiles[1] with files in /etc.
> 
> [1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html

Yep, but this [2] /strongly/ suggests that conffiles are exactly those
living under /etc.

Cheers
[2] https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles

-- tomás


signature.asc
Description: Digital signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Andrei POPESCU]

On Ma, 28 ian 20, 09:59:44, to...@tuxteam.de wrote:
> On Mon, Jan 27, 2020 at 07:54:47PM -0600, Nate Bargmann wrote:
> 
> >  As that package apparently is required for the Mate desktop, it's
> > likely that to resolve this that you'll need to comment the lines in
> > that file as root and note that package upgrades may overwrite your
> > commented file with the one supplied with the package.
> 
> This would be a Debian policy violation. /etc is taboo, sysadmin
> overrides (you get asked at upgrade, though, so some vigilance is
> in order).

It seems to me you are conflating dpkg conffiles[1] with files in /etc.

[1] https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Tom Browder]

On Tue, Jan 28, 2020 at 9:33 AM Curt  wrote:...
...

Okay, I've taken Curt's and Greg's suggestions together:

1. I had to install the dconf-editor package. I was able to use the
dconf editor to turn off the xrdb plugin. I then logged off and logged
back in. Highlighting is working.

Note: The deconf-editor has to be executed from the CLI (dconf-editor
&). It is not greatly intuitive. I had to search for xrdb to get to a
screen to turn off a slider widget.

2. In my home directory I ran "xrdb -query > highlight-works.txt"

It shows none of the original *emacs* stuff.

I'll report results later after I've given this a few days.

Thank you so much Nate, Tomas, Curt, David, Byung-Hee, and Greg!

Debian folks are great!

Cheers!

-Tom

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Curt]

On 2020-01-28, Tom Browder  wrote:
>
> On Tue, Jan 28, 2020 at 07:36 Greg Wooledge  wrote:
>
>> On Mon, Jan 27, 2020 at 04:11:33PM -0600, Tom Browder wrote:
>> >   when highlighting disappears, run "xrdb /dev/null" and restart emacs
>>
>> So, wait.  You're saying that it *works for a little while* after
>> you log in, and then at some point later, it *stops working*?
>>
>> If that's actually the case, then maybe you can pinpoint the offending
>> X resource by doing
>>
>> xrdb -query > working
>
> ...
>
> Great idea, Greg. And that goes hand-on-hand with my "giving up" method!

As mate-settings-daemon is a daemon, it may be the culprit here, too.

> But I will take a shot at Curt's method first.
>
> Cheers!
>
> -Tom
>


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Tom Browder]

On Tue, Jan 28, 2020 at 07:36 Greg Wooledge  wrote:

> On Mon, Jan 27, 2020 at 04:11:33PM -0600, Tom Browder wrote:
> >   when highlighting disappears, run "xrdb /dev/null" and restart emacs
>
> So, wait.  You're saying that it *works for a little while* after
> you log in, and then at some point later, it *stops working*?
>
> If that's actually the case, then maybe you can pinpoint the offending
> X resource by doing
>
> xrdb -query > working

...

Great idea, Greg. And that goes hand-on-hand with my "giving up" method!

But I will take a shot at Curt's method first.

Cheers!

-Tom

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Tom Browder]

On Tue, Jan 28, 2020 at 07:26 Curt  wrote:
...

> Have you tried my suggestion of yesterday, a method which worked for the
> man in the thread linked at the bottom of this post? You might have to
> be root, and you must have the dconf-editor installed. Open that gui
> app, search for the

...

No, Curt, I didn't, but I will. I'm sorry I glossed over the point about
the dconf editor. I will try that today.

Thanks.

-Tom

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Greg Wooledge]

On Mon, Jan 27, 2020 at 04:11:33PM -0600, Tom Browder wrote:
>   when highlighting disappears, run "xrdb /dev/null" and restart emacs

So, wait.  You're saying that it *works for a little while* after
you log in, and then at some point later, it *stops working*?

If that's actually the case, then maybe you can pinpoint the offending
X resource by doing

xrdb -query > working

right after you log in (possibly after verifying that emacs is in fact
working properly).

Then, after it stops working properly, run the xrdb -query command
again, but redirect it to a different file.  Then use diff to see
what changed.

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Curt]

On 2020-01-28, Tom Browder  wrote:
>
> On Tue, Jan 28, 2020 at 03:09  wrote:
>
>> On Mon, Jan 27, 2020 at 07:57:49PM -0600, Nate Bargmann wrote:
>> > Or it may be as easy as going into the Mate Settings Daemon application
>> > (if it has a GUI) and disabling the xrdg plugin.

> I tried to find that and couldn't.

Have you tried my suggestion of yesterday, a method which worked for the
man in the thread linked at the bottom of this post? You might have to
be root, and you must have the dconf-editor installed. Open that gui
app, search for the

 org.mate.SettingsDaemon.plugins.xrdb

setting and set it to false. Worth a try. Maybe you already did and I
missed it. You might also, as Nate suggested, simply comment out the
relevant or irrelevant lines in /etc/xrdb/Emacs.ad.

Of course, for any of this to have any effect, I believe, at the very
least you need to log out and back in again; verification of eventual
effects might be done with yet another 'xrdb -query'. 

I would point out that the man in the superuser.com thread uses an
~./.Xresources file for certain terminal settings, and the dconf-editor
method of deactivating plugins.xrdb succeeded in preventing that file
from being superseded.
 
> I would like to be able to experiment with other desktops or window
> managers. Can I do that and still return safely to my current setup? If so,
> what do you recommend?

This is purported to be as simple as installing the desired DE and
choosing it rather than Mate during login in your display manager.


https://superuser.com/questions/1351751/xresources-not-loaded-under-mate-desktop

> Best,
>
> -Tom
>
> --93c427059d31e489
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
>On Tue, Jan 28, 2020 at 03:09 mailto:to...@tuxteam.de;>=
> to...@tuxteam.de wrote: lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
> #ccc solid;padding-left:1ex">On Mon, Jan 27, 2020 at 07:57:49PM -0600, Nate=
>  Bargmann wrote:
>  Or it may be as easy as going into the Mate Settings Daemon applicatio=
> n
>  (if it has a GUI) and disabling the xrdg plugin.=3D"auto">I tried to find that and couldnt=
> .I would like to be abl=
> e to experiment with other desktops or window managers. Can I do that and s=
> till return safely to my current setup? If so, what do you recommend?=
>Best,=
>-Tom
>
> --93c427059d31e489--
>
>


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[tomas]

On Tue, Jan 28, 2020 at 05:54:46AM -0600, Tom Browder wrote:
> On Tue, Jan 28, 2020 at 03:09  wrote:
> 
> > On Mon, Jan 27, 2020 at 07:57:49PM -0600, Nate Bargmann wrote:
> > > Or it may be as easy as going into the Mate Settings Daemon application
> > > (if it has a GUI) and disabling the xrdg plugin.
> 
> 
> I tried to find that and couldn't.
> 
> I would like to be able to experiment with other desktops or window
> managers. Can I do that and still return safely to my current setup? If so,
> what do you recommend?

I burnt my bridges when i left, screaming, the last DE I used
(it was XFCE, AFAIR), so I can't give you first-hand advice. But
I know Debian goes a long way in enabling you to choose and change
your environment.

Perhaps set up another (throwaway) user accont to try out.

That said, I don't want to come across as if I consider DEs to be
"something bad": there are many things you'll have to take care
of (e.g. don't expect an USB stick to be automatically mounted on
insert, be prepared to go shopping or hacking -- I went hacking --
when your LCD brigntness control doesn't do what you want, yadda,
yadda).

I think it's a deeper problem, But perhaps off-topic here.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Tom Browder]

On Tue, Jan 28, 2020 at 03:09  wrote:

> On Mon, Jan 27, 2020 at 07:57:49PM -0600, Nate Bargmann wrote:
> > Or it may be as easy as going into the Mate Settings Daemon application
> > (if it has a GUI) and disabling the xrdg plugin.


I tried to find that and couldn't.

I would like to be able to experiment with other desktops or window
managers. Can I do that and still return safely to my current setup? If so,
what do you recommend?

Best,

-Tom

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[tomas]

On Mon, Jan 27, 2020 at 07:57:49PM -0600, Nate Bargmann wrote:
> Or it may be as easy as going into the Mate Settings Daemon application
> (if it has a GUI) and disabling the xrdg plugin.

By all means, do -- and tell us whether it worked (the link
I provided was a bit discouraging: so /if/ that works, it
should be here loud and clear for the search engines to find
and to the benefit of others).

Cheers
-- t


signature.asc
Description: Digital signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[tomas]

On Mon, Jan 27, 2020 at 07:54:47PM -0600, Nate Bargmann wrote:
> * On 2020 27 Jan 16:12 -0600, Tom Browder wrote:
>  
> > Gang, I've tried various combinations of:
> > 
> > 1. removing/installing the /etc/xrdb/*.ad files
> 
> I see that the mate-settings-daemon package has the /etc/xrdb/Emacs.ad
> file.

Yep, that was my impression too: that some desktop environment is
messing up the X resources (not the files, the database in the
server) in some creative way.

>  As that package apparently is required for the Mate desktop, it's
> likely that to resolve this that you'll need to comment the lines in
> that file as root and note that package upgrades may overwrite your
> commented file with the one supplied with the package.

This would be a Debian policy violation. /etc is taboo, sysadmin
overrides (you get asked at upgrade, though, so some vigilance is
in order).

Ah-hah. Some search-engining later: see this

  https://ubuntu-mate.community/t/issue-with-xresources-and-ubuntu-mate/3756

This guy is having the same problem (the solution is inconclusive,
though -- he disabled some "mate X resources plugin" without any
success).

Things like this, BTW, are what at last, drove me away from desktop
environments: they are fiendishly complex, full of quick fire-and
forget contribs "oh, this seems a good idea", and when you have
a serious question... crickets.

Note that I'm not blaming anyone. I'm of the impression that there
aren't enough resources to manage that complexity (and I don't mean
technical, but more the social, i.e. the width of the user base).

Hapy fvwm camper since.

Cheers
-- tomás


signature.asc
Description: Digital signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Nate Bargmann]

Or it may be as easy as going into the Mate Settings Daemon application
(if it has a GUI) and disabling the xrdg plugin.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Nate Bargmann]

* On 2020 27 Jan 16:12 -0600, Tom Browder wrote:
 
> Gang, I've tried various combinations of:
> 
> 1. removing/installing the /etc/xrdb/*.ad files

I see that the mate-settings-daemon package has the /etc/xrdb/Emacs.ad
file.  As that package apparently is required for the Mate desktop, it's
likely that to resolve this that you'll need to comment the lines in
that file as root and note that package upgrades may overwrite your
commented file with the one supplied with the package.  After commenting
those lines, you need to completely restart X11 or use an xrdb command
that I'm not familiar with to flush the xrdb database and clear the
Emacs* namespace.  I'd probably just do a complete system restart.

As I am using Gnome, the /etc/xrdb directory doesn't even exist on my
systems and I don't recall seeing it with Xfce either.  There are four
packages that contain a file named Emacs.ad:

https://packages.debian.org/search?searchon=contents=Emacs.ad=exactfilename=stable=any

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Tom Browder]

On Mon, Jan 27, 2020 at 2:39 AM  wrote:
> On Sun, Jan 26, 2020 at 08:04:29PM -0600, Tom Browder wrote:
> > On Sat, Jan 25, 2020 at 2:17 AM  wrote:
...
>
> Have you had a look in /etc/X11/Xresources?

Yes, contents:

$ cat /etc/X11/Xresources/x11-common
! $Id$

! load color-specific resources for clients that have them
#ifdef COLOR
*customization: -color
#endif

! make Xaw (Athena widget set) clients understand the delete key
! this causes problems with some non-Xaw apps, use with care
! *Text.translations: #override ~Shift ~Meta Delete:
delete-next-character()

Thanks, Tomas.

-Tom



> Cheers
> -- tomás

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Tom Browder]

On Mon, Jan 27, 2020 at 1:00 PM Nate Bargmann  wrote:
> * On 2020 27 Jan 10:11 -0600, Curt wrote:
> > I missed that point, yet I'm still left to wonder whether the mate
> > settings daemon xrdb plugins referenced above (if it is indeed running

Gang, I've tried various combinations of:

1. removing/installing the /etc/xrdb/*.ad files
2. running with an empty .Xresources file
3. running xrdb /dev/null

It seems like this is the only thing that I can do to get highlighting
reliably so far is:

  when highlighting disappears, run "xrdb /dev/null" and restart emacs

Ugh, suggestions welcome, but I'm about to give up.

Thanks for all the suggestions.

If anyone does have an .Xresources file that seems to give a
satisfactory emacs GTK under Buster I would love to get a copy to try
it.

Thanks,

-Tom


> > on the OP's machine as part of the Mate kitchen sink) might be
> > responsible for the rather copious Emacs 'xdrb -query' output he offered
> > up for inspection.
> >
> > Looking at this
> >
> > https://github.com/mate-desktop/mate-settings-daemon/blob/master/plugins/xrdb/data/Emacs.ad
> >
> > there does appear to be similarities. Maybe I'm not understanding the
> > whole thing correctly.
>
> Good sleuth work, Curt.  It looks to me like this is part of a theme
> plugin for Mate.  Beyond playing with it for a short time as to satisfy
> a bit of curiosity, I've not used Mate any length of time.  Still, I find
> it interesting that a Gtk based desktop is tweaking Xresources as that
> was one of things that was seemingly declared "obsolete" about 20+ years
> ago as the new "Linux desktops" began to develop.
>
> Anyway, @ the OP, Tom.  I'd go through the Appearance/theme menus of
> Mate and at least remove or disable this Emacs plugin if it can be found
> through the GUI.
>
> The other thought I had was to create a new user and see if the problem
> followed along.  In this case it probably would.  Another option would
> be to install Xfce and try it, but these thoughts were before I saw
> Curt's message.
>
> - Nate
>
> --
>
> "The optimist proclaims that we live in the best of all
> possible worlds.  The pessimist fears this is true."
>
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Nate Bargmann]

* On 2020 27 Jan 10:11 -0600, Curt wrote:
> I missed that point, yet I'm still left to wonder whether the mate
> settings daemon xrdb plugins referenced above (if it is indeed running
> on the OP's machine as part of the Mate kitchen sink) might be
> responsible for the rather copious Emacs 'xdrb -query' output he offered
> up for inspection.
> 
> Looking at this
> 
> https://github.com/mate-desktop/mate-settings-daemon/blob/master/plugins/xrdb/data/Emacs.ad
> 
> there does appear to be similarities. Maybe I'm not understanding the
> whole thing correctly.

Good sleuth work, Curt.  It looks to me like this is part of a theme
plugin for Mate.  Beyond playing with it for a short time as to satisfy
a bit of curiosity, I've not used Mate any length of time.  Still, I find
it interesting that a Gtk based desktop is tweaking Xresources as that
was one of things that was seemingly declared "obsolete" about 20+ years
ago as the new "Linux desktops" began to develop.

Anyway, @ the OP, Tom.  I'd go through the Appearance/theme menus of
Mate and at least remove or disable this Emacs plugin if it can be found
through the GUI.

The other thought I had was to create a new user and see if the problem
followed along.  In this case it probably would.  Another option would
be to install Xfce and try it, but these thoughts were before I saw
Curt's message.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Tom Browder]

On Mon, Jan 27, 2020 at 10:11 AM Curt  wrote:
> On 2020-01-27, David Wright  wrote:
> > On Mon 27 Jan 2020 at 14:34:14 (-), Curt wrote:
> >> On 2020-01-27, Nate Bargmann  wrote:
...

A few points ref my problem:

1. I have to admit I've always been confused by the menuing inside
emacs to change things, so that would be a last resort. I prefer to
put stull in my init.el.

2. I have also been very confused over the multitude of configuration
files affecting the graphical displays.

3. Looking in detail at the results of my "xrdb -query" incantation I
only see three colors and they affect the following attributes:

a. color: f8f8f8 affects:

*Button.activeBackground:#f8f8f8
*Checkbutton.activeBackground:#f8f8f8
*Radiobutton.activeBackground:#f8f8f8
*Scrollbar.activeBackground:#f8f8f8

b. color: cecece affects:
=

*Box.background:#cecece
*Button.background:#cecece
*Button.highlightBackground:#cecece
*Canvas.activeBackground:#cecece
*Canvas.background:#cecece
*Canvas.highlightBackground:#cecece
*Canvas.selectbackground:#cecece
*Checkbutton.background:#cecece
*Checkbutton.highlightBackground:#cecece
*Command.background:#cecece
*Dialog.background:#cecece
*Entry.activeBackground:#cecece
*Entry.background:#cecece
*Entry.highlightBackground:#cecece
*Entry.selectBackground:#cecece
*Form.background:#cecece
*Frame.background:#cecece
*Label.background:#cecece
*Label.highlightBackground:#cecece
*Labelframe.background:#cecece
*List.background:#cecece
*Listbox.activeBackground:#cecece
*Listbox.background:#cecece
*Listbox.highlightBackground:#cecece
*Listbox.selectBackground:#cecece
*Menu.activeBackground:#cecece
*Menu.background:#cecece
*MenuButton.background:#cecece
*Menubutton.activeBackground:#cecece
*Menubutton.background:#cecece
*Menubutton.highlightBackground:#cecece
*Radiobutton.background:#cecece
*Radiobutton.highlightBackground:#cecece
*Scale.activeBackground:#cecece
*Scale.background:#cecece
*Scale.highlightBackground:#cecece
*Scrollbar*background:#cecece
*Scrollbar.background:#cecece
*Scrollbar.highlightBackground:#cecece
*ScrollbarBackground:#cecece
*SimpleMenu*background:#cecece
*Text.activeBackground:#cecece
*Text.background:#cecece
*Text.highlightBackground:#cecece
*Text.selectBackground:#cecece
*Toggle.background:#cecece
*Toplevel.activeBackground:#cecece
*Toplevel.background:#cecece
*Toplevel.highlightBackground:#cecece
*XmCascadeButton.background:#cecece
*XmCascadeButtonGadget.background:#cecece
*XmDialogShell.background:#cecece
*XmFileSelectionBox.background:#cecece
*XmForm.background:#cecece
*XmFrame.background:#cecece
*XmLabel.background:#cecece
*XmLabelGadget.background:#cecece
*XmList.background:#cecece
*XmMenuShell.background:#cecece
*XmMessageBox.background:#cecece
*XmPanedWindow.background:#cecece
*XmPushButton.background:#cecece
*XmPushButtonGadget.background:#cecece
*XmRowColumn.background:#cecece
*XmSash.background:#cecece
*XmScrollBar.background:#cecece
*XmScrolledWindow.background:#cecece
*XmSelectionBox.background:#cecece
*XmSeparator.background:#cecece
*XmSeparatorGadget.background:#cecece
*XmTearOffButton.background:#cecece
*XmTearOffButtonGadget.background:#cecece
*XmText.background:#cecece
*XmTextField.background:#cecece
*XmToggleButton.background:#cecece
*XmToggleButtonGadget.background:#cecece
*background:#cecece
Editres*Panner.Background:#cecece
Editres*Tree.Background:#cecece
Editres*Tree.Toggle.Background:#cecece
Emacs*Background:#cecece
Emacs*Dialog*background:#cecece
Emacs*XlwScrollBar.Background:#cecece
Emacs*backgroundToolBarColor:#cecece
Emacs*bottomToolBarShadowColor:#cecece
Emacs*menubar*background:#cecece
Emacs*popup*Background:#cecece
Emacs*topToolBarShadowColor:#cecece
Emacs.default.attributeBackground:#cecece
Emacs.scroll-bar.attributeBackground:#cecece
Emacs.tool-bar.attributeBackground:#cecece

c. color: 3c3c3c affects:
==

*Box.foreground:#3c3c3c
*Button.activeForeground:#3c3c3c
*Button.foreground:#3c3c3c
*Button.highlightColor:#3c3c3c
*Canvas.activeForeground:#3c3c3c
*Canvas.foreground:#3c3c3c
*Canvas.highlightColor:#3c3c3c
*Canvas.selectforeground:#3c3c3c
*Checkbutton.activeForeground:#3c3c3c
*Checkbutton.foreground:#3c3c3c
*Checkbutton.highlightColor:#3c3c3c
*Command.foreground:#3c3c3c
*Dialog.foreground:#3c3c3c
*Entry.activeForeground:#3c3c3c
*Entry.foreground:#3c3c3c
*Entry.highlightColor:#3c3c3c
*Entry.selectForeground:#3c3c3c
*Form.foreground:#3c3c3c
*Frame.foreground:#3c3c3c
*Label.foreground:#3c3c3c
*Label.highlightColor:#3

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Curt]

On 2020-01-27, David Wright  wrote:
> On Mon 27 Jan 2020 at 14:34:14 (-), Curt wrote:
>> On 2020-01-27, Nate Bargmann  wrote:
>> >
>> > At this point, I think you need to find any file on your system that has
>> > the Emacs X resources that xrdb showed and comment them out.
>> >
>> 
>> As perhaps an unhelpful and not necessarily related data point, there
>> exists a bug report concerning Xresources and Emacs 24.4, the insect
>> consisting of the former remaining unread or "unrespected" (which may
>> not be a word) in the Mate desktop environment when using the latter.
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770781
>> 
>> https://superuser.com/questions/1351751/xresources-not-loaded-under-mate-desktop
>> 
>> (Set the active attribute to false under
>> 'org.mate.SettingsDaemon.plugins.xrdb' with dconf-editor?)
>
> It's not clear to me whether "my Xresources" means the dotfile in
> $HOME, or something else. In the case of the former, the OP wrote
> that they had no ~/.Xresources, so not reading it wouldn't matter.

I missed that point, yet I'm still left to wonder whether the mate
settings daemon xrdb plugins referenced above (if it is indeed running
on the OP's machine as part of the Mate kitchen sink) might be
responsible for the rather copious Emacs 'xdrb -query' output he offered
up for inspection.

Looking at this

https://github.com/mate-desktop/mate-settings-daemon/blob/master/plugins/xrdb/data/Emacs.ad

there does appear to be similarities. Maybe I'm not understanding the
whole thing correctly.


> Cheers,
> David.
>
>


-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[David Wright]

On Mon 27 Jan 2020 at 14:34:14 (-), Curt wrote:
> On 2020-01-27, Nate Bargmann  wrote:
> >
> > At this point, I think you need to find any file on your system that has
> > the Emacs X resources that xrdb showed and comment them out.
> >
> 
> As perhaps an unhelpful and not necessarily related data point, there
> exists a bug report concerning Xresources and Emacs 24.4, the insect
> consisting of the former remaining unread or "unrespected" (which may
> not be a word) in the Mate desktop environment when using the latter.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770781
> 
> https://superuser.com/questions/1351751/xresources-not-loaded-under-mate-desktop
> 
> (Set the active attribute to false under
> 'org.mate.SettingsDaemon.plugins.xrdb' with dconf-editor?)

It's not clear to me whether "my Xresources" means the dotfile in
$HOME, or something else. In the case of the former, the OP wrote
that they had no ~/.Xresources, so not reading it wouldn't matter.

Cheers,
David.

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[David Wright]

On Mon 27 Jan 2020 at 08:23:00 (-0600), Tom Browder wrote:
> On Mon, Jan 27, 2020 at 07:49 Nate Bargmann  wrote:
> ...
> 
> > At this point, I think you need to find any file on your system that has
> > the Emacs X resources that xrdb showed and comment them out.

You showed us your Xresources, presumably before you clobbered them
all with   xrdb /dev/null.

You might be able to find out which resources are causing your problem
by deleting them in turn with a command like:

$ xrdb -query | grep -v 'Emacs\*font:' | xrdb -

cutting and pasting from your posted list, and/or setting/editing
individual resources with:

$ xrdb -merge - <<< 'Emacs*font: neep-alt-iso10646-1-18'

Or you might be more comfortable running:

$ xrdb -query > /tmp/xrdb

then editing /tmp/xrdb while running

$ xrdb /tmp/xrdb

repeatedly in another xterm to set what's in your edit buffer.

Cheers,
David.

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Curt]

On 2020-01-27, Nate Bargmann  wrote:
>
> At this point, I think you need to find any file on your system that has
> the Emacs X resources that xrdb showed and comment them out.
>

As perhaps an unhelpful and not necessarily related data point, there
exists a bug report concerning Xresources and Emacs 24.4, the insect
consisting of the former remaining unread or "unrespected" (which may
not be a word) in the Mate desktop environment when using the latter.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770781

https://superuser.com/questions/1351751/xresources-not-loaded-under-mate-desktop

(Set the active attribute to false under
'org.mate.SettingsDaemon.plugins.xrdb' with dconf-editor?)

-- 
"J'ai pour me guérir du jugement des autres toute la distance qui me sépare de
moi." Antonin Artaud

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Tom Browder]

On Mon, Jan 27, 2020 at 07:49 Nate Bargmann  wrote:
...

> At this point, I think you need to find any file on your system that has
> the Emacs X resources that xrdb showed and comment them out.

...

Good suggestion, Nate.

And thanks for your and the other folks' patience.

-Tom

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Nate Bargmann]

* On 2020 27 Jan 07:03 -0600, Tom Browder wrote:
> Would it help if I post my entire /etc/X11 directory and init.el on my
> github account?

At this point probably not.  If there was nothing referencing Emacs in
/etc/X11/app-defaults then wherever those resources are being set must
be in your home directory.  Someplace.

> BTW, I do not use the GUI menu to start emacs, CLI only. and I rarely use
> it in its terminal version.

My suggestion to run it in the terminal was a test to see if the
highlighting colors come up sane.

There are several places where X resources can be set.  Default on
Debian these days appear to be /etc/X11/Xresources and
/etc/X11/app-defaults.  In your home directory it can become a mess as X
will look at several hidden files probably not limited to .Xresources,
.Xdefaults, .xinitrc, .xsession, and .xsessionrc.  Any of these can
source other files!

At this point, I think you need to find any file on your system that has
the Emacs X resources that xrdb showed and comment them out.

Is it possible that you had the emacs-lucid package installed and did
not purge it when you removed it?  I'm just grasping at straws here.

https://www.gnu.org/software/emacs/manual/html_node/emacs/X-Resources.html

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Tom Browder]

On Mon, Jan 27, 2020 at 05:37 Tom Browder  wrote:

> On Mon, Jan 27, 2020 at 5:00 AM Nate Bargmann  wrote:
> > OP, Tom, you might try:
> >
> > grep -i "Emacs" /etc/X11/app-defaults/*
>

Would it help if I post my entire /etc/X11 directory and init.el on my
github account?

BTW, I do not use the GUI menu to start emacs, CLI only. and I rarely use
it in its terminal version.

-Tom

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Tom Browder]

On Mon, Jan 27, 2020 at 5:00 AM Nate Bargmann  wrote:
> OP, Tom, you might try:
>
> grep -i "Emacs" /etc/X11/app-defaults/*

Nothing on mine, either, Nate.
Thanks.

-Tom

Re: Emacs and loss of highlighting: problem semi-solved (Buster MATE)

[Nate Bargmann]

* On 2020 27 Jan 02:40 -0600, to...@tuxteam.de wrote:
> On Sun, Jan 26, 2020 at 08:04:29PM -0600, Tom Browder wrote:
> > Emacs*Background:#cecece
> > Emacs*Dialog*background:    #cecece
> > Emacs*Dialog*foreground:#3c3c3c
> > Emacs*Foreground:#3c3c3c
> > Emacs*XlwScrollBar.Background:#cecece
> > Emacs*XlwScrollBar.Foreground:#3c3c3c
> > Emacs*backgroundToolBarColor:#cecece
> > Emacs*bottomToolBarShadowColor:#cecece
> > Emacs*menubar*background:#cecece
> > Emacs*menubar*foreground:#3c3c3c
> > Emacs*popup*Background:#cecece
> > Emacs*popup*Foreground:#3c3c3c
> > Emacs*topToolBarShadowColor:#cecece
> > Emacs.default.attributeBackground:#cecece
> > Emacs.default.attributeForeground:#3c3c3c
> > Emacs.mode-line.attributeForeground:#3c3c3c
> > Emacs.scroll-bar.attributeBackground:#cecece
> > Emacs.scroll-bar.attributeForeground:#3c3c3c
> > Emacs.tool-bar.attributeBackground:#cecece
> > Emacs.tool-bar.attributeForeground:#3c3c3c
> 
> OK. These are, I'd say, the first ones to concentrate on.
> Something in your system is setting that "on purpose", and
> you don't seem to like the results (note the prevalence of
> two colours: lightgray and darkgray -- kinda like a end-1990s
> Mac).
> 
> Have you had a look in /etc/X11/Xresources?

There are also ~/.Xdefaults and possibly a system Xdefaults to be
considered, IIUC.  In the old days I used to have an ~/.app-defaults
directory which had copies of files from /etc/X11/app-defaults/ that I
customized and loaded from ~/.xinitrc (maybe, something else?).  It's
not a facility I use any more, just ~/.Xresources with customizations
for Xterm and URxvt.

OP, Tom, you might try:

grep -i "Emacs" /etc/X11/app-defaults/*

and see if anything comes up.  Nothing comes up on my system.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature