Re: Where do you want to go tomorrow?
27 years
Michael Sperber
Michael Sperber
>>>>> "Olivier" == Olivier Galibert <galibert(a)pobox.com> writes:
Olivier> Just to put some gasoline on the fire, what about and ILU-like
Olivier> approach to extension language independence ?
Olivier> ftp://ftp.parc.xerox.com/pub/ilu/ilu.html
Olivier> We could have Common lisp, Java, Scheme and Perl simultaneously ;-)
A future Emacs Lisp engine is hopefully going to have some sort of
interface via RPC, preferrably CORBA. ILU does this, indeed.
However, CORBA and related IDL's are pretty heavyweight currently.
The sensible approach is to a have a low-level FFI and build RPC
support on top of it.
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 2 participants
- 1 comments
Re: Where do you want to go tomorrow?
27 years
Michael Sperber
Michael Sperber
>>>>> "Andy" == Andy Piper <andyp(a)parallax.co.uk> writes:
Andy> My $0.02 based on almost zero understanding ;)
Andy> I am assuming that Michael is talking about replacing the underlying
Andy> execution engine so that we would benefit from basically increased
Andy> performance with the existing elisp remaining largely unchanged?
The emphasis is slightly different: I want to keep full Elisp support,
while introducing an additional substrate meant to slowly replace
Elisp. Preferrably, Elisp will simply run inside the substrate.
Andy> My impression is that a scheme engine would be smaller and
Andy> faster than a clisp engine.
Smaller, definitely. Faster is a matter of implementation technology,
and pretty independent of that choice. CLISP as well as most existing
Scheme engines are plenty fast for our purposes. There are
native-code implementations for Scheme and CLISP which are plenty
faster.
Andy> Whatever the case I think the replacement should be as small and as fast as
Andy> possible rather than as feature rich as possible.
:-)
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
27 years
Michael Sperber
Michael Sperber
>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
Hrvoje> Common Lisp is much closer to elisp than any Scheme dialect
Hrvoje> is.
You've said that on a number of occasions, but I don't even know what
you mean. Actually, I claim this is false.
Hrvoje> Using Scheme as a primary language in XEmacs will alienate a
Hrvoje> large number of our contributors, and I, for one, do not want
Hrvoje> to see that happen.
If that is indeed so, I'm more than willing to give in. However, we
don't have any evidence for this statement yet. That's why I said we
need more discussion. It would generally be nice if people actually
took a look at both languages (or any other candidates) and posted
about their impressions and conclusions.
I personally believe a small substrate is less likely to alienate
people than a large substrate. (Hey, we're replacing Elisp by
something really cool! Hack great things with it! Contribute code!
The language reference is only slightly more than 500 pages ...)
Hrvoje> Translators or compatibility packages for elisp implemented in Scheme
Hrvoje> would of little help, except for porting old code.
You consider porting old code (several hundred thousands of lines) "of
little help"?
Hrvoje> I doubt anyone will consider using them to write new,
Hrvoje> XEmacs-specific code.
Of course not, that's why we want a substrate change in the first
place. What's your point?
Hrvoje> My second argument is that XEmacs has been going in the direction of
Hrvoje> Common Lisp for several years now. Extensions such as cl.el show that
Hrvoje> pretty clearly.
I honestly want to understand what you mean by this, but I don't.
Sure, it has made sense to write Elisp libraries with constructs
modelled like equivalent constructs in Common Lisp. It makes sense to
write Scheme libraries with those constructs as well. It would make
sense to write Common Lisp libraries to emulate Scheme constructs.
(Or ... libraries to emulate ... constructs, or ...)
However, the *language* has not changed through the evolution of
libraries. What we've been doing with Emacs Lisp is easily possible
with Scheme, or any of a number of other languages.
Sure, some people will prefer different programming idioms when they
have the full power of Scheme available. But they don't have to. I
use Scheme programming idioms when writing Elisp, for that matter.
Look at my code. If you want to use Common Lisp idioms when using
Scheme, that's absolutely fine. In fact, you can make Scheme look
almost completely like Common Lisp, if you want to. (Note that the
reverse is not generally possible, since Common Lisp is not properly
tail-recursive and does not support control abstraction.)
Hrvoje> If we want to extend elisp further, I think we should take a
Hrvoje> radical step in the same direction, rather than turn into a
Hrvoje> wholly different one.
I don't think we want to extend Elisp further, we want to replace it
by something new. The differences between Elisp and Common Lisp are
at least as great as those between Elisp and Scheme. Replacing Elisp
by Common Lisp is simply not a "radical step in the same direction,"
it's a great leap into a new one.
I claim that moving to Scheme would be moving into essentially the
same direction as Common Lisp, it's only the pragmatics and trade-offs
which are different, mainly dictated by the state of the art in
implementation technology.
Hrvoje> Suppose the impossible happens, and Erik does come in and does all the
Hrvoje> work to port XEmacs Lisp to, say, clisp. Would you quit XEmacs
Hrvoje> development?
Yes.
Hrvoje> If yes, why?
Arguing with Erik aggravates me. This is independent of the technical
merit of the content of his postings (which I generally also find
pretty low), it's just my gut-level reaction to what he writes.
Hrvoje> Now replace Erik with Bruno or Hrvoje. Do the answers change?
Absolutely.
Hrvoje> I think that you are arguing for Scheme because of personal
Hrvoje> preferences, which is perfectly natural. Your battle plan includes
Hrvoje> only Scheme-based options, and I think that no words of mine would
Hrvoje> ever convince you to consider anything else.
There must be a misunderstanding here, Hrvoje. My "battle plan" (I
assume you're referring to my Web page on the subject matter)
*specifically* includes other options. Up until the last possible
moment, it is totally independent of the language or
language substrate we'll drop in. If we do our jobs well, we can have
several extension languages to drive XEmacs.
Moreover, I've reserved Web space for arguments on Common Lisp, but
nobody has sent me anything yet to put there. I'm willing to hear
arguments, I've tried out implementations that you've suggested to me
and commented on them (and not just negatively, for that matter).
What more do you want from me to prove I'm open to arguments?
Hrvoje> This is why I think our disagreements can be only settled by a
Hrvoje> split, or by one of us leaving the development.
I don't get it Hrvoje, we've hardly started discussion on this, and
already you claim an irreconcileable split. Why?
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 2 participants
- 1 comments
Re: Where do you want to go tomorrow?
27 years
Michael Sperber
Michael Sperber
>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes:
Stephen> Been there. The only thing I understood in that page was that Scheme
Stephen> is small, elegant, extensible and thus a good candidate for a
Stephen> substrate. Agreed. The rest was so much noise, except for the "now
Stephen> you've got two big problems" comment about CL, which I would tend to
Stephen> agree with but as you point out yourself, and Hrvoje agrees, XE-CL
Stephen> would be a scaled-down version.
Agreed. The page is just an old xemacs-beta posting taken out of
context. I'll try to update it as I have time.
ms> Many features aren't part of the Scheme standard because they
ms> can be easily expressed within the language as it stands. True
ms> concepts are more important, and here CL is weak. I could go
ms> on about the virtues of hygienic macros, the evils of CL-style
ms> macros, especially in connection with module systems, the
ms> usefulness and beauty of call-with-current-continuation
ms> etc. etc. etc. Someone make me.
Stephen> OK. *twist, twist, twist*
Stephen> However, URLs where I can find out WTF the vocabulary means ahead of
Stephen> time would be vewy hehpfuh.[1] I've been to Indiana's Scheme
Stephen> Repository; I don't know where to start.
Hygienic macros:
ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/misc/macros-0[1-4].txt.gz
ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/prop/macinsch.ps.gz
The latter also contains some brief comparisons to Common Lisp.
It's difficult to find electronic versions of good explanations and
examples for CALL-WITH-CURRENT-CONTINUATION.
The basic idea is that every expression in a Scheme program has a
context to which its return value is fed once it's been computed.
This amounts to the "future" of that expression, and the underlying
implementation usually implements it as a stack of activation records.
Most programming languages support capturing the context via some
catch/throw or exception handling or setjmp/longjmp mechanism which
allows you to restore a context which is part of the current context,
i.e., to unwind part of the stack. This means that they work only
"upwards" on the stack. However, to implement sophisticated control
structures, you need to be able to:
1. Restore the context even if it's not lying around on the stack.
2. Restore it multiple times.
The most popular example are threads. From a C programmer's
viewpoint, all threads share the same global memory, but each has its
own stack aka context.
CALL-WITH-CURRENT-CONTINUATION simply converts its own context (the
"current continuation") into a one-argument procedure. When you call
that procedure, the current context is replaced by that of the call to
CALL-WITH-CURRENT-CONTINUATION.
In connection with one global reference (which Scheme gives you
easily), you can model *any* control structure (in a certain formal
sense). CL's mechanism is not strong enough for this.
(Another good example is the Icon language which uses a control
structure called "generator" as the backbone of a very powerful model
for text processing---much more powerful than Emacs Lisp. Generators
are a slightly generalized version of coroutines, and trivial to
implement in Scheme.)
Good explanations of continuations are in:
＠BOOK{FriedmanWandHaynes1992,
author = "Daniel P. Friedman and Mitchell Wand and Christopher
T. Haynes",
title = "Essentials of Programming Languages",
publisher = "MIT Press and McGraw-Hill",
year = 1992,
annote = "EOPL",
ISBN = {MIT 0-262-06145-7, McGraw-Hill 0-07-022443-9}
}
＠BOOK{SpringerFriedman1989,
author = {George Springer
and Daniel P. Friedman},
title = {Scheme and the Art of Programming},
year = 1989,
publisher = {MIT Press and McGraw-Hill},
keywords = {scheme-art}
}
＠Book{Queinnec1994,
author = {Christian Queinnec},
title = {Lisp in Small Pieces},
publisher = {Cambridge University Press},
year = 1994
}
Stephen> Re: global options and keyword arguments
ms> However, Scheme idiomatics usually uses a parameterization
ms> mechanism to achieve what you're talking about; they're
ms> similar to a structured and thread-compatible version of
ms> dynamic binding.
Stephen> Urk. I mean, URL please. :-)
http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node99.htm
Stephen> I'm not sure I agree with you, if I do get the general direction of
Stephen> your thought. I'm talking about situations where we are currently
Stephen> stuck choosing between
Stephen> ;; isn't it a shame that the FSF is now doing
Stephen> ;; (defun foo (arg &optional face) ...)?
Stephen> (defun foo (arg &optional coding-sys) ...)
Stephen> (foo "insert me in" 'euc-jp)
Stephen> and
Stephen> (defun foo (arg) ...)
Stephen> ;; boy this is ugly compared to
Stephen> ;; (foo "insert me in" :coding-sys 'euc-jp)
Stephen> (let ((coding-system-for-insertion 'euc-jp))
Stephen> (foo "insert me in"))
Stephen> What does that look like in Scheme idiom, if your idea does apply?
All three are possible. The advantage to the latter (the "ugly" one)
is that the same parameterization can apply to a whole dynamic context
rather than just a single procedure call.
ms> The term [proper tail recursion] doesn't exist as a noun. As
ms> I said above, a Scheme implementation is properly
ms> tail-recursive if it implements tail calls as gotos.
Stephen> No, you didn't say it. At least, not in words _I_ could understand.
Scheme takes the stance that recursion is sufficient to express, well,
recursion, as well as the common iterative control structures, such as
loops. However, the main difference between recursion and iteration
in most other languages is that a procedure call (specifically a
recursive procedure call) consumes space, on the stack or elsewhere,
to store its context. This means that, each iteration of a loop
consumes space, and may therefore lead to stack overflow or something
similar.
However, when you formulate loops via recursion, the context does not
change between successive iterations, because the recursive calls are
"tail calls"---they have no context. Scheme guarantees that such
calls will not consume space, and it's therefore safe to write loops
this way. The tail calls compile to goto + parameter passing. Tail
calls are important in other contexts, because not having them can
lead to space leaks.
Now, a lot code obviosuly depends on Scheme implementations having
this property because loops are so common. It's not possible to
support the general property of being properly tail-recursive after
the fact, unless you want to rewrite your whole program in terms of
goto.
The Scheme standard, available under:
http://www-swiss.ai.mit.edu/scheme-home.html
elaborates on this.
Stephen> Point is that a lot of the people who should contribute to
Stephen> this discussion don't even know where to start asking
Stephen> questions. I assume I'm not the only person totally ignorant
Stephen> of modern programming language theory on this list. Is that
Stephen> assumption unjustified?
Absolutely not. Let me know if I'm not doing a good job explaining
the issues. Doing programming language research all day clouds my
vision as to what I can assume and what I still need to explain.
More about module systems later ...
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
27 years
Michael Sperber
Michael Sperber
>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
Hrvoje> Lots of elisp code can run under Common Lisp almost
Hrvoje> unchanged. This is not true for Scheme.
>>
>> Please substantiate this. By default, for instance, `let' is
>> lexically scoped in Common Lisp, which is clearly incompatible with
>> Emacs Lisp.
Hrvoje> Not so by design. In fact, we were discussing introduction of a
Hrvoje> lexically scoped `let' to elisp many times. And guess what? The
Hrvoje> proposed semantics were equivalent to those used by CL -- lexical
Hrvoje> scope by default, dynamic scope for special variables.
Great. While I don't remember the proposed semantics, and don't
necessarily agree with this, this is just as easy to implement in
Scheme.
Hrvoje> I don't care. Emacs is not ANSI CL. If that was the
Hrvoje> impression I was giving, I apologize, because that is not what
Hrvoje> I meant.
One important benefit in swapping the extension language would be that
we could use library code not specifically written for XEmacs.
There's lots and lots of library code for both Scheme and Common Lisp.
Stripping down the language would mean we couldn't use much of it. If
we're going to hook to a Lisp engine maintained by someone else (which
we hopefully will), there's no reason to take only a part of it.
Hrvoje> I will probably not be the one doing the work, and I have not a clear
Hrvoje> idea of what it would take. This, however, should not mean I get no
Hrvoje> vote in the discussion. I know where I want to end up.
Sure. But in the end, we'll need someone who knows what it would
take. I have a pretty good idea, and the effort required is only
marginally different between Scheme and CL.
Hrvoje> The Scheme users and implementors don't have the constraint of
Hrvoje> previous implementation of Common Lisp idioms. We do, and I would
Hrvoje> like us to preserve them.
Sure. Let's.
Hrvoje> I don't believe this. Common Lisp may not be perfect, but it's far
Hrvoje> too complex to simulate correctly without a *lot* of effort.
Most of it's been done. PC Scheme used to come with a substantial
emulation, and we could probably hack it to make it work for us.
Hrvoje> What kind of write-up? Haven't I sent you my discussion with Bruno
Hrvoje> Haible?
Ermh, no, you haven't ... Please do!
Hrvoje> I don't like CMU CL (far too slow and buggy IMHO),
Actually, CMU CL produces pretty much the fastest CL code around.
Unfortuntately, it only works on very few architectures.
Hrvoje> and I haven't worked with GCL much. It might be usable.
Now *that*'s what I would call slow and buggy. (Took me three days
just to get it installed without dumping core.) CLisp is
significantly preferrable.
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
27 years
Michael Sperber
Michael Sperber
>>>>> "Stephen" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes:
Stephen> But (from this third party's point of view) neither of you has really
Stephen> explained what the advantages are to your preferred dialect.
My case for Scheme has been at
http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-gener...
for a while.
It's fairly rudimentary, but I'll be happy to elaborate on anything
anyone wants. The highlights (in a comparison to CL) are:
1. Scheme is a small language, both conceptually and in
implementation. It carries little historical baggage.
2. Many complete implementations of Scheme exist, and several would
make suitable substrates for XEmacs.
Some of the best-performing compilers for higher-order languages
exist for Scheme.
3. Scheme is built in such a way so as to be able to model most other
concepts existing in other programming languages. In particular,
it supports high-level macros, control abstraction, and reflection.
Stephen> One thing that we have banged up against a couple of times
Stephen> recently is the "global option-variable vs. function
Stephen> argument" thing. This is especially annoying in the Mule
Stephen> modules, since the FSF implementation keeps changing and it's
Stephen> useful to keep synch in many cases. It would be nice to have
Stephen> CL-like keyword arguments. Is this doable in a robust way in
Stephen> Scheme? Would it be efficient, especially when compiled?
Sure. In fact, the DSSSL subset of Scheme specifies keyword
arguments, and several Scheme implementations already have them. No
problem there. (Of course, it's equally possible to add them to the
language with a bunch of macros.)
However, Scheme idiomatics usually uses a parameterization mechanism
to achieve what you're talking about; they're similar to a structured
and thread-compatible version of dynamic binding.
Stephen> If Hrvoje is correct that much elisp code can be swallowed raw by a CL
Stephen> implementation, then this should make synching with the FSF much less
Stephen> painful. This is especially dear to Mule people, since the active
Stephen> development of Mule, at least in terms of (natural) language
Stephen> additions, is nearly all taking place at the FSF. You must have some
Stephen> thoughts about that. Or are you assuming that an eventual adoption of
Stephen> Guile by the FSF will make an XE-scheme a positive advantage in
Stephen> porting FSF code?
I think any Lisp engine swap should be preceded by two things:
1. A full emulation of Emacs Lisp, either within the language
substrate, or via a native compiler, or via simply including the
old Elisp engine, for legacy code support.
2. A source-to-source translator which turns readable Elisp into
halfway-readable substrate code for permanent migration.
The need for both won't go away with either Scheme or CL.
ms> (Note that the reverse is not generally possible, since Common
ms> Lisp is not properly tail-recursive and does not support
ms> control abstraction.)
Stephen> Do we care? Ie, can you give specific examples where those features
Stephen> would be useful to developers, either of the core XEmacs or of
Stephen> application libraries, or enhance efficiency of a running XEmacs?
You're quoting me out of context: I was talking about running Scheme
code inside a Common Lisp substrate.
Scheme code *very* often depends on the underlying implementation
being properly tail recursive. (This essentially means that
tail-recursive call don't consume stack space. The Revised^5 Report
on Scheme contains a rationale.) Therefore, these Scheme programs
won't run properly in a Common Lisp implementation which isn't
properly tail-recursive.
Some Scheme code relies on full-fledged continuation reification,
specifially code which implements co-routines, threads, generators,
exception mechanisms, etc. etc. Common Lisp supports only a very
limited form of control abstraction in the form of catch/throw which
works only in one direction (upwards-only). This makes catch/throw
unsuitable for the applications I enumerated. Scheme's call/cc works
in both directions. Adding efficient call/cc to a language substrate
which wasn't designed with it in mind is usually very difficult,
because it requires either a CPS-converting compiler or a stack
fragmentation mechanism.
Stephen> The answer I need is _not_ "I already told you it's properly
Stephen> tail-recursive, what more do you need to know?" I know what tail
Stephen> recursion is; I don't know what "proper tail recursion" is.
The term doesn't exist as a noun. As I said above, a Scheme
implementation is properly tail-recursive if it implements tail
calls as gotos.
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
- 2 participants
- 1 comments
Re: ANNOUNCE: I am speaking about XEmacs, July 1
27 years
Remek Trzaska
Remek Trzaska
Anybody could see the mbone session tonight?
Remek
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
27 years
Hrvoje Niksic
Hrvoje Niksic
Olivier Galibert <galibert(a)pobox.com> writes:
> We could have Common lisp, Java, Scheme and Perl simultaneously ;-)
Thanks but no thanks. At least both Scheme and CL have concepts such
as CAR/CDR, symbols, etc.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"I came here to chew bubble gum and to kick ass... and I'm all
out of ass." -- Crow, MST3K #519 ("Outlaw")
- 1 participants
- 0 comments
Re: Where do you want to go tomorrow?
27 years
Hrvoje Niksic
Hrvoje Niksic
sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
> Hrvoje> Lots of elisp code can run under Common Lisp almost
> Hrvoje> unchanged. This is not true for Scheme.
>
> Please substantiate this. By default, for instance, `let' is
> lexically scoped in Common Lisp, which is clearly incompatible with
> Emacs Lisp.
Not so by design. In fact, we were discussing introduction of a
lexically scoped `let' to elisp many times. And guess what? The
proposed semantics were equivalent to those used by CL -- lexical
scope by default, dynamic scope for special variables.
> Consequently, you would need a library of macros and procedures to
> emulate/translate Emacs Lisp functionality into Common Lisp.
Quite true -- I am not denying this.
> >> I personally believe a small substrate is less likely to alienate
> >> people than a large substrate.
>
> Hrvoje> I believe clisp is small enough, especially if we remove the
> Hrvoje> parts we don't need.
>
> This, however, means that Emacs CLisp won't be a standard Common
> Lisp implementation anymore, and surely old CL buffs will complain.
I don't care. Emacs is not ANSI CL. If that was the impression I was
giving, I apologize, because that is not what I meant.
> Hrvoje> My point is that choosing Common Lisp is a better idea
> Hrvoje> because it is closer to Emacs Lisp.
>
> The thing I'm having trouble is that you have not substantiated this
> statement based on the nature of the three languages involved. We
> really need to get down to the technical issues of this, and you
> haven't addressed them. I did outline what would be needed to adapt
> Scheme to Emacs Lisp. Someone should do the same for Common Lisp,
> and we can compare.
I will probably not be the one doing the work, and I have not a clear
idea of what it would take. This, however, should not mean I get no
vote in the discussion. I know where I want to end up.
> >> I honestly want to understand what you mean by this, but I don't.
> >> Sure, it has made sense to write Elisp libraries with constructs
> >> modelled like equivalent constructs in Common Lisp. It makes
> >> sense to write Scheme libraries with those constructs as well.
>
> Hrvoje> Does it? Not for me!
>
> Well, a lot of Scheme users and implementors disagree with you.
The Scheme users and implementors don't have the constraint of
previous implementation of Common Lisp idioms. We do, and I would
like us to preserve them.
> Hrvoje> Yes, that's what we were doing with Emacs Lisp, and I don't
> Hrvoje> really like the "poor man's common lisp" any more.
>
> In Scheme, you could actually implement a "rich man's Common Lisp"
I don't believe this. Common Lisp may not be perfect, but it's far
too complex to simulate correctly without a *lot* of effort.
> >> There must be a misunderstanding here, Hrvoje. My "battle plan" (I
> >> assume you're referring to my Web page on the subject matter)
> >> *specifically* includes other options.
>
> Hrvoje> Yes, but all the "Lisp engines" you mention are Scheme engines.
>
> Yes, because that's what I have personal experience with. Send me a
> write-up on CLisp or GCL or CMU CL, and I'll put it up.
What kind of write-up? Haven't I sent you my discussion with Bruno
Haible? Bruno's messages are an excellent case /pro/ clisp.
I don't like CMU CL (far too slow and buggy IMHO), and I haven't
worked with GCL much. It might be usable.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
HOW YOU CAN TELL THAT IT'S GOING TO BE A ROTTEN DAY:
#15 Your pet rock snaps at you.
- 1 participants
- 0 comments
problem with inserting image files
27 years
Charles G Waldman
Charles G Waldman
If I do C-x i foo.xpm RET with point at position 0 in a buffer, the
image is inserted and displayed correctly. If point is anywhere else
in the buffer, the image insert fails. Seems like the whole contents
of the buffer are being handed to the image decoder, not just the
image data.
I noticed this at first when trying to add support for JPEG and GIF to
the native Win32 version (this works by the way), but the bug is not
Windows-specific.
- 1 participants
- 0 comments