On 6 dc, 12:30, Colin L. [email protected] wrote:
On 6 dc, 09:53, Colin L. [email protected] wrote:
Screen:http://lh4.ggpht.com/_Hc_PJsJ5czI/TPy9KFd3RsI/AAAAAAABNIc/bApGqfK32fE…
Well I have to apologise for suggesting that if the html looked the
same then it would render the same. I had not allowed for
non-displaying characters. I wonder whether you are on developing on
windows? I seem to remember a problem with <%- -%> that the -
removed the LF but not the CR in files with CRLF line endings.
Colin
Yep, Windows. When i print special chars in Komodo, i see LF ending
each line, but no CR. I’m really not at ease with those file format
issues, can’t be really helpful on that, sorry 
On 6 dc, 15:28, Julien [email protected] wrote:
On 6 December 2010 11:03, Julien [email protected] wrote:
text it’s fine.
firefox and you can see which div or whatever the space is in and how
In Firefox, the generated html seems exactly the same, but in Chrome,
Yep, Windows. When i print special chars in Komodo, i see LF ending
each line, but no CR. I’m really not at ease with those file format
issues, can’t be really helpful on that, sorry
Confirmation of my second guess:
It’s Komodo Editor, adding ugly stuff.
I’ve open and added some files in the projects using Radrails and
everything is okay.
Though i have no way to correct files corrupted by Komodo (open and
save doesn’t do the trick).
Damn Komodo!!! And maybe some other text-editors generate the same
kind of horror.
Julien wrote in post #966616:
On 6 dc, 15:28, Julien [email protected] wrote:
On 6 December 2010 11:03, Julien [email protected] wrote:
text it’s fine.
firefox and you can see which div or whatever the space is in and how
In Firefox, the generated html seems exactly the same, but in Chrome,
Yep, Windows. When i print special chars in Komodo, i see LF ending
each line, but no CR. I’m really not at ease with those file format
issues, can’t be really helpful on that, sorry
Confirmation of my second guess:
It’s Komodo Editor, adding ugly stuff.
I use KomodoEdit all the time (on Mac OS, not Windows), and I’ve never
seen it do this. What are your line ending preferences set to (that
should be somewhere in the status bar)?
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
if it’s the adding of cr/lf, try scite - it has the ability to specify
and
convert eol to and from cr, cr/lf, or lf. A bit of a pain to do
manually,
but I dn’t know how to do automatically.
On 7 December 2010 07:11, Julien [email protected] wrote:
Well i guess the conclusion of all this is that if you encounter
unwanted spaces in your partials, check your editor 
It would be interesting to inspect the file with a hex editor to see
exactly what the non-printing chars are. They are not tabs are they?
Colin
On 6 dc, 20:50, Marnen Laibow-Koser [email protected] wrote:
issues, can’t be really helpful on that, sorry
–
Marnen Laibow-Koserhttp://www.marnen.org
[email protected]
–
Posted viahttp://www.ruby-forum.com/.
I tried Scite and converted some CR/LF endings to LF only but it
doesn’t correct the issue.
My gut tells me it’s not an matter of line endings since the strange
digit appears at the very beggining of the inclusion of the partial
(or the yield). I don’t know much about file system but i suppose
Komodo was created on Linux and uses some file headers which are not
correctly understood by Webrick on Windows which then tries to print
them.
I don’t have that many partials and will simply recreate them and copy/
paste the code using radrails. I should have guessed that the editor
was to blame before, because i finished a previous full project on
Radrails and never encountered that problem. I switched because
Radrails is a slow when you ctrl+s.
Well i guess the conclusion of all this is that if you encounter
unwanted spaces in your partials, check your editor
On 7 December 2010 13:38, Marnen Laibow-Koser [email protected]
wrote:
making silly speculations. Komodo does no such thing AFAIK.
What might be going on is that your file is being saved as UTF-8 with
a byte order mark (BOM) at the beginning. That shouldn’t cause
problems, but try changing the encoding to UTF-8 without BOM and see
what happens.
Jumping the gun I know, but if it were the BOM then would that be a
bug in rails as a BOM at the start of a partial should not be sent out
to the browser, should it?
Colin
Julien wrote in post #966777:
[…]
My gut tells me it’s not an matter of line endings since the strange
digit appears at the very beggining of the inclusion of the partial
(or the yield). I don’t know much about file system but i suppose
Komodo was created on Linux and uses some file headers which are not
correctly understood by Webrick on Windows which then tries to print
them.
Since you don’t know much about the filesystem, perhaps you shouldn’t be
making silly speculations. Komodo does no such thing AFAIK.
What might be going on is that your file is being saved as UTF-8 with
a byte order mark (BOM) at the beginning. That shouldn’t cause
problems, but try changing the encoding to UTF-8 without BOM and see
what happens.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Sent from my iPhone
I’m not sure it’s the editor; my own issues are coming with Notepad+
+. Still, I’m glad I checked back into this thread. It’s given me
some stuff to try out. If I find the magic solution (or if I don’t)
I’ll check back in.
Okay, here’s what I’ve got so far:
If I encode in ANSI or UTF-8 without BOM, I lose my phantom spaces.
If I encode in plain old UTF-8, phantom spaces with my partials.
Dunno why…but at least I can use partials again without mucking up
my page.
One small step for man, I know…
Colin L. wrote in post #966863:
On 7 December 2010 13:38, Marnen Laibow-Koser [email protected]
wrote:
making silly speculations. Komodo does no such thing AFAIK.
What might be going on is that your file is being saved as UTF-8 with
a byte order mark (BOM) at the beginning. That shouldn’t cause
problems, but try changing the encoding to UTF-8 without BOM and see
what happens.
Jumping the gun I know, but if it were the BOM then would that be a
bug in rails as a BOM at the start of a partial should not be sent out
to the browser, should it?
It actually shouldn’t matter. The BOM was chosen rather cleverly: it’s
U+FEFF ZERO-WIDTH NONBREAKING SPACE, so it should have no typographical
effect whatsoever. But maybe the browser is detecting it as whitespace,
or maybe there’s a further encoding issue. Or maybe something else is
going on.
Colin
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Sent from my iPhone
Just checking:
UTF-8 without BOM: no problems
UTF-8 with BOM: problems
Right?
Correct.
I’ve never seen this problem on *nix. I wonder if it’s an artifact of
Windows’ text handling routines.
Yes, I strongly suspect, since the two people who’ve had this problem
are working on Windows with different text editors.
This was a great thread. I never would have looked at the encoding
without you guys.
bravehoptoad wrote in post #966994:
Okay, here’s what I’ve got so far:
If I encode in ANSI or UTF-8 without BOM, I lose my phantom spaces.
If I encode in plain old UTF-8, phantom spaces with my partials.
Dunno why…
You’ve got your answer, I guess. It is the BOM creating problems, or
so it would seem from the behavior above.
Just checking:
UTF-8 without BOM: no problems
UTF-8 with BOM: problems
Right?
If so, then we have isolated the problem to a minimal pair.
but at least I can use partials again without mucking up
my page.
One small step for man, I know…
I’ve never seen this problem on *nix. I wonder if it’s an artifact of
Windows’ text handling routines.
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On 7 dc, 21:54, bravehoptoad [email protected] wrote:
Windows’ text handling routines.
Yes, I strongly suspect, since the two people who’ve had this problem
are working on Windows with different text editors.
This was a great thread. I never would have looked at the encoding
without you guys.
Hey you rock people, UTF8 without BOM is perfect. Sorry for silly
speculations on Komodo
Glad we found the root of it.
Thank you all!