Die Situation

Enter
Shift Enter
Shift Enter
Shift Enter
Enter
Shift Enter
Shift Enter
Shift Enter
Enter
Shift Enter
Shift Enter
Shift Enter

führt mit der GREP-Suche [#cc0000]Position Absatzbeginn[/#cc0000]^ dazu, dass nach dem Enter jeweils das zweite und dritte Shift Enter gefunden wird. Nicht aber das erste…?

und überhaupt: Weshalb ist ein Shift Enter – also der sog. Harte Zeilenumbruch – ein Absatzbeginn?

Ich hoffe die Fragestellung ist verständlich

Hallo Peter,
könnte ein Bug sein.

Von welcher InDesign-Version auf welchem Betriebssystem sprechen wir?
Und: Enthält der Text Hyperlinks, Querverweise oder sonstige Sonderzeichen?

Ciao Uwe

Tschuldigung, klar… ID CC 15.1.2, macOS 10.15.6

Vorgehen:

- Neues Dok
- Neuer Textrahmen
- Cursor stellen, ENTER drücken
- Shift Enter
- Shift Enter
- Shift Enter
ENTER drücken
- Shift Enter
- Shift Enter
- Shift Enter
ENTER drücken
- Shift Enter
- Shift Enter
- Shift Enter

dann Suchen/Ersetzen, GREP
Position Absatzbeginn
–> köstlich – oder ich bin blöd

Danke Uwe – andere machen Kreuzworträtsel 😉
Peter

Hallo Peter,
teste gerade mit ID 15.1.2 auf Windows 10 nach Deinen Vorgaben.

Der erste Absatzbeginn im Textrahmen wird gefunden.
Dann allerdings wird's doch etwas kurios im ersten Absatz:

Zweite Fundstelle ist genau vor dem zweiten Shift Enter.
Dritte Fundstelle ist genau vor dem dritten Shift Enter.

Das setzt sich so in den beiden anderen Absätzen genau so fort.

Jetzt gilt es noch herauszufinden, ob dieses Verhalten sich noch bei anderen Versionen von InDesign zeigt.

Habe gerade in InDesign CS6 Version 8.1.0 getestet. Da ist's noch schlimmer.
Der Absatzbeginn am Anfang des Textrahmens wird gefunden. Aber:

Nächster Treffer ist vor dem zweiten Shift Enter.
Nächster Treffer ist vor dem zweiten Shift Enter.
Nächster Treffer ist vor dem zweiten Shift Enter.

usw. usf. Es geht einfach nicht weiter mit "Weitersuchen".

Hallo Uwe,

Antwort auf:

Jetzt gilt es noch herauszufinden, ob dieses Verhalten sich noch bei anderen Versionen von InDesign zeigt.

Mir ist nicht bekannt, dass das Verhalten in irgendeiner Indesign-Version anders als wie beschrieben gewesen wäre.

Deswegen ist auf GREP-Suche mit '^' eben kein Verlass, weil es eine Zeilenschaltung genauso wie eine Absatzschaltung wahrnimmt.

Ist mit '$' übrigens genau dasselbe.

Eine Lösung (für andere als den ersten Absatz) wäre etwa

Code

(?<=\r) 

^ für nur Absatzschaltung wäre tatsächlich ein großer Fortschritt.

----
edit:
Allerdings bin ich überrascht, dass mit "^" und "$" überhaupt etwas gefunden wird. Hatte die beiden Zeichen stets als Positionszeichen (wie auch Wortanfang und Wortende) wahrgenommen und nur in Kombination mit anderen Ausdrücken/Zeichen (etwa ".") verwendet.
"\<", "\>", "\b" helfen schließlich auch nur bei der Verfeinerung der Position und bewirken alleine auf sich gestellt nichts.

Antwort auf:

"\<", "\>", "\b" helfen schließlich auch nur bei der Verfeinerung der Position und bewirken alleine auf sich gestellt nichts.

Stimmt nicht ganz.
CS6 verhält sich hier anders als CC2020 und CC2018.

CS6 findet bei GREP-Suche nach "\<", "\>" oder "\b" tatsächlich "manche" Wortbegrenzung. Allerdings eher unzuverlässig: \b etwa keine Wortbegrenzung vor oder nach einer Absatz- oder Zeilenschaltung. ;-)

Aber sind diese "Location Marks" tatsächlich dazu gedacht, für sich allein, ohne begleitende Zeichen/Ausdrücke etwas zu bestimmen?

Am Rande:

In CC2020 findet "^" ja sowohl die Positionen am Anfang eines Absatzes und nach einer Zeilenschaltung.

"^*" und "^+" und "^^" und "^{0,5}" finden gar nix.

Hallo Martin,
von den Dreien dürfte auch der Logik nach kein Einziger funktionieren, da es keine mehrfachen Zeilenanfänge ohne dazwischenliegendes Zeilenende geben kann.

Interessant ist aber auch das Ergebnis nach

Code

(^(\r|\n))+ 

[edit]
Ich habe ^ und $ bisher aber auch ausschliesslich als Positionsmarken angesehen und immer nur in Verbindung mit mindestens einem „realen Zeichen“ verwendet.
[/edit]

Lieber Martin, Pixxxelschubser und Uwe
Danke euch bestens für die Zeit – Grund meiner Frage war/ist die folgende Situation:

https://www.dropbox.com/...hy5qs37K6WNG9Ca?dl=0

Es ist ein Tweet-Buch eines Werbetexters. Es sind knapp 1000 Tweets enthalten. Kurz vor der geplanten Publikation wünschte er sich die Nummerierung zum Start eines jeden Tweets.

Also erstellte ich einen Textrahmen mit Nummerierung und kopierte diesen in die Zwischenablage. Nun Suchen/Ersetzen mit GREP:

Suchen: (?<=\r)^(.)
Ersetzen: ~c$1 –> Einfügen Zwischenablage, Fundstelle 1 zurückgeben

Mit dem SHIFT ENTER vor dem Absatzbeginn wird das ganze Buch durchgearbeitet, eben jeder Tweet aufsteigend nummeriert.

Aber der Affe hatte bereits gebissen… ich fragte mich weshalb der Absatzbeginn ^– wie Martin bereits erwähnt hat – eben ENTER und SHIFT ENTER findet. Begriffsverwirrung? GREP-nicht-verstehen?

Deshalb dann meine abstrakte Übung mit ENTER und mehreren SHIFT ENTERS – und die grosse Verwunderung des Resultates.

Mit lieben Grüssen – und voller Unverständnis ;-)
Peter

Lieber Peter,

mich überrascht, dass Du nach "(?<=\r)" noch "^" verwendest. Schließlich sorgt "(?<=\r)" bereits für die Positionsbestimmung "nach einer Absatzschaltung".

Ferner ist die Gruppenklammer um den Punkt (beliebiges Zeichen) überflüssig, wenn Du den Treffer beim Ersetzen mit $0 (= Fundstelle) statt mit $1 referenzierst.

Nach meinen Dafürhalten sollten folgende Ausdrücke ausreichen und zum Ziel führen:

Code

Suchen:   (?<=\r). 
Ersetzen: ~c$0 

Beim ersten Absatz im Textabschnitt, dem keine Absatzschaltung vorangeht, mußt Du händisch nachhelfen.

Zitat von Peter Laely

Mit dem SHIFT ENTER vor dem Absatzbeginn wird das ganze Buch durchgearbeitet, eben jeder Tweet aufsteigend nummeriert.

Diesen Satz verstehe ich nicht.
Wie soll SHIFT ENTER an der Nummerierung beteiligt sein? Die Nummern stehen doch immer nach einer Absatzschaltung am Anfang eines neuen Absatzes, oder?

Danke für das Beispiel. Nebenbei: das sind ganz nette Wortspiele.


