With a presumption that paragraphs start with a capital letter or opening double quote I think you can get at least 90% of the way there with a simple GREP find change using a negative look-ahead:

Find \r(?!["\u]) and change to a space

I don't see any hyphens in your sample, but if there are they might get left in the text, and of course you may still have some unwanted breaks where a sentence coincidentally starts a new line, but I think that will cut down on  manual changes.

@Kelli Jae Baeli

I think @James Gifford—NitroPress meant this thread:

https://community.adobe.com/t5/indesign-discussions/how-to-correct-wrong-page-break/m-p/14787906#M584149

If no marker string can be found, and no better version of the file can be obtained, the only "good" solution may be to go through and add a paragraph return before each genuine paragraph start. That would be fairly fast and efficient, if tedious beyond belief, but then any of these fixes can be implemented using a double return as an actual/desired return, and eliminating the rest.

Hi @Kelli Jae Baeli , It looks like from your capture that periods indicate the real end of a paragraph? If that’s the case a script could remove returns at the end of a line when there’s no period before the return. For example:

Before:

After:

Using this script with a text frame selected:

//Gets the parent story of a selected text frame
var sl = app.activeDocument.selection[0].parentStory.lines.everyItem().getElements();
var er
for (var i = sl.length-1; i > -1; i--){
     er = sl[i].characters.itemByRange(-2, -1)
     if (er.characters[0].contents != "." && er.characters[1].contents == "\r") {
         er.contents = ""
     } 
}; 

We just covered something like this. It can be fixed, within certain limits.

First off, the usual cause of this one-para-per-line fault is a glitched export or file conversion, or (very common) cut and paste from a PDF. If you can back up to any prior version, even that PDF, you might be able to export a better-structured file to start with.

While it's possible to write an elaborate GREP string that can sort this out, the more efficient, kind of bulldozer method I've used most often is a series of Find/Replace. That may be tricky here because I don't see how those paragraphs are indented. There has to be some "marker" for the start of the real paragraphs. You have hidden chars turned on, and I don't see a tab, and it looks as if every single paragraph is the same style with that indent.

The way it would work, if a marker can be found, is more or less this:

• FIND <paragraph return><marker>
• REPLACE both with a tag like #*#*#
• FIND all remaining paragraph returns and REPLACE with spaces
• FIND all double spaces and REPLACE with single (just cleanup — optional)
• FIND your tag and REPLACE with a paragraph return

That, in theory, will remove all extraneous paragraph returns and restore only those wanted at the end of paragraphs.

But if there's no marker to hang this on... I can't think of any easy solution. You may have to replace all paragraph returns with spaces, then go through and manually break the content back into paragraphs. If the marker is some unique text string (instead of a tab or leading space or such), a GREP string might be composed to find it.

ETA: It seems unlikely, but are any styles used here? Are all those paragraphs the same (BODY or NORMAL or such)? Or is that last paragraph ("Minutes later...") a different style? That would give a hook for the above process.