(no subject)

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

require-hard-newlines to use newline

[Chong Yidong]

(Sorry for leaving out a subject field)

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

As I see it, the rationale for turning on require-final-newline is that a
particular type of file should always end in a newline. The user should
type RET himself, but in case he forgets to do so, Emacs does it for him.
So (newline) should be used.

Nothing will go wrong when you save in the middle of a paragraph, since
the code inserts the newline inside a save-excursion. The hard newline
always goes *after* point, at the end of the buffer, where it won't get in
the way.

The specific problem I am trying to solve is with Longlines mode (which is
not part of Emacs.) It is, in principle, impossible for Longlines to
distinguish between the soft newline inserted by require-final-newline and
the soft newline inserted by filling when performing automatic line
wrapping. It therefore turns that newline into a space, with the effect
that buffer-modified-p is always t if you try to save a Longlines buffer
with require-final-newline.

Re: require-hard-newlines to use newline

[Luc Teirlinck]

Chong Yidong wrote:

   Nothing will go wrong when you save in the middle of a paragraph, since
   the code inserts the newline inside a save-excursion. The hard newline
   always goes *after* point, at the end of the buffer, where it won't get in
   the way.

I guess you may be right.  (But it is probably better if Richard still
takes a look at it.)

Sincerely,

Luc.

Re: require-hard-newlines to use newline

[Richard Stallman]

    As I see it, the rationale for turning on require-final-newline is that a
    particular type of file should always end in a newline. The user should
    type RET himself, but in case he forgets to do so, Emacs does it for him.
    So (newline) should be used.

That is true.  But those kinds of files are in special formats, not
human-language text.  What is the motive for setting use-hard-newlines
in one of those buffers?

    The specific problem I am trying to solve is with Longlines mode (which is
    not part of Emacs.) It is, in principle, impossible for Longlines to
    distinguish between the soft newline inserted by require-final-newline and
    the soft newline inserted by filling when performing automatic line
    wrapping.

"Automatic line wrapping" is not a normal Emacs term, and I am not
sure what you mean by it.  Do you mean Auto Fill mode?  If so,
longlines can distinguish the two cases because the newline inserted
by Auto Fill mode is not at the end of the line.

If it means something else, could you please say what?

Re: require-hard-newlines to use newline

[Chong Yidong]

>     As I see it, the rationale for turning on require-final-newline is
>     that a particular type of file should always end in a newline. The
>     user should type RET himself, but in case he forgets to do so, Emacs
>     does it for him. So (newline) should be used.
>
> That is true.  But those kinds of files are in special formats, not
> human-language text.  What is the motive for setting use-hard-newlines
> in one of those buffers?

Require-final-newline is a user option, and if a user customizes it to t
then it is turned on for every buffer, even for human-language text. A
user might do this if he want every file he edits to end in a newline.

>     The specific problem I am trying to solve is with Longlines mode
>     (which is not part of Emacs.) It is, in principle, impossible for
>     Longlines to distinguish between the soft newline inserted by
>     require-final-newline and the soft newline inserted by filling when
>     performing automatic line wrapping.
>
> "Automatic line wrapping" is not a normal Emacs term, and I am not
> sure what you mean by it.  Do you mean Auto Fill mode?  If so,
> longlines can distinguish the two cases because the newline inserted
> by Auto Fill mode is not at the end of the line.
>
> If it means something else, could you please say what?

Like Emacs' built-in Refill mode, Longlines does filling after every user
command, except that it uses its own filling functions (for various
reasons that have to do with simulating the behavior of "word-wrapped"
text editors.) In any case, it makes use of use-hard-newlines to keep
track of hard and soft newlines.

It is impossible to distinguish between a soft newline left at the end of
a line by require-final-newline, and a soft newline produced by, e.g., a
call to kill-line, simply by looking at the context. Both are soft, and
both occur at the end of a line. Both newlines might even occur at the end
of a buffer, if that was the final line. But the first is conceptually a
hard newline, and should not be converted into a space by filling; whereas
the second is a "real" soft newline.

Re: require-hard-newlines to use newline

[Richard Stallman]

    It is impossible to distinguish between a soft newline left at the end of
    a line by require-final-newline, and a soft newline produced by, e.g., a
    call to kill-line,

I don't see how a call to kill-line can produce a newline.
I don't understand you.

		       simply by looking at the context. Both are soft, and
    both occur at the end of a line. Both newlines might even occur at the end
    of a buffer, if that was the final line. But the first is conceptually a
    hard newline

Why do you think it is "conceptually a hard newline"?  I don't think
that is true.

As I understand it, the newline that ends the last line in a paragraph
is normally soft.  A hard newline would end the following blank line.
The newline added by require-final-newline would be at the end of the
last line in a paragraph, so it ought to be soft.

Re: require-hard-newlines to use newline

[Chong Yidong]

> As I understand it, the newline that ends the last line in a paragraph
> is normally soft.  A hard newline would end the following blank line.
> The newline added by require-final-newline would be at the end of the
> last line in a paragraph, so it ought to be soft.

Both of the newline ends the last line in a paragraph, as well as the
newline on the following blank line, are hard. You can verify this for
yourself, but I can also illustrate it. First, recall that soft newlines
are equivalent to spaces, so fill-paragraph can delete a soft newline or
replace it with one or more spaces. Now if you have a paragraph

foo foo\n
bar bar\n
\N
foo bar\n
...

where \n denotes a soft newline and \N a hard newline, then it is refilled to

foo foo\n
bar bar\N
foo bar\n
...

whereas

foo foo\n
bar bar\N
\N
foo bar\n

can't be further refilled.

>     It is impossible to distinguish between a soft newline left at the end
>     of a line by require-final-newline, and a soft newline produced by,
>     e.g., a call to kill-line,
>
> I don't see how a call to kill-line can produce a newline.
> I don't understand you.

kill-line deletes up to and including the newline. Suppose the cursor is
at the indicated position:

foo-!-bar\n[EOB]

Calling kill-lines gives

foo-!-\n[EOB]

which, since soft newlines can be converted to spaces, is refilled to

foo-!-[EOB]

The soft newline at the end is gobbled up. That's the problem.

Re: require-hard-newlines to use newline

[Luc Teirlinck]

Chong Yidong wrote:
   
   Both of the newline ends the last line in a paragraph, as well as the
   newline on the following blank line, are hard.

I believe that you are right on that one.  However, there is another
way to view things.  I believe that the newline inserted automatically
at the end of the buffer if `require-final-newline' is enabled should
be soft.

Here is my reasoning:

I believe that people often save in the middle of a paragraph, but
very rarely in the middle of a word.  C-x C-s inserts a newline at the
end of the file, but in the buffer that newline is just a nuisance.
If you call end-of-buffer you go past the newline and you have to be
careful to do C-b, or you are editing at the wrong place.  Normally,
there is nothing you can do about that, you just have to live with this
(granted small) misfeature of `require-final-newline'.  Because the
newline is soft, if you are careless and start typing at the wrong
place, you can trivially correct the situation with M-q.  However,
Longlines tries to make it convenient on you by translating the
newline back into a space.  Now you can just do end-of-buffer and
immediately continue typing, without having to worry about remembering
to type C-b.  Wonderful.  Making the newline hard would mess this up.
So what is the problem?  From what you told us, apparently that
Longlines marks the buffer modified.  Apart from that the feature (with
_soft_ newline) seems perfect.

I believe to remember that you said that Longlines is not included with
Emacs.  But you could ask the Longlines maintainer to put a function
in after-save-hook that transforms the soft newline into a space,
without marking the buffer modified.  There is no need to mark the
buffer modified, there are no changes that are going to be saved.  On
saving, filling should remove the trailing whitespace at the end of
the buffer and put the newline back in, yielding exactly the same
content as the file currently has on disk.  After this change, it
would seem that the problem disappears and everything is perfect.

Does the above make sense or are there other reasons to make the
newline hard?

Sincerely,

Luc.

Re: require-hard-newlines to use newline

[Chong Yidong]

> C-x C-s inserts a newline at the end of the file, but in the buffer that
> newline is just a nuisance. If you call end-of-buffer you go past the
> newline and you have to be careful to do C-b, or you are editing at the
> wrong place... Because the newline is soft, if you are careless and start
> typing at the wrong place, you can trivially correct the situation with
> M-q.

Typing C-b is no more difficult than typing M-q.

> Longlines tries to make it convenient on you by translating the
> newline back into a space.  Now you can just do end-of-buffer and
> immediately continue typing, without having to worry about remembering
> to type C-b...
> You could ask the Longlines maintainer to put a function
> in after-save-hook that transforms the soft newline into a space,
> without marking the buffer modified.

I *am* the Longlines maintainer. The solution you suggested is no good,
because if you edit somewhere else in the document (not at the end of the
buffer) and save, you will end up with another newline, which gets
converted into another space.

Yes, I can cook up a kludge to work around require-hard-newline if it
continues to use a soft final newline. But the reason I posted this thread
is because that would be unclean. Normal paragraphs are terminated by hard
newlines, and so should the final paragraph.

Re: require-hard-newlines to use newline

[Miles Bader]

BTW, longlines.el seems to be fairly widely used; is there a reason it
hasn't been added to the Emacs distribution?

-Miles

Re: require-hard-newlines to use newline

[Chong Yidong]

> BTW, longlines.el seems to be fairly widely used; is there a reason it
> hasn't been added to the Emacs distribution?

The main reason is the feature freeze. RMS contacted me about putting it
into Emacs a couple months back, and my guess is that it will go in after
this release. My copyright assignment is already in place.

Re: require-hard-newlines to use newline

[David Kastrup]

"Chong Yidong" <cyd@stupidchicken.com> writes:

>> BTW, longlines.el seems to be fairly widely used; is there a reason
>> it hasn't been added to the Emacs distribution?
>
> The main reason is the feature freeze. RMS contacted me about
> putting it into Emacs a couple months back, and my guess is that it
> will go in after this release. My copyright assignment is already in
> place.

Putting a limited optional package in should not really be a concern
for the feature freeze as long as its presence does not imply one
should rework the manual and stuff.  And as long as it does not keep
other people from working on the release.

I don't think this is the case here, but I'd let Richard decide this
instead of trying to interpret the general intent and rules yourself.
It is an often asked for functionality, and the package is more or
less the answer given to that even if I don't know it myself.  But
people need not use it if they don't want to.

So I'd ask Richard instead of censoring yourself.  It is certainly not
worth putting up a fight or argument for, but I don't see the harm in
him taking a look.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: require-hard-newlines to use newline

[Richard Stallman]

    BTW, longlines.el seems to be fairly widely used; is there a reason it
    hasn't been added to the Emacs distribution?

It would be useful for a few experienced Emacs developers to look it
over and make suggestions.

Re: require-hard-newlines to use newline

[Luc Teirlinck]

Richard Stallman wrote:

       BTW, longlines.el seems to be fairly widely used; is there a reason it
       hasn't been added to the Emacs distribution?

   It would be useful for a few experienced Emacs developers to look it
   over and make suggestions.

I am not really the best person to make suggestions.  It would  be
better if longtime users did.  Here are some remarks.

I do not know what the version is that would be included.  I
dowmloaded 2.2.7 from:

//www.emacswiki.org/elisp/index.html

After putting (load "~/longlines.elc") in my .emacs, I had to edit
longlines.el and put: (defvar longlines-mode nil) at the beginning to
avoid a warnings buffer cropping up each time I started Emacs, warning
about the free variable `longlines-mode'.  Just (defvar longlines-mode)
was _not_ sufficient.

If I understood correctly, we do not like code included with the Emacs
distribution to use `defadvice'.  longlines.el uses defadvice for
`newline', `kill-region', `copy-region-as-kill', `yank' and `yank-pop'.

Sincerely,

Luc.

Re: require-hard-newlines to use newline

[Chong Yidong]

"Luc Teirlinck" <teirllm@dms.auburn.edu> wrote:
>    It would be useful for a few experienced Emacs developers to look it
>    [longlines.el] over and make suggestions.
>
> I am not really the best person to make suggestions.  It would  be
> better if longtime users did.  Here are some remarks.
> ...
> After putting (load "~/longlines.elc") in my .emacs, I had to edit
> longlines.el and put: (defvar longlines-mode nil) at the beginning to
> avoid a warnings buffer cropping up each time I started Emacs, warning
> about the free variable `longlines-mode'.  Just (defvar longlines-mode)
> was _not_ sufficient.

I can't reproduce this, and it doesn't make sense; longlines-mode is
defined using define-minor-mode, which should do the variable definition
properly. Could you look into this further? Maybe it is something in your
.emacs.

> If I understood correctly, we do not like code included with the Emacs
> distribution to use `defadvice'.  longlines.el uses defadvice for
> `newline', `kill-region', `copy-region-as-kill', `yank' and `yank-pop'.

Yes, this will have to be fixed before longlines.el can go in.

Re: require-hard-newlines to use newline

[Luc Teirlinck]

Chong Yidong wrote:

   I can't reproduce this, and it doesn't make sense; longlines-mode is
   defined using define-minor-mode, which should do the variable definition
   properly. Could you look into this further? Maybe it is something in your
   .emacs.

I believe that the following should be reproducible:

Do `emacs -Q' `M-x ielm RET", then, after the following ielm run, the
warning appears:

===File ~/longlines-ielm====================================
***nil
 Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (compile-defun
	'(defun my-emacs-exit-question ()
	   "Ask for confirmation before exiting emacs, if there is a visible frame"
	   (if (visible-frame-list)
	       (y-or-n-p "Really quit Emacs? ")
	     t)))
nil
ELISP> (load "~/longlines.elc")
t
ELISP> ============================================================

Re: require-hard-newlines to use newline

[Luc Teirlinck]

The following contains less irrelevant clutter than my previous ielm run.

`emacs -Q' `M-x ielm RET', then:

***nil
 Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (compile-defun (lambda ()))
nil
ELISP> (load "~/longlines.elc")
t

Message appears.

Sincerely,

Luc.

Re: require-hard-newlines to use newline

[Luc Teirlinck]

In my previous ielm run, I somehow managed to misunderstand
`compile-defun', but anyway, the message appears after:

`emacs -Q', `M-x ielm RET' and:

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (load "bytecomp")
t
ELISP> (load "~/longlines.elc")
t
ELISP> 

It does not appear without (load "bytecomp").

Sincerely,

Luc.

Re: require-hard-newlines to use newline

[Chong Yidong]

> ELISP> (load "bytecomp")
> t
> ELISP> (load "~/longlines.elc")
> t
> ELISP>
>
> It does not appear without (load "bytecomp").

Okay, I can reproduce it now. Moving the define-minor-mode call to the top
of the file fixes the problem; thanks.

Strangely enough, M-x byte-compile does not complain about free variables.
Why should (load "bytecomp") be necessary to produce the message?

Re: require-hard-newlines to use newline

[Stefan Monnier]

ELISP> (load "bytecomp")
>> t
ELISP> (load "~/longlines.elc")
>> t
ELISP> 
>> 
>> It does not appear without (load "bytecomp").

> Okay, I can reproduce it now. Moving the define-minor-mode call to the top
> of the file fixes the problem; thanks.

> Strangely enough, M-x byte-compile does not complain about free variables.
> Why should (load "bytecomp") be necessary to produce the message?

Maybe it's because you call M-x byte-compiler from an Emacs where longlines
was already loaded.


        Stefan

Re: require-hard-newlines to use newline

[Luc Teirlinck]

Stefan Monnier wrote:

   Maybe it's because you call M-x byte-compiler from an Emacs where longlines
   was already loaded.

I do not believe so:

[bash2.05b.0 ~ 3 1] emacs-22.0.50 -batch -f batch-byte-compile
longlines.el
Wrote /home/teirllm/longlines.elc
[bash2.05b.0 ~ 3 2] 

Maybe it is because all the offending occurrences of the variable are
in defadvice forms.

Another thing I do not understand is that (devar longlines-mode) did
not help.  Only (devar longlines-mode nil) did.

Sincerely,

Luc.

Re: require-hard-newlines to use newline

[Stefan Monnier]

>    Maybe it's because you call M-x byte-compiler from an Emacs where longlines
>    was already loaded.

> I do not believe so:

> [bash2.05b.0 ~ 3 1] emacs-22.0.50 -batch -f batch-byte-compile
> longlines.el
> Wrote /home/teirllm/longlines.elc
> [bash2.05b.0 ~ 3 2] 

> Maybe it is because all the offending occurrences of the variable are
> in defadvice forms.

Indeed.  The code in defadvice is (generally) not compiled during
byte-compilation.

> Another thing I do not understand is that (devar longlines-mode) did
> not help.  Only (devar longlines-mode nil) did.

A (defvar longlines-mode) doesn't have any long term effect: it only
temporarily tells the byte-compiler to shut up.  This only lasts until the
file is byte-compiled.  If you do further byte-compilation (e.g. of the
advice code or of code output by some macro), the byte-compiler won't
remember that the file where this code originally appeared had a (defvar
longlines-mode).


        Stefan

Re: require-hard-newlines to use newline

[Luc Teirlinck]

I guess that, In Chong's message, I confused byte-compile with
byte-compile-file.  What I believed was strange is that byte compiling
the file produced no warning messages, but maybe that is due to the
variable occurring in defadvice.

Sincerely,

Luc.

Re: require-hard-newlines to use newline

[Richard Stallman]

    If I understood correctly, we do not like code included with the Emacs
    distribution to use `defadvice'.  longlines.el uses defadvice for
    `newline', `kill-region', `copy-region-as-kill', `yank' and `yank-pop'.

Yes,it would be good to think about other mechanisms to use instead
of that.  Yidong, would you like to think about what kind of new hook
might make it possible to do the job?

Re: require-hard-newlines to use newline

[Chong Yidong]

>     If I understood correctly, we do not like code included with the Emacs
>     distribution to use `defadvice'.  longlines.el uses defadvice for
>     `newline', `kill-region', `copy-region-as-kill', `yank' and
>     `yank-pop'.
>
> Yes,it would be good to think about other mechanisms to use instead
> of that.  Yidong, would you like to think about what kind of new hook
> might make it possible to do the job?

What the advice does is mainly encoding and decoding yanked text. When a
piece of text is yanked into a longlines buffer, the newlines have to be
marked as hard. Conversely, when text is killed from a longlines buffer,
the soft newlines have to be removed before it is placed in the kill ring.

As I see it, there are two ways to get around using advice:

1. If Longlines is to be merged into Emacs, lines like
(if (and (fboundp longlines-mode) longlines-mode) blahblahblah)
could be added to kill-region and the other functions. This is what
Transient mark mode does, but I doubt that Longlines mode is "important"
enough to justify it.

2. Defining two new abnormal hooks, maybe named yank-encode-functions and
kill-encode-functions, to be called by kill-region etc (or possibly the
lower-level functions like kill-new and kill-append.) Each function would
be called with one argument, the yanked or killed string, and return an
encoded string to be passed to the next function, or to the buffer/kill
ring. For example, kill-region could do something like

 (mapcar '(lambda (fun) (setq string (funcall fun string)))
         'kill-encode-functions)

Re: require-hard-newlines to use newline

[Chong Yidong]

> 2. Defining two new abnormal hooks, maybe named yank-encode-functions and
> kill-encode-functions, to be called by kill-region etc (or possibly the
> lower-level functions like kill-new and kill-append.) Each function would
> be called with one argument, the yanked or killed string, and return an
> encoded string to be passed to the next function, or to the buffer/kill
> ring.

On further consideration, there seems to be some overlap between the above
suggestion and the yank-handler text property (new to Emacs 22). It may be
better to a variable called `yank-handlers' which is a list of yank
handlers to use. The yank functions could then read from both
yank-handlers and the yank-handler text property.

There is one problem, however: currently, the function specified by the
yank-handler text property is called *instead* of insert, to insert the
desired text. According to NEWS, this is to allow it to do things like
yanking rectanges. Such a function obviously cannot "stack", so what
happens if yank-handlers and the yank-handler text property are both
defined? My original idea was to have the functions specified by
yank-handlers return a string to be passed to the next handler, but (i)
this would be an incompatibility with the text property, and (ii) it won't
be able to perform more general operations like yanking rectangles.

I would also still need an analogous kill-handlers variable for encoding
kills, i.e. stripping out newlines from the killed text (it's not enough
to use a yank handler, because the killed text could be pasted into an
external program via the X selection or clipboard.)

Re: require-hard-newlines to use newline

[Richard Stallman]

    2. Defining two new abnormal hooks, maybe named yank-encode-functions and
    kill-encode-functions, to be called by kill-region etc (or possibly the
    lower-level functions like kill-new and kill-append.)

This would be better than using advice.

    On further consideration, there seems to be some overlap between the above
    suggestion and the yank-handler text property (new to Emacs 22).

The idea of the yank-handler text property is that certain kill
strings are encoded specially, and need to be decoded when they are
yanked.  Maybe longlines could use this instead of a new hook for
yanking.

However, it would still need a hook for killing.  However,
not just for killing.  This hook should be used in various places,
including Fdelete_and_extract_region.

Or maybe you could just use after-change-functions.
Would that work?

Re: require-hard-newlines to use newline

[Chong Yidong]

> The idea of the yank-handler text property is that certain kill
> strings are encoded specially, and need to be decoded when they are
> yanked.  Maybe longlines could use this instead of a new hook for
> yanking.

It is possible to use the yank-handler property to remove the newlines
from longlines text when copying into other Emacs buffers; however, since
the newlines are copied onto the clipboard and X selection, they will show
up when the user does a paste in another application.  So this is not a
good approach.

> Or maybe you could just use after-change-functions.
> Would that work?

The only way I can see for this to work is for the after-change function
to test this-command, which I think is not very robust.

So I guess the best solution is to have an encoding hook for kills, and a
decoding hook for yanks.

I also think we should wait till after the release before implementing
this (which hopefully shouldn't be a long wait...)

Re: require-hard-newlines to use newline

[Kim F. Storm]

"Chong Yidong" <cyd@stupidchicken.com> writes:

> So I guess the best solution is to have an encoding hook for kills, and a
> decoding hook for yanks.
>
> I also think we should wait till after the release before implementing
> this (which hopefully shouldn't be a long wait...)

If we agree that those hooks are the proper approach, and you can
write the proper doc for them, this is a trivial change, so I don't
see why we have to wait.

Especially if that means that longlines.el can go into 22.1.

I think that would be a good thing considering that 23.x is most
likely years rather than months away...  [I hope that's not true for
22.x as well]

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

Re: require-hard-newlines to use newline

[Chong Yidong]

> If we agree that those hooks are the proper approach, and you can
> write the proper doc for them, this is a trivial change, so I don't
> see why we have to wait.
>
> Especially if that means that longlines.el can go into 22.1.

Okay then. How about this patch?

While writing it, I figured out that I only need to introduce one hook
(`before-kill-functions'), not two. The hook for yanking is not needed for
longlines.el -- I can handle that with post-command-hook (which longlines
already makes use of anyway.)

`before-kill-functions' seems like a convenient thing to have in any
event, since Emacs Lisp packages can use it to apply the yank-handler text
property on the fly.


*** simple.el~	Fri Mar 11 19:27:00 2005
--- simple.el	Fri Mar 11 21:00:45 2005
***************
*** 2275,2280 ****
--- 2275,2286 ----
  (defvar kill-ring-yank-pointer nil
    "The tail of the kill ring whose car is the last thing yanked.")

+ (defvar before-kill-functions nil
+   "List of functions called on the region before killing.
+ This abnormal hook is run before `kill-region' and
+ `copy-region-as-kill', with the beginning and end positions of
+ the killed region as the arguments.")
+
  (defun kill-new (string &optional replace yank-handler)
    "Make STRING the latest kill in the kill ring.
  Set `kill-ring-yank-pointer' to point to it.
***************
*** 2371,2376 ****
--- 2377,2385 ----
  The command \\[yank] can retrieve it from there.
  \(If you want to kill and then yank immediately, use \\[kill-ring-save].)

+ This runs the abnormal hook `before-kill-functions' with the
+ arguments BEG and END before actually killing.
+
  If you want to append the killed region to the last killed text,
  use \\[append-next-kill] before \\[kill-region].

***************
*** 2390,2395 ****
--- 2399,2405 ----
  specifies the yank-handler text property to be set on the killed
  text.  See `insert-for-yank'."
    (interactive "r")
+   (run-hook-with-args 'before-kill-functions beg end)
    (condition-case nil
        (let ((string (delete-and-extract-region beg end)))
  	(when string			;STRING is nil if BEG = END
***************
*** 2424,2431 ****
    "Save the region as if killed, but don't kill it.
  In Transient Mark mode, deactivate the mark.
  If `interprogram-cut-function' is non-nil, also save the text for a window
! system cut and paste."
    (interactive "r")
    (if (eq last-command 'kill-region)
        (kill-append (buffer-substring beg end) (< end beg))
      (kill-new (buffer-substring beg end)))
--- 2434,2445 ----
    "Save the region as if killed, but don't kill it.
  In Transient Mark mode, deactivate the mark.
  If `interprogram-cut-function' is non-nil, also save the text for a window
! system cut and paste.
!
! The abnormal hook `before-kill-functions' is run with the
! arguments BEG and END before the region is saved."
    (interactive "r")
+   (run-hook-with-args 'before-kill-functions beg end)
    (if (eq last-command 'kill-region)
        (kill-append (buffer-substring beg end) (< end beg))
      (kill-new (buffer-substring beg end)))

Re: require-hard-newlines to use newline

[Stefan Monnier]

> + (defvar before-kill-functions nil
> +   "List of functions called on the region before killing.
> + This abnormal hook is run before `kill-region' and
> + `copy-region-as-kill', with the beginning and end positions of
> + the killed region as the arguments.")

I think it's usually important to keep the property that killing doesn't
modify the buffer's text (when used in copy-as-kill), so rather than having
before-kill-functions modify the buffer's text just before it's put in the
kill-ring, it would be more convenient to make it return the string,
i.e. use it as a replacement for buffer-substring.


        Stefan

Re: require-hard-newlines to use newline

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> + (defvar before-kill-functions nil
>> +   "List of functions called on the region before killing.
>> + This abnormal hook is run before `kill-region' and
>> + `copy-region-as-kill', with the beginning and end positions of
>> + the killed region as the arguments.")
>
> I think it's usually important to keep the property that killing doesn't
> modify the buffer's text (when used in copy-as-kill), so rather than having
> before-kill-functions modify the buffer's text just before it's put in the
> kill-ring, it would be more convenient to make it return the string,
> i.e. use it as a replacement for buffer-substring.

I like the idea, but returning a value from a hook is rather
inconvenient -- if there are multiple functions on the hook, which
value should you use eventually?

Perhaps before-kill-functions should get START, END and STRING
as arguments where STRING is the result of buffer-substring.

Each hook could then modify that string as they please.


Or perhaps a different approach:

Run after-kill-hooks (a normal hook!) as the last thing in kill-region
and copy-region-as-kill, i.e. after putting the string into
the kill-ring.  If necessary, the hooks can modify the head of
the kill-ring as they please...?

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

Re: require-hard-newlines to use newline

[Chong Yidong]

>> I think it's usually important to keep the property that killing doesn't
>> modify the buffer's text (when used in copy-as-kill), so rather than
>> having before-kill-functions modify the buffer's text just before it's
>> put in the kill-ring, it would be more convenient to make it return the
>> string, i.e. use it as a replacement for buffer-substring.
>
> I like the idea, but returning a value from a hook is rather
> inconvenient -- if there are multiple functions on the hook, which
> value should you use eventually?

Another possibility is not to use a hook at all, e.g.:

(defvar kill-filters nil
  "List of functions for converting a string before it is killed.
Each function should accept a single argument, a string, and
return a string.  Whenever a string is killed, it is passed as an
argument to the first function in the list, and the return value
of each function is passed as the argument to the next.  The
final return value is the string that is actually put in the kill
ring and passed to `interprogram-cut-function'.")

Re: require-hard-newlines to use newline

[Stefan Monnier]

> (defvar kill-filters nil
>   "List of functions for converting a string before it is killed.
> Each function should accept a single argument, a string, and
> return a string.  Whenever a string is killed, it is passed as an
> argument to the first function in the list, and the return value
> of each function is passed as the argument to the next.  The
> final return value is the string that is actually put in the kill
> ring and passed to `interprogram-cut-function'.")

But that makes it difficult to process the string in a way that depends on
its context.


        Stefan

Re: require-hard-newlines to use newline

[Chong Yidong]

> Or perhaps a different approach:
>
> Run after-kill-hooks (a normal hook!) as the last thing in kill-region
> and copy-region-as-kill, i.e. after putting the string into
> the kill-ring.  If necessary, the hooks can modify the head of
> the kill-ring as they please...?

There would be no way for them to modify the text that's been stored into
the X selection or clipboard.

Re: require-hard-newlines to use newline

[Stefan Monnier]

>>> + (defvar before-kill-functions nil
>>> +   "List of functions called on the region before killing.
>>> + This abnormal hook is run before `kill-region' and
>>> + `copy-region-as-kill', with the beginning and end positions of
>>> + the killed region as the arguments.")
>> 
>> I think it's usually important to keep the property that killing doesn't
>> modify the buffer's text (when used in copy-as-kill), so rather than having
>> before-kill-functions modify the buffer's text just before it's put in the
>> kill-ring, it would be more convenient to make it return the string,
>> i.e. use it as a replacement for buffer-substring.

> I like the idea, but returning a value from a hook is rather
> inconvenient -- if there are multiple functions on the hook, which
> value should you use eventually?

> Perhaps before-kill-functions should get START, END and STRING
> as arguments where STRING is the result of buffer-substring.

> Each hook could then modify that string as they please.

Fair enough.

> Or perhaps a different approach:
> Run after-kill-hooks (a normal hook!) as the last thing in kill-region
> and copy-region-as-kill, i.e. after putting the string into
> the kill-ring.  If necessary, the hooks can modify the head of
> the kill-ring as they please...?

I'm not sure if that would be reliable: the head of kill-ring might be the
result of concatenating the old head and the new text, where the old head
has already been processed by after-kill-hook, but you can't tell which part
is the old one and which part is the new one.


        Stefan

Re: require-hard-newlines to use newline

[Chong Yidong]

>> I like the idea, but returning a value from a hook is rather
>> inconvenient -- if there are multiple functions on the hook, which
>> value should you use eventually?
>
>> Perhaps before-kill-functions should get START, END and STRING
>> as arguments where STRING is the result of buffer-substring.
>
>> Each hook could then modify that string as they please.
>
> Fair enough.

Sorry, I'm probably missing something, but I don't understand how this
would work. Since each function would only be modifying their own local
STRING variable, not the one that will actually be killed... Unless it's
something like

  [in kill-region]:
  (let ((string (delete-and-extract-region beg end)))
    (run-hook-with-args 'before-kill-functions beg end #'string)
    ...

Then the hook function would have to set the string by

  (defun foo-function (symbol)
    (set symbol "replacement string"))

But that would be ridiculously arcane.

Re: require-hard-newlines to use newline

[Stefan Monnier]

> Sorry, I'm probably missing something, but I don't understand how this
> would work.

Simple: it wouldn't use run-hook* (or maybe it would introduce a new
run-hook-filter).


        Stefan

Re: require-hard-newlines to use newline

[Chong Yidong]

>> Sorry, I'm probably missing something, but I don't understand how this
>> would work.
>
> Simple: it wouldn't use run-hook* (or maybe it would introduce a new
> run-hook-filter).

Not using a hook seems to be simpler than writing a new run-hook-filter
function.  How about the following?  It seems to be a bit overengineered,
but that's the only way to meet the various objections.


(defvar kill-filters nil
  "List of functions for converting a string before it is killed.
These are called by `kill-region' and `copy-region-as-kill' to
convert a buffer substring before putting it into the kill ring
and passing it to `interprogram-cut-function'.

Each function must accept three arguments: STRING, BEG, and END.
STRING is the string to be converted, and BEG and END are the
position arguments given to `kill-region' or
`copy-region-as-kill'.  Each function must return a string.

The buffer substring between BEG and END is passed as STRING to
the first function in the list, and the return value of each
function is passed as STRING to the next.  The final return value
is used as the killed string.

If this variable is nil, no filtering is performed.")

Re: require-hard-newlines to use newline

[Kim F. Storm]

"Chong Yidong" <cyd@stupidchicken.com> writes:

>>> I like the idea, but returning a value from a hook is rather
>>> inconvenient -- if there are multiple functions on the hook, which
>>> value should you use eventually?
>>
>>> Perhaps before-kill-functions should get START, END and STRING
>>> as arguments where STRING is the result of buffer-substring.
>>
>>> Each hook could then modify that string as they please.
>
> Sorry, I'm probably missing something, but I don't understand how this
> would work. Since each function would only be modifying their own local
> STRING variable, not the one that will actually be killed... 

It doesn't have to modify the variable `string', but its string value, e.g.

(defun x (s)
  (aset s 1 ?-))
(let ((s "abc"))
  (x s)
  s)
=> "a-c"

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

Re: require-hard-newlines to use newline

[Chong Yidong]

>> Sorry, I'm probably missing something, but I don't understand how this
>> would work. Since each function would only be modifying their own local
>> STRING variable, not the one that will actually be killed...
>
> It doesn't have to modify the variable `string', but its string value,
> e.g.
>
> (defun x (s)
>   (aset s 1 ?-))
> (let ((s "abc"))
>   (x s)
>   s)
> => "a-c"

But this method restricts the possible manipulations to those that keep
the string length unchanged.  That is fine for longlines, which is just
swapping spaces and newlines, but it may not be very useful for other
(hypothetical) purposes.  Even for longlines, aset would be very
inconvenient to use.

Re: require-hard-newlines to use newline

[Richard Stallman]

    > If we agree that those hooks are the proper approach, and you can
    > write the proper doc for them, this is a trivial change, so I don't
    > see why we have to wait.

    Okay then. How about this patch?

It only does a part of the job.  It handles kill, but not registers,
etc.  I think it is implemented at the wrong level.

Stefan wrote:

    I think it's usually important to keep the property that killing doesn't
    modify the buffer's text (when used in copy-as-kill), so rather than having
    before-kill-functions modify the buffer's text just before it's put in the
    kill-ring, it would be more convenient to make it return the string,
    i.e. use it as a replacement for buffer-substring.

That is true, too.

    Another possibility is not to use a hook at all, e.g.:

    (defvar kill-filters nil
      "List of functions for converting a string before it is killed.
    Each function should accept a single argument, a string, and
    return a string.

That is more the right idea, for the part that reads from
the buffer.  But it is not correct to associate this with
killing.  Think of it as a variant of buffer-substring.

    But that makes it difficult to process the string in a way that depends on
    its context.

Maybe so, but is it necessary to do that?

Re: require-hard-newlines to use newline

[Stefan Monnier]

>     But that makes it difficult to process the string in a way that
>     depends on its context.
> Maybe so, but is it necessary to do that?

I haven't thought really hard about it, but superficially, it would seem
like a pretty common occurrence that the transformation should be different
depending on the context (things like "was the beginning of the string at
BOL?", or maybe for message-mode "is this taken from the header or the body
of the email", ...).


        Stefan

Re: require-hard-newlines to use newline

[Richard Stallman]

    I haven't thought really hard about it, but superficially, it would seem
    like a pretty common occurrence that the transformation should be different
    depending on the context (things like "was the beginning of the string at
    BOL?", or maybe for message-mode "is this taken from the header or the body
    of the email", ...).

It's often a mistake to aim for generality that goes beyond the uses
we have envisioned, because any easy job can be made hard if you do
that.  Anyway, it is easy enough to have a convention to put point at
the start of where the text came from, before running the hook
functions.

Re: require-hard-newlines to use newline

[Chong Yidong]

> It only does a part of the job.  It handles kill, but not registers,
> etc.  I think it is implemented at the wrong level.
>
>>     (defvar kill-filters nil
>>       "List of functions for converting a string before it is killed.
>>     Each function should accept a single argument, a string, and
>>     return a string.
>
> That is more the right idea, for the part that reads from
> the buffer.  But it is not correct to associate this with
> killing.  Think of it as a variant of buffer-substring.

By this, I'm guessing you mean going to a lower level, e.g. calling the
filter functions from inside buffer-substring.  I'll look into this, but I
doubt it's worth it.

The current behavior of longlines.el, which is to filter at the level of
kill-region and copy-region-as-kill, addresses the main requirement of
users -- removing the soft newlines when copying into another program or
yanking into a non-longlines buffer.  All the bugs here have been pretty
much ironed out.  It doesn't deal with *all* the situations where
filtering might be good, like copy-to-register, but we could simply make
those commands use the filter too.

buffer-substring is called in many, many places, and I'm not confident
that filtering is appropriate everywhere.  For example, fill.el calls
buffer-substring all over the place, and one feature of longlines is that
M-q still works as usual; changing buffer-substring may screw it up.

I suggest implementing the `kill-filter' variable I proposed; then I will
change longlines.el to use it, and we can put longlines.el into Emacs. 
This version of longlines.el will be the same as the existing
"third-party" longlines.el, except it won't use advice.  A future version
can implement something more elegant. (I have other plans for longlines.el
too, including providing word wrap for files which are already full of
hard newlines.)

Re: require-hard-newlines to use newline

[Richard Stallman]

    > That is more the right idea, for the part that reads from
    > the buffer.  But it is not correct to associate this with
    > killing.  Think of it as a variant of buffer-substring.

    By this, I'm guessing you mean going to a lower level, e.g. calling the
    filter functions from inside buffer-substring.

No, buffer-substring should not call them.  That's why I said "a
variant of buffer-substring".  Some places would call this new
variant, but some would continue to call the existing, ordinary
buffer-substring function.

    I suggest implementing the `kill-filter' variable I proposed; then I will
    change longlines.el to use it, and we can put longlines.el into Emacs. 

That's not right.  It only does part of the job.  Killing is not the
only feature that needs to do this processing.

Anyway, what about my other suggestion?  The suggestion to make
longlines.el use after-change-functions to discover all new text inserted
in the buffer, and do longlines processing on that text?

Re: require-hard-newlines to use newline

[Chong Yidong]

> Anyway, what about my other suggestion?  The suggestion to make
> longlines.el use after-change-functions to discover all new text inserted
> in the buffer, and do longlines processing on that text?

I am already making longlines.el use post-command-hook to process text
yanked *into* the longlines buffer.  But I need a separate mechanism to
process text yanked *out of* the buffer, and neither post-command-hook nor
after-change-functions are suitable for this.  By the time the hook is
called, the text has already been put into the kill ring and clipboard.

> No, buffer-substring should not call them.  That's why I said "a
> variant of buffer-substring".  Some places would call this new
> variant, but some would continue to call the existing, ordinary
> buffer-substring function.

In that case, I don't think our ideas are so different.  I'll alter my
patch to implement the `kill-filters' variable, and make the appropriate
functions use it before calling buffer-substring.  So far, these functions
are `kill-region', `copy-region-as-kill', and `copy-to-register'; are
there others?

Re: require-hard-newlines to use newline

[Richard Stallman]

    > Anyway, what about my other suggestion?  The suggestion to make
    > longlines.el use after-change-functions to discover all new text inserted
    > in the buffer, and do longlines processing on that text?

    I am already making longlines.el use post-command-hook to process text
    yanked *into* the longlines buffer.

Ok.  So all that's missing is to process the text that is copied OUT OF
this buffer.

In that case, if the hook you've implemented does the job for
longlines.el, let's install it.

Re: require-hard-newlines to use newline

[Richard Stallman]

    The only way I can see for this to work is for the after-change function
    to test this-command, which I think is not very robust.

I don't understand.  Why check this-command?  Wouldn't it be correct
for longlines.el to operate on ALL text inserted in the buffer?

Re: require-hard-newlines to use newline

[Richard Stallman]

    First, recall that soft newlines
    are equivalent to spaces, so fill-paragraph can delete a soft newline or
    replace it with one or more spaces.

					Now if you have a paragraph

    foo foo\n
    bar bar\n
    \N
    foo bar\n
    ...

    where \n denotes a soft newline and \N a hard newline, then it is refilled to

    foo foo\n
    bar bar\N

That seems to be replacing \n with zero spaces, not with one space.
Is it correct?

Anyway, if it is a fact that both of these newlines are normally
hard, then it seems to me that there is no way of telling
whether the user wants a hard newline or a soft one
when require-final-newline adds a newline.
A user might save the file with an unfinished paragraph,
then go back to writing more of it.

Perhaps use-hard-newlines should inhibit the effect of
require-final-newline.

Re: require-hard-newlines to use newline

[Chong Yidong]

> Anyway, if it is a fact that both of these newlines are normally
> hard, then it seems to me that there is no way of telling
> whether the user wants a hard newline or a soft one
> when require-final-newline adds a newline.
> A user might save the file with an unfinished paragraph,
> then go back to writing more of it.

I don't think there's a problem in this situation; he just has to make
sure that point is before the final (hard) newline before he continues
editing. Furthermore, there is no need to re-position point, because the
final newline is inserted inside a save-excursion, *after* point.

Re: require-hard-newlines to use newline

[Richard Stallman]

    I don't think there's a problem in this situation; he just has to make
    sure that point is before the final (hard) newline before he continues
    editing. 

If the user has to do that, then why does it matter whether this
newline is hard or soft?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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