(unknown)

(unknown)

[Davin Pearson]

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

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

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

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

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

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

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



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

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

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

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

Re: none

[Stefan Monnier]

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

Change the `t` above to `prepend` or `append`.


        Stefan

Re:

[Eli Zaretskii]

> 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.

Re:

[Eli Zaretskii]

[Please keep the list address on the CC.]

> From: Davin Pearson <davin.pearson@gmail.com>
> Date: Tue, 28 Dec 2021 16:58:50 +1300
> 
> In your email to me you said that one of the foreground colours
> will "win" and the other will be ignored.  What I want is the
> same thing for the background colour.  As far as I understand the
> winning foreground colour will be the one that is added last in
> the fontification spec, and with the symbol 'end added to
> font-lock-add-keywords.
> 
> Here is my font-lock-string-face
> 
> "assdsdasd"
> 
> Here is the text dmp-asdssd coloured in my choice of colours: red
> and green:
> 
> "dmp-asdssd" (*)
> 
> Here is the code that fontifies the above code.
> 
> (make-face 'dmp-face--line0--col1-red)
> (set-face-foreground 'dmp-face--line0--col1-red "#ff0000")
> (set-face-background 'dmp-face--line0--col1-red nil)
> (make-face-bold 'dmp-face--line0--col1-red)
> 
> (make-face 'dmp-face--line0--col2-green)
> (set-face-foreground 'dmp-face--line0--col2-green "#00ff00")
> (set-face-background 'dmp-face--line0--col2-green nil)
> (make-face-bold 'dmp-face--line0--col2-green)
> 
> (make-face 'dmp-face--line0--col3-blue)
> (set-face-foreground 'dmp-face--line0--col3-blue "#0000ff")
> (set-face-background 'dmp-face--line0--col3-blue nil)
> (make-face-bold 'dmp-face--line0--col3-blue)
> 
> Here are some useful constant strings:
> 
> (defvar dmp-defun-inner-regexp-less-dash+star "a-zA-Z0-9_.!@$%^&=<>/|+:;?~")
> (defvar dmp-defun-inner-regexp-less-dash      (concat ""  dmp-defun-inner-regexp-less-dash+star))
> (defvar dmp-defun-inner-regexp-less-star      (concat "-"  dmp-defun-inner-regexp-less-dash+star))
> (defvar dmp-defun-inner-regexp                (concat "-," dmp-defun-inner-regexp-less-dash+star))
> (defvar dmp-defun-outer-regexp                (concat "["  dmp-defun-inner-regexp            "]+"))
> (defvar dmp-bra                               "\\(^\\|[][ \t\r\n()'\",.:=]\\)")
> (defvar dmp-ket                               "\\($\\|[][ \t\r\n()\",.:=]\\)")
> 
> Here is the actual font lock code:
> 
> (defun dmp-getting--syntax-highlighting--online ()
>   (font-lock-add-keywords
>    'emacs-lisp-mode
>    '(
>      (, (format "\\(dmp[0-9]\\)\\(\\(-[%s]+\\)+\\)%s"
>                 dmp-defun-inner-regexp-less-dash
>                 dmp-ket)
>         (1 'dmp-face--line0--col1-red t)
>         (2 'dmp-face--line0--col2-green t)
>         )
>      (, (format "\\(dmp[0-9]\\(-[%s]+\\)\\)\\(\\([-_][-_]\\|:\\)[%s]+\\)%s"
>                 dmp-defun-inner-regexp-less-dash
>                 dmp-defun-inner-regexp
>                 dmp-ket)
>         (1 'dmp-face--line0--col1-red t)
>         (3 'dmp-face--line0--col2-green t))
>      (, (format "\\(dmp[0-9]*\\(-[%s]+\\)*\\)\\([_-][_-][%s]+\\)\\([_-][_-][%s]+\\)%s"
>                 *dmp-defun-inner-regexp-less-dash*
>                 *dmp-defun-inner-regexp*
>                 *dmp-defun-inner-regexp*
>                 *dmp-ket*)
>         (1 'dmp-face--line0--col1-red t)
>         (3 'dmp-face--line0--col2-green t)
>         (4 'dmp-face--line0--col3-blue t))
>      )
>    'end)
>   )
> (add-hook 'font-lock-mode-hook 'dmp-getting--syntax-highlighting--online 'APPEND)
> 
> Notice that in the text marked with a (*) the background colour
> of the above text is the same as the background colour of the
> screen.
> 
> When dmp-face--line0--col1-red, dmp-face--line0--col2-green and
> dmp-face--line0--col3-blue 's set-face-foreground set to nil, as it
> is above, I want the for the string face's background colour to
> show through as light blue in the fontification of dmp-asdssd.

I think this is something that your code does.  If I just merge two
faces, one with a background color, the other with a foreground color,
the result of the merge has the background of the first faces and the
foreground of the second.

So I conclude that something goes wrong in your
dmp-getting--syntax-highlighting--on-line function, or in how it
interacts with font-lock.

Re:

[Davin Pearson]

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

Could you please run my code on your machine to verify that it works on
your machine but not mine.

On Wed, 29 Dec 2021 at 06:51, Eli Zaretskii <eliz@gnu.org> wrote:

> [Please keep the list address on the CC.]
>
> > From: Davin Pearson <davin.pearson@gmail.com>
> > Date: Tue, 28 Dec 2021 16:58:50 +1300
> >
> > In your email to me you said that one of the foreground colours
> > will "win" and the other will be ignored.  What I want is the
> > same thing for the background colour.  As far as I understand the
> > winning foreground colour will be the one that is added last in
> > the fontification spec, and with the symbol 'end added to
> > font-lock-add-keywords.
> >
> > Here is my font-lock-string-face
> >
> > "assdsdasd"
> >
> > Here is the text dmp-asdssd coloured in my choice of colours: red
> > and green:
> >
> > "dmp-asdssd" (*)
> >
> > Here is the code that fontifies the above code.
> >
> > (make-face 'dmp-face--line0--col1-red)
> > (set-face-foreground 'dmp-face--line0--col1-red "#ff0000")
> > (set-face-background 'dmp-face--line0--col1-red nil)
> > (make-face-bold 'dmp-face--line0--col1-red)
> >
> > (make-face 'dmp-face--line0--col2-green)
> > (set-face-foreground 'dmp-face--line0--col2-green "#00ff00")
> > (set-face-background 'dmp-face--line0--col2-green nil)
> > (make-face-bold 'dmp-face--line0--col2-green)
> >
> > (make-face 'dmp-face--line0--col3-blue)
> > (set-face-foreground 'dmp-face--line0--col3-blue "#0000ff")
> > (set-face-background 'dmp-face--line0--col3-blue nil)
> > (make-face-bold 'dmp-face--line0--col3-blue)
> >
> > Here are some useful constant strings:
> >
> > (defvar dmp-defun-inner-regexp-less-dash+star
> "a-zA-Z0-9_.!@$%^&=<>/|+:;?~")
> > (defvar dmp-defun-inner-regexp-less-dash      (concat ""
> dmp-defun-inner-regexp-less-dash+star))
> > (defvar dmp-defun-inner-regexp-less-star      (concat "-"
> dmp-defun-inner-regexp-less-dash+star))
> > (defvar dmp-defun-inner-regexp                (concat "-,"
> dmp-defun-inner-regexp-less-dash+star))
> > (defvar dmp-defun-outer-regexp                (concat "["
> dmp-defun-inner-regexp            "]+"))
> > (defvar dmp-bra                               "\\(^\\|[][
> \t\r\n()'\",.:=]\\)")
> > (defvar dmp-ket                               "\\($\\|[][
> \t\r\n()\",.:=]\\)")
> >
> > Here is the actual font lock code:
> >
> > (defun dmp-getting--syntax-highlighting--online ()
> >   (font-lock-add-keywords
> >    'emacs-lisp-mode
> >    '(
> >      (, (format "\\(dmp[0-9]\\)\\(\\(-[%s]+\\)+\\)%s"
> >                 dmp-defun-inner-regexp-less-dash
> >                 dmp-ket)
> >         (1 'dmp-face--line0--col1-red t)
> >         (2 'dmp-face--line0--col2-green t)
> >         )
> >      (, (format
> "\\(dmp[0-9]\\(-[%s]+\\)\\)\\(\\([-_][-_]\\|:\\)[%s]+\\)%s"
> >                 dmp-defun-inner-regexp-less-dash
> >                 dmp-defun-inner-regexp
> >                 dmp-ket)
> >         (1 'dmp-face--line0--col1-red t)
> >         (3 'dmp-face--line0--col2-green t))
> >      (, (format
> "\\(dmp[0-9]*\\(-[%s]+\\)*\\)\\([_-][_-][%s]+\\)\\([_-][_-][%s]+\\)%s"
> >                 *dmp-defun-inner-regexp-less-dash*
> >                 *dmp-defun-inner-regexp*
> >                 *dmp-defun-inner-regexp*
> >                 *dmp-ket*)
> >         (1 'dmp-face--line0--col1-red t)
> >         (3 'dmp-face--line0--col2-green t)
> >         (4 'dmp-face--line0--col3-blue t))
> >      )
> >    'end)
> >   )
> > (add-hook 'font-lock-mode-hook 'dmp-getting--syntax-highlighting--online
> 'APPEND)
> >
> > Notice that in the text marked with a (*) the background colour
> > of the above text is the same as the background colour of the
> > screen.
> >
> > When dmp-face--line0--col1-red, dmp-face--line0--col2-green and
> > dmp-face--line0--col3-blue 's set-face-foreground set to nil, as it
> > is above, I want the for the string face's background colour to
> > show through as light blue in the fontification of dmp-asdssd.
>
> I think this is something that your code does.  If I just merge two
> faces, one with a background color, the other with a foreground color,
> the result of the merge has the background of the first faces and the
> foreground of the second.
>
> So I conclude that something goes wrong in your
> dmp-getting--syntax-highlighting--on-line function, or in how it
> interacts with font-lock.
>

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

Re:

[Anders Lindgren]

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

Hi!

I just noticed that all your font-lock rules have specified "t" as the
OVERRIDE flag. This has the effect that the face in the rule replaces the
existing face. Instead, if you use 'prepend' or 'append' it will place both
faces on the text. With 'append' the new face will come before the old
face. (If the two faces both define a face property, the first face in the
list takes precedence.)

You can check the result for yourself. If you eval '(buffer-substring
(point) (+ (point) 1))' where you want both faces to be applied, the value
of the 'face' property should be a list of faces.

    -- Anders

On Wed, Dec 29, 2021 at 12:43 AM Davin Pearson <davin.pearson@gmail.com>
wrote:

> Could you please run my code on your machine to verify that it works on
> your machine but not mine.
>
> On Wed, 29 Dec 2021 at 06:51, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> [Please keep the list address on the CC.]
>>
>> > From: Davin Pearson <davin.pearson@gmail.com>
>> > Date: Tue, 28 Dec 2021 16:58:50 +1300
>> >
>> > In your email to me you said that one of the foreground colours
>> > will "win" and the other will be ignored.  What I want is the
>> > same thing for the background colour.  As far as I understand the
>> > winning foreground colour will be the one that is added last in
>> > the fontification spec, and with the symbol 'end added to
>> > font-lock-add-keywords.
>> >
>> > Here is my font-lock-string-face
>> >
>> > "assdsdasd"
>> >
>> > Here is the text dmp-asdssd coloured in my choice of colours: red
>> > and green:
>> >
>> > "dmp-asdssd" (*)
>> >
>> > Here is the code that fontifies the above code.
>> >
>> > (make-face 'dmp-face--line0--col1-red)
>> > (set-face-foreground 'dmp-face--line0--col1-red "#ff0000")
>> > (set-face-background 'dmp-face--line0--col1-red nil)
>> > (make-face-bold 'dmp-face--line0--col1-red)
>> >
>> > (make-face 'dmp-face--line0--col2-green)
>> > (set-face-foreground 'dmp-face--line0--col2-green "#00ff00")
>> > (set-face-background 'dmp-face--line0--col2-green nil)
>> > (make-face-bold 'dmp-face--line0--col2-green)
>> >
>> > (make-face 'dmp-face--line0--col3-blue)
>> > (set-face-foreground 'dmp-face--line0--col3-blue "#0000ff")
>> > (set-face-background 'dmp-face--line0--col3-blue nil)
>> > (make-face-bold 'dmp-face--line0--col3-blue)
>> >
>> > Here are some useful constant strings:
>> >
>> > (defvar dmp-defun-inner-regexp-less-dash+star
>> "a-zA-Z0-9_.!@$%^&=<>/|+:;?~")
>> > (defvar dmp-defun-inner-regexp-less-dash      (concat ""
>> dmp-defun-inner-regexp-less-dash+star))
>> > (defvar dmp-defun-inner-regexp-less-star      (concat "-"
>> dmp-defun-inner-regexp-less-dash+star))
>> > (defvar dmp-defun-inner-regexp                (concat "-,"
>> dmp-defun-inner-regexp-less-dash+star))
>> > (defvar dmp-defun-outer-regexp                (concat "["
>> dmp-defun-inner-regexp            "]+"))
>> > (defvar dmp-bra                               "\\(^\\|[][
>> \t\r\n()'\",.:=]\\)")
>> > (defvar dmp-ket                               "\\($\\|[][
>> \t\r\n()\",.:=]\\)")
>> >
>> > Here is the actual font lock code:
>> >
>> > (defun dmp-getting--syntax-highlighting--online ()
>> >   (font-lock-add-keywords
>> >    'emacs-lisp-mode
>> >    '(
>> >      (, (format "\\(dmp[0-9]\\)\\(\\(-[%s]+\\)+\\)%s"
>> >                 dmp-defun-inner-regexp-less-dash
>> >                 dmp-ket)
>> >         (1 'dmp-face--line0--col1-red t)
>> >         (2 'dmp-face--line0--col2-green t)
>> >         )
>> >      (, (format
>> "\\(dmp[0-9]\\(-[%s]+\\)\\)\\(\\([-_][-_]\\|:\\)[%s]+\\)%s"
>> >                 dmp-defun-inner-regexp-less-dash
>> >                 dmp-defun-inner-regexp
>> >                 dmp-ket)
>> >         (1 'dmp-face--line0--col1-red t)
>> >         (3 'dmp-face--line0--col2-green t))
>> >      (, (format
>> "\\(dmp[0-9]*\\(-[%s]+\\)*\\)\\([_-][_-][%s]+\\)\\([_-][_-][%s]+\\)%s"
>> >                 *dmp-defun-inner-regexp-less-dash*
>> >                 *dmp-defun-inner-regexp*
>> >                 *dmp-defun-inner-regexp*
>> >                 *dmp-ket*)
>> >         (1 'dmp-face--line0--col1-red t)
>> >         (3 'dmp-face--line0--col2-green t)
>> >         (4 'dmp-face--line0--col3-blue t))
>> >      )
>> >    'end)
>> >   )
>> > (add-hook 'font-lock-mode-hook
>> 'dmp-getting--syntax-highlighting--online 'APPEND)
>> >
>> > Notice that in the text marked with a (*) the background colour
>> > of the above text is the same as the background colour of the
>> > screen.
>> >
>> > When dmp-face--line0--col1-red, dmp-face--line0--col2-green and
>> > dmp-face--line0--col3-blue 's set-face-foreground set to nil, as it
>> > is above, I want the for the string face's background colour to
>> > show through as light blue in the fontification of dmp-asdssd.
>>
>> I think this is something that your code does.  If I just merge two
>> faces, one with a background color, the other with a foreground color,
>> the result of the merge has the background of the first faces and the
>> foreground of the second.
>>
>> So I conclude that something goes wrong in your
>> dmp-getting--syntax-highlighting--on-line function, or in how it
>> interacts with font-lock.
>>
>

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

Re:

[Davin Pearson]

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

I have factored out enough code to make debugging
my code easier for yous.  Note that the 'append
and the 'prepend options do not appear to work.

The only code which shows some sense of elegance
is the t option which fontifies ghi but instead of showing
just one layer of fontification shows the string ghi in
the bold face (i.e. overwriting the font-lock-string-face).

(remove-hook 'font-lock-mode-hook 'dmp-my-fonts)
(add-hook 'font-lock-mode-hook 'dmp-my-fonts)

(defun dmp-my-fonts ()
  (font-lock-add-keywords
   'emacs-lisp-mode
   `(
     ("abc" 0 'bold 'append)
     ("def" 0 'bold 'prepend)
     ("ghi" 0 'bold t)
     ("jkl" 0 'bold 't)
     )
   'end))

(progn
  (setq abc 123)
  (setq def 123)
  (setq ghi 123)
  (setq jkl 123)
  )

 "abc" abc
 "def" def
 "ghi" ghi
 "jkl" jkl

(buffer-substring (point) (+ (point) 1)) evalled
on the above returns

#("e" 0 1 (fontified t face font-lock-string-face))

when evalled on the strings

and this on the symbols

#("e" 0 1 (fontified t))

except for ghi which returns

#("h" 0 1 (fontified t face bold))

See the attached file for a pictorial version of my code and what it does.

On Sat, 1 Jan 2022 at 04:23, Anders Lindgren <andlind@gmail.com> wrote:

> Hi!
>
> I just noticed that all your font-lock rules have specified "t" as the
> OVERRIDE flag. This has the effect that the face in the rule replaces the
> existing face. Instead, if you use 'prepend' or 'append' it will place both
> faces on the text. With 'append' the new face will come before the old
> face. (If the two faces both define a face property, the first face in the
> list takes precedence.)
>
> You can check the result for yourself. If you eval '(buffer-substring
> (point) (+ (point) 1))' where you want both faces to be applied, the value
> of the 'face' property should be a list of faces.
>
>     -- Anders
>
> On Wed, Dec 29, 2021 at 12:43 AM Davin Pearson <davin.pearson@gmail.com>
> wrote:
>
>> Could you please run my code on your machine to verify that it works on
>> your machine but not mine.
>>
>> On Wed, 29 Dec 2021 at 06:51, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> [Please keep the list address on the CC.]
>>>
>>> > From: Davin Pearson <davin.pearson@gmail.com>
>>> > Date: Tue, 28 Dec 2021 16:58:50 +1300
>>> >
>>> > In your email to me you said that one of the foreground colours
>>> > will "win" and the other will be ignored.  What I want is the
>>> > same thing for the background colour.  As far as I understand the
>>> > winning foreground colour will be the one that is added last in
>>> > the fontification spec, and with the symbol 'end added to
>>> > font-lock-add-keywords.
>>> >
>>> > Here is my font-lock-string-face
>>> >
>>> > "assdsdasd"
>>> >
>>> > Here is the text dmp-asdssd coloured in my choice of colours: red
>>> > and green:
>>> >
>>> > "dmp-asdssd" (*)
>>> >
>>> > Here is the code that fontifies the above code.
>>> >
>>> > (make-face 'dmp-face--line0--col1-red)
>>> > (set-face-foreground 'dmp-face--line0--col1-red "#ff0000")
>>> > (set-face-background 'dmp-face--line0--col1-red nil)
>>> > (make-face-bold 'dmp-face--line0--col1-red)
>>> >
>>> > (make-face 'dmp-face--line0--col2-green)
>>> > (set-face-foreground 'dmp-face--line0--col2-green "#00ff00")
>>> > (set-face-background 'dmp-face--line0--col2-green nil)
>>> > (make-face-bold 'dmp-face--line0--col2-green)
>>> >
>>> > (make-face 'dmp-face--line0--col3-blue)
>>> > (set-face-foreground 'dmp-face--line0--col3-blue "#0000ff")
>>> > (set-face-background 'dmp-face--line0--col3-blue nil)
>>> > (make-face-bold 'dmp-face--line0--col3-blue)
>>> >
>>> > Here are some useful constant strings:
>>> >
>>> > (defvar dmp-defun-inner-regexp-less-dash+star
>>> "a-zA-Z0-9_.!@$%^&=<>/|+:;?~")
>>> > (defvar dmp-defun-inner-regexp-less-dash      (concat ""
>>> dmp-defun-inner-regexp-less-dash+star))
>>> > (defvar dmp-defun-inner-regexp-less-star      (concat "-"
>>> dmp-defun-inner-regexp-less-dash+star))
>>> > (defvar dmp-defun-inner-regexp                (concat "-,"
>>> dmp-defun-inner-regexp-less-dash+star))
>>> > (defvar dmp-defun-outer-regexp                (concat "["
>>> dmp-defun-inner-regexp            "]+"))
>>> > (defvar dmp-bra                               "\\(^\\|[][
>>> \t\r\n()'\",.:=]\\)")
>>> > (defvar dmp-ket                               "\\($\\|[][
>>> \t\r\n()\",.:=]\\)")
>>> >
>>> > Here is the actual font lock code:
>>> >
>>> > (defun dmp-getting--syntax-highlighting--online ()
>>> >   (font-lock-add-keywords
>>> >    'emacs-lisp-mode
>>> >    '(
>>> >      (, (format "\\(dmp[0-9]\\)\\(\\(-[%s]+\\)+\\)%s"
>>> >                 dmp-defun-inner-regexp-less-dash
>>> >                 dmp-ket)
>>> >         (1 'dmp-face--line0--col1-red t)
>>> >         (2 'dmp-face--line0--col2-green t)
>>> >         )
>>> >      (, (format
>>> "\\(dmp[0-9]\\(-[%s]+\\)\\)\\(\\([-_][-_]\\|:\\)[%s]+\\)%s"
>>> >                 dmp-defun-inner-regexp-less-dash
>>> >                 dmp-defun-inner-regexp
>>> >                 dmp-ket)
>>> >         (1 'dmp-face--line0--col1-red t)
>>> >         (3 'dmp-face--line0--col2-green t))
>>> >      (, (format
>>> "\\(dmp[0-9]*\\(-[%s]+\\)*\\)\\([_-][_-][%s]+\\)\\([_-][_-][%s]+\\)%s"
>>> >                 *dmp-defun-inner-regexp-less-dash*
>>> >                 *dmp-defun-inner-regexp*
>>> >                 *dmp-defun-inner-regexp*
>>> >                 *dmp-ket*)
>>> >         (1 'dmp-face--line0--col1-red t)
>>> >         (3 'dmp-face--line0--col2-green t)
>>> >         (4 'dmp-face--line0--col3-blue t))
>>> >      )
>>> >    'end)
>>> >   )
>>> > (add-hook 'font-lock-mode-hook
>>> 'dmp-getting--syntax-highlighting--online 'APPEND)
>>> >
>>> > Notice that in the text marked with a (*) the background colour
>>> > of the above text is the same as the background colour of the
>>> > screen.
>>> >
>>> > When dmp-face--line0--col1-red, dmp-face--line0--col2-green and
>>> > dmp-face--line0--col3-blue 's set-face-foreground set to nil, as it
>>> > is above, I want the for the string face's background colour to
>>> > show through as light blue in the fontification of dmp-asdssd.
>>>
>>> I think this is something that your code does.  If I just merge two
>>> faces, one with a background color, the other with a foreground color,
>>> the result of the merge has the background of the first faces and the
>>> foreground of the second.
>>>
>>> So I conclude that something goes wrong in your
>>> dmp-getting--syntax-highlighting--on-line function, or in how it
>>> interacts with font-lock.
>>>
>>

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

[-- Attachment #2: to-gnu.emacs.star-20220102-140746.png --]
[-- Type: image/png, Size: 370527 bytes --]

Re:

[Stefan Monnier]

>      ("abc" 0 'bold 'append)

No wonder it doesn't work: while the 3rd element of the above list is an
ELisp expression passed to `eval`, the 4th is not, so the quote before
`append` shouldn't be there.


        Stefan

Re:

[Davin Pearson]

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

Thanking you so much Anders for debugging my Elisp code.

Everything works perfectly fine with the quote removed from in front of the
append.

Thank you to Eli Zaretskii for your additional help!

On Sun, 2 Jan 2022 at 18:19, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >      ("abc" 0 'bold 'append)
>
> No wonder it doesn't work: while the 3rd element of the above list is an
> ELisp expression passed to `eval`, the 4th is not, so the quote before
> `append` shouldn't be there.
>
>
>         Stefan
>
>

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

Re: Make all tree-sitter modes optional

[Alan Mackenzie]

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).

Re: Make all tree-sitter modes optional

[Eli Zaretskii]

> 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.

Re: Make all tree-sitter modes optional

[Alan Mackenzie]

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).

Re: Make all tree-sitter modes optional

[Po Lu]

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.

Re: Make all tree-sitter modes optional

[Stefan Monnier]

> 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

Re: Make all tree-sitter modes optional

[Po Lu]

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.

Re: Make all tree-sitter modes optional

[Eli Zaretskii]

> 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

Re: Make all tree-sitter modes optional

[Dmitry Gutov]

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?

Re: Make all tree-sitter modes optional

[Eli Zaretskii]

> 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.)

Re:

[Alan Mackenzie]

Hello, Dick.

On Fri, Feb 17, 2023 at 10:24:43 -0500, dick wrote:
> EZ> Or I step down

> This wouldn't be the first time you've threatened that when you were on
> the wrong side of history.  Examples include bzr-to-git and pdumper.

> Perhaps now is the time to make good.  I know at least one person
> who'd like to take the reins.

Please refrain from making such unhelpful, and unnecessarily personl
insinuations.  They go against the respectful tenor which prevails on
this mailing list and, I think, are unwanted by everybody here.

Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

(no subject)

[Roger Mason]

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

Re:

[Immanuel Litzroth]

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

Re:

[Roger Mason]

Immanuel Litzroth <immanuel.litzroth@gmail.com> writes:

> 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

Indeed, that was it.  Many thanks,
Roger

Re:

[Angelo Graziosi]

> 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.

Re:

[Pedro Andres Aranda Gutierrez]

[-- 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 --]

wait_reading_process_ouput hangs in certain cases (w/ patches)

[Matthias Dahl]

[-- 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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Eli Zaretskii]

> 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.

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Eli Zaretskii]

> 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.

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Paul Eggert]

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.

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Matthias Dahl]

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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Paul Eggert]

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.

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Matthias Dahl]

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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Paul Eggert]

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.

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Matthias Dahl]

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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Matthias Dahl]

[-- 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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Paul Eggert]

> +  /* 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.

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Matthias Dahl]

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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Matthias Dahl]

[-- 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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Eli Zaretskii]

> 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.

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Lars Ingebrigtsen]

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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[andres.ramirez]

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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Matthias Dahl]

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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[andrés ramírez]

> 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). 

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Lars Ingebrigtsen]

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

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[andrés ramírez]

> 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).

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Daniel Colascione]

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?

Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[andrés ramírez]

> 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

Re:

[Daniel Colascione]

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.

Re:

[andrés ramírez]

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.

(unknown)

[steve]

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

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

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

Re:

[Artur Malabarba]

[-- 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 --]

Re:

[Steve Purcell]

> 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.

Re:

[Artur Malabarba]

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

On 8 Feb 2016 5:05 pm, "Steve Purcell" <steve@sanityinc.com> wrote:
> 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.

Yes. I'm not familiar with the fine details of SQL syntax, but \\w\\|\\s is
generally a better bet than just \\w.

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

Re:

[Константин Куликов]

[-- 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 --]

Re:

[Michaël Parienti]

 
 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

Re:

[Paul R]

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

(unknown)

[Jost Burkardt]

Hi,

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

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

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

What do you think?
Jost

Re:

[Jason F. McBrayer]

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    |

Re:

[solenoids]

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]

Re:

[avtologistic]

============================================================
Автомобильные грузоперевозки по России.
 
Имея собственный парк автотранспорта
от 15 куб. м до 120 куб.м, грузоподъемностью от 2 до 22 тонн, 
квалифицированные менеджеры позволят минимизировать расходы
по доставке Вашего груза. 


тел.(095) 920-1582, 8 - 916-119-06 05, avtologistic@postmaster.co.uk
============================================================

Автомобильные грузоперевозки от компании "Автологистик" 
- это гарантия надежной доставки Ваших грузов. 

Re:

[Art]

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

Re:

[Abdulaim]

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

Re:

[Alifgin]

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

Re:

[от Александр]

Строительная компания ООО "КРИЭЙТ" выполняет: 

Строительство  коттеджей  и  домов  из  любого  материала а также сопутствующих построек беседок, бань и.т.д.  
Ремонтные  работы  любой  сложности  квартир  и  офисов. Инженерные сети и коммуникации (водоснабжение, отопление, вентиляция и электромонтажные работы).
Изготовление и установка под заказ клиента окон и дверей из трехслойного клееного бруса и пластика.
Заключение договора. Поэтапная оплата. Гарантия на работу. 

Лицензия : Д 575244

тел: (095)  743-64-94
                  514-31-49 
                  514-31-73

Изготавливаем и устанавливаем деревянные евро-окна, лоджии и двери под заказ

тел: (095) 514-31-49, 8-926-580-76-34.

Re:

[Ishok]

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

Re:

[Maxus]

[-- 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 --]

re:

[Alex Claire]

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

Re:

[Вера]

Была на выставке Эрос-2005. Видела потрясающий товарчик. Держи
ссылку на www.RusGal.ru Не пожалеешь!




























"Иногдамыловимсебянатом,чтоменяемнашимнениябезвсякого
Внастоящеевремясуществуетпятьосновныхспособовподсоединенияк
обрадовавшись этому всему -- живому, яркому и бедному, что двигалось, дышало
выдержит и отменит свое приказание.
--Обождиздесь,--сказал,соскакиваяназемлюизабрасываяповодна
бугре неясно  заплясали  четыре конные  фигуры. Левинсон  свернул в кусты  и
Ейудалосьподнятьегонаноги,итак,увещеваяегоиотвлекаяот
ИринаЦарик
Таким образом, все химические, геохимические и геологические данные с несомненностью свидетельствуют об органическом происхождении нефти.
и  бессмысленно исполняли бы то дело, какое угодно было Колчаку?  Но это  же
сделанного за неделю. После обеда я ухожу к себе, открываю  свою  книгу  и
СН3–(СН2)6–СН2:СН2–(СН2)6–СН3t

Re:

[Карина]

[-- 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 --]

Re:

[Нина]

# В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  ни  королевство,  ни
тайны, приносящей успех в деловых контактах...  Исключительно  внимание  к
темно-зеленая, поросшая  ряской,  поверхность  вздувалась упругими  волнами,
ушей   новое  замечание  взводного.  Увидев,  однако,  что  тот   собирается

Re:

[Mariorisa]

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

Re:

[info]

...............тел. (905) 2039072................
...............тел. (095) 1363041................
.................ася 292593973................... 
..................сайт 8811.ws...................

Вы заинтересованы в увеличении количества клиентов? 

Обращаем Ваше внимание на то, что наша компания помогает решать 
подобные задачи стоящие перед Вашим бизнесом. 
Способ решения ваших проблем – электронные письма в сети Интернет!

........................................................
 ... Просто, легко, практично, конкретно, быстро! ...








БОРИСОВНЫ БЫВШЕЙ, Аркадий

Английские, Аомыне Академсеть

Re:

[webmaster]

[-- 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 --]

Re:

[info]

:::. Оптовая рaспродaжa aксессуaров для сотовых телефонов! .:::

          !!! супер низкие цены !!!

 Зaрядные устройства (сетевые и автомобильные), корпуса, шнурки, брелки,
 чехлы из нaтуральной кожи, силиконовые и др. 


     +-- Тел. 8(O95)  68З-49-44 --+
   +-- Тел/Фaк: 8(O95) 188-89-46 --+
   +-- E-mail: igorkurilov@gawab.com --+

Re:

[info]

^[$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/

(no subject)

[Gian Uberto Lauri]

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

Re:

[Peter Dyballa]

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

Re:

[Gian Uberto Lauri]

>>>>> "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

Re:

[Gian Uberto Lauri]

>>>>> "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

Re:

[support]

Электронные рассылки - это,
прежде всего донесение рекламы до высокодоходной,
активной, инновационной части целевой аудитории. 
Заинтересовало?
+7 905_203_90_72 
+7 905_144_53_18
http://8811.ws

Re:

[PEREEZDI]

[-- 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

Re:

[root]

[-- 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

Re:

[Budget]

[-- 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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;В х<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

Re:

[support]

[-- 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

Re:

[Евгения Гордеевна]

"Вы буд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

Re:

[Сабина Елизаровна]

!Р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

Re:

[Info]

Бизнес Центр
«НАЦИОНАЛЬНЫЙ»

Приглашает Вас на Семинары :

МАРКЕТИНГОВЫЕ ИССЛЕДОВАНИЯ СВОИМИ СИЛАМИ

и

ПРОДВИЖЕНИЕ ТОВАРОВ И УСЛУГ: СИСТЕМНЫЙ ПОДХОД


г. Киев, бульв. Шевченко 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

Re:..

[Документ]

[-- 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

Re:..

[Документ]

[-- 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

Re:

[Алина Соломоновна]

[-- 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

Re:

[Маргарита Валериановна]

[-- 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

Re:

[Эмма Ульяновна]

Внимание акция!
3akaжитe до 2О дekaбря Е-Mail paccылку и noлyчи бoнyc(paccылку no асе)....
 
(9О5)2О3-9О-72
reclamma@tom.com
icq 283673170

Re:

[Анжела Геннадиевна]

Внимание akция!
3akaжитe до 2O дekaбря Е-маil paccылку и noлyчи бoнyc(paccылкy по асе)....
 
(О95)1О9-57О6
raskrutim@tom.com
icq 283673170

Re:

[Зинаида Аверьяновна]

Внимание akция!
3akaжитe до 2O декабря Е-Mail paccылкy и noлyчи бoнyc(paccылку no iсq)....
 
accent@3432.cjb.net 

Re:

[Розалия Самойловна]

Внимание akция!
3akaжитe до 20 дekaбря Е-Mail paccылкy и noлyчи бонус(paccылкy по iсq)....
 
back@3432.cjb.net 

Re:

[Эльвира Викентьевна]

Внимание!
Только до 1 декабря 2OO4 года вы сможете заказать Е-Mail paccылку(платно) и получить paccылку по icq(бесплатно)....
 
alice@e881.cjb.net 

Re:

[Ева Давидовна]

Внимание!
Только до 1 декабря 2OO4 года вы сможете заказать Е-Mail paccылку(платно) и получить paccылку по icq(бесплатно)....
 
acquaintance@e881.cjb.net 

Re:

[Robbie Womack]

[-- 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

Re:

[Joel Bradford]

[-- 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

Re:

[Майя Исааковна]

[-- 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

Re:

[Регина Валериановна]

[-- 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

Re:

[Центр тарифной политики ОАО "РЖД"]

[-- 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

Re:

[Центр тарифной политики ОАО "РЖД"]

[-- 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

Re:

[Евгения Елизаровна]

[-- 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

Re:

[Елизавета Аверьяновна]

[-- 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

Re:

[John Gard]

[-- 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

Re:

[John Gard]

[-- 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

Re:

[Ярослав Леонидович]

[-- 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

Re:

[lefthand]

[-- 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

Re:

[lefthand]

[-- 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

Re:

[lefthand]

[-- 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

Re:

[info]

Бизнес - справочники, бизнес - программы, базы данных
на http://progz.port5.com

Re:

[info]

Бизнес - справочники, бизнес - программы, базы данных
на http://progz.8p.org.uk

Re:

[sugih]

[-- 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

Re:

[Murray]

[-- 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

Re:

[Vhdl-mode]

[-- 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

Re:

[Vhdl-mode]

[-- 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

Re:

[Востросаблина Карина]

[-- 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

Re:

[Язикова Изабелла]

[-- 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

Re:

[Валерий Ланшаков]

Предлагаем Базы Данных фирм и e-mail адресов для организации электронной 
коммерции на предприятии и ведения бизнеса в сети.
подробности на сайте   http://databasez.8bit.co.uk/ 

Re:

[Чагинова Снежана]

[-- 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

Re:

[Валерий Ланшаков]

Предлагаем Базы Данных фирм и e-mail адресов для организации электронной 
коммерции на предприятии и ведения бизнеса в сети.
подробности на сайте   http://databasez.p8.org.uk/ 

Re:

[Щербухина Вероника]

[-- 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

Re:

[Валерий Ланшаков]

Предлагаем Базы Данных фирм и e-mail адресов для организации электронной 
коммерции на предприятии и ведения бизнеса в сети.
подробности на сайте   http://allbases.7p.org.uk/ 

Re:

[Будищева Сабина]

В Бюро e-mail рассылок требуются менеджеры по работе с клиентами в крупных городах России и СНГ.
Обязательные  требования к кандидатам:
1. Наличие сотового телефона.
2. Опыт работы менеджером в любой сфере деятельности.
3. Минимальные знания банковских операций (перевод денежных средств, желательно наличие счета в банке, знание webmoney).
4. Знание Интернет (e-mail, ICQ).
5. Знание HTML
6. Деловые качества: Вежливость, общительность, решительность и оперативность.
7. Возраст 23-35 лет.

ПО ВОПРОСАМ СОТРУДНИЧЕСТВА ПРОСЬБА ОБРАЩАТЬСЯ ТОЛЬКО ПО - ICQ 349071146

Re:

[Резенкова Надежда]

[-- 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

Re:

[Горемыкина Оксана]

[-- 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

Re:

[Боровистова Эльза]

[-- 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

Re:

[Липинская Анна]

[-- 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

RE:

[juli]

[-- 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

RE:

[juliy]

[-- 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

Re:

[Лазлова Виктория]

[-- 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

Re:

[Аниськина Мария]

[-- 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

Re:

[Рютина Ева]

[-- 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

Re:

[Сеткова Лора]

[-- 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

Re:

[Манякина Наталья]

[-- 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

Re:

[Пыжьева Эмилия]

[-- 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

Re:

[Роман]

[-- 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

Re:

[Romia Fersi]

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

Re:

[Josep Maria]

[-- 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 --]

Re:

[Emiliano La Licata]

confirm 785958

Re:ȸ½ÅÇÕ´Ï´Ù.

[¿¬Áö]

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

Re:Àú ¿¹¿ä..

[Áö¿µ]

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

re:¿äûÇϽŠÀÚ·áÀÔ´Ï´Ù.

[°í°´Áö¿øÆÀ]

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