2:49 a.m.
Check out table-editing mode from http://table.sourceforge.net/. This
is really cool, but it does have problems with XEmacs.
The mode uses variable 'enable-multibyte-characters'. In XEmacs 21.2
this used to be an internal Emacs compatibility variable set to nil.
XEmacs 21.4 does not have it.
Q: Should we add this variable, or should table.el be modified not to
depend on it (it works fine if you bind it to nil)?
Gleb
PS It would be nice to see this added to one of the packages (even if
it is buggy with XEmacs for now)
8:06 a.m.
>>>> "Gleb" == Gleb Arshinov
<gleb(a)barsook.com> writes:
Gleb> The mode uses variable 'enable-multibyte-characters'. In
Gleb> XEmacs 21.2 this used to be an internal Emacs compatibility
Gleb> variable set to nil. XEmacs 21.4 does not have it.
If you want Emacs compatibility in this respect, just build
--with-file-coding or --with-mule.
Gleb> Q: Should we add this variable, or should table.el be
Gleb> modified not to depend on it (it works fine if you bind it
Gleb> to nil)?
It would be preferable for table.el to be fixed. That variable is an
abomination.
However, the easiest thing would be to add
(unless (intern-soft "enable-multibyte-characters")
(defvar enable-multibyte-characters nil
"Use of this variable causes text to dissolve or spontaneously combust!"))
As for packaging this library, sounds like a great idea. Go right ahead. :-)
Seriously, Ville, Rendhalver, Steve Y, and I would be happy to help,
but if you do it (asking questions as you go along) it will probably
happen a lot sooner than if you wait on us to do it.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
6:29 p.m.
On Sat, 2002-08-10 at 10:06, Stephen J. Turnbull wrote:
>>>>> "Gleb" == Gleb Arshinov
<gleb(a)barsook.com> writes:
Gleb> The mode uses variable 'enable-multibyte-characters'. In
Gleb> XEmacs 21.2 this used to be an internal Emacs compatibility
Gleb> variable set to nil. XEmacs 21.4 does not have it.
If you want Emacs compatibility in this respect, just build
--with-file-coding or --with-mule.
Gleb> Q: Should we add this variable, or should table.el be
Gleb> modified not to depend on it (it works fine if you bind it
Gleb> to nil)?
It would be preferable for table.el to be fixed. That variable is an
abomination.
However, the easiest thing would be to add
(unless (intern-soft "enable-multibyte-characters")
(defvar enable-multibyte-characters nil
"Use of this variable causes text to dissolve or spontaneously combust!"))
...into table.el, I suppose?
As for packaging this library, sounds like a great idea. Go right
ahead. :-)
Seriously, Ville, Rendhalver, Steve Y, and I would be happy to help,
but if you do it (asking questions as you go along) it will probably
happen a lot sooner than if you wait on us to do it.
Actually, I've also tried out table.el before, and adding it to a
package is on my TODO list (I've had it around in my package tree for
some months). It just got bumped upwards in the list...
edit-utils or text-modes? I think I'd prefer edit-utils. ISTR table.el
needs at least the fsf-compat and pc packages to work.
--
\/ille Skyttä
ville.skytta at xemacs.org
8:17 p.m.
On Sun, 2002-08-11 at 20:29, Ville Skyttä wrote:
> As for packaging this library, sounds like a great idea. Go
right ahead. :-)
>
> Seriously, Ville, Rendhalver, Steve Y, and I would be happy to help,
> but if you do it (asking questions as you go along) it will probably
> happen a lot sooner than if you wait on us to do it.
Actually, I've also tried out table.el before, and adding it to a
package is on my TODO list (I've had it around in my package tree for
some months). It just got bumped upwards in the list...
edit-utils or text-modes? I think I'd prefer edit-utils. ISTR table.el
needs at least the fsf-compat and pc packages to work.
D'oh, I can't make up my mind. Now I feel it would be better to put it
in text-modes. Opinions welcome.
--
\/ille Skyttä
ville.skytta at xemacs.org
11:13 p.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
> Actually, I've also tried out table.el before, and adding it
to
> a package is on my TODO list (I've had it around in my package
> tree for some months). It just got bumped upwards in the
> list...
Cool!
> edit-utils or text-modes? I think I'd prefer edit-utils.
ISTR
> table.el needs at least the fsf-compat and pc packages to work.
Ville> D'oh, I can't make up my mind. Now I feel it would be
Ville> better to put it in text-modes. Opinions welcome.
I looked at current contents of these packages, and text-modes seems
like a marginally better fit.
Gleb
7:14 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
On Sat, 2002-08-10 at 10:06, Stephen J. Turnbull wrote:
> However, the easiest thing would be to add
> (unless (intern-soft "enable-multibyte-characters")
(defvar
> enable-multibyte-characters nil "Use of this variable causes
> text to dissolve or spontaneously combust!"))
Ville> ...into table.el, I suppose?
Yes.
Ville> edit-utils or text-modes? I think I'd prefer edit-utils.
Ville> ISTR table.el needs at least the fsf-compat and pc packages
Ville> to work.
There's no real reason why a single file can't be a separate package;
finer division would help with tuning dependencies. The original
reason for packages consisting of multiple more-or-less independent
libraries was that Steve Baur didn't have time to split up more
finely, and the XEmacs team was responsible for more packages then.
It's up to you now, but I thought you'd appreciate the historical
background for the current arrangement.
If you do put it into one of the existing packages, it would be a good
idea to add a one-line blurb saying where table.el is found to
man/xemacs/packages.texi.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
7:43 p.m.
Okay, I've played around with table.el somewhat, and seems that it
doesn't indeed work too well in XEmacs.
I've sent messages upstream describing the problems along with a patch
containing a couple of trivial fixes, and including Stephen's workaround
for enable-multibyte-characters. The messages should appear at
<http://sourceforge.net/mailarchive/forum.php?forum_id=3866> sometime.
The list doesn't seem to be too active, though :(
Anyway, I don't think table.el works well enough in XEmacs to be
included in packages ATM. Let's see if someone picks it up and fixes
the bugs, I'd be happy to include it when it Works.
On Tue, 2002-08-13 at 09:14, Stephen J. Turnbull wrote:
>> However, the easiest thing would be to add
>> (unless (intern-soft "enable-multibyte-characters") (defvar
>> enable-multibyte-characters nil "Use of this variable causes
>> text to dissolve or spontaneously combust!"))
Ville> ...into table.el, I suppose?
Yes.
Okay...
Ville> edit-utils or text-modes? I think I'd prefer
edit-utils.
Ville> ISTR table.el needs at least the fsf-compat and pc packages
Ville> to work.
There's no real reason why a single file can't be a separate package;
finer division would help with tuning dependencies. The original
reason for packages consisting of multiple more-or-less independent
libraries was that Steve Baur didn't have time to split up more
finely, and the XEmacs team was responsible for more packages then.
It's up to you now, but I thought you'd appreciate the historical
background for the current arrangement.
I do. I'm also ready to work on finer division of the packages, but I
think pui wouldn't work too well with lots of packages the way it is
now. ISTR Steve Y said something about working on it in The Future,
hierarchical view or something like that?
So, for table.el, it'll be text-modes after the bugs have been fixed.
If you do put it into one of the existing packages, it would be a
good
idea to add a one-line blurb saying where table.el is found to
man/xemacs/packages.texi.
Hmm, IMO it would be better to keep it the way it is; to list only whole
packages. Or to do a major update there, expanding it to contain more
(all?) stuff in the single-file packages too.
--
\/ille Skyttä
ville.skytta at xemacs.org
1:56 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> I've sent messages upstream describing the problems along
Ville> with a patch containing a couple of trivial fixes, and
Ville> including Stephen's workaround for
Ville> enable-multibyte-characters. The messages should appear at
Ville> <http://sourceforge.net/mailarchive/forum.php?forum_id=3866>
Ville> sometime. The list doesn't seem to be too active, though
Ville> :(
Ville,
The message is still not there. Could you post it here?
Thanks,
Gleb
11:14 a.m.
On Sat, 2002-08-17 at 03:56, Gleb Arshinov wrote:
The message is still not there. Could you post it here?
Yep, here it goes.
----
Hello,
I've been asked to add table.el into one of the XEmacs packages, and
having played around with it a bit in XEmacs, I see (as the notes say)
there are some problems.
We've worked around a couple of problems, see the attached patch.
At least one showstopper remains, let me try to describe it.
When I have inserted a table into a buffer, I poke around and type some
characters *into* the top border (the line with the +-----+------
stuff), then move into a cell, and type some more. Now, when the table
tries to resize itself, I get (after setting debug-on-error to t):
Signaling: (wrong-type-argument number-char-or-marker-p nil)
table--put-property(nil table-justify nil)
table--put-cell-justify-property(nil nil)
table--put-cell-property(nil)
table--update-cell(now)
I'd appreciate it if this could be fixed so I could continue the process
of distributing table.el with XEmacs. I have no idea whether it works
this way in GNU Emacs too, I'm using XEmacs 21.4.8.
--- table-1.5.53.el Wed Aug 14 20:57:03 2002
+++ table.el Wed Aug 14 21:16:25 2002
＠＠ -789,6 +789,11 ＠＠
"Clear quail-translating after its use."
(setq quail-translating nil)))
+;; XEmacs addition
+(unless (intern-soft "enable-multibyte-characters")
+ (defvar enable-multibyte-characters nil
+ "Use of this variable causes text to dissolve or spontaneously combust!"))
+
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;
;;; Customization:
＠＠ -1563,7 +1568,10 ＠＠
(if table-inhibit-advice ad-do-it
(let* ((table-inhibit-advice t)
(table-inhibit-update t)
- (deactivate-mark nil))
+ ;; XEmacs change: Commented out to avoid a warning,
+ ;; we don't need this.
+ ;(deactivate-mark nil)
+ )
(if (null (table--point-in-cell-p)) ad-do-it
(table--finish-delayed-tasks)
(table-recognize-cell 'force)
＠＠ -5376,6 +5384,9 ＠＠
;; return the result
internal-list))))
+;; XEmacs addition: This autoload is needed in order to make `table-insert'
+;; work without having to (require 'table) in init.el.
+;;;###autoload
(defun table--point-in-cell-p (&optional location)
"Return t when point is in a valid table cell in the current buffer.
When optional LOCATION is provided the test is performed at that location."
--
\/ille Skyttä
ville.skytta at xemacs.org
3:40 a.m.
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
SJT> If you do put it into one of the existing packages, it would be
SJT> a good idea to add a one-line blurb saying where table.el is
SJT> found to man/xemacs/packages.texi.
I'd strongly recommend *against* doing this...
find ./xemacs-packages/ ./mule-packages/ -name "*.el" | wc -l
1708
And I would imagine that a fairly high percentage of those could
possibly fall into the same "one-line blurb in texinfo" category.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
6:52 a.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
> --==> "SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> If you do put it into one of the existing packages, it would
SJT> be a good idea to add a one-line blurb saying where table.el
SJT> is found to man/xemacs/packages.texi.
SY> I'd strongly recommend *against* doing this...
SY> find ./xemacs-packages/ ./mule-packages/ -name "*.el" | wc -l
SY> 1708
Uh, yes? So what? Package listings that are pretty damn useless for
identifying what's in them is not a design goal I ever heard about.
Not to mention a FAQ.
Remember, Steve B's original intent was to split all independent
functionality into separate packages. This proposal is a halfway
house that allows somebody who hasn't spent the last 3 years
maintaining the package hierarchy to find out what's in there, and
where, without imposing all that crap on (a) the pui display or (b)
the XPRE.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
6:33 p.m.
On Tue, 2002-08-20 at 08:52, Stephen J. Turnbull wrote:
SJT> If you do put it into one of the existing packages, it
would
SJT> be a good idea to add a one-line blurb saying where table.el
SJT> is found to man/xemacs/packages.texi.
SY> I'd strongly recommend *against* doing this...
SY> find ./xemacs-packages/ ./mule-packages/ -name "*.el" | wc -l
SY> 1708
Uh, yes? So what? Package listings that are pretty damn useless for
identifying what's in them is not a design goal I ever heard about.
Not to mention a FAQ.
Yep, but IMO man/xemacs/packages.texi isn't the correct place for them,
because packages change. Not that often, but they do. Instead, leaving
it the way it is now, and adding a blurb like "For up to date
information, please consult the detailed packages listing at
<http://www.xemacs.org/......>." (The blurb might already be there,
haven't checked.) Having only one thing to update would at least make
my and Rendhalver's lives easier :)
I'm already (slowly) working on a comprehensive package listing, which
would include the descriptions, authors/maintainers (both XEmacs and
upstream) and URLs (along with the information already at [1]).
And this would not only be for regular packages, but all the stuff
inside single-file packages too. IMO, placing this on the website would
be the way to go.
Hmm, actually, the bunch of package descriptions could be a downloadable
package... what do you think?
[1] <http://www.xemacs.org/Develop/packages.html>
--
\/ille Skyttä
ville.skytta at xemacs.org
3:49 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Tue, 2002-08-20 at 08:52, Stephen J. Turnbull wrote:
SJT> If you do put it into one of the existing packages, it would
SJT> be a good idea to add a one-line blurb saying where table.el
SJT> is found to man/xemacs/packages.texi.
>
SY> I'd strongly recommend *against* doing
this...
>
SY> find ./xemacs-packages/ ./mule-packages/ -name
"*.el" | wc -l
>
SY> 1708
>
>> Uh, yes? So what? Package listings that are
pretty damn useless for
>> identifying what's in them is not a design goal I ever heard about.
>> Not to mention a FAQ.
Ville> Yep, but IMO man/xemacs/packages.texi isn't the correct place for them,
Ville> because packages change. Not that often, but they do. Instead, leaving
Ville> it the way it is now, and adding a blurb like "For up to date
Ville> information, please consult the detailed packages listing at
Ville> <http://www.xemacs.org/......>." (The blurb might already be
there,
Ville> haven't checked.) Having only one thing to update would at least make
Ville> my and Rendhalver's lives easier :)
brilliant plan ville :)
i am all for lazyness in its purest form
(thanks for accepting the name change BTW make me happy)
Ville> I'm already (slowly) working on a comprehensive package listing, which
Ville> would include the descriptions, authors/maintainers (both XEmacs and
Ville> upstream) and URLs (along with the information already at [1]).
Ville> And this would not only be for regular packages, but all the stuff
Ville> inside single-file packages too. IMO, placing this on the website would
Ville> be the way to go.
excellent how far have you got ??
need some help ??
Ville> Hmm, actually, the bunch of package descriptions could be a downloadable
Ville> package... what do you think?
yes defiantly
Ville> [1] <http://www.xemacs.org/Develop/packages.html>
Ville> --
Ville> \/ille Skyttä
Ville> ville.skytta at xemacs.org
--
XEmacs Advocate | Do not try the patience of Wizards,
FreeBSD Devote | for they are subtle and quick to anger.
Perl Hacker | - Elric (Technomage) , Babylon 5.
Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>
7:49 a.m.
On Wed, 2002-08-21 at 05:49, Rendhalver [Peter Brown] wrote:
(thanks for accepting the name change BTW make me happy)
You're welcome :)
Ville> I'm already (slowly) working on a comprehensive
package listing, which
Ville> would include the descriptions, authors/maintainers (both XEmacs and
Ville> upstream) and URLs (along with the information already at [1]).
Ville> And this would not only be for regular packages, but all the stuff
Ville> inside single-file packages too. IMO, placing this on the website would
Ville> be the way to go.
excellent how far have you got ??
need some help ??
Yep, that would be welcome. I've stuck the list, based on one Steve Y
sent me a while ago to CVS, see packages/unsupported/scop/packages.txt,
feel free to update it. Thanks!
--
\/ille Skyttä
ville.skytta at xemacs.org
1:16 p.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> On Wed, 2002-08-21 at 05:49, Rendhalver [Peter Brown] wrote:
> (thanks for accepting the name change BTW make me happy)
Ville> You're welcome :)
Ville> I'm already (slowly) working on a comprehensive package listing, which
Ville> would include the descriptions, authors/maintainers (both XEmacs and
Ville> upstream) and URLs (along with the information already at [1]).
Ville> And this would not only be for regular packages, but all the stuff
Ville> inside single-file packages too. IMO, placing this on the website would
Ville> be the way to go.
>
> excellent how far have you got ??
> need some help ??
Ville> Yep, that would be welcome. I've stuck the list, based on one Steve Y
Ville> sent me a while ago to CVS, see packages/unsupported/scop/packages.txt,
Ville> feel free to update it. Thanks!
cool i will have a look and see if there is anything i can help with
--
XEmacs Advocate | Do not try the patience of Wizards,
FreeBSD Devote | for they are subtle and quick to anger.
Perl Hacker | - Elric (Technomage) , Babylon 5.
Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>
7:25 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> Having only one thing to update would at least make my and
Ville> Rendhalver's lives easier :)
Please arrange it so that there is only one thing to update. Texinfo
would make it easy for me to download, overwrite
man/xemacs/package-list.texi, commit, and release. But anything which
could easily be autobogotified into texi is fine (as long as you don't
tinker with it ;-).
Ville> IMO, placing this on the website would be the way to go.
Of course it should be on the website. But it should be directly
accessible from a buck-naked XEmacs as well.
Ville> Hmm, actually, the bunch of package descriptions could be a
Ville> downloadable package... what do you think?
That's a _really_ good idea, better than a texi file to put into
man/xemacs. We'll put it into the bootstrap packages that I'm
planning to put into the core distro (EFS, xemacs-base, etc).
(Maintained in the packages hierarchy, but distributed with and
installed from the core for bootstrap purposes.)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
7926
days inactive
7937
days old
15 comments
5 participants
participants (5)
-
Gleb Arshinov -
Rendhalver [Peter Brown] -
Stephen J. Turnbull -
Steve Youngs -
Ville Skyttä