(no subject)

(no subject)

[Kenichi Handa]

With today's CVS, I found that makefile-mode got unusable
when font-lock is on.

When I visit, for instance, emacs/Makefile.in, it is
displayed with font-lock correctly fairly soon.  But when I
hit C-v, I feel a delay in displaying the next page.  When I
hit more C-v's, the screen update gets slower and slower,
and, at last Emacs hangups.  Typing C-g doesn't work.  Gdb
shows that Emacs is executing re-search-forward.

(gdb) xba
"re-search-forward"
"byte-code"
"makefile-match-dependency"
"font-lock-fontify-keywords-region"
"font-lock-default-fontify-region"
"font-lock-fontify-region"
"run-hook-with-args"
"byte-code"
"jit-lock-fontify-now"
"jit-lock-function"

Isn't it because of this change?

2005-05-16  Daniel Pfeiffer  <occitan@esperanto.org>

	* font-lock.el (lisp-font-lock-keywords-1): Set
	`font-lock-negation-char-face' for [^...] char group.
	(lisp-font-lock-keywords-2): Highlight regexp's \\( \\| \\).

	* progmodes/make-mode.el (makefile-dependency-regex): Turn it into
	a var, and refine it to mask one more level of nested vars.
	(makefile-rule-action-regex): Turn it into a var, and refine it so
	it recognizes backslashed continuation lines as belonging to the
	same command.
	(makefile-macroassign-regex): Refine it so it recognizes
	backslashed continuation lines as belonging to the same command.
	(makefile-var-use-regex): Don't look at the next char, because it
	might be the same one to be skipped by the initial [^$], leading
	to an overlooked variable use.
	(makefile-make-font-lock-keywords): Remove two parameters, which
	are now variables that some of the modes set locally.  Handle
	dependency and rule action matching through functions, because
	regexps alone match too often.  Dependency matching now comes
	last, so it can check, whether a colon already matched something
	else.
	(makefile-mode): Inform that font-lock improves makefile parsing
	capabilities.
	(makefile-match-dependency, makefile-match-action): New functions.

---
Ken'ichi HANDA
handa@m17n.org

(No subject)

[slb zetrov]

Hi,

tl;dr: By actually trying to implement the idea, I just realized that the idea
is flawed, and ‘exec-path-from-shell’ is necessary.

---

Thanks for pointing out ‘exec-path-from-shell’ can work on other situations and
‘parsenv’ to sync two versions of paths.

Problem is that users might have a lot of staffs inside ‘.bashrc’
‘.bash_profile’ and ‘.zshrc’, as a result, an embedded script just cannot be
simply imported to a shell session to figure the PATH.

The only way to properly get the PATH is to let the shell print the PATH and
read the results which is exactly what ‘exec-path-from-shell’ do.

---

Technically, Emacs.app and command-line Emacs "lives" in two different worlds.
Command-line Emacs lives in at a Unix environment. Emacs.app lives in macOS's
‘launchd‘ environment which is part of the desktop environment and it has a
specific set of env variables.

I guess the reason why some Linux desktop environments didn't provide right
PATH is they override the env variables or use a different technique to launch
applications. It might not be a bug but a feature.

---

Thanks!

Re: (No subject)

[Yuan Fu]

Can we implement something built-in? So paths works out-of-the-box and new users doesn’t need to google why Emacs can’t find xxx.

Yuan

Re: (No subject)

[Michael Albinus]

Yuan Fu <casouri@gmail.com> writes:

> Can we implement something built-in? So paths works out-of-the-box and
> new users doesn’t need to google why Emacs can’t find xxx.

Can we use a proper subject in messages? So users doen’t need to google
what is meant?

> Yuan

Best regards, Michael.

Re: [no subject]

[Chris Gregory]

Oops meant to reply to `Simplify internal_catch()'.

Anyway here is another patch with the same thing.
-- 
Chris Gregory

diff --git a/src/eval.c b/src/eval.c
index e50e26a..edb41b6 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1337,20 +1337,12 @@ internal_condition_case_1 (Lisp_Object (*bfun) (Lisp_Object), Lisp_Object arg,
 			   Lisp_Object (*hfun) (Lisp_Object))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val);
-    }
-  else
-    {
-      Lisp_Object val = bfun (arg);
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun (arg);
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val) : val;
 }
 
 /* Like internal_condition_case_1 but call BFUN with ARG1 and ARG2 as

(no subject)

[Richard Stallman]

bzr was slow on savannah due to the use of sftp.
Do people find bzr satisfactory now?


-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: (no subject)

[Werner LEMBERG]

> bzr was slow on savannah due to the use of sftp.
> Do people find bzr satisfactory now?

Well, I'm only doing `bzr pull', and it seems indeed to be more
responsive than previously.  However, the amount of data transferred
by bzr is still excessively large.  For example, updating from
rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull') used
more than 20MByte!  Looking at the amount of changes actually applied
to the repository, I estimate that git would need only approx. 200 to
300kByte ^[$(Q#|^[(B this is 70 to 100 times less...

It would be great if someone using an emacs git repository could
verify my estimation.

git compresses the data on the remote side before transferring it.
Does bzr omit that step?  Maybe I'm missing a bzr option?  Otherwise,
it looks like a severe flaw in the design.  Given that many users
(including me currently) use mobile internet connections which are
sometimes extremely slow due to weak signal strength, bandwidth *is*
an issue even today.


    Werner

Re: (no subject)

[Werner LEMBERG]

> Well, I'm only doing `bzr pull', and it seems indeed to be more
> responsive than previously.  However, the amount of data transferred
> by bzr is still excessively large.  For example, updating from
> rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull')
> used more than 20MByte!

I forgot to mention that I'm currently using bzr version 2.0.5 in case
this makes a difference w.r.t. the amount of transferred data.


    Werner

Re: (no subject)

[Richard Stallman]

    Well, I'm only doing `bzr pull', and it seems indeed to be more
    responsive than previously.  However, the amount of data transferred
    by bzr is still excessively large.  For example, updating from
    rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull') used
    more than 20MByte!  Looking at the amount of changes actually applied
    to the repository, I estimate that git would need only approx. 200 to
    300kByte   this is 70 to 100 times less...

    It would be great if someone using an emacs git repository could
    verify my estimation.

It would be interesting to set up parallel repositories, the latest
bzr and git, and update them at the same times.  Then it would be
possible to rigorously compare the amount of data transferred.

    git compresses the data on the remote side before transferring it.
    Does bzr omit that step?  Maybe I'm missing a bzr option?

It might be that the compression occurs in scp, and you're measuring
the amount of raw data rather than the amount actually transmitted.

But that's just a speculation.  It would be interesting to find out
for certain.

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

Re: (no subject)

[Glenn Morris]

Richard Stallman wrote:

> bzr was slow on savannah due to the use of sftp.
> Do people find bzr satisfactory now?

It is much improved and personally I find it satisfactory now, yes.

(no subject)

[Jambunathan K]

Emacs version.

,----
| GNU Emacs 23.1.91.1 (i386-mingw-nt5.1.2600) of 2010-01-03 on PRETEST
`----

I am using package.el 
http://github.com/davidswelt/aquamacs-emacs/raw/aquamacs24

(I hope it is as good as one in the trunk)

If I do M-x list-packages, I see that revert-buffer-function gets set to
package-menu-revert. The problem seems to be that it is having a
'global' effect so that a revert on an elisp buffer fails with

  "if: The current buffer is not a Package Menu"

Please take care of this if it is not already taken care of.

Jambunathan K.

(no subject)

[Drew Adams]

I've gotten this message for a while now when trying to visit the Emacs-Lisp
repository at
http://bazaar.launchpad.net/%7Evcs-imports/emacs/trunk/files/head%3A/lisp/:

 "Internal Server Error"

Is that still the correct URL?

(no subject)

[Xavier Maillard]

Hi,

In the NEWS file (for 23.1), I can read this:

*** diff-add-change-log-entries-other-window iterates through the diff
buffer and tries to create ChangeLog entries for each change.
It is bound to `C-x 4 A'.

If, for some reason, I have many diffs in a file, I would like
this to wait for me typing a log entry (if any) before inserting
yet another entry.

Currently, if I am doing C-x 4 A with my emacs.el file, it ends
up with something like:

2008-03-23  Xavier Maillard  <xma@gnu.org>

	* emacs.el:

	* emacs.el (Man-mode-hook):

	* emacs.el (lambda):

	* emacs.el (kbd):

	* emacs.el (kbd):

	* emacs.el (dired-mode-hook):

	* emacs.el (dired-mode-hook):

	* emacs.el (mm-body-charset-encoding-alist):

	* emacs.el:

	* emacs.el (emacs-lisp-mode-hook):

	* emacs.el (vc-diff-other-window):

	* emacs.el:

	* emacs.el:

So there are many "duplicate" and useless entries. A better
approach would have to split the window with on one side, the
diff entry and on the other side, the changelog buffer. This way
I could review better my change and add an accurate and
informative change message.

---------------------------------
| Diff buffer | Change log buffer|
----------------------------------
| a diff     => description      |
----------------------------------

If changelog could not find an accurate function/variable name to
put into parenthesis, then fail back to the "default" emacs.el
entry.

WDYT ?

	Xavier
--
http://www.gnu.org
http://www.april.org
http://www.lolica.org

(no subject)

[Herbert Euler]

Hi Alan,

I found cc mode signals an error.  To reproduce:

1. $ emacs -Q
2. C-x C-f x.c  (an empty file should be able to reproduce)
3. Type `#'

Emacs signals an error: "End of buffer".  I have located the position
that the error is signaled, it is in c-neutralize-syntax-in-CPP.  In
the above use case, this function is invoked as follows:

(c-neutralize-syntax-in-CPP 1 2 0)
error--> End of buffer

Regards,
Guanpeng Xu
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

(no subject)

[A Soare]

Can somebody recommend me a place (usenet/etcetera) where one speaks about problems of parsers/grammars? I found nothing to like so far.

Thanks in advance.

Re: (no subject)

[Stefan Monnier]

> Can somebody recommend me a place (usenet/etcetera) where one speaks about
> problems of parsers/grammars? I found nothing to like so far.

I have no idea what this has to do with Emacs, but comp.compilers seems like
the best place for it,


        Stefan

(no subject)

[A Soare]

Why it is not chosen another system to change the font using the mouse?


In this moment (default) to change the font I press SHIFT+[left mouse button] , then choose a font.

In general I receive the message << mouse-set-font: Font not found [2 times] >>. That is because there is no rule to select the fonts from the default list.

Why it is not assigned to SHIFT + LEFT-MOUSE-BUTTON a menu to choose:
- font color
- background color
- a list of fonts (and to dresse this list detecting at least whether the fonts are instlled in the system).

What do you say about this proposal. If the assoc list (buffer-name, color) cannot be implemented, maybe this solution would work better?

Alin Soare.

(no subject)

[A Soare]

Here is the indentation rewriten, and taking into consideration all problems we have just talked about.

If there are some other new problems, please report.


Alin  Soare


Index: emacs/lisp/emacs-lisp/lisp-mode.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/emacs-lisp/lisp-mode.el,v
retrieving revision 1.199
diff -c -r1.199 lisp-mode.el
*** emacs/lisp/emacs-lisp/lisp-mode.el	17 Feb 2007 11:34:22 -0000	1.199
--- emacs/lisp/emacs-lisp/lisp-mode.el	21 Feb 2007 22:26:09 -0000
***************
*** 908,942 ****
        (let ((normal-indent (current-column)))
          (cond ((elt state 3)
                 ;; Inside a string, don't change indentation.
! 	       nil)
!               ((save-excursion
!                  ;; test whether current line begins with a constant
!                  (goto-char indent-point)
!                  (skip-chars-forward " \t")
!                  (looking-at ":"))
!                (let ((desired-indent
!                       (save-excursion
!                         (goto-char (1+ containing-sexp))
!                         (parse-partial-sexp (point) calculate-lisp-indent-last-sexp 0 t)
!                         (point)))
!                      (parse-sexp-ignore-comments t))
!                  ;; Align a constant symbol under the last constant symbol
!                  (goto-char calculate-lisp-indent-last-sexp)
!                  (while (> (point) desired-indent)
!                    (if (looking-at ":")
!                        (setq desired-indent (point))
!                      (backward-sexp 1))))
!                  (current-column))
                ((and (integerp lisp-indent-offset) containing-sexp)
                 ;; Indent by constant offset
                 (goto-char containing-sexp)
                 (+ (current-column) lisp-indent-offset))
                (desired-indent)
-               ((and (boundp 'lisp-indent-function)
-                     lisp-indent-function
-                     (not retry))
-                (or (funcall lisp-indent-function indent-point state)
-                    normal-indent))
                (t
                 normal-indent))))))
  
--- 908,955 ----
        (let ((normal-indent (current-column)))
          (cond ((elt state 3)
                 ;; Inside a string, don't change indentation.
!                nil)
                ((and (integerp lisp-indent-offset) containing-sexp)
                 ;; Indent by constant offset
                 (goto-char containing-sexp)
                 (+ (current-column) lisp-indent-offset))
+               ((save-excursion
+                  ;; the car must be defined on the same line as the inner parenthesis.
+                  ;; in this case calculate-lisp-indent-last-sexp is not nil.
+                  (and containing-sexp
+                       (goto-char (1+ containing-sexp))
+                       (skip-chars-forward " \t")
+                       (looking-at "\\sw\\|\\s_")))
+                (or
+                 ;; try to align the parameters of a known function
+                 (and (boundp 'lisp-indent-function)
+                      lisp-indent-function
+                      (not retry)
+                      (funcall lisp-indent-function indent-point state))
+                 ;; if not a standard function, try to align a constant-symbol
+                 ;; under the last preceding constant symbol, if there is such one
+                 ;; of the last 2 preceding symbols, in the previous uncommented
+                 ;; line
+                 (and (save-excursion
+                        (goto-char indent-point)
+                        (skip-chars-forward " \t")
+                        (looking-at ":"))
+                      (let ((parse-sexp-ignore-comments t)
+                            indent)
+                        (goto-char calculate-lisp-indent-last-sexp)
+                        (if (looking-at ":")
+                            (setq indent (current-column))
+                          (when (and (> calculate-lisp-indent-last-sexp containing-sexp)
+                                     (< (save-excursion (beginning-of-line) (point))
+                                        (prog2 (backward-sexp) (point))))
+                            (if (looking-at ":")
+                                (setq indent (current-column)))))
+                        indent))
+                 ;; another symbols or constants not preceded by a constant
+                 ;; as defined above.
+                 normal-indent))
+               ;; in this case calculate-lisp-indent-last-sexp is nil
                (desired-indent)
                (t
                 normal-indent))))))

(no subject)

[Werner LEMBERG]

[CVS 2006-10-28]

I've just seen the following link in an email:

  http://www.google.com/codesearch?hl=en&q=+pango_layout_(iter_)%3Fget_(lines%3F%7Crun)%5B%5E_%5D&start=50&sa=N

As you can probably can see immediately, thingatpt only colorizes (and
uses) the string up to `..._layout_', stopping at the opening
parenthesis.

Is this intentional or is this a bug?


    Werner

Re: (no subject)

[Kevin Rodgers]

Werner LEMBERG wrote:
> [CVS 2006-10-28]
> 
> I've just seen the following link in an email:
> 
>   http://www.google.com/codesearch?hl=en&q=+pango_layout_(iter_)%3Fget_(lines%3F%7Crun)%5B%5E_%5D&start=50&sa=N
> 
> As you can probably can see immediately, thingatpt only colorizes (and
> uses) the string up to `..._layout_', stopping at the opening
> parenthesis.
> 
> Is this intentional or is this a bug?

It is intentional, as parentheses are explicitly excluded from URLs by
thing-at-point-url-path-regexp.  It could be a bug, as parentheses are
defined as reserved characters in URIs, which are only sometimes percent-
encoded, depending on the context; but I think they are allowed within
both the path and query components of generic URIs (without being
percent-encoded).

So just as the slashes in the URI above should not need to be %-encoded
(since they follow the ?, they are clearly within the query component),
neither should the parentheses need to be %-encoded -- but perhaps they
ought to be.

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: (no subject)

[Slawomir Nowaczyk]

On Thu, 21 Dec 2006 11:43:55 -0700
Kevin Rodgers <kevin.d.rodgers@gmail.com> wrote:

#> Werner LEMBERG wrote:
#> > [CVS 2006-10-28]
#> > 
#> > I've just seen the following link in an email:
#> > 
#> >   http://www.google.com/codesearch?hl=en&q=+pango_layout_(iter_)%3Fget_(lines%3F%7Crun)%5B%5E_%5D&start=50&sa=N
#> > 
#> > As you can probably can see immediately, thingatpt only colorizes (and
#> > uses) the string up to `..._layout_', stopping at the opening
#> > parenthesis.
#> > 
#> > Is this intentional or is this a bug?
#> 
#> It is intentional, as parentheses are explicitly excluded from URLs by
#> thing-at-point-url-path-regexp.  It could be a bug, as parentheses are
#> defined as reserved characters in URIs, which are only sometimes percent-
#> encoded, depending on the context; but I think they are allowed within
#> both the path and query components of generic URIs (without being
#> percent-encoded).
#> 
#> So just as the slashes in the URI above should not need to be %-encoded
#> (since they follow the ?, they are clearly within the query component),
#> neither should the parentheses need to be %-encoded -- but perhaps they
#> ought to be.

FWIW, I have found this behaviour to be pretty annoying: URLs like this
one are becoming rather common nowadays (at least in my experience) and
the fact that find-file-at-point does not handle them feels like a bug.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

All I want is a warm bed, and a kind word, and unlimited power.

(no subject)

[Richard Stallman]

In-reply-to: <2cd46e7f0609010846o7b393dd5xef60a645125d08@mail.gmail.com>
	(ken.manheimer@gmail.com)
Subject: Re: cursor doesn't show through transparent images in emacs 22, unlike emacs 21
bcc: rms-outgoing@gnu.org
Reply-to: rms@gnu.org
References: <2cd46e7f0608181622w23c7d2b0h9b963deeadfd1c06@mail.gmail.com>
	 <E1GHpIm-00027E-7t@fencepost.gnu.org> <87wt8sbhux.fsf@jurta.org>
	 <m3zmdoa2h7.fsf@kfs-l.imdomain.dk>
	 <2cd46e7f0608291431k1d26dac9l1f41c271da28495e@mail.gmail.com>
	 <85y7t7mdha.fsf@lola.goethe.zz>
	 <2cd46e7f0608291512ne9a865av7fb7bb537658887a@mail.gmail.com>
	 <E1GIUKm-0000Gd-Tx@fencepost.gnu.org>
	 <2cd46e7f0608301120q190d710bya04f85359e79e29@mail.gmail.com>
	 <E1GIr5F-0000KL-6z@fencepost.gnu.org> <2cd46e7f0609010846o7b393dd5xef60a645125d08@mail.gmail.com>
--text follows this line--
    > What happens when you do not specify any :mask attribute?
    > Is that the case where the cursor fails to show?

    yes.

    > If I understand right, then this is a bug, as I previously said.

    i think i agree.  the only question i have concerns the resonsibility
    and disrcetion of the application developer.

I think we have a responsibility to make sure that the default way of
displaying an image does work properly with the cursor.  To have some
peculiar option which means the cursor does not display properly might
be excusable, but it's not excusable for the default to display wrong.

I suggested:

    That would be bad,  since it would change the geometry.
    What I think he proposed is to show the cursor over the outer parts
    of the image.  That seems good for this case.

Is anyone working on this?

(no subject)

[amcorreia]

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

Date: Tue, 25 Jul 2006 14:33:29 -0300
From: Alessandro Madruga Correia <amcorreia@viaconnect.com.br>
To: ML Emacs Devel <emacs-devel@gnu.org>
Subject: Possible bug in C-mode
Message-ID: <20060725173328.GA23717@viaconnect.com.br>
Mail-Followup-To: Alessandro Madruga Correia <amcorreia@viaconnect.com.br>,
	ML Emacs Devel <emacs-devel@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Operating-System: Linux 2.6.15-1-686 (i686)
Organization: Viaconnect
X-URL: http://www.viaconnect.com.br
Mail-Followup-To: Alessandro Madruga Correia <amcorreia@viaconnect.com.br>
X-Uptime: 14:28:39 up 15 days, 17:56, 61 users,  load average: 0.28, 0.65, 0.82
User-Agent: Mutt/1.5.11

Hi folks.

amcorreia@fileserver:~$  emacs -Q

I'm using:

M-x version
GNU Emacs 22.0.50.4 (i686-pc-linux-gnu, X toolkit) of 2006-05-09 on fileserver

with
M-x c-version
Using CC Mode version 5.31.3

in X.
if I have a comment wich this.

/* 
 * comment
 */

fontify correct.

/**
 * comment
 */

don't fontify correct

and
/***
 * comment
 */
 
correct again.

maybe a trouble with regexp?


-- 
 ,= ,-_-. =.  [<o>] Alessandro Madruga Correia
((_/)o o(\_)) [http://counter.li.org]              Slack User# 342751
 `-'(. .)`-'  ln -s /dev/brain /dev/null
     \_/      "Mostre-me teu bookmark e te direi quem es"

14:28:39 up 15 days, 17:56, 61 users,  load average: 0.28, 0.65, 0.82
Linux fileserver 2.6.15-1-686 #2 Mon Mar 6 15:27:08 UTC 2006 i686 GNU/Linux


[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[amcorreia]

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

Date: Mon, 26 Jun 2006 09:54:48 -0300
From: Alessandro Madruga Correia <amcorreia@viaconnect.com.br>
To: emacs-devel@gnu.org
Subject: Fontify comment problem?!
Message-ID: <20060626125448.GA8335@viaconnect.com.br>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Operating-System: Linux 2.6.15-1-686 (i686)
X-Uptime: 09:50:09 up  1:47, 54 users,  load average: 1.77, 2.04, 1.83
User-Agent: Mutt/1.5.11

Hi,

I'm using Emacs version.
GNU Emacs 22.0.50.1 (i686-pc-linux-gnu) of 2006-06-26 on fw1b

my Emacs don't fontify correct the comment in buffer (in any mode).
this in text mode, in graphic mode this fontify correct.

i.e
if i have:

"/* this is a comment */
int x;"

fontify just "/*" and "*/".

this is a bug?

-- 
 ,= ,-_-. =.  [<o>] Alessandro Madruga Correia
((_/)o o(\_)) [http://counter.li.org]              Slack User# 342751
 `-'(. .)`-'  ln -s /dev/brain /dev/null
     \_/      "Mostre-me teu bookmark e te direi quem es"

 ..... __@ ...... __@
 ...._ \ >_ .... _ \ >_
 ...(_)/ (_) ...(_)/ (_) 
Linux fileserver 2.6.15-1-686 #2 Mon Mar 6 15:27:08 UTC 2006 i686 GNU/Linux
09:50:09 up  1:47, 54 users,  load average: 1.77, 2.04, 1.83


[-- 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: (no subject)

[Richard Stallman]

This is not a bug, it is the intended function on a tty.  You can
customize it by changing the definition of the face used for comments.

(no subject)

[Richard Stallman]

Subject: [mjreed@essex.ac.uk: regexp problem in ldap.el?]
bcc: rms-outgoing@gnu.org
Reply-to: rms@gnu.org
--text follows this line--
Would someone please DTRT here, and ack?

------- Start of forwarded message -------
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 1 Jun 2006 17:37:38 +0100
From: Martin J. Reed <mjreed@essex.ac.uk>
To: bug-gnu-emacs@gnu.org
Subject: regexp problem in ldap.el?
X-Spam-Status: No, score=0.6 required=5.0 tests=HOT_NASTY autolearn=no 
	version=3.0.4

Hi,

I have had problems with ldap.el. It seems that the version shipped
(and latest CVS) matches erroneous lines in the grabbed output from
ldapsearch when SASL authentication is used. The problem may also
occur in other situations (I think it is a genuine bug). I have had to
apply the following diff (to ldap-1.11.2.10.el grabbed from CVS):

- --------------------------->8-------------------------------------
diff -u ldap-1.11.2.10.el ldap-1.11.2.10-reed.el 
- --- ldap-1.11.2.10.el   2006-06-01 17:05:40.000000000 +0100
+++ ldap-1.11.2.10-reed.el      2006-06-01 17:04:41.000000000 +0100
@@ -154,7 +154,7 @@
   :type '(string :tag "`ldapsearch' Program")
   :group 'ldap)
 
- -(defcustom ldap-ldapsearch-args '("-LL" "-tt" "-x")
+(defcustom ldap-ldapsearch-args '("-LL" "-tt")
   "*A list of additional arguments to pass to `ldapsearch'."
   :type '(repeat :tag "`ldapsearch' Arguments"
                 (string :tag "Argument"))
@@ -555,7 +555,7 @@
          (setq arglist (nconc arglist (list (format "-z%s" sizelimit)))))
       (eval `(call-process ldap-ldapsearch-prog
                           nil
- -                          `(,buf nil)
+                          buf
                           nil
                           ,@arglist
                           ,@ldap-ldapsearch-args
@@ -580,7 +580,7 @@
                                               (end-of-line)
                                               (point))))
          (forward-line 1)
- -         (while (looking-at "^\\(\\w*\\)\\(;\\w*\\)?[=:\t ]+\\(<[\t ]*file://\\)?\\(.*\\)$")
+         (while (looking-at "^\\(\\w*\\)\\(;\\w*\\)?[=:\t ]+\\(<[\t ]*file://\\)\\(.*\\)$")
            (setq name (match-string 1)
                  value (match-string 4))
             ;; Need to handle file:///D:/... as generated by OpenLDAP
- --------------------------->8-------------------------------------
The main problem I have is the last change in the diff. The "?" is
removed as with it there is a match on "one or none" instances of the
"file://". This seems to mean that it grabs any available line not
just those with a "file://" in it. Then the defun tries to load files
that match the erroneous lines (and fails).

The change of ldap-ldapsearch-args is probably not important (although
do we want users to use the insecure unencrypted form by default?),
also I do not understand why the change from `(,buf nil) to buf is
required (probably my elisp ignorance).

Example output of ldapsearch that causes a problem (OpenLdap 2.2.28)
with cleaned content. The error occurs on the second line where the
(looking-at regexp...) matches true and the defun tries to load a file
"/home/myhome/username: myusername". 
- -------------------------->8----------------------------------------
SASL/DIGEST-MD5 authentication started
SASL username: myusername
SASL SSF: 128
SASL installing layers
version: 1

dn: CN=xxxx,OU=xxxxxx,DC=xxxxx,DC=xx,DC=xx
objectClass:< file:///tmp/ldapsearch-objectClass-8bcsA7
objectClass:< file:///tmp/ldapsearch-objectClass-wlxT99
objectClass:< file:///tmp/ldapsearch-objectClass-GPNlJc
objectClass:< file:///tmp/ldapsearch-objectClass-G4DOif
cn:< file:///tmp/ldapsearch-cn-u79hSh
sn:< file:///tmp/ldapsearch-sn-YjeMrk
title:< file:///tmp/ldapsearch-title-qHNg1m
givenName:< file:///tmp/ldapsearch-givenName-8ATLAp
initials:< file:///tmp/ldapsearch-initials-83xhas
distinguishedName:< file:///tmp/ldapsearch-distinguishedName-uiXNJu
- -------------------------->8---------------------------------------

Also there is a problem with ldapsearch from latest OpenLDAP in that
it can wrap long lines. Not sure if there is a possible fix in emacs
but maybe a warning could be added (I use a wrapper script to get rid
of the "bad line wraps").

Otherwise thanks for the updates it works much better than ldap.el
shipped with 21.4.

Regards,
 
Martin
- --
Dr. M.J. Reed                               Room:          1NW.5.3G
Dept. Electronic Systems Engineering         Tel:+44 (0)1206 872479
University of Essex, Colchester CO4 3SQ, UK  FAX:+44 (0)1206 872900
Email mjreed (non Essex users should add @essex.ac.uk)
Web: http://esewww.essex.ac.uk/~mjreed


_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

Re: (no subject)

[Chong Yidong]

> I have had problems with ldap.el. It seems that the version shipped
> (and latest CVS) matches erroneous lines in the grabbed output from
> ldapsearch when SASL authentication is used. The problem may also
> occur in other situations (I think it is a genuine bug). I have had to
> apply the following diff (to ldap-1.11.2.10.el grabbed from CVS):

Your patch looks OK, so I've installed it.

> - --------------------------->8-------------------------------------
> diff -u ldap-1.11.2.10.el ldap-1.11.2.10-reed.el 
> - --- ldap-1.11.2.10.el   2006-06-01 17:05:40.000000000 +0100
> +++ ldap-1.11.2.10-reed.el      2006-06-01 17:04:41.000000000 +0100
> @@ -154,7 +154,7 @@
>    :type '(string :tag "`ldapsearch' Program")
>    :group 'ldap)
>  
> - -(defcustom ldap-ldapsearch-args '("-LL" "-tt" "-x")
> +(defcustom ldap-ldapsearch-args '("-LL" "-tt")
>    "*A list of additional arguments to pass to `ldapsearch'."
>    :type '(repeat :tag "`ldapsearch' Arguments"
>                  (string :tag "Argument"))
> @@ -555,7 +555,7 @@
>           (setq arglist (nconc arglist (list (format "-z%s" sizelimit)))))
>        (eval `(call-process ldap-ldapsearch-prog
>                            nil
> - -                          `(,buf nil)
> +                          buf
>                            nil
>                            ,@arglist
>                            ,@ldap-ldapsearch-args
> @@ -580,7 +580,7 @@
>                                                (end-of-line)
>                                                (point))))
>           (forward-line 1)
> - -         (while (looking-at "^\\(\\w*\\)\\(;\\w*\\)?[=:\t ]+\\(<[\t ]*file://\\)?\\(.*\\)$")
> +         (while (looking-at "^\\(\\w*\\)\\(;\\w*\\)?[=:\t ]+\\(<[\t ]*file://\\)\\(.*\\)$")
>             (setq name (match-string 1)
>                   value (match-string 4))
>              ;; Need to handle file:///D:/... as generated by OpenLDAP
> - --------------------------->8-------------------------------------
> The main problem I have is the last change in the diff. The "?" is
> removed as with it there is a match on "one or none" instances of the
> "file://". This seems to mean that it grabs any available line not
> just those with a "file://" in it. Then the defun tries to load files
> that match the erroneous lines (and fails).
>
> The change of ldap-ldapsearch-args is probably not important (although
> do we want users to use the insecure unencrypted form by default?),
> also I do not understand why the change from `(,buf nil) to buf is
> required (probably my elisp ignorance).
>
> Example output of ldapsearch that causes a problem (OpenLdap 2.2.28)
> with cleaned content. The error occurs on the second line where the
> (looking-at regexp...) matches true and the defun tries to load a file
> "/home/myhome/username: myusername". 
> - -------------------------->8----------------------------------------
> SASL/DIGEST-MD5 authentication started
> SASL username: myusername
> SASL SSF: 128
> SASL installing layers
> version: 1
>
> dn: CN=xxxx,OU=xxxxxx,DC=xxxxx,DC=xx,DC=xx
> objectClass:< file:///tmp/ldapsearch-objectClass-8bcsA7
> objectClass:< file:///tmp/ldapsearch-objectClass-wlxT99
> objectClass:< file:///tmp/ldapsearch-objectClass-GPNlJc
> objectClass:< file:///tmp/ldapsearch-objectClass-G4DOif
> cn:< file:///tmp/ldapsearch-cn-u79hSh
> sn:< file:///tmp/ldapsearch-sn-YjeMrk
> title:< file:///tmp/ldapsearch-title-qHNg1m
> givenName:< file:///tmp/ldapsearch-givenName-8ATLAp
> initials:< file:///tmp/ldapsearch-initials-83xhas
> distinguishedName:< file:///tmp/ldapsearch-distinguishedName-uiXNJu
> - -------------------------->8---------------------------------------
>
> Also there is a problem with ldapsearch from latest OpenLDAP in that
> it can wrap long lines. Not sure if there is a possible fix in emacs
> but maybe a warning could be added (I use a wrapper script to get rid
> of the "bad line wraps").
>
> Otherwise thanks for the updates it works much better than ldap.el
> shipped with 21.4.
>
> Regards,
>  
> Martin
> - --
> Dr. M.J. Reed                               Room:          1NW.5.3G
> Dept. Electronic Systems Engineering         Tel:+44 (0)1206 872479
> University of Essex, Colchester CO4 3SQ, UK  FAX:+44 (0)1206 872900
> Email mjreed (non Essex users should add @essex.ac.uk)
> Web: http://esewww.essex.ac.uk/~mjreed
>
>
> _______________________________________________
> bug-gnu-emacs mailing list
> bug-gnu-emacs@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
> ----------
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Amir Bukhari]

we in LG3D (Project Looking glass 3D) trying to build a 3d Desktop by using 
Composite Extension. we want to resolve all problem we encoured when using 
emacs with Lg3D.
I will describe the issue like following:
when opening emacs and click with mouse on a menu (For example File Menu), a
popup menu appear under File Menu. now 
we move the mouse pointer to other menu (in menubar) when mouse over one of 
them, a popup window appear but on the old possition (under File Menu also)
of the first opened 
menu.
it is not an issue in emacs, but rather in LG3D, because emacs works fine in

other window manager or without WM.
to fix this issue I need to know how emacs create menu, does it grab 
(pointer) during a popup menu is opened!
any help will be apreciated!

looking to the code of emacs will not help because I don't know how it is 
organized. 

-Amir

(no subject)

[Ahmadshah]

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

(no subject)

[SHestbrooke]

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

(no subject)

[Afrael]

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

(no subject)

[Kajane]

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

(no subject)

[Taneev]

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

(no subject)

[Baron]

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

(no subject)

[Stalina]

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

(no subject)

[Alafir]

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

(no subject)

[Alimgereiy]

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

(no subject)

[David PONCE]

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

Lennart Borgman wrote:
> I have added them to the web page now. Personally I am still in favour 
> of you first suggestion and my suggestion with M-x and the gnu head. One 
> of the reasons is that the screen normally contains so much horizontal 
> and vertical elements. Your second suggestion with the parenthesis 
> breaks this too and I like that one also.

Hi,

Attached you will find a new icon idea. I must confess that it is my
favorite icon for now ;-) It looks quite good scaled to 16x16.

Sincerely,
David

[-- Attachment #2: /home/ponce/.icons/hicolor/48x48/apps/emacs-logo-48x48.png --]
[-- Type: image/png, Size: 5653 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[r.reichlin]

URGENT!	 Winning Notification
Mime-Version: 1.0
Content-Type: text/plain;charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

PRIME GOLDEN LOTTO INC.,
Stadhouderskade 402
1071 ZD Amsterdam
The Netherlands
TEL: +31 64 597 6717
FAX: +31 84 751 9538

FROM: LOTTERY COORDINATIOR,
INTERNATIONAL PROMOTIONS/
PRIZE AWARD DEPARTMENT.
REF: IPAH/900111/2004.
BATCH: 08/11810/IPH.

Dear Beneficiary,

RE: AWARD NOTIFICATION; FINAL NOTICE

With all due respect to your right to granting a verifiable deliberate, exp=
licit=20
and revocable permission for this message being sent you, we are pleased=20
to inform you of the result of The Online Lottery  program Draw Number 926.=
01=20
held on the 6th November, 2004 in which your email address emerged the jack=
pot=20
winner. Ticket number 370982217413-7240 with serial number 4708-325, which=
=20
was attached to your email address in the lottery program, drew lucky numbe=
rs=20
5-17-23-26-42-48 consequently winning the sum of GB=C2=A31,666,667.00. You =
have=20
therefore been approved for the winning prize lump sum pay of One Million,=
=20
Six Hundred and Sixty Six Thousand, Six Hundred and Sixty Seven British=20
Pounds (GB=C2=A31,666,667.00) exchanging to Three Million, Two Hundred and =
Three=20
Thousand, Seven Hundred and Fifteen United States Dollars, Sixty Cents (US$=
=20
3,203,715.60) - Live mid-market rates as of 2005.03.08 11:41:15 UTC.=20

CONGRATULATIONS!!!

In accordance with our Terms of Service in line with privacy and confidenti=
al concerns,=20
we ask that you keep your winning information confidential until your claim=
=20
has been processed and your money remitted to you. This is part of our secu=
rity=20
protocol to avoid double claiming and unwarranted abuse of this program=20
by some participants. All participants were selected through a computer=20
ballot system drawn from over 20,000 companies and 30,000,000 individual=20
email addresses and names from all over the world. This promotional program=
=20
takes place every year, and is promoted and sponsored by eminent personalit=
ies=20
like the Sultan of Brunei, Bill Gates of Microsoft Inc and other corporate=
=20
organizations in encouraging the use of the computers worldwide with emphas=
is=20
in bolstering confidence in internet commerce and online business/economic/=
financial=20
transactions; we hope with part of your winning you will take part in our=
=20
next jackpot's USD50 million international lottery.

You are hereby advised to contact our financial agent and your assigned Cla=
ims=20
Clearance Officer MRS.PAMELA COCKER by fax on +31 84 751 9538 and/or email:=
=20
pam4pgl7@eresmas.com to assist you with the processing of your winnings=20
and subsequent payments.  All winnings must be claimed not later than one=
=20
month from the date of this notice.  After this date the affected winnings=
=20
shall become null and void causing the unclaimed fund to be included in=20
the next stake.  Please note, in order to avoid unnecessary delays and comp=
lications,=20
always quote your reference number and batch numbers in all correspondence.=
 =20
Furthermore, should there be any change of address do inform our agent as=
=20
soon as possible.

Congratulations once more and thank you for being part of our promotional p=
rogram.

Sincerely yours,

ROBERT REICHLIN,
Coordinator.

=20

(no subject)

[Luc Teirlinck]

Is there a reason why this-original-command, unlike this-command,
returns a non-nil value when no command is running?  The reason why
this originally annoyed me is no longer valid, so I do not need this
to be "fixed", but I thought that maybe it might just be due to an
oversight.  What about the patch below?  Grepping shows that
this-original-command, is only used in ido and cua.  Basically, I
believe that only Kim has ever used it.  What about the mini-patch
below?  I can install if desired.

===File ~/keyboard.c-diff===================================
*** keyboard.c	26 May 2005 10:40:35 -0500	1.826
--- keyboard.c	30 May 2005 17:14:15 -0500	
***************
*** 1522,1527 ****
--- 1522,1528 ----
  
        Vthis_command = Qnil;
        real_this_command = Qnil;
+       Vthis_original_command=Qnil;
  
        /* Read next key sequence; i gets its length.  */
        i = read_key_sequence (keybuf, sizeof keybuf / sizeof keybuf[0],
============================================================

(no subject)

[uiuew_qqy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;charset="EUC", Size: 132 bytes --]


@@¡o‰ï‚¢Œn‚È‚ñ‚āc‚Æ’ú‚ß‚Ä‚¢‚Ü‚¹‚ñ‚©H
@@@http://love-game-dream.com/kowaza



ƒ[ƒ‹‹‘”Û‚Í‚±‚¿‚ç‚܂ŁB
paulresis@yahoo.com

(no subject)

[Charity Donahue]

[-- Attachment #1: Type: text/html, Size: 363 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

(no subject)

[loot]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;charset="EUC", Size: 49 bytes --]

‚±‚êâ‘΃IƒXƒXƒB

http://www.deaino1.net/


‹­

(no subject)

[John Knottenbelt]

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

Here is a patch to get Emacs to compiler under Mac OS X 10.4:

[-- Attachment #2: tiger.patch --]
[-- Type: application/octet-stream, Size: 578 bytes --]

Index: src/image.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/image.c,v
retrieving revision 1.22
diff -u -4 -r1.22 image.c
--- src/image.c	16 Apr 2005 03:07:05 -0000	1.22
+++ src/image.c	3 May 2005 08:15:40 -0000
@@ -90,8 +90,10 @@
 #endif
 #if TARGET_API_MAC_CARBON
 #ifdef MAC_OSX
 #include <QuickTime/QuickTime.h>
+#include <QuickTime/ImageCompression.h>
+#include <QuickTime/QuickTimeComponents.h>
 #else  /* not MAC_OSX */
 #include <QuickTime.h>
 #endif	/* not MAC_OSX */
 #else  /* not TARGET_API_MAC_CARBON */

[-- Attachment #3: Type: text/plain, Size: 12 bytes --]

Cheers

John

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Richard Stallman]

    Richard, you never responded to my questions, nor made any changes in
    the related files.

You sent me that message three days ago, so I read it two days ago.
It is ridiculous to tell someone "you never responded" after just two
days.  Please give me some slack!

I think you will have to wait a few more days.  I have got 450
messages since yesterday evening, and I am behind 30 messages just
from today.

With luck I will have time to catch up this weekend.
I cannot promise it.

(no subject)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 28 Apr 2005 07:00:48 -0400
> 
>     Richard, you never responded to my questions, nor made any changes in
>     the related files.
> 
> You sent me that message three days ago, so I read it two days ago.
> It is ridiculous to tell someone "you never responded" after just two
> days.  Please give me some slack!

I did.  I waited until I saw your responses to other messages which
were posted after the one I referred to.  After I saw those responses,
I naturally assumed that you somehow missed mine.

(no subject)

[Richard Stallman]

    I did.  I waited until I saw your responses to other messages which
    were posted after the one I referred to.  After I saw those responses,
    I naturally assumed that you somehow missed mine.

You mustn't assume such things--it is a mistake.  I always deal with
the easier issues immediately and postpone harder ones.

This one is going to require thought.  I wrote the changes in files.el
weeks ago, and I must have misremembered what they were supposed to do
when I wrote the changes in copy-file.  I'm going to have to figure
out what's really going on here.  I can't do that at any moment.

(no subject)

[Felix Cohen]

Hey,
	My name is Felix Cohen, and I am a researcher at Bath University, 
England. I am currently undertaking research to investigate the 
relationships between motivation and other factors on F/OSS developers 
and users.
	To this end, we have put a questionnaire online for developers to fill 
in. It shouldn't take more than bout 10 minutes, and is easy to 
complete. It is at

http://www.bath.ac.uk/~ps2fac/Research/questionnaire.html

	Please complete the form honestly. All results will be anonymised, and 
the final research will be published on the website.
	
Thanks,

Felix

(no subject)

[jhigr]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;charset="EUC", Size: 118 bytes --]

‚ ‚肪‚Ɓ[‚ł„DM)¥ß¥¡¥ßߥ*:.?.?:*¥ß c
ƒAƒLŒN‚Ì‚¨‚©‚°‚Åhappy‚¾‚æB

‚¾[‚è‚ñ’T‚µƒuƒƒO
http://www.freegal.net/

g.

(no subject)

[weather]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain;charset="EUC", Size: 911 bytes --]

„«Š®„«‘S„«–³„«—¿„«š„«Š„„«Ø„«‚è„«ƒl„«ƒb„«ƒg
„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª
@@@@„«‚g„«‚È„«o„«‰ï„«‚¢„«‚ð„«ƒA„«ƒi„«ƒ^„«‚¾„«‚¯„«‚É„«š
@@@@„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª„¯„ª

¦ƒc[ƒNƒŠƒbƒN¼‹\ƒTƒCƒg‚â•s³“‘£‚͈êØ‚ ‚è‚Ü‚¹‚ñB
@¼‹\¿‹–o–ňψõ‰ïNo.000113
@http://www.yahyahyah.info/

¦¡”N“xÅ‚‚̏o‰ï‚¢‚ð‰‰o‚µ‚Ü‚·B
@’j—‚Æ‚à‚ɃI[ƒ‹ƒT[ƒrƒX–³—¿B
@http://www.yahyahyah.info/


@„¬„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª™œc
„¡š@‹Â“VÌ‹ÆŠENEWSFÅV‹LŽ–ƒsƒbƒNƒAƒbƒv
„¹„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª

 „­@yahooƒtƒŠ[ƒ[ƒ‹‘Ήž‚Á‚ă}ƒWH
„¯„®„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
‘±‚«Fhttp://www.yahyahyah.info/

„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª„ª
@¡@–³—¿o‰ï‚¢“¹•W@¡
cccccccccccccccccccccccccccccc
http://www.yahyahyah.info/
•‰ÓlF—›g

(no subject)

[Chong Yidong]

Could this patch be checked in? When require-final-newlines is t, the
newline is inserted by (insert "\n"), which does not take
use-hard-newlines into account, so the newline is not marked as 'hard.


*** emacs/lisp/files.el~	Tue Mar  1 22:13:16 2005
--- emacs/lisp/files.el	Wed Mar  2 10:16:52 2005
***************
*** 1661,1667 ****
  		   (= (char-after (1- (point-max))) ?\r)))
  	 (save-excursion
  	   (goto-char (point-max))
! 	   (insert "\n")))
      (when (and buffer-read-only
  	       view-read-only
  	       (not (eq (get major-mode 'mode-class) 'special)))
--- 1661,1667 ----
  		   (= (char-after (1- (point-max))) ?\r)))
  	 (save-excursion
  	   (goto-char (point-max))
! 	   (newline)))
      (when (and buffer-read-only
  	       view-read-only
  	       (not (eq (get major-mode 'mode-class) 'special)))
***************
*** 3244,3250 ****
  				     (buffer-name)))))
  		   (save-excursion
  		     (goto-char (point-max))
! 		     (insert ?\n))))
  	    ;; Support VC version backups.
  	    (vc-before-save)
  	    (run-hooks 'before-save-hook)
--- 3244,3250 ----
  				     (buffer-name)))))
  		   (save-excursion
  		     (goto-char (point-max))
! 		     (newline))))
  	    ;; Support VC version backups.
  	    (vc-before-save)
  	    (run-hooks 'before-save-hook)

Re: (no subject)

[Luc Teirlinck]

Chong Yidong wrote:

   Could this patch be checked in? When require-final-newlines is t, the
   newline is inserted by (insert "\n"), which does not take
   use-hard-newlines into account, so the newline is not marked as 'hard.

Are you really _sure_ that a newline inserted by saving a buffer
should be hard if use-hard-newlines is enabled?  I would guess that
people might occasionally save their work to file while in the middle
of a long paragraph, in which case the inserted newline should be
soft.  I guess that if people want to mark the end of a paragraph
before saving, they would explicitly type RET.

What situation are you thinking of that would motivate making C-x C-s
insert a hard newline?

Sincerely,

Luc.

(no subject)

[Georgia Jaramillo]

[-- Attachment #1.1.1: Type: text/plain, Size: 29 bytes --]

Get a capable html e-mailer


[-- Attachment #1.1.2: Type: text/html, Size: 2017 bytes --]

[-- Attachment #1.2: xxpne.gif --]
[-- Type: image/gif, Size: 6736 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

(no subject)

[vr]

From: Vijay Rahvy.
Return email:vijayrahvy@netscape.net

As you read this, I don't want you to feel sorry for me, because, I believe everyone will die someday. 

My name is Vijay Rahvy, a merchant in Dubai, in the U.A.E. I have been diagnosed with prostate and esophageal Cancer that was discovered very late due to my laxity in caring for my health. It has defiled all form of medicine and right now, I have only about a few months to live according to medical experts. 

I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. Now that I know my time is near, I have willed and given most of my properties and assets to my immediate and extended family members and as well as a few close friends and Schools in the UAE. I have decided to give alms to charity organizations, as I want this to be one of the last good deeds I do on earth. So far, I have distributed money to some charity organizations Now that my health has deteriorated so badly, I cannot do this my self any more.

I once asked members of my family to close one of my accounts and donate the money, which I have there to charity rganization in Bulgaria, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them. The last of my money which is the huge cash deposit that I have with Financial Firm Abroad .

I will want you to help me collect this deposit and dispatched it to charity organizations and let them know that it is I Vijay Rahvy that is making this generous donation. 

I am writing this from my laptop computer in my hospital bed where I wait for my time to come. I pray that God uses you to support and assist me with good heart God be with you. 

Mr Vijay Rahvy




___________________________________________________________________________
Mail sent from WebMail service at PHP-Nuke Powered Site
- http://yoursite.com

(no subject)

[tvpeq]

 0v[3

(no subject)

[Hazel Whitaker]

[-- Attachment #1.1.1: Type: text/plain, Size: 29 bytes --]

Get a capable html e-mailer


[-- Attachment #1.1.2: Type: text/html, Size: 2004 bytes --]

[-- Attachment #1.2: gnyjto.gif --]
[-- Type: image/gif, Size: 6736 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

(no subject)

[Anna Nguyen]

[-- Attachment #1.1.1: Type: text/plain, Size: 29 bytes --]

Get a capable html e-mailer


[-- Attachment #1.1.2: Type: text/html, Size: 2022 bytes --]

[-- Attachment #1.2: ixor.gif --]
[-- Type: image/gif, Size: 6736 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

(no subject)

[Han Boetes]

It would be nice if the undo history would recognize that:

  "any char" 
    followed by 
  m-x delete-backward-char

Is functionally the same as.

  "any char"
    followed by
  m-x undo

I admit it's easier said than done.



# Han

Re: (no subject)

[Stefan Monnier]

> It would be nice if the undo history would recognize that:
>   "any char" 
>     followed by 
>   m-x delete-backward-char

> Is functionally the same as.

>   "any char"
>     followed by
>   m-x undo

> I admit it's easier said than done.

What would be the benefit?
I.e. in which cases would it make a diference?


        Stefan

Re: (no subject)

[Han Boetes]

Stefan Monnier wrote:
> Han wrote:
> > It would be nice if the undo history would recognize that:
> >   "any char" 
> >     followed by 
> >   m-x delete-backward-char
>
> > Is functionally the same as.
>
> >   "any char"
> >     followed by
> >   m-x undo
>
> > I admit it's easier said than done.
>
> What would be the benefit?
> I.e. in which cases would it make a diference?

Alright, good question. I have no answer except that it was a
silly idea. :-)



# Han

(no subject)

[Frank J. Hall]

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



[-- Attachment #1.1.2: Type: text/html, Size: 366 bytes --]

[-- Attachment #1.2: cvhxqyso.gif --]
[-- Type: image/gif, Size: 9636 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

(no subject)

[perfect butts]

[-- Attachment #1.1: Type: text/html, Size: 358 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

(no subject)

[Luc Teirlinck]

I took a look at all calls to `interactive-p' in the Emacs Elisp code.
For many (actually most) it is impossible to check whether the call is
"correct" without studying tons of code, which I did not do and am not
going to do.  For most others, the current behavior prevents nuisance
messaging, as intended.

_Maybe_ the following are exceptions to that (they should be checked
further).  Most of these seem to abuse `interactive-p' to read their
arguments outside the interactive declaration.  (Something that should
be avoided anyway, regardless of the negative effect on keyboard macros.)

1. Info-goto-emacs-key-command-node

I can not check this one right now, because
`Info-goto-emacs-command-node' seems broken.  I do not even know
whether this is worth worrying about.  It would seem to make no sense
to define a macro that always checks the documentation for the _same_
command.  Better use bookmarks in that case.

2.  Three functions in `indent.el'.  I could check these out further.
    If they give any problems, they are trivial to fix.

Apart from that, two files _seem_ to have problems: ibuf-ext.el, in
particular the function `ibuffer-jump-to-buffer' and allout.el, in
particular `allout-init', `allout-backward-current-level' and maybe
others.  I CC the maintainers of those files.  They can better
determine than I do whether the calls to interactive-p in those files
are appropriate and in particular, appropriate for keyboard macros.

Like I said I do not know whether the above list of (potential)
problems is exhaustive.  It probably is not.  Checking every single
call to `interactive-p' in detail is hopeless.  But what we know is
that the current behavior of `interactive-p', which has been in place
for a long time, has not exactly led to a flood of complaints from
keyboard macro users.  Keyboard macro users appear to be happy with
the current situation. What we do not know is whether changing the
behavior will lead to a flood a bug reports and complaints about macro
execution speed getting ruined.

Sincerely,

Luc.

(no subject)

[Guerra]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-4397-0", Size: 380 bytes --]

Hi again,

Here is  Guerra. I write to you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $252.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:


http://.quotestore.net/j8/jwex.php?cyb=101>



Thank you.

Best Regards  Guerra
First Account Manager



[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Mcdermott]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-8694-0", Size: 361 bytes --]

Hi again,

Here is  Mcdermott. I write to you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $252.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:


http://-.on-cash.com


Thank you.

Best Regards  Mcdermott
First Account Manager



[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Isaiah Ham]

Hello ,

Ready to boost your sex life? Positive?
Time to do it right now Order Cialis at incredibly low prices
$2.75 per dose. Unbelivable

http://lew.dbjflkea.info/?dtfLLwdCzNk7_JJadhere

(no subject)

[Levi Miller]

Dear sir/ madame 

CONGRATULATIONS!

Our records show from preliminary tests that 
you have been approved and are eligible for a loan of 
up to 400,000 USD. All you have to do is click on this 
link below and fill in the form which takes less than two minutes and we 
will contact you within 24 hours with a final decision. 
We accept allsorts of applications even if you do 
not have a 100% good credit record and pay the money 
into your account in some cases on the very same day. 

http://bind.bbgejfck.info/?fshyh3fSLQSc4Lfpater

Regards 
Levi Miller 
Senior lending specialist

(no subject)

[Lilly Pryor]

Hi again,

Here is Lilly Pryor. I write to you because we are accepting your mortgage=
 application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:

http://joel.mejcgall.info/?MtO3O4MnglTdBMgdental



Thank you.

Best Regards Lilly Pryor
First Account Manager

(no subject)

[Loretta Roe]

Hi again,

Here is Loretta Roe. I write to you because we are accepting your mortgage=
 application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:


http://cantilever-halo.debt-states.com

Thank you.

Best Regards Loretta Roe
First Account Manager





Remove Me Please

http://inexpiable.debt-states.com/r1/

(no subject)

[Eddy]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-8107-1", Size: 376 bytes --]

Hi again,

My name is  Eddy. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:


http://.financialfirms.net/p3/jwex.php?weo=101



Thank you.

Best Regards  Eddy
First Account Manager


[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Drew Adams]

Commands like `customize-group-other-window', and function
`custom-buffer-create-other-window' were apparently designed _not_ to select
the custom buffer after displaying it.

This can be inconvenient if you use separate frames, instead of windows
(pop-up-frames t).

For example, suppose I want to do something to or in the custom buffer after
it is displayed. To be more specific, suppose I want to resize (fit) the
frame to the buffer if the custom buffer is alone in its frame (which it
will be, because of pop-up-frames).

What are my options?

 1. Is there a hook that's run after display of the custom buffer? I don't
think so; I find only custom-mode-hook, which is run before the buffer is
displayed. Doing the frame fitting at that time is no good.

 2. How about using a defadvice-after? Well, that would be logical, except
that the custom buffer is not selected. I could select it in the defadvice,
but then I would need to copy & use the code that creates the buffer name.
Which more or less amounts to option #3.

 3. _Redefine_ the functions.

So, in order to avoid having people redefine such functions just to do
something simple after the buffer is displayed, how about making one of
these changes?

 - Select the custom buffer in the other window/frame. OK by me -- I don't
understand why this isn't done now; after all, the custom buffer is mainly
for editing. But, I can anticipate others groaning, and I'm sure there must
be good reasons (with pop-up-frames nil) for the current behavior. After
all, all of these functions go out of their way to unselect the custom
buffer.

 - Select the custom buffer, but only if pop-up-frames is t. OK by me, but
it seems like kind of a hack.

 - Provide an after-display hook for the customize functions; it would be
run with the custom buffer selected (before unselecting it as is currently
done).

Any reason we shouldn't implement one of these (or another)?

 - Drew

(no subject)

[Becky Sorensen]

Hi again,

Here is Becky Sorensen. I write to you because we are accepting your mortg=
age application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:


http://infarct-impart.refi-world.com


Thank you.

Best Regards Becky Sorensen
First Account Manager

(no subject)

[Carmen Hill]

Find the realtor that's right for you. Find your dream home. Find the mort=
gage you need.
Apply today and Get a free quote from competing lenders.
Find the right broker that will help you receive the lowest interst rate y=
ou need.
No obligations are neccesary! A broker will contact you within 24 hours.

http://cbyfdltazcwuoal.states-finance.com/?nlrhdhabiyo

You're on your way to getting the mortgage you deserve.


rem:
http://wkuiuawsevbq.loanz-states.com/r1/?ltrjj

(no subject)

[Dana Fisher]

Dear sir/ madame 

CONGRATULATIONS!

Our records show from preliminary tests that 
you have been approved and are eligible for a loan of 
up to 400,000 USD. All you have to do is click on this 
link below and fill in the form which takes less than two minutes and we 
will contact you within 24 hours with a final decision. 
We accept allsorts of applications even if you do 
not have a 100% good credit record and pay the money 
into your account in some cases on the very same day. 

http://tooth.mecbiink.info/?OvQBk6iVOnVL7Oitrouble

Regards 
Dana Fisher 
Senior lending specialist

(no subject)

[Tommie Bullock]

Hi again,

Here is Tommie Bullock. I write to you because we are accepting your mortg=
age application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:


http://adultery-purloin.refi-talk.com


Thank you.

Best Regards Tommie Bullock
First Account Manager

(no subject)

[Antoine Heard]

Hi again,

Here is Antoine Heard. I write to you because we are accepting your mortga=
ge application.
Our office confirms you can get a $220.000 lo=C0n for a $252.00 per month =
payment.
Approval process will take 1 minute, so please fill out the form on our we=
bsite:

http://muck.mcidmkdf.info/?QxSDm8QXQVrhFQkforfeit



Thank you.

Best Regards Antoine Heard
First Account Manager

(no subject)

[May Dixon]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-3273-1", Size: 385 bytes --]

Hi again,

Here is May Dixon. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:

http://queue.moneyintelligent.info/s6/jj.php?weo=101



Thank you.

Best Regards May Dixon
First Account Manager


[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Geoffrey Spears]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-5954-0", Size: 401 bytes --]

Hi again,

Here is Geoffrey Spears. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:

http://shortstop.moneyintelligent.info/s6/jj.php?weo=101



Thank you.

Best Regards Geoffrey Spears
First Account Manager


[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Rogelio Lott]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-4883-5", Size: 397 bytes --]

Hi again,

Here is Rogelio Lott. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:

http://emeritus.moneyintelligent.info/j8/o0o.php?jq1=101



Thank you.

Best Regards Rogelio Lott
First Account Manager



[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Duane Dahl]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.1: Type: text/plain; charset="iso-4230-8", Size: 396 bytes --]

Hi again,

Here is Duane Dahl. I wite you because we are accepting your mortgage application.
Our office confirms you can get a $220.000 loÀn for a $352.00 per month payment.
Approval process will take 1 minute, so please fill out the form on our website:

http://elephantine.moneyintelligent.info/j8/o0o.php?jq1=101



Thank you.

Best Regards Duane Dahl
First Account Manager



[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Luc Teirlinck]

`(emacs)Requesting Formatted Text' contains:

   You can add annotations for saving additional text properties,
   which Emacs normally does not save, by adding to
   `enriched-translations'.  Note that the text/enriched standard
   requires any non-standard annotations to have names starting with
   `x-', as in `x-read-only'.  This ensures that they will not
   conflict with standard annotations that may be added later.

   *Note Text Properties: (elisp)Text Properties, for more information
   about text properties.

But `enriched-translations' is defined in enriched.el with a
def_const_.  This suggest (maybe misleadingly) that the value should
not be messed with.  Also, if enriched.el gets (re-)loaded, any user
redefined value will be overridden again.  I believe that the defconst
should be changed to a defvar.  There seem to be unusually many
defconst's in enriched.el.  Do some other ones also need to be made
into defvar's?

There also is the problem that the text quoted above makes things look
much simpler than they are.  If one wants to successfully add
annotations for saving additional text properties, one will have to
(at least) read through three docstrings, two of which are rather long
and some parts of which assume at least some familiarity with Elisp
and with the text/enriched standard.  Depending on what one wants to
do, one might have to be able to write reasonably complex Lisp functions.
Remember that this is the Emacs (not Elisp) manual.

Do we want to keep the above paragraph in the Emacs manual?  It also
occurs in enriched.doc, where it more clearly seems aimed at a more
sophisticated audience:

    - You can add annotations for your own text properties by making
    additions to enriched-translations.  Note that the standard
    requires you to name your annotation starting "x-" (as in
    "x-read-only").  Please send me any such additions that you
    think might be of general interest so that I can include them
    in the distribution.

I personally believe that we should make `enriched-translations' into
a defvar, regardless of whether we keep the above text in the Emacs manual.

Sincerely,

Luc.

Re: (no subject)

[Richard Stallman]

    But `enriched-translations' is defined in enriched.el with a
    def_const_.  This suggest (maybe misleadingly) that the value should
    not be messed with.

Thanks for noticing that.  Please fix that.

    There also is the problem that the text quoted above makes things look
    much simpler than they are.  If one wants to successfully add
    annotations for saving additional text properties, one will have to
    (at least) read through three docstrings, two of which are rather long
    and some parts of which assume at least some familiarity with Elisp
    and with the text/enriched standard.

Could you add xrefs in the doc string for enriched-translations to
point to the other two symbols whose doc strings people need to read?

It might be better to mention this somewhere other than the Emacs Manual,
but there is no logical other place to do it.  I think it is right for the
text in the Emacs manual to be brief and refer people to other sources.

Re: (no subject)

[Luc Teirlinck]

Richard Stallman wrote:
       
       But `enriched-translations' is defined in enriched.el with a
       def_const_.  This suggest (maybe misleadingly) that the value should
       not be messed with.

   Thanks for noticing that.  Please fix that.

Done.

   Could you add xrefs in the doc string for enriched-translations to
   point to the other two symbols whose doc strings people need to read?

The docstring already contains those xrefs.

Sincerely,

Luc.

(no subject)

[Zane Cross]

[-- Attachment #1.1: schoolgirlish treadle psychic --]
[-- Type: text/html, Size: 743 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

(no subject)

[Stephan Stahl]

Hi.

Since i learned that M-n while doing completing-read and friends
brings up the default value and lets you edit it i used that feature
very often.

However it does not work in previous-matching-history-element (M-r
while the minibuffer is active). The following very simple patch
will do the trick.. Its much better that way.

Maybe someone wants to include that in emacs.

*** simple.el.1.644 Thu May 27 13:03:44 2004
--- simple.el.new Thu May 27 13:03:44 2004
***************
*** 933,939 ****
  					nil
  					minibuffer-local-map
  					nil
! 					'minibuffer-history-search-history)))
       ;; Use the last regexp specified, by default, if input is empty.
       (list (if (string= regexp "")
  	       (if minibuffer-history-search-history
--- 933,940 ----
  					nil
  					minibuffer-local-map
  					nil
! 					'minibuffer-history-search-history
! 					(car minibuffer-history-search-history))))
       ;; Use the last regexp specified, by default, if input is empty.
       (list (if (string= regexp "")
  	       (if minibuffer-history-search-history

-- 
Stephan Stahl

(no subject)

[Katrina Bliss]

[-- Attachment #1.1: Type: text/html, Size: 2322 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Dhruva Krishnamurthy]

Hello,
 "nmake info" (and gmake info) fails on GNU Emacs CVS HEAD using MSVC6
 (MinGW32).
The problem is in:
1. cd emacs/man
2. nmake info (gmake info)

The error is:
for the command "./../nt/multi-install-info.bat", "." which represents
the current direcotry is not interpreted as it should be and gives an
error. 

    '.' is not recognized as an internal or external command,
    operable program or batch file.

Changing the above command to : ".\..\nt\multi-install-info.bat" works
for both nmake and gmake!

Here is the diff of original versus modified (is this the standard?):
emacs/man/makefile.w32-in

*** \tmp\cvs\emacs\man\makefile.w32-in  Mon May  3 16:51:32 2004
--- ..\man\makefile.w32-in      Tue May  4 12:21:54 2004
*************** infodir = $(srcdir)/../info
*** 30,36 ****

  # The makeinfo program is part of the Texinfo distribution.
  MAKEINFO = makeinfo
! MULTI_INSTALL_INFO = $(srcdir)/../nt/multi-install-info.bat
  INFO_TARGETS = $(infodir)/emacs $(infodir)/ccmode \
                $(infodir)/cl $(infodir)/dired-x \
                $(infodir)/ediff $(infodir)/forms \
--- 30,36 ----

  # The makeinfo program is part of the Texinfo distribution.
  MAKEINFO = makeinfo
! MULTI_INSTALL_INFO = $(srcdir)\..\nt\multi-install-info.bat
  INFO_TARGETS = $(infodir)/emacs $(infodir)/ccmode \
                $(infodir)/cl $(infodir)/dired-x \
                $(infodir)/ediff $(infodir)/forms \
________________________________________
Dhruva Krishnamurthy
Proud FSF member: #1935
http://schemer.fateback.com/

(no subject)

[Nicole Delarosa]

[-- Attachment #1.1: proficient brunch amino --]
[-- Type: text/html, Size: 3126 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Delores Bacon]

[-- Attachment #1.1: scribble capstan acquiescent --]
[-- Type: text/html, Size: 2759 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Alyson]

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

saturable afflict brassy phrasemake imprimatur consecutive octane innards 
augean gusset corinth optoelectronic artifice bewilder mycology ibis pong integument 
stupid fenugreek pairwise diathermy claudio dichotomy melanin 

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

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[admail.direct]

  from mail.unsubscribenow.org with eGlobal Planet (MMS ver1.6)
Message-ID: <eGlobal Planet Shanghai TuXiang China>
From: "UnsubscribeNow.org" <admail.direct@unsubscribenow.org>
Reply-To: "UnsubscribeNow.org" <admail.direct@unsubscribenow.org>
To: emacs-devel@gnu.org
Subject: Fw: ADV: IMPORTANT: your email address is circulating...
Date: Tue, 03 Feb 2004 02:21:28 +0500
X-Mailer: eGlobal Planet (MMS ver1.6)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="--274836256165949156"
X-Priority: 1
X-MSMail-Priority: High

----274836256165949156
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1=
">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<CENTER>
<TABLE style=3D"WIDTH: 551px; HEIGHT: 179px" width=3D551 align=3Dcenter bo=
rder=3D0>
  <TBODY>
  <TR>
    <TD vAlign=3Dbottom colSpan=3D2 height=3D41>
      <DIV align=3Dcenter>&nbsp;</DIV>
      <DIV align=3Dleft><FONT face=3DArial size=3D2><FONT 
      face=3DTahoma color=3D#006699><STRONG>[UnsubscribeNow.org OLX Public=
 Service Announcement 
      ADV# 56T1002]</STRONG></FONT></FONT></DIV>
      <DIV align=3Dcenter><FONT face=3DArial color=3D#006699 size=3D2></FO=
NT>&nbsp;</DIV>
      <DIV align=3Dcenter>
      <HR style=3D"WIDTH: 300pt" align=3Dcenter width=3D400 SIZE=3D2>
      </DIV>
      <DIV align=3Dcenter><FONT face=3DTahoma size=3D2></FONT><FONT face=3D=
Tahoma 
      color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
      <DIV align=3Dleft><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#006699 
      size=3D2><STRONG>If you've received this message</STRONG> - then you=
r 
      email address has been screened</FONT></DIV>
      <DIV align=3Dleft><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#006699 
      size=3D2>circulating on pornography and spam related mailing lists. =

      <FONT face=3D"Arial, Helvetica, sans-serif" color=3D#006699 
      size=3D2>UnsubscribeNow.org</FONT></FONT></DIV>
      <DIV align=3Dleft><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#006699 
      size=3D2><FONT face=3D"Arial, Helvetica, sans-serif" color=3D#006699=
 
      size=3D2>screens junk-email circulating online and registers
      their 'remove-me'</FONT><FONT face=3DArial color=3D#006699 size=3D2>=
 links into 
      the</FONT></DIV><DIV align=3Dleft><FONT face=3DArial color=3D#006699=
 size=3D2>
      UnsubscribeNow.org 'remove-me' database.
      <DIV align=3Dleft><FONT face=3DArial color=3D#006699 size=3D2></FONT=
>&nbsp;</DIV>
      <DIV align=3Dleft><FONT face=3D"Arial, Helvetica, sans-serif" color=3D=
#006699 
      size=3D2>To learn how we help clear and 'Opt-out' your email address=
es online,
      </FONT><FONT face=3D"Arial, Helvetica, sans-serif" color=3D#006699 s=
ize=3D2>
      </FONT><FONT face=3D"Arial, Helvetica, sans-serif" color=3D#006699 
      size=3D2>visit </FONT><FONT face=3D"Arial, Helvetica, sans-serif" 
      color=3D#006699 size=3D2>us at <A 
      href=3D"http://www.unsubscribenow.org">www.UnsubscribeNow.org</A></F=
ONT></DIV>
      <DIV align=3Dleft><a href=3D"http://www.unsubscribenow.org"><img
      src=3D"http://www.unsubscribe-now.net/eml_usn.gif" width=3D"460" hei=
ght=3D"60"
      border=3D"0"></a></DIV>
  <TR>
    <TD vAlign=3Dcenter colSpan=3D2>
      <DIV align=3Dleft><FONT face=3DVerdana size=3D1 color=3D#000000><STR=
ONG>
      Please Forward.... To ensure removal from future online notification=
s,
      <a href=3D'http://www.unsubscribe-now.net/global_remove/'>Remove Now=
</a>
      </STRONG></FONT></DIV>
      <DIV align=3Dleft><FONT face=3DVerdana size=3D1 color=3D#006699>
      Messaging provided by: eGlobal Planet, 244 Madison Ave, #456, New Yo=
rk, NY 10016
      </FONT></DIV>
      <DIV align=3Dleft><FONT face=3DVerdana size=3D1 color=3D#006699>
      <a href=3D'http://www.unsubscribenow.org/support_privacy.php'>Privac=
y Policy</a>
      This message is a US Federal CAN Spam compliant advertisement. 
      </STRONG></FONT></DIV>
      <DIV align=3Dleft><STRONG><FONT face=3DVerdana 
      size=3D1></FONT></STRONG></A></DIV></TD></TR>
</TBODY></TABLE></CENTER>

----274836256165949156--

(no subject)

[Walden Teri]

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

chicanery compleat folk rabies howell adrienne rim 
bindle corral rhodolite compliment emphatic translate henderson 
atkins okay raven extroversion 

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

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Lutz Julianne]

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

pappy doberman siren ratty conjugacy daze 
delinquent counterproposal aliphatic lute rotogravure autotransformer whitlock cologne hoard 
freudian eighth hinman deaden occident crossover auditory morsel kitten calculable 

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

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Luc Teirlinck]

The changes in:

2003-11-16  Jan Djarv  <jan.h.d@swipnet.se>

do not seem to take the native scrollbar into account.  Configuring
without options works fine, but after:

./configure --without-toolkit-scroll-bars

bootstrapping still works fine, but when trying to start Emacs, I get
an immediate segfault:

[bash2.05b.0 ~ 3 1] gdb emacs-21.3.50
(gdb) run
Starting program: /usr/local/bin/emacs-21.3.50 

Program received signal SIGSEGV, Segmentation fault.
0x080bc5ff in x_window_to_scroll_bar (display=0x85f5ab8,
window_id=60817438)
    at xterm.c:3880
3880         if (FRAME_X_DISPLAY (XFRAME (frame)) != display)
(gdb) 


I do not know the code in question well enough to fix this myself.

Sincerely,

Luc.

Re: (no subject)

[Jan D.]

> The changes in:
> 
> 2003-11-16  Jan Djarv  <jan.h.d@swipnet.se>
> 
> do not seem to take the native scrollbar into account.  Configuring
> without options works fine, but after:
> 
> ./configure --without-toolkit-scroll-bars
> 
> bootstrapping still works fine, but when trying to start Emacs, I get
> an immediate segfault:
> 
> [bash2.05b.0 ~ 3 1] gdb emacs-21.3.50
> (gdb) run
> Starting program: /usr/local/bin/emacs-21.3.50 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x080bc5ff in x_window_to_scroll_bar (display=0x85f5ab8,
> window_id=60817438)
>     at xterm.c:3880
> 3880         if (FRAME_X_DISPLAY (XFRAME (frame)) != display)
> (gdb) 
> 

This was trying to fix the very rare case where you get
identical window id from two X displays.

I have checked in a better fix.  There are too many configurations to
test. :-(

Thanks,


	Jan D.

(no subject)

[george mbulu]

Dear friend
 
As you read this, I don't want you to feel sorry for
me, because, I believe everyone will die someday.
 
My name is  George Mbulu, a merchant in Dubai, in the
U.A.E.I have been diagnosed with Esophageal cancer
which was discovered very late, due to my laxity in
carrying for my health. It has defiled all forms of
medicine, and right now I have only about a few
months to live, according to medical experts.
I have not particularly lived my life so well, as I
never really cared for anyone not even myself but my
business. Though I am very rich, I was never
generous, I was always hostile to people and only
focus on my business as that was the only thing I
cared for. But now I regret all this as I now know
that there is more to life than just wanting to have
or make all the money in the world.
I believe when God gives me a second chance to come
to this world I would live my life a different way
from how I have lived it. Now that God ! has called
me, I have willed and given most of my properties
and assets to my immediate and extended family
members and as well as a few close friends.
I want God to be merciful to me and accept my soul
and so, I have decided to give alms to charity
organizations, as I want this to be one of the last
good deeds I do on earth. So far, I have distributed
money to some charity organizations in the U.A.E,
Algeria and Malaysia. Now that my health has
deteriorated so badly, I cannot do this my self any
more. I once asked members of my family to close one
of my accounts and distribute the money which I have
there to charity organization in Bulgaria and
Pakistan, they refused and kept the money to
themselves. Hence, I do not trust them anymore, as
they seem not to be contended with what I have left
for them.
The last of my money which no one knows of is the
huge cash deposit of twenty four million dollars
that I have with a security company in Amsterdam Holland.The name of the company is coin securities compies in Holland.
I will want you to help me col lect this deposit and
dispatched it to charity organizations.You can reach me on:georgembulu@yahoo.com
I have set aside 10% for you for your time and
patience.
 
God be with you.
 
George

NB:IT IS ONLY YOU AND I KNOW WHAT IS THE CONTENT OF THE TRUNKBOX.
 
 


___________________________________________________
Check-out GO.com
GO get your free GO E-Mail account with expanded storage of 6 MB!
http://mail.go.com

Re: (no subject)

[Richard Stallman]

      (while file-exists-p target-file)
	;; Remove the target before writing it, so that any
	;; hard-links continue to point to the old file (this makes
	;; it possible for installed files to share disk space with
	;; the build tree, without causing problems when emacs-lisp
	;; files in the build tree are recompiled).
	(delete-file target-file))

    This is a hack for developers, and shouldn't be in the releases, in my
    opinion. For example, it trashes the .elc file permissions, not to
    speak about symlinks, etc.

I think we need to keep this feature.

Re: (no subject)

[shuki_duv]

Richard Stallman <rms@gnu.org> wrote:
>>    (while file-exists-p target-file)
>> 	;; Remove the target before writing it, so that any
>> 	;; hard-links continue to point to the old file (this makes
>> 	;; it possible for installed files to share disk space with
>> 	;; the build tree, without causing problems when emacs-lisp
>> 	;; files in the build tree are recompiled).
>> 	(delete-file target-file))
>> 
>>    This is a hack for developers, and shouldn't be in the releases, in
>>    my opinion. For example, it trashes the .elc file permissions, not
to
>>    speak about symlinks, etc.
> 
> I think we need to keep this feature.

Of what use is it to users (as opposed to the developers)? On the other
hand, for example, I am maintaining an emacs configuration which is in
widespread use (via -u). My umask is 077, and whenever I recompile a file,
I need to change its .elc counterpart permissions back.

You could say that I should change the recompiling function, but in my
opinion, the UNIX way of rewriting files is in no need of questionable
improvements like these. At the least, one could ensure that the number of
hardlinks is more than one before erasing target-file.

Also, what if target-file is a symlink? In my opinion, this feature only
confuses matters.

Best regards,
Shuki

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: (no subject)

[Miles Bader]

On Tue, Aug 12, 2003 at 06:11:23AM -0700, shuki_duv@yahoo.com wrote:
> Of what use is it to users (as opposed to the developers)?

Even if one were to accept that the distinction were relevant, how, pray
tell, does emacs know which you are?  The very fact that you're compiling .el
file multiple times suggests that you, in fact, are actually more like a
`developer.'

In any case, I think the point is that emacs simply doesn't know what you
want, and can't, unless you tell it.  Perhaps something like a
`byte-compile-overwrite-output-file' could be added to do what you want.

> On the other hand, for example, I am maintaining an emacs configuration
> which is in widespread use (via -u). My umask is 077, and whenever I
> recompile a file, I need to change its .elc counterpart permissions back.

Writing a new file (as opposed to overwriting the old one) is very common
in unix tools (especially in emacs).  If you have set up your environment so
that this doesn't do what you want, you have to deal with the result yourself
(it's not like it's hard).

> Also, what if target-file is a symlink? In my opinion, this feature only
> confuses matters.

Relying on writing files through a symlink is similarly something you can't
rely on; you simply shouldn't do that in general.

-Miles
-- 
We live, as we dream -- alone....

Re: (no subject)

[Thien-Thi Nguyen]

<shuki_duv@yahoo.com> writes:

   Of what use is it to users (as opposed to the developers)?

users opposing programmers is opposite of emacs' (and one could say
fsf's) appeal.  IME people who can't see it this way tend to make life
more difficult for those who can.

   Also, what if target-file is a symlink? In my opinion, this feature
   only confuses matters.

luckily, although matters may be confusing, in the end it is each person
who is or is not confused, individually.  i wouldn't wish my confusion
on anyone; i worked hard to acquire it!

thi

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Tue, 5 Nov 2002, Stefan Monnier wrote:

> > > Maybe this can be achieved by making
> > > "smaller" releases, where each new release has fewer new features.
> > 
> > That requires a higher degree of control than we have now over what
> > changes are installed on the trunk.  As long as each change does not
> > need to be approved before it's installed, I think we cannot guarantee
> > that some new features are postponed.
> 
> That's not true.  We can and do declare feature freezes and we can
> impose them pretty effectively by shaming the poor soul who disobeys
> and undoing his change.

Feature freeze means there are _no_ new features until the thaw; Kai 
suggested a finer control (allow some new features, but not others).

I also have a clear impression that reverting changes is something we 
do only as the last resort (and for a number of good reasons; I don't 
suggest doing that more often!).  I don't remember a single change that 
was reverted because we thought it would destabilize the code, I think 
the few cases of chnage revrsal were all due to known bugs they caused, 
not because we were afraid of unknown bugs.

Re: 21.2.90 pretest, 21.3, 21.4...

[Kim F. Storm]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Feature freeze means there are _no_ new features until the thaw; Kai 
> suggested a finer control (allow some new features, but not others).

IMO, a feature freeze on the trunk at the current state would be OK!

There are now so many new features and fixes compared to 21.[1-3], that
starting a pretest cycle for 21.4 from the trunk would be a _good thing_
to start getting all those new features tested (before we add even more
features).

Admittedly, it would halt "development" on the trunk for, say 2-3
months, but what's the purpose of such developments anyway if we
(virtually) never make a release containing those new features?

So I suggest that we announce a date (e.g. Dec 1st) for a trunk
feature freeze and make the first pretest for 21.4 soon thereafter,
with the goal of releasing 21.4 no later than Mar 1st, 2003!

In my experience, the trunk has been very stable for a very long time
[with a few hickups of course], so after the first few pretests, I
would assume that the software would be stable enough for a release,
or at least stable enough that we could make a 21_4 release branch for
ironing out the final issues with the 21.4 release and remove the
feature freeze on the trunk before Mar 1st (or whenever 21.4 will
actually be ready).

Are anyone of you aware of any significant stability (or redisplay)
related bugs that we need to fix before 21.4 ?

Are there any of the on-going tasks which *must be* completed before
we release 21.4 ?

I know we need some work on the manuals for the new features; maybe
the goal of releasing 21.4 soon will also move our focus towards
writing proper documentation for the new features (I know I still have
a few pending tasks in that area).

WDYT ??

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

(no subject)

[Kenichi Handa]

In article <5xbs52oor1.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes:
> Are there any of the on-going tasks which *must be* completed before
> we release 21.4 ?

(1) I'm working on fixing ps-print and ps-mule so that
non-ASCII characters in a buffer name can also be converted
to correct PostScript code.   I think I can find time to
finish it by the end of this month.

(2) I've just installed an automatic character composition
mechanism in emacs-unicode branch.  It works like font-lock.
I think it is worth back-porting to HEAD because it is very
convenient for such scripts that require complicated
displaying (thai, lao, devanagari, tibetan).  But, It seems
that I don't have enough time to do that.  Aren't there any
volunteer?

(3) Currently, one person is working on Malayalam support in
emacs-unicode.  It is also worth back-poring to HEAD.  But,
as it is just adding a new language support, it may be
possible to add it even after feature freeze.

---
Ken'ichi HANDA
handa@m17n.org

Re: (no subject)

[Richard Stallman]

    (2) I've just installed an automatic character composition
    mechanism in emacs-unicode branch.  It works like font-lock.
    I think it is worth back-porting to HEAD

Why bother?  We could just wait till we adopt the Unicode changes
and we will get to the same place.

Text mode menu wishlist

[Sacha Chua]

The EmacsWiki has a new node: http://www.emacswiki.org/cgi-bin/wiki.pl?TextMenu

---
We need a good replacement for tmm (f10) which does not confuse the
blind. A start is available as Lisp:textmenu.el. Read the
documentation for define-key and improve it.
---
Please define "confuse the blind." I need to know what people like or
don't like about tmm.el and textmenu.el. I have copious amounts of
free time and quite a great bit of interest in making this
work. Personal itches: changing keymaps and losing the ability to C-h
k.
--- (me)

I'd like to know people's thoughts on this. You can either add to the wiki,
post to emacs-devel or e-mail me directly, and I'll keep the wiki page updated. =)

-- 
Sacha Chua <sacha@free.net.ph> - 4 BS CS Ateneo geekette
interests: emacs, gnu/linux, wearables, teaching compsci

Re: Text mode menu wishlist

[Alex Schroeder]

Sacha Chua <sacha@free.net.ph> writes:

> I'd like to know people's thoughts on this. You can either add to
> the wiki, post to emacs-devel or e-mail me directly, and I'll keep
> the wiki page updated. =)

People like me would like a simple buffer where we can use up and down
and RET to select a menu entry.  This can be done in Lisp and works
for me.

Other people would like to see "real" menus in the console, but that
requires messing with the C code.  The basic stuff is already there in
the MSDOS port (which has "real" menus), all we need is to do is port
that to curses or something.  I think this would also work for the
blind which will probably use emacs -nw anyway.  But it would not be
enough for me if I wanted to use a buffer-based menu eventhough I am
running X.

Alex.

Re: Text mode menu wishlist

[Sacha Chua]

Alex Schroeder <alex@emacswiki.org> writes:

> People like me would like a simple buffer where we can use up and down
> and RET to select a menu entry.  This can be done in Lisp and works
> for me.

tmm does that, doesn't it? Or, well, it uses the history mechanism,
and you can pageup to get to the completion buffer...

> Other people would like to see "real" menus in the console, but that
> requires messing with the C code.  The basic stuff is already there in

I can start studying ncurses and the Emacs C code if people feel that this is
important enough. =) 

> blind which will probably use emacs -nw anyway.  But it would not be
> enough for me if I wanted to use a buffer-based menu eventhough I am
> running X.

What would an ideal buffer-based menu be for you?  Simple buffer, up
and down and ret, tab, mouse clicks, ability to go up to the parent
menu.. what else? =)

-- 
Sacha Chua <sacha@free.net.ph> - 4 BS CS Ateneo geekette
interests: emacs, gnu/linux, wearables, teaching compsci

Re: Text mode menu wishlist

[Thien-Thi Nguyen]

Sacha Chua <sacha@free.net.ph> writes:

   I can start studying ncurses and the Emacs C code if people feel that
   this is important enough. =)

perhaps you can kill two birds w/ one stone by prototyping using
guile-ncurses, q.v.

thi

Re: Text mode menu wishlist

[Miles Bader]

Thien-Thi Nguyen <ttn@glug.org> writes:
>    I can start studying ncurses and the Emacs C code if people feel that
>    this is important enough. =)
> 
> perhaps you can kill two birds w/ one stone by prototyping using
> guile-ncurses, q.v.

Um, emacs doesn't use curses.

You probably want to do this at the emacs glyph-matrix level.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

(no subject)

[Thien-Thi Nguyen]

   From: Miles Bader <miles@lsi.nec.co.jp>
   Date: 10 Sep 2002 16:48:40 +0900

   Um, emacs doesn't use curses.

   You probably want to do this at the emacs glyph-matrix level.

sorry, i thought we were talking about text menus.
(however, note the weasle-word "prototyping". :-)

thi

(no subject)

[Dhruva Krishnamurthy]

Hi,
 The latest promotion fails to compile on W2K using MinGW32 (gcc) with
 the following message.

with regards,
dhruva

xdisp.c: In function `get_window_cursor_type':
xdisp.c:15330: structure has no member named `x_highlight_frame'
gmake[1]: *** [oo-spd/i386/xdisp.o] Error 1
gmake[1]: Leaving directory `D:/tmp/emacs/emacs/src'
gmake: *** [all-other-dirs-gmake] Error 2


-- 
Dhruva Krishnamurthy
Home: http://www.geocities.com/gnued/

(no subject)

[Richard Stallman]

I sent this request for the first time about two weeks ago, but I have
not heard from anyone.  I need help to make the new Emacs manual good.
Please do check part of the manual, and then please tell me about it.


I have updated the Emacs Manual for all the features listed in NEWS.
That is, I added documentation of these features--there might be other
parts of the manual that are no longer accurate and need correction.

Can people please try reading a chapter or file of the manual,
looking for anything that is incorrect or ought to be changed?
Whether it is a misspelled word, or incorrect grammar, or unclear
text, or a statement that used to be true but isn't true now,
please report it to me.

Please tell me which chapter or file you read, so I can check
coverage.  If you can do more than one chapter or file,
that would be good too.

Re: (no subject)

[Simon Josefsson]

Richard Stallman <rms@gnu.org> writes:

> I have updated the Emacs Manual for all the features listed in NEWS.

I did not read a chapter in particular, but I searched for
documentation related to fringes and found that the elisp manual
doesn't document the left-fringe and right-fringe frame parameters.

(I read the Emacs 21.3 RC info files, which doesn't seem to be synched
with HEAD, I'm not sure which one you wanted us to read.)

Re: (no subject)

[Richard Stallman]

    I did not read a chapter in particular, but I searched for
    documentation related to fringes and found that the elisp manual
    doesn't document the left-fringe and right-fringe frame parameters.

I haven't updated the Emacs Lisp Manual, just the Emacs Manual.

The version I'd like people to read are the one in the trunk.

(no subject)

[Free Concert Tickets!]

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


 

TI wants to send you to your favourite concerts for free! 

Simply tell us what kind of music you like and we will notify you when your favourite shows are in your area. TI does not need your name or any other personal information making this a risk free opportunity. Great seats are given away at every show and one lucky subscriber will even get a chance to go backstage.
For more information about this offer click here. To get started immediately, complete the short survey below.
At Ticket Inbox we recognize that your time is valuable. Part of our success is because we adhere to Federal Government regulations on Internet privacy and we deliver on our promise to give you the best concert and event information. 

We welcome your feedback and if at anytime you are not satisfied you can unsubscribe. 


Subscribe now and Never Miss a Beat!
SUBSCRIBE NOW FOR FREE:


Area Code:  201202203204205206207208209210212213214215216217218219224225228229231234239240242246248250251252253254256260262264267268270276281284289301302303304305306307308309310312313314315316317318319320321323330334336337339340345347351352360361386401402403404405406407408409410412413414415416417418419423425434435440441443450469473478479480484501502503504505506507508509510512513514515516517518519520530540541551559561562563567570571573574580585586601602603604605606607608609610612613614615616617618619620623626630631636641646647649650651660661662664670671678682701702703704705706707708709712713714715716717718719720724727731732734740754757758760763765767770772773774775778780781784785786787801802803804805806807808809810812813814815816817818819828830831832843845847848850856857858859860862863864865867868869870876878901902903904905906907908909910912913914915916917918919920925928931936937939940941949952954956970971972973978979980985989

Confirmation email:
 

Music Preferences: 

AlternativeBluesJazz
CountryClassicalChristian
GospelFolkHip Hop/Rap
IndieLatinMetal
New AgeOldiesPop
PunkR&B/SoulReggae
Rock n RollRootsTraditional Pop
WorldtejanoSymphony

 




Home | About | Members | Benefits | Statistics & Events | Modify Your Profile | Contact Us | Promoter Info

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

(no subject)

[laurent mpeti kabila]

REQUEST FOR URGENT BUSINESS ASSISTANCE
--------------------------------------
Your contact was availed to me by the chamber of
commerce. It was given
to me because of my diplomatic status as I did not
disclose the actual
reasons for which I sought your contact. But I was
assured
That you are reputable and trustworthy if you will be
of assistance. I am Laurent Mpeti Kabila (Jnr) the
second son of
Late President LAURENT DESIRE KABILA the immediate
Past president of the DEMOCRATIC REPUBLIC OF CONGO in
Africa who was
murdered by his opposition through his personal
bodyguards in his bedroom
on Tuesday 16th January, 2001. I have the privilege of
being mandated
by my father colleagues to seek your immediate and
urgent co-operation
to receive into your bank account the sum of US $25m.
(twenty-five million Dollars) and some thousands carats
of Diamond. This
money and treasures was lodged in a vault with a
security firm in
Europe and South-Africa.

SOURCES OF DIAMONDS AND FUND
In August 2000, my father as a defence minister and
president has a
meeting with his cabinet and armychief about the
defence budget for 2000
to 2001 which was US $700m. so he directed one of his
best
friend. Frederic Kibasa Maliba who was a minister of
mines and a political party leader known as the Union
Sacree de, I\x11
opposition radicale et ses allies (USORAL) to buy arms
with US $200m on
5th January 2001; for him to finalized the arm\x12s deal,
my father was
murdered. f.K. Maliba (FKM) and I have decided to keep
the money with a
foreigner after which he will use it to contest for
the political
election. Inspite of all this we have resolved to
present your or your company
for the firm to pay it into your nominated account the
above sum and
diamonds. This transaction should be finalized within
seven (7) working
days and for your co-operation and partnership, we
have unanimously
agreed that you will be entitled to 5.5% of the money
when successfully
receive it in your account. The nature of your
business is not relevant to
the successful execution of this transaction what we
require is your
total co-operation and commitment to ensure 100%
risk-free transaction at
both ends and to protect the persons involved in this
transactio!
n, strict confidence and utmost secrecy is required
even after the
successful conclusion of this transaction. If this
proposal is acceptable
to you, kindly provide me with your personal telephone
and fax through
my E-mail box for immediate commencement of the
 transaction. I count on your honour to keep my
secret, SECRET.

Looking forward for your urgent reply
Thanks.
Best Regards

MPETI L. KABILA (Jnr)

Re: ctext-pre-write-conversion barfs

[Tak Ota]

Sat, 23 Feb 2002 10:48:42 +0200: "Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> Do you have any real-life example of using compound-text in a way that
> causes it to be called from write-region?  Note that compound-text is
> generally inappropriate for use in file I/O, as its string says (it
> can't DTRT with multibyte text).

I don't know the exact mechanism why ctext-pre-write-conversion was
summoned.  But it was where the debug-on-error brought me to, while
using a mail package 'Mew' (3.0.54).  Following is the last function
issued in Mew (mew-mark.el) where write-region was called with a
string for the argument START.

(defun mew-summary-clean-folder-cache (folder)
  "Erase Summary mode then remove and touch the cache file."
  (if (get-buffer folder)
      (save-excursion
	(set-buffer folder)
	(mew-erase-buffer)
	(set-buffer-modified-p nil)))
  (let ((cfile (mew-expand-folder folder mew-summary-cache-file)))
    (if (file-exists-p cfile)
	(write-region "" nil cfile nil 'no-msg))))

BTW, I just now tried to save this buffer and noticed that
ctext-pre-write-conversion was invoked.  It is called 3 times for
each save-buffer.  Here is the output from describe-coding-system.

-Tak


Coding system for saving this buffer:
  x -- ctext-unix

Default coding system (for new files):
  S -- sjis (alias of japanese-shift-jis)

Coding system for keyboard input:
  S -- sjis (alias of japanese-shift-jis)

Coding system for terminal output:
  S -- sjis (alias of japanese-shift-jis)

Defaults for subprocess I/O:
  decoding: S -- sjis (alias of japanese-shift-jis)

  encoding: S -- sjis (alias of japanese-shift-jis)


Priority order for recognizing coding systems when reading files:
  1. iso-2022-jp (alias: junet)
  2. japanese-iso-8bit (alias: euc-japan-1990 euc-japan euc-jp)
  3. japanese-shift-jis (alias: shift_jis sjis)
  4. iso-2022-jp-2 
  5. iso-latin-1 (alias: iso-8859-1 latin-1)
  6. iso-2022-7bit 
  7. iso-2022-8bit-ss2 
  8. emacs-mule 
  9. raw-text (alias: mew-cs-text mew-cs-text-lf mew-cs-text-crlf mew-cs-text-cr mew-cs-text-net)
  10. chinese-big5 (alias: big5 cn-big5)
  11. no-conversion (alias: binary)
  12. mule-utf-8 (alias: utf-8)

  Other coding systems cannot be distinguished automatically
  from these, and therefore cannot be recognized automatically
  with the present coding system priorities.

  The following are decoded correctly but recognized as iso-2022-jp-2:
    iso-2022-7bit-ss2 iso-2022-7bit-lock iso-2022-7bit-lock-ss2 iso-2022-cn iso-2022-cn-ext iso-2022-kr

Particular coding systems specified for certain file names:

  OPERATION	TARGET PATTERN		CODING SYSTEM(s)
  ---------	--------------		----------------
  File I/O	"\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'"
					(no-conversion . no-conversion)
		"\\.tgz\\'"		(no-conversion . no-conversion)
		"\\.bz2\\'"		(no-conversion . no-conversion)
		"\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'"
					(no-conversion . no-conversion)
		"\\.elc\\'"		(emacs-mule . emacs-mule)
		"\\.utf\\(-8\\)?\\'"	utf-8
		"\\(\\`\\|/\\)loaddefs.el\\'"
					(raw-text . raw-text-unix)
		"\\.tar\\'"		(no-conversion . no-conversion)
		""			find-buffer-file-type-coding-system
  Process I/O	nothing specified
  Network I/O	"nntp"			(junet-unix . junet-unix)
		110			(no-conversion . no-conversion)
		25			(no-conversion . no-conversion)

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

(no subject)

[Eli Zaretskii]

	 Tak Ota on Sat, 23 Feb 2002 08:11:49 -0800 (PST))
Subject: Re: ctext-pre-write-conversion barfs
Reply-to: Eli Zaretskii <eliz@is.elta.co.il>
References: <20020222.225355.01365596.Takaaki.Ota@am.sony.com>
	    <9743-Sat23Feb2002104842+0200-eliz@is.elta.co.il> <20020223.081149.60852929.Takaaki.Ota@am.sony.com>
--text follows this line--
> Date: Sat, 23 Feb 2002 08:11:49 -0800 (PST)
> From: Tak Ota <Takaaki.Ota@am.sony.com>
> 
> BTW, I just now tried to save this buffer and noticed that
> ctext-pre-write-conversion was invoked.  It is called 3 times for
> each save-buffer.  Here is the output from describe-coding-system.
> 
> Coding system for saving this buffer:
>   x -- ctext-unix

Could you please find out how come the buffer's encoding got set to
ctext-unix?  It's a very unusual coding system for buffers.
Compound-text is normally used for X selections only.

The reason I'm asking you to look into this is that the assumption
behind the code I wrote for the ctext extensions is that ctext is not
normally used for file I/O.  There are limitations of the pre-write
and post-read conversions that make the modified ctext coding system
inappropriate for reading and writing text to/from multibyte buffers.
If ctext is used for file I/O, I will have to revert the decision to
call the new encoding `ctext', and will find some other name.

So please look into this.  Thanks in advance.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: (no subject)

[Tak Ota]

Yamamoto-san,

We find that there is a small conflict in a recent change made to the
developer version of emacs with the coding system used in Mew package.

Could you answer to the following question?  What I can tell is
mew-mule3.el defines as:

;; ctext for consistency --unibyte, -unix for XEmacs's ^M
(defvar mew-cs-m17n (if (mew-coding-system-p 'ctext-unix) 'ctext-unix 'ctext))

Therefore many buffers in Mew sets ctext-unix as the default coding
system.  However, I have no idea how this decision was made.

-Tak

Sat, 23 Feb 2002 13:51:54 -0500: Eli Zaretskii <eliz@gnu.org> wrote:

> 	 Tak Ota on Sat, 23 Feb 2002 08:11:49 -0800 (PST))
> Subject: Re: ctext-pre-write-conversion barfs
> Reply-to: Eli Zaretskii <eliz@is.elta.co.il>
> References: <20020222.225355.01365596.Takaaki.Ota@am.sony.com>
> 	    <9743-Sat23Feb2002104842+0200-eliz@is.elta.co.il> <20020223.081149.60852929.Takaaki.Ota@am.sony.com>
> --text follows this line--
> > Date: Sat, 23 Feb 2002 08:11:49 -0800 (PST)
> > From: Tak Ota <Takaaki.Ota@am.sony.com>
> > 
> > BTW, I just now tried to save this buffer and noticed that
> > ctext-pre-write-conversion was invoked.  It is called 3 times for
> > each save-buffer.  Here is the output from describe-coding-system.
> > 
> > Coding system for saving this buffer:
> >   x -- ctext-unix
> 
> Could you please find out how come the buffer's encoding got set to
> ctext-unix?  It's a very unusual coding system for buffers.
> Compound-text is normally used for X selections only.
> 
> The reason I'm asking you to look into this is that the assumption
> behind the code I wrote for the ctext extensions is that ctext is not
> normally used for file I/O.  There are limitations of the pre-write
> and post-read conversions that make the modified ctext coding system
> inappropriate for reading and writing text to/from multibyte buffers.
> If ctext is used for file I/O, I will have to revert the decision to
> call the new encoding `ctext', and will find some other name.
> 
> So please look into this.  Thanks in advance.
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel