* Re:
@ 2002-10-18 18:30 Josep Maria
0 siblings, 0 replies; 106+ messages in thread
From: Josep Maria @ 2002-10-18 18:30 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/plain, Size: 2108 bytes --]
Untitled Document
Problemas de seguridad de Outlook Express: sale otro parche.
La vulnerabilidad encontrada es bastante seria y permite a los hackers o bien bloquear el funcionamiento del programa, o lo que es peor, ejecutar un código cualquiera en la máquina..
Casio CW-100: nueva impresora térmica para discos CD/DVD.
¿Será la frecuencia funcional recomendada del NV30 igual a 400 MHz?
Sistema acústico SP 53 de 5.1 canales de ABIT: especificaciones y precios.
Los paleontólogos por primera vez obtienen una momia de un dinosaurio en condiciones óptimas.
El cadaver momificado del dinosaurio, que estuvo enterrado debajo de la tierra durante 77 millones de años, fue encontrado al norte del estado de Montana, nos cuenta Nationalgeografic.com. El hallazgo lo llamaron Leonardo en honor a un graffiti pintado cerca (Leonard Webb and Geneva Jordan, 1917). Leonardo es un dinosaurio ...
A los pobladores de Alaska les aterroriza un pterodáctilo gigante.
El tratamiento genético contra la calvicie hará que el pelo brille con colores amarillo, verde, azul o rojo.
La estación espacial sigue en obras.
Mecano Lego: estructuras en cuatro dimensiones.
Hay gente que afirma ser constructores profesionales de mecano. Estas afirmaciones afectan sobre todo los famoso mecanos Lego. Asimismo, un hombre llamado Andrew Lipson afirma ser el professional nerd. De su arte vamos a hablar hoy...
Clonacion humana es imposible, pero inevitable.
Hoy en dia, cuando ya se sabe que ir y hacer un ejercito de clones - casihumanos idénticos - es imposible, la situación de la clonación humana es precaria. No podemos esperar nada sensacional, pero...
www.xtio.com
[-- Attachment #1.2: Type: text/html, Size: 12416 bytes --]
[-- Attachment #2: zero.gif --]
[-- Type: image/gif, Size: 43 bytes --]
[-- Attachment #3: enov.gif --]
[-- Type: image/gif, Size: 1120 bytes --]
[-- Attachment #4: xnov.gif --]
[-- Type: image/gif, Size: 1181 bytes --]
[-- Attachment #5: 3605.jpg --]
[-- Type: image/jpeg, Size: 3131 bytes --]
[-- Attachment #6: verccompl4.gif --]
[-- Type: image/gif, Size: 857 bytes --]
[-- Attachment #7: ball.gif --]
[-- Type: image/gif, Size: 145 bytes --]
[-- Attachment #8: 3589.jpg --]
[-- Type: image/jpeg, Size: 2082 bytes --]
[-- Attachment #9: clocas.gif --]
[-- Type: image/gif, Size: 388 bytes --]
[-- Attachment #10: cienciad.gif --]
[-- Type: image/gif, Size: 445 bytes --]
[-- Attachment #11: 3386.jpg --]
[-- Type: image/jpeg, Size: 4118 bytes --]
[-- Attachment #12: 3316.jpg --]
[-- Type: image/jpeg, Size: 2631 bytes --]
^ permalink raw reply [flat|nested] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ messages in thread
* (no subject)
@ 2022-01-20 14:13 Roger Mason
2022-01-20 19:57 ` Immanuel Litzroth
0 siblings, 1 reply; 106+ messages in thread
From: Roger Mason @ 2022-01-20 14:13 UTC (permalink / raw)
To: Org Mode Mailing List
Hello,
I want to run stack ghci from haskell blocks in org-mode. For the
task at I need to start ghci with command line option
-XFlexibleContexts. I have this in my org-mode buffer:
#+begin_src emacs-lisp :results none
(setq haskell-process-type 'stack-ghci)
(setq haskell-process-args-stack-ghci (list "--ghci-options -XFlexibleContexts"))
#+end_src
but I get
Process haskell exited abnormally with code 1
Invalid option `--ghci-options -XFlexibleContexts'
in the inferior haskell buffer.
Does anyone know how to do what I want?
Thanks,
Roger
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
2022-01-20 14:13 Roger Mason
@ 2022-01-20 19:57 ` Immanuel Litzroth
2022-01-20 19:58 ` Re: Roger Mason
0 siblings, 1 reply; 106+ messages in thread
From: Immanuel Litzroth @ 2022-01-20 19:57 UTC (permalink / raw)
To: Roger Mason; +Cc: Org Mode Mailing List
Just going by what I see, not having tried it:
(setq haskell-process-args-stack-ghci (list "--ghci-options"
"-XFlexibleContexts"))
In your version the process gets 1 argument (with a space in it). In
my version it gets 2 args.
Immanuel
On Thu, Jan 20, 2022 at 8:22 PM Roger Mason <rmason@mun.ca> wrote:
>
> Hello,
>
> I want to run stack ghci from haskell blocks in org-mode. For the
> task at I need to start ghci with command line option
> -XFlexibleContexts. I have this in my org-mode buffer:
>
> #+begin_src emacs-lisp :results none
> (setq haskell-process-type 'stack-ghci)
> (setq haskell-process-args-stack-ghci (list "--ghci-options -XFlexibleContexts"))
> #+end_src
>
> but I get
>
> Process haskell exited abnormally with code 1
> Invalid option `--ghci-options -XFlexibleContexts'
>
> in the inferior haskell buffer.
>
> Does anyone know how to do what I want?
>
> Thanks,
> Roger
>
--
-- A man must either resolve to point out nothing new or to become a
slave to defend it. -- Sir Isaac Newton
^ permalink raw reply [flat|nested] 106+ messages in thread
* (unknown)
@ 2021-12-20 2:29 Davin Pearson
2021-12-21 14:29 ` Eli Zaretskii
0 siblings, 1 reply; 106+ 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] 106+ 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; 106+ 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] 106+ messages in thread
* Re:
@ 2021-12-02 14:09 Angelo Graziosi
0 siblings, 0 replies; 106+ 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] 106+ messages in thread* Re:
@ 2021-11-04 6:36 Pedro Andres Aranda Gutierrez
0 siblings, 0 replies; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ messages in thread
* Re:
2018-02-26 17:24 ` Daniel Colascione
@ 2018-02-27 1:53 ` andrés ramírez
0 siblings, 0 replies; 106+ 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] 106+ messages in thread
* (unknown)
@ 2016-02-08 7:54 steve
2016-02-08 12:56 ` Artur Malabarba
0 siblings, 1 reply; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ 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; 106+ 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] 106+ messages in thread
* Re:
@ 2008-08-06 15:50 Michaël Parienti
2008-08-06 16:57 ` Re: Paul R
0 siblings, 1 reply; 106+ messages in thread
From: Michaël Parienti @ 2008-08-06 15:50 UTC (permalink / raw)
To: Paul R; +Cc: emacs-orgmode
Le mer 06/08/08 09:37, Paul R paul.r.ml@gmail.com a écrit:
> Hi Michaël,
>
> On Mon, 4 Aug 2008 14:21:00 +0200, Michaël Parienti <michael
> @parienti.name> said:
> Michaël> Hi,
>
> Michaël> After upgrading to orgmode version 6.05 (with an aptitude
> Michaël> dist-upgrade under a debian sid system), and changing my
> Michaël> configuration file to resolve the problem described here:
> Michaël> http://www.mail-archive.com/emacs-o
>
> rgmode@gnu.org/msg07167.html,
Michaël> I still have a problem when I type C-ca. I get the
> following
Michaël> error message:
>
> Michaël> "Autoloading failed to define function org-agenda"
I uninstall one of my emacs version (the snapshot one) and keep
just the 22.2.1 version. I reinstall the org-mode package from
debian repository.
I am sure that I have only one version of the org-mode files
availables for emacs: I manually deleted source directory
(*..el files) and the *.elc files compiled for snapshot version
of emacs.
Here is the content of my load-path variable:
("/usr/share/emacs22/site-lisp/python-mode"
"/usr/share/emacs22/site-lisp/pymacs"
"/usr/share/emacs22/site-lisp/pymacs"
"/usr/share/emacs22/site-lisp/org-mode"
"/usr/share/emacs22/site-lisp/css-mode"
"/usr/share/emacs/site-lisp/css-mode"
"/usr/share/emacs22/site-lisp/a2ps"
"/usr/share/emacs22/site-lisp/wl"
"/usr/share/emacs22/site-lisp/semi"
"/usr/share/emacs22/site-lisp/w3m"
"/usr/share/emacs22/site-lisp/w3m/shimbun"
"/usr/share/emacs22/site-lisp/html-helper-mode" ...) available
in *Message* buffer. It seems troncated, but I don't know how to
get it complety.
--
Michaël Parienti
^ permalink raw reply [flat|nested] 106+ messages in thread* Re:
2008-08-06 15:50 Re: Michaël Parienti
@ 2008-08-06 16:57 ` Paul R
0 siblings, 0 replies; 106+ messages in thread
From: Paul R @ 2008-08-06 16:57 UTC (permalink / raw)
To: michael; +Cc: emacs-orgmode
On Wed, 6 Aug 2008 17:50:38 +0200, " Michaël Parienti" <michael@parienti.name> said:
Michaël> I uninstall one of my emacs version (the snapshot one) and
Michaël> keep just the 22.2.1 version. I reinstall the org-mode
Michaël> package from debian repository.
Michaël> I am sure that I have only one version of the org-mode files
Michaël> availables for emacs: I manually deleted source directory
Michaël> (*..el files) and the *.elc files compiled for snapshot
Michaël> version of emacs.
What happens if you (require 'org-install) before first call to org ?
If it works straight, then you may need to find where your default org
autoloads are defined. If it does not work, then you may need to
rebuild the org-install file. To do so, on debian, get your package
sources and run the build process. org-install.el is generated during
this process IIRC. Finally, depending on your conclusions, you can
write an email to the package maintainer to inform him that something
is wrong in its org package.
--
Paul
^ permalink raw reply [flat|nested] 106+ messages in thread
* (unknown)
@ 2007-04-04 19:09 Jost Burkardt
2007-04-05 0:26 ` Jason F. McBrayer
0 siblings, 1 reply; 106+ messages in thread
From: Jost Burkardt @ 2007-04-04 19:09 UTC (permalink / raw)
To: emacs-orgmode
Hi,
I really love the integration of remember with org, especially the way
how to insert the notes by moving within the headings-tree.
Is it possible to use this feature also for moving portions of text
via regular copy/paste an org-buffer, and have org automatically adapt
the header levels? I didn't find anything in the manual.
One possible workaround for me is to use remember-clipboard, which has
the drawback, that the clipboard's content is indented, so I always
have to remove the indentation by hand.
What do you think?
Jost
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
2007-04-04 19:09 (unknown) Jost Burkardt
@ 2007-04-05 0:26 ` Jason F. McBrayer
0 siblings, 0 replies; 106+ messages in thread
From: Jason F. McBrayer @ 2007-04-05 0:26 UTC (permalink / raw)
To: Jost Burkardt; +Cc: emacs-orgmode
Jost Burkardt <jost.burkardt@web.de> writes:
> I really love the integration of remember with org, especially the way
> how to insert the notes by moving within the headings-tree.
>
> Is it possible to use this feature also for moving portions of text
> via regular copy/paste an org-buffer, and have org automatically adapt
> the header levels? I didn't find anything in the manual.
C-c C-x C-w will cut a subtree, which you can paste with C-c C-x C-y,
and it will automatically adapt the header levels. You can navigate
to where you want to insert it with C-c C-j, which works a lot like
selecting your place with org-remember.
--
+-----------------------------------------------------------+
| Jason F. McBrayer jmcbray@carcosa.net |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors. --- The Dhammapada |
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-12-03 23:03 solenoids
0 siblings, 0 replies; 106+ messages in thread
From: solenoids @ 2005-12-03 23:03 UTC (permalink / raw)
From: The Desk of Mr.Peter Chang [Director]
Solenoids Industrial Co.Ltd.
55,An Suing East 9th Street,
Taichung, Taiwan.
Tel: 886-9162278842
Email:
Dear Sir/Madam,
Solenoids Industrial Co. Ltd are exporters based in Taiwan. We export raw materials,such as Calcite,Barytes, Manganese Dioxide , Dolomite, Mica , China Clay, Mangnese Dioxide, Ferrous(Iron) Oxide, Paints, Rubber,Plastics, Construction chemicals, etc. We export from Asia into Europe, America and Australia.
Due to expansion, We would like to employ foreign services to work with us as our payment agent that will help in establishing a medium of recieving and disbursing payments on our behalf for goods and raw materials supplied to our customers in Europe, America or Australia. Please note that all neccesarry information required for establishing a convenient business working environment will be communicated to you once a business relationship is established between us.
Should you be interested in dealing with us as one of our foreign representatives, please communicate to us through the email provided below.
step01ca@email.com
Subject to your satisfaction you will be given the opportunity to negotiate your the mode of which we will pay for your services as our representative in either of these locations. Please be sure to include your phone/fax number and your full contact address.
Thank you as we await your urgent response.
Regards ,
Mr.Peter Chang,
[Director]
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-09-27 14:03 avtologistic
0 siblings, 0 replies; 106+ messages in thread
From: avtologistic @ 2005-09-27 14:03 UTC (permalink / raw)
============================================================
Автомобильные грузоперевозки по России.
Имея собственный парк автотранспорта
от 15 куб. м до 120 куб.м, грузоподъемностью от 2 до 22 тонн,
квалифицированные менеджеры позволят минимизировать расходы
по доставке Вашего груза.
тел.(095) 920-1582, 8 - 916-119-06 05, avtologistic@postmaster.co.uk
============================================================
Автомобильные грузоперевозки от компании "Автологистик"
- это гарантия надежной доставки Ваших грузов.
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-09-18 14:11 Art
0 siblings, 0 replies; 106+ messages in thread
From: Art @ 2005-09-18 14:11 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 862 bytes --]
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-09-10 14:39 Abdulaim
0 siblings, 0 replies; 106+ 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] 106+ messages in thread
* Re:
@ 2005-08-29 20:51 Alifgin
0 siblings, 0 replies; 106+ messages in thread
From: Alifgin @ 2005-08-29 20:51 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 1223 bytes --]
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-08-11 16:17 от Александр
0 siblings, 0 replies; 106+ messages in thread
From: от Александр @ 2005-08-11 16:17 UTC (permalink / raw)
Строительная компания ООО "КРИЭЙТ" выполняет:
Строительство коттеджей и домов из любого материала а также сопутствующих построек беседок, бань и.т.д.
Ремонтные работы любой сложности квартир и офисов. Инженерные сети и коммуникации (водоснабжение, отопление, вентиляция и электромонтажные работы).
Изготовление и установка под заказ клиента окон и дверей из трехслойного клееного бруса и пластика.
Заключение договора. Поэтапная оплата. Гарантия на работу.
Лицензия : Д 575244
тел: (095) 743-64-94
514-31-49
514-31-73
Изготавливаем и устанавливаем деревянные евро-окна, лоджии и двери под заказ
тел: (095) 514-31-49, 8-926-580-76-34.
^ permalink raw reply [flat|nested] 106+ messages in thread* Re:
@ 2005-07-06 17:37 Ishok
0 siblings, 0 replies; 106+ 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] 106+ messages in thread
* Re:
@ 2005-07-05 23:11 Maxus
0 siblings, 0 replies; 106+ messages in thread
From: Maxus @ 2005-07-05 23:11 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 132 bytes --]
a distraction from the holiness of Man, casting its doubt upon
formative experience of my life, I tell thee, and it would do
[-- Attachment #1.1.2: Type: text/html, Size: 542 bytes --]
[-- Attachment #1.2: hbdstc.gif --]
[-- Type: image/gif, Size: 5622 bytes --]
^ permalink raw reply [flat|nested] 106+ messages in thread
* re:
@ 2005-06-30 18:50 Alex Claire
0 siblings, 0 replies; 106+ messages in thread
From: Alex Claire @ 2005-06-30 18:50 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 2411 bytes --]
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-06-14 23:56 Вера
0 siblings, 0 replies; 106+ messages in thread
From: Вера @ 2005-06-14 23:56 UTC (permalink / raw)
Была на выставке Эрос-2005. Видела потрясающий товарчик. Держи
ссылку на www.RusGal.ru Не пожалеешь!
"Иногдамыловимсебянатом,чтоменяемнашимнениябезвсякого
Внастоящеевремясуществуетпятьосновныхспособовподсоединенияк
обрадовавшись этому всему -- живому, яркому и бедному, что двигалось, дышало
выдержит и отменит свое приказание.
--Обождиздесь,--сказал,соскакиваяназемлюизабрасываяповодна
бугре неясно заплясали четыре конные фигуры. Левинсон свернул в кусты и
Ейудалосьподнятьегонаноги,итак,увещеваяегоиотвлекаяот
ИринаЦарик
Таким образом, все химические, геохимические и геологические данные с несомненностью свидетельствуют об органическом происхождении нефти.
и бессмысленно исполняли бы то дело, какое угодно было Колчаку? Но это же
сделанного за неделю. После обеда я ухожу к себе, открываю свою книгу и
СН3–(СН2)6–СН2:СН2–(СН2)6–СН3t
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-06-13 21:36 Карина
0 siblings, 0 replies; 106+ messages in thread
From: Карина @ 2005-06-13 21:36 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 1313 bytes --]
Подари себе новые ощущения,
находясь в отремонтированной квартире.
Мы можем сделать ремонт и в одной комнате. Можем сделать Вам студию,
объединив кухню и зал. Молодые и прогрессивные дизайнеры нашей небольшой
фирмы, подскажут и воплотят в реальность Ваши желания, создадут уют, который
будет гарантировать Вам приятный отдых, находясь дома.
Мы подскажем как разделить зону отдыха от зоны, где приходится делать
уроки, подберем Вам недорогие, но очень стильные предметы интерьера. Подбор
мебели тоже входит в наши возможности. Попробуем сделать все в максимально
сжатые сроки. Стоимость работ - средняя цена по Москве. Гарантия 18 месяцев.
тел. 8-926-536-38-57
Благоустройство территорий:
- асфальтировка – 300 руб.\кв.м
- парковка с основанием – 1400 руб.
- озеленение – от 7 до 10 см. – 150 руб. (чернозем)
- бордюры дорожные – 600 руб.\1 шт.
- тротуарная брусчатка – 700 руб.\кв.м.
Цены регулируются в зависимости от объема работ.
тел. 8-926-536-38-57
своего маленького сына. Мальчик был худосочный и отказывался есть сам.
"Какугадал",--подумалМетелица,вспомнивсвоипредположения.
президенту, он сказал, как говорят все президенты, что не будет возражать
от работы, если бы не считал, что дело это общее, затронуты обе стороны,
а
[-- Attachment #1.1.2: Type: text/html, Size: 3369 bytes --]
^ permalink raw reply [flat|nested] 106+ messages in thread* Re:
@ 2005-06-06 10:27 Нина
0 siblings, 0 replies; 106+ messages in thread
From: Нина @ 2005-06-06 10:27 UTC (permalink / raw)
# ВCE СD-ДИCKИ - HOBИНКИ #
# HE TPEБУЮT ИHCTAЛЛЯЦИИ И 3AПУCKAЮТCЯ HEПOСРЕДCTBEHHO С КОMПАКT-ДИCКA #
* CD 1 ВCE ГOPOДА РOCСИИ 2OO5 (l2O гopoдов) ! NEW !
Koллeкция вeктopных элeктpoнных кapт нa l2O гoрoдa Poссии (cтoлицы cубъeктов Фeдepaции, кpупныe гоpодa): Mоcквa, Caнкт-Пeтepбург, Hижний Hoвгорoд, Eкатepинбург, Kpаснояpск, Caмарa, Oмcк, Hoвосибиpcк, Kpаснoдар, Bладивocток, Xабаpовcк и дp. + (пoиск, рeдактоp)
* CD 2 БOЛЬШOЙ АTЛАC РOCСИИ 2OO5 ! NEW !
Kаpты Рoccии и CHГ - aдминиcтрaтивнo-пoлитичecкая (фeдeрaльныe окpугa, cубъeкты Фeдeрaции), гeoграфичecкая (публикyeтся впеpвыe) сo cпpавочникoм бoлеe l2O тыc. нacеленныx пyнктoв, жeлeзнодoрoжная и бoтaническaя. + (пoиск, редaктoр)
* CD 3 ЖEЛТЫE СTPАHИЦЫ МОCKBЫ + ПOДРОБНAЯ КAPТА МОCКBЫ
Coдeржитcя 200 OOO eдиниц инфopмaции o фиpмаx и оpганизaциях Moсквы и Мocковской oблаcти. Инфоpмациoнный блoк пo кaждoмy пpeдприятию включaeт ИHДЕКC, АДPEC, TЕЛЕФОH и т.д.
* CD 4 ВСE OТEЛИ PОСCИИ и ближнeгo зapубежья 2OO5 ! NEW !
Инфоpмaция o 283O отeляx в бoлеe 48O гoрoдаx Рoсcии и ближнeго заpубeжья. А тaкжe KEМПИНГИ, ПAНСИOHAТЫ, MOТEЛИ, TУPИСТИЧЕСКИE БA3Ы ОTДЫXА, СAHAТОPИИ.
* CD 5 АTЛАC АBTОМOБИЛЬHЫХ ДОPОГ 2005 ! NEW !
Hoвая пpoграммa с yлyчшеннoй гpaфикoй и peдактоpoм пoльзовaтельскoго слoя c вoзможнoстью пpoкладки мapшрутoв пo aвтoдорoгaм вплoть дo гpyнтовыx пo вceй тepритopии стpaны. + (пoиск, рeдaктоp, мapшрутизaтор, пoддержкa GРS)
* CD 6 КAРТA МИPA 2005 ! NEW !
Coвремeннaя пoлитичecкая каpтa миpa в видe глoбуca, a тaкжe кoллeкция из 47 каpт инocтранныx гоcyдарств, интepeсныx для тypизма, мacштабa 1:300 OOO - 1:4 OOO 000. Кapты кpyпных гoрoдoв миpa (Лoндoн, Пapиж, Бepлин и дp.) + (пoиск, pедактoр).
Цeнa oднoгo диcкa 25O рyблeй.
Пpи зaкaзe вcеx диcкoв oбщaя цeнa - 1OOO pублeй.
Вce пoдрoбноcти oплaты и пoлyчeния диcкoв:
SOWA @ GAWAB . COM (ввoдить 6eз пpoбелoв)
сомнения. И вот, чтобы дать почувствоватьсвою значительность и
признался мне,кчто y него нет опыта сортировки белой сосны. Он стал
--Амнеидежпритулиться?--плаксивозагнусилхромой.--Ичтоже
nидентификаторпользователя
Полностью совместимы с кабельными сетями. Электротехнические параметры,
превратился в желе, как следует нарезать его ломтиками, чтобы потом делать
ИменнотакимприемомпользуетсяЛоуэлиТомас,иповерьтемнеон
Сборнефтисповерхностиводоемов–это,очевидно,первыйповременипоявленияспособдобычи,которыйдонашейэрыприменялсявМидии,ВавилониииСирии.СборнефтивРоссии,споверхностирекиУхтыначатФ.С.Прядуновымв1745г.В1858на
троне. Верно, она была красивейшей женщиной мира. ho ни королевство, ни
тайны, приносящей успех в деловых контактах... Исключительно внимание к
темно-зеленая, поросшая ряской, поверхность вздувалась упругими волнами,
ушей новое замечание взводного. Увидев, однако, что тот собирается
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-05-10 17:54 Mariorisa
0 siblings, 0 replies; 106+ messages in thread
From: Mariorisa @ 2005-05-10 17:54 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 952 bytes --]
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-05-04 17:05 info
0 siblings, 0 replies; 106+ messages in thread
From: info @ 2005-05-04 17:05 UTC (permalink / raw)
...............тел. (905) 2039072................
...............тел. (095) 1363041................
.................ася 292593973...................
..................сайт 8811.ws...................
Вы заинтересованы в увеличении количества клиентов?
Обращаем Ваше внимание на то, что наша компания помогает решать
подобные задачи стоящие перед Вашим бизнесом.
Способ решения ваших проблем – электронные письма в сети Интернет!
........................................................
... Просто, легко, практично, конкретно, быстро! ...
БОРИСОВНЫ БЫВШЕЙ, Аркадий
Английские, Аомыне Академсеть
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-04-21 7:57 webmaster
0 siblings, 0 replies; 106+ messages in thread
From: webmaster @ 2005-04-21 7:57 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 1152 bytes --]
Кoмпания "СУШИМАРКЕТ" - мы дoставляем удoвольствие
(O95) 225-25-ЗЗ
Бесплатная дoставка блюд Японской кухни на дом и в офис!
Толькo самая свежая рыба и лучший рис!
ВЕСЕННЯЯ АКЦИЯ oт компании СУШИМАРКЕТ
До З1 мая - к каждoму заказу в ПОДАРОК РОЛЛ КАЛИФОРНИЯ!
ВСТРЕТИМ ВЕСНУ ВМЕСТЕ!
Суши:
• лосoсь – 4О.-
• тунец – 65.-
• угорь – 6O.-
• краб – 60.-
• Муки Эби (коктеильная креветка, икра летучей рыбы, авoкадo, спайс соус) – 70.-
• Тoри Унаги (угoрь, курица, спайс соус) – 6O.-
• «Do» - (яйцо, красная икра, майонез) – 5О.-
Роллы:
• Нара Маки – лосось, краб, латук, майонез. – 20O.-
• Филадельфия – угорь, спаржа, сыр Филадельфия, икра летучей рыбы. – 22О.-
• Спайс ролл «Бравo» - Краб, лосось, спайс соус. – 22О.-
• Марчибo (лoсось, угорь, сыр, авокадo, огурец, латук) – I4O.-
• «СушиДо» креветка в кляре, огурец, латук, икра летучей рыбы 290.-
• Омлет с угрем – I0O.-
Гoрячее:
• Пельмени с креветками – I80.-
• Плoв с мoрепродуктами – 160.-
• Мисo суп – 7O.-
• Суимонo суп – 90.-
А также: Сашими, Салаты, Напитки, Чай и Вoлшебные ассорти.
Оценить качествo нашей прoдукции Вы также мoжете в рестoране «Япoнский Пейзаж»
пo адресу Ленинский пр-т l46.
[-- Attachment #1.1.2: Type: text/html, Size: 2911 bytes --]
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-03-28 15:10 info
0 siblings, 0 replies; 106+ messages in thread
From: info @ 2005-03-28 15:10 UTC (permalink / raw)
:::. Оптовая рaспродaжa aксессуaров для сотовых телефонов! .:::
!!! супер низкие цены !!!
Зaрядные устройства (сетевые и автомобильные), корпуса, шнурки, брелки,
чехлы из нaтуральной кожи, силиконовые и др.
+-- Тел. 8(O95) 68З-49-44 --+
+-- Тел/Фaк: 8(O95) 188-89-46 --+
+-- E-mail: igorkurilov@gawab.com --+
^ permalink raw reply [flat|nested] 106+ messages in thread* Re:
@ 2005-03-20 5:29 info
0 siblings, 0 replies; 106+ 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] 106+ messages in thread* (no subject)
@ 2005-03-08 14:48 Gian Uberto Lauri
2005-03-08 21:02 ` Peter Dyballa
0 siblings, 1 reply; 106+ messages in thread
From: Gian Uberto Lauri @ 2005-03-08 14:48 UTC (permalink / raw)
Cc: help-gnu-emacs
Sorry if this breaks the threading...
>>>>> "UH" == Ulrich Hobelmann <u.hobelmann@web.de> writes:
UH> Thanks! That solves the display problem.
UH> Emacs doesn't work with the Mac input method, though (alt-s doesn't do
UH> ß, but §). I suspect the Alt key is mapped for something...
Using the Emacs Input Method (I prefer this since I use Emacs in 3
differnt OS) solves the problem. You can choose between german prefix
where ß is the result of the sequence " and s (prefix version work
somethin like iso-accents-mode, so wovels with umlauts are entered
with the sequence " (wovel)) and german postfix where you get the same
result by hitting s and then z. In this mode wovels with umlauts are
entered typing what I think is the "no umlaut version" of the word (I
don't speak German -blame on me- so I'm not sure...).
>> Hmmm... I think thak the use of mac roman is in second place for
>> deserving a rightful spanking (for Apple developers) after the
>> implementation of cp, mv and so on ... :)
>>
UH> What's wrong with cp, mv ...?
UH> Aren't they just from FreeBSD?
The commands do come from BSD or GNU. But the filesystem not, and
those smarties did not adapt the commands to the filesystem.
So if you cp a file you cp just the data losing the extended
attributes. mv should behave likewise too. There are a couple of
utilities that fix this in the development stuff. I never used them as
I use my iMac as a Unix box and I don't care of the other file forks
(btw does someone know a free utility to repartition the disk to make
place to an healy Debian GNU/Linux ?).
--
/\ ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
//--\| | \| | Integralista GNUslamico
\/ e coltivatore diretto di Software
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
2005-03-08 14:48 (no subject) Gian Uberto Lauri
@ 2005-03-08 21:02 ` Peter Dyballa
2005-03-08 21:14 ` Re: Gian Uberto Lauri
2005-03-08 21:24 ` Re: Gian Uberto Lauri
0 siblings, 2 replies; 106+ messages in thread
From: Peter Dyballa @ 2005-03-08 21:02 UTC (permalink / raw)
Cc: help-gnu-emacs, Ulrich Hobelmann
Am 08.03.2005 um 15:48 schrieb Gian Uberto Lauri:
> (btw does someone know a free utility to repartition the disk to make
> place to an healy Debian GNU/Linux ?).
When you boot into Debian you're offered to repartition any Mac volume
-- that's presumingly not that what you want? If so you could try to
boot into OpenBSD or NetBSD. I think both have a tool to manipulate the
partition table, change the type of partitions ...
Have you checked tucows? (http://mac.tucows.com/) Is Apple's pdisk not
enough?
--
Greetings
Pete
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
2005-03-08 21:02 ` Peter Dyballa
@ 2005-03-08 21:14 ` Gian Uberto Lauri
2005-03-08 21:24 ` Re: Gian Uberto Lauri
1 sibling, 0 replies; 106+ messages in thread
From: Gian Uberto Lauri @ 2005-03-08 21:14 UTC (permalink / raw)
Cc: help-gnu-emacs
>>>>> "PD" == Peter Dyballa <Peter_Dyballa@Web.DE> writes:
PD> Am 08.03.2005 um 15:48 schrieb Gian Uberto Lauri:
>> (btw does someone know a free utility to repartition the disk to
>> make place to an healy Debian GNU/Linux ?).
PD> When you boot into Debian you're offered to repartition any Mac
PD> volume -- that's presumingly not that what you want? If so you
PD> could try to boot into OpenBSD or NetBSD. I think both have a tool
PD> to manipulate the partition table, change the type of partitions
PD> ...
I badly worded my sentence. What I need is something to shrink Mac OS
X partition.
PD> Have you checked tucows? (http://mac.tucows.com/) Is Apple's pdisk
PD> not enough?
Goig to check.
--
/\ ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
//--\ | | \| | Integralista GNUslamico
\/ e coltivatore diretto di software
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
2005-03-08 21:02 ` Peter Dyballa
2005-03-08 21:14 ` Re: Gian Uberto Lauri
@ 2005-03-08 21:24 ` Gian Uberto Lauri
1 sibling, 0 replies; 106+ messages in thread
From: Gian Uberto Lauri @ 2005-03-08 21:24 UTC (permalink / raw)
Cc: help-gnu-emacs
>>>>> "PD" == Peter Dyballa <Peter_Dyballa@Web.DE> writes:
PD> Am 08.03.2005 um 15:48 schrieb Gian Uberto Lauri:
>> (btw does someone know a free utility to repartition the disk to
>> make place to an healy Debian GNU/Linux ?).
PD> When you boot into Debian you're offered to repartition any Mac
PD> volume -- that's presumingly not that what you want? If so you
PD> could try to boot into OpenBSD or NetBSD. I think both have a tool
PD> to manipulate the partition table, change the type of partitions
PD> ...
I badly worded my sentence. What I need is something to shrink Mac OS
X partition.
PD> Have you checked tucows? (http://mac.tucows.com/) Is Apple's pdisk
PD> not enough?
It seems that they don't have what I need. (BTW, it was free as in freedom :))
--
/\ ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
//--\ | | \| | Integralista GNUslamico
\/ e coltivatore diretto di software
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-03-03 8:38 support
0 siblings, 0 replies; 106+ messages in thread
From: support @ 2005-03-03 8:38 UTC (permalink / raw)
Электронные рассылки - это,
прежде всего донесение рекламы до высокодоходной,
активной, инновационной части целевой аудитории.
Заинтересовало?
+7 905_203_90_72
+7 905_144_53_18
http://8811.ws
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-03-02 5:19 PEREEZDI
0 siblings, 0 replies; 106+ messages in thread
From: PEREEZDI @ 2005-03-02 5:19 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/plain, Size: 607 bytes --]
ПЕРЕЕЗД-НАША ПРОФЕССИЯ
стаж 10 лет
Абсолютно любые переезды:
квартирные, офисные, дачные
перевозка: Антикварные, хрупкие предметы, станки, пианино, сейфы, производственое оборудование (собственная спецтехника, стропольщики), нестандартные заказы и т.д.
Собственный автопарк (при заказе с грузчиками) :
ГАЗЕЛЬ (12м3, оборудована под мебель, паралон, картон, ремни) - 160 р/ч
ЗИЛ (28м3, оборудована под мебель, паралон, картон, ремни) - 250 р/ч
т. (095) 728-16-04 т/ф (095) 778-51-09
gruzpereezd@netscape.net
[-- Attachment #1.2: Type: text/html, Size: 2576 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread* Re:
@ 2005-02-17 3:39 root
0 siblings, 0 replies; 106+ messages in thread
From: root @ 2005-02-17 3:39 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
Добрый день!
Вы решили увеличить количество клиентов со следующего месяца?
Или хотите прорекламировать новую услугу или продукт Вашей компании?
И не знаете как это можно сделать качественно, быстро и не дорого?
Тогда рассылки по электронной почте идеальный для Вас выбор!
www.8811.ws
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-01-28 21:22 Budget
0 siblings, 0 replies; 106+ messages in thread
From: Budget @ 2005-01-28 21:22 UTC (permalink / raw)
[-- Attachment #1: Type: text/HTML, Size: 16721 bytes --]
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1251">
<STYLE type=text/css media=screen>BODY {
BACKGROUND: #e0e0e0; COLOR: #000000; FONT-FAMILY: Verdana, Geneva, Arial, Helvetica, sans-serif; TEXT-DECORATION: none
}
</STYLE>
<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#e0e0e0>
<TABLE borderColor=#3e5a27 cellSpacing=0 cellPadding=0 width="98%" align=center
border=1>
<TBODY>
<TR>
<TD bgColor=#3e5a27 height=70>
<DIV align=center><FONT face="Verdana, Arial, Helvetica, sans-serif"
size=4><B><FONT color=#e0e310><BR></FONT><FONT
face="Verdana, Arial, Helvetica, sans-serif" size=4><B><FONT
color=#e0e310><B><FONT face="Verdana, Arial, Helvetica, sans-serif"
size=2>Бизн<ao>ес Ц<ao>ентр</FONT></B><BR>«Н<ao>АЦИ<ao><ao>ОН<ao>АЛЬНЫЙ»</FONT></B></FONT><FONT
color=#e0e310><B><FONT face="Verdana, Arial, Helvetica, sans-serif"
size=2></FONT></B></FONT></B></FONT><FONT color=#e0e310><B><FONT
face="Verdana, Arial, Helvetica, sans-serif" size=2><BR><BR><FONT
color=#ffffff>Пригл<ao><ao>аш<ao><ao>а<ao>ет В<ao><ao>ас н<ao><ao>а С<ao>емин<ao><ao>ар
:<BR><BR></FONT></FONT></B></FONT></DIV></TD></TR>
<TR>
<TD bgColor=#3e5a27 height=72>
<DIV align=center>
<P><FONT size=3><FONT
face="Verdana, Arial, Helvetica, sans-serif"><B><I><FONT color=#ffffff
size=4>БЮДЖ<ao>ЕТИР<ao><ao>ОВ<ao>АНИ<ao>Е К<ao>АК С<ao><ao>ОВР<ao>ЕМ<ao>ЕНН<ao>АЯ Т<ao>ЕХН<ao><ao>ОЛ<ao><ao>ОГИЯ <ao>УПР<ao>АВЛ<ao>ЕНИЯ К<ao><ao>ОМП<ao>АНИ<ao>ЕЙ.
М<ao>ЕТ<ao><ao>ОДИК<ao>А И ПР<ao>АКТИЧ<ao>ЕСКИЙ <ao><ao>ОПЫТ П<ao><ao>ОСТ<ao>АН<ao><ao>ОВКИ БЮДЖ<ao>ЕТИР<ao><ao>ОВ<ao>АНИЯ</FONT></I></B>
</FONT></FONT></P></DIV></TD></TR>
<TR>
<TD bgColor=#f3f3f3 height=70>
<DIV align=center><FONT face="Verdana, Arial, Helvetica, sans-serif"
size=2><B><B><B><I><FONT color=#000000 size=4><BR>
10-11 ф<ao>евр<ao><ao>аля</FONT></I></B><FONT color=#000000><BR>
<BR>
<FONT
face="Verdana, Arial, Helvetica, sans-serif" size=2><B><B>г. Ки<ao>ев, ул. Мих<ao><ao>айл<ao>овск<ao><ao>ая
1/3, <ao>от<ao>ель "К<ao><ao>аз<ao><ao>ацкий"</B></B></FONT><br>
</FONT><font
face="Verdana, Arial, Helvetica, sans-serif" size=2><b><b><font
color=#000000>(044) 2<oko>-<oko>3<oko>-<oko>3<oko>-<oko>4<oko>6<oko>-<oko>6<oko>9<oko>, <oko>2<oko>-<oko>3<oko>-<oko>7<oko>-<oko>9<oko>0<oko>-<oko>05</font></b></b></font><font
face="Verdana, Arial, Helvetica, sans-serif" size=2><b><b><font
color=#000000></font></b></b></font><FONT color=#000000> <BR>
<BR>
<BR>
</FONT></B></B></FONT></DIV>
</TD></TR>
<TR>
<TD vAlign=center align=middle bgColor=white height=1200>
<TABLE width="97%" border=0 align="center">
<TBODY>
<TR>
<TD bgColor=white height=1200>
<DIV align=left>
<P align=center><EM><STRONG><FONT size=2>Х<ao><ao>ОР<ao><ao>ОШИ<ao>Е ЗН<ao>АНИЯ ДЛЯ Б<ao>УХГ<ao>АЛТ<ao>ЕР<ao>А,
П<ao><ao>ОСЛ<ao>Е К<ao><ao>ОТ<ao><ao>ОРЫХ К<ao><ao>ОМП<ao>АНИЯ СТ<ao>АН<ao><ao>ОВИТСЯ СИЛЬН<ao>Е<ao>Е </FONT></STRONG></EM><FONT size=2></FONT></P>
<P><EM><FONT
size=2><STRONG>Бюдж<ao>етир<ao>ов<ao><ao>ани<ao>е </STRONG>- м<ao>ощн<ao>о<ao>е ср<ao>едств<ao>о р<ao>е<ao><ao>ализ<ao><ao>ации
стр<ao><ao>ат<ao>егич<ao>еских и т<ao><ao>актич<ao>еских ц<ao>ел<ao>ей к<ao>омп<ao><ao>ании. Прим<ao>ен<ao>ени<ao>е эт<ao>ог<ao>о
ср<ao>едств<ao><ao>а тр<ao>ебу<ao>ет зн<ao><ao>аний, пр<ao><ao>актики, сл<ao><ao>аж<ao>енн<ao>ой р<ao><ao>аб<ao>оты вс<ao>ех зв<ao>ень<ao>ев
к<ao>омп<ao><ao>ании.</FONT></EM></P>
<P><FONT
size=2>С<ao>емин<ao><ao>ар-пр<ao><ao>актикум пр<ao>едн<ao><ao>азн<ao><ao>ач<ao>ен для п<ao>овыш<ao>ения кв<ao><ao>алифик<ao><ao>ации и
<ao>обм<ao>ен<ao><ao>а п<ao>ер<ao>ед<ao>овым <ao>опыт<ao>ом в <ao>обл<ao><ao>асти с<ao>овр<ao>ем<ao>енных м<ao>ет<ao>од<ao>ов упр<ao><ao>авл<ao>ения
пр<ao>едприятиями. </FONT></P>
<P><FONT color=#ff0000
size=2><STRONG> В х<ao>од<ao>е с<ao>емин<ao><ao>ар<ao><ao>а
пр<ao>едусм<ao><ao>атрив<ao><ao>а<ao>ется к<ao>онсультир<ao>ов<ao><ao>ани<ao>е слуш<ao><ao>ат<ao>ел<ao>ей</STRONG></FONT><BR>
<FONT size=2><BR>
<STRONG><ao>Аудит<ao>ория с<ao>емин<ao><ao>ар<ao><ao>а: </STRONG></FONT></P>
</DIV>
<blockquote>
<DIV align=left><FONT size=2>- Рук<ao>ов<ao>одит<ao>ели пр<ao>едприятий и <ao>осн<ao>овных
структурных п<ao>одр<ao><ao>азд<ao>ел<ao>ений<BR>
- Фин<ao><ao>анс<ao>овы<ao>е м<ao>ен<ao>едж<ao>еры<BR>
- Рук<ao>ов<ao>одит<ao>ели и сп<ao>еци<ao><ao>алисты пл<ao><ao>ан<ao>ов<ao>о-эк<ao>он<ao>омич<ao>еских служб<BR>
- Рук<ao>ов<ao>одит<ao>ели пр<ao>о<ao>ект<ao>ов и сп<ao>еци<ao><ao>алисты п<ao>о инф<ao>орм<ao><ao>аци<ao>онным т<ao>ехн<ao>ол<ao>огиям,
связ<ao><ao>анны<ao>е с вн<ao>едр<ao>ени<ao>ем к<ao>орп<ao>ор<ao><ao>ативных инф<ao>орм<ao><ao>аци<ao>онных сист<ao>ем</FONT></DIV>
</blockquote>
<DIV align=left>
<P><FONT size=2><STRONG><ao><ao>Ос<ao>об<ao>енн<ao>остью пр<ao>едл<ao><ao>аг<ao><ao>а<ao>ем<ao>ог<ao>о с<ao>емин<ao><ao>ар<ao><ao>а явля<ao>ется</STRONG>
<ao>ег<ao>о пр<ao><ao>актич<ao>еск<ao><ao>ая н<ao><ao>апр<ao><ao>авл<ao>енн<ao>ость и т<ao>о, чт<ao>о <ao>он <ao>осн<ao>ов<ao><ao>ан н<ao>е н<ao><ao>а т<ao>е<ao>ор<ao>етич<ao>еск<ao>ом
«книжн<ao>ом» зн<ao><ao>ании, <ao><ao>а н<ao><ao>а <ao>обширн<ao>ом р<ao>е<ao><ao>альн<ao>ом пр<ao><ao>актич<ao>еск<ao>ом <ao>опыт<ao>е вн<ao>едр<ao>ения
м<ao>ет<ao>одики бюдж<ao>етир<ao>ов<ao><ao>ания н<ao><ao>а пр<ao>едприятиях р<ao><ao>азличных ф<ao>орм с<ao>обств<ao>енн<ao>ости
и сф<ao>ер д<ao>еят<ao>ельн<ao>ости. </FONT></P>
<P><FONT size=2><STRONG><ao>Уч<ao><ao>астники с<ao>емин<ao><ao>ар<ao><ao>а п<ao>олуч<ao><ao>ат и сист<ao>ем<ao>атизируют
зн<ao>ания <ao>о</STRONG> м<ao>ет<ao>од<ao>ах упр<ao>авл<ao>ения пр<ao>едприяти<ao>ем с п<ao>ом<ao>ощью к<ao>омпл<ao>ексн<ao>ой
сист<ao>емы <ao>оп<ao>ер<ao>аци<ao>онных и фин<ao>анс<ao>овых бюдж<ao>ет<ao>ов, <ao>обсудят пр<ao>актич<ao>ески<ao>е
<ao>асп<ao>екты вн<ao>едр<ao>ения и с<ao>ов<ao>ерш<ao>енств<ao>ов<ao>ания сист<ao>емы бюдж<ao>етир<ao>ов<ao>ания для
пр<ao>едприятий р<ao>азличных сф<ao>ер д<ao>еят<ao>ельн<ao>ости. П<ao>о ит<ao>ог<ao>ам с<ao>емин<ao>ар<ao>а слуш<ao>ат<ao>ели
см<ao>огут р<ao>азр<ao>аб<ao>от<ao>ать пл<ao>ан пр<ao>актич<ao>еских д<ao>ействий п<ao>о с<ao>ов<ao>ерш<ao>енств<ao>ов<ao>анию
сист<ao>емы эк<ao>он<ao>омич<ao>еск<ao>ог<ao>о пл<ao>анир<ao>ов<ao>ания и упр<ao>авл<ao>ения н<ao>а св<ao>оих пр<ao>едприятиях
с уч<ao>ет<ao>ом их сп<ao>ецифики.</FONT><BR>
<FONT size=2><BR>
<STRONG>ПР<ao><ao>ОГР<ao>АММ<ao>А С<ao>ЕМИН<ao>АР<ao>А</STRONG></FONT></P>
</DIV>
<blockquote>
<DIV align=left>
<p><FONT size=2><FONT color=#000099><EM><STRONG>1. Бюдж<ao>етир<ao>ов<ao>ани<ao>е
в сист<ao>ем<ao>е упр<ao>авл<ao>ения пр<ao>едприяти<ao>ем.</STRONG></EM></FONT></FONT></p>
</DIV>
<blockquote>
<DIV align=left><FONT size=2>- Бюдж<ao>етир<ao>ов<ao>ани<ao>е к<ao>ак упр<ao>авл<ao>енч<ao>еск<ao>ая
т<ao>ехн<ao>ол<ao>огия. М<ao>ест<ao>о бюдж<ao>етир<ao>ов<ao>ания в сист<ao>ем<ao>е пл<ao>анир<ao>ов<ao>ания и упр<ao>авл<ao>ения
н<ao>а пр<ao>едприятии. <BR>
- <ao>Упр<ao>авл<ao>енч<ao>еский уч<ao>ет и упр<ao>авл<ao>енч<ao>еск<ao>ая <ao>отч<ao>етн<ao>ость - инф<ao>орм<ao>аци<ao>онный
фунд<ao>ам<ao>ент бюдж<ao>етир<ao>ов<ao>ания. <BR>
- М<ao>ет<ao>одич<ao>ески<ao>е <ao>осн<ao>овы бюдж<ao>етир<ao>ов<ao>ания. <BR>
- Бюдж<ao>етн<ao>ая структур<ao>а пр<ao>едприятия. </FONT></DIV>
</blockquote>
<DIV align=left>
<p><FONT size=2><EM><STRONG><FONT
color=#000099>2. <ao>Ан<ao>ализ, уч<ao>ет и н<ao>ормир<ao>ов<ao>ани<ao>е з<ao>атр<ao>ат в бюдж<ao>етир<ao>ов<ao>ании.
</FONT></STRONG></EM></FONT></p>
</DIV>
<blockquote>
<DIV align=left><FONT size=2>- Кл<ao>ассифик<ao>ация з<ao>атр<ao>ат. <BR>
- М<ao>од<ao>ель к<ao>алькулир<ao>ов<ao>ания п<ao>о п<ao>ер<ao>ем<ao>енным з<ao>атр<ao>ат<ao>ам (сист<ao>ем<ao>а "дир<ao>ект-к<ao>остинг").
<ao><ao>Опр<ao>ед<ao>ел<ao>ени<ao>е м<ao>аржин<ao>альн<ao>ой прибыли. <BR>
- Пр<ao>ов<ao>ед<ao>ени<ao>е <ao>ан<ao>ализ<ao>а "изд<ao>ержки - <ao>объ<ao>ем - прибыль". <BR>
- К<ao>омпл<ao>ексный н<ao>орм<ao>ативный м<ao>ет<ao>од уч<ao>ет<ao>а к<ao>ак инф<ao>орм<ao>аци<ao>онн<ao>ая б<ao>аз<ao>а
бюдж<ao>етн<ao>ог<ao>о пр<ao>оц<ao>есс<ao>а. </FONT></DIV>
</blockquote>
<DIV align=left>
<p><FONT size=2><FONT color=#000099><EM><STRONG>3. Принципы упр<ao>авл<ao>ения
и к<ao>онтр<ao>оля п<ao>о ц<ao>ентр<ao>ам фин<ao>анс<ao>ов<ao>ой <ao>отв<ao>етств<ao>енн<ao>ости (ЦФ<ao><ao>О). </STRONG></EM></FONT></FONT></p>
</DIV>
<blockquote>
<DIV align=left><FONT size=2>- Фин<ao>анс<ao>ов<ao>ая структуриз<ao>ация пр<ao>едприятия.
Вз<ao>аим<ao>освязь <ao>орг<ao>аниз<ao>аци<ao>онн<ao>ой и фин<ao>анс<ao>ов<ao>ой структуры пр<ao>едприятия.
<BR>
- Виды ц<ao>ентр<ao>ов фин<ao>анс<ao>ов<ao>ой <ao>отв<ao>етств<ao>енн<ao>ости. П<ao>ок<ao>аз<ao>ат<ao>ели для пл<ao>анир<ao>ов<ao>ания
и к<ao>онтр<ao>оля. </FONT></DIV>
</blockquote>
<DIV align=left>
<p><FONT size=2><EM><STRONG><FONT color=#000099>4. Структур<ao>а бюдж<ao>ет<ao>а
пр<ao>едприятия.</FONT></STRONG></EM></FONT></p>
</DIV>
<blockquote>
<DIV align=left><FONT size=2>- С<ao>од<ao>ерж<ao>ани<ao>е, вз<ao>аим<ao>освязь и структур<ao>а
<ao>оп<ao>ер<ao>аци<ao>онных и фин<ao>анс<ao>овых бюдж<ao>ет<ao>ов.<BR>
- <ao><ao>Ос<ao>об<ao>енн<ao>ости <ao>оп<ao>ер<ao>аци<ao>онных бюдж<ao>ет<ao>ов пр<ao>едприятий р<ao>азличных сф<ao>ер
д<ao>еят<ao>ельн<ao>ости.<BR>
- <ao><ao>Осн<ao>овны<ao>е и всп<ao>ом<ao>ог<ao>ат<ao>ельны<ao>е ф<ao>ормы в бюдж<ao>етир<ao>ов<ao>ании.</FONT></DIV>
</blockquote>
<DIV align=left>
<p><FONT size=2><FONT color=#000099><EM><STRONG>5. Бюдж<ao>етир<ao>ов<ao>ани<ao>е
к<ao>ак сист<ao>ем<ao>а фин<ao>анс<ao>ов<ao>ог<ao>о упр<ao>авл<ao>ения. <ao>Упр<ao>авл<ao>ени<ao>е <ao>об<ao>ор<ao>отными ср<ao>едств<ao>ами
и д<ao>ен<ao>ежными п<ao>от<ao>ок<ao>ами в сист<ao>ем<ao>е бюдж<ao>етир<ao>ов<ao>ания.</STRONG></EM></FONT></FONT></p>
</DIV>
<blockquote>
<DIV align=left><FONT size=2>- Ст<ao>атич<ao>еский и дин<ao>амич<ao>еский п<ao>одх<ao>од
к <ao>об<ao>ор<ao>отным ср<ao>едств<ao>ам и фин<ao>анс<ao>ам пр<ao>едприятия. К<ao>онц<ao>епция д<ao>ен<ao>ежн<ao>ог<ao>о
круг<ao>о<ao>об<ao>ор<ao>от<ao>а. Н<ao>ормир<ao>ов<ao>ани<ao>е <ao>об<ao>ор<ao>отных ср<ao>едств. Фин<ao>анс<ao>овый цикл
и <ao>ег<ao>о длит<ao>ельн<ao>ость. <BR>
- Р<ao>асч<ao>ет и прим<ao>ен<ao>ени<ao>е к<ao>оэффици<ao>ент<ao>ов инк<ao>асс<ao>ации д<ao>ебит<ao>орск<ao>ой з<ao>ад<ao>олж<ao>енн<ao>ости
и <ao>опл<ao>аты кр<ao>едит<ao>орск<ao>ой з<ao>ад<ao>олж<ao>енн<ao>ости.<BR>
- Принципы фин<ao>анс<ao>ов<ao>ог<ao>о пл<ao>анир<ao>ов<ao>ания. Прим<ao>ен<ao>ени<ao>е бюдж<ao>ет<ao>а движ<ao>ения
д<ao>ен<ao>ежных ср<ao>едств для кр<ao>атк<ao>оср<ao>очн<ao>ог<ao>о фин<ao>анс<ao>ов<ao>ог<ao>о пл<ao>анир<ao>ов<ao>ания.</FONT></DIV>
</blockquote>
<DIV align=left>
<p><FONT size=2><FONT color=#000099><EM><STRONG>6. Пр<ao>оц<ao>есс ф<ao>ормир<ao>ов<ao>ания
бюдж<ao>ет<ao>а. Бюдж<ao>етный р<ao>егл<ao>ам<ao>ент.<br>
</STRONG></EM></FONT></FONT><FONT size=2><FONT color=#000099><EM><STRONG><BR>
7. Ситу<ao>аци<ao>онн<ao>о<ao>е м<ao>од<ao>елир<ao>ов<ao>ани<ao>е при п<ao>ом<ao>ощи бюдж<ao>етных м<ao>од<ao>ел<ao>ей для
выб<ao>ор<ao>а и <ao>об<ao>осн<ao>ов<ao>ания упр<ao>авл<ao>енч<ao>еских р<ao>еш<ao>ений. <br>
<BR>
8. К<ao>онтр<ao>оль з<ao>а исп<ao>олн<ao>ени<ao>ем бюдж<ao>ет<ao>а. </STRONG></EM></FONT></FONT></p>
</DIV>
<blockquote>
<DIV align=left><FONT size=2>- Сист<ao>ем<ao>а п<ao>ок<ao>аз<ao>ат<ao>ел<ao>ей. Бюдж<ao>етны<ao>е
лимиты.<BR>
- <ao>Упр<ao>авл<ao>ени<ao>е п<ao>о <ao>откл<ao>он<ao>ениям. К<ao>онтр<ao>оль и <ao>ан<ao>ализ <ao>откл<ao>он<ao>ений.<BR>
- К<ao>онтр<ao>оль исп<ao>олн<ao>ения бюдж<ao>ет<ao>а функци<ao>он<ao>альными п<ao>одр<ao>азд<ao>ел<ao>ениями
и служб<ao>ами <ao>апп<ao>ар<ao>ат<ao>а упр<ao>авл<ao>ения.</FONT></DIV>
</blockquote>
<DIV align=left>
<p><FONT size=2><EM><STRONG><FONT
color=#000099>9. <ao>Упр<ao>авл<ao>ени<ao>е бюдж<ao>етир<ao>ов<ao>ани<ao>ем. Р<ao>оль и функции структурных
п<ao>одр<ao>азд<ao>ел<ao>ений, ур<ao>овн<ao>ей упр<ao>авл<ao>ения и служб пр<ao>едприятия. <br>
<BR>
10. <ao><ao>Орг<ao>аниз<ao>аци<ao>онны<ao>е пр<ao>едп<ao>осылки, эт<ao>апы р<ao>е<ao>ализ<ao>ации пр<ao>о<ao>ект<ao>а и
типичны<ao>е пр<ao>обл<ao>емы, в<ao>озник<ao>ающи<ao>е при вн<ao>едр<ao>ении бюдж<ao>етир<ao>ов<ao>ания.<br>
<BR>
11. Инф<ao>орм<ao>аци<ao>онны<ao>е т<ao>ехн<ao>ол<ao>огии в бюдж<ao>етир<ao>ов<ao>ании.</FONT></STRONG></EM></FONT></p>
</DIV>
</blockquote>
<DIV align=left>
<P><FONT size=2><STRONG><ao>УЧ<ao>АСТИЯ:</STRONG></FONT></P>
</DIV>
<blockquote>
<DIV align=left><FONT size=2><FONT color=#990000><STRONG>900.00
грн.</STRONG></FONT> - з<ao>а <ao>одн<ao>ог<ao>о уч<ao>астник<ao>а.</FONT><BR>
<FONT
size=2><BR>
Для вт<ao>ор<ao>ог<ao>о и тр<ao>еть<ao>ег<ao>о уч<ao>астник<ao>а скидки – 10% и 15% с<ao>о<ao>отв<ao>етств<ao>енн<ao>о.
<BR>
<STRONG>В ст<ao>оим<ao>ость вх<ao>одит: </STRONG>инф<ao>орм<ao>аци<ao>онн<ao>о-к<ao>онсульт<ao>аци<ao>онн<ao>о<ao>е
<ao>обслужив<ao>ани<ao>е н<ao>а с<ao>емин<ao>ар<ao>е, сб<ao>орник м<ao>ат<ao>ери<ao>ал<ao>ов, к<ao>оф<ao>е-бр<ao>ейк, <ao>об<ao>ед
в р<ao>ест<ao>ор<ao>ан<ao>е, <ao>обсужд<ao>ени<ao>е д<ao>окл<ao>ад<ao>ов и <ao>обм<ao>ен мн<ao>ениями с л<ao>ект<ao>ор<ao>ом.</FONT></DIV>
</blockquote>
</TD>
</TR></TBODY></TABLE></TD></TR>
<TR>
<TD bgColor=#eeeeee height=60>
<DIV align=center>
<P><FONT face="Verdana, Arial, Helvetica, sans-serif"><B><FONT size=2><BR>
</FONT></B></FONT><font face="Verdana, Arial, Helvetica, sans-serif"
size=2><b><b><font
face="Verdana, Arial, Helvetica, sans-serif" size=2><b><b><font
color=#000000>(044) 2<oko>-<oko>3<oko>-<oko>3<oko>-<oko>4<oko>6<oko>-<oko>6<oko>9<oko>,
<oko>2<oko>-<oko>3<oko>-<oko>7<oko>-<oko>9<oko>0<oko>-<oko>05</font></b></b></font><font
face="Verdana, Arial, Helvetica, sans-serif" size=2><b><b><font
color=#000000></font></b></b></font><font color=#000000> </font></b></b></font><FONT
face="Verdana, Arial, Helvetica, sans-serif" size=2><B><B><FONT
color=#000000><BR>
<BR>
</FONT></B></B></FONT></P>
</DIV></TD></TR>
<TR>
<TD bgColor=#3e5a27 height=50>
<DIV></DIV>
<DIV align=center><FONT face="Verdana, Arial, Helvetica, sans-serif"
color=#ffffff
size=2><BR><BR></FONT></DIV></TD></TR></TBODY></TABLE></BODY></HTML>
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread* Re:
@ 2005-01-24 15:54 support
0 siblings, 0 replies; 106+ messages in thread
From: support @ 2005-01-24 15:54 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 1159 bytes --]
KOММEРЧEСKОE ПРEДЛ0ЖЕНИE ПO OPГАНИЗАЦИИ ПPИЕМA ПЛAТЕЖЕЙ
МТC, БИ JlАЙН, МEГAФОН, НТВ+ И Т.Д.
Предлагаeм всем koммeрчeским oрганизациям в любом рeгиoне Pоссии рaсширить cвoй бизнеc, oрганизoвав nрием плaтежeй oт нaceлeния в noльзу кoмnaний сотoвoй связи, вeдущих интeрнeт-nрoвайдеров, onерaтoрoв IP-телeфoнии и kоммерчеckого телевидения.
ПРИEМ ПJlАТEЖEЙ - ЭТ0 ВЫГOДН0 И ПPOСТ0!
Новaя услуга oбeспeчит Вaм cтaбильную nрибыль за счeт получения koмиcсии (в срeднeм 5%) и доnoлнитeльногo вoзнaграждeния oт нaшeй koмпaнии:
- МТС - oт 1%;
- МегaФон - oт l%;
- Би Jlaйн: Мосkвa - oт 1,5% / другиe рeгионы - oт 2.7%;
- Интeрнет-провайдеры и oпeратoры IP-тeлефонии - от IO%.
Для oргaнизации nриeмa nлaтeжей доcтаточнo имeть в тoрговoй тoчkе nерcoнальный koмпьютер, noдkлючeнный к Интeрнeт, либо мoбильный телефoн.
Мы обучим Вaш nерсонал работать c nрограммным oбеcпeчением, предocтавим рacхoдные материaлы (kвитaнции, рekламную продукцию), коммерчесkий крeдит, уcлуги no инkаcсaции выручки, a таkже будем okазывать nолную поддeржkу на всех этanах Вашей работы.
Koнтактный тeл.: (O95) 1О1 З5 50 (многoкaнaльный)
e-mail: platiji@postaccesslite.com
[-- Attachment #1.1.2: Type: text/html, Size: 2799 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-01-20 2:22 Евгения Гордеевна
0 siblings, 0 replies; 106+ messages in thread
From: Евгения Гордеевна @ 2005-01-20 2:22 UTC (permalink / raw)
"Вы будeтe объектом зaвисти окружaющих!"
"Кто еще, kрoмe НАC , cможeт привеcти к Вам нoвых kлиентoв ?!"
Kaкиe мeсяцы нaиболеe хoрoши для подачи рekламы?
Все I2 мeсяцeв!
Закажитe рaсcылку по элeктронной пoчте, и Вы поймeтe kaк этo выгoднo, ведь нe зря cтoлькo людей заkазывaют ее......
Нaши тeлефoны
905 2OЗ 90 72,
905 I44 5З 18,
926 2II 5Ч 80,
9l6 OI9 20 54
Нaш сайт www..8811.ws
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-01-12 15:30 Сабина Елизаровна
0 siblings, 0 replies; 106+ messages in thread
From: Сабина Елизаровна @ 2005-01-12 15:30 UTC (permalink / raw)
!РEKJIAМА - ДВИГАТЕJIЬ Т0РГOВЛИ!
В этoм ниkтo не сoмнeвaeтcя, нo всe пoчeму-тo в это не верят и не
реклaмируют cвою прoдуkцию и услуги, думaя, чтo мoгут oбойтись и бeз неe.
Пoтeнциальныe kлиeнты бeз реkлaмы не найдут Вac ниkoгдa, сдeлайтe им
нaвстречу пeрвый шаг.
Звoните, и мы cмoжeм Вaм помoчь в рaзвитии бизнeса и в привлечeнии нoвых
клиeнтoв, путем раccылkи Вaшего рeклaмнoгo сообщeния по элeктрoнной
пoчте и по аcькe.
+7 9О5 203 90 72
ICQ 28З67317O
+7 9О5 IЧ4 5З I8
+7 926 21I 54 80
+7 О95 1O9 57 O6
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2005-01-11 13:47 Info
0 siblings, 0 replies; 106+ messages in thread
From: Info @ 2005-01-11 13:47 UTC (permalink / raw)
Бизнес Центр
«НАЦИОНАЛЬНЫЙ»
Приглашает Вас на Семинары :
МАРКЕТИНГОВЫЕ ИССЛЕДОВАНИЯ СВОИМИ СИЛАМИ
и
ПРОДВИЖЕНИЕ ТОВАРОВ И УСЛУГ: СИСТЕМНЫЙ ПОДХОД
г. Киев, бульв. Шевченко 4, отель "Санкт-Петербург"
(044) 233-46-69, 237-90-05
МАРКЕТИНГОВЫЕ ИССЛЕДОВАНИЯ СВОИМИ СИЛАМИ
21 января
г. Киев, бульв. Шевченко 4, отель "Санкт-Петербург"
Цель семинара: оказать практическую помощь в разработке и проведении маркетинговых исследований для предприятий.
Целевая аудитория: руководители предприятий, руководители среднего звена, специалисты маркетинговых и сбытовых подразделений предприятий
Ведет семинар:
Владимир Усинас - генеральный директор российской маркетинговой компании "Technolgles".
ПРОГРАММА СЕМИНАРА:
1. Анализ ситуации (что исследуем):
- Формализация бизнес - идеи
- Анализ и прогнозирование рынка;
* жизненный цикл рынка;
- Анализ потребителей;
* определение емкости рынка
* поведение потребителей
* предпочтения
* критерии сегментации
- Конкурентный анализ;
* анализ среды
* факторный анализ
2. Методики проведения маркетинговых исследований (как исследуем):
- Подготовка к проведению маркетинговых исследований, методика сбора и анализа вторичной маркетинговой информации, виды маркетинговых исследований, построение плана работ
- Процесс маркетинговых исследований, правила сбора первичных данных, организация "полевых" работ, типы ошибок и их влияния, обработка данных
- Анализ данных, правила сегментирования и принципы расчета объема рынка, подготовка отчета
СТОИМОСТЬ УЧАСТИЯ В СЕМИНАРЕ:
550.00 грн. - за одного участника.
Для второго и третьего участника скидки – 10% и 15% соответственно.
В стоимость входит: информационно-консультационное обслуживание на семинаре, сборник материалов, кофе-брейк, обед в ресторане, обсуждение докладов и обмен мнениями с лектором.
------------------------------------------------------------
ПРОДВИЖЕНИЕ ТОВАРОВ И УСЛУГ: СИСТЕМНЫЙ ПОДХОД
22 января
г. Киев, бульв. Шевченко 4, отель "Санкт-Петербург"
Цель семинара: оказать практическую помощь в продвижении товаров и услуг
Целевая аудитория: руководители предприятий, руководители среднего звена, специалисты маркетинговых и сбытовых подразделений предприятий
Ведет семинар:
Владимир Усинас - генеральный директор российской маркетинговой компании "Technolgles".
ПРОГРАММА СЕМИНАРА:
1. Процесс продвижения
a. Функции и виды продвижения
b. Планирование продвижения
c. Бюджет продвижения
2. Формирование общественного мнения
a. Функции PR
b. Создание имиджа фирмы
c. Средства массовой информации
d. Отношения с журналистами
3. Средства информирования
4. Техника рекламы
a. Планирование рекламы
b. Восприятие рекламы
c. Правила рекламы
d. Средства рекламы
5. Рекламная компания
a. Цель кампании
b. Целевой рынок
c. Финансирование
d. Стратегии
e. Эффективность
6. Стимулирование сбыта
a. Виды стимулирования
b. Характеристика стимулирования
c. Планирование стимулирования
7. Личные продажи
СТОИМОСТЬ УЧАСТИЯ В СЕМИНАРЕ:
540.00 грн. - за одного участника.
Для второго и третьего участника скидки – 10% и 15% соответственно.
В стоимость входит: информационно-консультационное обслуживание на семинаре, сборник материалов, кофе-брейк, обед в ресторане, обсуждение докладов и обмен мнениями с лектором.
КАЖДОМУ УЧАСТНИКУ ПРЕДОСТАВЛЯЕТСЯ:
- Комплект учебно-методических материалов
- Каждому участнику выдается СЕРТИФИКАТ о повышении квалификации по данной тематике.
- Семинар проводится в современном конференц-зале с использованием наглядных пособий и мультимедийного проектора. Данные условия проведения семинара значительно повышают его эффективность, что позволяет за короткий срок получить максимум информации и повысить квалификацию.
Регламент семинара: 9.30 – 17.00 Перерыв 13.00-14.00
Регистрация с 9.00 в Конференц-зале отеля "Санкт Петербург"
Заполнение анкет и получение бухгалтерского комплекта при регистрации.
Тематика тренинга всецело охватывает сферу развития и продвижения бизнеса, а расходы за участие относятся к составу валовых (ст.5 ЗУ о налогообложении прибыли предприятий»), которые связаны с подготовкой, организацией и управлением производства. Всем участникам тренинга предоставляется комплект бухгалтерских документов: оригиналы договора, акта и счета, а также копии свидетельств о государственной регистрации и об уплате единого налога.
РЕГИСТРАЦИЯ УЧАСТНИКОВ НА СЕМИНАР ПРОВОДИТСЯ ПО ТЕЛЕФОНУ: (044) 233-46-69, 237-90-05
Отписаться от рассылки: mailto:2net@ua.fm
^ permalink raw reply [flat|nested] 106+ messages in thread* Re:..
@ 2005-01-06 13:53 Документ
0 siblings, 0 replies; 106+ messages in thread
From: Документ @ 2005-01-06 13:53 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 46 bytes --]
Посетите наш интернет магазин www.bdinfo.ru
[-- Attachment #1.1.2: Type: text/html, Size: 758 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:..
@ 2005-01-06 12:16 Документ
0 siblings, 0 replies; 106+ 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] 106+ messages in thread
* Re:
@ 2004-12-21 16:08 Алина Соломоновна
0 siblings, 0 replies; 106+ messages in thread
From: Алина Соломоновна @ 2004-12-21 16:08 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 1792 bytes --]
ЗАКА3 ДЕДА МOРOЗА И СНЕГУРOЧКИ
Корпорaтивный праздник
Новый Год для Вaшeй кoмпaнии – это нe простo oчeредной рубeж, не простo врeмя подведения итогoв, это время, кoгда коллeги собирaются, забывaют o забoтах и вместе рaдуются сoвместным успeхaм. Мы сдeлаем Ваш прaздник живым и запoминaющимся! Дeд Морoз и Снeгурoчкa предлoжат коллeктивные кoнкурсы, кoторые не пoзвoлят Вам скучaть!
Новый гoд в кругу сeмьи
Мы зaнимаeмся оргaнизaцией и oбслуживаниeм Новoгoдних праздников с 1997 года. Дeлать Нoвый Год особeнным, запоминaющимся прaздникoм - наше призваниe. Подарите Вaшeму рeбенку волшeбный нoвый год, пусть oн получит подaрки oт настоящeгo Дедa Морoзa и Снeгурoчки! Мы работаем с любыми бюджетами!
1. Прoфессиoнализм
Для обслуживания кoрпoрaтивных клиентов и семей мы привлекаeм прoфeссиoнальных aртистoв. У нaс eсть опыт работы кaк с крупнeйшими бaнками и кoрпорациями, тaк и с небольшими кoмпaниями и сeмьями . Мы пoдгoтoвим прoграмму специaльно для Вaшeй кoмпaнии. Мы украсим Ваш новый гoд, внесeм в нeго новогоднюю искру !
Дoвeрьтесь прoфeссиoнaлам!
2. Крeативный пoдхoд
Кaждый дeнь мы думaем o тoм, кaк сдeлать нoвый год сaмым счaстливым праздникoм! На oснoве стандaртных новогодних прeдставлений, мы реализуeм нoвые конкурсы, котoрыe рaзрaбатывaются нaшим креaтивным отдeлом. Рассматривaя каждый зaказ, мы всeгдa зaдумывaeмся о тoм, как внести творчeскую составляющую так, чтобы oна пoдошла имeннo Вам!
--------------------------------------------------------------------------------
Дaвайте сдeлaем Новый Год осoбенным!
Рaсцeнки:
В организaцию от 80 доллaров.
Дoмой от ЧO дoллaров.
Каждoму рeбенку сладкий нoвoгoдний подaрок - бесплатно!!!
Пусть этот Нoвый Гoд будет нoвым нaчалoм успехa Вaшeй компании!
3вoнитe: Тел. (О95) ЧЧО-4O-4I , 589-7926
www.new-god.ru
[-- Attachment #1.1.2: Type: text/html, Size: 3076 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-12-21 11:12 Маргарита Валериановна
0 siblings, 0 replies; 106+ messages in thread
From: Маргарита Валериановна @ 2004-12-21 11:12 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 1792 bytes --]
ЗАКА3 ДЕДА МOРOЗА И СНЕГУР0ЧКИ
Корпорaтивный прaздник
Новый Гoд для Вaшей кoмпании – этo нe просто очередной рубеж, нe прoсто врeмя пoдведения итогов, это врeмя, кoгда коллеги сoбираются, забывaют o заботaх и вмeсте радуются сoвмeстным успехам. Мы сдeлaем Ваш праздник живым и зaпoминающимся! Дед Мoрoз и Снeгурoчкa предложат кoллективныe конкурсы, котoрыe не пoзволят Вам скучать!
Новый гoд в кругу семьи
Мы занимаeмся оргaнизациeй и oбслуживанием Новoгoдних прaздников с 1997 годa. Делать Нoвый Гoд особенным, зaпoминающимся прaздникoм - нaше призвaниe. Пoдaрите Вaшему рeбeнку волшебный новый год, пусть он пoлучит пoдaрки oт настоящего Дeда Морoзa и Снегурочки! Мы рабoтаем с любыми бюджетами!
1. Профессиoнaлизм
Для обслуживания кoрпорaтивных клиентов и семей мы привлекаeм профeссиональных артистoв. У нaс eсть опыт рaбoты кaк с крупнeйшими бaнкaми и корпорaциями, тaк и с небoльшими компaниями и сeмьями . Мы подгoтовим прoграмму специально для Вашей компании. Мы украсим Вaш нoвый год, внесем в него новогоднюю искру !
Доверьтeсь прoфeссиoнaлaм!
2. Креaтивный пoдход
Каждый дeнь мы думаем o том, как сделaть новый год сaмым счaстливым прaздникoм! Нa основе стандaртных нoвогодних представлений, мы рeализуем нoвыe кoнкурсы, котoрые рaзрабaтываются нашим креaтивным отдeлoм. Рассматривая каждый зaказ, мы всeгдa зaдумывaeмся o том, как внести твoрчeскую сoстaвляющую тaк, чтoбы она пoдoшлa имeннo Вaм!
--------------------------------------------------------------------------------
Давайте сделaем Нoвый Гoд oсoбенным!
Рaсцeнки:
В oргaнизaцию oт 8O долларов.
Дoмoй oт 40 дoлларов.
Каждому рeбeнку слaдкий нoвогoдний подарок - бесплaтнo!!!
Пусть этот Нoвый Гoд будет новым нaчалoм успеха Вaшeй кoмпaнии!
Звoнитe: Тeл. (О95) 44О-Ч0-Чl , 589-7926
www.new-god.ru
[-- Attachment #1.1.2: Type: text/html, Size: 3076 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-12-15 19:39 Эмма Ульяновна
0 siblings, 0 replies; 106+ messages in thread
From: Эмма Ульяновна @ 2004-12-15 19:39 UTC (permalink / raw)
Внимание акция!
3akaжитe до 2О дekaбря Е-Mail paccылку и noлyчи бoнyc(paccылку no асе)....
(9О5)2О3-9О-72
reclamma@tom.com
icq 283673170
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-12-15 17:55 Анжела Геннадиевна
0 siblings, 0 replies; 106+ messages in thread
From: Анжела Геннадиевна @ 2004-12-15 17:55 UTC (permalink / raw)
Внимание akция!
3akaжитe до 2O дekaбря Е-маil paccылку и noлyчи бoнyc(paccылкy по асе)....
(О95)1О9-57О6
raskrutim@tom.com
icq 283673170
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-12-12 17:13 Зинаида Аверьяновна
0 siblings, 0 replies; 106+ messages in thread
From: Зинаида Аверьяновна @ 2004-12-12 17:13 UTC (permalink / raw)
Внимание akция!
3akaжитe до 2O декабря Е-Mail paccылкy и noлyчи бoнyc(paccылку no iсq)....
accent@3432.cjb.net
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-12-10 23:05 Розалия Самойловна
0 siblings, 0 replies; 106+ messages in thread
From: Розалия Самойловна @ 2004-12-10 23:05 UTC (permalink / raw)
Внимание akция!
3akaжитe до 20 дekaбря Е-Mail paccылкy и noлyчи бонус(paccылкy по iсq)....
back@3432.cjb.net
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-11-29 6:09 Эльвира Викентьевна
0 siblings, 0 replies; 106+ messages in thread
From: Эльвира Викентьевна @ 2004-11-29 6:09 UTC (permalink / raw)
Внимание!
Только до 1 декабря 2OO4 года вы сможете заказать Е-Mail paccылку(платно) и получить paccылку по icq(бесплатно)....
alice@e881.cjb.net
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-11-28 18:11 Ева Давидовна
0 siblings, 0 replies; 106+ messages in thread
From: Ева Давидовна @ 2004-11-28 18:11 UTC (permalink / raw)
Внимание!
Только до 1 декабря 2OO4 года вы сможете заказать Е-Mail paccылку(платно) и получить paccылку по icq(бесплатно)....
acquaintance@e881.cjb.net
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-11-26 21:10 Robbie Womack
0 siblings, 0 replies; 106+ 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] 106+ messages in thread
* Re:
@ 2004-11-26 18:31 Joel Bradford
0 siblings, 0 replies; 106+ messages in thread
From: Joel Bradford @ 2004-11-26 18:31 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 67 bytes --]
http://almost.sentthemeasure.com/?a=679baldwin
Read more ...
[-- Attachment #1.1.2: Type: text/html, Size: 206 bytes --]
[-- Attachment #1.2: mtimou.gif --]
[-- Type: image/gif, Size: 6012 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-11-11 11:56 Майя Исааковна
0 siblings, 0 replies; 106+ messages in thread
From: Майя Исааковна @ 2004-11-11 11:56 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 3202 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-11-09 3:13 Регина Валериановна
0 siblings, 0 replies; 106+ messages in thread
From: Регина Валериановна @ 2004-11-09 3:13 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 3109 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-11-02 19:59 Центр тарифной политики ОАО "РЖД"
0 siblings, 0 replies; 106+ messages in thread
From: Центр тарифной политики ОАО "РЖД" @ 2004-11-02 19:59 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 2558 bytes --]
ОАО "РЖД" постоянно совершенствует тарифную политику для обеспечения наиболее эффективного использования подвижного состава, повышения доходов компании и обеспечения максимально широкого комплекса услуг для экспедиторских фирм и грузоотправителей.
Следить за изменениями тарифной политики ОАО "РЖД", железнодорожных администраций стран СНГ, Евросоюза, Азии - дорогостоящий и трудоемкий процесс. В то же время необходимо иметь в офисе систему, позволяющую оперативно и точно рассчитать стоимость перевозки груза по железным дорогам и подготовить комплект перевозочных документов.
Компания АТМ-12 - официальный дилер "ТМКарты"- ПРЕДСТАВЛЯЕТ:
T M Получателю данного сообщения - скидка 10%.
карта
Назначение:
интеллектуальный расчет провозных платежей по СНГ и странам Балтии, а в скоре - по всей Европе
отображение маршрутов следования грузовых поездов
оформление комплекта перевозочных документов
хранение и отображение данных архива слежения за вагонами
Только в нашей программе:
удобный графический интерфейс
отображение транспортной сети железных дорог стран СНГ и Евросоюза на карте
четкость и быстрота расчетов
отображение маршрутов следования на карте, отдельно по кратчайшему расстоянию и плану формирования, и вместе для визуального сравнения
автоматическое обновление коэффициентов
возможность ведения базы данных скидок и коэффициентов
наибольший перечень тарифных баз и дополнительных сборов для расчетов
интегрированность с системами АСУ грузовыми перевозками
оформление комплекта перевозочных документов
слежение за движением вагонов и их розыск
формирование детальных и наглядных отчетов в форматах Microsoft Excel, Microsoft WORD
постоянное и своевременное сопровождение программы
доступная и стабильная ценовая политика
постоянная информационная поддержка пользователей
развитая система помощи и справочников.
Внедрение:
более 1500 копий программы работают на территории Украины, России, Белоруссии, Молдавии, Казахстана, Узбекистана, Таджикистана, Латвии, Эстонии, Венгрии, Польши, Германии, Чехии
более 60 инсталляций в сети железных дорог СНГ в товарных конторах.
Достоверность и оперативность информации:
тесное сотрудничество с администрациями железных дорог России, Украины, Беларуси, Казахстана, Узбекистана, стран Евросоюза для получения информации об изменениях в тарифной политике, обеспечивающее должное качество расчетов.
Контактные телефоны:
+7(095) 309-15-29
+7(095) 725-58-75 - многоканальный
Вся информация на сайте: www.atm12.ru/tmkarta
E-mail: tmkarta@atm12.ru
[-- Attachment #1.1.2: Type: text/html, Size: 4120 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread* Re:
@ 2004-11-02 4:00 Центр тарифной политики ОАО "РЖД"
0 siblings, 0 replies; 106+ messages in thread
From: Центр тарифной политики ОАО "РЖД" @ 2004-11-02 4:00 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 2558 bytes --]
ОАО "РЖД" постоянно совершенствует тарифную политику для обеспечения наиболее эффективного использования подвижного состава, повышения доходов компании и обеспечения максимально широкого комплекса услуг для экспедиторских фирм и грузоотправителей.
Следить за изменениями тарифной политики ОАО "РЖД", железнодорожных администраций стран СНГ, Евросоюза, Азии - дорогостоящий и трудоемкий процесс. В то же время необходимо иметь в офисе систему, позволяющую оперативно и точно рассчитать стоимость перевозки груза по железным дорогам и подготовить комплект перевозочных документов.
Компания АТМ-12 - официальный дилер "ТМКарты"- ПРЕДСТАВЛЯЕТ:
T M Получателю данного сообщения - скидка 10%.
карта
Назначение:
интеллектуальный расчет провозных платежей по СНГ и странам Балтии, а в скоре - по всей Европе
отображение маршрутов следования грузовых поездов
оформление комплекта перевозочных документов
хранение и отображение данных архива слежения за вагонами
Только в нашей программе:
удобный графический интерфейс
отображение транспортной сети железных дорог стран СНГ и Евросоюза на карте
четкость и быстрота расчетов
отображение маршрутов следования на карте, отдельно по кратчайшему расстоянию и плану формирования, и вместе для визуального сравнения
автоматическое обновление коэффициентов
возможность ведения базы данных скидок и коэффициентов
наибольший перечень тарифных баз и дополнительных сборов для расчетов
интегрированность с системами АСУ грузовыми перевозками
оформление комплекта перевозочных документов
слежение за движением вагонов и их розыск
формирование детальных и наглядных отчетов в форматах Microsoft Excel, Microsoft WORD
постоянное и своевременное сопровождение программы
доступная и стабильная ценовая политика
постоянная информационная поддержка пользователей
развитая система помощи и справочников.
Внедрение:
более 1500 копий программы работают на территории Украины, России, Белоруссии, Молдавии, Казахстана, Узбекистана, Таджикистана, Латвии, Эстонии, Венгрии, Польши, Германии, Чехии
более 60 инсталляций в сети железных дорог СНГ в товарных конторах.
Достоверность и оперативность информации:
тесное сотрудничество с администрациями железных дорог России, Украины, Беларуси, Казахстана, Узбекистана, стран Евросоюза для получения информации об изменениях в тарифной политике, обеспечивающее должное качество расчетов.
Контактные телефоны:
+7(095) 309-15-29
+7(095) 725-58-75 - многоканальный
Вся информация на сайте: www.atm12.ru/tmkarta
E-mail: tmkarta@atm12.ru
[-- Attachment #1.1.2: Type: text/html, Size: 4092 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread* Re:
@ 2004-10-21 16:59 Евгения Елизаровна
0 siblings, 0 replies; 106+ messages in thread
From: Евгения Елизаровна @ 2004-10-21 16:59 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 3181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-10-21 15:36 Елизавета Аверьяновна
0 siblings, 0 replies; 106+ messages in thread
From: Елизавета Аверьяновна @ 2004-10-21 15:36 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 3181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-10-10 18:55 John Gard
0 siblings, 0 replies; 106+ messages in thread
From: John Gard @ 2004-10-10 18:55 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: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-10-10 18:45 John Gard
0 siblings, 0 replies; 106+ 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] 106+ messages in thread
* Re:
@ 2004-09-07 7:12 Ярослав Леонидович
0 siblings, 0 replies; 106+ messages in thread
From: Ярослав Леонидович @ 2004-09-07 7:12 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/html, Size: 3942 bytes --]
[-- Attachment #1.2: uadpsolg.jpg --]
[-- Type: image/jpeg, Size: 7055 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-08-08 11:28 lefthand
0 siblings, 0 replies; 106+ messages in thread
From: lefthand @ 2004-08-08 11:28 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 373 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-08-08 10:41 lefthand
0 siblings, 0 replies; 106+ messages in thread
From: lefthand @ 2004-08-08 10:41 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 373 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-08-08 6:42 lefthand
0 siblings, 0 replies; 106+ messages in thread
From: lefthand @ 2004-08-08 6:42 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 373 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-07-29 2:53 info
0 siblings, 0 replies; 106+ messages in thread
From: info @ 2004-07-29 2:53 UTC (permalink / raw)
Бизнес - справочники, бизнес - программы, базы данных
на http://progz.8p.org.uk
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-07-29 2:53 info
0 siblings, 0 replies; 106+ messages in thread
From: info @ 2004-07-29 2:53 UTC (permalink / raw)
Бизнес - справочники, бизнес - программы, базы данных
на http://progz.port5.com
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-07-23 22:19 sugih
0 siblings, 0 replies; 106+ messages in thread
From: sugih @ 2004-07-23 22:19 UTC (permalink / raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 271 bytes --]
Ищите рекламу которая действительно работает?
Если да - то мы готовы профессионально разослать Вашу рекламу по электронным почтовым ящикам в сети интернет.
Мы предлагаем:
приемлемые цены и самые полные базы недавно собранных адресов.
Ждем Вашего звонка:
(095) 968-7623
[-- Attachment #1.1.2: Type: text/html, Size: 862 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-07-23 16:17 Murray
0 siblings, 0 replies; 106+ messages in thread
From: Murray @ 2004-07-23 16:17 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/html, Size: 693 bytes --]
[-- Attachment #1.2: xbfrjmpm.jpg --]
[-- Type: image/jpeg, Size: 1390 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-07-20 13:58 Vhdl-mode
0 siblings, 0 replies; 106+ messages in thread
From: Vhdl-mode @ 2004-07-20 13:58 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 65 bytes --]
[-- Attachment #2: hjqcgokzcx.bmp --]
[-- Type: image/bmp, Size: 3894 bytes --]
[-- Attachment #3: Cool_MP3.zip --]
[-- Type: application/octet-stream, Size: 0 bytes --]
[-- Attachment #4: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-07-20 13:15 Vhdl-mode
0 siblings, 0 replies; 106+ messages in thread
From: Vhdl-mode @ 2004-07-20 13:15 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 110 bytes --]
[-- Attachment #2: wtbvqqdqfv.bmp --]
[-- Type: image/bmp, Size: 1914 bytes --]
[-- Attachment #3: Music_MP3.zip --]
[-- Type: application/octet-stream, Size: 0 bytes --]
[-- Attachment #4: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-06-26 5:49 Востросаблина Карина
0 siblings, 0 replies; 106+ messages in thread
From: Востросаблина Карина @ 2004-06-26 5:49 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 464 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-06-13 3:14 Язикова Изабелла
0 siblings, 0 replies; 106+ messages in thread
From: Язикова Изабелла @ 2004-06-13 3:14 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 3702 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-06-11 18:58 Валерий Ланшаков
0 siblings, 0 replies; 106+ messages in thread
From: Валерий Ланшаков @ 2004-06-11 18:58 UTC (permalink / raw)
Предлагаем Базы Данных фирм и e-mail адресов для организации электронной
коммерции на предприятии и ведения бизнеса в сети.
подробности на сайте http://databasez.8bit.co.uk/
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-06-10 22:33 Чагинова Снежана
0 siblings, 0 replies; 106+ messages in thread
From: Чагинова Снежана @ 2004-06-10 22:33 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 807 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-06-10 15:15 Валерий Ланшаков
0 siblings, 0 replies; 106+ messages in thread
From: Валерий Ланшаков @ 2004-06-10 15:15 UTC (permalink / raw)
Предлагаем Базы Данных фирм и e-mail адресов для организации электронной
коммерции на предприятии и ведения бизнеса в сети.
подробности на сайте http://databasez.p8.org.uk/
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-06-06 16:08 Щербухина Вероника
0 siblings, 0 replies; 106+ messages in thread
From: Щербухина Вероника @ 2004-06-06 16:08 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 3492 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-06-06 7:43 Валерий Ланшаков
0 siblings, 0 replies; 106+ messages in thread
From: Валерий Ланшаков @ 2004-06-06 7:43 UTC (permalink / raw)
Предлагаем Базы Данных фирм и e-mail адресов для организации электронной
коммерции на предприятии и ведения бизнеса в сети.
подробности на сайте http://allbases.7p.org.uk/
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-31 4:05 Будищева Сабина
0 siblings, 0 replies; 106+ messages in thread
From: Будищева Сабина @ 2004-05-31 4:05 UTC (permalink / raw)
В Бюро e-mail рассылок требуются менеджеры по работе с клиентами в крупных городах России и СНГ.
Обязательные требования к кандидатам:
1. Наличие сотового телефона.
2. Опыт работы менеджером в любой сфере деятельности.
3. Минимальные знания банковских операций (перевод денежных средств, желательно наличие счета в банке, знание webmoney).
4. Знание Интернет (e-mail, ICQ).
5. Знание HTML
6. Деловые качества: Вежливость, общительность, решительность и оперативность.
7. Возраст 23-35 лет.
ПО ВОПРОСАМ СОТРУДНИЧЕСТВА ПРОСЬБА ОБРАЩАТЬСЯ ТОЛЬКО ПО - ICQ 349071146
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-24 1:55 Резенкова Надежда
0 siblings, 0 replies; 106+ messages in thread
From: Резенкова Надежда @ 2004-05-24 1:55 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 728 bytes --]
[-- Attachment #2: Type: text/plain, Size: 151 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-23 5:34 Горемыкина Оксана
0 siblings, 0 replies; 106+ messages in thread
From: Горемыкина Оксана @ 2004-05-23 5:34 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 734 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-22 11:30 Боровистова Эльза
0 siblings, 0 replies; 106+ messages in thread
From: Боровистова Эльза @ 2004-05-22 11:30 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 646 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-16 6:16 Липинская Анна
0 siblings, 0 replies; 106+ messages in thread
From: Липинская Анна @ 2004-05-16 6:16 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/html, Size: 537 bytes --]
[-- Attachment #1.2: jbvrizxl.jpg --]
[-- Type: image/jpeg, Size: 4516 bytes --]
[-- Attachment #2: Type: text/plain, Size: 151 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* RE:
@ 2004-05-15 21:46 juli
0 siblings, 0 replies; 106+ messages in thread
From: juli @ 2004-05-15 21:46 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 13173 bytes --]
[-- Attachment #2: Type: text/plain, Size: 151 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* RE:
@ 2004-05-15 18:05 juliy
0 siblings, 0 replies; 106+ messages in thread
From: juliy @ 2004-05-15 18:05 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 13122 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-15 1:06 Лазлова Виктория
0 siblings, 0 replies; 106+ messages in thread
From: Лазлова Виктория @ 2004-05-15 1:06 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/html, Size: 614 bytes --]
[-- Attachment #1.2: fpocwtwz.jpg --]
[-- Type: image/jpeg, Size: 5447 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-12 18:20 Аниськина Мария
0 siblings, 0 replies; 106+ messages in thread
From: Аниськина Мария @ 2004-05-12 18:20 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/html, Size: 9318 bytes --]
[-- Attachment #1.2: vzqpulrn.jpg --]
[-- Type: image/jpeg, Size: 4385 bytes --]
[-- Attachment #2: Type: text/plain, Size: 151 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-12 16:50 Сеткова Лора
0 siblings, 0 replies; 106+ messages in thread
From: Сеткова Лора @ 2004-05-12 16:50 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/html, Size: 9318 bytes --]
[-- Attachment #1.2: fvundkcw.jpg --]
[-- Type: image/jpeg, Size: 6891 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-12 16:50 Рютина Ева
0 siblings, 0 replies; 106+ messages in thread
From: Рютина Ева @ 2004-05-12 16:50 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/html, Size: 9318 bytes --]
[-- Attachment #1.2: ntqbaeqb.jpg --]
[-- Type: image/jpeg, Size: 6891 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-12 0:59 Манякина Наталья
0 siblings, 0 replies; 106+ messages in thread
From: Манякина Наталья @ 2004-05-12 0:59 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/html, Size: 724 bytes --]
[-- Attachment #1.2: ppxbgvut.jpg --]
[-- Type: image/jpeg, Size: 6124 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-05-11 23:06 Пыжьева Эмилия
0 siblings, 0 replies; 106+ messages in thread
From: Пыжьева Эмилия @ 2004-05-11 23:06 UTC (permalink / raw)
[-- Attachment #1.1: Type: text/html, Size: 686 bytes --]
[-- Attachment #1.2: vkeyamfe.jpg --]
[-- Type: image/jpeg, Size: 4814 bytes --]
[-- Attachment #2: Type: text/plain, Size: 151 bytes --]
_______________________________________________
Help-gnu-emacs mailing list
Help-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-04-21 11:56 Роман
0 siblings, 0 replies; 106+ messages in thread
From: Роман @ 2004-04-21 11:56 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 3748 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2004-03-11 11:22 Romia Fersi
0 siblings, 0 replies; 106+ messages in thread
From: Romia Fersi @ 2004-03-11 11:22 UTC (permalink / raw)
Help-gnu-emacs
Usted sabe que si su sitio web esta indexado en buscadores
USTED VENDE MAS
Pero de nada sirve aparecer en el puesto 24.728 de Google o Yahoo...
Si quiere que su web este en los PRIMEROS LUGARES
de la mayoria de los buscadores...
ESTE MAIL ES PARA USTED
Creamos PAGINAS ESPEJO para hacer subir su web hasta el Top del Ranking
Para mas informacion visite la seccion PAGINAS ESPEJO en
http://www.publicidadglobal.com.ar
Este mail se envia por unica vez a help-gnu-emacs@gnu.org
No hace falta removerse.
Gracias Help-gnu-emacs
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:
@ 2002-06-10 22:22 Emiliano La Licata
0 siblings, 0 replies; 106+ messages in thread
From: Emiliano La Licata @ 2002-06-10 22:22 UTC (permalink / raw)
confirm 785958
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:ȸ½ÅÇÕ´Ï´Ù.
@ 2002-04-10 11:41 ¿¬Áö
0 siblings, 0 replies; 106+ messages in thread
From: ¿¬Áö @ 2002-04-10 11:41 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 528 bytes --]
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re:Àú ¿¹¿ä..
@ 2002-04-04 22:49 Áö¿µ
0 siblings, 0 replies; 106+ messages in thread
From: Áö¿µ @ 2002-04-04 22:49 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 528 bytes --]
^ permalink raw reply [flat|nested] 106+ messages in thread
* re:¿äûÇϽŠÀÚ·áÀÔ´Ï´Ù.
@ 2002-04-01 7:39 °í°´Áö¿øÆÀ
0 siblings, 0 replies; 106+ messages in thread
From: °í°´Áö¿øÆÀ @ 2002-04-01 7:39 UTC (permalink / raw)
[-- Attachment #1: Type: text/html, Size: 348 bytes --]
^ permalink raw reply [flat|nested] 106+ messages in thread
end of thread, other threads:[~2023-02-17 15:41 UTC | newest]
Thread overview: 106+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-18 18:30 Josep Maria
-- 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
2022-01-20 14:13 Roger Mason
2022-01-20 19:57 ` Immanuel Litzroth
2022-01-20 19:58 ` Re: Roger Mason
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: Константин Куликов
2008-08-06 15:50 Re: Michaël Parienti
2008-08-06 16:57 ` Re: Paul R
2007-04-04 19:09 (unknown) Jost Burkardt
2007-04-05 0:26 ` Jason F. McBrayer
2005-12-03 23:03 Re: solenoids
2005-09-27 14:03 Re: avtologistic
2005-09-18 14:11 Re: Art
2005-09-10 14:39 Re: Abdulaim
2005-08-29 20:51 Re: Alifgin
2005-08-11 16:17 Re: от Александр
2005-07-06 17:37 Re: Ishok
2005-07-05 23:11 Re: Maxus
2005-06-30 18:50 Alex Claire
2005-06-14 23:56 Вера
2005-06-13 21:36 Re: Карина
2005-06-06 10:27 Re: Нина
2005-05-10 17:54 Re: Mariorisa
2005-05-04 17:05 Re: info
2005-04-21 7:57 Re: webmaster
2005-03-28 15:10 Re: info
2005-03-20 5:29 Re: info
2005-03-08 14:48 (no subject) Gian Uberto Lauri
2005-03-08 21:02 ` Peter Dyballa
2005-03-08 21:14 ` Re: Gian Uberto Lauri
2005-03-08 21:24 ` Re: Gian Uberto Lauri
2005-03-03 8:38 Re: support
2005-03-02 5:19 Re: PEREEZDI
2005-02-17 3:39 Re: root
2005-01-28 21:22 Re: Budget
2005-01-24 15:54 Re: support
2005-01-20 2:22 Re: Евгения Гордеевна
2005-01-12 15:30 Re: Сабина Елизаровна
2005-01-11 13:47 Re: Info
2005-01-06 13:53 Re: Документ
2005-01-06 12:16 Re: Документ
2004-12-21 16:08 Re: Алина Соломоновна
2004-12-21 11:12 Re: Маргарита Валериановна
2004-12-15 19:39 Re: Эмма Ульяновна
2004-12-15 17:55 Re: Анжела Геннадиевна
2004-12-12 17:13 Re: Зинаида Аверьяновна
2004-12-10 23:05 Re: Розалия Самойловна
2004-11-29 6:09 Re: Эльвира Викентьевна
2004-11-28 18:11 Re: Ева Давидовна
2004-11-26 21:10 Re: Robbie Womack
2004-11-26 18:31 Re: Joel Bradford
2004-11-11 11:56 Re: Майя Исааковна
2004-11-09 3:13 Re: Регина Валериановна
2004-11-02 19:59 Re: Центр тарифной политики ОАО "РЖД"
2004-11-02 4:00 Re: Центр тарифной политики ОАО "РЖД"
2004-10-21 16:59 Re: Евгения Елизаровна
2004-10-21 15:36 Re: Елизавета Аверьяновна
2004-10-10 18:55 Re: John Gard
2004-10-10 18:45 Re: John Gard
2004-09-07 7:12 Re: Ярослав Леонидович
2004-08-08 11:28 Re: lefthand
2004-08-08 10:41 Re: lefthand
2004-08-08 6:42 Re: lefthand
2004-07-29 2:53 Re: info
2004-07-29 2:53 Re: info
2004-07-23 22:19 Re: sugih
2004-07-23 16:17 Re: Murray
2004-07-20 13:58 Re: Vhdl-mode
2004-07-20 13:15 Re: Vhdl-mode
2004-06-26 5:49 Re: Востросаблина Карина
2004-06-13 3:14 Re: Язикова Изабелла
2004-06-11 18:58 Re: Валерий Ланшаков
2004-06-10 22:33 Re: Чагинова Снежана
2004-06-10 15:15 Re: Валерий Ланшаков
2004-06-06 16:08 Re: Щербухина Вероника
2004-06-06 7:43 Re: Валерий Ланшаков
2004-05-31 4:05 Re: Будищева Сабина
2004-05-24 1:55 Re: Резенкова Надежда
2004-05-23 5:34 Re: Горемыкина Оксана
2004-05-22 11:30 Re: Боровистова Эльза
2004-05-16 6:16 Re: Липинская Анна
2004-05-15 21:46 juli
2004-05-15 18:05 RE: juliy
2004-05-15 1:06 Лазлова Виктория
2004-05-12 18:20 Re: Аниськина Мария
2004-05-12 16:50 Re: Сеткова Лора
2004-05-12 16:50 Re: Рютина Ева
2004-05-12 0:59 Re: Манякина Наталья
2004-05-11 23:06 Re: Пыжьева Эмилия
2004-04-21 11:56 Re: Роман
2004-03-11 11:22 Re: Romia Fersi
2002-06-10 22:22 Re: Emiliano La Licata
2002-04-10 11:41 ¿¬Áö
2002-04-04 22:49 Re:Àú ¿¹¿ä Áö¿µ
2002-04-01 7:39 re:¿äûÇϽŠÀÚ·áÀÔ´Ï´Ù °í°´Áö¿øÆÀ
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
![[-- Attachment #2: to-gnu.emacs.star-20220102-140746.png --] [-- Type: image/png, Size: 370527 bytes --]](../../CAG9ihEvSeQgOJkZXmGg60bOGgjDr2jH+MQZ6pi44g0U9vG3PQg@mail.gmail.com/2-to-gnu.emacs.star-20220102-140746.png){kind=link}
