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;
[-- 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 --]
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/
[-- 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 --]
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/
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?
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
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.
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
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
Sorry, messed up sending that patch by email, but it's hopefully helpful nonetheless. -Steve
[-- 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 --]
[-- 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 --]
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,
--
^고맙습니다 _地平天成_ 감사합니다_^))//
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 *
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."
>>> 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
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.
>> 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
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
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
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."
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?
Troy Hinckley [2021-07-27 17:54:25] wrote:
> 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.
Hmm... no, the code in `backquote.el` is only used to macro expand uses
of backquotes (which are commonly used in macro definitions but not in
all of them) and `byte-run.el` is indeed careful not to use backquotes,
specifically because that would break the bootstrap.
IIRC there are cases where we rely on even more subtle details, more
specifically, I seem to remember that we have functions whose body uses
macros that aren't yet defined when we define the function, and this
still works OK because this is done at a stage where macro expansion is
still lazy, so the macros in the body of the function are only expanded
when the function gets called (or when it gets byte-compiled) both of
which "happen" to take place later, when the corresponding macros have
been defined.
Stefan
[-- Attachment #1: Type: text/plain, Size: 1709 bytes --] byte-run.el does use backquotes https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/byte-run.el#n122 However I had not thought about the impacts of lazy evaluation. I guess this would require that you load the code twice: First with the interpreter, then with the byte compiler, since you can't compile a macro that has not been defined. On Fri, Jul 30, 2021 at 3:33 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Troy Hinckley [2021-07-27 17:54:25] wrote: > > 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. > > Hmm... no, the code in `backquote.el` is only used to macro expand uses > of backquotes (which are commonly used in macro definitions but not in > all of them) and `byte-run.el` is indeed careful not to use backquotes, > specifically because that would break the bootstrap. > > IIRC there are cases where we rely on even more subtle details, more > specifically, I seem to remember that we have functions whose body uses > macros that aren't yet defined when we define the function, and this > still works OK because this is done at a stage where macro expansion is > still lazy, so the macros in the body of the function are only expanded > when the function gets called (or when it gets byte-compiled) both of > which "happen" to take place later, when the corresponding macros have > been defined. > > > Stefan > > [-- Attachment #2: Type: text/html, Size: 2274 bytes --]
Troy Hinckley [2021-07-30 23:09:29] wrote: > byte-run.el does use backquotes > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/byte-run.el#n122 > However I had not thought about the impacts of lazy evaluation. Right [except evaluation is not lazy, only macro-expansion is]. > I guess this would require that you load the code twice: First with > the interpreter, then with the byte compiler, since you can't compile > a macro that has not been defined. Indeed: we first load the interpreted code when dumping the `src/bootstrap-emacs` executable, which is then used to compile the preloaded files (and the compiler), after which we load them again (but in their compiled form) to dump the final `src/emacs` executable. Note that lazy macro-expansion is only used for some of the preloaded files (more specifically for those loaded before `macroexp.el` in `lisp/loadup.el`, where you can also see some hackish workaround we have to use at that time). Stefan
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- -... --- .-. . -.. ..--.. ...-.-
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-
-... --- .-. . -.. ..--.. ...-.-
[-- 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 --]
[-- 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 --]
a29a3ad55d breaks the build of master with: cedet/semantic/symref/list.el:35:2: Error: Wrong type argument: number-or-marker-p, nil
[-- 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 --]
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
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
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++) ----
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.
> 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'