unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Re:
@ 2021-12-02 14:09 Angelo Graziosi
  2021-12-02 14:21 ` msys2 build path problems + copy-paste english results in chinese characters Angelo Graziosi
  0 siblings, 1 reply; 23+ 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] 23+ 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; 23+ 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] 23+ messages in thread
* (unknown)
@ 2021-12-20  2:29 Davin Pearson
  2021-12-21 14:29 ` Eli Zaretskii
  0 siblings, 1 reply; 23+ 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] 23+ messages in thread
* Re:
@ 2021-11-04  6:36 Pedro Andres Aranda Gutierrez
  0 siblings, 0 replies; 23+ 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] 23+ 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; 23+ 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] 23+ messages in thread
* (unknown)
@ 2016-02-08  7:54 steve
  2016-02-08 12:56 ` Artur Malabarba
  0 siblings, 1 reply; 23+ 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] 23+ messages in thread
[parent not found: <CAFkz2yroLhknptDnWyC9B1fbZKEwTCV-T0VttHQiwZoaAW-j6A@mail.gmail.com>]
* Re:
@ 2005-09-10 14:39 Abdulaim
  0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* Re:
@ 2005-07-06 17:37 Ishok
  0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* Re:
@ 2005-03-20  5:29 info
  0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* Re:..
@ 2005-01-06 12:16 Документ
  0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* Re:
@ 2004-11-26 21:10 Robbie Womack
  0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* Re:
@ 2004-10-10 18:45 John Gard
  0 siblings, 0 replies; 23+ 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] 23+ messages in thread
end of thread, other threads:[~2023-02-17 15:41 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-02 14:09 Angelo Graziosi
2021-12-02 14:21 ` msys2 build path problems + copy-paste english results in chinese characters Angelo Graziosi
  -- 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-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-09-10 14:39 Re: Abdulaim
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).