xslide-list — Discussion list for xslide XSL mode for Emacs

(xslide) Up and running...

[Glen P. <gl...@or...>]

Well, I have my ssh and cvs clients working.  I just merged my
indentation changes and Ville Skytt=E4's elimination of some unnesecary
cut-n-paste code.  I'm ready to plan a release and the merging of the
other patches.

Any suggestions as to when to what additional patches to include in this
release?  Should I try for as many as possible, or should I make a
release, then apply the rest of the patches?

-Glen

Re: (xslide) indentation changes

[xslide S. <xsl...@me...>]

At 12 Oct 2003 17:30 -0400, Glen Peterson wrote:
 > On Sun, 2003-10-12 at 22:15, xslide Support wrote:
 > > The stable/development model could work, but what about 'unstable'
 > > development that takes longer than one release cycle?  I haven't
 > > worked out the model for doing that with xslide as I've contemplated
 > > adding Semantic support/parsing to xslide, so I'm open to suggestions.
 > 
 > Can you add all your Semantic support/parsing in a new file and include
 > it?  That way you can minimize the changes to code that will be released

Firstly, using Semantic with xslide currently fits in the
'pie-in-the-sky' category since all I've done so far is convince
myself that I need to start with the basics and just make a set of
files that can parse XML, and after that work on parsing XSL.

Secondly, using Semantic should replace both the imenu stuff and the
font-lock stuff and should tie in to the projected ability to
add/define custom tag sets for use with xslide.  So adding Semantic
support requires major changes, not just simple additions.  Hence
adding Semantic support doesn't fit well with the 'release the current
code' development cycle that's been used so far.

Regards,


Tony Graham.

Re: (xslide) indentation changes

[Glen P. <gl...@or...>]

On Sun, 2003-10-12 at 22:15, xslide Support wrote:
> The stable/development model could work, but what about 'unstable'
> development that takes longer than one release cycle?  I haven't
> worked out the model for doing that with xslide as I've contemplated
> adding Semantic support/parsing to xslide, so I'm open to suggestions.

Can you add all your Semantic support/parsing in a new file and include
it?  That way you can minimize the changes to code that will be released
before Semantic support is done.  Ideally, you would only need to add a
"require" statement to xslide.el and maybe a couple of lines in the
keyboard command table.  Each change to xslide.el, you could surround
with something like:

(eval-and-compile
  (if semantic-support-on
    (progn
       ...)))

-Glen

Re: (xslide) indentation changes

[xslide S. <xsl...@me...>]

At 9 Oct 2003 22:57 -0400, Glen Peterson wrote:
 > I would be honored to recieve CVS access.
 > 
 > Two things about your other points:
 > 
 > 1.)  I wrote "merge", but I really meant "check-in".  I merged all my

Understood.

 > 2.)  The word "branch" always makes me nervous, because it's so easy to
...
 > I have a feeling that I am not understanding exactly what you meant. 

Considering that I hadn't thought it through in great detail, that's
not too surprising.

 > Are you saying you don't want me posting unfinished ideas as patches and

No, I'm not telling you not to post patches, I'm trying to make it
easier for everybody: you, me, and anybody who wants to pick up your
patches.

I mentioned branches because it seemed to me that you were capable of
developing and implementing ideas faster than they could be integrated
into xslide.

 > you would rather have me make temporary branches to the code base to
 > test these ideas out?  Then delete or merge each branch as we decide on
 > them as a group?  I haven't worked that way before, but it might be a
 > good idea.  I don't know.  Sure, I'll try it.
 > 
 > A lot of projects on the web have an installable "latest stable" build
 > and a "development" build with future features. GNU Emacs, XEmacs,
 > Linux, and many others follow this model.  Maybe that would meet similar
 > needs?

There's multiple development models to choose from in the Open Source
world: Gentoo Linux, for example, maintains multiple kernel
distributions.

The stable/development model could work, but what about 'unstable'
development that takes longer than one release cycle?  I haven't
worked out the model for doing that with xslide as I've contemplated
adding Semantic support/parsing to xslide, so I'm open to suggestions.

xslide is currently at version 0.2.2 and heading for 0.2.3.  Maybe
there should be a stable branch and a development branch from which
the more stable parts are added to the stable branch (and brought to
real stability before making a stable release), or maybe the
development branch is periodically declared 'stable' (and then made
stable), or maybe there should be stable and development branches and
possibly multiple pie-in-the-sky branches for developing ideas such as
Semantic support.

Regards,


Tony Graham.

Re: (xslide) indentation changes

[Glen P. <gl...@or...>]

On Thu, 2003-10-09 at 22:33, xslide Support wrote:
> At 6 Oct 2003 21:44 -0400, Glen Peterson wrote:
>  > On Fri, 2003-10-03 at 00:46, xslide Support wrote:
>  > > Yes, a separate xslide-indent.el probably does make sense now.
>  > 
>  > Would you like me to move the changes to a separate file before you
>  > merge the patch I just posted?
> 
> Thank you, yes.

OK.  I'm on it.

-Glen

Re: (xslide) indentation changes

[Glen P. <gl...@or...>]

I would be honored to recieve CVS access.

Two things about your other points:

1.)  I wrote "merge", but I really meant "check-in".  I merged all my
changes with the latest version from CVS so that you could just check-in
the file I posted on my latest patch page if you chose.  I don't think
anyone has made other changes to xslide.el since the last check-in so
that would be all there was to it.  Does that make sense?

2.)  The word "branch" always makes me nervous, because it's so easy to
branch code and so difficult to un-branch it.  To me, "branch" means
having 2 xslide, and that sounds counter-productive to me.  I don't
think we have two different directions to go in, nor do we have too many
developers for one project.  Do we?

I have a feeling that I am not understanding exactly what you meant. 
Are you saying you don't want me posting unfinished ideas as patches and
you would rather have me make temporary branches to the code base to
test these ideas out?  Then delete or merge each branch as we decide on
them as a group?  I haven't worked that way before, but it might be a
good idea.  I don't know.  Sure, I'll try it.

A lot of projects on the web have an installable "latest stable" build
and a "development" build with future features. GNU Emacs, XEmacs,
Linux, and many others follow this model.  Maybe that would meet similar
needs?

On Thu, 2003-10-09 at 22:58, xslide Support wrote:
> At 30 Sep 2003 23:03 -0400, Glen Peterson wrote:
>  > I uploaded a new version of xslide.el but found something I didn't like
>  > afterwards.  It unfairly descriminates against people who use
>  > single-quoted attributes in quick-close tags.  Please wait to merge this
>  > file until I get this problem fixed and tested.
> 
> The problem is that when it is uploaded, it's not immediately useful
> to me or to anyone else since a person has to find it and then
> download it and merge it before they can make use of it.
> 
> I should give you CVS access so you can at least make a branch so you
> can develop your ideas where people can easily get a copy and also so
> you can do some of the merging of your own (and other people's)
> patches yourself.  What do you think?
> 
> Regards,
> 
> 
> Tony Graham.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> xslide-list mailing list
> xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xslide-list
> 

Re: (xslide) indentation changes

[xslide S. <xsl...@me...>]

At 30 Sep 2003 23:03 -0400, Glen Peterson wrote:
 > I uploaded a new version of xslide.el but found something I didn't like
 > afterwards.  It unfairly descriminates against people who use
 > single-quoted attributes in quick-close tags.  Please wait to merge this
 > file until I get this problem fixed and tested.

The problem is that when it is uploaded, it's not immediately useful
to me or to anyone else since a person has to find it and then
download it and merge it before they can make use of it.

I should give you CVS access so you can at least make a branch so you
can develop your ideas where people can easily get a copy and also so
you can do some of the merging of your own (and other people's)
patches yourself.  What do you think?

Regards,


Tony Graham.

Re: (xslide) indentation changes

[xslide S. <xsl...@me...>]

At 6 Oct 2003 21:44 -0400, Glen Peterson wrote:
 > On Fri, 2003-10-03 at 00:46, xslide Support wrote:
 > > Yes, a separate xslide-indent.el probably does make sense now.
 > 
 > Would you like me to move the changes to a separate file before you
 > merge the patch I just posted?

Thank you, yes.

Regards,


Tony Graham.

Re: (xslide) indentation changes

[Glen P. <gl...@or...>]

On Fri, 2003-10-03 at 00:46, xslide Support wrote:
> Yes, a separate xslide-indent.el probably does make sense now.

Would you like me to move the changes to a separate file before you
merge the patch I just posted?

-Glen

Re: (xslide) indentation changes

[xslide S. <xsl...@me...>]

At 29 Sep 2003 12:24 -0400, Glen Peterson wrote:
 > I'm in Los Gatos, California today for a wedding, but I merged the
 > rest of my indentation changes on the plane ride out here.  I
 > forgot my transformer, and I used up the battery on the way out
 > here, so I won't be able to do any more until I get home tonight.
 > I hope to test the changes in the next week or so.

I was going to say that you should have just relaxed and not worked on
xslide, but then I admitted to myself that it's exactly the sort of
thing that I would have done.

 > There is quite a bit more indentation code than there was before
 > and it occurs to me that it might be nice to make a
 > xslide-indent.el file and put the indentation code in there instead
 > of in xslide.el.  I thought it would help modularize the code and
 > make merges and simultaneous development easier.  What do you
 > think?

Yes, a separate xslide-indent.el probably does make sense now.

Regards,


Tony Graham.

(xslide) Merge away!

[Glen P. <gl...@or...>]

I have tested my merged changes for indenting and am satisfied that they
work and do not discriminate against single or double-quoted attribute
values.  If they meet your approval, Tony, please merge them.  The patch
is at:

http://sourceforge.net/tracker/index.php?func=detail&aid=815569&group_id=22964&atid=377145

Please let us know when you are ready to make the next release so that
we can test the new merged version.

Re: (xslide) indentation changes

[Glen P. <gl...@or...>]

I uploaded a new version of xslide.el but found something I didn't like
afterwards.  It unfairly descriminates against people who use
single-quoted attributes in quick-close tags.  Please wait to merge this
file until I get this problem fixed and tested.

-Glen

(xslide) indentation changes

[Glen P. <gl...@or...>]

I'm in Los Gatos, California today for a wedding, but I merged the rest of my indentation changes on the plane ride out here.  I forgot my transformer, and I used up the battery on the way out here, so I won't be able to do any more until I get home tonight.  I hope to test the changes in the next week or so.

There is quite a bit more indentation code than there was before and it occurs to me that it might be nice to make a xslide-indent.el file and put the indentation code in there instead of in xslide.el.  I thought it would help modularize the code and make merges and simultaneous development easier.  What do you think?

-Glen

Re: (xslide) PSGML compatibility?

[xslide S. <xsl...@me...>]

At 19 Sep 2003 20:48 -0400, Glen Peterson wrote:
 > First </ is just as easy to type as C-c / and is simply brilliant.  That
 > is one of the things I like most about xslide.

It's also something that people sometimes want PSGML to do.  I usually
add it with an `xml-mode-hook`.

Of course, PSGML couldn't do that for SGML, since end-tags can
sometimes be omitted, so there's sometimes choices for what to end.

 > Second, I would like to see C-c v for Verify document.  Xalan is crummy
 > at giving good error messages.  It would be nice to be able to verify a
 > document and get a good error message from xslide.  I have a prototype
 > of this working.  Not very robust, but worth adding to.  I'll submit a
 > patch when I finish my merge.

You and I have totally opposite perspectives (and not for the first
time).  I was contemplating the usefulness of C-c C-v to run an
external XML processor for well-formedness checking, but I decided
against mentioning it in my previous mail because C-c C-p in xslide
will do that for you anyway (and more besides).  I would never have
thought to write a well-formedness checker as part of xslide.
(Actually, I am thinking of parsing it with `semantic`, but that's not
exactly the same thing.)

If Xalan gives lousy error messages, isn't the solution just to use a
different XSLT processor that does give better error messages?  C-c
C-p will populate the history with the command lines for a couple of
XSLT processors, and you can add others, so it's pretty easy to set it
up so you can alternate between Xalan and another at will.

Regards,


Tony Graham.

Re: (xslide) PSGML compatibility?

[Glen P. <gl...@or...>]

First </ is just as easy to type as C-c / and is simply brilliant.  That
is one of the things I like most about xslide.

Second, I would like to see C-c v for Verify document.  Xalan is crummy
at giving good error messages.  It would be nice to be able to verify a
document and get a good error message from xslide.  I have a prototype
of this working.  Not very robust, but worth adding to.  I'll submit a
patch when I finish my merge.

-Glen

On Fri, 2003-09-19 at 21:19, xslide Support wrote:
> C-c / would be pretty simple (after all, I do the opposite in my own
> `xml-mode-hook` setup and make PSGML close elements on '</'), but are
> there any others that are so fundamental for PSGML users?
> 
> There are plenty that I'd like to do, like 'C-c r', 'C-c =' or 'C-c
> ret', but which ones are worth putting on the To Do list?
> 
> Regards,
> 
> 
> Tony Graham.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> xslide-list mailing list
> xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xslide-list
> 

(xslide) PSGML compatibility?

[xslide S. <xsl...@me...>]

I was just pinged about xslide (not) supporting C-c / for the benefit
of those people whose fingers are hardwired to the PSGML way of
closing elements.

C-c / would be pretty simple (after all, I do the opposite in my own
`xml-mode-hook` setup and make PSGML close elements on '</'), but are
there any others that are so fundamental for PSGML users?

There are plenty that I'd like to do, like 'C-c r', 'C-c =' or 'C-c
ret', but which ones are worth putting on the To Do list?

Regards,


Tony Graham.

Re: (xslide) I'm back

[xslide S. <xsl...@me...>]

At 9 Sep 2003 21:07 -0400, Glen Peterson wrote:
 > I am enjoying this intellectual debate, but the bottom line for me is
 > still that it's a personal pain in the neck when the code doesn't
 > compile on XEmacs.  As long as making the .el files compile doesn't
 > break anything on the platform they already work on, I don't see the
 > harm.

Absolutely, the code should compile on both versions.  I'm just
advocating not sweating it over '<variable> is not known to be
defined' byte-compilation messages, etc., that are the product of the
split if they don't affect the running of the code on either version.

 > > BTW, it appears that adding "(require 'sendmail)" after the "(require
 > > 'reporter)" in `xsl-submit-bug-report` removes the need for the
 > > special handling for `mail-position-on-field`.
 > 
 > Cool!  I'll try it out.

If you wait long enough, it will be in CVS.

Actually, '-l sendmail' has been in the Makefile for a while, so
presumably XEmacs users byte-compiling using the Makefile haven't had
that problem for a while.  Adding the `require` is just another in a
continuing sequence of changes made to cater for the different ways
that people byte-compile.

Regards,


Tony Graham.

Re: (xslide) I'm back

[Glen P. <gl...@or...>]

On Tue, 2003-09-09 at 21:55, xslide Support wrote:
> It's just that I don't much like creating functions and variables that
> don't do anything just to quieten the byte-compiler just because the
> XEmacs and Emacs maintainers can't settle their differences.

I know there was a split, but I don't know anything about it and I'm not
sure I want to know.  I agree that there's no sense having two when the
only real difference between them is minor incompatibilities and bugs.  

I see it as the same type of problem as the Netscape vs. IE browser
wars.  If one's code breaks on either platform, users still blame the
code, not the browser.

It seems to me that making the code work on both versions of Emacs is
the best way we can encourage them to merge.  If you know a more
effective positive encouragement, let me know.

I am enjoying this intellectual debate, but the bottom line for me is
still that it's a personal pain in the neck when the code doesn't
compile on XEmacs.  As long as making the .el files compile doesn't
break anything on the platform they already work on, I don't see the
harm.

> BTW, it appears that adding "(require 'sendmail)" after the "(require
> 'reporter)" in `xsl-submit-bug-report` removes the need for the
> special handling for `mail-position-on-field`.

Cool!  I'll try it out.

> It's probably true that the most often implemented functions across
> all XEmacs and Emacs modes are the ones that test whether or not the
> current Emacs is FSF Emacs and whether or not the current Emacs is
> XEmacs.

Using the browser analogy, the most implemented JavaScript functions are
definitely the ones which test which browser they are running on.  I
hate it, but that's the nature of the beast.  To quote from
Stewart_Saves_His_Family, "If you can't carpet the world, wear
slippers."

> Please merge your indentation changes and provide either the full file
> or a diff (it doesn't make much difference to `ediff` either way).

Righto.

-Glen

Re: (xslide) I'm back

[xslide S. <xsl...@me...>]

At 7 Sep 2003 20:37 -0400, Glen Peterson wrote:
 > OK, great!  One point to clarify: do you want to merge my other
 > indentation fixes before or after doing a release?

Before.

 > Having byte compilation errors in the code means that I need to
 > comment and un-comment the offending lines between building and
 > diffing when I prepare a patch or a version to commit to CVS.
 > Since that usually takes between 3 and 30 iterations, that's a lot
 > of times to remember to comment and uncomment a few lines.  So I
 > fixed them.  I tested the fixes on XEmacs and GNU, Windows and
 > Linux and they work everywhere.  Also, compiling without errors is
 > part of what separates professional quality software from something
 > that was thrown together in someone's spare time.  I know we're all
 > doing this in our spare time, but I don't want it to LOOK that way.
 > It's a quality perception thing for me.

The whole XEmacs/Emacs split is hardly the result of professional
behaviour on several people's part.

It's just that I don't much like creating functions and variables that
don't do anything just to quieten the byte-compiler just because the
XEmacs and Emacs maintainers can't settle their differences.

BTW, it appears that adding "(require 'sendmail)" after the "(require
'reporter)" in `xsl-submit-bug-report` removes the need for the
special handling for `mail-position-on-field`.

It's probably true that the most often implemented functions across
all XEmacs and Emacs modes are the ones that test whether or not the
current Emacs is FSF Emacs and whether or not the current Emacs is
XEmacs.

 > In terms of the lengthy comments, I can probably abbreviate them if
 > you like.

If it needs to be said, then it should be said somewhere, hence the
texinfo move.  BTW, I've now found the docbook2x SourceForge project,
but have yet to try it out since my Internet connection is currently
in use downloading today's collection of spam (800 messages so far).

 > What is the prefix argument for xsl-electric-delete you were
 > talking about?

I should have said `xsl-delete`.  Ordinarily, M-8 <delete> deletes 8
characters, but right now, from CVS, M-8 <delete> in `xsl-mode`
deletes one character.  The prefix arg ('8' in this case) should be
passed to the appropriate function.  Actually, it should set both
arguments of the appropriate function.  It's about a five minute fix.

 > I'm glad to hear that your mail is working now.  Thanks for doing
 > the CVS commits, Tony.  Let me know what to do next: test for a
 > release, or merge the rest of my indentation changes.

Please merge your indentation changes and provide either the full file
or a diff (it doesn't make much difference to `ediff` either way).

Regards,


Tony Graham.

Re: (xslide) I'm back

[Glen P. <gl...@or...>]

OK, great!  One point to clarify: do you want to merge my other indentation fixes before or after doing a release?

Having byte compilation errors in the code means that I need to comment and un-comment the offending lines between building and diffing when I prepare a patch or a version to commit to CVS.  Since that usually takes between 3 and 30 iterations, that's a lot of times to remember to comment and uncomment a few lines.  So I fixed them.  I tested the fixes on XEmacs and GNU, Windows and Linux and they work everywhere.  Also, compiling without errors is part of what separates professional quality software from something that was thrown together in someone's spare time.  I know we're all doing this in our spare time, but I don't want it to LOOK that way.  It's a quality perception thing for me.

In terms of the lengthy comments, I can probably abbreviate them if you like.

What is the prefix argument for xsl-electric-delete you were talking about?

I'm glad to hear that your mail is working now.  Thanks for doing the CVS commits, Tony.  Let me know what to do next: test for a release, or merge the rest of my indentation changes.

-Glen

---- xslide Support <xsl...@me...> wrote:
> Glen,
> 
> At 7 Sep 2003 00:29 -0400, Glen Peterson wrote:
>  > Cool!  xslide now supports spaces and tabs!  Wohoo!  Thank you.
>  > You have made me very happy.
> 
> That's good to hear.
> 
> The reason that I said I'd looked at doing an Info file for xslide is
> that some of your comments are more than you'd want to read if you did
> 'C-h v' on some of those variables.  The full comments are in the CVS
> version since I don't want to trim them until there's somewhere else
> to put the detailed information.
> 
> Also, I still want to persuade you that it is okay to have
> byte-compilation errors because of XEmacs/Emacs differences.  As it
> is, some of the XEmacs/Emacs stuff that I put in long ago is on
> borrowed time since I understand from the Speedbar (I think)
> documentation that recent versions of XEmacs come with `imenu` and it
> may be time to say that xslide only supports XEmacs versions starting
> from the first one that has `imenu` as standard.
> 
> Also, I need to fix `xsl-electric-delete` so it accepts a prefix
> argument.
> 
>  > Next:
>  > 
>  > 1.) Are you interested in merging my indentation fixes for
>  > comments, cdata, and text sections?  This is the indentation fix
> 
> Yes.
> 
>  > that someone on the list (was it adrian?) complimented last week
>  > because it fixed the problem he was having (tags in comments and
>  > cdata sections messed up subsequent indenting and repeated
>  > indent-regions messed up multi-line comments).  I was concerned
>  > that this patch might be slow, but the user who tried it said it
>  > actually seemed a little faster.  I can forward you his email if
>  > you lost it.
> 
> I can look it up in the archive.  I did see some of the thread when I
> was viewing mail online from my webhost's web-based reader, but the
> messages never made it to my computer.
> 
>  > 2.) What about my auto-completion enhancements?  Are you interested
>  > in merging them?  Should we merge them at the same time as the
>  > indentation fixes in #1 or do them separately?  Do you want them
>  > reworked to use data structures instead of being hard-coded before
>  > merging them or can we do that after?
> 
> At this point, I'd prefer to do the auto-completion separately after
> making a release containing the indentation fixes.
> 
> Regards,
> 
> 
> Tony.

---
Glen Peterson
Senior Software Engineer, Web Consultant
South Hamilton, MA USA

(xslide) I'm back

[xslide S. <xsl...@me...>]

After a couple of week of mail trouble, I've had my backlog cleared
for me by my computer spontaneously deleting about 1400 messages from
my POP server.  They would have been 99.5% spam anyway, but if you've
sent my anything since August 24 that you want me to see, you'd better
send it again.

xslide's status is that I've checked in Glen Peterson's indent patch
plus a one-line patch from Ville Skytta.  I did look at starting an
Info file for xslide, but one look at the texinfo format convinced me
that it's more than I want to grapple with right now.  Does anybody
know of a DocBook to texinfo converter?

Regards,


Tony Graham.

Re: Fwd: (xslide) Using XSlide for XML rather than XSL editing?

[Aaron W. <aa...@xi...>]

Glen:

  Sweet! It works great.  It also seems to be faster-- not sure if
that's due to optimization in your code, or me byte-compiling things, or
what, but it definitely seems snappier.  Thanks! (GNU emacs 21.2, for
what it's worth, on RH8).

Yours,
Aaron.

On Thu, 2003-08-28 at 20:23, Glen Peterson wrote:

> Aaron,
> 
> I have this fixed in a patch that we are working on merging into the tree right now.  Until then, you can try it out at (one line):
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=742946&group_id=22964&atid=377145
> 
> Choose: glensChanges2003-08-28.tar.gz
> 
> You should be able to just unzip it over your existing xslide (assuming you have the latest version).  You can use my previous patch with earlier versions of xslide.
> b
> ----------
> From: Aaron Weber <aa...@xi...>
> Date: Thu, 28 Aug 2003 14:44:01 -0400
> To: xsl...@li...
> Subject: (xslide) Using XSlide for XML rather than XSL editing?
> 
> Hello,
>   I've been using XSlide for XML (DocBook) editing rather than XSL
> editing-- it seems to do quite well in most cases, but for very large
> files it slows down quite a bit. I imagine this isn't really an issue
> with XSL files, since they tend to be fewer than 1000 lines or so. And
> of course the indenting is a little weird on things that don't tend to
> appear in XSL:
> 
>   <para>
>       A paragraph with a <command>short tag</command> in it
>       will break indenting because the close-tag will move 
>   out a level like this, even though the open-tag didn't go
>   in a level.
> </para>
> 
> Should I be using some other Emacs tool for this? (The XML mode doesn't
> do indenting as well as I'd like it to, especially when I have several
> files that are included rather than freetanding, and therefore don't
> begin with a DTD).  If XSlide is the correct tool for this job, can you
> give me pointers on how to make the indenting do what I mean? ;)
> 
> Thanks in advance, and thanks for XSlide! It's great.
> 
> a.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> xslide-list mailing list
> xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xslide-list
> 
> 
> ---
> Glen Peterson
> Senior Software Engineer, Web Consultant
> South Hamilton, MA USA
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> xslide-list mailing list
> xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xslide-list
> 

Fwd: (xslide) Using XSlide for XML rather than XSL editing?

[Glen P. <gl...@or...>]

Aaron,

I have this fixed in a patch that we are working on merging into the tree right now.  Until then, you can try it out at (one line):

http://sourceforge.net/tracker/index.php?func=detail&aid=742946&group_id=22964&atid=377145

Choose: glensChanges2003-08-28.tar.gz

You should be able to just unzip it over your existing xslide (assuming you have the latest version).  You can use my previous patch with earlier versions of xslide.
b
----------
From: Aaron Weber <aa...@xi...>
Date: Thu, 28 Aug 2003 14:44:01 -0400
To: xsl...@li...
Subject: (xslide) Using XSlide for XML rather than XSL editing?

Hello,
  I've been using XSlide for XML (DocBook) editing rather than XSL
editing-- it seems to do quite well in most cases, but for very large
files it slows down quite a bit. I imagine this isn't really an issue
with XSL files, since they tend to be fewer than 1000 lines or so. And
of course the indenting is a little weird on things that don't tend to
appear in XSL:

  <para>
      A paragraph with a <command>short tag</command> in it
      will break indenting because the close-tag will move 
  out a level like this, even though the open-tag didn't go
  in a level.
</para>

Should I be using some other Emacs tool for this? (The XML mode doesn't
do indenting as well as I'd like it to, especially when I have several
files that are included rather than freetanding, and therefore don't
begin with a DTD).  If XSlide is the correct tool for this job, can you
give me pointers on how to make the indenting do what I mean? ;)

Thanks in advance, and thanks for XSlide! It's great.

a.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
xslide-list mailing list
xsl...@li...
https://lists.sourceforge.net/lists/listinfo/xslide-list


---
Glen Peterson
Senior Software Engineer, Web Consultant
South Hamilton, MA USA

(xslide) Using XSlide for XML rather than XSL editing?

[Aaron W. <aa...@xi...>]

Hello,
  I've been using XSlide for XML (DocBook) editing rather than XSL
editing-- it seems to do quite well in most cases, but for very large
files it slows down quite a bit. I imagine this isn't really an issue
with XSL files, since they tend to be fewer than 1000 lines or so. And
of course the indenting is a little weird on things that don't tend to
appear in XSL:

  <para>
      A paragraph with a <command>short tag</command> in it
      will break indenting because the close-tag will move 
  out a level like this, even though the open-tag didn't go
  in a level.
</para>

Should I be using some other Emacs tool for this? (The XML mode doesn't
do indenting as well as I'd like it to, especially when I have several
files that are included rather than freetanding, and therefore don't
begin with a DTD).  If XSlide is the correct tool for this job, can you
give me pointers on how to make the indenting do what I mean? ;)

