Re: Lisp Stream API.
17 years, 6 months
Aidan Kehoe
Ar an ceathrú lá déag de mí na Samhain, scríobh stephen(a)xemacs.org:
> > Can someone explain to this no-formal-education-in-the-language Lisp user
> > why we don’t have (with-open-file ...) and the rest of the Common Lisp
> > stream API in XEmacs Lisp?
>
> Mostly hysterical raisins, I would guess. I suppose the main issue is
> that Emacs is an interactive text editor with a strong bias toward
> "slurp it ALL into an Emacs buffer and operate on it there". If you
> actually have an open I/O stream (pipe, network) then we do support
> those, with comint and so on, but in a quite different way from
> line-oriented streams (for example).
>
> > (insert-file-contents ...) with offsets doesn’t really cut it for
> > things like Perlish line processing.
>
> I don't understand what you mean by "Perlish line processing". The
> closest I can come up with is
>
> (progn
> (find-file "some/file")
> (while (not (eobp))
> (function-that-operates-on-a-line (point) (point-at-eol))
> (forward-line 1)))
>
> which demonstrates the "file-at-a-gulp" attitude. I suppose if you're
> really worried about memory usage you could do partial buffering with
> insert-file-contents as you mention, but the actual "read-line"
> function would still just be `forward-line'.
My problem is the memory usage, and my laptop’s tendency to overheat. For
example, I have a natural-language dictionary with each entry on a separate
line and I’m generating a .db index; the memory usage is stupid. The same
will be true for anyone working on Unihan.txt or big database dumps.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
RE: XEmacs 21.4.19: Problem with customized folders on Windows XP
17 years, 6 months
Benson Margulies
It could be a few days before I get set up to tackle check_writable,
which would be my approach. I don't see a problem with an interim patch
if you like.
-----Original Message-----
From: Tony Freixas [mailto:tony＠tigerheron.com]
Sent: Monday, November 13, 2006 11:02 AM
To: Benson Margulies
Cc: stephen(a)xemacs.org; XEmacs-Beta(a)xemacs.org
Subject: Re: XEmacs 21.4.19: Problem with customized folders on Windows
XP
Benson Margulies wrote:
> Can you point me at some description of how to get off the ground as
an
> XEmacs contributor.
stephen(a)xemacs.org wrote:
> Please do it this way:
>
> #define DONT_CHECK_DIRECTORY_WRITABLE
> #if !defined(MS_WINDOWS) || !defined(DONT_CHECK_DIRECTORY_WRITABLE)
> /* code that does the wrong thing on windows */
> #endif
>
> and send a patch to xemacs-patches.
Benson, feel free to take this on--I don't have the time or the
expertise. Here's what I did on my system using the XEmacs 21.4.19
source:
In src/fileio.c:
DEFUN ("file-writable-p", Ffile_writable_p, 1, 1, 0, /*
Return t if file FILENAME can be written or created by you.
*/
(filename))
{
/* This function can GC. GC checked 1997.04.10. */
Lisp_Object abspath, dir;
Lisp_Object handler;
struct stat statbuf;
struct gcpro gcpro1;
CHECK_STRING (filename);
abspath = Fexpand_file_name (filename, Qnil);
/* If the file name has special constructs in it,
call the corresponding file handler. */
GCPRO1 (abspath);
handler = Ffind_file_name_handler (abspath, Qfile_writable_p);
UNGCPRO;
if (!NILP (handler))
return call2 (handler, Qfile_writable_p, abspath);
if (xemacs_stat ((char *) XSTRING_DATA (abspath), &statbuf) >= 0)
return (check_writable ((char *) XSTRING_DATA (abspath))
? Qt : Qnil);
// GCPRO1 (abspath);
// dir = Ffile_name_directory (abspath);
// UNGCPRO;
// return (check_writable (!NILP (dir) ? (char *) XSTRING_DATA (dir)
//: "")
// ? Qt : Qnil);
//AF The check_writable() method doesn't work correctly on NTFS so
//we are going to lie
return Qt;
}
With Stephen's suggestion, the commented out section would become:
#if !defined(MS_WINDOWS) || !defined(DONT_CHECK_DIRECTORY_WRITABLE)
GCPRO1 (abspath);
dir = Ffile_name_directory (abspath);
UNGCPRO;
return (check_writable (!NILP (dir) ? (char *) XSTRING_DATA (dir)
: "")
? Qt : Qnil);
#else
return Qt;
#endif
The "right" solution would be to fix the check_writable function in the
same file:
static int
check_writable (const char *filename)
{
#ifdef MS_WINDOWS
// Use correct access control for Windows
// Needs to work for FAT, FAT32, NTFS and ???
// Filename can be a file, directory, junction point(?), shortcut(??)
#else
#ifdef HAVE_EACCESS
return (eaccess (filename, W_OK) >= 0);
#else
/* Access isn't quite right because it uses the real uid
and we really want to test with the effective uid.
But Unix doesn't give us a right way to do it.
Opening with O_WRONLY could work for an ordinary file,
but would lose for directories. */
return (access (filename, W_OK) >= 0);
#endif
#endif
}
If you don't plan to take this on, let me know and I'll try to submit a
patch for the stop-gap solution.
--
Tony Freixas
Tiger Heron LLC
tony(a)tigerheron.com
http://www.tigerheron.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
RE: XEmacs 21.4.19: Problem with customized folders on Windows XP
17 years, 6 months
Stephen J. Turnbull
Benson Margulies writes:
> I've never seen any program other than xemacs pay any attention to the
> read-only attribute on a Windows directory. I suspect that XEmacs is
> manually checking the bit. Given the complexity of ACLS, XEmacs needs to
> just go ahead and try to write to the directory and see what comes back,
> or learn to use the API that asks 'do I have effective Write access'.
> Looking at the flag is only causing confusion.
We have both native and Cygwin implementations, and currently no
active experienced Windows developers. Patches would be welcome.
Vague specifications that say "this is hard" ;-) will be ignored by me
for sure (I don't even have a working Windows system at the moment),
and probably by the project for lack of skills.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Lisp Stream API.
17 years, 6 months
Aidan Kehoe
Can someone explain to this no-formal-education-in-the-language Lisp user
why we don’t have (with-open-file ...) and the rest of the Common Lisp
stream API in XEmacs Lisp? (insert-file-contents ...) with offsets doesn’t
really cut it for things like Perlish line processing.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: [PATCH] Prevent a crash if the ASCII charset registries match nothing
17 years, 6 months
Aidan Kehoe
Ar an triú lá déag de mí na Samhain, scríobh stephen(a)xemacs.org:
> > > QUERY
> > >
> > > What's the big hurry?
> >
> > Where is everyone getting the impression I’m in a hurry?
>
> I don't speak for anybody else in this. IMO "I'll commit this
> tonight" is a *big* hurry, for those of us who should be reviewing.
I had posted a first draft of the patch Wednesday, in
17746.1739.273694.339710(a)parhasard.net . I committed it Sunday. The patch
itself is only relevant to people with the bad sense to call
(set-charset-registries 'ascii ["nothing-sensible"])--for the vast, vast
majority of users it’s irrelevant. It didn’t seem to me to need much
discussion; I appear to have been wrong in this.
In contrast, I posted two more debatable patches yesterday with no time
frame for a commit. I posted a patch today with no time frame for a commit.
I suspect I’ll post one tomorrow.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: empty charset registry?
17 years, 6 months
Aidan Kehoe
Ar an triú lá déag de mí na Samhain, scríobh stephen(a)xemacs.org:
> Aidan Kehoe writes:
>
> > I haven’t tried, but if you’ve access to the machine the X server’s
> > running on, what’s preventing you creating a directory under /tmp/,
> > adding a fonts.alias file to it with such a mapping, and adding that
> > directory to your font path with xset fp+ ?
>
> It would work if you copied the fonts, too, I think.
I just tried it on Cygwin, and you don’t even need to copy the fonts.
> So? It's still a nasty hack that typical users of legacy systems are not
> going to expect to need, and the need is going to be less than obvious.
> "*" should match "fixed" without any need for hacks.
Wrong; either there’s an abstraction-breaking hack in the XEmacs code, or
the particularly driven user with a particularly broken X server gets to
implement a hack. We have been saying for literally ten years to use XLFDs:
1.1 (steve 18-Dec-96): versions. All X fonts can be referred to via XLFD-style names, so you
1.1 (steve 18-Dec-96): should use those forms. See the man pages for ＠samp{X(1)},
1.1 (steve 18-Dec-96): ＠samp{xlsfonts(1)}, and ＠samp{xfontsel(1)}.
1.1 (steve 18-Dec-96):
(from the CVS annotation of man/custom.texi) and I don’t think it
unreasonable to enforce that now.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: [PATCH] Prevent a crash if the ASCII charset registries match nothing
17 years, 6 months
Aidan Kehoe
Ar an triú lá déag de mí na Samhain, scríobh stephen(a)xemacs.org:
> [...] The point is that we are not thinking about a release at this time.
> The patches that you are proposing do fix real bugs, and arguably are
> better than what we have. But they clearly change *correct* (ie, useful
> to somebody and conforming to existing specs, including the trivial case
> of no explicit spec) user-visible behavior and IMO complexify XEmacs's
> APIs. Is that really appropriate at this stage in the development cycle?
What development cycle? “Cycle” involves some concept of “release,”
right? Release involves a release engineer, and a schedule, things we don’t
have.
> Again IMO, XEmacs is in trouble more because of its archaic complexity
> which deters improvement than because of its bugs (and admittedly
> those are many). We really need to simplify and regularize behavior,
> especially of Mule, even at the expense of more buggy behavior in the
> short run. We need to push fixes out to Lisp wherever possible;
> changes at C-level should be in accord with some kind of design and
> explicit specification, not ad hoc fixes of bugs.
You know, I hate that. I understand the reasoning, but it seems to me that
people push decisions out to Lisp _and then leave them unimplemented or
unfinished there_ too much. The locale sniffing is in Lisp, and it sucks.
The face menu is Lisp, and it’s kind of buggy, inconsistent, and slow (not
helped by my recent change--I’ll get to fixing it soon, promise!). More
generally, the menus are in Lisp, and they’re not that coherent or nice to
use--they is no overarching theme of what merits a menu entry and what
doesn’t. Deciding which mouse button to use when clicking on a link is in
Lisp, and it’s wrong, and has been ever since Mosaic was released.
> For example, your change to the specifier tags may be a good one, but
> we should think about other revisions at the same time. For example,
> I think it would be a good idea to have a mode specifier domain---the
> buffer domain is mostly used only by mode-specific code, people hardly
> ever apply specifications to just one buffer. Are there other
> features that could use tag tests like the one you added for charsets?
> Are we pretty sure there aren't? (If the answer to the last question
> were "yes", I'd have much less objection to the specifier changes
> you've made. If it's "no", the API you created is dubious.)
I’m not enchanted with specifiers generally--do a (setq debug-x-faces 1
debug-x-objects 1) and watch how often they call that code for one part of
why--so with regard to your example, IMO buffer-local variables are good
enough for that problem, and there are enough parts of XEmacs that aren’t
“good enough” that they come earlier in the queue.
I can’t think of any other features that could use tag tests like the one I
added for charsets, but maybe someone more enchanted by specifiers could.
> In general, IMO we need to get rid of internal Mule encoding and CCL
> so people with some familiarity with modern I18N can work on XEmacs,
> not make them less painful for end users but require a PhD in software
> archaeology of would-be hackers.
Well, I think implementing that would be workable and relatively painless,
there are none of the design questions I had trouble with when I first
proposed it--refactor the existing Mule encoding and the existing Unicode
support to make it possible to treat it as an implementation of ISO 2022 on
top of Unicode, instead of vice-versa, use some of that infrastructure for
X11 server-side redisplay, don’t use any of it for XFT or Win32, use the
UTF-8 escapes in generated escape-quoted .elc files instead of the ISO-2022
encoding for non-ASCII characters, but be equally prepared to read the
ISO-2022 representations of characters.
But I don’t like the idea of adding one more configure option for it at this
point in time; it’s already a lot of work, and too easy to forget one of
them, to test any changes on X11 with Mule, X11 without Mule, XFT with Mule,
XFT without Mule, Win32 with Mule, Win32 without Mule, the TTY. I’d be more
open to it if we removed non-Mule as an option, but I don’t see that
happening soon.
> Now, if you think that we *need* to fix those bugs so that people can
> have a usable XEmacs in the meantime, I can live with that. But IMO
> we need to make a separate branch (ie, an interim release) so that the
> mainline doesn't get encrufted with ad hoc workarounds.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: decoders writing control-1 chars?
17 years, 6 months
Aidan Kehoe
Ar an t-ochtú lá de mí na Samhain, scríobh Ilya N. Golubev:
> > it seems I sent that to the
> > list, and not to you explicitly.
>
> Then thanks for resending, since I am not on any of the lists.
>
> Adding `ccl-program-definition' did not directly fix the broken
> conversion. It was practically necessary to figure what C code to
> look at, and will remain so until no CCL coding system is ever used.
> Will post separate patches on request.
>
> [...]
>
> --- src/mule-ccl.c
> +++ src/mule-ccl.c
> ＠＠ -1372,8 +1372,6 ＠＠
> i = reg[RRR]; /* charset */
> if (i == LEADING_BYTE_ASCII)
> i = reg[rrr] & 0xFF;
> - else if (LEADING_BYTE_CONTROL_1 == i)
> - i = ((reg[rrr] & 0xFF) - 0xA0);
> else if (POSSIBLE_LEADING_BYTE_P(i) &&
> !NILP(CHARSET_BY_LEADING_BYTE(i)))
> {
> ＠＠ -2257,6 +2255,18 ＠＠
Your change crashes a debug build of 21.5 when the following code is
executed:
(let ((ccl-vector [0 0 0 0 0 0 0 0 0]))
(define-ccl-program ccl-write-two-control-1-chars
`(1
((r0 = 143)
(r1 = 0)
(write-multibyte-character r0 r1)
(r1 = 31)
(write-multibyte-character r0 r1)))
"CCL program to transform Mule characters to UCS-2.")
(assert (equal
(ccl-execute-on-string 'ccl-write-two-control-1-chars
ccl-vector "")
(format "%c%c" (make-char 'control-1 0)
(make-char 'control-1 31)))
nil
"CCL's write-multibyte-character breaks for control-1! "))
This works okay, however:
Index: src/mule-ccl.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/mule-ccl.c,v
retrieving revision 1.30
diff -u -u -r1.30 mule-ccl.c
--- src/mule-ccl.c 2006/06/14 06:10:10 1.30
+++ src/mule-ccl.c 2006/11/12 22:49:27
＠＠ -1390,7 +1390,7 ＠＠
if (i == LEADING_BYTE_ASCII)
i = reg[rrr] & 0xFF;
else if (LEADING_BYTE_CONTROL_1 == i)
- i = ((reg[rrr] & 0xFF) - 0xA0);
+ i = ((reg[rrr] & 0x1F) + 0x80);
else if (POSSIBLE_LEADING_BYTE_P(i) &&
!NILP(charset_by_leading_byte(i)))
{
There is a separate but similar problem with mule-to-unicode that I’m still
looking into.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: [PATCH] Prevent a crash if the ASCII charset registries match nothing
17 years, 6 months
Aidan Kehoe
Ar an triú lá déag de mí na Samhain, scríobh stephen(a)xemacs.org:
> QUERY
>
> What's the big hurry?
Where is everyone getting the impression I’m in a hurry? I mean, if you want
me to code less, sure, I’ve a stack of language textbooks that are being
super-slack about reading themselves. But if you want me to spend months
intermittently on every patch, I don’t know that that’s any more helpful
than a concentrated block of time; certainly I think that the docstring
error that Ilya pointed out was a consequence of that sort of wait.
> Aidan Kehoe writes:
>
> > Eh, still, XEmacs shouldn’t be crashable from Lisp. The below has a
> > bit more testing, with X11 and GTK; I intend committing it this
> > evening.
>
> The crash you're describing is the well-known exit-via-X-handler on
> startup, is it not?
No, at least not to my knowledge. Reference? My crash is:
1. Start an XEmacs in a screen session.
(unset DISPLAY && screen -d -m xemacs)
2. Open a gnuclient frame on the current X11 display.
gnuclient
3. Set the charset registries of ASCII to something that prevents any font
matching.
(set-charset-registries 'ascii ["this is not-sensible"])
4. Watch XEmacs crash. But it shouldn’t crash, it should delete the X11
frame and throw an error in the TTY.
This didn’t happen previously and in 21.4 because of some special-casing
that optionally ignored charset registries for ASCII--this restores some
special-casing, but enforces more strictly that font names should be in XLFD
format, a requirement already documented in the manual.
> You really need to replace the X error handler to prevent that.
>
> Making things a little bit better for people with misconfigured
> systems at the expense of breaking Ilya's hacks is not a good tradeoff
> IMO.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
Re: empty charset registry?
17 years, 6 months
Aidan Kehoe
Ar an triú lá déag de mí na Samhain, scríobh stephen(a)xemacs.org:
> Aidan Kehoe writes:
>
> > No; you can add a fonts.alias entry for that font to your X11 server
> > configuration, mapping it to a sane name.
>
> Not everybody has the necessary privileges.
>
> Please stop assuming personal computers.
I haven’t tried, but if you’ve access to the machine the X server’s running
on, what’s preventing you creating a directory under /tmp/, adding a
fonts.alias file to it with such a mapping, and adding that directory to
your font path with xset fp+ ?
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta