> Date: Thu, 19 May 2005 21:31:23 +0200
> From: Juanma Barranquero <[EMAIL PROTECTED]>
>
> But I don't think is an error in MSVC. I think it's some mixup between
> "pascal" and "C" style calls (as you know, the former remove their
> arguments, the latter don't). MSVC must be thinking that the exte
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>> Date: Thu, 19 May 2005 21:31:23 +0200
>> From: Juanma Barranquero <[EMAIL PROTECTED]>
>>
>> But I don't think is an error in MSVC. I think it's some mixup between
>> "pascal" and "C" style calls (as you know, the former remove their
>> arguments, the
Lute Kamstra <[EMAIL PROTECTED]> writes:
> Stefan Monnier <[EMAIL PROTECTED]> writes:
>
>>> So, how do you make Font Lock use the function in the variable
>>> syntax-begin-function to move to top level?
>>
>> I don't understand the question. What have you tried?
>
>> From what I understand, font-
> Cc: Juanma Barranquero <[EMAIL PROTECTED]>, emacs-devel@gnu.org
> From: [EMAIL PROTECTED] (Kim F. Storm)
> Date: Fri, 20 May 2005 10:24:55 +0200
>
> Could it be that the following define need to specify "Pascal" somewhere
> for the tiff library?
>
> #define DEF_IMGLIB_FN(func) FARPROC fn_##fun
Kim F. Storm wrote:
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
Can you show the declarations of the TIFF functions as they appear in
the header files visible to MSVC when it compiles Emacs?
Could it be that the following define need to specify "Pascal" somewhere
for the tiff library?
#defi
> The version of TIFF headers I have uses extern "C" if compiling under
> C++, so I doubt the library is using Pascal calling conventions.
> Maybe Juanma's library is different than mine.
Unless I'm wrong, the issue is not how the functions are defined on
the headers, because we don't statically l
Richard Stallman <[EMAIL PROTECTED]> writes:
> Thanks. WOuld someone please install this change?
Done.
Lute.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Hi Jason,
Jason Rumney writes:
> The version of TIFF headers I have uses extern "C" if compiling
> under C++, so I doubt the library is using Pascal calling
> conventions. Maybe Juanma's library is different than mine.
'extern "C"' doesn't mean what you think it means, at least not in
most comp
> Can somebody confirm that this change is correct?
Confirmed,
Stefan
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Does anyone see any problems with the patch below? font-lock-defaults
is defined in lisp/font-core.el which is loaded by lisp/loadup.el
before any major modes are loaded. I checked that the patch
introduces no compiler warnings.
Lute.
Index: lisp/subr.el
===
Trọn
bộ 13 Đĩa phim về "Chiến Tranh Việt Nam"
Những
hình ảnh không thể lãng quên
Giá
trọn bộ chỉ: 150.000đ Giao
hàng tận nhà bằng chuyển phát nhanh
Đây
là Email quảng cáo qua dịch vụ của EMB. Xin quý khá
> Date: Fri, 20 May 2005 12:42:09 +0200
> From: Juanma Barranquero <[EMAIL PROTECTED]>
>
> Unless I'm wrong, the issue is not how the functions are defined on
> the headers, because we don't statically link against the functions,
> but how are they compiled in the library and how do we define the
Eli Zaretskii wrote:
That seems to be the problem. What I still don't get is how come the
same declaration that uses FARPROC works for the MinGW build? Can you
figure this out?
Without looking at the disassembly, I'd guess that MinGW gcc and
non-optimised MSVC builds restore the stack pointer
> Date: Fri, 20 May 2005 16:46:38 +0100
> From: Jason Rumney <[EMAIL PROTECTED]>
> CC: Juanma Barranquero <[EMAIL PROTECTED]>, emacs-devel@gnu.org
>
> Without looking at the disassembly, I'd guess that MinGW gcc and
> non-optimised MSVC builds restore the stack pointer from a known
> location r
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I spotted some apparently broken info cross referencs in mh-e
> defgroups,
The manual update is going slower than the programming work, but I
plan to finish it in the next month or two.
--
Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ Gnu
> Does anyone see any problems with the patch below? font-lock-defaults
> is defined in lisp/font-core.el which is loaded by lisp/loadup.el
> before any major modes are loaded. I checked that the patch
> introduces no compiler warnings.
Now that font-core is preloaded, the thing can indeed be re
> Without looking at the disassembly, I'd guess that MinGW gcc and
> non-optimised MSVC builds restore the stack pointer from a known
> location regardless of the calling convention, which should always work.
Optimized MSVC builds also restore the stack and frame pointers. But
before that it tries
> It's the issue with both: the prototypes in the header files should be
> consistent with how the functions were compiled, since those
> prototypes are the only way for the compiler to know how the functions
> were compiled. If it doesn't know that, it might produce wrong code.
Yes, in general,
> That could be it, but I'd prefer that someone
> looks at the code produced by MinGW and see that it indeed doesn't
> restore the stack pointer, either.
I've not had much luck trying to build with MinGW, so I won't be able
to test it. Jason, could you perhaps try it?
--
/L/e
Hi,
in PCL-CVS, the important command `cvs-mode-mark' (bound to `m')
doesn't have a menu entry. Is this intended? Else I'd like to add
it:
2005-05-20 Reiner Steib <[EMAIL PROTECTED]>
* pcvs-defs.el (cvs-menu): Add cvs-mode-mark.
--8<---cut here---start---
With the single change from
#define DEF_IMGLIB_FN(func) FARPROC fn_##func
to
#define DEF_IMGLIB_FN(func) int (FAR CDECL *fn_##func)()
all test images I have do work beautifully.
MORE IMPORTANT: two horrible hacks that I added about a year ago (when
I first fought this same issue and came to
On Sat, Apr 16 2005, Stefan Monnier wrote:
> How about the patch below?
There has been no objection (withing several weeks), AFAICS. I like
Stefan's suggestion.
[...]
> [EMAIL PROTECTED]
> +Adjusting the configuration to various contexts.
> +
> +In most of the cases, people want their Emacs to
Reiner Steib <[EMAIL PROTECTED]> writes:
> in PCL-CVS, the important command `cvs-mode-mark' (bound to `m')
> doesn't have a menu entry. Is this intended? Else I'd like to add
> it:
>
> 2005-05-20 Reiner Steib <[EMAIL PROTECTED]>
>
> * pcvs-defs.el (cvs-menu): Add cvs-mode-mark.
>
> --8<
On Fri, May 20 2005, David Kastrup wrote:
> Reiner Steib <[EMAIL PROTECTED]> writes:
>> in PCL-CVS, the important command `cvs-mode-mark' (bound to `m')
>> doesn't have a menu entry. Is this intended? Else I'd like to add
>> it:
[...]
>> +["Mark current" cvs-mode-mark t]
[...]
> Th
Thien-Thi Nguyen <[EMAIL PROTECTED]> wrote:
> Richard Stallman <[EMAIL PROTECTED]> writes:
>
> > The goal now is to *find* possible bugs.
> > The patch should set the property to something unusual (maybe
> > `never-set') by default. When such an overlay becomes empty, there
> > should be some so
> --8<---cut here---start->8---
> --- pcvs-defs.el 17 Dec 2004 16:17:35 +0100 1.30
> +++ pcvs-defs.el 20 May 2005 20:49:45 +0200
> @@ -421,6 +421,8 @@
> ["Ignore"cvs-mode-ignore (cvs-enabledp
> 'ignore)]
Stefan Monnier <[EMAIL PROTECTED]> writes:
>> --8<---cut here---start->8---
>> --- pcvs-defs.el 17 Dec 2004 16:17:35 +0100 1.30
>> +++ pcvs-defs.el 20 May 2005 20:49:45 +0200
>> @@ -421,6 +421,8 @@
>> ["Ignore" cvs-m
> Do you find _this_ menu completely unusable, or menus in general? If
> the former, then maybe it can be improved.
This menu in particular.
But I have no idea how to improve it, so AFAIC no change can make
it worse: feel free to change it.
Stefan
_
I did a checkout and bootstrap of CVS yesterday both at work and home. Both
versions are leaving the following in my *Messages* buffer, repeatedly
Error during redisplay: (search-failed \([\][\]\)\([(|)]\)\(\?:\)?) [62 times]
The pattern looks like it is highlighting subsets of regexps. I hav
Introduce font-lock-comment-keywords which would basically work like
font-lock-keywords, except it's applied only to comments (with the buffer
narrowed to just the comment so that comment-start-skip matches correctly,
without needing font-lock-comment-start-skip). This way we could
$B!!(.(!(,(!(,(!(,(!(,(!(,(!(/(B
$B!!"!!~"!!~("!!6[5^!*5^!*5^!*Jg=8!!("!~"!!~"!(B
$B!!(1(!(,(!(,(!(,(!(,(!(,(!(0(B
$B!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&!&(B
$B!!Ev%0%k!<[EMAIL PROTECTED]@Z$N$*R2pCW$7
Richard Stallman wrote:
Does this fix it?
Yes, it does.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
How about removing these from bytecomp.el? Unlike the previous variables,
AFAICS these don't seem to be defined in the first place.
Nick
(make-obsolete-variable 'auto-fill-hook 'auto-fill-function "before 19.15")
(make-obsolete-variable 'blink-paren-hook 'blink-paren-function "before 19.15")
(m
Don't Visit the Doc, Visit Us
http://www.uidm.com/p/coupon/dainsr
Leave our lists uidm.comv.php
Let not poor Nelly starve.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
> You mustn't presume such a thing.
Eh, don't shoot the messenger. I *didn't* remove unfocus-frame, I was
just talking about what I suppose was the frame of mind of the person
who did it :)
Sorry, it sounded like you were saying why you removed it,
so I thought you had done it. (
But then, what about dot, dot-marker, dot-min, dot-max,
buffer-flush-undo, compiled-function-p and focus-frame, which were
deleted on the same commit? Do I restore them too?
Please restore focus-frame.
The rest were already marked obsolete in Emacs 21, so they can
now be deleted.
_
Buffer Menu, which I described earlier, is caused by a change made
today, namely making Buffer-menu-buffer-face the value of the
font-lock-face property rather than the face property. Reverting that
change makes the problem completely go away. But I presume that there
must hav
- Use "\(fn ARG1 ARG2...)" now (so 22.1 at least has good cl docstrings)
- Use the best method available, once we branch 22.1
That represents doing twice the fixing, but I don't mind, and it'll
get us the best results (assuming I don't screw up the docstrings :)
I would not have
I suggest to set up a policy for the NEWS file that the first line
contains of a full sentence (which must not be too long) or sectioning
title.
That is how it should be, ideally, and I rewrote many entries this week
to do that. However, to insist that absolutely all of them follow th
39 matches
Mail list logo
