I have received a bug report via Fedora's bug tracker that appears to
be identical to issue 802. The reporter says that the assertion
failure is repeatable if he (a) installs the xemacs-ess package, (b)
sets up his init files to initialize ESS on startup, and (c) launches
XEmacs by clicking on an icon on his KDE desktop.
Is anything more known about this crash?
See https://bugzilla.redhat.com/show_bug.cgi?id=890565.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2013-01-08 - 2013-01-15)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
553 open ( +0) / 294 closed ( +0) / 847 total ( +0)
Open issues with patches: 13
Average duration of open issues: 1335 days.
Median duration of open issues: 1418 days.
Open Issues Breakdown
new 233 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 57 ( +0)
assigned 153 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 17 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
>> o What next? Gotta get mule in there, I guess. Where do I get it,
>> and where in the source hierarchy does it fall? I don't know that
>> no mule is the only problem.
> I went through this exercise last week... the first step is to add
> "--with-mule" to the "configure" options. You may have to hunt down &
> install "gettext" and "iconv" as well; I had to, but I don't use macports
> (or any equivalent).
Aha! Okay. That allowed me to get all the way to the end and produces
a runnable xemacs.
I did make install under sudo, and it dropped stuff in /usr/local/lib and
in /usr/local/share, but nothing I recognize as a usable binary. There
is one in the src directory, though.
The one major headache that's always bothered me with xemacs is
where all the directories of stuff belong.
When I run the xemacs in this src directory, naturally it finds errors in
my ~/.xemacs/init.el, but that's got to be because it doesn't know where
to find the packages.
> I ended up with an XEmacs image that appears to have no support for the
> native Mac Windowing system, and not X11 support. I'm pretty sure that it
> should be possible to get the X11 support in there ...
Ummm. I've never heard of it running native on the Mac, and have always
assumed that X11 is required. I do have that. Since I first started using
Macs as a base of operations things have shifted around with X11, and
when I was configuring my iMac for use, I was told that this is now
under the auspicies of a organization (?) called XQuartz. In any case,
it was not difficult to install this, and in fact X11 now runs much better
than it ever did before.
Isn't X11 what the "X" in XEmacs is all about? Emacs that runs under
X11 in order to get graphics support? I always thought so.
Well, at least I got it to compile. Sometime RSN I'll have to tread my
way through the splatter that got left behind to see if I can get it to
actually work for me.
My days of testing stuff are long behind me. I've become the sort of guy
who just wants stuff on my own workhorse system to just work right,
with minimum hassles.
Thanks.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.comlynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Uwe Brauer writes:
> Of course of course, but the issue is the other person does not
> use Xemacs, but Kile and then transfer the files from devices
> with different file systems, ext2, fat32 etc and suddenly they
> have a dos ending, I don't notice check in and oops.
Check out core.eol, core.safecrlf, core.autocrlf in "git help config".
Probably other VCSes will do the same thing, but git's the one I
already knew (and I'll bet you RCS *does not*" ;-) git also allows
you to safely revert commits (or even reach back and create a whole
new history, just with the file having the proper EOLs throughout the
branch -- this isn't easy, but it can be done safely).
> decline the changes. However if the file has *no* mac line
> ending, the changes are *not* correctly detected and the whole
> process can end up in a complete mess. I am not sure whether I
> explained myself well enough....
It sounds like this program is using the Mac line endings the way
Emacs used to -- to "hide" lines from normal processing. It also
sounds like you have a real mess on your hands, if Kile and/or the
file transfers are randomly changing the EOLs.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Uwe Brauer writes:
> Precisely, this is main source for headache for me. In a collaboration
> with a college (LaTeX files) I obtain often files with dos ending, and
> when checking them in, RCS gets screwed up just in the way you mention.
LaTeX doesn't care about line endings (the CR is just whitespace, and
the LF already introduces whitespace), right? RCS doesn't either, as
long as you don't change them. Why not edit with XEmacs, which
doesn't care about line endings either, and leave the line endings as
they are?
If for some reason you *need* to combine files with *different* line
endings, there's got to be a better workflow for you.
> That's why I thought of a different tool, which is not based on version
> control but on Latex itself and a python script; problem again for the
> script to work the files now must use the Mac end of the line
> convention. :'(
That's bizarre. Python doesn't usually care about newlines.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Uwe,
This is not a modeline indicator that you asked about,
but I have to convert line ends frequently enough
that Byrel and I made a menu item to convert line end
styles a couple of years ago.
As an improvement. I was thinking of figuring out how to
display the current line-end style in
the title of the sub menu, which, while not on the modeline,
would be an indicator of the current style on a submenu.
That would at least save me from editing it as a hex file to see
which line ends style were being used in a file.
It also does not do anything with end of file
(control-Z?)--it just changes line ends, but that could probably
be added.
Hopefully someone who knows more about different encodings
can suggest improvements.
Posted inline, since I am not sure if we can post attachments.
;;; change-line-ends-menu.el
;;; Copyright (C) 2013 Steve Mitchell and Byrel Mitchell
;;; email: smitchel(a)bnin.net
;;; email: byrel.mitchell(a)gmail.com
;;;
;;; This program is free software; you can redistribute it and/or modify
;;; it under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3, or (at your option)
;;; any later version.
;;;
;;; This program is distributed in the hope that it will be useful,
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with this program; if not, write to the Free Software
;;; Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
;;;
;;;
;;; This adds a sub-menu item, Change Line Ends which offers choices
;;; to quickly change all line ends in a selection or a whole buffer
;;; to styles used by different OS's.
;;;
;;; The menu items have two components to their string names:
;;; - a character representation, i.e. CR-LF --> LF
;;; - an OS representation, i.e. DOS to Linux
;;; together, these representations help you quickly understand
;;; the choice to make in converting line ends.
;;;
;;; Note, Fanuc is the output of of GE's fanuc cnc machine controls
;;; this can be left off if this is not germane to your situation.
;;;
;;; Note: Windows is not left off to slight that Operating System.
;;; some programs in Windows still output DOS's line ends (CR LF)
;;; and some output just LF as line ends (like Linux generally does)
;;; so I am not sure how to implement that correctly.
(add-submenu '("Cmds") '("Change Line Ends"
["CR-LF --> LF (DOS to Linux)"
( change-line-ends "\^M\^J" "\^J")]
["CR-LF --> CR (DOS to Mac)"
( change-line-ends "\^M\^J" "\^M")]
["LF --> CR-LF (Linux to DOS)"
( change-line-ends "\^J" "\^M\^J")]
["LF --> CR (Linux to Mac)"
( change-line-ends "\^J" "\^M")]
["CR --> CR-LF (Mac to DOS)"
( change-line-ends "\^M" "\^J")]
["CR --> LF (Mac to Linux)"
( change-line-ends "\^M" "\^J")]
["LF-CR-CR --> LF (fanuc to Linux)"
( change-line-ends "\^J\^M\^M" "\^J")]) nil)
( defun change-line-ends (from to)
"Change line ends in whole buffor or marked block.
FROM is the line end to search for,
TO is the line end to replace it with."
(if (not (region-exists-p)) (goto-char (point-min)) ;if no selection,
do whole buffer
( goto-char point)) ;if a selection, go to
beginning. maybe not needed?
(while (search-forward-regexp from nil t ) ; do the requested
search/replace
(replace-match to)))
;--- end of change-line-ends-menu.el
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
APPROVE COMMIT 21.5
I'm not sure how this happened, whether it's a side effect of a
Mercurial operation or a careless merge by hand, but please be really
careful to ensure that the release Herald markers are not disturbed
when pushing. It would be nice if the logs were in order of commits
(and there are definitely similar artifacts in several logs), but it's
not such a big deal within a version. It is important that commits
that occur *after* a release do not appear in the logs *before* the
release and vice versa.
diff -r 9dc294ae3004 -r 9f1c9f957073 lisp/ChangeLog
--- a/lisp/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/lisp/ChangeLog Mon Dec 24 01:07:25 2012 +0900
@@ -51,15 +51,15 @@
Removed. Move this to C, so we can use
look_for_coding_system_magic_cookie().
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* help.el (describe-function-1):
Document any command remapping that has been done in this function.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-14 Aidan Kehoe <kehoea(a)parhasard.net>
* byte-optimize.el (byte-optimize-letX):
diff -r 9dc294ae3004 -r 9f1c9f957073 man/ChangeLog
--- a/man/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/man/ChangeLog Mon Dec 24 01:07:25 2012 +0900
@@ -17,10 +17,6 @@
Document the new syntax of ## for the symbol with name "" interned
in obarray.
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* lispref/keymaps.texi (Keymaps):
@@ -31,6 +27,10 @@
* lispref/keymaps.texi (Other Keymap Functions):
Document the new command remapping functionality in this file.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-06 Aidan Kehoe <kehoea(a)parhasard.net>
* lispref/macros.texi (Expansion):
diff -r 9dc294ae3004 -r 9f1c9f957073 src/ChangeLog
--- a/src/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/src/ChangeLog Mon Dec 24 01:07:25 2012 +0900
@@ -89,10 +89,6 @@
Adopt GNU's ## syntax for the interned symbol with the zero-length
name.
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* keymap.c:
@@ -128,6 +124,10 @@
* keymap.c (complex_vars_of_keymap):
* lisp.h: New CHECK_COMMAND macro.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-14 Aidan Kehoe <kehoea(a)parhasard.net>
* minibuf.c (Ftest_completion):
diff -r 9dc294ae3004 -r 9f1c9f957073 tests/ChangeLog
--- a/tests/ChangeLog Fri Dec 14 01:19:36 2012 +0100
+++ b/tests/ChangeLog Mon Dec 24 01:07:25 2012 +0900
@@ -14,15 +14,15 @@
Make sure we can search for character ranges successfully when the
syntax table is dirty.
-2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
-
- * XEmacs 21.5.32 "habanero" is released.
-
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* automated/keymap-tests.el:
Test the new command remapping functionality.
+2012-08-02 Stephen J. Turnbull <stephen(a)xemacs.org>
+
+ * XEmacs 21.5.32 "habanero" is released.
+
2012-05-12 Aidan Kehoe <kehoea(a)parhasard.net>
* automated/mule-tests.el:
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
As long as I have the attention of a few diehard loyal xemacers, maybe
someone knows ...
Is there some sort of add-on that works with Chrome that can make use of
gnuclient?
For years I used Firefox as my browser, and had a lot of extensions I depended
on. One of the main ones was a fancy version of view-source (I think it's
called ViewSourceWith) that allows users to use an external editor of choice
to edit textarea boxes, or in fact absolutely any sort of text box.[1] I set it
up to use gnuclient, and was able to edit long and complex e-mail messages
with it, but also most anything else: even cells in Google Drive spreadsheets
if I wanted. I needed to write a really simple shell script in order to handle
arguments. Worked like a million bucks, and made it easy for me to switch
from using VM for mail to using gmail directly, which I've now done for a long
time and can't imagine ever going back.
However, Firefox has its shortcomings, as a lot of people are realizing,
whereas Chrome is the latest cat's meow. I with ViewSourceWith would be
ported to work with Chrome, but it doesn't appear that it will be.
There are a couple of extensions that purport to use Emacs for editing.
I tried them. They depend on an elisp file (supplied) and I guess a
sort of client like gnuclient (ditto). GNU Emacs has to be running. You
press the magic key, and it sends the current textarea buffer to a new
frame (or window, whatever the nomenclature is). (Doesn't pop it up,
though.) Not bad. Could be better. Would be better if it could be
modified to run with xemacs instead. Other problems, too.
Unfortunately, though, there were some negative side effects. I found
that I was unable almost entirely to use Google Drive any more,
particularly for spreadsheets. I use a fair number of these. Something
or other was messing severely with the keybindings.
After struggling with this at least a month, I finally gave up and went
back to Firefox and ViewSourceWith for a while. Until my aging MacBook
Pro totally bit the dust on me. (It was due.)
So I bought the new 27-inch iMac, which is sweet, and of couse I have
emacs-like keybindings in gmail and other places, but I don't have the
easy ability to pop a buffer out to a running XEmacs -- or more
specifically, to a running client program that will serve it to the
program of choice.
Is there a solution?
[1] I guess I should point out that the main purpose of the extension
is to view HTML source using an external editor of choice, but the author
added this little functionality almost as an afterthought, but I grabbed
ahold of it and used it for years.
--
Lynn David Newton
Columbus, Ohio
neologisticsediting.comlynndavidnewton.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hello
Is there a way configure the modline such that not only the coding
system is displayed but also the line ending convention?
thanks
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta