Richard Stallman wrote:
It would be cleaner to do the same thing for :set and :type--to suppress
the default one when there is an explicit one.
Done.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman
>From my previous message:
So, to do what the comment says, we should replace the default
:initialize for minor modes from 'custom-initialize-default to
'custom-initialize-set.
Well actually, one might need to replace `custom-initialize-default'
with a new :initialize function, custom-in
Here is the code:
;; If the mode is global, call the function according to the default.
,(if globalp
`(if (and load-file-name (not (equal ,init-value ,mode)))
(eval-after-load load-file-name '(,mode (if ,mode 1 -1
I believe that this code definitely s
The following patch for lisp/smtpmail.el implements the PLAIN smtp
authentication method.
--- ChangeLog 6 Jul 2005 12:07:32 - 1.426
+++ ChangeLog 16 Jul 2005 01:06:58 -
@@ -1,3 +1,9 @@
+2005-07-16 Jose E. Marchesi <[EMAIL PROTECTED]>
+
+ * lisp/mail/smtpmail.el (smtpma
Jason Rumney <[EMAIL PROTECTED]> writes:
> Shouldn't all responses that do not start with a status code be ignored?
>
> ie
>
> "^[^1-9][^0-9][^0-9]"
Be careful when negating regexps, as this is seldom as easy as it
seems. An actual negation of "^[1-9][1-9][1-9]" would be:
"^\\([^1-9]\\|[1-9][^1-
Lennart Borgman <[EMAIL PROTECTED]> writes:
> A more important reason is that programs on w32 communicate
> differently than on GNU/Linux.
Ghostscript is a port of a Unix program, it communicates the
traditional way through stdio, like any other command-line program.
___
David Kastrup wrote:
Ghostscript is not installed that way on w32. It is not supposed to
be find in the PATH. That is because the w32 "architecture" is
different. You can only find Ghostscript through the registry (or
searching the whole disk ;-)
Does not sound too intelligent.
I belie
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Ghostscript is not installed that way on w32. It is not supposed to be
> find in the PATH.
Why? It seems very inconvenient to require programs to find other
programs by searching for them manually in a "registry", rather than
using the PATH features t
Jason Rumney wrote:
Ghostscript is not installed that way on w32. It is not supposed to be
find in the PATH.
Why? It seems very inconvenient to require programs to find other
programs by searching for them manually in a "registry", rather than
using the PATH features that are built into t
>>There is no conspiracy here. The number of developers reflects the
>>number of volunteers.
Perhaps developers, if they have the opportunity, prefer freedom:
freedom to develop regardless of what it is, even an operating system.
Obviously, people choose order and law before they choose j
Can you prevent users and Custom from doing it? If not, the "should not"
consideration is fairly meaningless.
No code can prevent users from making mistakes. No code can reliably
correct user mistakes and I do not believe that one should try to do
that. Just alert the user that there may
Lennart Borgman <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>
>>I don't see that Emacs has an interface into the locale in general
>>which would be required for reading the papersize setting. And the
>>usual way for GhostScript is just to look for "gs" in the exec path.
>>Since the process
Hi
If you eval the following:
(defun drkm:test ()
(interactive)
(with-temp-buffer
(insert-file-contents "/tmp/an-existing-file" t)
(insert "To modify the buffer...")
(error "Some error")))
and then 'M-x drkm:test ', you'll be prompt for saving or
not t
David Kastrup wrote:
I don't see that Emacs has an interface into the locale in general
which would be required for reading the papersize setting. And the
usual way for GhostScript is just to look for "gs" in the exec path.
Since the process shell does that already, "gs" is usually used as the
> Aren't user-defined constants useful in other languages?
the only user-defined constant is ignorance.
(with programmers, this is a variable concept. :-)
This should go in the Emacs humor file.
___
Emacs-devel mailing list
Emacs-devel@gnu
However, the question is: should I expect for a 22.0.X .elc file to
work on 21.4? I would've assumed "not", but for this comment on
`define-derived-mode':
If it is easy to make this work (or work more), we can do it,
but I'd rather not do a lot of work for that sake.
I think that such
Short term, I think a few more functions should be added to
`byte-compile-interactive-only-functions', according to
recommendations on their own docstrings:
1) `insert-buffer', `insert-file-literally'
I'd say ok to those. I think the others are too specialized
to be worth the at
Jason Rumney wrote:
Lennart Borgman <[EMAIL PROTECTED]> writes:
An implementation for accessing Registry on w32 was offered some
years ago, but was not accepted.
I don't recall this. If it was anything like most such offers, someone
submitted some code, the Emacs developers suggested
Stefan Monnier wrote:
>Miles complained loudly (in the form of comments, some of which
>may still be in the current elisp code ;-)
> These comments make no sense.
If you do not understand them, I fear you may not understand the problem
well enough to judge what's the least
Lennart Borgman <[EMAIL PROTECTED]> writes:
> I see no reason why Emacs should be able to edit the w32 Registry,
> but reading it would be very convenient. It should not be seen as
> giving Emacs extra features on w32. Rather it is another way to
> accomplish the same thing that are already easily
Lennart Borgman <[EMAIL PROTECTED]> writes:
> An implementation for accessing Registry on w32 was offered some
> years ago, but was not accepted.
I don't recall this. If it was anything like most such offers, someone
submitted some code, the Emacs developers suggested some improvements,
and we ne
> * Stefan Monnier <[EMAIL PROTECTED]> [2005-07-15 16:49:56 -0400]:
>
>> I have 3 files:
>> config.h.in
>> config.h.in~
>> configure.in
>
>> C-x C-f c o n TAB
>
>> ==> completed to "config", cursor right after "g" (correct)
>
>> then
>> . TAB
>
>> *Completions* buffer pops up with the 3 files above
I'm far from sure it'll fix the bug and if it doesn't, I'd rather not
install it, so please have someone try it before I install it,
I agree, but I don't have a way to check it myself.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http
>AFAIK, the motivation was also for some other cases where the user may
>somehow setq the variable before loading the file. IIRC this setq may
>actually be done by Custom (at a time where it doesn't yet know that
>the var have a :setter).
> The user should not set a minor mode var
> I have 3 files:
> config.h.in
> config.h.in~
> configure.in
> C-x C-f c o n TAB
> ==> completed to "config", cursor right after "g" (correct)
> then
> . TAB
> *Completions* buffer pops up with the 3 files above,
> and cursor is now between "g" and "."
Is this in `emacs -q --no-site-file' ?
T
> I can't build from C sources and test this myself, but I'll take your word
> for it that it's fixed. If someone else happens to do a Windows build,
> perhaps s?he could confirm. Thanks.
I'm far from sure it'll fix the bug and if it doesn't, I'd rather not
install it, so please have someone try
> In CUA, I have this:
> (define-minor-mode cua-mode
> "..."
> :global t
> ...)
> Now, assume I have a buffer `xyz' which definitely don't want
> cua-mode enabled.
> If I do things in the following sequence, it works alright:
> M-x cua-mode RET
> C-x b xyz RET
> M-: (set (make-local-vari
> The solution is that somebody write a working emacsclient/server.
> Obviously, this someone is to be looked for among people actually
> using Windows.
Actually, I don't think so. IIRC What we need for emacsclient/server to
work on Windows is to make it work over TCP sockets rather than only ove
> * Richard M. Stallman <[EMAIL PROTECTED]> [2005-07-15 14:11:20 -0400]:
>
> the current cvs head appears to have a problem with completion.
> when I have a file (or buffer) named foo.bar and I type "foo." and hit
> TAB, the cursor moves 1 step to the left (i.e., between "o" and ".")
>
Lennart Borgman <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>
>>>I personally find it quite disturbing that the policies do not allow
>>>for fetching for example paper size from within Emacs.
>>>
>>>
>>Nonsense. If they are implemented as a general feature that would,
>>for example, co
Lennart Staflin wrote:
On 14 jul 2005, at 21:43, Stuart D. Herring wrote:
>
> (defun special-form-p (object)
> "Return t if OBJECT is a special form."
> (and (subrp object) (eq (cdr (subr-arity object)) 'unevalled)))
>
I know that Emacs Lisp isn't Common Lisp, but isn't
David Kastrup wrote:
I am not suggesting any such thing. I know nothing whatsoever about
w32 and I consider life too short to change anything about that.
Sorry, I thought you did.
I have no idea what you are complaining about actually with regard to
the paper size. It appears that you ar
Well that someone was me.
The short version is that I completely dropped the ball on this and
after volunteering to look at porting emacsclient to Windows never had
the time to actually do it. I updated gnuclient at the time and then
ran out of time when looking at all of the changes in the new e
Juanma Barranquero wrote:
On 7/15/05, Jason Rumney <[EMAIL PROTECTED]> wrote:
There is no conspiracy here. The number of developers reflects the
number of volunteers.
I absolutely agree with David and you on this issue.
No problems. I do too. I am talking about consequences, not
Is it OK to obsolete these?
Ok.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
More precisely, without my changes, if you specify an explicit
:initialize keyword, the expansion of the define-minor-mode form
contains two :initialize keywords, first
":initialize 'custom-initialize-default" and then, at some later place
the explicit :initialize.
That's not c
So removing it may prevent running .elc files compiled with Emacs-20.
I'd expect that several people have .elc files compiled with Emacs-20 for
the purpose of making them work with both Emacs-20 and Emacs-21, so unless
you have a good reason to get rid of that function (and the vari
the current cvs head appears to have a problem with completion.
when I have a file (or buffer) named foo.bar and I type "foo." and hit
TAB, the cursor moves 1 step to the left (i.e., between "o" and ".")
instead of completing to "foo.bar".
this happens with "-" instead of "." to
Aren't user-defined constants useful in other languages? Isn't it
useful per se to be able to set a symbol and guarantee that the user,
or another module, is not going to change it by accident?
I don't see a need for this.
Certainly
Common Lisp is not above having constants
> Date: Fri, 15 Jul 2005 14:40:09 +0200
> From: Lennart Borgman <[EMAIL PROTECTED]>
> Cc: Emacs Devel
>
> The first thing is to hope for someone who can and want to do this. If
> this fail I think we at least should tell the truth about the state of
> Emacs in this respect. Maybe that could be
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Jason Rumney wrote:
>
>>
>>> I have suggested that there might be too few developers on the w32
>>> side. In that sense it may actually be part of a strategy.
>>
>>
>>
>> There is no conspiracy here. The number of developers reflects the
>> number of v
Lennart Borgman <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>
>>Well, obviously port emacsclient. Somebody already took a look of it
>>IIRC, but nothing has been heard of it since.
>>
>>And with any other stuff: if nobody does the work, it will not be
>>done. As far as I remember, this is
Lennart Borgman wrote:
> Jason Rumney wrote:
>
>>
>>> I have suggested that there might be too few developers on the w32
>>> side. In that sense it may actually be part of a strategy.
>>
>>
>>
>> There is no conspiracy here. The number of developers reflects the
>> number of volunteers.
>
> I
On 14 jul 2005, at 21:43, Stuart D. Herring wrote:
(defun special-form-p (object)
"Return t if OBJECT is a special form."
(and (subrp object) (eq (cdr (subr-arity object)) 'unevalled)))
I know that Emacs Lisp isn't Common Lisp, but isn't special-operator-p
a better name?
//Lennart S
Jason Rumney wrote:
I have suggested that there might be too few developers on the w32
side. In that sense it may actually be part of a strategy.
There is no conspiracy here. The number of developers reflects the
number of volunteers.
I am not at all talking about conspiracy. I am tryi
David Kastrup wrote:
Lennart Borgman <[EMAIL PROTECTED]> writes:
Yes, nobody has done it yet and I believe there is no one working on
it actively at the moment. I raised the issue to see if someone could
do it.
I have suggested that there might be too few developers on the w32
side. In that
David Kastrup wrote:
The way to handle this is to create a working implementation of
emacsclient. Feel free to go ahead.
Sorry, I do not know network programming enough. Someone who could
implement this must know this on both the unix style and winsock.
The first thing is to hope for som
David Kastrup wrote:
I personally find it quite disturbing that the policies do not allow
for fetching for example paper size from within Emacs.
Nonsense. If they are implemented as a general feature that would,
for example, consult LC_PAPER on Posix-compliant systems, there is
nothing s
Short term, I think a few more functions should be added to
`byte-compile-interactive-only-functions', according to
recommendations on their own docstrings:
1) `insert-buffer', `insert-file-literally'
2) `add-mode-abbrev', `add-global-abbrev', `bookmark-write', `org-diary'
3) from mail/mailabb
On 7/15/05, Jason Rumney <[EMAIL PROTECTED]> wrote:
> There is no conspiracy here. The number of developers reflects the
> number of volunteers.
I absolutely agree with David and you on this issue.
OTOH, as in any volunteer development effort, people often feels a bit
left out. Warnock applies m
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> On 7/15/05, Jason Rumney <[EMAIL PROTECTED]> wrote:
>
>> There is no conspiracy here. The number of developers reflects the
>> number of volunteers.
>
> I absolutely agree with David and you on this issue.
>
> OTOH, as in any volunteer development e
Lennart Borgman <[EMAIL PROTECTED]> writes:
> David Kastrup wrote:
>
>>Lennart Borgman <[EMAIL PROTECTED]> writes:
>>
>>
>>>Yes, nobody has done it yet and I believe there is no one working on
>>>it actively at the moment. I raised the issue to see if someone could
>>>do it.
>>>
>>>I have sugges
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Jason Rumney wrote:
>
>> Lennart Borgman wrote:
>>
>>> I just want to tell that w32 still have no working
>>> emacsclient/server. Gnuserver/client is a workaround, but as far as
>>> I understand this can currently not be part of Emacs because of
>>> li
I have suggested that there might be too few developers on the w32
side. In that sense it may actually be part of a strategy.
There is no conspiracy here. The number of developers reflects the
number of volunteers.
___
Emacs-devel mailing list
Quickly, I will lend on any and all Real Estate. Make me an offer. Any loan
amount. Any Credit Situation. Any Type of property. Quick, Hassle free closings
All offers will be considered most will be approved.
Call me directly with all offers
Nigel Allen
Toll Free# 1-866-308-1598
[EMAIL PROTECTE
Stefan Monnier wrote:
AFAIK, the motivation was also for some other cases where the user may
somehow setq the variable before loading the file. IIRC this setq may
actually be done by Custom (at a time where it doesn't yet know that the var
have a :setter).
The user should not set a m
> emacs -q
> M-x set-variable pop-up-frames t
> M-x complet TAB
> This opens a new frame for buffer *Completions*. At least in
Windows, the
> new frame is selected. The frame focus for typing key sequences thus
> switches to the *Completions* frame, but the minibuffer o
Jason Rumney wrote:
Lennart Borgman wrote:
I just want to tell that w32 still have no working
emacsclient/server. Gnuserver/client is a workaround, but as far as I
understand this can currently not be part of Emacs because of license
problems.
This sums up (in my opinion) that we can not d
David Kastrup wrote:
Well, obviously port emacsclient. Somebody already took a look of it
IIRC, but nothing has been heard of it since.
And with any other stuff: if nobody does the work, it will not be
done. As far as I remember, this is a "simple" nobody-did-it-yet
case. It is not part of a
Lennart Borgman <[EMAIL PROTECTED]> writes:
> I just want to tell that w32 still have no working
> emacsclient/server. Gnuserver/client is a workaround, but as far as
> I understand this can currently not be part of Emacs because of
> license problems.
>
> This sums up (in my opinion) that we can
David Abrahams <[EMAIL PROTECTED]> writes:
> I am trying to get a clue as to how this stuff is organized so that I
> can fix the problems described below. Thanks for your attention.
>
These's a general overview at the top of src/xdisp.c .
Also look at the data structures in dispextern.h.
And t
On 7/15/05, Juanma Barranquero <[EMAIL PROTECTED]> wrote:
> I have a little major mode
> derived from emacs-lisp-mode via `define-derived-mode'. When I compile
> it with 21.4 I can use it on 21.4 and 22.0.X; however, when I compile
> it with 22.0.X it fails on 21.4 (it does not produce an error, b
Juanma Barranquero <[EMAIL PROTECTED]> writes:
> Aren't user-defined constants useful in other languages?
the only user-defined constant is ignorance.
(with programmers, this is a variable concept. :-)
thi
___
Emacs-devel mailing list
Emacs-devel@gnu
JD Smith <[EMAIL PROTECTED]> writes:
> I'm still getting SEGFAULTS in the most recent CVS build, relating to
> increment_row_positions. I had previously reported this was fixed in
> 22.0.50, but had not tested adequately. It is an intermittent
> SEGFAULT, usually triggered by a key comand that c
Lennart Borgman wrote:
I just want to tell that w32 still have no working emacsclient/server.
Gnuserver/client is a workaround, but as far as I understand this can
currently not be part of Emacs because of license problems.
This sums up (in my opinion) that we can not distribute a fully
work
On 7/15/05, Stefan Monnier <[EMAIL PROTECTED]> wrote:
> So removing it may prevent running .elc files compiled with Emacs-20.
> I'd expect that several people have .elc files compiled with Emacs-20 for
> the purpose of making them work with both Emacs-20 and Emacs-21, so unless
> you have a good r
In CUA, I have this:
(define-minor-mode cua-mode
"..."
:global t
...)
Now, assume I have a buffer `xyz' which definitely don't want
cua-mode enabled.
If I do things in the following sequence, it works alright:
M-x cua-mode RET
C-x b xyz RET
M-: (set (make-local-variable 'cua-mode) nil)
> a good reason to get rid of that function (and the various other
> similar ones in derived.el)
While reinstalling the function, I've now seen this comment that I
somehow missed yesterday:
;;; OBSOLETE
;; The functions below are only provided for backward compatibility with
;; code byte-compiled
> So maybe Fdisplay_buffer should protect against it with something like the
> patch below. Does it help?
Sorry about the botched patch. Try this one instead,
Stefan
--- window.c13 jui 2005 13:58:39 -0400 1.512
+++ window.c15 jui 2005 03:30:07 -0400
@@ -3475,7 +347
I just want to tell that w32 still have no working emacsclient/server.
Gnuserver/client is a workaround, but as far as I understand this can
currently not be part of Emacs because of license problems.
This sums up (in my opinion) that we can not distribute a fully working
Emacs on w32. What sh
70 matches
Mail list logo