Thanks in advance, and thanks for XSlide! It's great.

a.

(xslide) [Fwd: Re: progress]

[Glen P. <gl...@or...>]

"Tabs vs. Spaces" changes are ready for merging:

http://sourceforge.net/tracker/?func=detail&aid=788471&group_id=22964&atid=377145

I believe I also fixed the XEmacs compilation errors.  I wrote a book of
comments in the code.  The really big section where I explain the theory
behind the way indent-to is used might be better posted to this list
than stuck in the code.  Or maybe both places.  Here it is:

  ; NOTES ON INDENT-TO: (an epic comment by Glen Peterson)
  ; ======================================================
  ; indent-tabs-mode: if nil, spaces only.
  ;                   if t, indent-line converts tab-width groups of
  ;                   spaces to tabs.
  ; tab-width: controls how many spaces to convert to a tab, or how
  ;            many spaces to insert for each indentation step.
  ; tab-stops-list: controls how tabs actually display on the screen.
  ;
  ; Spaces mode just works.  In tabs-mode, if tab-stops-list and
  ; tab-width do not match it will indent one way and display another
  ; creating a mess.  We will avoid this by calculating tab-stop-list
  ; to be in multiples of tab-width (Tony Grahm's excellent idea).
  ;
  ; Sometimes, files are indented with a combination of tabs and
  ; spaces - usually because the author's tab-width is not the same as
  ; the indent-step width.  Although these files are more challenging
  ; to display than ones using pure spaces or pure tabs, a user can
  ; still display these files as the author saw them by viewing them
  ; in spaces-mode with the same tab-width setting as the author (the
  ; user must figure this out, but it's usually 8)
  ; 
  ; Since many editors make a mess of displaying files with mixed tabs
  ; and spaces, we will endeavor not to create any xsl files of that
  ; sort.  Users who are particular about indentation will want to
  ; convert existing files to all tabs or all spaces anyway.  In
  ; spaces mode, we must indent using only spaces so that the file is
  ; guaranteed to look the same on all machines.  In tabs mode, we
  ; should try to indent using only tabs so that the file will appear
  ; indented using the viewer's preferred indentation step size.
  ;
  ; The one xsl exception to using tabs exclusively in tabs mode is
  ; for indenting attributes in multi-line tags.  In order for
  ; pretty-print indented attributes to look right in tabs-mode
  ; regardless of tab-width we must:
  ;
  ; - indent to the proper indentation depth of the element using tabs
  ;
  ; - indent from the start of the element to the start of the
  ;   attribute using spaces.
  ;
  ; - indent subsequent lines using only tabs
  ;
  ; For example:
  ;
  ; tab<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  ; tab................version="1.0"
  ; tab................xmlns:java="http://xml.apache.org/xslt/java">
  ; tabtab<xsl:output method="html" />
  ;
  ; For simplicity, we could indent attributes by two indentation
  ; steps instead of pretty-printing them below the first attribute.
  ; For now, I have ignored this issue altogether since it could be
  ; done manually by tabbers the few times they use multiple lines for
  ; long tags.

I put a bunch of end-user documentation in the custom variables
themselves:

(defcustom xsl-tab-width 2
  "Sets the indentation step size on entering xsl-mode.

You must run M-x xsl-mode (or just reload your xsl file) before
changing this variable will take effect.

If undefined, this variable will inherit its value from tab-width (or
from xsl-element-indent-step for backward compatibility if it is
defined).

If `xsl-indent-tabs-mode' is Spaces (nil), this controls the number of
spaces to insert for each indentation level.

If `xsl-indent-tabs-mode' is Tabs (t), this controls the width of the
tab stops for this buffer.

Consider using the same setting for this variable as those you work
with - regardless of your personal preference.

If you defined `xsl-element-indent-step' in your dot emacs file (for
an older version of xslide), please remove it since it is no longer
used (since 0.2.3).  Use xsl-tab-width instead."

  :type '(choice (const :tag "nil" nil)
                 (integer))
  :group 'xsl)

(defcustom xsl-indent-tabs-mode nil
  "Whether to indent using tabs or spaces.

You must run M-x xsl-mode (or just reload your xsl file) before
changing this variable will take effect.

To summarize:
  1.) Files indented with spaces will always look the same on every
      machine.  This feature is the main argument for using spaces.

  2.) Files indented with tabs will show up with each users preferred
      tab width on their machine if they have xsl-indent-tabs-mode set
      to Tabs (t).  This feature and a slightly reduced file size are
      the main arguments for using tabs.

  3.) For files indented with tabs and spaces, set
      xsl-indent-tabs-mode to Spaces (nil) and adjust xsl-tab-width
      until it matches the author's tab-width.  Try 8 because it's a
      common default.  Then issue M-x xsl-mode.

Consider using the same setting for this variable as those you work
with - regardless of your personal preference.

If `xsl-indent-tabs-mode' is Tabs (t), xslide makes a buffer-local
copy of tab-stop-list based on xsl-tab-width.  Your global
tab-stop-list will be ignored."

  :type '(choice (const :tag "Spaces" nil)
                 (const :tag "Tabs" t))
  :group 'xsl)

-----Forwarded Message-----

> From: xslide Support <xsl...@me...>
> To: Glen Peterson <gl...@or...>
> Subject: Re: progress
> Date: 12 Aug 2003 23:57:50 -0400
> 
> At 10 Aug 2003 14:00 -0400, Glen Peterson wrote:
>  > I have implemented my tabs-mode changes, plus some of the tabs
>  > vs. spaces enhancements we talked about.  I also pretty-print
>  > indented xsl-if-to-choose and all my new code.  I think you'll like
>  > it.  I just need to test it on XEmacs/Linux and GNU emacs, but I'm
>  > tired now and may not get to it until next weekend.
> 
> As I have said before, don't sweat it.  Do it as you have the time,
> but there's no deadline involved.
> 
>  > Oh yeah, I tried another trick to get xslide to compile without
>  > errors or warnings on my machine.  I'll let you know if it
>  > withstands the testing.
> 
> Having looked at both the VM and Mew mail readers recently and seen
> that they both say to ignore any byte-compilation error messages, I
> think it is sufficient for the xslide documentation to also say to
> ignore byte-compilation error messages (provided the thing works after
> it's been byte-compiled, that is).
> 
>  > After testing, I'll submit a patch with version number and
>  > ChangeLog comments updated.  I know it's tough to merge too much at
>  > once, so I'm not going to merge my other changes until tabs
>  > vs. spaces is checked in.
> 
> Thanks.  I look forward to seeing your changes.
> 
> Regards,
> 
> 
> Tony Graham.