Mats, my feeling is that a lot of what needs doing here involves subjective
choices (e.g. what to call the merged file), where the most important thing
is not exactly what they are, but that someone decides one way or the other.
Basically, trust your judgement and make the changes. (And also, this is not
ferro-concrete, we can change things if something goes drastically wrong!)
Ar an ceathrú lá de mí Meitheamh, scríobh Mats Lidell:
> >>>>> Aidan Kehoe <kehoea(a)parhasard.net> writes:
>
> > My feeling is that this is the right way to go. In your position I’d
> > create a new file in XEmacs, call it syntax-ppss.el (notice that
> > #'syntax-ppss is the main function exported by their syntax.el), and
> > move GNU’s syntax.el into that file.
>
> One problem though, Users of syntax-ppss get it by requiring syntax.
One user (if we exclude core GNU Emacs files) does:
http://google.com/codesearch?as_q=\(require\+'syntax\)+file%3A\.el%24
Your go-mode.el doesn’t, as far as I can see. (Probably because GNU’s
syntax.el is dumped.)
> Which in our case would be require syntax-ppss instead I
> guess. This might be considered a small change to those, few!?,
> packages like the go-mode that actually uses syntax-ppss. (Go mode
> only uses that single function by the way.)
>
> I have earlier proposed to move the stuff in our syntax.el to subr.el
> and add the new syntax.el in xemacs-base. Views on that plan?
Will the new syntax.el even work in 21.4 (which would be the point of
putting it in packages)? I get the following when I byte-compile it under
21.4:
Compiling file /Sources/emacs/lisp/emacs-lisp/syntax.el at Sat Jun 4 16:01:34 2011
While compiling the end of the data:
** The following functions are not known to be defined:
replace-regexp-in-string, string-to-syntax, with-no-warnings,
font-lock-fontify-syntactic-keywords-region,
with-silent-modifications
> > Note when testing that #'syntax-ppss relies on #'parse-partial-sexp, and I
> > don’t know how compatible ours is with theirs.
>
> If they are not then making our compatible with theirs would be a good
> thing, right? That must be the overall plan for basic APIs? I assume
> here that parse-partial-sexp is a basic function possibly used by many
> packages.
Certainly, compatibility is a good thing, and #'p-p-s is a basic function
possibly used by many packages.
> > According to the docstring, a wrapper around #'parse-partial-sexp
> > would do it. But is #'syntax-ppss faster? Does it not modify some
> > global state? Does it cache things that #'parse-partial-sexp
> > doesn’t? It’s just about possible that there’s no point to it, in
> > which case a wrapper would be the way to go.
>
> Huh... seems complicated. parse-partial-sexp is implemented in C as
> buffer-syntactic-context is. Naively I would assume that to be
> faster!? But I guess looking into the function an see what it does is
> feasible.
>
> Your idea with syntax-ppss.el is I guess a smaller step. If it later
> can be removed due to overlapping functionality then why not but then
> I we don't have to bother about that now.
--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Anybody else seen this? Maybe I've done something wrong?
[jsparkes xemacs]$ hg pull xemacs
pulling from ssh://sperber-guest@hg.debian.org//hg/xemacs/xemacs
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 4 changes to 2 files
(run 'hg update' to get a working copy)
[jsparkes xemacs]$ hg update
merging man/ChangeLog
warning: conflicts during merge.
merging man/ChangeLog failed!
30 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges
[jsparkes xemacs]$ hg resolve -l
U man/ChangeLog
[jsparkes xemacs]$
[jsparkes xemacs]$
[jsparkes xemacs]$ hg resolve -l
U man/ChangeLog
[jsparkes xemacs]$ head man/ChangeLog
<<<<<<< local
2011-05-02 Aidan Kehoe <kehoea(a)parhasard.net>
=======
2011-05-20 Jerry James <james(a)xemacs.org>
>>>>>>> other
<<<<<<< local
* Makefile:
* texinfo.tex:
Merge by hand with the changeset that backed out e82f5b7010fe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
Been looking again at the task of getting the mode for go work with
XEmacs and need some help.
It uses functions from syntax.el[1] which in GNU Emacs contains
"helper functions to find syntactic context". Oddly(!?) this file
contains at the bottom commented out XEmacs(!) compatibility functions
for "buffer-syntactic-contex" and "buffer-syntactic-context-dept"
which are found in font-lock.c. This could indicate that we have
overlapping functionality which in its turn might be better handled by
just using our APIs instead!?
I ask myself what is the proper thing to do here:
1. Ignore that we have these overlap and just get the functions in
syntax.el into XEmacs as is.
2. Flip the coin and produce compatibility functions for the
functions in syntax.el.
2. Just change the mode that triggered this, go-mode, to use the
functions we have in XEmacs.[2]
Yours
Footnotes:
[1] This is a problem of its own since we have syntax.el already but
with different functions. I have posted about it earlier but with no
response. (Adding this footnote in the hope of getting some attention
to that problem! ;-)
[2] The actual offending function used by go-mode is this:
(syntax-ppss (&optional pos)
"Parse-Partial-Sexp State at POS, defaulting to point.
The returned value is the same as `parse-partial-sexp' except that
the 2nd and 6th values of the returned state cannot be relied upon.
Point is at POS when this function returns."
What would be the XEmacs way to implement that?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
From: jeff-xemacs(a)delphioutpost.com
Date: Wed, 1 Jun 2011 12:47:00 -0400
When I open a particular tiff file xemacs (21.4.22) crashes.
The bzipped tiff file is attached. The crash txt showing the lisp
backtrace is attached in crash.txt, the gdb where c backtrace is
attached in core.txt.
Some extra possibly useful information.
The image was cropped using gimp and saved using the default
CCIT Group 4 fax compression. The same image saved using 'CCIT Group
3 fax' compression does not crash XEmacs.
Also, I got a 'Failed issue tracker submission' email:
From: XEmacs Issue Tracking System <stephen(a)xemacs.org>
To: jeff-xemacs(a)delphioutpost.com
Subject: Failed issue tracker submission
Date: Wed, 01 Jun 2011 17:50:11 +0000
You are not permitted to add files to issue.
...
-jeff
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi all
It's been almost twelve years[1] since I created a PNG version of the
XEmacs icon with actual transparency and drop shadow. I figured that I
should submit it before my copyright expires... Speaking of which,
since the artwork is a rip off from etc/xemacs-icon.xpm, same license
would apply I guess. Please find attached PNG and XCF versions.
Enjoy,
Marcus
Footnotes:
[1] -rw-r--r-- 1 marcus marcus 739 1999-06-24 19:25 xemacs-icon.png
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta