(unknown)

(unknown)

[¿ì¹®°ü]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6192 bytes --]

" <bug-gnu-emacs@gnu.org>
Subject: [ È« º¸ ] ¾î¸±Àû ¿ìÇ¥¼öÁý¿¡ Àá¸øÀÌ·ç´ø ±â¾ïÀÌ ÀÖ³ª¿ä? 
Content-Type: multipart/alternative;
	boundary="----=_MailParts1017627182201d720fdd393b9e8f055c8efc18d719"
MIME-Version: 1.0
Sender: bug-gnu-emacs-admin@gnu.org
Errors-To: bug-gnu-emacs-admin@gnu.org
X-BeenThere: bug-gnu-emacs@gnu.org
X-Mailman-Version: 2.0.8
Precedence: bulk
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe>
List-Id: Bug reports for GNU Emacs,
	the Swiss army knife of text editors <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/bug-gnu-emacs/>
Date: Mon, 1 Apr 2002 11:13:02 +0900

This is a multi-part message in MIME format.

------=_MailParts1017627182201d720fdd393b9e8f055c8efc18d719
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64
X-MIME-Autoconverted: from 8bit to base64 by woomoon.com id g312D2Q00817

DQoJCQkJCVdvb21vb24uY29tDQoJCQkJCQ0KCQkJCQl0ZHtmb250LWZhbWlseTogJ7G8uLIn
OyBmb250LXNpemU6IDlwdDsgY29sb3I6IGJsYWNrOyBmb250LXN0eWxlOiBub3JtYWx9DQoJ
CQkJCWJvZHl7Zm9udC1mYW1pbHk6ICexvLiyJzsgZm9udC1zaXplOiA5cHQ7IGNvbG9yOiBi
bGFjazsJZm9udC1zdHlsZTogbm9ybWFsfQ0KCQkJCQlkaXZ7Zm9udC1mYW1pbHk6ICexvLiy
JzsgZm9udC1zaXplOiA5cHQ7IGNvbG9yOiBibGFjazsgZm9udC1zdHlsZTogbm9ybWFsfQ0K
CQkJCQkNCgkJCQkJDQoJCQkJCQ0KCQkJCQkNCgkJCQkJCQ0KCQkJCQkNCgkJCQkJDQoJCQkJ
CQkgDQoJCQkJCQ0KCQkJCQkNCgkJCQkJCQ0KCQkJCQkJDQoJCQkJCQkNCgkJCQkJCQkNCgkJ
CQkJCQm41cD6IMfjtvTAuyC53sH2IL7KsO0guN7Az8C7ILq4s7u15biwIMGhv6EgtOvHz7+p
ILvnsPq15biztM+02S4NCgkJCQkJCQm6uyC43sDPwLogwM7FzbPdu/PAxyC43sDPwda80rim
ILnfw+nHz7+pILnfvNvHz7+0vcC0z7TZDQoJCQkJCQkJv/jEoSC+yrTCILjewM+3ziC4vsC7
ILvzx8+w1CDH37TZuOksIL/rvK3H2CDB1r3KvcO/wC4NCgkJCQkJCQm09cDMu/MguN7Az7z2
vcXAuyC/+MfPwfYgvsrAuyCw5r/sv6G0wiC89r3FsMW6zrimIMfPv6kgwda9w7jpILTZvcO0
wiC43sDPwMwgud+827XHwfYgvsq1tbfPIMfPsNq9wLTPtNkuDQoJCQkJCQ0KCQkJCQkJCQ0K
CQkJCQkJCbq7ILjewM/AuiC537zbwPy/6yC43sDPwNS0z7TZLrmuwMcgu+fH18C6IHdvb21v
b25Ad29vbW9vbi5jb23AuLfOILq4s7vB1r3KvcO/wC6wqLvnx9W0z7TZLg0KCQkJCQkJDQoJ
CQkJCQkNCgkJCQkJCQ0KCQkJCQkNCgkJCQkJDQoJCQkJCQ0KCQkJCQkNCgkJCQkJDQoJCQkJ
CQ0KCQkJCQkNCgkJCQkJDQoJCQkJCQ0KCQkJCQkNCgkJCQkJDQoJCQkJCQ0KCQkJCQ0K
------=_MailParts1017627182201d720fdd393b9e8f055c8efc18d719
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-base: 
Content-Transfer-Encoding: base64
X-MIME-Autoconverted: from 8bit to base64 by woomoon.com id g312D2Q00817

PEJBU0UgSFJFRj0iIj4NCg0KDQoJCQkJCTxodG1sPjx0aXRsZT5Xb29tb29uLmNvbTwvdGl0
bGU+DQoJCQkJCTxzdHlsZSB0eXBlPSd0ZXh0L2Nzcyc+DQoJCQkJCXRke2ZvbnQtZmFtaWx5
OiAnsby4sic7IGZvbnQtc2l6ZTogOXB0OyBjb2xvcjogYmxhY2s7IGZvbnQtc3R5bGU6IG5v
cm1hbH0NCgkJCQkJYm9keXtmb250LWZhbWlseTogJ7G8uLInOyBmb250LXNpemU6IDlwdDsg
Y29sb3I6IGJsYWNrOwlmb250LXN0eWxlOiBub3JtYWx9DQoJCQkJCWRpdntmb250LWZhbWls
eTogJ7G8uLInOyBmb250LXNpemU6IDlwdDsgY29sb3I6IGJsYWNrOyBmb250LXN0eWxlOiBu
b3JtYWx9DQoJCQkJCTwvc3R5bGU+DQoJCQkJCTxib2R5Pg0KCQkJCQk8dGFibGUgYm9yZGVy
PScwJyBjZWxscGFkZGluZz0nMCcgY2VsbHNwYWNpbmc9JzAnIHdpZHRoPSc4MDAnIGFsaWdu
PWNlbnRlcj4NCgkJCQkJPHRyPg0KCQkJCQkJPHRkIHdpZHRoPTEwMCU+PGltZyBzcmM9J2h0
dHA6Ly93d3cud29vbW9vbi5jb20vbWFpbGltZy9pbWcvMjAwMjAzMjZtYWlsLmdpZicgd2lk
dGg9JzgwMCcgaGVpZ2h0PSc5MDAnIGJvcmRlcj0nMCcgYWx0PScnIHVzZW1hcD0nI2xpbmsn
PjwvdGQ+DQoJCQkJCTwvdHI+DQoJCQkJCTx0cj4NCgkJCQkJCTx0ZCB3aWR0aD0xMDAlIGhl
aWdodD0xNT4gPC90ZD4NCgkJCQkJPC90cj4NCgkJCQkJPHRyPg0KCQkJCQkJPHRkIHdpZHRo
PTEwMCUgYWxpZ249Y2VudGVyPg0KCQkJCQkJPHRhYmxlIGJvcmRlcj0nMCcgY2VsbHBhZGRp
bmc9JzMnIGNlbGxzcGFjaW5nPScxJyB3aWR0aD0nMTAwJScgYmdjb2xvcj0nZGZkZmRmJyBh
bGlnbj1jZW50ZXI+DQoJCQkJCQk8dHI+DQoJCQkJCQkJPHRkIHdpZHRoPTEwMCUgYWxpZ249
J2NlbnRlcicgaGVpZ2h0PTQ1IGJnY29sb3I9J2ZmZmZmZicgc3R5bGU9J2xpbmUtaGVpZ2h0
OjE1MCU7Jz4NCgkJCQkJCQm41cD6IMfjtvTAuyC53sH2IL7KsO0guN7Az8C7ILq4s7u15biw
IMGhv6EgtOvHz7+pILvnsPq15biztM+02S48YnI+DQoJCQkJCQkJursguN7Az8C6IMDOxc2z
3bvzwMcguN7Az8HWvNK4piC538Ppx8+/qSC537zbx8+/tL3AtM+02Txicj4NCgkJCQkJCQm/
+MShIL7KtMIguN7Az7fOILi+wLsgu/PHz7DUIMfftNm46Swgv+u8rcfYIMHWvcq9w7/ALjxi
cj4NCgkJCQkJCQm09cDMu/MguN7Az7z2vcXAuyC/+MfPwfYgvsrAuyCw5r/sv6G0wiC89r3F
sMW6zrimIMfPv6kgwda9w7jpILTZvcO0wiC43sDPwMwgud+827XHwfYgvsq1tbfPIMfPsNq9
wLTPtNkuPGJyPjxicj4NCgkJCQkJPGEgaHJlZj0naHR0cDovL3d3dy53b29tb29uLmNvbS9l
dGMvcmVqZWN0X21haWwuaHRtbD90X25vPTA0JnRfbWFpbD1idWctZ251LWVtYWNzQGdudS5v
cmcNJz48aW1nIHNyYz0naHR0cDovL3d3dy53b29tb29uLmNvbS9tYWlsaW1nL2ltZy9tYWls
LXJlZnVzZS5naWYnIGJvcmRlcj0nMCcgYWx0PSe89r3FsMW6zic+PC9hPjxicj48YnI+DQoJ
CQkJCQkJPGltZyBzcmM9J2h0dHA6Ly93d3cud29vbW9vbi5jb20vZXRjL2NoZWNrX21haWwu
aHRtbD90X25vPTA0JnRfbWFpbD1idWctZ251LWVtYWNzQGdudS5vcmcNJyBib3JkZXI9MCB3
aWR0aD0xIGhlaWdodD0xPg0KCQkJCQkJCTxiPrq7ILjewM/AuiC537zbwPy/6yC43sDPwNS0
z7TZLjxicj65rsDHILvnx9fAuiA8YSBocmVmPW1haWx0bzp3b29tb29uQHdvb21vb24uY29t
Pndvb21vb25Ad29vbW9vbi5jb208L2E+wLi3ziC6uLO7wda9yr3Dv8AuPGJyPrCou+fH1bTP
tNkuPC9iPjwvdGQ+DQoJCQkJCQk8L3RyPg0KCQkJCQkJPC90YWJsZT4NCgkJCQkJCTwvdGQ+
DQoJCQkJCTwvdHI+DQoJCQkJCTwvdGFibGU+DQoJCQkJCTxtYXAgbmFtZT0nbGluayc+DQoJ
CQkJCTxhcmVhIGFsdD0nv+y5rrD8IMiowLi3zicgY29vcmRzPSc5NSw3LDMxNyw1NScgaHJl
Zj0naHR0cDovL3d3dy53b29tb29uLmNvbS8nIHRhcmdldD0nX2JsYW5rJz4NCgkJCQkJPGFy
ZWEgYWx0PSe/7LmusPwgyKjAuLfOJyBjb29yZHM9Jzk2LDU1NywyNTIsNTc3JyBocmVmPSdo
dHRwOi8vd3d3Lndvb21vb24uY29tLycgdGFyZ2V0PSdfYmxhbmsnPg0KCQkJCQk8YXJlYSBh
bHQ9J8fRsbm/7MelJyBjb29yZHM9Jzk3LDY4MywyMzYsODA4JyBocmVmPSdodHRwOi8vd3d3
Lndvb21vb24uY29tL2tvcmVhL2tvcmVhX3N0YW1wLmh0bWwnIHRhcmdldD0nX2JsYW5rJz4N
CgkJCQkJPGFyZWEgYWx0PSe/7MPrv+vHsCcgY29vcmRzPScyNDgsNjgyLDM4Nyw4MTInIGhy
ZWY9J2h0dHA6Ly93d3cud29vbW9vbi5jb20va29yZWEvc3RhbXB0b29sLmh0bWwnIHRhcmdl
dD0nX2JsYW5rJz4NCgkJCQkJPGFyZWEgYWx0PSe/3LG5v+zHpScgY29vcmRzPSc0MDMsNjgy
LDU0MSw4MDgnIGhyZWY9J2h0dHA6Ly93d3cud29vbW9vbi5jb20va29yZWEvZm9yX3N0YW1w
Lmh0bWwnIHRhcmdldD0nX2JsYW5rJz4NCgkJCQkJPGFyZWEgYWx0PSdLUEMgvtm5/CcgY29v
cmRzPSc1NTYsNjgzLDY5NSw4MDgnIGhyZWY9J2h0dHA6Ly93d3cud29vbW9vbi5jb20va29y
ZWEva3BjLmh0bWwnIHRhcmdldD0nX2JsYW5rJz4NCgkJCQkJPC9tYXA+DQoJCQkJCTwvYm9k
eT4NCgkJCQkJPC9odG1sPg0KCQkJCQ==
------=_MailParts1017627182201d720fdd393b9e8f055c8efc18d719--

(unknown)

[JMT]

[-- Attachment #1: Type: text/html, Size: 5613 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

(unknown)

[Waruna Singappuli]

Hi

Could you please tell me from where I could get the emacs
installation(binaries) for Solaris 5.8

Thanks
Waruna.

(unknown)

[Sebastian Tennant]

  Hi all,

	I'm running the bundled emacs that comes with OSX Jaguar (version 
21.1.1 no less) and am experiencing one or two problems saving my 
desktop in between sessions.  'desktop-enable' is non-nil, and I 
manually M-x desktop-saved everything first time around.  My 
.emacs.desktop file even lists the buffers correctly, (i.e. as 
text-mode), but try as I might they keep being restored in 
fundamental-mode.  Curiously the minor mode auto-fill is being 
preserved but not the major mode!  I've even put text-mode in 
desktop-buffer-modes-to-save and fundamental-mode in 
desktop-modes-not-to-save without success.

	Any help would be greatly appreciated.

Seb.

(unknown)

[@Traduire]

Bonjour, 

Nous souhaiterions vous faire connaître les services de Traduction du Bureau International @Traduire.com.

Le Bureau International @Traduire.com répond à tous vos besoins en traduction, en vous offrant des solutions globales d'édition numérique plurilingue : traduction dans toutes les langues, interprétation, PAO et reproduction de documents, sites web plurilingues, réalisation de projets globaux multimédia plurilingues sur CD-ROM, localisation de logiciels.

Pour pouvoir offrir le niveau de qualité exigé par les clients, le Bureau International @Traduire.com dispose d'un réseau de traducteurs hautement qualifiés qui lui permet de former des équipes de travail en fonction de la nature de chaque projet et de mener à bien des projets de grande envergure tout en offrant une qualité maximale.
 
N'hésitez pas à nous demander un devis gratuit.
Dans l'attente d'une possible collaboration, je vous prie d'agréer l'expression de mes sentiments distingués.

Bureau International @Traduire.com
Site : www.a-traduire.com

(unknown)

[@Traduire]

Bonjour, 

Nous souhaiterions vous faire connaître les services de Traduction du Bureau International @Traduire.com.

Le Bureau International @Traduire.com répond à tous vos besoins en traduction, en vous offrant des solutions globales d'édition numérique plurilingue : traduction dans toutes les langues, interprétation, PAO et reproduction de documents, sites web plurilingues, réalisation de projets globaux multimédia plurilingues sur CD-ROM, localisation de logiciels.

Pour pouvoir offrir le niveau de qualité exigé par les clients, le Bureau International @Traduire.com dispose d'un réseau de traducteurs hautement qualifiés qui lui permet de former des équipes de travail en fonction de la nature de chaque projet et de mener à bien des projets de grande envergure tout en offrant une qualité maximale.
 
N'hésitez pas à nous demander un devis gratuit.
Dans l'attente d'une possible collaboration, je vous prie d'agréer l'expression de mes sentiments distingués.

Bureau International @Traduire.com
Site : www.a-traduire.com

(unknown)

[Knowledg1]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

Уважаемые коллеги!

Приглашаем Вас и Вашу фирму к участию в международном симпозиуме
по Knowledge Technology & Management. На нем для руководителей и
специалистов ведущих предприятий России будет представлен опыт
применения технологий управления корпоративными знаниями, а также
будет рассмотрена роль этих и близких к ним информационных технологий
в повышении эффективности производства и инвестиционной
привлекательности предприятий, организаций и регионов. Более подробная
информация приведена на сайте http://proteus-spb.ru/tmp/russoft.html .

Краткая же информация о международном симпозиуме по Knowledge
Technology & Management (состоится в Санкт - Петербурге
с 25 по 27 июня 2003г.) прилагается.

Оргкомитет
По проведению международного симпозиума по Knowledge Technology – технологиям знаний
(Комитет по информатизации и телекоммуникациям Ленинградской области, 
«BITKOM»,  Центр «Протей»,  «Rus-Soft»,   «Fort-Ross»).  

[-- Attachment #2: Ðóêîâîäèòåëÿì îðãàíèçàöèé_êðàòêî.doc --]
[-- Type: application/msword, Size: 30720 bytes --]

[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

(unknown)

[Knowledg1]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

Уважаемые коллеги!

Приглашаем Вас и Вашу фирму к участию в международном симпозиуме
по Knowledge Technology & Management. На нем для руководителей и
специалистов ведущих предприятий России будет представлен опыт
применения технологий управления корпоративными знаниями, а также
будет рассмотрена роль этих и близких к ним информационных технологий
в повышении эффективности производства и инвестиционной
привлекательности предприятий, организаций и регионов. Более подробная
информация приведена на сайте http://proteus-spb.ru/tmp/russoft.html .

Краткая же информация о международном симпозиуме по Knowledge
Technology & Management (состоится в Санкт - Петербурге
с 25 по 27 июня 2003г.) прилагается.

Оргкомитет
По проведению международного симпозиума по Knowledge Technology – технологиям знаний
(Комитет по информатизации и телекоммуникациям Ленинградской области, 
«BITKOM»,  Центр «Протей»,  «Rus-Soft»,   «Fort-Ross»).  

[-- Attachment #2: Ðóêîâîäèòåëÿì îðãàíèçàöèé_êðàòêî.doc --]
[-- Type: application/msword, Size: 30720 bytes --]

[-- Attachment #3: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnu-emacs

(unknown)

[mayuko_v_v_sutekimax]

私、今まで出会い系で何人か男の人に会ってきました。
でも、それだと男の人がお金かかって大変みたいだし…
だから私がいろんな人にチャンスをあげたくて本物の出会い系始める事にしたんです!!
12月から募集始めたんだけど女の子ばかりで男の人があまり居ないから是非見て欲しいんです。
みんな体の関係を望んでるから当然会う事もできるし。
それで登録して会えなかったら保障として私が会いに行きます。
名前はまゆこです。play-M-999005@sweet-chat.netにメールしてくれてもかまいません。
もし会えなかったらメルアド載せてあるから連絡ください。
↓が私の運営してるサイトです。
http://www.sweet-chat.net/index.php/999005
一度使ってみてくださいね。今なら2000円分無料で使えるようになってます。感想聞かせてくれたら嬉しいです！

(unknown)

[Jost Burkardt]

Hi,

I really love the integration of remember with org, especially the way
how to insert the notes by moving within the headings-tree. 

Is it possible to use this feature also for moving portions of text
via regular copy/paste an org-buffer, and have org automatically adapt
the header levels? I didn't find anything in the manual.

One possible workaround for me is to use remember-clipboard, which has
the drawback, that the clipboard's content is indented, so I always
have to remove the indentation by hand.

What do you think?
Jost

(unknown)

[tester12312]

I am using a fresh vanilla build of emacs from the bzr repository.
Somehow I cannot get display-buffer-function to work.  Whenever I fall
back to display-buffer inside my display-buffer-function, windowing gets
funky.

How to reproduce:

emacs -q
(setq display-buffer-function
      (lambda (a b)
    (let ((display-buffer-function nil))
      (display-buffer a b))))
open a file

why is a new window created?

(unknown)

[Eli Zaretskii]

Dmitry, could you please explain the reason(s) for the change below?

Vertical positions in a window can never be large enough to justify
using ptrdiff_t (on platforms where that is wider than a 32-bit
'int').  These are pixel positions on the Emacs display, so they
cannot be too large.  The type of 'first_vpos' looks especially
strange, since it is explicitly set to 1 at most.  I'm not aware of a
platform where an 'int' is not wide enough for a value 1 ;-)

Using inappropriate data types makes the code harder to read and
understand, because it hints that something non-obvious is going on
somewhere.

	 * xdisp.c (try_window_id): Change type of 'first_vpos' and 'vpos'
	 to ptrdiff_t.

  --- src/xdisp.c 2012-06-28 12:29:37 +0000
  +++ src/xdisp.c 2012-06-29 11:48:08 +0000
  @@ -17761,8 +17761,8 @@ try_window_id (struct window *w)
       {
	 /* Displayed to end of window, but no line containing text was
	   displayed.  Lines were deleted at the end of the window.  */
  -      int first_vpos = WINDOW_WANTS_HEADER_LINE_P (w) ? 1 : 0;
  -      int vpos = XFASTINT (w->window_end_vpos);
  +      ptrdiff_t first_vpos = WINDOW_WANTS_HEADER_LINE_P (w) ? 1 : 0;
  +      ptrdiff_t vpos = XFASTINT (w->window_end_vpos);
	 struct glyph_row *current_row = current_matrix->rows + vpos;
	 struct glyph_row *desired_row = desired_matrix->rows + vpos;

(unknown)

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

Hi,

I'm a gnus newbie and using it for about two weeks in just one of my IMAP
mail accounts. I like it so far, but wonder at its marking system...

To the question: Does it make sense to not use gnus-ancient-mark "O"
completely? I want to see old marks that I laboriously set in previous
sessions, such as the gnus-del-mark "r" mark. It seems to be replaced by
"O" all the time.

If so how would I achieve this?

-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 621 bytes --]

Re: (unknown)

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> To the question: Does it make sense to not use gnus-ancient-mark "O"
> completely? I want to see old marks that I laboriously set in previous
> sessions, such as the gnus-del-mark "r" mark. It seems to be replaced
> by "O" all the time. 

"r" just marks stuff as read, and this isn't saved beyond that.  Any way
of marking stuff as read ends up in the same data set, so it's all
displayed as "O".

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: (unknown)

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

I see, so the difference between "r" and "R" is just for the current
"summary mode" session.

Curious, when does adaptive scoring kick in then? It does differentiate
between "r" and "R" doesn't it?

Thanks (and sorry for not including a subject, I stupidly forgot)
João

On Sat, Jul 6, 2013 at 4:22 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > To the question: Does it make sense to not use gnus-ancient-mark "O"
> > completely? I want to see old marks that I laboriously set in previous
> > sessions, such as the gnus-del-mark "r" mark. It seems to be replaced
> > by "O" all the time.
>
> "r" just marks stuff as read, and this isn't saved beyond that.  Any way
> of marking stuff as read ends up in the same data set, so it's all
> displayed as "O".
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog http://lars.ingebrigtsen.no/
>



-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 1610 bytes --]

Re: (unknown)

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> I see, so the difference between "r" and "R" is just for the current
> "summary mode" session.

Yes.

> Curious, when does adaptive scoring kick in then? It does
> differentiate between "r" and "R" doesn't it?

Adaptive scoring kicks in as you're leaving the summary buffer, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

(unknown)

[Eli Zaretskii]

Bootstrapping master from the git repo, I see multiple error messages
like this:

  Eager macro-expansion failure: (error "Lisp nesting exceeds `max-lisp-eval-depth'")

Does anyone else see this?

Re: (unknown)

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Bootstrapping master from the git repo, I see multiple error messages
> like this:
>
>   Eager macro-expansion failure: (error "Lisp nesting exceeds
> `max-lisp-eval-depth'")
>
> Does anyone else see this?

Yes, I get the same thing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

(unknown)

[David Kastrup]

Unless objected to timely, I intend to push this change tomorrow.  It
should not affect current operation but brings Emacs' behavior for
synthesized Lisp events containing an "up-" modifier in line with the
current behavior of "down-" events.  Such events are not produced by
Emacs itself; no change in behavior for existing code is expected.

I have code that might eventually make it into ELPA that benefits from
these changes.

Re: (unknown)

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Unless objected to timely, I intend to push this change tomorrow.  It
> should not affect current operation but brings Emacs' behavior for
> synthesized Lisp events containing an "up-" modifier in line with the
> current behavior of "down-" events.  Such events are not produced by
> Emacs itself; no change in behavior for existing code is expected.
>
> I have code that might eventually make it into ELPA that benefits from
> these changes.

Ugh.  Sorry for the Subject line.  This concerns the patch in the
message with title:

[PATCH] Deal gracefully with up-events (Bug#19746)

-- 
David Kastrup

(unknown)

[steve]

From: Steve Purcell <steve@sanityinc.com>
Date: Mon, 8 Feb 2016 20:47:43 +1300
Subject: [PATCH] Safer prompt-regexp for postgres/vertica in
 sql-interactive-mode
--text follows this line--

Fixes issue 22596, whereby "_" is now not considered a word constituent
character in sql-interactive-mode, so prompts like "foo_dev# " are not
correctly detected.
---
 lisp/progmodes/sql.el | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/progmodes/sql.el b/lisp/progmodes/sql.el
index fd59f46..90c8dfe 100644
--- a/lisp/progmodes/sql.el
+++ b/lisp/progmodes/sql.el
@@ -462,9 +462,9 @@ sql-product-alist
      :list-all ("\\d+" . "\\dS+")
      :list-table ("\\d+ %s" . "\\dS+ %s")
      :completion-object sql-postgres-completion-object
-     :prompt-regexp "^\\w*=[#>] "
+     :prompt-regexp "^[[:alpha:]_]*=[#>] "
      :prompt-length 5
-     :prompt-cont-regexp "^\\w*[-(][#>] "
+     :prompt-cont-regexp "^[[:alpha:]_]*[-(][#>] "
      :input-filter sql-remove-tabs-filter
      :terminator ("\\(^\\s-*\\\\g$\\|;\\)" . "\\g"))
 
@@ -514,9 +514,9 @@ sql-product-alist
      :sqli-comint-func sql-comint-vertica
      :list-all ("\\d" . "\\dS")
      :list-table "\\d %s"
-     :prompt-regexp "^\\w*=[#>] "
+     :prompt-regexp "^[[:alpha:]_]*=[#>] "
      :prompt-length 5
-     :prompt-cont-regexp "^\\w*[-(][#>] ")
+     :prompt-cont-regexp "^[[:alpha:]_]*[-(][#>] ")
     )
   "An alist of product specific configuration settings.
 
-- 
2.7.1

Re: (unknown)

[Steve Purcell]

Sorry, messed up sending that patch by email, but it's hopefully helpful
nonetheless.

-Steve

(unknown)

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

Hi!

About a year ago, the long time maintainer of the official Emacs user
interface on OS X (the "nextstep" or "NS" user interface), retired from
Emacs. This is very unfortunately, as he did a very, very good job for
during the years he was active.

When I found out about this, about six months ago, I stepped up as I had
some knowledge after having worked along side of him on some NS-related
features.

Unfortunately, my personal situation has since changed so I no longer can
handle the NS user interface by myself.

In other words, I'm looking for someone or a group of people who are
interested in enhancing Emacs on OS X, or at least making sure that it
doesn't stop working.

To make it easier to start working on the NS port, I've updated the README
and add a WISHLIST of features that I would like to see implemented.

I will still be around, but I find that time no longer permits me doing
much core development work.

Sincerely,
    Anders Lindgren

[-- Attachment #2: Type: text/html, Size: 1211 bytes --]

(unknown)

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

Hi developers.

I translated GNU Emacs manual "The Emacs Edirot" from English to Japanese.

  Emacs-24.5: https://ayatakesi.github.io/#emacs-24.5-emacs
  Emacs-25.1: https://ayatakesi.github.io/#emacs-25.1-emacs

So, how should I take next action.
Submit it to somewhere, or else?
(Currently I am sharing it by GitHub.)

Any ideas?

Thanks.

---
Ayanokoji Takesi <ayanokoji.takesi@gmail.com>

[-- Attachment #2: Type: text/html, Size: 1450 bytes --]

Re: (unknown)

[Byung-Hee HWANG (황병희, 黃炳熙)]

Takesi Ayanokoji <ayanokoji.takesi@gmail.com> 께서 쓰시길,
 《記事 全文
 <CAN7WbibOXQGSCYbzErB9e9X3YinM3OmBinApAM15hecx4O7-PA@mail.gmail.com>
 에서》:

> Hi developers.
>
> I translated GNU Emacs manual "The Emacs Edirot" from English to Japanese.
>
>   Emacs-24.5: https://ayatakesi.github.io/#emacs-24.5-emacs
>   Emacs-25.1: https://ayatakesi.github.io/#emacs-25.1-emacs
>
> So, how should I take next action.
> Submit it to somewhere, or else?
> (Currently I am sharing it by GitHub.)
>
> Any ideas?
>
> Thanks.

Takesi-san, it is very hard work, i think. You are strong man. Anyway
thanks thanks thanks!!!

Sincerely,

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

(unknown)

[Chris Gregory]

Here is another patch that does more of this.
-- 
Chris Gregory

diff --git a/src/eval.c b/src/eval.c
index e50e26a..9e1d612 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1313,20 +1313,12 @@ internal_condition_case (Lisp_Object (*bfun) (void), Lisp_Object handlers,
 			 Lisp_Object (*hfun) (Lisp_Object))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val);
-    }
-  else
-    {
-      Lisp_Object val = bfun ();
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun ();
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val) : val;
 }
 
 /* Like internal_condition_case but call BFUN with ARG as its argument.  */
@@ -1364,20 +1356,12 @@ internal_condition_case_2 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
 			   Lisp_Object (*hfun) (Lisp_Object))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val);
-    }
-  else
-    {
-      Lisp_Object val = bfun (arg1, arg2);
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun (arg1, arg2);
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val) : val;
 }
 
 /* Like internal_condition_case but call BFUN with NARGS as first,
@@ -1393,20 +1377,12 @@ internal_condition_case_n (Lisp_Object (*bfun) (ptrdiff_t, Lisp_Object *),
 						Lisp_Object *args))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val, nargs, args);
-    }
-  else
-    {
-      Lisp_Object val = bfun (nargs, args);
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun (nargs, args);
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val, nargs, args) : val;
 }
 
 struct handler *

Re: (unknown)

[Andreas Schwab]

On Dez 28 2016, Chris Gregory <czipperz@gmail.com> wrote:

> Here is another patch that does more of this.

Nothing of that is valid C.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

(unknown)

[Paul Pogonyshev]

>>> Have you tried to measure the impact of your patch on the actual problem?
>> I mentioned 3%.
>
>That's the percentage impact on the number of lambdas.  I'm curious
>about its impact on actual problematic aspects, such as speed and code
>size (and compilation time, I guess).
>
>> Yes, it is practically negligible, but this is a first small patch and
>> I'm willing to work on improving generators further.
>
>Of course.

Actually, forget it. It's too complicated to jump through all the hoops here.

I would just be glad if someone applied the patch from bug 26068. It's a
fix, not an optimization, and there is example of a form, evaluation of
which it fixes.

And if you reply, *please*, keep me on CC, otherwise I won't see your
mail.

Paul

Re: (unknown)

[Mark Oteiza]

Paul Pogonyshev <pogonyshev@gmail.com> writes:

>>>> Have you tried to measure the impact of your patch on the actual problem?
>>> I mentioned 3%.
>>
>>That's the percentage impact on the number of lambdas.  I'm curious
>>about its impact on actual problematic aspects, such as speed and code
>>size (and compilation time, I guess).
>>
>>> Yes, it is practically negligible, but this is a first small patch and
>>> I'm willing to work on improving generators further.
>>
>>Of course.
>
> Actually, forget it. It's too complicated to jump through all the hoops here.

Darn.  Such improvements would be nice.

> I would just be glad if someone applied the patch from bug 26068. It's a
> fix, not an optimization, and there is example of a form, evaluation of
> which it fixes.

Applied, thanks.  AFAICT it didn't break any tests and didn't exacerbate
bug#12119 which the previous code was fixing.

Re: (unknown)

[Paul Pogonyshev]

>> I would just be glad if someone applied the patch from bug 26068. It's a
>> fix, not an optimization, and there is example of a form, evaluation of
>> which it fixes.
>
> Applied, thanks.  AFAICT it didn't break any tests and didn't exacerbate
> bug#12119 which the previous code was fixing.

Thank you. If you are familiar with the code involved, can you please also
look at bug 26073? It's related, but more difficult to fix. I added a patch to
the bug report, but I don't think the patch is ready for application. Maybe
someone could finish it.

Paul

(unknown)

[Eli Zaretskii]

> From: "B. T. Raven" <btraven@nihilo.net>
> Date: Thu, 13 Apr 2017 00:09:51 -0500
> 
> I also have these lines in my .emacs:
> 
>    (set-locale-environment   "utf-8")
>          (set-language-environment               'utf-8)
>          (set-default-coding-systems             'utf-8)
>          (setq file-name-coding-system           'utf-8)
>          (setq buffer-file-coding-system 'utf-8)
>          (setq coding-system-for-write           'utf-8)
>          (set-keyboard-coding-system             'utf-8)
>          (set-terminal-coding-system          'utf-8)
>          (prefer-coding-system                   'utf-8)
>          ;; (set-buffer-process-coding-system 'utf-8 'utf-8)
>          (modify-coding-system-alist 'process 
> "[cC][mM][dD][pP][rR][oO][xX][yY]" 'utf-8-dos)
> 
> 
> The line commented out caused a problem but I don't remember what it 
> was. My os w64 vers. 7

Some of the above are not recommended, and some are downright
dangerous (a.k.a. "shooting yourself in the foot").  Especially on
MS-Windows, UTF-8 should be used with extra care, because Windows only
partially supports this encoding in its APIs.

Specifically:

>    (set-locale-environment   "utf-8")

Don't do this on Windows, as Windows locales cannot use UTF-8 as their
encoding.

>          (set-language-environment               'utf-8)
>          (set-default-coding-systems             'utf-8)

Redundant as long as you have the prefer-coding-system call below.

>          (setq file-name-coding-system           'utf-8)

This is a no-op: Emacs on Windows ignores the value of this variable,
except if you are on Windows 9X, and file names cannot be encoded in
UTF-8 on Windows anyway.  Starting with Emacs 24.4, Emacs on Windows
uses Unicode APIs to deal with file names, so it supports non-ASCII
file names with all Unicode characters, and you don't need to do
anything to get this support.

>          (setq buffer-file-coding-system 'utf-8)

Dangerous.  Also redundant with prefer-coding-system below.

>          (setq coding-system-for-write           'utf-8)

This is dangerous: it will produce subtle issues with some commands,
notably when invoking subprocesses with non-ASCII strings in
command-line arguments.  This variable exists so that Lisp programs
could force specific encoding where appropriate, so leave it to that
and don't globally set it.

>          (set-keyboard-coding-system             'utf-8)
>          (set-terminal-coding-system          'utf-8)

These are wrong, and will get in the way when you work in -nw
sessions.  Emacs on MS-Windows doesn't fully support UTF-8 encoding of
keyboard input and console output, even if you tweak your system's
codepage to be 65001 (did you?).

>          (prefer-coding-system                   'utf-8)

This is the only setting that you should have if you want to use UTF-8
wherever possible and reasonable.

>          ;; (set-buffer-process-coding-system 'utf-8 'utf-8)
>          (modify-coding-system-alist 'process 
> "[cC][mM][dD][pP][rR][oO][xX][yY]" 'utf-8-dos)

This is wrong: Emacs on MS-Windows doesn't support UTF-8 encoding of
program command-line arguments for subprocesses, and most Windows
programs will NOT talk UTF-8 in their standard streams.
prefer-coding-system should take care of those situations where this
is possible/actually happens; the rest should be left alone, or you
will have subtle problems with non-ASCII I/O vis-a-vis subprocesses.

HTH

(unknown)

[Mark Oteiza]

Hi,

I wrote the following to get rid of the 'apply' here.  The
expansion is something that, according to how byte-switch is described,
should compile to a switch/jumptable, but it isn't happening.

Applying the following, doing M-x byte-compile-file, and inspecting the
.elc/disassembly I am seeing a series of goto-if-nil.  Am I doing
something wrong?

diff --git a/lisp/json.el b/lisp/json.el
index 64486258cc..6990ddd0f5 100644
--- a/lisp/json.el
+++ b/lisp/json.el
@@ -683,6 +683,23 @@ json-readtable
     table)
   "Readtable for JSON reader.")
 
+(defmacro json-readtable-dispatch (char)
+  "Dispatch reader function for CHAR."
+  (declare (debug (symbolp)))
+  (let ((table
+         '((?t json-read-keyword "true")
+           (?f json-read-keyword "false")
+           (?n json-read-keyword "null")
+           (?{ json-read-object)
+           (?\[ json-read-array)
+           (?\" json-read-string)))
+        res)
+    (dolist (c '(?- ?+ ?. ?0 ?1 ?2 ?3 ?4 ?5 ?6 ?7 ?8 ?9))
+      (push (list c 'json-read-number) table))
+    (pcase-dolist (`(,c . ,rest) table)
+      (push `((= ,char ,c) (,@rest)) res))
+    `(cond ,@res (t (signal 'json-readtable-error ,char)))))
+
 (defun json-read ()
   "Parse and return the JSON object following point.
 Advances point just past JSON object."
@@ -690,10 +707,7 @@ json-read
   (let ((char (json-peek)))
     (if (zerop char)
         (signal 'json-end-of-file nil)
-      (let ((record (cdr (assq char json-readtable))))
-        (if (functionp (car record))
-            (apply (car record) (cdr record))
-          (signal 'json-readtable-error record))))))
+      (json-readtable-dispatch char))))
 
 ;; Syntactic sugar for the reader
 

(unknown)

[siraben]

I'm new to contributing, so I was wondering if this is a viable
project to get started on.

I've noticed that development on the Emacs Calc has stalled
recently. /lisp/calc shows no commits since January 1 2018, which was
a copyright year update. I would like to contribute documentation to
many of the undocumented functions, and work on the symbolic
integration algorithm which, despite its complexity, still has great
difficulty with integration by parts and by substitution.

What are some recommended starting points for first-time contributors?

Thanks,

Ben Phipathananunth

(unknown)

[Budi]

how to assign shortcut key i.e. bind a key to do M-x ielm <ret>
sequence in emacs

tried;

(defun d () (interactive)(command-execute (execute-extended-command "ielm")))
(global-set-key (kbd "<f1>") 'd)

to no avail...
Please help me!

Re: (unknown)

[Óscar Fuentes]

Budi <budikusasi@gmail.com> writes:

> how to assign shortcut key i.e. bind a key to do M-x ielm <ret>
> sequence in emacs
>
> tried;
>
> (defun d () (interactive)(command-execute (execute-extended-command "ielm")))
> (global-set-key (kbd "<f1>") 'd)
>
> to no avail...
> Please help me!

Try

(global-set-key (kbd "<f1>") 'ielm)

In the future, please use an appropriate Subject field on your
enquiries. Thanks.

(unknown)

[Justin Barclay]

Hi there,

I'm hoping to publish my first Emacs package to Melpa, but before I do I
was hoping someone with more elisp experience then I would be willing to
give me some feedback on my package. Before I started this project, I
wasn't very familiar with Emacs package creation. So, I'm curious to find
out what I've done plainly wrong or what improvements I could make to this
package.

My package can be found at
https://github.com/justinbarclay/parinfer-rust-mode.

Sincerely,

Justin

(unknown)

[Arne Babenhauserheide]

Subject: [PATCH] ox-html: escape & in license magnets
In-Reply-To: <87d09dz92a.fsf@yandex.com>
Date: Sun, 15 Mar 2020 23:36:37 +0100
References: <87eett7bql.fsf@yandex.com> <871rpt9zc4.fsf@kyleam.com> <87d09dz92a.fsf@yandex.com>
References: <87d09dz92a.fsf@yandex.com>
User-agent: mu4e 1.2.0; emacs 26.3
* lisp/ox-html (org-html-scripts): & escaped as &amp;
* lisp/ox-html (org-html-infojs-template): & escaped as &amp;

This fixes xhtml validation while still being recognized by LibreJS as
valid license.
---
 lisp/ox-html.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 9a1dd44b5..5c2b766e9 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -232,7 +232,7 @@ property on the headline itself.")

 (defconst org-html-scripts
   "<script type=\"text/javascript\">
-// @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&dn=gpl-3.0.txt GPL-v3-or-Later
+// @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&amp;dn=gpl-3.0.txt GPL-v3-or-Later
 <!--/*--><![CDATA[/*><!--*/
      function CodeHighlightOn(elem, id)
      {
@@ -510,12 +510,12 @@ means to use the maximum value consistent with other options."

 (defcustom org-html-infojs-template
   "<script type=\"text/javascript\" src=\"%SCRIPT_PATH\">
-// @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&dn=gpl-3.0.txt GPL-v3-or-Later
+// @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&amp;dn=gpl-3.0.txt GPL-v3-or-Later
 // @license-end
 </script>

 <script type=\"text/javascript\">
-// @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&dn=gpl-3.0.txt GPL-v3-or-Later
+// @license magnet:?xt=urn:btih:1f739d935676111cfff4b4693e3816e664797050&amp;dn=gpl-3.0.txt GPL-v3-or-Later
 <!--/*--><![CDATA[/*><!--*/
 %MANAGER_OPTIONS
 org_html_manager.setup();  // activate after the parameters are set
--
2.25.1

(unknown)

[Ag Ibragimov]

Spacemacs (community-driven Emacs distribution/config) has a feature called Layers, Doom-Emacs (another community-driven Emacs config) has a similar feature (I think they are called Modules).

A Layer is a bundle of [related] Emacs packages that work together and very often tightly integrate (with one another) to provide a comprehensive set of features to achieve specific goals. For example, there are many language-specific Spacemacs layers: Python, Lua, Haskell, etc.
For example, the Python layer includes basic Python-related packages and sets defaults for Flycheck, Company, etc.
There also layers for tools like Docker or layers for version-control, et al.

So my question is: Has anyone ever thought about designing a sort of standardized module system? It would be great if we could have a unified model for creating such bundles.
Wouldn't be nice if for example, instead of discovering, installing and configuring a bunch of related packages, an Emacs user would say: "install LaTeX module" and then "customize "LaTeX module", etc.

Emacs ecosystem is growing. There are hundreds (maybe more) packages; standardizing a system that would allow the "plug-n-play" experience would be very nice. Otherwise, everyone would continue solving same problems in their own, unique ways, increasing entropy towards the "Lisp curse."

Re: (unknown)

[Eric Skoglund]

Krupal <krupalinbox@gmail.com> writes:

I'd be happy to help as well.

In particular I have some experience of making responsive (and
accessible) websites from when it used to be part of my job.

// Eric

Re: (unknown)

[Bastien]

Hi Eric,

Eric Skoglund <eric@pagefault.se> writes:

> I'd be happy to help as well.

Thanks!

> In particular I have some experience of making responsive (and
> accessible) websites from when it used to be part of my job.

That is indeed something we badly need.

Please send me an email offlist with the username you want for
code.orgmode.org and I'll give you commit access to Worg.

Best,

-- 
 Bastien

(unknown)

[Sai Karthik]

Hello, is there any way to list all recipients of a gpg file using epa? couldn't find anything useful from the manual (https://www.gnu.org/software/emacs/manual/html_mono/epa.html)

(unknown)

[Troy Hinckley]

Subject: Load order for elisp files
User-agent: mu4e 1.2.0; emacs 28.0.50

I am trying to better understand the bootstrap process for Emacs and I
have run into a chicken and egg problem. When looking for where the
basic functions are defined, I can see that defmacro and defun are defined in
byte-run.el. However the code needed to evaluate a macro is in
backquote.el. But backquote.el uses defun, which is defined in
byte-run.el. Which of these files is loaded first, and how does Emacs
work around this apparent causality dilemma?

(unknown)

[telegraph]

From telegraph@gmx.net  Mon Aug 23 20:35:54 2021
From: Gregor Zattler <telegraph@gmx.net>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: xterm [menu] key definition
In-Reply-To: <20210819024728.kgnf6jmpakqdto4p@Ergus>
References: <20210819024728.kgnf6jmpakqdto4p.ref@Ergus>
 <20210819024728.kgnf6jmpakqdto4p@Ergus>
Mail-Followup-To: emacs-devel <emacs-devel@gnu.org>
Date: Mon, 23 Aug 2021 20:35:51 +0200
Message-ID: <87k0kcovp4.fsf@no.workgroup>
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:sxHfD7zdrmCrHJSZln2GfPWmdbMMIDsRDQsLpU/nfq2YcMnLSwp
 hYDoOFW4h00C5RkEQiWqTD0Ghszr1rlMksOFjeCzf6UdQ6KCjGfM9H/0FNpGLz//8NEoqgM
 S5utAAvPbhusMs8u3C+lcawvEbL65zJofM+Ydv0o9vvHaRqEnoH26xvM2TKzTcYI3D+cvMJ
 tbufjgNLdJD0dp/gT0Usg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:0O6w3nRKzCM=:0yGavBBfSnyh5UA4ZyLNTu
 xZveGSXWYdvpP90089lYIVteVaqX2TjAGj5I0C+mVPtjbh++j7XzPszGW59UNb8XhbXv/RRAU
 PaKuQZQs2zeJi6m/mnUR28wuFqa9EJFXsUMLywX7A9pcq+nj88RJDkFOyOUucK8ZRDJczVJtq
 hCRthc8vZLS9I7t/BScUxTX0Gkr572eqLRSK7ZAnzyi28WyMc4Q67ujkJYogQakM7BESX2mqb
 n+cqLaM/SkXB4ftaF7C8YmAY7GFK64ACinZ71HIBSIVZhIDaFwmTiO3KSz0zuGFf9pYBndhTr
 iuv3dGLvRCBxYAxZ/8PDf2xts3TXZK6WpjTyQVjthqj5y9OwIYt2kZrgnV0PrbFfAm1H6RPcT
 xQqoU1Xhi3xaLOnNKx5DQp+M3P5/x1uu24XDKzXlVaAmN3r8tMcfbLFbE8Rk5+ikVt5xVHvXM
 pZHJA5ggu0HowH10nfZZ4b9dmeCitsqF9dVOA/sv9WsRdQ+M33ZsdYpk5UTaurTjfVU6JWaOG
 gScUUAQx9O2Iltx9m/jOlfw9aOZQ4cv9uNRiJc0ujo0Iv3T2oqkKoBjTVj5WUY2mqfPkKIhLe
 PqiVdMC2viIT1LzxgCRzghRqizF0E6OGu1twlQNqBMxo8J1MbU5OYo/uJ/QoF4DMY7Z7TgVyc
 4X3WbN7qsken+icUxr5UljsAhpg3Y9VdcF1aLJuFObC5ceIlMAylmUt0MzVfdhDGf4fy7lMWD
 3WVTDeehE5N+vf+gtoktTNzUUVujv6vDihkwb8M8cWBC0iDlLFf7a74EyzY+B4Hgc3Lc4HXGz
 C1HnGSPrG5xCYjzjGRaEulxTMjIBoCaBjj7UamceG6e+8preYjhjJlboGUEc2jWUAhUlK1E/I
 U92uRwgIm+mLukfNLQO/jzObm/a6Xd8xI8DXV3NGzqLWBNR5zZrhXErR2CM9bYihuPyN6Mw+t
 +v9efj6W3mrNpQEjsquqT7OrC3PVSRX8ZER0SkyOmvje3HyALBssD5NBvtOl1YBiYAFN2IbdH
 f2lclpuTkYQ73x9fe5OxwVoz71ASxro8z+oG1pRYVnwfWLwbNw+UK2n9qWxEblnARL9lfLqAr
 LRIc8W9CUi1Q6qGkLmdnpUYMF9eR2jPfzzqbhwIyj7rdZtkfYFCveiAPQ==
Content-Transfer-Encoding: quoted-printable

Hi Ergus,
* Ergus <spacibba@aol.com> [2021-08-19; 04:47]:
> I don't actually know about any keyboard with a print
> button...

wouldn't that be the PrtSc key which is on every standard PC
keyboard right of F12 and above of Insert?

> But I suppose there should be some. If someone has it;
> please could you check with xev and cat+xterm what it
> sends?

Said key gives via cat on xterm:

^[[2~

and xev says the same.

Ciao; Gregor
=2D-
 -... --- .-. . -.. ..--.. ...-.-

(unknown)

[telegraph]

From telegraph@gmx.net  Mon Aug 23 20:37:01 2021
From: Gregor Zattler <telegraph@gmx.net>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: xterm [menu] key definition
In-Reply-To: <87k0kcovp4.fsf@no.workgroup>
References: <20210819024728.kgnf6jmpakqdto4p.ref@Ergus>
 <20210819024728.kgnf6jmpakqdto4p@Ergus> <87k0kcovp4.fsf@no.workgroup>
Mail-Followup-To: emacs-devel <emacs-devel@gnu.org>
Date: Mon, 23 Aug 2021 20:36:58 +0200
Message-ID: <87h7fgovn9.fsf@no.workgroup>
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:HRO/ZXce88Iozn+9UJq+ekk0abWiVqAiW05nvxhROUw4xLXvaVA
 I8MJYVw59QFHLg4As0OZgf1yCpriSS+YQsdNhys754yK6pB/wk2+6i/PbDMRG3YQWQXBUpo
 tvTC4EpNZXzi5CJg4d4uCg+Wj9SxoajT3JMmIXMug1Xz00P1aemSpf0v6oIf5wFAQ/lSwTr
 D/dkF2dL88+BwVa6vBhhw==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:x+ng0FuV5Xw=:c1ueAnEJSAQkxkyqjZnCx1
 KN6IxRv+LnP6G96c416OIk26JuOsdDTIyiXvEUq6QzrLXZ5rgupHYTCvwJQGBvSvaDphMyFDW
 ST49PCmrRrxwWE1dbBVQ27MMr+q1Ny0ITq7KtafxKw1tmDO6FXXA5N8RaecNs6vDmCQtpbW9z
 /HKAM7MjtdvPVAgtFnY/AYbwK+/jXHEFARP5XNgHbQOOdf9n6GiLAP55AehHp6mv7J+f1yr/Y
 ciX0YuEm8kHEixainZ80as4FOQarr0Vetdd59a+BwIafQxT2iUR+brhxxJxEBH4GR7/F7yN5G
 Ftp4iQDM45po2gmJlveQrUj25Urfz6f0reLHFwE/OfQq9wHaElOvOeZUnOsE6xnxh/PL7kASV
 mbYfUxKk1iCdDC8thJtevvbox8fw8bwCSSzcgwwN1SvtkFXGmZxk1ah64ue4Re/slO35L2voM
 fN+xxT6j8MJwtERNEhJZxeGBgQMVlQ+HuErhFhx5zq96HJgNZh6mHER4/hwHyJ7VPWJDpcMqu
 +gQD5H75FMDrPdWeti2lUxpPbqNcVvEvlziv4agxtJGYTNn75GtI526JU20W/5f1oZuwwoFre
 f+oXHczb6XnEctuTuUlJfPQkBvqDfWTk0X7KvzqmyYJyNjJOmo74O/kIIySZbfhruL3HLs7ba
 r2ofHxlQsyJvZRiJ2sX8xbA5aYVI7830NBkvi3aQeQ2PpHpI3FUg8Z0+Hcumly9COz75+GbM3
 pSje0giAF92ACLFp9kbyeRwKJpdpaZy81alSigFqMF9l6gHvY9v1EP3lHX6L1vC1w9S/bTqoQ
 yioc6IwC4iqTnPQV4agbfB7Xyy3IRD2TDh3ntAVihDXMb6IjBr6jSL3dB8hKU9JUAOiBuGy20
 DtvVNkoryKhJQFjg9N8qtjj7NdZuG+iX4bhej2GzQc6/jqOvev4umnj8n1l7AWUiSJWeT3Mec
 auVYAJHcixI79uAPvWH/7R8F2vLv+mtt/oO+3OTz1KDSntG+OiwefVZFSn6tvtfi0cA2GRH/q
 HpF7JyrC/S5FP0PaE9nXV2526YQacHrPSpmbJB5sMxwpOBQ6UYbTV0y9OqtDIkKBh9mwOJ8jL
 nkPnOo63oY9QmXA63umgtmElXMZvdLieT/clPOiVNacWQUdXuMJKa29kw==
Content-Transfer-Encoding: quoted-printable

Hi Ergus,
* Gregor Zattler <telegraph@gmx.net> [2021-08-23; 20:35]:
> * Ergus <spacibba@aol.com> [2021-08-19; 04:47]:
>> I don't actually know about any keyboard with a print
>> button...
>
> wouldn't that be the PrtSc key which is on every standard PC
> keyboard right of F12 and above of Insert?
>
>> But I suppose there should be some. If someone has it;
>> please could you check with xev and cat+xterm what it
>> sends?
>
> Said key gives via cat on xterm:
>
> ^[[2~
>
> and xev says the same.

on debian buster, that is.


Ciao; Gregor
=2D-
 -... --- .-. . -.. ..--.. ...-.-

(unknown)

[Davin Pearson]

[-- Attachment #1.1: Type: text/plain, Size: 795 bytes --]

I was wondering if you could make the following improvement to
GNU Emacs: Make it so that fonts with a nil for background-colour
have the fontification of the inner symbols shines through
to appear over higher layers, like so:

*abc* is fontified as a blue foreground with nil background

"*abc*" is fontified in light blue background with a black foreground
but should appear with a light blue background and a blue foreground.

Here is the Elisp code that I want the behaviour of which changed:

(set-face-foreground 'dmp-face--fg:blue "#000")
(set-face-background 'dmp-face--fg:blue nil)

("\\*.*\\*" 0 'dmp-face--fg:blue t)



-- 
Sorry about the delay in getting back to you.
I am only allowed my computer once per week
so that makes for a two-three week round trip in
getting back to you.

[-- Attachment #1.2: Type: text/html, Size: 1041 bytes --]

[-- Attachment #2: old-screenshot-20211212-181211.png --]
[-- Type: image/png, Size: 261635 bytes --]

[-- Attachment #3: new-screenshot-20121212-181236.png --]
[-- Type: image/png, Size: 262908 bytes --]

(unknown)

[hput]

When I do scripting in ksh93 emacs defaults to a mode that on the
bar across the bottom where page and char number appear it says:
                  (shell-script[ksh 88] abbrev)

I know very little about ksh 88, and do know that it is considered out
dated.

Is there a mode specifically for ksh93?

It seems that when in that `ksh 88' mode my cursor is continually
jerked to a position that is definitely wrong for where I am in the
script.

Now, when I press <enter> after typing the `fi' in an `if' clause, my
cursur is jerked to the position one would add "content" to an `if'
clause, (the `bleh bleh' ) below.

Example:

if [ $this ];then
   bleh bleh
fi <RET>
   [] <= cusor lands here

Instead of
   
if [ $this ];then
   bleh bleh
fi <RET>
[] <= here, where it needs to be for most next steps

From that position (first `if' clause) cursor needs to go to the far
left edge where one might start more scripting such as another `if'
clause.  And that wrong behavior continues throughout the rest of the
script.

Unlike perl-mode .. where cursor lands where it should.

If the `ksh' script has more than a few lines, that can get
aggravating and time consuming to have to get the cursor to the far
left.  What ever means one uses to position the cursor there is a
pause => action and begin again for more scripting. Why is that?

Re: (unknown)

[Stefan Monnier via Users list for the GNU Emacs text editor]

> if [ $this ];then
>    bleh bleh
> fi <RET>
>    [] <= cusor lands here
>
> Instead of
>    
> if [ $this ];then
>    bleh bleh
> fi <RET>
> [] <= here, where it needs to be for most next steps

Definitely sounds like a bug.  Please `M-x report-emacs-bug` and feel
free to put me in the `X-Debbugs-Cc:` since I might very well be
to blame.


        Stefan

(unknown)

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

> Date: Sat, 28 May 2022 08:43:13 +0800
> From: Po Lu <luangruo@yahoo.com>
> To: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Subject: Re: ns-do-applescript
> Message-ID: <87leumebby.fsf@yahoo.com>
> Content-Type: text/plain

> Richard Stallman <rms@gnu.org> writes:

> > I have never heard of "osascript".  What is that?  What systems
> > support it?  Does it exist on GNU/Linux?

> It's only present in macOS.
Right

> > Basically, what are the differences that make it better to use
> > osascript than applescript?

> I think that binary _is_ Apple's proprietary AppleScript interpreter,
Indeed it is

> but using it in a subprocess to retrieve only contacts data (which is
> already possible on free systems) must be more acceptable than Emacs
> including a C primitive to do the same thing.

Not only that. You can do things like raising Emacs to the top and other
system actions that would otherwise require (Objective-)?C functions in the
Emacs executable.

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2842 bytes --]

(unknown)

[Lorenzo Isella]

>
>Lorenzo Isella wrote:
>
>> ;; See https://github.com/jming422/fira-code-mode
>
>Grep that for "non-graphical" and you get this:
>
>(unless (display-graphic-p)
>  (display-warning '(fira-code-ligatures) "fira-code-mode
>  probably won't work for non-graphical displays!"))
>
>So `display-graphic-p' returns nil for you, and truthfully so
>I take it?
>
>If so, read the help for `display-warning' ...
>
>-- 
>underground experts united
>https://dataswamp.org/~incal

Thanks for taking the time to give some help.
I understand that this is a warning which is (rightly) activated by
the code at

https://github.com/jming422/fira-code-mode

Unfortunately, I do not know yet how to disable it.

I would like to avoid tampering with the source code of fira.
How do I read the help for `display-warning' ?
I google it with emacs and I found a lot of hits (too many!) and M-x
help on my emacs does not provide anything about the display-warning.
Thanks!

Lorenzo

Re: (unknown)

[Óscar Fuentes]

Lorenzo Isella <lorenzo.isella@gmail.com> writes:

> Thanks for taking the time to give some help.
> I understand that this is a warning which is (rightly) activated by
> the code at
>
> https://github.com/jming422/fira-code-mode
>
> Unfortunately, I do not know yet how to disable it.
>
> I would like to avoid tampering with the source code of fira.
> How do I read the help for `display-warning' ?

I think the right string you need to pull is the variable
`warning-suppress-types' (or even `warning-suppress-log-types', although
this is mentioned on the docstring of `warning-suppress-types'.)

Or let-bind `warning-minimum-level' around the problematic point:

(let ((warning-minimum-level :error))
  ... put here the the code you want to silence
  )

(unknown)

[Gregory Heytings]

a29a3ad55d breaks the build of master with:

cedet/semantic/symref/list.el:35:2: Error: Wrong type argument: number-or-marker-p, nil

(unknown)

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

Rob writes:
> Regarding the writes to HOME, etc.  I think David covered that fairly
> well -- Debian runs emacs to "do things" (build .elcs, run tests, etc.)
> at package build time, package install time, and during package testing.
> In all of these cases, we're likely to want to avoid side-effects outside
> the build/test dir like writing .elc or .eln files to the current user's
> HOME, whether that's /root/ or /home/*.  It sounds like we may be able
> to accomplish that by redirecting everything to a temp dir, which is
> likely fine.

I know this may come late and be redundant, but just my .01 cents of
experience:
I have my own tweaked Debian infra to build emacs29 for Ubuntu and I have
native-compile enabled. All .eln files generated during build from the
emacs (git) source are stored in /usr/lib/emacs-xyz and are never
recompiled when I run emacs.

What actually gets natively compiled to $HOME/.emacs.d/eln-cache is any
package that I download from (m)elpa-xyz as a result of my
HOME/.emacs.d/init.el

I may be doing something wrong, but AFAIK it seems to work and I have the
same functionality on my Ubuntu natively-compiled Emacs and on the macOS
(both running +/- the same snapshot of the emacs master git branch), where
I have no native compilation.

I hope I somehow contributed something ;-)
/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2037 bytes --]

(unknown)

[cheyrn via Users list for the GNU Emacs text editor]

I don't see a way to specify plain text in this email client. Sorry if it's
html.  

  

I built emacs 28.1 from source on ubuntu 22.04 running under WSL2 on windows
11. I have the theme specified using the GTK_THEME environment variable. The
theme works as expected in gnome-terminal and nautilus, but for emacs it only
works within the window. The border and title bar are white and I'm using
Adwaita-dark theme.  

  

So, first, do you know how I can get the theme to apply to the title bar and
border?  

  

Also, I thought the titlebar and border were ordinarily supplied by a desktop
manager or desktop shell. Since I'm not running a DM, where is that coming
from?  

  

cheyrn  

  

  

(unknown)

[Pedro Andres Aranda Gutierrez]

Joao Tavora wrote:

> This indeed works, I've fixed the manual which previously said that
> setting the variable globally "doesn't make sense".  It can be useful,
> if you know what you're doing.

;-)

> But I don't know if we should be recommending this over the use of
> eglot-server-program + :initializationOptions as described in section
> 5.1 User-specific configuration.  Will see.

Fine, I don't know either whether you should _recommend_.

But, at least mentioning that this can be done to have an initial configuration
to start with... There is no one fits all and some tweaks may be needed
in some projects, but an initial config can speed up the process and it is
'as bad as' putting the dir-locals in your git repo and someone opening it
with -say- vscode or vi ;-)

/PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

(unknown)

[Pedro Andres Aranda Gutierrez]

On Sat, 11 Mar 2023 04:45:21 -0800, Ongaro <david.ongaro@hamburg.de> wrote

> I don't understand this argument. If you're an Emacs user who uses
> tree-sitter the probability is high that you're also a developer so you
> need development tools like a compiler anyway. Especially in a
> "professional" programming environment. A sys-admin banning that would
> be an admin banning you from work.

Two things to bring another perspective:

1.- the probability is high, but what do we do with the (1-p)... shy
them away? ;-)
2.- with the current landscape, even professional developers can't
sometimes do what they need.
There is this balance between productivity and security, which I do
understand. I've already seen a couple of frighting attacks...

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

(unknown)

[Greg Minshall]

hi.  i would like to be able to write Emacs scripts ("#!...") that allow
a user to enter almost any option to the script itself, *without* having
to use double dashes ("--") to avoid colliding with Emacs option
processing.

looking at "--script" and "-x", this doesn't seem possible.

as a test case, given a simple script foo.sh (*), using "-x", and
invoking it with an option "--eval" gives this error:

----
% ./foo.sh --eval
emacs: Option '--eval' requires an argument
----

(that bare "--eval" *should* be an error if it were meant for Emacs
itself; however, it is meant for the Emacs script, which may have other
ideas of the syntax/semantics of "--eval".)

the below patch to src/emacs.c (**) treats a "-x" (and its "partner"
"-scripteval") like a "--" on the command line, and *seems* to allow
arbitrary options on the command line.  for example, with this patch
installed:

----
% ./foo.sh --eval
command-line-args-left (--eval)
----


i wonder if this might be of use for Emacs?  if there are worries about
backwards compatibility with "-x", well ... "-y" anybody?  :)

(i was thinking of writing a test to go with the patch, but the ERT
framework is maybe a bit awkward for tests of essentially
shell-command-line functionality.  i may have missed it, but i didn't
see anything in ./test/Makefile.in that seemed to be aimed at testing
command-line invocation of Emacs.)

cheers, Greg


(*) foo.sh
----
#!/usr/bin/env -S emacs -x

(message "command-line-args-left %s" command-line-args-left)

1
----


(**) proposed patch
----
diff --git a/src/emacs.c b/src/emacs.c
index 6101ed4004c..6e140177086 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -2795,9 +2795,10 @@ sort_args (int argc, char **argv)
        {
          int match;

-         /* If we have found "--", don't consider
-            any more arguments as options.  */
-         if (argv[from][1] == '-' && argv[from][2] == 0)
+         /* If we have found "--", or a "-x", don't consider any more
+            arguments as options.  */
+         if ((((argv[from][1] == '-') || (argv[from][1] == 'x')) && argv[from][2] == 0)
+             || !strcmp(argv[from], "-scripteval"))
            {
              /* Leave the "--", and everything following it, at the end.  */
              for (; from < argc; from++)
----

Re: (unknown)

[Jim Porter]

On 11/17/2023 7:13 PM, Greg Minshall wrote:
> (i was thinking of writing a test to go with the patch, but the ERT
> framework is maybe a bit awkward for tests of essentially
> shell-command-line functionality.  i may have missed it, but i didn't
> see anything in ./test/Makefile.in that seemed to be aimed at testing
> command-line invocation of Emacs.)

You could probably take some inspiration from the "Synchronous 
processes" section of the file test/lisp/eshell/esh-proc-tests.el. 
Essentially, you can just start a new Emacs instance in your ERT test 
and do whatever you like.

Re: Emacs script options

[Eli Zaretskii]

> From: Greg Minshall <minshall@umich.edu>
> Date: Fri, 17 Nov 2023 19:13:56 -0800
> 
> hi.  i would like to be able to write Emacs scripts ("#!...") that allow
> a user to enter almost any option to the script itself, *without* having
> to use double dashes ("--") to avoid colliding with Emacs option
> processing.
> 
> looking at "--script" and "-x", this doesn't seem possible.
> 
> as a test case, given a simple script foo.sh (*), using "-x", and
> invoking it with an option "--eval" gives this error:
> 
> ----
> % ./foo.sh --eval
> emacs: Option '--eval' requires an argument
> ----
> 
> (that bare "--eval" *should* be an error if it were meant for Emacs
> itself; however, it is meant for the Emacs script, which may have other
> ideas of the syntax/semantics of "--eval".)

But if we change that, how can we pass additional options to Emacs
when invoking it from a script?  That is also an important capability,
and replacing it with what you want seems to be an incompatible
change, which takes away a capability we have now.

If we want to be able to pass options to the script itself, we need to
do it in a compatible way, that doesn't lose what we have now.

In any case, could you please show a real-life case where this is
needed?  The -x option was intended to support the use cases where the
rest of the script is Emacs Lisp code, so what would such a script do
with an option that is not interpreted by Emacs, and why is that
needed?

Thanks.

Re: (unknown) -x behavior change

[Greg Minshall]

Jim Porter <jporterbugs@gmail.com> wrote:

> You could probably take some inspiration from the "Synchronous
> processes" section of the file
> test/lisp/eshell/esh-proc-tests.el. Essentially, you can just start a
> new Emacs instance in your ERT test and do whatever you like.

thanks.  that looks likely.

cheers, Greg

ps -- sorry, all, for the lack of Subject:

Re: Emacs script options

[Greg Minshall]

Eli Zaretskii <eliz@gnu.org> wrote:

> But if we change that, how can we pass additional options to Emacs
> when invoking it from a script?  That is also an important capability,
> and replacing it with what you want seems to be an incompatible
> change, which takes away a capability we have now.
> 
> If we want to be able to pass options to the script itself, we need to
> do it in a compatible way, that doesn't lose what we have now.
> 
> In any case, could you please show a real-life case where this is
> needed?  The -x option was intended to support the use cases where the
> rest of the script is Emacs Lisp code, so what would such a script do
> with an option that is not interpreted by Emacs, and why is that
> needed?

this last point is maybe all i can answer now (your other points are
food for thought, and code-staring).  the idea is a generalized facility
that allows script-writers to do whatever they want, define whatever
options they want.

plus, trying to stay out of the way of even current, let alone future,
Emacs options is tricky; realistically, script-writers would need to
require their users to always type double-dashes, e.g.,
----
ls-emacs -- -F
----
which doesn't seem so user-friendly.

in my case, for example, i want to write an Emacs script that has some
familiar options like "-d", "-V", etc., in addition to options to
specify how the script should run (what input files to process, output
files to produce, alterations to behavior).

i could have users do that in an Emacs'y way ('--eval (setq debug 1)').
but, the idea is to provide something that, to the end user, looks like
a standard Unix'y script.  if that makes any sense.

cheers, Greg

Re: Emacs script options

[Eli Zaretskii]

> cc: emacs-devel@gnu.org
> From: Greg Minshall <minshall@umich.edu>
> Comments: In-reply-to Eli Zaretskii <eliz@gnu.org>
>    message dated "Sat, 18 Nov 2023 09:36:36 +0200."
> Date: Sat, 18 Nov 2023 06:38:24 -0800
> 
> Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > In any case, could you please show a real-life case where this is
> > needed?  The -x option was intended to support the use cases where the
> > rest of the script is Emacs Lisp code, so what would such a script do
> > with an option that is not interpreted by Emacs, and why is that
> > needed?
> 
> this last point is maybe all i can answer now (your other points are
> food for thought, and code-staring).  the idea is a generalized facility
> that allows script-writers to do whatever they want, define whatever
> options they want.
> 
> plus, trying to stay out of the way of even current, let alone future,
> Emacs options is tricky; realistically, script-writers would need to
> require their users to always type double-dashes, e.g.,
> ----
> ls-emacs -- -F
> ----
> which doesn't seem so user-friendly.
> 
> in my case, for example, i want to write an Emacs script that has some
> familiar options like "-d", "-V", etc., in addition to options to
> specify how the script should run (what input files to process, output
> files to produce, alterations to behavior).

How would you pass these -F, -d, -V etc. options to Emacs, or use them
in any other way in the script, whose contents is supposed to be an
Emacs Lisp program?  There's something I'm missing here.  I asked my
question because I thought you had a real-life example of a script you
wanted to use, but in your response you don't show any such example.
Can you show it?

Re: Emacs script options

[Sebastian Miele]

> From: Greg Minshall <minshall@umich.edu>
> Date: Fri, 2023-11-17 19:13 -0800
>
> hi.  i would like to be able to write Emacs scripts ("#!...") that allow
> a user to enter almost any option to the script itself, *without* having
> to use double dashes ("--") to avoid colliding with Emacs option
> processing.
>
> looking at "--script" and "-x", this doesn't seem possible.
>
> as a test case, given a simple script foo.sh (*), using "-x", and
> invoking it with an option "--eval" gives this error:
>
> ----
> % ./foo.sh --eval
> emacs: Option '--eval' requires an argument
> ----
>
> (that bare "--eval" *should* be an error if it were meant for Emacs
> itself; however, it is meant for the Emacs script, which may have other
> ideas of the syntax/semantics of "--eval".)
>
> the below patch to src/emacs.c (**) treats a "-x" (and its "partner"
> "-scripteval") like a "--" on the command line, and *seems* to allow
> arbitrary options on the command line.  for example, with this patch
> installed:
>
> ----
> % ./foo.sh --eval
> command-line-args-left (--eval)
> ----

On Linux that can be achieved by defining a custom interpreter.  E.g.,
put the following into ‘/path/to/emacs-script’:

  #!/bin/sh
  script=$1
  shift
  exec emacs -Q --batch --load $script -- "$@"

Then, with the following in a ‘test-script’

  #!/path/to/emacs-script
  ;; -*- mode: emacs-lisp; lexical-binding: t -*-
  (message "%s" command-line-args-left)

‘test-script --eval’ prints "(-- --eval)".

On Linux, and when ‘emacs-script’ is in the PATH, the ‘/path/to/’ in the
shebang even can be omitted.

However, the workaround is not possible on at least some non-Linux
systems, because not all systems allow something interpreted as an
interpreter in a shebang, see
https://en.wikipedia.org/wiki/Shebang_(Unix)#Syntax.

Re: Emacs script options

[Greg Minshall]

Eli Zaretskii <eliz@gnu.org> wrote:

> How would you pass these -F, -d, -V etc. options to Emacs, or use them
> in any other way in the script, whose contents is supposed to be an
> Emacs Lisp program?  There's something I'm missing here.  I asked my
> question because I thought you had a real-life example of a script you
> wanted to use, but in your response you don't show any such example.
> Can you show it?

in this case, the -F, -d, -V are aimed at the elisp code running in the
script, not for Emacs itself.

think of wanting to convert some random unix utility to run as an Emacs
script (rather than as a shell script, say), and trying to make the
command line options (and invocation) the same as the original shell
script.  does that help clarify?

in my case, i have the beginnings of a shell script that is to set up
some state and then invoke Emacs to do some work (org mode stuff).  its
projected getopt(1) strings look like
----
getopt -o "B:C:dhP:V" -l "base-dir:,config-file:,debug,help,publish-dir:,version"
----

presumably most of those options (especially the long ones) don't
conflict with any Emacs command line options.  but, some might ("-d"
does, as it turns out).

i'd like the users (hah!) to be able to type
----
./random-script -d --base-dir ${PWD}/foo
----
rather than
----
./random-script -- -d --base-dir ${PWD}/foo
----

cheers, Greg

(truth in advertising: in addition to this *application*, i also -- for
this application, really -- wrote some emacs-getopt package that would
probably benefit from such a facility.)

Re: Emacs script options

[Greg Minshall]

Sebastian Miele <iota@whxvd.name> wrote:

> On Linux that can be achieved by defining a custom interpreter.  E.g.,
> put the following into ‘/path/to/emacs-script’:

yes, thanks.  R has similar (Rscript in R itself; r in littler).  for a
script writer, it's somewhat of a barrier, wondering how many potential
users' machines will have such a script installed; for users, it's one
more hurdle between them and making use of a provided script.

one could also *imagine* (i.e., i think this could work) a packaging
step that would turn one's elisp script into a string and embed it
inside a "#!/bin/sh" script that would unquote the string and feed it
(along with the command line arguments) to Emacs.  if that worked, it at
least would remove the minor hurdle of needing the custom interpreter
you suggest (since everything -- in my fantaxy -- would be in one file).
it seems very messy, though.

cheers, Greg

Re: Emacs script options

[Bob Rogers]

   From: Sebastian Miele <iota@whxvd.name>
   Date: Sat, 18 Nov 2023 20:18:00 +0100

   > From: Greg Minshall <minshall@umich.edu>
   > Date: Fri, 2023-11-17 19:13 -0800

   . . .

   > the below patch to src/emacs.c (**) treats a "-x" (and its "partner"
   > "-scripteval") like a "--" on the command line, and *seems* to allow
   > arbitrary options on the command line.  for example, with this patch
   > installed:
   >
   > ----
   > % ./foo.sh --eval
   > command-line-args-left (--eval)
   > ----

   On Linux that can be achieved by defining a custom interpreter . . .

   However, the workaround is not possible on at least some non-Linux
   systems, because not all systems allow something interpreted as an
   interpreter in a shebang, see
   https://en.wikipedia.org/wiki/Shebang_(Unix)#Syntax.

A more portable option might be for emacs itself to change its startup
behavior if invoked under a special name.  For example, if you used an
"emacscript" alias, emacs would assume "--batch --load" and defer the
rest of its argument processing to the script.  That would make life
easy on Unix-like systems.  And you could just do

	emacscript script-name.el ...

on non-Unix systems.

   ================
   From: Greg Minshall <minshall@umich.edu>
   Date: Sat, 18 Nov 2023 11:36:52 -0800

   . . .

   i'd like the users (hah!) to be able to type
   ----
   ./random-script -d --base-dir ${PWD}/foo
   ----
   rather than
   ----
   ./random-script -- -d --base-dir ${PWD}/foo
   ----

   cheers, Greg

   (truth in advertising: in addition to this *application*, i also -- for
   this application, really -- wrote some emacs-getopt package that would
   probably benefit from such a facility.)

I am reminded of the emacs-lisp email server I wrote 30 years ago
. . . it ran for about 8 years.  "emacs --batch" on steroids.  ;-}

					-- Bob

Re: Emacs script options

[Eli Zaretskii]

> cc: emacs-devel@gnu.org
> From: Greg Minshall <minshall@umich.edu>
> Comments: In-reply-to Eli Zaretskii <eliz@gnu.org>
>    message dated "Sat, 18 Nov 2023 18:20:56 +0200."
> Date: Sat, 18 Nov 2023 11:36:52 -0800
> 
> Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > How would you pass these -F, -d, -V etc. options to Emacs, or use them
> > in any other way in the script, whose contents is supposed to be an
> > Emacs Lisp program?  There's something I'm missing here.  I asked my
> > question because I thought you had a real-life example of a script you
> > wanted to use, but in your response you don't show any such example.
> > Can you show it?
> 
> in this case, the -F, -d, -V are aimed at the elisp code running in the
> script, not for Emacs itself.

So this is about avoiding the need to type "--" before those options
which you want to be passed to the Lisp code?  Can't you arrange for
another script or shell alias that would inject the "--" part before
invoking the main script?

Re: Emacs script options

[Eli Zaretskii]

> Date: Sat, 18 Nov 2023 21:04:11 -0800
> From: Bob Rogers <rogers@rgrjr.com>
> CC: emacs-devel@gnu.org,
>     Eli Zaretskii <eliz@gnu.org>
> 
> A more portable option might be for emacs itself to change its startup
> behavior if invoked under a special name.

The GNU Coding Standards frown on such practices:

  Please don't make the behavior of a utility depend on the name used to
  invoke it.  It is useful sometimes to make a link to a utility with a
  different name, and that should not change what it does.  Thus, if you
  make 'foo' a link to 'ls', the program should behave the same regardless
  of which of those names is used to invoke it.

Re: Emacs script options

[Jens Schmidt]

On 2023-11-18  20:49, Greg Minshall wrote:

> one could also *imagine* (i.e., i think this could work) a packaging
> step that would turn one's elisp script into a string and embed it
> inside a "#!/bin/sh" script that would unquote the string and feed it
> (along with the command line arguments) to Emacs.  if that worked, it at
> least would remove the minor hurdle of needing the custom interpreter
> you suggest (since everything -- in my fantaxy -- would be in one file).
> it seems very messy, though.

What about this one, which nicely plays with the meaning of ";" in
Emacs and the Bourne shell:

------------------------- test -------------------------
#!/bin/sh
: ; exec emacs --script "$0" -- "$@"
(message "%S" command-line-args-left)
------------------------- test -------------------------

Might not be very portable.  And I couldn't cram the lexical-bindings
line in, yet.

Re: Emacs script options

[Jens Schmidt]

On 2023-11-19  22:39, Jens Schmidt wrote:

> And I couldn't cram the lexical-bindings
> line in, yet.

But of course like this:

------------------------- test -------------------------
#!/bin/sh
: ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-
(message "%S" command-line-args-left)
------------------------- test -------------------------

Re: Emacs script options

[Greg Minshall]

Jens,

> ------------------------- test -------------------------
> #!/bin/sh
> : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-
> (message "%S" command-line-args-left)
> ------------------------- test -------------------------

no way, NO way near hack'y enough.  :)

that is, in fact, truly, truly impressive!

(i'd still vote for something like my mod for "-x", but i can run with
this!)

thank you very much!

cheers, Greg

Re: Emacs script options

[Sebastian Miele]

> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Date: Sun, 2023-11-19 22:47 +0100
>
> ------------------------- test -------------------------
> #!/bin/sh
> : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-
> (message "%S" command-line-args-left)
> ------------------------- test -------------------------

This is the trick that Doom Emacs employs, see
https://github.com/doomemacs/doomemacs/blob/master/bin/doom.

But it has a problem with lexical binding.  Consider:

  #!/bin/sh
  : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t; mode: emacs-lisp -*-

  (defmacro lexical-binding-p ()
    '(let* ((x t)
            (f (lambda () x))
            (x nil))
       (funcall f)))

  (message "%s %s" lexical-binding (lexical-binding-p))

When I run it as a script, the output is "nil nil", i.e., the script
definitely does not run with lexical binding enabled.  When I evaluate
it in a buffer, the output is "t t".

When I discovered the problem some while ago, I wanted to report it as
an issue to Doom Emacs, but the bars for reporting issues to that
specific project were set to high for me to actually go through the
process.

But maybe it should be reported as an Emacs bug?

Re: Emacs script options

[Jens Schmidt]

On 2023-11-20  07:10, Sebastian Miele wrote:

> This is the trick that Doom Emacs employs, see
> https://github.com/doomemacs/doomemacs/blob/master/bin/doom.

Aw, I was afraid that somebody might have code-golfed that already.

> But it has a problem with lexical binding.  Consider:
> 
>   #!/bin/sh
>   : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t; mode: emacs-lisp -*-
> 
>   (defmacro lexical-binding-p ()
>     '(let* ((x t)
>             (f (lambda () x))
>             (x nil))
>        (funcall f)))
> 
>   (message "%s %s" lexical-binding (lexical-binding-p))
> 
> When I run it as a script, the output is "nil nil", i.e., the script
> definitely does not run with lexical binding enabled.  When I evaluate
> it in a buffer, the output is "t t".

I tried byte-compiling something similar yesterday, which also
indicated that the byte-compiler compiles with lexical bindings.  Only
the scripting machinery sees dynamical bindings.

> When I discovered the problem some while ago, I wanted to report it as
> an issue to Doom Emacs, but the bars for reporting issues to that
> specific project were set to high for me to actually go through the
> process.
> 
> But maybe it should be reported as an Emacs bug?

I think chances are good that this gets accepted.  It seems that the
scripting machinery expects a semicolon in the very first column,
without that the lexical-binding line is not recognized.  Even a 
space before the semicolon breaks the recognition.

The problem is in function `lisp_file_lexically_bound_p' from lread.c,
which is indeed much more strict in its recognition of the -*- ... -*-
stanza than the functions `set-auto-mode-1' and
`hack-local-variables-prop-line' from files.el.  The Emacs manual
((emacs) Specifying File Variables) only mentions that the stanza
has to be in the first line (or the second one if the first is taken
by a she-bang), without any restriction where the comment has to start.

Would you or Greg report that as a bug?

Re: Emacs script options

[Sebastian Miele]

> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Date: Mon, 2023-11-20 21:10 +0100
>
> On 2023-11-20  07:10, Sebastian Miele wrote:
>
>> But it has a problem with lexical binding.  Consider:
>>
>>   #!/bin/sh
>>   : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t; mode: emacs-lisp -*-
>>
>>   (defmacro lexical-binding-p ()
>>     '(let* ((x t)
>>             (f (lambda () x))
>>             (x nil))
>>        (funcall f)))
>>
>>   (message "%s %s" lexical-binding (lexical-binding-p))
>>
>> When I run it as a script, the output is "nil nil", i.e., the script
>> definitely does not run with lexical binding enabled.  When I evaluate
>> it in a buffer, the output is "t t".
>
> I tried byte-compiling something similar yesterday, which also
> indicated that the byte-compiler compiles with lexical bindings.  Only
> the scripting machinery sees dynamical bindings.
>
> […]  It seems that the scripting machinery expects a semicolon in the
> very first column, without that the lexical-binding line is not
> recognized.  Even a space before the semicolon breaks the recognition.
>
> The problem is in function `lisp_file_lexically_bound_p' from lread.c,
> which is indeed much more strict in its recognition of the -*- ... -*-
> stanza than the functions `set-auto-mode-1' and
> `hack-local-variables-prop-line' from files.el.  The Emacs manual
> ((emacs) Specifying File Variables) only mentions that the stanza
> has to be in the first line (or the second one if the first is taken
> by a she-bang), without any restriction where the comment has to
> start.

Thank you for the additional investigation into and information about
the issue.

> Would you or Greg report that as a bug?

Done, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67321.

Re: Emacs script options

[Jens Schmidt]

On 2023-11-20  02:19, Greg Minshall wrote:

> no way, NO way near hack'y enough.  :)

I couldn't stand the fact that my hack was taken already plus
that it is flawed, so I set off to extend it with a work-around
for the lexical-binding issue.

While there are surely other methods to achieve what below code
does, supposedly also more stable ones, I wanted to go for
brevity to keep the non-script overhead small:

------------------------- escript -------------------------
#!/bin/sh
: ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-

;; Work around `eval-buffer' not recognizing the lexical-binding
;; stanza when the comment containing it does not start at first
;; column (bug#67321).
(unless (ignore-errors (funcall (let ((v t)) (lambda () v))))
  (with-current-buffer (car eval-buffer-list)
    (goto-char (point-min)) (search-forward "; -*-")
    (delete-region (point-min) (match-beginning 0))
    (eval-buffer)))

;; Script payload.
(message "%S:%S" lexical-binding command-line-args-left)

;; Explicitly exit Emacs to not return from the second-level
;; `eval-buffer'.
(kill-emacs 0)

;;; Local Variables:
;;; mode: emacs-lisp
;;; End:
------------------------- escript -------------------------

(Thanks to Sebastian for opening the bug, BTW.  When looking at
the previous, now merged bug, it seems that this won't be
something easy to get through.)

Re: Emacs script options

[Sebastian Miele]

> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Date: Tue, 2023-11-21 22:13 +0100
>
> On 2023-11-20  02:19, Greg Minshall wrote:
>
>> no way, NO way near hack'y enough.  :)
>
> I couldn't stand the fact that my hack was taken already plus
> that it is flawed, so I set off to extend it with a work-around
> for the lexical-binding issue.
>
> While there are surely other methods to achieve what below code
> does, supposedly also more stable ones, I wanted to go for
> brevity to keep the non-script overhead small:
>
> ------------------------- escript -------------------------
> #!/bin/sh
> : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-
>
> ;; Work around `eval-buffer' not recognizing the lexical-binding
> ;; stanza when the comment containing it does not start at first
> ;; column (bug#67321).
> (unless (ignore-errors (funcall (let ((v t)) (lambda () v))))
>   (with-current-buffer (car eval-buffer-list)
>     (goto-char (point-min)) (search-forward "; -*-")
>     (delete-region (point-min) (match-beginning 0))
>     (eval-buffer)))
>
> ;; Script payload.
> (message "%S:%S" lexical-binding command-line-args-left)
>
> ;; Explicitly exit Emacs to not return from the second-level
> ;; `eval-buffer'.
> (kill-emacs 0)
>
> ;;; Local Variables:
> ;;; mode: emacs-lisp
> ;;; End:
> ------------------------- escript -------------------------

Thank you, I noted this trick for the future.

For the record, Gerd Möllemann mentioned yet another trick on
https://debbugs.gnu.org/67321:

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Wed, 2023-11-22 15:59 +0100
>
> cat >somefile <<EOF
> ; -*- lexical-binding: t -*-
> (message "%s" lexical-binding)
> EOF
> emacs --script somefile

Re: Emacs script options

[Jens Schmidt]

On 2023-11-22  19:17, Sebastian Miele wrote:

> For the record, Gerd Möllemann mentioned yet another trick on
> https://debbugs.gnu.org/67321:
> 
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Wed, 2023-11-22 15:59 +0100
>>
>> cat >somefile <<EOF
>> ; -*- lexical-binding: t -*-
>> (message "%s" lexical-binding)
>> EOF
>> emacs --script somefile

Hmja, only this leaves somefile behind, which I intentionally wanted
to avoid.  (At least in Bash one could get more or less safely rid of
that with a "trap 'rm -f somefile' EXIT", but anyway.)

Re: Emacs script options

[Greg Minshall]

Jens,

> While there are surely other methods to achieve what below code
> does, supposedly also more stable ones, I wanted to go for
> brevity to keep the non-script overhead small:

yes, i would say the below code *is* sufficiently hacky!

but, i would go back to my suggestion for "-x".  i think it would be a
real benefit to those wanting to write general purpose scripts using
Emacs as the "engine" (or whatever).

cheers, Greg

> ------------------------- escript -------------------------
> #!/bin/sh
> : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-
> 
> ;; Work around `eval-buffer' not recognizing the lexical-binding
> ;; stanza when the comment containing it does not start at first
> ;; column (bug#67321).
> (unless (ignore-errors (funcall (let ((v t)) (lambda () v))))
>   (with-current-buffer (car eval-buffer-list)
>     (goto-char (point-min)) (search-forward "; -*-")
>     (delete-region (point-min) (match-beginning 0))
>     (eval-buffer)))
> 
> ;; Script payload.
> (message "%S:%S" lexical-binding command-line-args-left)
> 
> ;; Explicitly exit Emacs to not return from the second-level
> ;; `eval-buffer'.
> (kill-emacs 0)
> 
> ;;; Local Variables:
> ;;; mode: emacs-lisp
> ;;; End:
> ------------------------- escript -------------------------

Re: Emacs script options

[Jens Schmidt]

Hi Greg,

On 2023-11-24  05:22, Greg Minshall wrote:

> but, i would go back to my suggestion for "-x".  i think it would be a
> real benefit to those wanting to write general purpose scripts using
> Emacs as the "engine" (or whatever).

only I have the gut feeling that this branch of your thread drifted
off too far from your initial request, so that you keeping up to your
suggestion won't be noticed here.

So probably you'd like to bump an earlier branch, and/or include Eli
in the Cc.

								Jens

Re: Emacs script options

[Greg Minshall]

Eli, et al.,

there was an interesting discussion on how to use a two-line shell
script as a spring board into Emacs.  but, possibly not everyone
followed the discussion that far.

but, i would jump back to my suggestion for "-x".  i think it would be a
real benefit to those wanting to write general purpose scripts using
Emacs as the "engine" (or whatever you want to call it).

cheers, Greg

Re: Emacs script options

[Eli Zaretskii]

> cc: emacs-devel@gnu.org
> From: Greg Minshall <minshall@umich.edu>
> Comments: In-reply-to Eli Zaretskii <eliz@gnu.org>
>    message dated "Sat, 18 Nov 2023 09:36:36 +0200."
> Date: Sun, 26 Nov 2023 19:29:25 -0800
> 
> there was an interesting discussion on how to use a two-line shell
> script as a spring board into Emacs.  but, possibly not everyone
> followed the discussion that far.
> 
> but, i would jump back to my suggestion for "-x".  i think it would be a
> real benefit to those wanting to write general purpose scripts using
> Emacs as the "engine" (or whatever you want to call it).

My understanding of this is that one can easily avoid the annoyance of
having to use "--" by at least two different techniques.

As mentioned in

  https://lists.gnu.org/archive/html/emacs-devel/2023-11/msg00864.html

the proposed feature will change the Emacs behavior in incompatible
ways, so there's also a significant disadvantage to this proposal.

So on balance, I think that we should not add this feature.

Re: Emacs script options

[Greg Minshall]

hi, Eli,

> My understanding of this is that one can easily avoid the annoyance of
> having to use "--" by at least two different techniques.
> 
> As mentioned in
> 
>   https://lists.gnu.org/archive/html/emacs-devel/2023-11/msg00864.html

there are ways.  they have the random problem here or there.  but, even
if they didn't, i think it would be cleaner, and maybe more robust, to
have something in the "#!/usr/bin/emacs" line that would stop parsing
any Emacs options at the end of that line (rather than looking at any
command line options the end-user gave when invoking the script).

> the proposed feature will change the Emacs behavior in incompatible
> ways, so there's also a significant disadvantage to this proposal.

it's definitely a good idea to not introduce incompatibilities.  (though
i'd be curious to see how people are using "-x" with other Emacs
options, whether on the "#!/usr/bin/emacs" line, or on the command
line.)

how about "-y"? :)

cheers, Greg

(unknown)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Tue, 12 Mar 2024 23:02:10 -0400 (EDT)
> 
> branch: master
> commit 6b40d557c4a9a4152565c1a1b0da49a1aaaec84f
> Author: Po Lu <luangruo@yahoo.com>
> Commit: Po Lu <luangruo@yahoo.com>
> 
>     Port more notification senders to non-XDG systems
>     
>     * doc/lispref/os.texi (Desktop Notifications): Document that
>     `:timeout' is now implemented.
>     
>     * java/org/gnu/emacs/EmacsDesktopNotification.java
>     (EmacsDesktopNotification): New field delay.
>     (display1): Set delay on Android 8.0 and up.
>     
>     * lisp/erc/erc-desktop-notifications.el
>     (erc-notifications-notify): Call Android or Haiku notification
>     functions on those systems.
>     
>     * lisp/gnus/gnus-notifications.el (gnus-notifications-action)
>     (gnus-notification-close): Remove dismissed notifications from
>     the notification to message map.
>     (gnus-notifications-notify): Call android-notifications-notify
>     if possible.
>     
>     * src/androidselect.c (android_init_emacs_desktop_notification):
>     Update accordingly.
>     (android_notifications_notify_1): New argument TIMEOUT.
>     (Fandroid_notifications_notify): New argument QCtimeout.
>     (syms_of_androidselect) <QCtimeout>: New symbol.

This causes the following byte-compilation warning:

  In gnus-notification-close:
  gnus/gnus-notifications.el:91:36: Warning: Unused lexical argument `reason'

(unknown)

[Tennyson Bardwell]

*tl;dr: <esc> converted to meta-prefix during a freeze (spacemacs)*

*Symptoms*
I have an annoying problem, but I think I know what's going on. <esc>[1]
followed by keys like <j> get converted into <M-j> when they arrive at
emacs during a freeze. Practically, my habit of `saving => esc => movement`
causes emacs to freeze for 200-500ms frequently, followed by some random
command happening, causing me a decent amount of problems.

*Environment*
I'm using spacemacs via GUI on a Mac M1[2]. I don't think this is
environment specific, however. I believe I can replicate this in the CLI
vis emacsclient and across versions of emacs.

*Attempted Solution*
I did try to set `meta-prefix-char` from `27` (esc) to `nil` but then I had
weird behavior, like <M-:> stopped working (it was converted to <ESC :>).
It seemed like there was enough odd behavior that I abandoned this route.

*Request*
If anyone has any more information about this (or has intuition) please let
me know. I got the sense that this issue only really affects people in
evil-mode, and that setting meta-prefix-char to nil was a bad idea.

[1]
I press escape via [ C-[ ] on my laptop

[2]
MacOS 14.2.1 on an M1
GNU Emacs 29.2 (build 1, aarch64-apple-darwin21.6.0, NS appkit-2113.60
Version 12.6.6 (Build 21G646)) of 2024-01-18 (homebrew)
spacemacs ffebed03d2d21b8f9b1cbb173656c2fe073f6a7f