file output with inconsistent line endings from JavaScript Big Prompt

I am sure I have asked this before but this is just bitten me in the backside again so I thought I would see if anyone has the answer.

ok the problem is actions like “ESS-Convert to Style Sheet” and my own “Script Maker” allow people to dump great big bits of code into a Freeway “JavaScript Big Prompt” widow and that’s great BUT there is a bit of a flaw which is:

if you copy and paste a load of css which is all nice and tidy from a text editor like TextMate2 or TextWranger into a the “JavaScript Big Prompt” then the out viewed in textmate is exactly as originally pasted, but if you just ad an extra line say a new tiny style within the “JavaScript Big Prompt” then the output spits out the inconsistent line endings and I am assuming its processing the amended styles within the big prompt in a different way and thats messing things up.

You can see this problem in Textmate2 via any big prompts output. Basically the output now contains loads of tags and from what I have read its because the file has inconsistent line endings, Textmate then treats n as a line ending marker and display as text.

I am assuming the pasted text is using one line ending such as CR (e.g. Carriage Return) line endings.
an then freeways javascript prompt is then using something els like: LF (e.g. Line Feed)

( I am guessing a lot of this above)

Anyway so what can I do about it, bearing in mind I copy and paste a lot and then adjust whats there within the Big Promt.

So the question is is there something like

      <action-encoding>UTF-8</action-encoding>

But for line endings?
Does anyone have clue?

all the best max


actionsdev mailing list
email@hidden
Update your subscriptions at:

I am assuming the pasted text is using one line ending such as CR (e.g. Carriage Return) line endings.
an then freeways javascript prompt is then using something els like: LF (e.g. Line Feed)

Hey Max–

I use Coda for a lot of development, and when I open a Freeway-generated HTML file in the past would always get complaints about converting the CRs to LFs (or maybe the other way around?). Anyway, I just tested (latest versions of both) and didn’t get any complaints… maybe something changed?

Anyway, just popping by to say I think you’re on to something there.

Best of luck,


actionsdev mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

Hi Ernie

I am fairly sure its do do with the big prompt window which is used in quite few actions. It may also effect the other input fields in actions but I don’t know for sure.

At the moment I am resorting to making sure I copy any amendments conent I have added within the big prompt window into an editor and then pasting it back again and all the while making sure I don’t touch the content … which sort of defeats the object of having a big prompt window.

Max


actionsdev mailing list
email@hidden
Update your subscriptions at:

What I ended up doing in Protaculous2 was splitting the content of the box by [\r\n], then concatenating the resulting array back together by using fwAddRawln inside a loop. That forces Freeway to use whatever line-ending it is configured with by the user.

Walter

On May 10, 2016, at 9:40 AM, max email@hidden wrote:

Hi Ernie

I am fairly sure its do do with the big prompt window which is used in quite few actions. It may also effect the other input fields in actions but I don’t know for sure.

At the moment I am resorting to making sure I copy any amendments conent I have added within the big prompt window into an editor and then pasting it back again and all the while making sure I don’t touch the content … which sort of defeats the object of having a big prompt window.

Max


actionsdev mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk


actionsdev mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options