* Re:
@ 2005-09-10 14:39 Abdulaim
0 siblings, 0 replies; 22+ messages in thread
From: Abdulaim @ 2005-09-10 14:39 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 1223 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Make all tree-sitter modes optional
@ 2023-02-15 17:57 Alan Mackenzie
2023-02-15 18:33 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Alan Mackenzie @ 2023-02-15 17:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: juri, casouri, monnier, larsi, theo, jostein, emacs-devel
Hello, Eli.
On Wed, Feb 15, 2023 at 17:35:16 +0200, Eli Zaretskii wrote:
> > Date: Tue, 14 Feb 2023 21:02:25 +0000
> > Cc: juri@linkov.net, casouri@gmail.com, monnier@iro.umontreal.ca,
> > larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net,
> > emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > > I'm okay with adding the latter, if it turns out easy enough and safe
> > > enough (of which I'm not sure at all), and if such a command will be
> > > implemented for all the *-ts-modes which have non-ts siblings, but I
> > > see no reason for the former, since there are several simple ways to
> > > cause the same effect, and they are all documented in NEWS.
> > OK, Try this (so far only on c-ts-mode.):
> > diff --git a/etc/NEWS b/etc/NEWS
> > index 2d15e39036a..0a745d7cde9 100644
> > --- a/etc/NEWS
> > +++ b/etc/NEWS
> > @@ -3239,10 +3239,13 @@ for which a "built-in" mode would be turned on. For example:
> > (add-to-list 'major-mode-remap-alist '(ruby-mode . ruby-ts-mode))
> > -If you try these modes and don't like them, you can go back to the
> > -"built-in" modes by restarting Emacs. But please tell us why you
> > -didn't like the tree-sitter based modes, so that we could try
> > -improving them.
> > +Normally, the loading of one of the new modes amends 'auto-mode-alist'
> > +such that future visiting of the same type of file will continue to
> > +use that new mode. If this is not what you want, do M-x
> > +<mode>-make-ts-undefault-mode. For a more permanent effect, put, for
> > +example, the following into your initialization file:
> > +
> > + (eval-after-load 'c-ts-mode '(c-make-ts-undefault-mode))
> Please don't delete the text in NEWS, it is a result of many
> discussions and a lot of thought. Your proposal is yet another way of
> going back to the non-ts modes, so simply _adding_ that to what's
> already in NEWS should be much better.
OK, I'll try to combine them.
> > +(defun c-make-ts-undefault-mode ()
> > + "Make the older C and C++ Modes the default major modes for C(++) files."
> > + (interactive)
> > + (setq auto-mode-alist (delete '("\\.h\\'" . c-or-c++-ts-mode)
> > + auto-mode-alist))
> > + (setq auto-mode-alist
> > + (delete '("\\(\\.[chi]\\|\\.lex\\|\\.y\\(acc\\)?\\|\\.x[bp]m\\)\\'" . c-ts-mode)
> > + auto-mode-alist))
> > + (setq auto-mode-alist
> > + (delete
> > + '("\\(\\.ii\\|\\.\\(CC?\\|HH?\\)\\|\\.[ch]\\(pp\\|xx\\|\\+\\+\\)\\|\\.\\(cc\\|hh\\)\\)\\'"
> > + . c++-ts-mode)
> > + auto-mode-alist)))
> > +
> So you revert auto-mode-alist to its original shape, but leave the
> buffers already under c-ts-mode in that mode? Is that what the users
> would expect, you think?
I think so, yes. The scenario I am envisaging is the user tentatively
trying c-ts-mode on one, or a few buffers, then doing C-x C-f foo.c to
carry on with her work using C Mode.
> Also, this won't work if the user customized auto-mode-alist in some
> way wrt some of those file-name extensions.
OK. How about something like the following instead (untested)?
(defun c-make-ts-undefault-mode ()
"<Doc string>"
(interactive)
(let (c)
(while (setq c (rassq 'c-ts-mode auto-mode-alist))
(setq auto-mode-alist (remq c auto-mode-alist)))))
> > > Then they [proposed amendments] aren't "reasonable" at this time.
> > > Maybe later, maybe on master.
> > That will be too late, the damage will have been done.
> What "damage"? why do you call "damage" changes made by others in
> Emacs as part of Emacs development?
The damage I'm talking about is the disruption in users' work flow which
is likely to occur. Being perfectly blunt, c-ts-mode is not yet as
capable as CC Mode in some areas, and in any case its configuration is
wholly different (for good reasons). Converting to the use of c-ts-mode
is a project, not something which can just happen. The current code is
likely to confuse and anger users when, after trying out c-ts-mode, it
gradually dawns on them that the reason C Mode no longer works is that
their newly opened files aren't in C Mode at all. That is what has
happened to me several times.
I'm not calling others' changes damage. I'm calling the disruptive
effect on users' work flow damage. That disruption, once it's happened,
cannot ever be undone.
> > It is the first experience people have of the new modes which will
> > create their long term impressions of them.
> Please leave that to people. We are introducing new technology to
> Emacs, and try doing that in the least intrusive way. If you don't
> want to help that effort (a stance that is frankly very
> disappointing), at least don't bad-mouth it.
I'm doing my best to help. If you don't like me using "damage", perhaps
you could suggest a more acceptable synonym expressing the disadvantage
about to be suffered by some of our users.
> > I remember something similar happening in Emacs 21.1, when the new
> > fringes were not made optional. Lots of users complained loudly and
> > bitterly.
> Well, that's exactly why these new modes are entirely optional.
They're not entirely optional, that's the whole point of my posts over
the last couple of days. One can opt in to using c-ts-mode, but opting
out again is unreasonably difficult. Even restarting Emacs (which to me
is a drastic operation) won't opt out if there are still buffers in
c-ts-mode in the desktop. I don't think the current NEWS item makes this
clear enough.
> > > As I said several times, we have no good idea yet how users will react
> > > to what we have. Maybe, after we hear from them, we decide to
> > > implement such switches, who knows.
> > We are ourselves all users, too. We know how we have reacted, and it is
> > reasonable to try to prevent bad experiences for users similar to
> > ourselves.
> For you and me as users, having to restart Emacs, or having to use a
> separate session for such experiments, is an entirely reasonable and
> simple alternative, ....
Having to restart Emacs is NOT at all reasonable for me, even if it may
be for you. Neither is having to use a separate session. We all use
Emacs differently, with different expectations.
> .... one which should eliminate any need for undoing the "damage" of
> c-ts-mode.
As I noted above, such restarting will not clear the state of c-ts-mode
being default whilst there are still c-ts-mode buffers in the desktop.
Anyhow, there is no mention of using a separate session in NEWS, and
restarting Emacs is incompletely documented (as already noted).
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Make all tree-sitter modes optional
2023-02-15 17:57 Make all tree-sitter modes optional Alan Mackenzie
@ 2023-02-15 18:33 ` Eli Zaretskii
2023-02-17 13:30 ` Alan Mackenzie
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2023-02-15 18:33 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: juri, casouri, monnier, larsi, theo, jostein, emacs-devel
> Date: Wed, 15 Feb 2023 17:57:15 +0000
> Cc: juri@linkov.net, casouri@gmail.com, monnier@iro.umontreal.ca,
> larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net,
> emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
> > So you revert auto-mode-alist to its original shape, but leave the
> > buffers already under c-ts-mode in that mode? Is that what the users
> > would expect, you think?
>
> I think so, yes. The scenario I am envisaging is the user tentatively
> trying c-ts-mode on one, or a few buffers, then doing C-x C-f foo.c to
> carry on with her work using C Mode.
And when going back, they don't want their C/C++ buffers revert to C
mode? I'd be surprised.
> > Also, this won't work if the user customized auto-mode-alist in some
> > way wrt some of those file-name extensions.
>
> OK. How about something like the following instead (untested)?
>
> (defun c-make-ts-undefault-mode ()
> "<Doc string>"
> (interactive)
> (let (c)
> (while (setq c (rassq 'c-ts-mode auto-mode-alist))
> (setq auto-mode-alist (remq c auto-mode-alist)))))
Shouldn't you add the elements of C mode back, in case they were
removed?
> > > > Then they [proposed amendments] aren't "reasonable" at this time.
> > > > Maybe later, maybe on master.
>
> > > That will be too late, the damage will have been done.
>
> > What "damage"? why do you call "damage" changes made by others in
> > Emacs as part of Emacs development?
>
> The damage I'm talking about is the disruption in users' work flow which
> is likely to occur. Being perfectly blunt, c-ts-mode is not yet as
> capable as CC Mode in some areas, and in any case its configuration is
> wholly different (for good reasons). Converting to the use of c-ts-mode
> is a project, not something which can just happen. The current code is
> likely to confuse and anger users when, after trying out c-ts-mode, it
> gradually dawns on them that the reason C Mode no longer works is that
> their newly opened files aren't in C Mode at all. That is what has
> happened to me several times.
This can happen with any new feature. There's nothing we can do about
this, so please just stop worrying about it.
> I'm not calling others' changes damage. I'm calling the disruptive
> effect on users' work flow damage. That disruption, once it's happened,
> cannot ever be undone.
With the implied assumption that the effect will necessarily be
"disruptive" in many cases. Why assume that?
> I'm doing my best to help.
Actually, no, you aren't. "Help" would be to actively partake in the
development of c/c++-ts-mode. You are our best expert on supporting
these languages, so who better than you to do at least part of this
job, if not coordinate and guide the few brave souls who are motivated
enough to do that in record time. I'm extremely disappointed that you
completely removed yourself from that effort. I think we could have
ended up with much better ts modes if you took part in that these last
weeks.
Instead, you only speak up to describe the "disadvantages" of these
new modes, and suggest ways to turn them off.
> > Well, that's exactly why these new modes are entirely optional.
>
> They're not entirely optional, that's the whole point of my posts over
> the last couple of days. One can opt in to using c-ts-mode, but opting
> out again is unreasonably difficult.
That's an unusual way of interpreting "opt out". One doesn't need to
"opt out" of an optional behavior; instead, one should avoid turning
it on, and that's all!
> Even restarting Emacs (which to me is a drastic operation) won't opt
> out if there are still buffers in c-ts-mode in the desktop.
Many people restart Emacs all the time. And those who use desktop
know how to overcome such problems, which aren't unique to these
modes.
> I don't think the current NEWS item makes this clear enough.
The current NEWS already goes way beyond its purpose and scope in
presenting these new modes and the related issues. And I object to
using NEWS to tell users in too much detail how NOT to use our new
features: that is like shooting ourselves in the foot.
> > For you and me as users, having to restart Emacs, or having to use a
> > separate session for such experiments, is an entirely reasonable and
> > simple alternative, ....
>
> Having to restart Emacs is NOT at all reasonable for me, even if it may
> be for you. Neither is having to use a separate session. We all use
> Emacs differently, with different expectations.
>
> > .... one which should eliminate any need for undoing the "damage" of
> > c-ts-mode.
>
> As I noted above, such restarting will not clear the state of c-ts-mode
> being default whilst there are still c-ts-mode buffers in the desktop.
> Anyhow, there is no mention of using a separate session in NEWS, and
> restarting Emacs is incompletely documented (as already noted).
Sounds like you run your full customized production environment in
test runs of Emacs. The prudent thing to do is instead to either use
"emacs -Q" or to have a special user/home directory which you use for
such jobs. Then restarting and/or deleting the desktop is not an
issue at all. I'm surprised I need to explain that, I though
everybody who is involved in Emacs maintenance does that.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Make all tree-sitter modes optional
2023-02-15 18:33 ` Eli Zaretskii
@ 2023-02-17 13:30 ` Alan Mackenzie
2023-02-17 13:37 ` Po Lu
0 siblings, 1 reply; 22+ messages in thread
From: Alan Mackenzie @ 2023-02-17 13:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: juri, casouri, monnier, larsi, theo, jostein, emacs-devel
Hello, Eli.
On Wed, Feb 15, 2023 at 20:33:49 +0200, Eli Zaretskii wrote:
> > Date: Wed, 15 Feb 2023 17:57:15 +0000
> > Cc: juri@linkov.net, casouri@gmail.com, monnier@iro.umontreal.ca,
> > larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net,
> > emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
[ .... ]
> This [severe inconvenience to users who wish to stop using a new
> feature] can happen with any new feature. There's nothing we can do about
> this, ....
There is; we're competent hackers.
> .... so please just stop worrying about it.
I continue to be unhappy about the state of this change. If we are going
to insist on users restarting Emacs simply to remove three entries from
auto-mode-alist, we should at least ensure that such restarting will
work. In the current NEWS, the directions are incomplete and misleading.
I propose the following to correct this; it adds text to what is
currently there rather than replacing it, as you requested a couple of
days ago:
diff --git a/etc/NEWS b/etc/NEWS
index 2d15e39036a..dbe6517e78f 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -3239,10 +3239,13 @@ for which a "built-in" mode would be turned on. For example:
(add-to-list 'major-mode-remap-alist '(ruby-mode . ruby-ts-mode))
-If you try these modes and don't like them, you can go back to the
-"built-in" modes by restarting Emacs. But please tell us why you
-didn't like the tree-sitter based modes, so that we could try
-improving them.
+Loading one of the new modes amends 'auto-mode-alist' such that
+visiting the same type of file in the future will continue to use that
+new mode. If you try these modes and don't like them, you can go back
+to the "built-in" modes by restarting Emacs, but first, if you use
+desktop-save-mode, make sure no buffers using the new mode will get
+entered into your .desktop file. But please tell us why you didn't
+like the tree-sitter based modes, so that we can try improving them.
Each major mode based on tree-sitter needs a language grammar library,
usually named "libtree-sitter-LANG.so" ("libtree-sitter-LANG.dll" on
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: Make all tree-sitter modes optional
2023-02-17 13:30 ` Alan Mackenzie
@ 2023-02-17 13:37 ` Po Lu
2023-02-17 13:46 ` Stefan Monnier
0 siblings, 1 reply; 22+ messages in thread
From: Po Lu @ 2023-02-17 13:37 UTC (permalink / raw)
To: Alan Mackenzie
Cc: Eli Zaretskii, juri, casouri, monnier, larsi, theo, jostein,
emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> Hello, Eli.
>
> On Wed, Feb 15, 2023 at 20:33:49 +0200, Eli Zaretskii wrote:
>> > Date: Wed, 15 Feb 2023 17:57:15 +0000
>> > Cc: juri@linkov.net, casouri@gmail.com, monnier@iro.umontreal.ca,
>> > larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net,
>> > emacs-devel@gnu.org
>> > From: Alan Mackenzie <acm@muc.de>
>
> [ .... ]
>
>> This [severe inconvenience to users who wish to stop using a new
>> feature] can happen with any new feature. There's nothing we can do about
>> this, ....
>
> There is; we're competent hackers.
>
>> .... so please just stop worrying about it.
>
> I continue to be unhappy about the state of this change. If we are going
> to insist on users restarting Emacs simply to remove three entries from
> auto-mode-alist, we should at least ensure that such restarting will
> work. In the current NEWS, the directions are incomplete and misleading.
>
> I propose the following to correct this; it adds text to what is
> currently there rather than replacing it, as you requested a couple of
> days ago:
>
> diff --git a/etc/NEWS b/etc/NEWS
> index 2d15e39036a..dbe6517e78f 100644
> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -3239,10 +3239,13 @@ for which a "built-in" mode would be turned on. For example:
>
> (add-to-list 'major-mode-remap-alist '(ruby-mode . ruby-ts-mode))
>
> -If you try these modes and don't like them, you can go back to the
> -"built-in" modes by restarting Emacs. But please tell us why you
> -didn't like the tree-sitter based modes, so that we could try
> -improving them.
> +Loading one of the new modes amends 'auto-mode-alist' such that
> +visiting the same type of file in the future will continue to use that
> +new mode. If you try these modes and don't like them, you can go back
> +to the "built-in" modes by restarting Emacs, but first, if you use
> +desktop-save-mode, make sure no buffers using the new mode will get
> +entered into your .desktop file. But please tell us why you didn't
> +like the tree-sitter based modes, so that we can try improving them.
>
> Each major mode based on tree-sitter needs a language grammar library,
> usually named "libtree-sitter-LANG.so" ("libtree-sitter-LANG.dll" on
Let me ask what I asked earlier, again?
Does c-ts-mode make itself default upon being loaded, or does it make
itself the default upon being first enabled?
The former has been a Bad Thing for as long as I can remember.
The latter is not particularly problematic as long as we document the
caveat.
Thanks.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Make all tree-sitter modes optional
2023-02-17 13:37 ` Po Lu
@ 2023-02-17 13:46 ` Stefan Monnier
2023-02-17 14:16 ` Po Lu
0 siblings, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2023-02-17 13:46 UTC (permalink / raw)
To: Po Lu
Cc: Alan Mackenzie, Eli Zaretskii, juri, casouri, larsi, theo,
jostein, emacs-devel
> Does c-ts-mode make itself default upon being loaded, or does it make
> itself the default upon being first enabled?
Upon being loaded.
> The former has been a Bad Thing for as long as I can remember.
Yup.
> The latter is not particularly problematic as long as we document
> the caveat.
I can live with that one, yes.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Make all tree-sitter modes optional
2023-02-17 13:46 ` Stefan Monnier
@ 2023-02-17 14:16 ` Po Lu
2023-02-17 14:40 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Po Lu @ 2023-02-17 14:16 UTC (permalink / raw)
To: Stefan Monnier
Cc: Alan Mackenzie, Eli Zaretskii, juri, casouri, larsi, theo,
jostein, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Does c-ts-mode make itself default upon being loaded, or does it make
>> itself the default upon being first enabled?
>
> Upon being loaded.
That is extremely nasty, especially for people who preload all (or most)
Lisp libraries.
c-ts-mode should be fixed before the pretest starts. It is not some
small triviality that can be dismissed.
Alan Mackenzie <acm@muc.de> writes:
>> Let me ask what I asked earlier, again?
>> Does c-ts-mode make itself default upon being loaded, or does it make
>> itself the default upon being first enabled?
>
> It makes itself default upon loading, even if that loading is only in
> response to C-h C-f c-ts-mode.
>
>> The former has been a Bad Thing for as long as I can remember.
>
> Indeed.
This means that if we release Emacs 29 as-is, the resulting Emacs will
be broken.
There is NO REASON asking Emacs to describe something should result in
changes to auto-mode-alist.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Make all tree-sitter modes optional
2023-02-17 14:16 ` Po Lu
@ 2023-02-17 14:40 ` Eli Zaretskii
2023-02-17 14:56 ` Dmitry Gutov
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2023-02-17 14:40 UTC (permalink / raw)
To: Po Lu; +Cc: monnier, acm, juri, casouri, larsi, theo, jostein, emacs-devel
> From: Po Lu <luangruo@yahoo.com>
> Cc: Alan Mackenzie <acm@muc.de>, Eli Zaretskii <eliz@gnu.org>,
> juri@linkov.net, casouri@gmail.com, larsi@gnus.org, theo@thornhill.no,
> jostein@secure.kjonigsen.net, emacs-devel@gnu.org
> Date: Fri, 17 Feb 2023 22:16:07 +0800
>
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> >> Does c-ts-mode make itself default upon being loaded, or does it make
> >> itself the default upon being first enabled?
> >
> > Upon being loaded.
>
> That is extremely nasty, especially for people who preload all (or most)
> Lisp libraries.
>
> c-ts-mode should be fixed before the pretest starts.
It won't be.
Please, everybody, stop pushing for these changes. I understand that
you disagree, but I respectfully request that you-all assume that
either I'm right here (in that I consider the alternatives to be
worse), or if I'm wrong, it is for me to make this mistake and learn
from it. Please give me some minimal credit that I have thought long
and hard about the possible alternatives, and didn't arrive at this
conclusion easily, and that I'm also fully aware that changing the
behavior by loading a package is not good, in and of itself.
TIA
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Make all tree-sitter modes optional
2023-02-17 14:40 ` Eli Zaretskii
@ 2023-02-17 14:56 ` Dmitry Gutov
2023-02-17 15:04 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Dmitry Gutov @ 2023-02-17 14:56 UTC (permalink / raw)
To: Eli Zaretskii, Po Lu
Cc: monnier, acm, juri, casouri, larsi, theo, jostein, emacs-devel
On 17/02/2023 16:40, Eli Zaretskii wrote:
> I understand that
> you disagree, but I respectfully request that you-all assume that
> either I'm right here (in that I consider the alternatives to be
> worse), or if I'm wrong, it is for me to make this mistake and learn
> from it. Please give me some minimal credit that I have thought long
> and hard about the possible alternatives, and didn't arrive at this
> conclusion easily, and that I'm also fully aware that changing the
> behavior by loading a package is not good, in and of itself.
I suppose there is not much to add here, and the mistake (if it is one,
respectfully) is yours to make.
I just don't understand what's your plan here regarding Emacs 29. What's
going to happen next? What kind of feedback will you be looking for?
What I think will happen, is people will try out the new modes, some
will suffer the inconveniences we warned about here and possibly think
less of Emacs as a result; others will avoid those problems by accident;
yet a lot more users will never try these new modes and thus avoid the
problems as well.
If we're lucky, we get a couple of new bug reports associated with it,
maybe 1-6 months after the release: a lot of users don't report
problems, much less these less obvious ones, where the behavior doesn't
end up in a "error" written somewhere. The reports will likely repeat
some of what's already been said.
At what point does this turn into some kind of conclusion, and a
teaching moment, so to speak?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Make all tree-sitter modes optional
2023-02-17 14:56 ` Dmitry Gutov
@ 2023-02-17 15:04 ` Eli Zaretskii
[not found] ` <8735741fic.fsf@dick>
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2023-02-17 15:04 UTC (permalink / raw)
To: Dmitry Gutov
Cc: luangruo, monnier, acm, juri, casouri, larsi, theo, jostein,
emacs-devel
> Date: Fri, 17 Feb 2023 16:56:51 +0200
> Cc: monnier@iro.umontreal.ca, acm@muc.de, juri@linkov.net, casouri@gmail.com,
> larsi@gnus.org, theo@thornhill.no, jostein@secure.kjonigsen.net,
> emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
>
> I just don't understand what's your plan here regarding Emacs 29. What's
> going to happen next? What kind of feedback will you be looking for?
Whatever feedback we will get. I don't know what we will hear, and
I'm not sure why I should try guessing.
> What I think will happen, is people will try out the new modes, some
> will suffer the inconveniences we warned about here and possibly think
> less of Emacs as a result; others will avoid those problems by accident;
> yet a lot more users will never try these new modes and thus avoid the
> problems as well.
>
> If we're lucky, we get a couple of new bug reports associated with it,
> maybe 1-6 months after the release: a lot of users don't report
> problems, much less these less obvious ones, where the behavior doesn't
> end up in a "error" written somewhere. The reports will likely repeat
> some of what's already been said.
Something like that, yes. Except that the 6-month figurer could be
better (or worse), and some of the reports might actually tell us
something that wasn't yet said or proposed.
> At what point does this turn into some kind of conclusion, and a
> teaching moment, so to speak?
It depends on what we hear. It is quite possible that a single report
will show the light. Or a significant number of reports expressing a
particular opinion will change the weight of that opinion. Or
something else. (Or I step down, or am overrun by a bus.)
^ permalink raw reply [flat|nested] 22+ messages in thread
* (unknown)
@ 2021-12-20 2:29 Davin Pearson
2021-12-21 14:29 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Davin Pearson @ 2021-12-20 2:29 UTC (permalink / raw)
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:
2021-12-20 2:29 (unknown) Davin Pearson
@ 2021-12-21 14:29 ` Eli Zaretskii
[not found] ` <CAG9ihEvK5VVgP9O+TXYSz+BQF1=YzMgzGBbc5s-fewwT34yytA@mail.gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2021-12-21 14:29 UTC (permalink / raw)
To: Davin Pearson; +Cc: emacs-devel
> From: Davin Pearson <davin.pearson@gmail.com>
> Date: Mon, 20 Dec 2021 15:29:04 +1300
>
> 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.
AFAIU, what you are asking basically goes against the way faces are
implemented in Emacs: when Emacs merges two faces, if both of them
specify the foreground color, one of them will "win", and the
foreground of the other will be ignored.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:
@ 2021-12-02 14:09 Angelo Graziosi
0 siblings, 0 replies; 22+ messages in thread
From: Angelo Graziosi @ 2021-12-02 14:09 UTC (permalink / raw)
To: emacs-devel@gnu.org, ofv@wanadoo.es
> Try this in your .emacs :
>
> (let ((dir (file-name-directory (car command-line-args))))
> (setenv "PATH" (concat (getenv "PATH") path-separator dir))
> (setq exec-path (append exec-path (list dir))))
I tried this
(let ((dir (file-name-directory (car command-line-args))))
(setenv "PATH" (concat (getenv "PATH") path-separator dir))
(setq exec-path (append exec-path '("C:/msys64/mingw64/bin" "C:/msys64/usr/bin"))))
but it does not seem to work.
First, I had to change it this way
- ...setq exec-path (append exec-path (list dir)...
+ ...setq exec-path (append exec-path '(list dir)...
otherwise Emacs won't start.
Second, with that change only '...\Emacs\bin' is added to the PATH, not the MSYS2/MINGW64 paths...
Instead of change the init file, it is some year I use a Windows .lnk with
Target: C:\Windows\System32\cmd.exe /c "SET path=C:\msys64\mingw64\bin;%path%&& SET PRELOAD_WINSOCK=1&& START /D ^"C:\LocalApps\Emacs\bin^" runemacs.exe"
Ciao,
Angelo.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:
@ 2021-11-04 6:36 Pedro Andres Aranda Gutierrez
0 siblings, 0 replies; 22+ messages in thread
From: Pedro Andres Aranda Gutierrez @ 2021-11-04 6:36 UTC (permalink / raw)
To: Eli Zaretskii, mardani29; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
Hi,
I finally jumped into the cold water yesterday and migrated to Big Sur. I'm
not using HomeBrew but rather Rudix (looki for it in github) to Produce
packages with the libraries I need (gnutls and a couple more). I compile
emacs directly, create the app, use macholib to install all the frameworks
in the package and codesign it (self-signed, no developer key).
Additionally, I'm on emacs-28 right now and can report that the App I had
on Catalina has survived the migration and is running quite well on Big
Sur. I'm planning to compile emacs-28 in my next free slot on a Catalina
box and see if I can install in on Big Sur. Will report then.
Best, /PA
--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler
[-- Attachment #2: Type: text/html, Size: 1031 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* wait_reading_process_ouput hangs in certain cases (w/ patches)
@ 2017-10-24 18:52 Matthias Dahl
2017-11-14 16:03 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Matthias Dahl @ 2017-10-24 18:52 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 3195 bytes --]
Hello all,
recursively calling accept-process-output with the first call waiting
for the output of a specific process, can hang Emacs (as-in: it is
waiting forever but can be canceled of course) even though it should
not be the case since data was read.
This is actually not all that uncommon. One example of this is a hang
seen with Magit opening its COMMIT_MSG buffer, reported here [1]. I've
myself run into this problem continuously which is why I started to
debug it in the first place.
The hang with Magit happens in flyspell.el which waits for output from
its spellchecker process through accept-process-output and specifies
that specific process as wait_proc. Now depending on timing (race),
wait_reading_process_output can call the pending timers... which in
turn can call accept-process-output again. This almost always leads
to the spellchecker output being read back in full, so there is no
more data left to be read. Thus the original accept-process-output,
which called wait_reading_process_output, will wait for the data to
become available forever since it has no way to know that those have
already been read.
Naturally one could argue that a timeout should be specified when
calling accept-process-output. But nevertheless I still think this is
a breach of contract. The caller expects accept-process-output to
return as promised when data has been read from the specified process
and it clearly isn't always the case and can hang forever, depending
on timing and the specifics of the data being read.
The attached patches fix this by introducing process output read
accounting -- simply counting the bytes read per process. And using
that data to strategically check in wait_reading_process_output for
data being read while we handed over control to timers and/or filters.
I haven't seen any ill side-effects in my tests and it clearly fixes
the problem seen in [1] as well as I would wager quite a few others
that were probably seen by user's of all kinds of setups that seemed
unpredictable and mysterious and never debugged.
As a side-note: I decided against an artificial metric and went with
simply counting the bytes read, since this does come in handy when
doing debugging and being able to see how much data was read from a
process during specific time intervals.
Also, this still leaves the possibility that wait_reading_process_output
could wait forever while being called without wait_proc and a timeout
set. This could be mitigated as well by some sort of a tick counter that
only increases when no wait_proc was specified and data from processes
were processed. I decided against implementing that for now since imho
the chances of that happening are marginal, if at all present. OTOH,
the semantics in that case are not all that clear and would further add
complexity to an already rather unhealthy function. I am naturally open
to other opinions and implementing this as well if requested. :-)
Any suggestions and/or comments are very welcome, as always.
Thanks for the patience to read this longish post. :-)
So long,
Matthias
[1] https://github.com/magit/magit/issues/2915
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-process-output-read-accounting.patch --]
[-- Type: text/x-patch; name="0001-Add-process-output-read-accounting.patch", Size: 1625 bytes --]
From 6c24b8d7082222df28d2046bfe70ff0e22342f08 Mon Sep 17 00:00:00 2001
From: Matthias Dahl <matthias.dahl@binary-island.eu>
Date: Tue, 24 Oct 2017 15:55:53 +0200
Subject: [PATCH 1/2] Add process output read accounting
This tracks the bytes read from a process's stdin which is not used
anywhere yet but required for follow-up work.
* src/process.c (read_process_output): Track bytes read from a process.
* src/process.h (struct Lisp_Process): Add infd_num_bytes_read
to track bytes read from a process.
---
src/process.c | 2 ++
src/process.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/src/process.c b/src/process.c
index fc46e74332..904ca60863 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5900,6 +5900,8 @@ read_process_output (Lisp_Object proc, int channel)
/* Now set NBYTES how many bytes we must decode. */
nbytes += carryover;
+ p->infd_num_bytes_read += nbytes;
+
odeactivate = Vdeactivate_mark;
/* There's no good reason to let process filters change the current
buffer, and many callers of accept-process-output, sit-for, and
diff --git a/src/process.h b/src/process.h
index 5a044f669f..f796719a51 100644
--- a/src/process.h
+++ b/src/process.h
@@ -129,6 +129,8 @@ struct Lisp_Process
pid_t pid;
/* Descriptor by which we read from this process. */
int infd;
+ /* Byte-count for process output read from `infd'. */
+ unsigned long infd_num_bytes_read;
/* Descriptor by which we write to this process. */
int outfd;
/* Descriptors that were created for this process and that need
--
2.14.3
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-src-process.c-wait_reading_process_output-Fix-wait_p.patch --]
[-- Type: text/x-patch; name="0002-src-process.c-wait_reading_process_output-Fix-wait_p.patch", Size: 3155 bytes --]
From 57e9adc220312681588180aff2bae1eb07925ad5 Mon Sep 17 00:00:00 2001
From: Matthias Dahl <matthias.dahl@binary-island.eu>
Date: Tue, 24 Oct 2017 15:56:47 +0200
Subject: [PATCH 2/2] * src/process.c (wait_reading_process_output): Fix
wait_proc hang.
If called recursively (through timers or process filters by the means
of accept-process-output), it is possible that the output of wait_proc
has already been read by one of those recursive calls, leaving the
original call hanging forever if no further output arrives through
that fd and no timeout has been specified. Implement proper checks by
taking advantage of the process output read accounting.
---
src/process.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/process.c b/src/process.c
index 904ca60863..a743aa973e 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5003,6 +5003,8 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
struct timespec got_output_end_time = invalid_timespec ();
enum { MINIMUM = -1, TIMEOUT, INFINITY } wait;
int got_some_output = -1;
+ unsigned long initial_wait_proc_num_bytes_read = (wait_proc) ?
+ wait_proc->infd_num_bytes_read : 0;
#if defined HAVE_GETADDRINFO_A || defined HAVE_GNUTLS
bool retry_for_async;
#endif
@@ -5161,6 +5163,17 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
&& requeued_events_pending_p ())
break;
+ /* Timers could have called `accept-process-output', thus reading the output
+ of wait_proc while we (in the worst case) wait endlessly for it to become
+ available later. So we need to check if data has been read and break out
+ early if that is so since our job has been fulfilled. */
+ if (wait_proc
+ && wait_proc->infd_num_bytes_read != initial_wait_proc_num_bytes_read)
+ {
+ got_some_output = 1;
+ break;
+ }
+
/* This is so a breakpoint can be put here. */
if (!timespec_valid_p (timer_delay))
wait_reading_process_output_1 ();
@@ -5606,7 +5619,15 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
buffered-ahead character if we have one. */
nread = read_process_output (proc, channel);
- if ((!wait_proc || wait_proc == XPROCESS (proc))
+
+ /* In case a filter was run that called `accept-process-output', it is
+ possible that the output from wait_proc was already read, leaving us
+ waiting for it endlessly (if no timeout was specified). Thus, we need
+ to check if data was already read. */
+ if (wait_proc
+ && wait_proc->infd_num_bytes_read != initial_wait_proc_num_bytes_read)
+ got_some_output = 1;
+ else if ((!wait_proc || wait_proc == XPROCESS (proc))
&& got_some_output < nread)
got_some_output = nread;
if (nread > 0)
--
2.14.3
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
@ 2017-11-14 16:03 ` Eli Zaretskii
2017-11-14 16:23 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2017-11-14 16:03 UTC (permalink / raw)
To: Paul Eggert; +Cc: ml_emacs-lists, emacs-devel
> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 14 Nov 2017 07:24:31 -0800
>
> On 11/14/2017 06:58 AM, Matthias Dahl wrote:
> > If during an active
> > call to wait_... all recursive calls happen to read exactly 2**32 (or
> > whatever bit depths EMACS_UINT is) bytes back, then we will miss it
> > completely and stall.
>
> First, this means that the companion idea of subtracting the two
> counters to yield a byte count is also buggy because the byte count will
> be wrong for this call. This would be a bug that could happen whenever a
> successful recursive call occurs, which apparently is quite common. So
> if we stick with the current approach, we definitely should be dropping
> the requirement that Eli was thinking of, which says that a positive
> number returned by wait_reading_process_output indicates the number of
> bytes read for this call.
No, I'm not dropping that requirement.
> Second, I don't leaving a known bug in the code, even if the bug is
> unlikely. Too often, these extreme cases occur anyway (e.g., due to a
> network attack). I'd prefer a slightly-more-complicated solution where
> the bug cannot occur. It can't be that hard to fix.
Please describe such a solution, or show the code.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-11-14 16:03 ` Eli Zaretskii
@ 2017-11-14 16:23 ` Eli Zaretskii
2017-11-14 21:54 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2017-11-14 16:23 UTC (permalink / raw)
To: eggert; +Cc: ml_emacs-lists, emacs-devel
> Date: Tue, 14 Nov 2017 18:03:33 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: ml_emacs-lists@binary-island.eu, emacs-devel@gnu.org
>
> > Second, I don't leaving a known bug in the code, even if the bug is
> > unlikely. Too often, these extreme cases occur anyway (e.g., due to a
> > network attack). I'd prefer a slightly-more-complicated solution where
> > the bug cannot occur. It can't be that hard to fix.
>
> Please describe such a solution, or show the code.
And also the problem you are talking about, because I'm not sure I
understand it well enough.
Thanks.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-11-14 16:23 ` Eli Zaretskii
@ 2017-11-14 21:54 ` Paul Eggert
2017-11-15 14:03 ` Matthias Dahl
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2017-11-14 21:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ml_emacs-lists, emacs-devel
On 11/14/2017 08:23 AM, Eli Zaretskii wrote:
> And also the problem you are talking about, because I'm not sure I > understand it well enough.
I doubt whether anyone understands the problem well enough, which is why
I have been asking questions about the proposed solution - which as far
as I can see, is more of a band-aid rather than a real fix. To help move
this forward, I just reread the original bug report here:
https://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00743.html
and I have some further questions that may help understand what's going
on. The bug report said:
> flyspell.el ... waits for output from its spellchecker process > through accept-process-output and specifies that specific process as
> wait_proc. Now depending on timing (race), >
wait_reading_process_output can call the pending timers... which in >
turn can call accept-process-output again. This almost always leads > to
the spellchecker output being read back in full, so there is no > more
data left to be read. Thus the original accept-process-output, > which
called wait_reading_process_output, will wait for the data to > become
available forever since it has no way to know that those have > already
been read.
When this happens, it appears that the original accept-process-output
acted by calling wait_reading_process (0, 0, 0, 0, Qnil, PROC, 0) where
PROC is the ispell-process. First, is that correct? (If not, my
remaining questions may be a wild goose chase....)
This meant the original wait_reading_process did the following: set wait
= INFINITY, run the timers (which apparently call wait_reading_process
recursively), then check whether update_tick != process_tick (line 5182
of process.c in commit 79108894dbcd642121466bb6af6c98c6a56e9233). Is
update_tick equal to process_tick in the problematic call? I'll assume
so, but please check this. (If not, my remaining questions may need to
be changed.)
Next, the original wait_reading_process output checks whether
wait_proc->raw_status_new is nonzero (line 5210). Is it nonzero? For
now, I'll assume it is zero. (If not, my remaining questions may need to
be changed.)
Next, the original wait_reading_process_output checks whether (! EQ
(wait_proc->status, Qrun) && ! connecting_status (wait_proc->status))
(line 5213). Does this check succeed? For now, I'll assume this check
returns false. (If not, then we need to understand why.)
Next, the original wait_reading_process_output recomputes the input wait
masks, sets check_delay = 0, check_write = true, no_avail = 0, timeout =
timer_delay (line 5355), and so forth. This means it wiil call select
with a nonzero timeout, even though we don't want it to do that: we want
wait_reading_process_output to return 0, because it attempted to receive
input but got none.
The changes you're proposing essentially kick the code so that it
pretends that it read some bytes, even though it didn't (because the
bytes were actually read and processed by a subroutine), causing it to
exit the loop (and return nonzero instead of zero -- why?). But isn't
this kick what the update_tick != process_tick (line 5182) check is
supposed to be doing? And if so, why isn't that check working for your
case? Is it because the code is forgetting to increment a tick count?
This above sort of reasoning is the sort of thing that needs to be done
with this sort of change to such an intricate part of the Emacs code.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-11-14 21:54 ` Paul Eggert
@ 2017-11-15 14:03 ` Matthias Dahl
2017-11-16 16:46 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Matthias Dahl @ 2017-11-15 14:03 UTC (permalink / raw)
To: Paul Eggert, Eli Zaretskii; +Cc: emacs-devel
Hello Paul...
On 14/11/17 22:54, Paul Eggert wrote:
> I doubt whether anyone understands the problem well enough, which is why
> I have been asking questions about the proposed solution - which as far
> as I can see, is more of a band-aid rather than a real fix.
What makes you think that, just out of curiosity? I poured quite a lot
of time into debugging this bug, reading up on the relevant C sources
and coming up with a "simple" enough that is easy to grasp and review.
This was by no means a 5-minute look and fix... which is nothing I would
ever do, period. If anything, I am usually too thorough for my own good.
> When this happens, it appears that the original accept-process-output
> acted by calling wait_reading_process (0, 0, 0, 0, Qnil, PROC, 0) where
> PROC is the ispell-process. First, is that correct? (If not, my
> remaining questions may be a wild goose chase....)
Exactly. You can also have a deeper look at things, as there is a full
and detailed backtrace posted a few messages back (emacs-bt-full.txt).
> This meant the original wait_reading_process did the following: set wait
> = INFINITY, run the timers (which apparently call wait_reading_process
> recursively), then check whether update_tick != process_tick (line 5182
> of process.c in commit 79108894dbcd642121466bb6af6c98c6a56e9233). Is
> update_tick equal to process_tick in the problematic call? I'll assume
> so, but please check this. (If not, my remaining questions may need to
> be changed.)
This is pretty much irrelevant, if I am not missing some huge bit piece
of the puzzle somewhere.
If the branch update_tick != process_tick is taken, there is nothing in
there that would eventually notice that the data from our wait_proc has
already been read.
If thread_select signaled that there is no more data available, we end
up with status_notify for our wait_proc -- and that will also only try
to read any remaining data, if at all.
The crucial part is: ALL data has been read from our wait_proc while we
were running timers or filters -- and no further data will become
available until there is some interaction again with the process. That
is the case with the ispell process.
wait_reading_... currently has no chance/code to detect such an event
since it solely relies on pselect calls and such -- which will come up
empty handed if no further data is available, and there is nothing to
change that.
[ ... I skipped the remaining questions for now. If you still think
those are relevant, let me know and I will do my best to answer
those as well. ...]
> The changes you're proposing essentially kick the code so that it
> pretends that it read some bytes, even though it didn't (because the
> bytes were actually read and processed by a subroutine), causing it to
> exit the loop (and return nonzero instead of zero -- why?). But isn't
> this kick what the update_tick != process_tick (line 5182) check is
> supposed to be doing? And if so, why isn't that check working for your
> case? Is it because the code is forgetting to increment a tick count?
The fix is no band-aid, as you put it earlier. To answer your questions:
1)
Yes, it gives wait_reading_... the possibility to exit the loop and
return >= 1, if the data for our wait_proc has been read while we were
running timers or filters.
2)
Returning >= 1 is semantically correct, imho. We were waiting for data
to become available. That data became available. Granted, it is not us
directly who read it and passed it to the filter, but still, the caller
expects us to signal if data become available... and that is exactly
what happened. Returning anything else wouldn't make much sense, imho
and probably (?) cause problems in this particular case...
3)
update_tick != processed_tick ... see earlier in this mail for why this
is not helping a bit with this particular case.
By the way, I do have ideas for solutions that have no corner-cases,
which is what you are asking for. My current solution will fail to
detect a read-back if exactly 2**(bit depth of counter) has been read
which is very (!) unlikely, but still. That's it... otherwise it will
work reliably.
But that requires that we change wait_reading_... to really only return
-1, 0 or 1 and give up returning the real amount of bytes. Otherwise we
either end up with the same corner-case all over again, just in a more
complex solution or with a way too complex solution for this problem.
No user is using the return value in such a way in-tree. And given that
those changes are going only to master, it gives all out-of-tree users
who might use that value differently, ample time to adjust -- or voice
their concerns.
Thanks for your thorough questions and review -- very much appreciated!
So long,
Matthias
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-11-15 14:03 ` Matthias Dahl
@ 2017-11-16 16:46 ` Paul Eggert
2017-11-18 14:24 ` Matthias Dahl
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2017-11-16 16:46 UTC (permalink / raw)
To: Matthias Dahl, Eli Zaretskii; +Cc: emacs-devel
On 11/15/2017 06:03 AM, Matthias Dahl wrote:
> The crucial part is: ALL data has been read from our wait_proc while we
> were running timers or filters -- and no further data will become
> available until there is some interaction again with the process.
Sure, but how do we know that the data read while running timers and
filters was being read on behalf of our caller? Perhaps a timer or
filter fired off some Elisp function that decided to read data for its
own purposes, unrelated to our caller. We wouldn't want to count the
data read by that function as being data of interest to our caller.
In your ispell case we know that the timers and filters are reading on
ispell's behalf, so the proposed fix should be OK. (If memory serves,
integer overflow isn't possible for ispell either.) But I don't yet see
how the fix works in general.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-11-16 16:46 ` Paul Eggert
@ 2017-11-18 14:24 ` Matthias Dahl
2017-11-19 7:07 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Matthias Dahl @ 2017-11-18 14:24 UTC (permalink / raw)
To: Paul Eggert, Eli Zaretskii; +Cc: emacs-devel
Hello Paul...
On 16/11/17 17:46, Paul Eggert wrote:
> Sure, but how do we know that the data read while running timers and
> filters was being read on behalf of our caller? Perhaps a timer or
> filter fired off some Elisp function that decided to read data for its
> own purposes, unrelated to our caller. We wouldn't want to count the
> data read by that function as being data of interest to our caller.
I had considered that when I debugged the bug but think about it for a
moment. If you treat the process as a shared resource, it is your sole
responsibility to take care of proper management and synchronization of
the process as well.
If a wait_... is in progress for process A which is the response to some
interaction A* (w/ filter F1), then if the timers get processed during
our wait and end up with another interaction B* (w/ filter F2) to
process A that will cause havoc either way. They will probably read the
data that was destined for filter F1 or things get messed up even more
horribly.
Thus, that should not happen. And there is actually nothing Emacs can do
about it form its side. This is solely the responsibility of package
authors and so forth to make sure things like that do not happen through
the usual mechanics and techniques.
And doing the same from a filter... well... everything stated above is
true here as well.
The current situation is without a doubt a bug -- Emacs should detect
that data was read and processed and not hang indefinitely. That we can
agree on, I hope. :-)
We could, by the way, avoid this whole problem and dilemma if we shift
the processing of timers to _AFTER_ we are finished with everything. But
this brings in new problems, like if we have to wait too long for the
data to become available, timers would get delayed quite a bit. And they
would only fire once, no matter how much time has passed. So this is not
ideal as well.
Again, I do not see the problem with my solution. We cannot and should
not account for bugs in 3rd party package implementations like the one
state earlier above.
If I'm wrong here or missing something, please don't hesitate to correct
me. Right now, at least, I am not seeing any problems.
Have a nice weekend,
Matthias
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-11-18 14:24 ` Matthias Dahl
@ 2017-11-19 7:07 ` Paul Eggert
2017-11-20 15:29 ` Matthias Dahl
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2017-11-19 7:07 UTC (permalink / raw)
To: Matthias Dahl, Eli Zaretskii; +Cc: emacs-devel
Matthias Dahl wrote:
> If you treat the process as a shared resource, it is your sole
> responsibility to take care of proper management and synchronization of
> the process as well.
OK, but this is all news to me. Shouldn't this be documented? As things stand,
it is not obvious.
So, getting back to the patch proposed in
<https://lists.gnu.org/r/emacs-devel/2017-11/msg00193.html>, this discussion
convinced me that the approach will work well enough. I have the following
suggestions for improvement:
* Fix the bug with carryover that I mentioned in
<https://lists.gnu.org/r/emacs-devel/2017-11/msg00283.html>.
* Document in the Elisp manual that filters and timers are supposed to do
"proper management and synchronization", and be clear about how this constrains
filters and timers. (This is probably the hardest part of the fix....)
* Change the type of infd_num_bytes_read from EMACS_UINT to uintmax_t. This will
provide an extra margin of safety on some platforms. infd_num_bytes_read has
nothing to do with Emacs integers, and wider counts are safer.
* Document in its comment that infd_num_bytes_read is actually the count modulo
UINTMAX_MAX + 1.
* When assigning to got_some_output, ceiling it at INT_MAX to avoid overflow
problems. Something like the following, say:
got_some_output = min (INT_MAX, (wait_proc->infd_num_bytes_read
- initial_wait_proc_num_bytes_read));
This removes the need for that long comment about overflow, since this
assignment cannot overflow.
Thanks.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-11-19 7:07 ` Paul Eggert
@ 2017-11-20 15:29 ` Matthias Dahl
2017-11-21 14:44 ` Matthias Dahl
0 siblings, 1 reply; 22+ messages in thread
From: Matthias Dahl @ 2017-11-20 15:29 UTC (permalink / raw)
To: Paul Eggert, Eli Zaretskii; +Cc: emacs-devel
Hello Paul...
On 19/11/17 08:07, Paul Eggert wrote:
> * Fix the bug with carryover that I mentioned in
> <https://lists.gnu.org/r/emacs-devel/2017-11/msg00283.html>.
Done already locally, will be in the revised patch.
> * Document in the Elisp manual that filters and timers are supposed to
> do "proper management and synchronization", and be clear about how this
> constrains filters and timers. (This is probably the hardest part of the
> fix....)
I believe Eli said he will take care of this one.
> * Change the type of infd_num_bytes_read from EMACS_UINT to uintmax_t.
> This will provide an extra margin of safety on some platforms.
> infd_num_bytes_read has nothing to do with Emacs integers, and wider
> counts are safer.
Thanks, didn't know about that one. Will do.
> * Document in its comment that infd_num_bytes_read is actually the count
> modulo UINTMAX_MAX + 1.
On my todo, will be on the new patch.
> * When assigning to got_some_output, ceiling it at INT_MAX to avoid
> overflow problems. Something like the following, say:
>
> got_some_output = min (INT_MAX, (wait_proc->infd_num_bytes_read
> - initial_wait_proc_num_bytes_read));
Actually, I already spotted this and corrected it locally. I would have
mentioned it in the revised patch. Thanks though for your keen eye. :-)
> This removes the need for that long comment about overflow, since this
> assignment cannot overflow.
Not quite. The long comment explicitly explains why we can always do
the subtraction this way because we could end up in a situation were we
subtract a larger number from a smaller number, e.g. when the initial
value was close to the max and once data was read, we had a wrap around.
The assignment itself was another issue, that went unnoticed in the
first patch. ;-)
I'll update the patches tomorrow most likely and send them to the list
as I just didn't get around to it today.
Thanks again for all the great feedback.
So long,
Matthias
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-11-20 15:29 ` Matthias Dahl
@ 2017-11-21 14:44 ` Matthias Dahl
2017-11-22 8:55 ` Paul Eggert
0 siblings, 1 reply; 22+ messages in thread
From: Matthias Dahl @ 2017-11-21 14:44 UTC (permalink / raw)
To: Paul Eggert, Eli Zaretskii; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
Hello Eli and Paul,
attached you find the updated patches which have all the discussed
changes and fixes.
If there is anything else, please let me know.
Thanks again for all the patience and valuable feedback.
Have a nice day,
Matthias
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-process-output-read-accounting.patch --]
[-- Type: text/x-patch; name="0001-Add-process-output-read-accounting.patch", Size: 1642 bytes --]
From 94cd9ac3867305184f310dbf411729c59897c2c5 Mon Sep 17 00:00:00 2001
From: Matthias Dahl <matthias.dahl@binary-island.eu>
Date: Tue, 24 Oct 2017 15:55:53 +0200
Subject: [PATCH 1/2] Add process output read accounting
This tracks the bytes read from a process's stdin which is not used
anywhere yet but required for follow-up work.
* src/process.c (read_process_output): Track bytes read from a process.
* src/process.h (struct Lisp_Process): Add infd_num_bytes_read
to track bytes read from a process.
---
src/process.c | 4 ++++
src/process.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/src/process.c b/src/process.c
index fc46e74332..ab023457bd 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5886,6 +5886,10 @@ read_process_output (Lisp_Object proc, int channel)
nbytes += buffered && nbytes <= 0;
}
+ /* Don't count carryover as those bytes have already been count by
+ a previous iteration. */
+ p->infd_num_bytes_read += nbytes;
+
p->decoding_carryover = 0;
/* At this point, NBYTES holds number of bytes just received
diff --git a/src/process.h b/src/process.h
index 5670f44736..96c19fcf81 100644
--- a/src/process.h
+++ b/src/process.h
@@ -129,6 +129,8 @@ struct Lisp_Process
pid_t pid;
/* Descriptor by which we read from this process. */
int infd;
+ /* Byte-count modulo (UINTMAX_MAX + 1) for process output read from `infd'. */
+ uintmax_t infd_num_bytes_read;
/* Descriptor by which we write to this process. */
int outfd;
/* Descriptors that were created for this process and that need
--
2.15.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-src-process.c-wait_reading_process_output-Fix-wait_p.patch --]
[-- Type: text/x-patch; name="0002-src-process.c-wait_reading_process_output-Fix-wait_p.patch", Size: 3769 bytes --]
From 1bbe69611bb4db8bd4149d57cfa5be548ee64c9d Mon Sep 17 00:00:00 2001
From: Matthias Dahl <matthias.dahl@binary-island.eu>
Date: Tue, 24 Oct 2017 15:56:47 +0200
Subject: [PATCH 2/2] * src/process.c (wait_reading_process_output): Fix
wait_proc hang.
If called recursively (through timers or process filters by the means
of accept-process-output), it is possible that the output of wait_proc
has already been read by one of those recursive calls, leaving the
original call hanging forever if no further output arrives through
that fd and no timeout has been specified. Implement proper checks by
taking advantage of the process output read accounting.
---
src/process.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/process.c b/src/process.c
index ab023457bd..b75ac171a1 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5003,6 +5003,8 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
struct timespec got_output_end_time = invalid_timespec ();
enum { MINIMUM = -1, TIMEOUT, INFINITY } wait;
int got_some_output = -1;
+ uintmax_t initial_wait_proc_num_bytes_read = (wait_proc) ?
+ wait_proc->infd_num_bytes_read : 0;
#if defined HAVE_GETADDRINFO_A || defined HAVE_GNUTLS
bool retry_for_async;
#endif
@@ -5161,6 +5163,19 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
&& requeued_events_pending_p ())
break;
+ /* Timers could have called `accept-process-output', thus reading the output
+ of wait_proc while we (in the worst case) wait endlessly for it to become
+ available later. So we need to check if data has been read and break out
+ early if that is so since our job has been fulfilled. */
+ if (wait_proc
+ && wait_proc->infd_num_bytes_read != initial_wait_proc_num_bytes_read)
+ {
+ /* Make sure we don't overflow signed got_some_output.
+ Calculating bytes read is modulo (UINTMAX_MAX + 1) and won't overflow. */
+ got_some_output = min(INT_MAX, (wait_proc->infd_num_bytes_read
+ - initial_wait_proc_num_bytes_read));
+ }
+
/* This is so a breakpoint can be put here. */
if (!timespec_valid_p (timer_delay))
wait_reading_process_output_1 ();
@@ -5606,7 +5621,20 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
buffered-ahead character if we have one. */
nread = read_process_output (proc, channel);
- if ((!wait_proc || wait_proc == XPROCESS (proc))
+
+ /* In case a filter was run that called `accept-process-output', it is
+ possible that the output from wait_proc was already read, leaving us
+ waiting for it endlessly (if no timeout was specified). Thus, we need
+ to check if data was already read. */
+ if (wait_proc
+ && wait_proc->infd_num_bytes_read != initial_wait_proc_num_bytes_read)
+ {
+ /* Make sure we don't overflow signed got_some_output.
+ Calculating bytes read is modulo (UINTMAX_MAX + 1) and won't overflow. */
+ got_some_output = min(INT_MAX, (wait_proc->infd_num_bytes_read
+ - initial_wait_proc_num_bytes_read));
+ }
+ else if ((!wait_proc || wait_proc == XPROCESS (proc))
&& got_some_output < nread)
got_some_output = nread;
if (nread > 0)
--
2.15.0
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-11-21 14:44 ` Matthias Dahl
@ 2017-11-22 8:55 ` Paul Eggert
2017-12-04 9:40 ` Matthias Dahl
0 siblings, 1 reply; 22+ messages in thread
From: Paul Eggert @ 2017-11-22 8:55 UTC (permalink / raw)
To: Matthias Dahl, Eli Zaretskii; +Cc: emacs-devel
> + /* Don't count carryover as those bytes have already been count by
> + a previous iteration. */
> + p->infd_num_bytes_read += nbytes;
> +
This doesn't look right, as nbytes might be negative (indicating an error).
> Subject: [PATCH 2/2] * src/process.c (wait_reading_process_output): Fix
> wait_proc hang.
Please start with a summary line that doesn't contain so much detail. <=50 chars
is good. No trailing period. "Fix wait_reading_process_output_hang", perhaps.
> + uintmax_t initial_wait_proc_num_bytes_read = (wait_proc) ?
> + wait_proc->infd_num_bytes_read : 0;
Kind of a long name, no? Perhaps make it shorter, so that you can write
something like this:
uintmax_t nbytes_read0 = wait_proc ? wait_proc->infd_num_bytes_read : 0;
Even better, shorten the member name too: "nbytes_read" is easier to read than
"infd_num_bytes_read".
> + /* Timers could have called `accept-process-output', thus reading the output
Please limit the program to 80 columns.
> + of wait_proc while we (in the worst case) wait endlessly for it to become
> + available later. So we need to check if data has been read and break out
> + early if that is so since our job has been fulfilled. */
> + if (wait_proc
> + && wait_proc->infd_num_bytes_read != initial_wait_proc_num_bytes_read)
> + {
> + /* Make sure we don't overflow signed got_some_output.
> + Calculating bytes read is modulo (UINTMAX_MAX + 1) and won't overflow. */
> + got_some_output = min(INT_MAX, (wait_proc->infd_num_bytes_read
> + - initial_wait_proc_num_bytes_read));
Space before "(" in function calls.
> + if (wait_proc
> + && wait_proc->infd_num_bytes_read != initial_wait_proc_num_bytes_read)
> + {
> + /* Make sure we don't overflow signed got_some_output.
> + Calculating bytes read is modulo (UINTMAX_MAX + 1) and won't overflow. */
> + got_some_output = min(INT_MAX, (wait_proc->infd_num_bytes_read
> + - initial_wait_proc_num_bytes_read));
> + }
It's annoying that the code (and the comment!) is duplicated. How about putting
it into a function? Also, there's nothing unusual about unsigned arithmetic
wrapping around; to me that (repeated) comment is almost as bad as writing "i++;
/* Add 1 to i. */". Perhaps that's just me, but at least the obvious comment
should not be duplicated.
A function like this, perhaps?
static int
input_progress (struct Lisp_Process *wait_proc, uintmax_t nbytes_read0)
{
if (wait_proc)
{
/* This subtraction might wrap around; that's OK. */
uintmax_t progress = wait_proc->nbytes_read - nbytes_read0;
if (progress != 0)
return min (progress, INT_MAX);
}
return -1;
}
and then the above chunks could be turned into something as simple as:
got_some_output = input_progress (wait_proc, nbytes_read0);
with maybe some other trivial changes to make this all work.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-11-22 8:55 ` Paul Eggert
@ 2017-12-04 9:40 ` Matthias Dahl
2018-02-13 14:25 ` Matthias Dahl
0 siblings, 1 reply; 22+ messages in thread
From: Matthias Dahl @ 2017-12-04 9:40 UTC (permalink / raw)
To: Paul Eggert, Eli Zaretskii; +Cc: emacs-devel
Hello guys...
I am terribly sorry I haven't yet made the changes and posted updated
patches. Real life happened, unfortunately, as always. I have not been
kidnapped by aliens -- I believe.
This is top on my list and I will post something later this week if
everything goes as planned.
Thanks for the patience.
Have a nice day,
Matthias
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2017-12-04 9:40 ` Matthias Dahl
@ 2018-02-13 14:25 ` Matthias Dahl
2018-02-16 16:01 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Matthias Dahl @ 2018-02-13 14:25 UTC (permalink / raw)
To: Paul Eggert, Eli Zaretskii; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
Hello,
after some unexpected / unintended prolonged delay due to personal
reasons, for which I apologize, attached the v2 of my patches.
Basically I have gone a somewhat different route. While working in
some of the requested changes, I noticed that there were still some
pathological cases that were not covered and fixing that would make
things even more convoluted.
So, in this version, the return value is calculated (if necessary)
strategically right before we return from the function call, thus it
cannot be missed and we will always properly signal if data was read
from a wait_proc (either directly or indirectly).
And instead of messing with got_some_output, we exit the loop when we
got some data (directly or indirectly) for our wait_proc if there is
no data to be read for this iteration. This leaves the whole function
logic alone -- except for this key point.
I have addressed the remaining issues, if they still applied. And I
have not been able to trigger a single hang with these patches.
I appreciate any comments and suggestions.
Thanks, again, for all the patience.
So long,
Matthias
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-process-output-read-accounting.patch --]
[-- Type: text/x-patch; name="0001-Add-process-output-read-accounting.patch", Size: 1597 bytes --]
From 94e0dc26f45e1a06881b016dd26446c43d339a4d Mon Sep 17 00:00:00 2001
From: Matthias Dahl <matthias.dahl@binary-island.eu>
Date: Tue, 24 Oct 2017 15:55:53 +0200
Subject: [PATCH 1/2] Add process output read accounting
This tracks the bytes read from a process' stdin which is not used
anywhere yet but required for follow-up work.
* src/process.c (read_process_output): Track bytes read from a process.
* src/process.h (struct Lisp_Process): Add nbytes_read to track bytes
read from a process.
---
src/process.c | 3 +++
src/process.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/src/process.c b/src/process.c
index 2ec10b12ec..17fdf592ec 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5889,6 +5889,9 @@ read_process_output (Lisp_Object proc, int channel)
return nbytes;
coding->mode |= CODING_MODE_LAST_BLOCK;
}
+
+ /* Ignore carryover, it's been added by a previous iteration already. */
+ p->nbytes_read += nbytes;
/* Now set NBYTES how many bytes we must decode. */
nbytes += carryover;
diff --git a/src/process.h b/src/process.h
index ab468b18c5..6464a8cc61 100644
--- a/src/process.h
+++ b/src/process.h
@@ -129,6 +129,8 @@ struct Lisp_Process
pid_t pid;
/* Descriptor by which we read from this process. */
int infd;
+ /* Byte-count modulo (UINTMAX_MAX + 1) for process output read from `infd'. */
+ uintmax_t nbytes_read;
/* Descriptor by which we write to this process. */
int outfd;
/* Descriptors that were created for this process and that need
--
2.16.1
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Fix-wait_reading_process_output-wait_proc-hang.patch --]
[-- Type: text/x-patch; name="0002-Fix-wait_reading_process_output-wait_proc-hang.patch", Size: 3307 bytes --]
From b9c05bbfb4559b21deb0ea4e156430dedb60ce41 Mon Sep 17 00:00:00 2001
From: Matthias Dahl <matthias.dahl@binary-island.eu>
Date: Tue, 6 Feb 2018 15:24:15 +0100
Subject: [PATCH 2/2] Fix wait_reading_process_output wait_proc hang
* src/process.c (wait_reading_process_output): If called recursively
through timers and/or process filters via accept-process-output, it is
possible that the output of wait_proc has already been read by one of
those recursive calls, leaving the original call hanging forever if no
further output arrives through that fd and no timeout has been set.
Fix that by using the process read accounting to keep track of how
many bytes have been read and use that as a condition to break out
of the infinite loop and return to the caller as well as to calculate
the proper return value (if a wait_proc is given that is).
---
src/process.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/src/process.c b/src/process.c
index 17fdf592ec..0abbd5fa8e 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5006,6 +5006,7 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
struct timespec got_output_end_time = invalid_timespec ();
enum { MINIMUM = -1, TIMEOUT, INFINITY } wait;
int got_some_output = -1;
+ uintmax_t prev_wait_proc_nbytes_read = wait_proc ? wait_proc->nbytes_read : 0;
#if defined HAVE_GETADDRINFO_A || defined HAVE_GNUTLS
bool retry_for_async;
#endif
@@ -5460,6 +5461,8 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
if (nfds == 0)
{
/* Exit the main loop if we've passed the requested timeout,
+ or have read some bytes from our wait_proc (either directly
+ in this call or indirectly through timers / process filters),
or aren't skipping processes and got some output and
haven't lowered our timeout due to timers or SIGIO and
have waited a long amount of time due to repeated
@@ -5467,7 +5470,9 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
struct timespec huge_timespec
= make_timespec (TYPE_MAXIMUM (time_t), 2 * TIMESPEC_RESOLUTION);
struct timespec cmp_time = huge_timespec;
- if (wait < TIMEOUT)
+ if (wait < TIMEOUT
+ || (wait_proc
+ && wait_proc->nbytes_read != prev_wait_proc_nbytes_read))
break;
if (wait == TIMEOUT)
cmp_time = end_time;
@@ -5772,6 +5777,15 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
maybe_quit ();
}
+ /* Timers and/or process filters that we have run could have themselves called
+ `accept-process-output' (and by that indirectly this function), thus
+ possibly reading some (or all) output of wait_proc without us noticing it.
+ This could potentially lead to an endless wait (dealt with earlier in the
+ function) and/or a wrong return value (dealt with here). */
+ if (wait_proc && wait_proc->nbytes_read != prev_wait_proc_nbytes_read)
+ got_some_output = min (INT_MAX, (wait_proc->nbytes_read
+ - prev_wait_proc_nbytes_read));
+
return got_some_output;
}
\f
--
2.16.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2018-02-13 14:25 ` Matthias Dahl
@ 2018-02-16 16:01 ` Eli Zaretskii
2018-02-16 16:09 ` Lars Ingebrigtsen
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2018-02-16 16:01 UTC (permalink / raw)
To: Matthias Dahl; +Cc: eggert, emacs-devel
> Cc: emacs-devel@gnu.org
> From: Matthias Dahl <ml_emacs-lists@binary-island.eu>
> Date: Tue, 13 Feb 2018 15:25:44 +0100
>
> after some unexpected / unintended prolonged delay due to personal
> reasons, for which I apologize, attached the v2 of my patches.
>
> Basically I have gone a somewhat different route. While working in
> some of the requested changes, I noticed that there were still some
> pathological cases that were not covered and fixing that would make
> things even more convoluted.
>
> So, in this version, the return value is calculated (if necessary)
> strategically right before we return from the function call, thus it
> cannot be missed and we will always properly signal if data was read
> from a wait_proc (either directly or indirectly).
>
> And instead of messing with got_some_output, we exit the loop when we
> got some data (directly or indirectly) for our wait_proc if there is
> no data to be read for this iteration. This leaves the whole function
> logic alone -- except for this key point.
>
> I have addressed the remaining issues, if they still applied. And I
> have not been able to trigger a single hang with these patches.
>
> I appreciate any comments and suggestions.
Thanks for your work and perseverance. I've now pushed this to the
master branch.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2018-02-16 16:01 ` Eli Zaretskii
@ 2018-02-16 16:09 ` Lars Ingebrigtsen
2018-02-22 11:45 ` andres.ramirez
0 siblings, 1 reply; 22+ messages in thread
From: Lars Ingebrigtsen @ 2018-02-16 16:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Matthias Dahl, emacs-devel, eggert
Eli Zaretskii <eliz@gnu.org> writes:
> Thanks for your work and perseverance. I've now pushed this to the
> master branch.
I've tested this for three minutes in Gnus, and I'm not seeing the
network related hangs than I've seen earlier, so this looks promising.
But three minutes is a bit short to say anything definite. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2018-02-16 16:09 ` Lars Ingebrigtsen
@ 2018-02-22 11:45 ` andres.ramirez
2018-02-26 14:39 ` Matthias Dahl
0 siblings, 1 reply; 22+ messages in thread
From: andres.ramirez @ 2018-02-22 11:45 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: eggert, Eli Zaretskii, Matthias Dahl, emacs-devel
Hi.
> I've tested this for three minutes in Gnus, and I'm not seeing the
> network related hangs than I've seen earlier, so this looks promising.
I have tested this patch for four days.
Nntp news have improved. No network hangs until now.
AR
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2018-02-22 11:45 ` andres.ramirez
@ 2018-02-26 14:39 ` Matthias Dahl
2018-02-26 15:11 ` andrés ramírez
0 siblings, 1 reply; 22+ messages in thread
From: Matthias Dahl @ 2018-02-26 14:39 UTC (permalink / raw)
To: andres.ramirez, Lars Ingebrigtsen; +Cc: Eli Zaretskii, eggert, emacs-devel
Hello Andres,
Thanks for reporting back, it is very much appreciated and quite useful
feedback.
On 22/02/18 12:45, andres.ramirez wrote:
> Nntp news have improved. No network hangs until now.
Great to hear. I suspect there are quite a few mysterious Emacs hangs
that have been reported to package maintainers and such but never got
reproduced/diagnosed that can be directly attributed to this bug.
It would be nice to also have this in Emacs 26 since 27 is still very
far away for the majority of users.
So long,
Matthias
--
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2018-02-26 14:39 ` Matthias Dahl
@ 2018-02-26 15:11 ` andrés ramírez
2018-02-26 15:17 ` Lars Ingebrigtsen
0 siblings, 1 reply; 22+ messages in thread
From: andrés ramírez @ 2018-02-26 15:11 UTC (permalink / raw)
To: Matthias Dahl; +Cc: Lars Ingebrigtsen, eggert, Eli Zaretskii, emacs-devel
> Great to hear. I suspect there are quite a few mysterious Emacs hangs
> that have been reported to package maintainers and such but never got
> reproduced/diagnosed that can be directly attributed to this bug.
That's my idea also.
> It would be nice to also have this in Emacs 26 since 27 is still very
> far away for the majority of users.
But. I need to remind this case:
https://xkcd.com/1172/
Btw. Lars. Mentioned a hang. I have also got a hang a few minutes ago reading
nntp news with an specific site (hacker news nntp; most of my hangs in last 8 years have
been on emacs-devel nntp and also on hacker news nntp). With my mail client
wanderlust reading.
--8<---------------cut here---------------start------------->8---
/last:1000/-gwene.com.ycombinator.news@news.gwene.org "hnews"
--8<---------------cut here---------------end--------------->8---
The other one. I have NOT yet got a hang. But quite probably I am
going to get it:
--8<---------------cut here---------------start------------->8---
/last:2000/-gmane.emacs.devel@news.gmane.org "emacs-devel"
--8<---------------cut here---------------end--------------->8---
I am still testing emacs-27 (master).
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2018-02-26 15:11 ` andrés ramírez
@ 2018-02-26 15:17 ` Lars Ingebrigtsen
2018-02-26 15:29 ` andrés ramírez
0 siblings, 1 reply; 22+ messages in thread
From: Lars Ingebrigtsen @ 2018-02-26 15:17 UTC (permalink / raw)
To: andrés ramírez
Cc: eggert, Eli Zaretskii, Matthias Dahl, emacs-devel
andrés ramírez <rrandresf@gmail.com> writes:
> Btw. Lars. Mentioned a hang. I have also got a hang a few minutes ago
> reading nntp news with an specific site (hacker news nntp; most of my
> hangs in last 8 years have been on emacs-devel nntp and also on hacker
> news nntp). With my mail client wanderlust reading.
The fixes to wait_reading_process_ouput have definitely made a
difference. I used to see hangs several times a day, but after the fix,
I'm only seeing the hangs once every few days, and it's impossible to
set up a repeatable test case for them. So my guess is that there might
still be a problem in this area, but that the window for triggering it
is much smaller.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2018-02-26 15:17 ` Lars Ingebrigtsen
@ 2018-02-26 15:29 ` andrés ramírez
2018-02-26 16:52 ` Daniel Colascione
0 siblings, 1 reply; 22+ messages in thread
From: andrés ramírez @ 2018-02-26 15:29 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: eggert, Eli Zaretskii, Matthias Dahl, emacs-devel
> The fixes to wait_reading_process_ouput have definitely made a
> difference. I used to see hangs several times a day, but after the fix,
> I'm only seeing the hangs once every few days, and it's impossible to
> set up a repeatable test case for them. So my guess is that there might
> still be a problem in this area, but that the window for triggering it
> is much smaller.
Right. I was thinking the last some days about backporting this change
by myself even to emacs-23 which I still use on an embedded platform (my
phone).
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2018-02-26 15:29 ` andrés ramírez
@ 2018-02-26 16:52 ` Daniel Colascione
2018-02-26 17:19 ` andrés ramírez
0 siblings, 1 reply; 22+ messages in thread
From: Daniel Colascione @ 2018-02-26 16:52 UTC (permalink / raw)
To: andrés ramírez, Lars Ingebrigtsen
Cc: Matthias Dahl, Eli Zaretskii, eggert, emacs-devel
On 02/26/2018 07:29 AM, andrés ramírez wrote:
>> The fixes to wait_reading_process_ouput have definitely made a
>> difference. I used to see hangs several times a day, but after the fix,
>> I'm only seeing the hangs once every few days, and it's impossible to
>> set up a repeatable test case for them. So my guess is that there might
>> still be a problem in this area, but that the window for triggering it
>> is much smaller.
>
> Right. I was thinking the last some days about backporting this change
> by myself even to emacs-23 which I still use on an embedded platform (my
> phone).
Why wouldn't the phone run a newer Emacs?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: wait_reading_process_ouput hangs in certain cases (w/ patches)
2018-02-26 16:52 ` Daniel Colascione
@ 2018-02-26 17:19 ` andrés ramírez
2018-02-26 17:24 ` Daniel Colascione
0 siblings, 1 reply; 22+ messages in thread
From: andrés ramírez @ 2018-02-26 17:19 UTC (permalink / raw)
To: Daniel Colascione
Cc: Matthias Dahl, Lars Ingebrigtsen, eggert, Eli Zaretskii,
emacs-devel
> Why wouldn't the phone run a newer Emacs?
info 4.3 is not supported anymore which is installed on kernel 2.6.28.
gtk 2.24. There is some hope on maemo-leste for having mainline on the
n900 which is from the year 2009. Sorry guys droid does not have emacs with X. But this
phone has it. If maemo leste is succesfull I could migrate to
emacs-master once again. I have been running emacs on a touch phone see
my pic:
https://transfer.sh/hOfuv/Screenshot-20180226-121458.png
AR
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:
2018-02-26 17:19 ` andrés ramírez
@ 2018-02-26 17:24 ` Daniel Colascione
2018-02-27 1:53 ` Re: andrés ramírez
0 siblings, 1 reply; 22+ messages in thread
From: Daniel Colascione @ 2018-02-26 17:24 UTC (permalink / raw)
To: andrés ramírez
Cc: Matthias Dahl, Lars Ingebrigtsen, eggert, Eli Zaretskii,
emacs-devel
On 12/31/1969 04:00 PM, wrote:
>> Why wouldn't the phone run a newer Emacs?
>
> info 4.3 is not supported anymore which is installed on kernel 2.6.28.
Can't bootstrap a newer makeinfo?
> gtk 2.24. There is some hope on maemo-leste for having mainline on the
> n900 which is from the year 2009. Sorry guys droid does not have emacs with X. But this
> phone has it. If maemo leste is succesfull I could migrate to
> emacs-master once again. I have been running emacs on a touch phone see
I mean, if we can support Windows 95, we can support this ancient phone.
> my pic:
> https://transfer.sh/hOfuv/Screenshot-20180226-121458.png
Cool. I've wanted better mobile support for Emacs for ages. I've been
disappointed with all the org-mode mobile client options, and I think
there's no substitute for the real thing.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:
2018-02-26 17:24 ` Daniel Colascione
@ 2018-02-27 1:53 ` andrés ramírez
0 siblings, 0 replies; 22+ messages in thread
From: andrés ramírez @ 2018-02-27 1:53 UTC (permalink / raw)
To: Daniel Colascione
Cc: Matthias Dahl, Lars Ingebrigtsen, eggert, Eli Zaretskii,
emacs-devel
On Mon, 26 Feb 2018 11:24:16 -0600,
Daniel Colascione wrote:
>
> On 12/31/1969 04:00 PM, wrote:
> >> Why wouldn't the phone run a newer Emacs?
> >
> > info 4.3 is not supported anymore which is installed on kernel 2.6.28.
>
> Can't bootstrap a newer makeinfo?
I could compile with --without-makeinfo too. I remember I compiled the
previous release candidate of emacs there and found a bug on eww because
of these old libraries. But emacs-23 have also a small binary which is
paramount on those devices (see the nokia n800). Which I do not turn on
almost for a year now.
>
> Cool. I've wanted better mobile support for Emacs for ages. I've been
> disappointed with all the org-mode mobile client options, and I think
> there's no substitute for the real thing.
Yes this phone is the real linux phone. I can make phone calls from
bbdb, text from bbdb also. store gps points when needed on a text
file (with a key combination). having with me all my org files is really nice. I need to
hildonize the emacs source code. It means replacing:
--8<---------------cut here---------------start------------->8---
wtop = gtk_window_new (GTK_WINDOW_TOPLEVEL);
on ~/abs/emacs-27.0.50/src/gtkutil.c
--8<---------------cut here---------------end--------------->8---
With
--8<---------------cut here---------------start------------->8---
wtop = hildon_window_new();
hildon_gtk_window_set_portrait_flags (GTK_WINDOW(window), HILDON_PORTRAIT_MODE_SUPPORT);
--8<---------------cut here---------------end--------------->8---
And Emacs is going to support screen rotation (portrait mode). On the
phone.
^ permalink raw reply [flat|nested] 22+ messages in thread
* (unknown)
@ 2016-02-08 7:54 steve
2016-02-08 12:56 ` Artur Malabarba
0 siblings, 1 reply; 22+ messages in thread
From: steve @ 2016-02-08 7:54 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re:
2016-02-08 7:54 (unknown) steve
@ 2016-02-08 12:56 ` Artur Malabarba
2016-02-08 19:05 ` Re: Steve Purcell
0 siblings, 1 reply; 22+ messages in thread
From: Artur Malabarba @ 2016-02-08 12:56 UTC (permalink / raw)
To: Steve Purcell; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
> - :prompt-regexp "^\\w*=[#>] "
> + :prompt-regexp "^[[:alpha:]_]*=[#>] "
One thing that comes to mind is that \\w and :alpha: are generally not the
same thing. So \\(\\w\\|_\\) might be more appropriate.
[-- Attachment #2: Type: text/html, Size: 294 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:
2016-02-08 12:56 ` Artur Malabarba
@ 2016-02-08 19:05 ` Steve Purcell
2016-02-08 20:16 ` Re: Artur Malabarba
0 siblings, 1 reply; 22+ messages in thread
From: Steve Purcell @ 2016-02-08 19:05 UTC (permalink / raw)
To: bruce.connor.am, emacs-devel
> On 9 Feb 2016, at 01:56, Artur Malabarba <bruce.connor.am@gmail.com> wrote:
> > - :prompt-regexp "^\\w*=[#>] "
> > + :prompt-regexp "^[[:alpha:]_]*=[#>] "
>
> One thing that comes to mind is that \\w and :alpha: are generally not the same thing. So \\(\\w\\|_\\) might be more appropriate.
>
Yes, possibly. And in fact :alnum: would be better than :alpha:, of course…
And since the rules for database names are probably much the same as for other SQL identifiers, there’s a chance \\s (symbol constituent) would work too.
^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <CAFkz2yroLhknptDnWyC9B1fbZKEwTCV-T0VttHQiwZoaAW-j6A@mail.gmail.com>]
* Re:
[not found] <CAFkz2yroLhknptDnWyC9B1fbZKEwTCV-T0VttHQiwZoaAW-j6A@mail.gmail.com>
@ 2012-12-20 8:36 ` Константин Куликов
0 siblings, 0 replies; 22+ messages in thread
From: Константин Куликов @ 2012-12-20 8:36 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2929 bytes --]
found how code it more correct:
No need to change anything in startup.el
Code for server.el will be:
(unless (or files commands)
(let ((type (type-of initial-buffer-choice)))
(cond
((eq 'string type) (find-file initial-buffer-choice))
((eq 'buffer type) (switch-to-buffer initial-buffer-choice
'norecord))
(t (switch-to-buffer (get-buffer-create "*scratch*")
'norecord)))))
So, someone who has write access to emacs, maybe add this change to trunk?
(if u see no bugs with this code of course =p)
2012/12/20 Константин Куликов <zxnotdead@gmail.com>
> I discribed my problem here:
> http://comments.gmane.org/gmane.emacs.help/88218 .
> short:
> > when you run 'emacsclient -c' the new frame created and window in that
> frame is switched to
> > *scratch* buffer or file with name that is set in
> `initial-buffer-choice'.
> So, I can set `initial-buffer-choice' in the `after-make-frame-functions'
> to switch to buffer other than *scratch* on frame creation, but can't set
> somehow to buffer without underlying file.
>
> I found place where this behaviour handled(server.el:1258):
>
> ;; If we were told only to open a new client, obey
> ;; `initial-buffer-choice' if it specifies a file.
> (unless (or files commands)
> (if (stringp initial-buffer-choice)
> (find-file initial-buffer-choice)
> (switch-to-buffer (get-buffer-create "*scratch*")
> 'norecord)))
>
> Changed it to this:
> (unless (or files commands)
> (typecase initial-buffer-choice
> (string (find-file initial-buffer-choice))
> (buffer (switch-to-buffer initial-buffer-choice 'norecord))
> (t (switch-to-buffer (get-buffer-create "*scratch*")
> 'norecord)))
>
> then emacsclient -c it create frame and after short time destroys it with
> error:
> "*ERROR*: Wrong type argument: stringp, #<buffer *scratch*>"
>
> ok. I grepped sources, find startup.el:2325 :
> (when initial-buffer-choice
> (cond ((eq initial-buffer-choice t)
> (switch-to-buffer (get-buffer-create "*scratch*")))
> ((stringp initial-buffer-choice)
> (find-file initial-buffer-choice))))
>
> replaced it to:
> (when initial-buffer-choice
> (typecase initial-buffer-choice
> (symbol (when (eq initial-buffer-choice t)
> (switch-to-buffer (get-buffer-create "*scratch*"))))
> (string (find-file initial-buffer-choice))
> (buffer (switch-to-buffer initial-buffer-choice))))
>
> But still get same error:
> "*ERROR*: Wrong type argument: stringp, #<buffer *scratch*>"
>
> Any suggestions?
>
>
[-- Attachment #2: Type: text/html, Size: 4048 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:
@ 2005-07-06 17:37 Ishok
0 siblings, 0 replies; 22+ messages in thread
From: Ishok @ 2005-07-06 17:37 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 1292 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:
@ 2005-03-20 5:29 info
0 siblings, 0 replies; 22+ messages in thread
From: info @ 2005-03-20 5:29 UTC (permalink / raw)
^[$B40A4L5NA3NDj!*!*!*^[(B
^[$B:#$^$G!"El5~8BDj$@$C$?%5%$%H$,^[(B
^[$B9%I>$K$D$-!"A49q3HBg!*!*:#$,%A%c%s%9$G$9!#^[(B
^[$B"(%3%3$KEPO?$7$F$k=w$N;R$OK\Ev$G$9!#^[(B
1.^[$B5U!{=u4uK>=w@-^[(B
2.^[$B#S#M4uK>=w@-^[(B
3.^[$B:#F|=P2q$$$?$$=w@-^[(B
4.^[$BITNQ4uK>=w@-^[(B
^[$B$J$I$N=w@-=P2q$$J|Bj^[(B
^[$BAa$/$7$J$$$H#S#O#L#D!!#O#U#T^[(B
http://loves.qsv20.com/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:..
@ 2005-01-06 12:16 Документ
0 siblings, 0 replies; 22+ messages in thread
From: Документ @ 2005-01-06 12:16 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 46 bytes --]
Посетите наш интернет магазин www.bdinfo.ru
[-- Attachment #1.1.2: Type: text/html, Size: 571 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:
@ 2004-11-26 21:10 Robbie Womack
0 siblings, 0 replies; 22+ messages in thread
From: Robbie Womack @ 2004-11-26 21:10 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 68 bytes --]
http://absolute.sentthemeasure.com/?a=679actual
Read more ...
[-- Attachment #1.1.2: Type: text/html, Size: 196 bytes --]
[-- Attachment #1.2: nzoqz.gif --]
[-- Type: image/gif, Size: 6012 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re:
@ 2004-10-10 18:45 John Gard
0 siblings, 0 replies; 22+ messages in thread
From: John Gard @ 2004-10-10 18:45 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/plain, Size: 1609 bytes --]
Dear,
Mail to: JOHNGARD@ACCOUNTANT.COM
I came across your email address through Internet search. I do not know you or have I done any business with you before but my instinct tells me to try and see if you will be interested in my proposition. I am also sending this email to other five people also from Internet search. I will choose one person from the five people I will email. That is if they are interested in my proposal.
My name is JOHN GARD. I have worked in a bank here in Europe name (withheld) for 15yrs. I happened to be an account officer to one Mr. (Name Withheld) who deposited a total amount of $15,000,000.00 in 1990. Mr. (Name Withheld) died two years ago in a car accident and have no next of kin to come and claim this money.
As his account officer I have every thing it takes to send this money to anybody that comes forward as his next of kin but since he does not have next of kin I am willing to make you his next of kin. I will give you 50% and I will keep 50% for my self. You do not need to come to the bank, all you need to do is follow my instructions and I will have the money wired to you in no time.
This Transaction is totally risk free and legal you should not exercise any atom of fear because I have taken care of every thing. Confidentiality and secrecy is highly needed. If you are interested you can contact me through the below email address. I will give you more information upon your acceptance to this proposal. Please include your direct phone number in your reply.
Sincerely
JOHN GARD
Email: JOHNGARD@ACCOUNTANT.COM
REPLY TO: JOHNGARD@ACCOUNTANT.COM
[-- Attachment #1.2: Type: text/html, Size: 2759 bytes --]
[-- Attachment #2: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2023-02-17 15:41 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-10 14:39 Abdulaim
-- strict thread matches above, loose matches on Subject: below --
2023-02-15 17:57 Make all tree-sitter modes optional Alan Mackenzie
2023-02-15 18:33 ` Eli Zaretskii
2023-02-17 13:30 ` Alan Mackenzie
2023-02-17 13:37 ` Po Lu
2023-02-17 13:46 ` Stefan Monnier
2023-02-17 14:16 ` Po Lu
2023-02-17 14:40 ` Eli Zaretskii
2023-02-17 14:56 ` Dmitry Gutov
2023-02-17 15:04 ` Eli Zaretskii
[not found] ` <8735741fic.fsf@dick>
2023-02-17 15:41 ` Alan Mackenzie
2021-12-20 2:29 (unknown) Davin Pearson
2021-12-21 14:29 ` Eli Zaretskii
[not found] ` <CAG9ihEvK5VVgP9O+TXYSz+BQF1=YzMgzGBbc5s-fewwT34yytA@mail.gmail.com>
[not found] ` <CAG9ihEsdD2Dd=paZatMfnD3HJxKsUM=3etTz7c-tDcs-H80PoA@mail.gmail.com>
[not found] ` <CAG9ihEsQFkx+uE+pZ7R42GXUFR_C2PSzVK8M5AQuHdtOsND0cg@mail.gmail.com>
[not found] ` <CAG9ihEv_OPaYhTgfh2WnfckC5r21U5Hv0qW7Msnwz4Bbvz6ccg@mail.gmail.com>
2021-12-28 17:51 ` Re: Eli Zaretskii
2021-12-28 23:41 ` Re: Davin Pearson
2021-12-31 15:23 ` Re: Anders Lindgren
2022-01-02 1:15 ` Re: Davin Pearson
2022-01-02 5:19 ` Re: Stefan Monnier
2022-01-03 0:53 ` Re: Davin Pearson
2021-12-02 14:09 Re: Angelo Graziosi
2021-11-04 6:36 Re: Pedro Andres Aranda Gutierrez
2017-10-24 18:52 wait_reading_process_ouput hangs in certain cases (w/ patches) Matthias Dahl
2017-11-14 16:03 ` Eli Zaretskii
2017-11-14 16:23 ` Eli Zaretskii
2017-11-14 21:54 ` Paul Eggert
2017-11-15 14:03 ` Matthias Dahl
2017-11-16 16:46 ` Paul Eggert
2017-11-18 14:24 ` Matthias Dahl
2017-11-19 7:07 ` Paul Eggert
2017-11-20 15:29 ` Matthias Dahl
2017-11-21 14:44 ` Matthias Dahl
2017-11-22 8:55 ` Paul Eggert
2017-12-04 9:40 ` Matthias Dahl
2018-02-13 14:25 ` Matthias Dahl
2018-02-16 16:01 ` Eli Zaretskii
2018-02-16 16:09 ` Lars Ingebrigtsen
2018-02-22 11:45 ` andres.ramirez
2018-02-26 14:39 ` Matthias Dahl
2018-02-26 15:11 ` andrés ramírez
2018-02-26 15:17 ` Lars Ingebrigtsen
2018-02-26 15:29 ` andrés ramírez
2018-02-26 16:52 ` Daniel Colascione
2018-02-26 17:19 ` andrés ramírez
2018-02-26 17:24 ` Daniel Colascione
2018-02-27 1:53 ` Re: andrés ramírez
2016-02-08 7:54 (unknown) steve
2016-02-08 12:56 ` Artur Malabarba
2016-02-08 19:05 ` Re: Steve Purcell
2016-02-08 20:16 ` Re: Artur Malabarba
[not found] <CAFkz2yroLhknptDnWyC9B1fbZKEwTCV-T0VttHQiwZoaAW-j6A@mail.gmail.com>
2012-12-20 8:36 ` Re: Константин Куликов
2005-07-06 17:37 Re: Ishok
2005-03-20 5:29 Re: info
2005-01-06 12:16 Re: Документ
2004-11-26 21:10 Re: Robbie Womack
2004-10-10 18:45 Re: John Gard
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).