It *is* a niche thing, but it’s a small enough request to write a custom script for. This one requires you to click inside the story to process – it does not Play Nice with stuff like locked layers and master pages and such.
It just inserts the Indent To Here marker at the start of the second word in a story. It also processes one-line paragraphs, which is kinda superfluous, but there you go, it was in the specs.

//DESCRIPTION:Indent 3-line paragraphs after first word
// A Jongware Script 15-Dec-2019
// 1. Iterate over all paragraphs.
allParagraphs = app.selection[0].parentStory.paragraphs;
// 2. Filter out 3-lines-or-less.
for (i=0; i<allParagraphs.length; i++)
{
// 3. Indent them after the first word.
if (allParagraphs[i].words.length > 1 && allParagraphs[i].lines.length <= 3)
{
allParagraphs[i].words[1].insertionPoints[0].contents = '\u0007';
}
}

If your footnote texts use a dedicated paragraph style, then I see no problem. You can specify this style in the Find Format field in Find/Change. (And as Chris says, don’t forget to check if “Include footnotes” is actually on.)

That said: if you added that smaller font with a character style, then you have this problem because you stated the smaller size *in* that char style and thus made it work only for a specific base size. You can avoid that by not specifying the actual size in pts, but instead use Horizontal and Vertical Scale in the Advanced Character Formats section. To go from 13pt to 10pt, enter “1000/13” in both the scale fields, and ID will calculate how much that is in %%. (I could have told you to type in “76.9%” but knowing how to get such a value is more useful in the longer run.) Then you can use the same character style for any text size, either larger or smaller, as in your footnotes.

What you are seeing is Adobe’s patented Paragraph Composer at work.

Other than most word processors (Microsoft Word, I’m looking at you), the Paragraph Composer checks the line length of every line agains every other line, and makes them as equal as (mathematically) possible. Thus, if moving a word to a next line decreases that line’s length, it is because the alternative is worse. Sure, when unaltered that paragraph may have one full line more but you can be sure somewhere else another line will be way shorter than everything else, and thus will be less perfectly filled.

The algorithm is designed to work best with fully hyphenated and justified text – in which case it will minimize different space widths between consecutive lines – but the same thing also works for ragged, unhyphenated text.

That said: the Paragraph Composer is only the default setting, but of course you can change your text to use the Single Line Composer. That name does not mean it only works on single lines, it’s just that it only considers one line at a time. It uses a straightforward rule to break paragraphs into lines: fill with words. Last word does not fit? Break there.

While it may sound as if filling one line at a time should yield “the best” line breaking, that is not the case. Inside any moderately long paragraph, you might spot occasions where it would be nicer to move the final word of a long line to the start of the next one, so you don’t get one very full line followed by one that is visibly much shorter. The Paragraph Composer does check for that, in the extreme: it minimizes all deviations in the entire paragraph – just because moving one word at the first line may influence the very last line to make the entire paragraph more even.

Here is David’s view on the Paragraph Composer: https://indesignsecrets.com/the-importance-of-paragraph-composition.php (we pretty much agree on this).

Instructions to change the default composer (for some of your paragraphs only, or, if you have consistently been using paragraph styles, for all of your document) can be found in Adobe’s Online Help: https://helpx.adobe.com/indesign/using/text-composition.html

Aaron is definitely on the right track this far, but it looks like we’re going to need to see some actual examples here.

There is a TextVariable for that – its type is even called “File Name”. See the Online Help: https://helpx.adobe.com/indesign/using/text-variables.html

Basically, all you have to do is create a variable of type “File Name” and replace your typed text with it. Then, no matter what you save your document as, as soon as it’s saved, the variable will contain that name. (If it appears to not work: then it’s just a redraw lag. If you force the screen to redraw, even only by scrolling a bit, you’ll see the variable update.)

Can you please expand on “it does not work”? It’s like taking your car to a garage and telling the mechanic “it does not work”. They’ll be pressing for details too. (“I meant the windshield wipers don’t work”, for example.)

It’s a JavaScript and so you should be saving it into your Script Folder with a .jsx file extension. Also, are you using Adobe’s own ESTK editor to enter it? At times, people use Word or TextEdit to edit their scripts (which is their good right; both are indeed good editors, and why not use it if you are familiar with how it works?) but they forget that a plain “Save” command from these will save the text in each respective’s own internal file format, and InDesign can’t read these. (Which it actaully can – Word saves as a file type of .docx and TextEdit saves as .rtf, aand you can import both of these into InDesign. But scripts are not imported,) The ESTK editor saves in the right file format; if you use something else then make sure you save your script as “plain text”.

Also pay particular attention to things such as en-dashes and quotes. Sometimes the forum software (or, indeed, “smart” text editors such as Word) replaces a double minus as in i--; (a faster way of typing i = i - 1;) with a single en-dash, and changes straight single and double quotes to “typographically correct” curly open and close quotes. If your script has been saved correctly but it shows an error on a certain line, inspect that line for these special characters and correct them. For clarity: programming languages need straight quotes.*
Using the ESTK editor has an advantage here: ‘text strings’ get colored differently than other code, and if you have the wrong kind of quote, you can see the string does not get colored correctly, or its color extends past where you would expect.

* Because Historical Reasons. Ye Olde Keyboards did not contain correct quotes and used the same characters for open and closing, and also for feet and inches, and minutes and seconds. That “Ye Olde Keyboards” even harks back to the very first mechanical typewriters, although I think it’s excusable because one could not enter programs into a computer with pen and paper, it needed a keyboard. (As it happens, I am typing this on my iPad which does not have a keyboard. Oh how progress progresses. And I can type curly open en close quotes! But programming languages lag behind. And it’s also easier to use just a single character, rather than hunting for the correct one.)

InDesign’s measurements are far (far, far!) more accurate than the paltry 4 or 5 digits shown in the control panel and the rest of the interface. It can handle differences as small as 0.00001pt (uh, probably even smaller!). David’s trick of switching to another measurement unit may work well. Usually such indents are logically based on, say, 1/6th of an inch – which can only translate to lots of invisible decimals when converted to millimeters. (And the other way around too.)

But there is another factor at play: the initial accuracy of the conversion from (presumably) a Word document to InDesign. At that point it is possible that some rounding introduces a small difference at the umpteenth position, and what is reported on-screen as “1.25pt” may internally be stored as “1.24999999435pt”.

For such cases I use a one-line script that copies the actual value of such an indent into the Find formatting field:

See also this older post of mine in the Adobe forum (which pretty much says the same): https://forums.adobe.com/thread/2485366

It indeed isn’t too difficult. For your consideration, two scenarios:

1. To only put the text cursor at the very start of the text in a selected text frame:

try {
	app.selection[0].texts[0].insertionPoints[0].select();
} catch (_)
{
	/* beep beep */
}

2. To select all of the text in the frame:

try {
	app.selection[0].texts[0].select();
} catch (_)
{
	/* beep beep */
}

In both these scripts it is blindly assumed there is a selection, and it has at least one item (if you select multiple objects it will probably work at random, depending on what order you selected in!), and it contains some text. Now usually, for a more robust script, you would add some checking for each and every item that can possibly go wrong. It takes a lot of checking, not only because there are tons of different things to click on, but, surprisingly, users can also get incredibly creative at how to indicate what they want to do – click frame, click in frame, multiple selections, linked captions, not-a-textframe-at-all, et cetera.

But it’s a simple function to use, and you would not be surprised if you accidentally try it on an embedded image and nothing happens. (Rather than, say, an alert popping up stating that you cannot edit the text in that image, or – worse – an aggressive “boing” sound and a scary error message from ExtendScript with lots of technical details.

So here I wrapped the magic single line into a “try .. catch” sequence. This will bluntly run the script inside the “try” part and if something – *anything* – goes wrong, it will silently continue with the code in the “catch” part. Which … does nothing! There is just a comment there. So if nothing happens, it just means “yeah this ain’t gonna work and you probably should not have tried this”.

Pick one of these scripts (or both), save under a useful filename in your Scripts Panel, and make sure to assign a Keyboard Shortcut Key to it for maximum efficiency.

… Surprise! I assigned “Escape” with a context of “Default”, and lo! “Escape” toggles between having the text frame selected and having the text *in* it selected! I think that’s a keeper.