symbol's value as variable is void: allow-remote-paths
12 years, 11 months
Richard Cook
Hi, I compiled xemacs myself and installed into $HOME/xemacs-without-ipv6-cname
I then made a symlink of $HOME/xemacs-without-ipv6-cname/bin/xemacs to $HOME/bin/xemacs
I untarred the sumo tarball from http://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo-2009-02-17.tar.gz and untarred it into $HOME/xemacs-without-ipv6-cname/lib/xemacs, which made a directory called xemacs-packages there.
When I run xemacs, I am not able to update my packages.
I go to Tools -> Packages -> Set Download Site -> Official Releases -> US and choose US Main.
I then go "update package index" or any other command in the Tools menu about Packages and it complains: "symbol's value as variable is void: allow-remote-paths"
Can anyone help me with this? Thanks.
--
✐Richard Cook
✇ Lawrence Livermore National Laboratory
Bldg-453 Rm-4024, Mail Stop L-557
7000 East Avenue, Livermore, CA, 94550, USA
☎ (office) (925) 423-9605
☎ (fax) (925) 423-6961
---
Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNL)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
Re: Thunderbird and XEmacs 21.4.22
14 years, 3 months
Rodney Sparapani
On 07/24/10 03:58 AM, Stephen J. Turnbull wrote:
>
> XEmacs *does* understand those, via the function url-retrieve.
> However, changing the meaning of command-line arguments
> program means is a recipe for trouble. Cf. the "Slow startup" thread,
> where Apple has gone and broken the DISPLAY variable. Trying to guess
> what is intended by these programs is a difficult problem.
>
> > So, I was crafting an email with thunderbird to which I attached a text
> > file.
> > But, then I wanted to view/edit that file. So, I double-clicked on it and
> > it asked me which application that I wanted to open it with. I chose
> > /usr/local/bin/xemacs which is 21.4.22. If I had picked OpenOffice,
> > then everything works. But, for text files, there is nothing like
> > XEmacs:o)
>
> There is probably a way to tell Thunderbird that it's talking to a
> traditional Unix program that expects to receive a file, not an URL.
> Traditionally in mimecap files that format would be
>
> text/plain /usr/local/bin/xemacs %s
>
> but I wouldn't be surprised if Thunderbird has usurped that format to
> mean URL, not file.
>
> I can't think of any quick hacks to make XEmacs do the right thing
> with an URL from the command line. I'll try later in the week.
I was trying to avoid URIs since they are such a PITA. I have spent
hours hacking them and they are no fun at all: very tricky to debug and
the syntax from hell. So, I decided to find a quick hack like you
suggest. Since XEmacs doesn't ship with a wrapper, I created one...
ARGS=
for i
do
ARGS="$ARGS \"`expr \"$i\" : \"file://\(.*\)\" \| \"$i\"`\""
done
if ! eval gnuclient $ARGS 2>/dev/null
then eval xemacs-21.4.21 $ARGS
fi
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
Grey Matter
14 years, 3 months
Ə
So when I install Xemacs there are useless items on the Tools menu marked
"Games" and "Calendar". How do I access them? They are all greyed out. Or
if they don't really exist, why are they even listed?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
closing named branches in the repository
14 years, 3 months
Jeff Sparkes
I've made a bit of a mess in the xemacs-gtk repository by working on two
separate machines and merging.
I tried named branches but didn't do it right, and did a poor job of
merging ChangeLogs.
I have a tendency to work on more than one thing at once. It's a lot
easier to use separate check out directories
or named shelves to switch between changeset.
I think I've repaired it with "hg rebase", and I closed my named branches
using method 1 in
http://mercurial.selenic.com/wiki/PruningDeadBranches.
There are 4 named branches in the current repository. Only one of them has
two parents, which I think
means it was merged back into the default. Should we close them for at least
aesthetic reasons?
--
Jeff Sparkes
jsparkes(a)gmail.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
Re: [Bug: 21.5-b29] Crash when displaying gif
14 years, 4 months
Vin Shelton
Yes. I have generated a ChangeLog and attached it to your patch. I
am posting this amalgam to xemacs-patches and will apply the change
tonight.
Thank you!
- Vin
On Wed, Aug 25, 2010 at 5:07 AM, Adam Sjøgren <asjo(a)koldfront.dk> wrote:
> Hi Vin,
>
>
> Have you had a chance to look at incorporating this patch in XEmacs?
>
>
> Best regards,
>
> Adam, hoping I am not to naggy.
>
>
> On Fri, 20 Aug 2010 06:49:12 -0400, Vin wrote:
>
>> Adam -
>> Thanks for digging in on this. You're not entirely by yourself - I
>> tried out your killer gif on my cygwin Windows build, and
>> unsurprisingly, XEmacs crashed immediately.
>
>> On Fri, Aug 20, 2010 at 4:56 AM, Adam Sjøgren <asjo(a)koldfront.dk> wrote:
>
>>> (Continuing talking to myself:)
>
>>> I've checked how other code handles color maps when reading gifs
>>> (specifically libimlib2-dev in Debian), and the following patch fixes
>>> the problem I encountered and makes the logo.gif in Mike Kupfers issue
>>> #713 show correctly (same as in Firefox):
>>>
>>> diff -r 04811a268716 -r 2519c46c4b9b src/glyphs-eimage.c
>>> --- a/src/glyphs-eimage.c Sun Aug 15 15:42:45 2010 +0100
>>> +++ b/src/glyphs-eimage.c Fri Aug 20 10:49:12 2010 +0200
>>> ＠＠ -694,7 +694,7 ＠＠
>>>
>>> /* 3. Now create the EImage(s) */
>>> {
>>> - ColorMapObject *cmo = unwind.giffile->SColorMap;
>>> + ColorMapObject *cmo = (unwind.giffile->Image.ColorMap ? unwind.giffile->Image.ColorMap : unwind.giffile->SColorMap);
>>> int i, j, row, pass, interlace, slice;
>>> UINT_64_BIT pixels_sq;
>>> Binbyte *eip;
>>> ＠＠ -703,6 +703,9 ＠＠
>>> static int InterlacedOffset[] = { 0, 4, 2, 1 };
>>> static int InterlacedJumps[] = { 8, 8, 4, 2 };
>>>
>>> + if (cmo == NULL)
>>> + signal_image_error ("GIF image has no color map", instantiator);
>>> +
>>> height = unwind.giffile->SHeight;
>>> width = unwind.giffile->SWidth;
>>> pixels_sq = (UINT_64_BIT) width * (UINT_64_BIT) height;
>
>> I much prefer this version of the fix. :-)
>
>>> I'm sure I haven't submitted this patch in the correct way, as I haven't
>>> had the time (nor momentum) to look into patcher etc. I hope someone
>>> will pick it up anyway.
>
>> I'll try this out by Sunday or Monday if no one else gets to this first.
>
>> Regards,
>> Vin
>
> --
> "But we are stubborn." Adam Sjøgren
> asjo(a)koldfront.dk
>
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
Scrolling large images
14 years, 4 months
Adam Sjøgren
So, feeling pretty cocky after figuring out the color map thing with
the crashing GIFs, here is the next niggle I have:
When a large image is displayed in XEmacs, I can't scroll down and see
the part of the image that isn't room for "on the first page" in the
frame.
I.e. load this image in an XEmacs window of say 42 chars~700 pixels
height:
* http://koldfront.dk/misc/xemacs/16x1440.png
I can't scroll further down than around the 600-mark - neither using the
arrow keys, page down, nor the scroll wheel.
The scroll wheel takes me down a little further than the arrow down and
page down keys, but not much.
It isn't much of a problem when just displaying a single image, as in
the example above, but when you are reading an HTML-article on
news.gwene.org which has large images in it, it quickly gets quite
annoying.
Are there any fixes for this?
Is it a fundamental thing, or something that someone stumbling through
the code could have a chance to do something about? Where to start?
Thanks :-),
Adam
--
"My internal clock is on Tokyo time." Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
comint-replace-by-expanded-filename and Slime
14 years, 4 months
Raymond Toy
Slime has this function for expanding filenames in the slime repl:
(defun slime-maybe-complete-as-filename ()
"If point is at a string starting with \", complete it as filename.
Return nil if point is not at filename."
(if (save-excursion (re-search-backward "\"[^ \t\n]+\\=" (max (point-min)
(-
(point) 1000)) t))
(let ((comint-completion-addsuffix '("/" . "\"")))
(comint-replace-by-expanded-filename)
t)
nil))
This doesn't work. I always get a error from
comint-replace-by-expanded-filename which says "last thing matched was
not a buffer". I don't really understand what that means, but this
means filename completion doesn't work.
Looking at comint-replace-by-expanded-filename, I see a call to
replace-match, but that doesn't need a buffer does it? It just needs
some match to so it knows what to replace.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
Fwd: xemacs winclient improvements
14 years, 4 months
Reini Urban
Hi
I'm back in business :)
I switched from native Win32 to cygwin because of the non-matching
Win32 permissions.
Cygwin ACL's are sometimes fucked up by inheritance.
So I have several improvements.
Patches inlined because gmail uploader fails on my proxy
diff -u xemacs-21.5.28/lib-src/winclient.c.orig
xemacs-21.5.28/lib-src/winclient.c
--- xemacs-21.5.28/lib-src/winclient.c.orig 2009-06-24 09:30:22.234375000 +0200
+++ xemacs-21.5.28/lib-src/winclient.c 2009-06-24 10:59:52.437500000 +0200
＠＠ -209,8 +209,8 ＠＠
CloseHandle (pi.hThread);
CloseHandle (pi.hProcess);
- /* Try to connect */
- for (n = 0; n < 5; n++)
+ /* Try to connect. Process startup and XEmacs init might be slow */
+ for (n = 0; n < 10; n++)
{
Sleep (CONNECT_DELAY);
＠＠ -408,6 +408,12 ＠＠
/* Retrieve arguments */
while ((arg = getNextArg ((const char**)&lpszCommandLine, &len)) != NULL)
{
+#ifdef __CYGWIN__
+ /* On cygwin args are already space delimited so pass these args
+ verbatim to XEmacs */
+ fullpath = (char *) xmalloc (len);
+ ret = doFile (hConv, fullpath, arg);
+#else
/* First find the canonical path name */
fullpath = filepart = NULL;
pathlen = GetFullPathName (arg, 0, fullpath, &filepart);
＠＠ -451,7 +457,7 ＠＠
FindClose (hFindFile);
}
-
+#endif
/* Release the path name buffers */
free (fullpath);
free (arg);
diff -u xemacs-21.5.28/lib-src/Makefile.in.in.orig
xemacs-21.5.28/lib-src/Makefile.in.in
--- xemacs-21.5.28/lib-src/Makefile.in.in.orig 2007-05-21
05:50:19.000000000 +0200
+++ xemacs-21.5.28/lib-src/Makefile.in.in 2009-06-24 09:40:30.250000000 +0200
＠＠ -375,7 +375,7 ＠＠
$(CC) $(cflags) ${srcdir}/../nt/minitar.c $(ldflags) -lz -o $＠
winclient: ${srcdir}/winclient.c
- $(CC) $(cflags) ${srcdir}/winclient.c $(ldflags) -o $＠
+ $(CC) $(cflags) -mwindows ${srcdir}/winclient.c $(ldflags) -o $＠
hexl: ${srcdir}/hexl.c
$(CC) $(cflags) ${srcdir}/hexl.c $(ldflags) -o $＠
---------- Forwarded message ----------
From: Reini Urban <rurban(a)x-ray.at>
Date: 2009/6/24
Subject: xemacs winclient improvements
To: The Cygwin Mailing List <cygwin(a)cygwin.com>
Several xemacs ideas:
* I added -mwindows to the winclient linker step which results in a
much improved winclient.
I'll take this patch to xemacs-patches by myself.
* parseCommandLine() does not work on cygwin this way.
It uses the Win32 API to find files, and should be special cased to
use the POSIX API.
I'll discuss this at xemacs-beta
* xemacs-21.5.28-3 uses slow defaults:
Compiling in support for extra debugging code.
Compiling in support for runtime error checking.
WARNING: ---------------------------------------------------------
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
hmm. 21.5.28 is stable for me and upstream. maybe remove this.
* build failure on 1.7:
In file included from
/usr/src/xemacs-21.5.28-3/src/xemacs-21.5.28/src/console-msw.h:41,
from
/usr/src/xemacs-21.5.28-3/src/xemacs-21.5.28/src/cmdloop.c:43:
/usr/src/xemacs-21.5.28-3/src/xemacs-21.5.28/src/syswindows.h:500:
error: conflicting types for 'wcstok'
/usr/include/wchar.h:92: error: previous declaration of 'wcstok' was here
make[1]: *** [cmdloop.o] Error 1
This needs a patch upstream. Maybe I'll take it upstream.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: XEmacs equivalent of emacs mode line data?
14 years, 4 months
Aidan Kehoe
Ar an chéad lá is fiche de mí Lúnasa, scríobh Raymond Toy:
> On 8/21/10 10:40 AM, Aidan Kehoe wrote:
> > Ar an naoú lá déag de mí Lúnasa, scríobh Raymond Toy:
> >
> > > This shows up in slime where currently slime updates the modeline by
> > > scanning every buffer to see if it is in slime-mode and updating the
> > > modeline appropriately. When there are a dozen buffers or more,
> > > slime drastically slows down.
> >
> > There isn’t yet. I would be shocked if [it] were absolutely necessary,
> > though; does replacing #'slime-recompute-modelines with the below
> > (untested, I haven’t used slime much) improve things for you? And yes,
> > byte-compilation is the way to go!
>
> [snip code]
>
> This seems to work very well, even without byte-compiling the code.
>
> Thank you very much for this. I'll send it off to the slime guys so
> they can incorporate this code into slime.
As I say, I haven’t used slime much, and from looking a bit closer at the
slime code I can imagine my change being irritatingly slow to update
modelines in buffers that have just been displayed, after having been hidden
for some time. If you notice this, please give the below a shot; as well as
updating the modeline with each slime event received, it’ll update the
modeline every time XEmacs has nothing to do (that is, you’ve stopped typing
for five seconds, or whatever.) The older version of the recompute function
was a little readier to force a modeline update, which is not ideal if the
function is to be called from pre-idle-hook.
(defmacro slime-recompute-modelines ()
;; Avoid a needless runtime funcall on GNU Emacs:
(and (featurep 'xemacs) `(slime-xemacs-recompute-modelines)))
(defun slime-xemacs-recompute-modelines ()
(let (redraw-modeline)
(walk-windows
#'(lambda (object)
(setq object (window-buffer object))
(when (or (symbol-value-in-buffer 'slime-mode object)
(symbol-value-in-buffer 'slime-popup-buffer-mode object))
;; Only do the unwind-protect of #'with-current-buffer if we're
;; actually interested in this buffer:
(with-current-buffer object
(setq redraw-modeline
(or (not (equal slime-modeline-string
(setq slime-modeline-string
(slime-modeline-string))))
redraw-modeline)))))
'never 'visible)
(and redraw-modeline (redraw-modeline t))))
(and (featurep 'xemacs)
(pushnew 'slime-xemacs-recompute-modelines pre-idle-hook))
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