Allerdings verstehe ich die unorthodoxe Anwendung der harten Zeilenumbrüche + Worttrennungen nicht ganz. (Aber vielleicht ist das auch lediglich dem Beispielaufbau geschuldet und der reale Text ist „stimmiger“.)

Und wahrscheinlich hätte ich die Grepsuche etwas anders aufgebaut.
Eventuell mit:

Code

\r\K(.) 

oder

Code

\r\K. 

und anschließend den ersten Absatz manuell gesucht und die Zwischenablage eingefügt.

Noch eine Frage: Da du von tausend Tweets redest - wie sieht denn das Ende des Textes aus? Drei- und vierstellige Zahlen, um 90° gedreht, als Aufzählung? Ich kann mir nicht vorstellen, dass das optisch wirklich gut aussieht.

----------

Wie auch immer. Das Verhalten deiner Grepsuche ist hier tatsächlich nicht ganz so wie erwartet - um nicht zu sagen: nicht wirklich verständlich. Und von daher stellt sich nach wie vor die Frage: Bug oder nicht Bug?

@Martin – Danke!

Der Feind des Guten ist das bessere… dachte ich zuerst

aber ohne ^ bleibt dein Vorschlag stecken – dh. InDesign weigert sich nach einigen Fundstellen weiter zu suchen
(.) mit . und $0 zu erstzen: ja, völlig richtig

Nicht zuletzt deshalb habe ich mir dann versucht das Ganze erklärbar zu machen – eben mit dieser abstrakten ursprünglich geposteten Fragestellung von Absatzbeginn gefolgt von harten Zeilenumbrüchen…………


@Pixxxelschubser
Jaja – die Sprüche sind echt lustig – Kannst das lustige Buch gerne erwerben –> Ich mag die Art, wie du mich ignorierst; René Moor

Die Datei mit «ihren Shift-Enters» wurde mir so angeliefert – es war keine Zeit (und Lust) da einzugreifen – aber die Motivation die Nummern einzufügen war da – aus der Praxis für die Praxis quasi

Das Ende ist bei 730 erreicht und die Nummer schaut recht nett aus. Passt also


Liebe Grüsse, Peter

Antwort auf [ pixxxelschubser ]

Und von daher stellt sich nach wie vor die Frage: Bug oder nicht Bug?

Auch wenn die Mehrdeutigkeit des Caret-Zeichens (^) für sowohl Absatzbeginn als auch Beginn einer neuen Zeile nach fester Zeilenschaltung mit Umschalt-Eingabetaste (übrigens Shift-Return, nicht Shift-Enter) schon immer so war - und deswegen aufgrund Erfahrung gewissermaßen erwartbar - halte ich es für einen Fehler.

Absatzbeginn ist eben Absatzbeginn (= Beginn eines neuen Absatzes) und nicht Beginn einer neuen Zeile nach Umschalt-Eingabetaste.
So wie Beginning of Paragraph eben auch "Beginning of Paragraph" nun nicht "new line" (LF) nach Betätigung von Umschalt-Eingabetaste ist.

Ja, ich nenne dieses Verhalten einen Bug, der sich seit Erscheinen von InDesign CS3 im Jahr 2007 (mangels Reklamation?) hat halten können.
Vielleicht sollten wir das mal reklamieren.

Willst Du, Peter, den Anfang machen?
Meine Stimme hast Du. :-)

Antwort auf [ Peter Laely ]

aber ohne ^ bleibt dein Vorschlag stecken – dh. InDesign weigert sich nach einigen Fundstellen weiter zu suchen

Das macht mich schon wieder stutzig.

Erledigst Du das Ersetzen in einem Rutsch oder interaktiv, Absatz für Absatz?

Wenn InDesign irgendwann aufhören würde, bzw. sich "weigern" würde, weiterzusuchen, dann wäre das – weil nahezu unberechenbar (mal geht's, mal nicht) – ein noch größerer Bug als die Sache mit dem Caret-Zeichen.

Bitte sag, dass es sich um ein Missverständnis handelt. Wenn nicht, bitte ich Dich um eine Beispieldatei, in der sich diese Weigerung von InDesign, weiterzusuchen/-ersetzen reproduzieren lässt.

Zitat

„… aber ohne ^ bleibt dein Vorschlag stecken – dh. InDesign weigert sich nach einigen Fundstellen weiter zu suchen …“

Das macht für mich – genau wie für Martin – auch keinen Sinn. Und es widerspricht komplett meinen bisherigen Erfahrungen mit Greps dieser Art.

Zumindest in deiner Beispieldatei ( im „Kleinen“ nachgebaut) funktioniert alles problemlos. Aber genau das ist auch das Grundproblem mit selbstgebastelten Beispieldateien.

@Martin

Ja, ein Missverständnis – und nach einem Neustart von InDesign läuft Deine (?<=\r). perfekt durch alle Seiten. Auch die damalige (?<=\r)^(.) lief in einem Rutsch durch. Also das was der Kunde wünschte.

Stutzig wurde ich ja erst definitiv mit der eingangs beschriebenen «Fake-Übung»: Absatz-Beginn wird gefunden, und zwei von drei harten Zeilenschaltungen… – ooops, 2 von 3?

Das ^ zu diskutieren macht Spass … auch ich finde, dass der Absatzbeginn was anderes ist als eine Zeilenschaltung.
Aber eben – vielleicht existieren hier mir unbekannte Zusammenhänge, bspw mit MultilineMode? Oder sowas?


Liebe Grüsse und DANKE euch allen, Peter

Die Unschärfe bzw. Doppelbedeutung des "^" als Positionsmarke für sowohl einen Absatzbeginn als auch den Beginn einer neuen Zeile nach einer erzwungenen Zeilenschaltung (Shift-Return) ist nun meinerseits als Fehler beschrieben:

GREP position marker "^" = Beginning of Paragraph
(not beginning of a new line after a forced line break)

Mit unterstützenden Stimmen kann die Korrektur befördert werden.

gevotet

Super Martin – ebenfalls gevotet !

Prima!

Übrigens bin ich von jemanden auf einen (funktionierenden) Ausdruck für den Absatzbeginn aufmerksam gemacht worden:

Code

(?<!\n)^. 

Analog dazu lautet der Ausdruck für das Absatzende

Code

.$(?!\n) 

Man muss also einfach nach dem suchen, was man ursprünglich im Sinn hatte und dann \n ausschließen.
Quasi von hinten durch die Brust ins Auge.

Zitat

… Quasi von hinten durch die Brust ins Auge.

From behind through the chest into the eye.
[:D]

Nach einigem Nachdenken und Reflektieren muss ich jetzt feststellen, dass ich/wir den Schwanz mit dem Hund haben wedeln lassen.

Der eigentliche Fehler liegt nicht darin, dass sich das Caret-Zeichen ^ nicht auf den Absatzbeginn beschränkt und darüberhinaus auch den Beginn einer neuen Zeile berücksichtigt. Nein, der eigentliche Fehler liegt darin, dass Adobe diese Positionsmarke ^ als "Absatzbeginn" bezeichnet bzw. der Begriff "Absatzbeginn" eine gewisse Unschärfe in sich trägt. Und da diese Marke auch Positionen finden, die nicht Absatzbeginn sind, sondern Zeilenbeginn, weisen wir zu Recht auf eine Differenz zwischen Bezeichnung und Wirkung hin.

Unter einem Absatz verstehen wir eine Texteinheit, die zwischen bestimmten Begrenzern eingeschlossen ist:
– zwei Absatzschaltungen (RETURNs)
– Textanfang + Absatzschaltung
– Absatzschaltung + Textende
– Textanfang + Textende
(theoretisch könnte man nun auch die Trennung von Text durch Shift-Return [ein besonderes Return] als ein "Absetzen" = einen Absatz verstehen)

Computertechnisch hat sich diese "Sinneinheit" aus Begrifflichkeiten um die Schreibmaschine und den Telegrafen entwickelt: Wagenrücklauf (carriage return, cr) und Zeilenvorschub (line feed, lf).
Bei der Schreibmaschine war noch jede neue Zeile mit Beginn im Bereich des linken Rands mit einem handgreiflich verursachten Wagenrücklauf in Gemeinschaft mit einem Zeilenvorschub verbunden. Ein Absatz ("ab-setzen", hervorheben) wurde daraus erst mit einer besonderen Gestaltung: (Erst-)Zeileneinzug bzw. Leerzeile (vergrößerter Zeilenvorschub).
Tatsächlich war aber unter diesen mechanischen Bedingungen jede Zeile – unabhängig ob neuer Absatz oder nur neue Zeile – mit einem Zeilenvorschub verbunden.

Auf dem Computer haben sich mit verschiedenen Betriebssystemen dann unterschiedliche Bezeichnungen und Codierungen für den Zeilenvorschub entwickelt:

Zitat von https://de.wikipedia.org/wiki/Zeilenvorschub

In den verschiedenen Betriebssystemen wurde aber uneinheitlich verfahren. Bei manchen wurde die Interpretation der typografischen Absatzmarke (¶ Pilcrow) durch die Zeichenkette CR LF (entspricht ASCII 0x0D 0x0A) unverändert weitergenutzt – so etwa bei CP/M, DOS und Windows (und damit auch in Texteditoren wie Notepad) – bei anderen, namentlich Unix und Unix-artigen Systemen, wurde dieser auf das einzelne Zeichen LF Line Feed (den hier thematisierten Zeilenvorschub) gekürzt, unter klassischem Mac OS hingegen auf das einzelne Zeichen CR Carriage Return (den Wagenrücklauf). Und wieder andere Systeme kennen ein eigenes Zeichen NL oder NEL (engl. für New Line oder Next Line) oder ein Zeichen EOL (engl. für End of Line). Aus diesem Grund ist der Austausch von Textdateien zwischen unterschiedlichen Betriebssystemen erheblich erschwert. Viele Programme (zum Beispiel Browser) akzeptieren daher jedes dieser Steuerzeichen als Zeilenvorschub, auch wenn dies technisch nicht ganz korrekt ist. In anderen Programmen unterscheiden CR und LF das Absatzende ¶ und den harten Zeilenumbruch _| oder den Spaltenumbruch.

Langer Rede kurzer Sinn:
^ sucht nicht nach einem Absatzbeginn, wie die Bezeichnung, die Adobe dafür gewählt hat, nahelegt, sondern nach einem per Tastatur vorgenommenen Zeilenbeginn - egal ob nun ein Return oder ein Shift-Return eingegeben wurde.

Insofern führt die GREP-Suche genau das aus, wofür das ^ im Kontext der regulären Ausdrücke steht: Position Zeilenanfang. Wobei dieser "Zeilenanfang" nicht jeden Zeilenanfang (weicher Umbruch) einschließt, sondern nur solche, die durch ein entsprechendes Zeichen (Return oder Shift-Return) oder durch den "Textbeginn" veranlasst wurden.

Der Fehler liegt also nicht in der tatsächlichen Wirkung,
sondern in der irreführenden Bezeichnung.

Insofern stellen die beiden Ausdrücke

Code

(?<!\n)^. 

und

Code

.$(?!\n) 

nicht eine überflüssige oder vermeidbare Umschweife dar, sondern vielmehr eine Präzisierung/Vergenauerung des Zeilenvorschubzeichens (nicht nach/vor dem \n; also nur nach dem damit verbleibenden \r).

Für die lange Ausführung bitte ich um Entschuldigung. Mitunter bedarf es eines weiten Rundumschlags, um sich selbst von falschen Überzeugungen zu befreien. ;-)

(Konsequenterweise müsste ich eigentlich meinen Bugreport jetzt löschen oder die o.g. Ausführungen dorthin übersetzen lassen. Denn u.U. bedeutete eine Änderung der Wirkung von ^ einen Fehler im Hinblick auf die Konventionen andernorts ... Was tun?)

Danke für die lange Erklärung. Find ich super und wirklich informativ.

Antwort auf:

(Konsequenterweise müsste ich eigentlich meinen Bugreport jetzt löschen oder die o.g. Ausführungen dorthin übersetzen lassen. Denn u.U. bedeutete eine Änderung der Wirkung von ^ einen Fehler im Hinblick auf die Konventionen andernorts ... Was tun?)

Vielleicht einfach eine Korrektur der Übersetzung bzw. eine korrekte Benennung vorschlagen ;-)

Es bleibt aber – wenn ich die Diskussion richtig verfolgt habe – immer noch die Frage, warum die Grepsuche in Indesign 15 in dem Beispiel von Peter Laely je Absatz nur 2 von drei Fundstellen auflistet. Das finde ich beunruhigend und ich frage mich, was mir bei der Bereinigung von sehr langen Dokumenten wohl noch durchgeht …

Antwort auf:

warum die Grepsuche in Indesign 15 in dem Beispiel von Peter Laely je Absatz nur 2 von drei Fundstellen auflistet.

Das war m.E. einmal der experimentellen Einrichtung des Beispiels geschuldet (\n\n\n\r\n\n\n\r\n\n\n\r...), das so in der Realität eher nicht vorkommen dürfte.

Und dann war es der Tatsache geschuldet, dass nach der Positionsmarke allein und nicht in Kombination mit weiteren Zeichen (. oder \w) gesucht wurde.
Hier landen (wie gezeigt) unterschiedliche InDesign-Versionen unterschiedliche Ergebnisse.

Wenn Du bei der Suche die Positionsmarke mit weiteren Zeichen kombinierst sollten diese Unterschiede bei den Treffern nicht mehr erscheinen.

Aber - wie oben bei Peter gesehen - passieren manchmal auch unvorhergesehene Dinge, die sich durch einen Neustart des Programms oder des Rechners abstellen lassen.

Ich schließe mich an.
Egal ob fehlerhafte Übersetzung oder fehlerhafte Ausführung – eine Frage bleibt.

Warum findet:

Code

^ 

oder

Code

(^(\r|\n)) 

alle Absatzschaltungen und meistens einen Zeilenanfang – aber in dem eingangs genannten Beispiel NICHT den ersten nachfolgenden Zeilenanfang nach einer Absatzschaltung ???



[edit]
Ich war zu langsam,
du hattest schon geantwortet.
Das Problem an experimentellen Fehlern ist, dass sie dann im täglichen Alltag unverhofft wieder auftauchen.
[/edit]


.

Ja, es ist mir schon klar, dass es ein gestelltes Beispiel ist, aber man sollte nie die Kreativität der Ersteller/Bearbeiter von Word- oder Indesign-Dateien unterschätzen. Da liegt auch das gestellte Beispiel nicht außerhalb der Realität und bei der weiteren Bearbeitung/Bereinigung der Daten benötigt man manchmal ausgefallene, komplexe oder eben ganz simple Suchterme, wie einen einzelnen "Absatzbeginn".

Und wenn nicht alle Fundstellen gelistet werden, hinterlässt das einen Nachgeschmack und verunsichert.

Gerade bei sehr umfangreichen Dateien und "vermurksten" zugelieferten Daten möchte man sich doch auf die Suchen verlassen können.

Mir ist das Suchergebnis bei Peter Laelys Beispiel zu reproduzierbar um als zufällig zu gelten. Warum findet die Suche nach dem "Absatzbeginn" diesen direkt nach der Absatzschaltung nicht (also dort, wo der Absatz tatsächllich beginnt)? Sondern nur jeweils nach einer harten Zeilenschaltung?