At 31 May 2003 09:47 +0100, Colin Paul Adams wrote:
> The problem with indentation following an empty tag has now been
> corrected, but I've discovered another one - mixed content:
Well, the rationale for 0.2.1 is as a base for adding fixes from
submitted patches, and there's indentation fixes in both Glen
Petersen's ongoing work and the xslide.el from Steven J. Owens that I
posted as a patch on SourceForge.
The next step would be to try out Glen's improvements, since they're
under active development and since Glen is on this list and can
respond to comments.
Regards,
Tony Graham.

The problem with indentation following an empty tag has now been
corrected, but I've discovered another one - mixed content:
Here's how xslide indents this:
<fred>tom
<jim/>
<susan></susan>
</fred>
If you remove tom, then it indents correctly.
--
Colin Paul Adams
Preston Lancashire

At 30 May 2003 18:18 +0100, Colin Paul Adams wrote:
> >>>>> "xslide" == xslide Support <xslide-bug@...> writes:
>
> xslide> How do people go about byte-compiling xslide? Colin Paul
> xslide> Adams just posted on the xsl-list about the bug he posted
>
> Sorry about that, I thought I was posting to this list!
I did run the xsl-list, but that was a while ago.
> xslide> My assumption, which, it seems, is frequently wrong, is
> xslide> that people will use the provided Makefile to byte-compile
> xslide> xslide from the command line.
>
> I just typed:
>
> make
>
> and got no error messages.
>
> The errors only came when emacs processed my .emacs file.
>
> So should I go ahead and produce the pathces?
I don't understand what your .emacs file is trying to do.
What do you have in your .emacs w.r.t. xslide?
The problem appears to be that you're loading xlide-abbrev.el ahead of
xslide.el.
xslide is set up so that xslide.el loads the other modules, and the
other modules don't necessarily know about each other.
The question is, is it a problem that xslide's set up this way, or is
it a problem that your .emacs does things in alphabetical order?
Regards,
Tony Graham.

>>>>> "xslide" == xslide Support <xslide-bug@...> writes:
xslide> How do people go about byte-compiling xslide? Colin Paul
xslide> Adams just posted on the xsl-list about the bug he posted
Sorry about that, I thought I was posting to this list!
xslide> My assumption, which, it seems, is frequently wrong, is
xslide> that people will use the provided Makefile to byte-compile
xslide> xslide from the command line.
I just typed:
make
and got no error messages.
The errors only came when emacs processed my .emacs file.
So should I go ahead and produce the pathces?
--
Colin Paul Adams
Preston Lancashire

How do people go about byte-compiling xslide?
Colin Paul Adams just posted on the xsl-list about the bug he posted
to xslide-bug@... about byte-compiling xslide 0.2:
At 10 Apr 2003 07:44 +0100, Colin Paul Adams wrote:
>
> I have just (!) upgraded from xslide 0.23b to 0.2.
>
> After copying the .el and .elc files to my site-start.d, I encountered
> an error message, xsl-all-elements-alist symbol is void (something
> like that).
>
> I solved that by adding:
>
> (require 'xslide-data "xslide-data")
>
> to xslide-abbrev.el
>
> but then encountered a similar message for something to do with
> font-lock faces, so I added:
>
> (require 'font-lock)
>
> to xslide-font.el.
>
> (just in case you ever progress on xslide mode).
>
> Emacs : GNU Emacs 21.2.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
> of 2002-08-29 on astest
> Package: xslide.el 0.2
and I've been having a similar exchange with Dave Pawson about how to
byte-compile xslide without getting error messages.
My assumption, which, it seems, is frequently wrong, is that people
will use the provided Makefile to byte-compile xslide from the command
line.
Dave Pawson, at least, was using "C-u 0 M-x byte-recompile-directory"
and getting similar errors.
The xslide Makefile preloads font-lock, sendmail, and all of the
xslide files before byte-compiling a file.
It may be sufficient to use `load-file' to preload xslide.el before
byte-compiling any of the xslide source files.
So the question is: what do you do to byte-compile xslide and does it
byte-compile without errors or warnings?
Personally, I don't byte-compile xslide because I'm liable to tinker
with it at any time and I get annoyed by messages about .el files
being newer than .el files.
Regards,
Tony Graham.

>>>>> "Glen" == Glen Peterson <glen@...> writes:
>> Agreed, but I would have thought that impossible to achieve
>> with elisp.
Glen> I'll take that as a compliment - thanks! Elisp can do
Glen> anything.
I should have said I thought it would be impossible to achieve given
the restrictions of Emacs Modes.
Since you can do anything with elisp, then here's an absolute necessity
for making xslide a true XSL IDE:
Since a predominant use of XSLT is to produce HTML, and HTML pages
tend to contain javascript, I would like you to modify your behaviour
for comments and CDATA sections.
Firstly, to be at least able to toggle the behaviour of the TAB key,
so that you can get it to behave the same for CDATA and coments, as
any other tag (but I agree that pre-formatted text is probably the
best default.
But more importantly, recognise the XHTML script tag, (when specified
without a src attribute), and honour the type attribute. Specifically,
if type="text/javascript" (or text/JScript for Micros**t slaves),
indent, highlight and keymap the contents of the CDATA and comments children
as Javascript.
--
Colin Paul Adams
Preston Lancashire

Colin wrote:
>Is there any particular release or CVS version that the patches apply to?
It's not really a patch, just a newer version of two files. The latest whole package available on the home page is old. I got the latest version of each file from the CVS tree. It seems my XEmacs Windows distribution had done that for me already which was pretty cool.
>> Are you saying that the contents of a comment or CDATA section
>> should be treated as pre-formatted text?
Glen> Yes - when using indent-region. Well put. I wish I had
Glen> thought to say it that way in the first place.
>So, is the performatted text as a whole indented to a fixed-column?
It depends. The tab key will insert tabs (or spaces if you prefer) in these sections so you can change them manually. If you perform an indent-region those sections will be unaffected.
In any other part of the document, the tab key will still perform an "indent-line" command.
To indent a region, first select (highlight) it, then while it's highlighted, invoke indent-region. I have indent-region mapped to C-M-\ but you can also invoke it with:
M-x eval-expr
(indent-region)
>Now, what about xhtml definition lists? Anything special for them?
>(I'm asking because I'm writing one write now - I use xsl mode for
>xhtml editing - I prefer it to html-mode).
Can you send a representative document to the list? Is it XML? If so, I would hope it would just work. I haven't done a lot of testing with tags that start with <! or <? (aside from CDATA or the xml tags) so there might be some problems. Can any <! tags have children?
-Glen
---
Glen Peterson
Senior Software Engineer, Web Consultant
South Hamilton, MA USA

>>>>> "Glen" == Glen Peterson <glen@...> writes:
Glen> Doh! I posted new fixes this morning.
Is there any particular release or CVS version that the patches apply to?
>> Are you saying that the contents of a comment or CDATA section
>> should be treated as pre-formatted text?
Glen> Yes - when using indent-region. Well put. I wish I had
Glen> thought to say it that way in the first place.
So, is the performatted text as a whole indented to a fixed-column?
Now, what about xhtml definition lists? Anything special for them?
(I'm asking because I'm writing one write now - I use xsl mode for
xhtml editing - I prefer it to html-mode).
--
Colin Paul Adams
Preston Lancashire

Well, I seem to have put both feet in my mouth with my very first message.
1.) I meant Tony, not Tom. Sorry!
2.) Naturally, I didn't test the actual example that I sent to the list before claiming that my indentation worked. Doh! I posted new fixes this morning. I had done something really dumb while merging versions of this file on my own system. You want the top two files on the patches page (Fixes for indenting and highlighting). Tony, can you delete the bottom (older) xslide.el?
In response to Colin:
>Are you saying that the contents of a comment or CDATA section should
>be treated as pre-formatted text?
Yes - when using indent-region. Well put. I wish I had thought to say it that way in the first place.
Glen> * When using the tab key manually within a CDATA or comment
Glen> section, it should NOT perform an (indent-line). It should
Glen> insert a single tab character or the appropriate number of
Glen> spaces based on your xsl-tab-mode and xsl-tab-width settings
Glen> each time it is pressed.
>Agreed, but I would have thought that impossible to achieve with
>elisp.
I'll take that as a compliment - thanks! Elisp can do anything. Try my fixes.
>Can someone commit this to CVS (maybe in a branch)?
Not I. I think Tony is going to make a release before incorporating any of my changes. The fastest way to get it committed is to download it, try it out and make sure it works. After that, plus some discussion on this list, you can ask Tony again to commit it.
Here's some installation instructions:
1.) Find where these files are on your system.
- type M-x find-library
- When prompted, type xslide
- hit C-x-w to make your xslide directory show up in the status line.
- Remember this directory and use it for the steps below.
- Close the file (so it doesn't mess you up later)
2.) Make backup copies of xslide.el and xslide-font.el.
3.) Download my patched files
- Take the top two files from the bottom of this page:
http://sourceforge.net/tracker/index.php?func=detail&aid=741185&group_id=22964&atid=377145
- overwrite xslide.el and xslide-font.el with my changed versions.
- open emacs
4.) Build xslide:
- type M-x find-library
- When prompted, type xslide
- When it comes up, type M-x byte-compile-file
- hit enter when the file name comes up.
- hopefully there are no errors!
5.) Build xslide-font the same way you did xslide
6.) Close emacs
7.) Reopen emacs and open an xsl file
8.) You're done!
- Glen

>>>>> "Glen" == Glen Peterson <glen@...> writes:
Glen> I hope the other one was truly lost in the mail and doesn't
Glen> show up later to cause confusion.
No, it wasn't lost!
Glen> Here's my preferred indenting
Glen> rules for xsl (and xml):
I strongly agree with just about all of that. Exceptions follow.
Glen> * Comments and CDATA sections may contain "commented-out"
Glen> code and must have no effect on the indentation of the code
Glen> which follows them.
Glen> * (indent-region) must have no effect on the text within
Glen> comments or CDATA sections as these sections do not follow
Glen> the normal xsl rules.
Well, this is where I am a bit uncertain, as to what you mean.
Are you saying that the contents of a comment or CDATA section should
be treated as pre-formatted text?
Glen> * When using the tab key manually within a CDATA or comment
Glen> section, it should NOT perform an (indent-line). It should
Glen> insert a single tab character or the appropriate number of
Glen> spaces based on your xsl-tab-mode and xsl-tab-width settings
Glen> each time it is pressed. This allows easy manual indenting
Glen> of comments or other languages such as JavaScript.
Agreed, but I would have thought that impossible to achieve with
elisp.
Glen> I believe I have implemented all of the above in my latest
I'm very impressed.
Glen> If it sounds good, please try it out.
Can someone commit this to CVS (maybe in a branch)?
--
Colin Paul Adams
Preston Lancashire

Hello all. This is my second attempt at posting a message. I hope the
other one was truly lost in the mail and doesn't show up later to cause
confusion.
Tom suggested that a bit of discussion about ideal indenting was in
order and I agree. Here's my preferred indenting rules for xsl (and
xml):
* Either tabs or spaces is acceptable, but never both. Xslide should be
friendly to both camps.
* If you use tabs, you must set your tab stops to represent a single
indentation level - preferably 2 to 4 spaces wide. The 8 space default
tabs might be fine for typewriters, but it makes a mess of code and
gives tabs a bad name. I have mine set to 3 spaces.
* Closing tags should line up precisely below their matched opening tag.
* Children should be indented exactly one level.
* Putting each attribute on a new line is sometimes necessary for very
long tags. (I hardly ever do this myself, but it should not break
subsequent indenting)
* Several tags should be allowed on the same line. This is handy if
they are short and logically related.
* The tab key should perform an indent-line to be consistent with other
modes.
* Pressing the return key should move the cursor to the proper column
where the next line will start.
* Comments and CDATA sections may contain "commented-out" code and must
have no effect on the indentation of the code which follows them.
* (indent-region) must have no effect on the text within comments or
CDATA sections as these sections do not follow the normal xsl rules.
* When using the tab key manually within a CDATA or comment section, it
should NOT perform an (indent-line). It should insert a single tab
character or the appropriate number of spaces based on your xsl-tab-mode
and xsl-tab-width settings each time it is pressed. This allows easy
manual indenting of comments or other languages such as JavaScript.
Here is some sample indented xsl code showing many of the above points.
I used spaces so that it would look the same in everyone's email.
<xsl:template name="myTemplate>
<xsl:param name="myParam">
<!--
This code is commented out. It has no effect on
subsequent indenting.
<xsl:choose>
<xsl:when test="$myParam = 3">
<xsl:text>It's three!</xsl:text>
-->
<xsl:if test="$myParam = 2"><p>It's Two!</p></xsl:if>
<hr />
<p>Hello World</p>
<table>
<tr>
<td>Hi</td>
<td>There</td>
</tr>
</table>
<!-- Below is some javascript -->
<script type="text/javascript">
<xsl:comment><![CDATA[
var a = 5;
a--;
if (a > 3)
{
alert("<<<<hello>>>");
}
// ]]></xsl:comment>
</script>
<p>That's all folks!</p>
</xsl:template>
I believe I have implemented all of the above in my latest patch and
uploaded it to the patches area under the heading, "Fixes for indenting
and highlighting". Please ignore my previous patches. This should also
fix the empty tag indenting issue that was reported on this list as well
as the multi-line comment highlighting reported in the bugs section.
If it sounds good, please try it out.
I am new to Open Source contributions and associated lists. Please tell
me if I commit any social or procedural blunders.
- Glen Peterson

I have uploaded two new files with my fixes (and a description of such) to the patches area under the heading: "Fixes for indenting and highlighting". This should fix the indenting issue that was reported on this list. I am enjoying the ide much more with the strict stair-step indenting style that I prefer where close and open tags always line up and children are indented an additional level. Multi-line comment highlighting is also much improved (but I still don't have the closing --> highlighted without manually issuing a font-lock-fontify-buffer).
My changes include indenting comments and CDATA sections differently from the rest of an XSL file. The tab key insert either a tab character (if xsl-tabs-mode) or the number of spaces equaling one indent level in these sections. indent-region has no effect on these sections. Try it out and see if you like it. You can always save your xslide.el and xslide-font.el and restore them if you don't like my versions.
Also, I fixed some slow performance issues from my last post. There are a few more details on the patch page. Enjoy!
I'm a new to Open Source contributions and associated lists. Please tell me if I commit any social or procedural blunders.
P.S. I finally got the return key mapped. After trying everything under the sun, "\C-m" was the ticket! Aaaah...
---
Glen Peterson
Senior Software Engineer, Web Consultant
South Hamilton, MA USA

*** Replies are sent to the sender by default, not to the list ***
At 17 May 2003 09:39 +0100, Colin Paul Adams wrote:
> >>>>> "Tony" == xslide Support <xslide-bug@...> writes:
...
> Tony> Just us two at present.
>
> Not quite.
Well, there were two when I checked on Friday. There's three now.
Welcome.
> I used xslide extensively in my previous job.
>
> Then a year-and-a-half out of work later, I've started a new job. As I
> will be making extensive use of XSLT (as will my boss) later on in the
> project, I thought I'd better download the latest version. I was
> somewhat disappointed to discover that it had not progressed very far,
> and even more to discover I had to tweak the elisp to get it to
> compile (I filed a bug report).
I got your report, but I was on holidays in Australia in April, and
that was immediately followed by a business trip to the USA.
xslide hasn't progressed much because I haven't used it much and
because using SourceForge CVS was so painful.
I have been (and still am) working on the Sun xmlroff XSL Formatter
(http://xmlroff.sourceforge.net/) and I haven't used XSLT or even
XSL nearly as much as I've used C.
SourceForge CVS access from my Windows machine was painful (since I
couldn't even do C-x v v), but since xmlroff moved to SourceForge,
I've got my Linux machine working properly with SourceForge CVS, plus
I am more used to CVS now than I was in 2001.
...
> One feature I would like to see fixed is indentation after an empty
> tag. It would appear that xslide doesn't recognise empty tags.
I believe that's fixed in the version in CVS.
Regards,
Tony Graham.

At 15 May 2003 13:54 -0700, Shawn O. McKenzie wrote:
> Not sure if anyone is on this list yet, but I thought I'd get the party
> going. =)
Just us two at present.
> I spend much of my time in xslide, and it is pretty fantastic. My
Thank you.
> recent project has over 5000 lines of XSLT and xslide has really helped.
...
> I am very familiar with DocBook and psgml-mode. One thing that would be
> nice in xslide is the ability to tag whole regions. It would, for
Please submit a feature request on the SourceForge site.
> instance, be nice to be able to highlight a large section of XSLT and
> wrap that section with an if conditional. Another thing that might be
I want the function that turns
<xsl:if>
...
</xsl:if>
into
<xsl:choose>
<xsl:when>
...
</xsl:when>
<xsl:otherwise></xsl:otherwise>
</xsl:choose>
but I've yet to implement it.
> nice is if it could validate the code, and only allow you to insert xsl
> tags in the right place.. for instance it would only allow you to insert
> a sort after a for-each or apply-templates. But I could see how this
> might be impossible because you could have html tags all over the place
> that would break validation...
If you assume XML-style validation. I have contemplated using the
Semantic Bovinator to implement better parsing than the current
font-lock pattern matching. That also leads towards using Speedbar
for a structural view of the stylesheet.
Another idea is adding font-lock keywords for HTML and/or adding the
ability for adding custom tag sets to the font-lock patterns.
> Anyhow. It is fantastic, and I'm sure I'm not using it to its potential.
Hopefully one day xslide will reach its full potential. Right now it
barely warrants the 'ide' part of its name.
Regards,
Tony Graham

Not sure if anyone is on this list yet, but I thought I'd get the party
going. =)
I spend much of my time in xslide, and it is pretty fantastic. My
recent project has over 5000 lines of XSLT and xslide has really helped.
I've looked at the .el files briefly, but don't really see what is going
on at first glance. So, I'm not sure if the following suggestions are
feasible or if they are already there and I just don't know how to use them.
I am very familiar with DocBook and psgml-mode. One thing that would be
nice in xslide is the ability to tag whole regions. It would, for
instance, be nice to be able to highlight a large section of XSLT and
wrap that section with an if conditional. Another thing that might be
nice is if it could validate the code, and only allow you to insert xsl
tags in the right place.. for instance it would only allow you to insert
a sort after a for-each or apply-templates. But I could see how this
might be impossible because you could have html tags all over the place
that would break validation...
Anyhow. It is fantastic, and I'm sure I'm not using it to its potential.

Since there has been a recent increase in interest in using and
improving xslide (and since I now use SourceForge for the xmlroff and
PangoPDF projects), I am belatedly starting a mailing list specific to
the xslide XSL mode for Emacs.
No, the world doesn't really need another mailing list, but nor does
any other mailing list need traffic about xslide. Having a mailing
list for xslide hopefully pleases those people interested in xslide
without annoying those uninterested in xslide.
Regards,
Tony Graham.