Text editor search (not "Search and Replace")

Previous topic - Next topic

deifert

Unless I've missed something, it appears that Scribus lacks something absolutely fundamental to any application that aspires to wrangle words and images.  If I am working with a long document or a multi-chapter document, I will on a routine basis need to search for specific sections of text in order to make edits and changes.   I would expect in Scribus to open the text editor on any given chain of text columns, search for my text block, make the changes within the text editor, and then select "Update text frame and exit", whereupon I would be looking at the page where I finished the edits with the cursor blinking at the point within the text frame where I exited.

Have I missed something obvious?  I've worked with everything from the ancient Ventura Publisher and Calamus up through Adobe InDesign, and  this is a standard feature for long document management.  Is there a Scribus workaround?  Has anyone had any experience with managing multi-chapter projects in Scribus and can share their solutions?

Thanks in advance for any information ...

-- Darrell

a.l.e

if you double click on a text frame and edit there your text (with the "windows > properties" palette open) you will be exactly there where you edited when you finish editing...

the text editor, well, don't expect too much from it...

GarryP

#2
Darrell, what you've said sounds quite obvious but it doesn't take multiple edits into account.

If you make changes in two (or more) places in the text, each change being something that modifies the text that is seen in different frames on different pages, which frame/page would you expect to be looking at once the editing was complete?

You said you want to be "where [you] finished the edits" but is this the location of where the editing last occurred or the location of the edited text furthest through the text? Do you mean "last in time" or "last in position"?

For a very basic example, given the text "So long and thanks for all the fish.", if you changed "fish" to "food" and then changed "thanks" to "cheers", would you expect to be looking at the end of "food" or at the end of "cheers"? They can both be called "the last edited text" but in different contexts.

I think you're right that Scribus should try to put you somewhere where you can see what's changed but for multiple edits that effect many pages, how would Scribus choose where to put you? How does Scribus know which edit is most "important"? Different people would expect different things in different circumstances and either way is going to be wrong for some people some of the time.

What do other applications do in these cases?

Nermander

The logical place to end up is of course where the cursor is (or just was).

a.l.e

I don't that moving the cursor (and view) to the right place is really a hard thing.

But letting all things as they are is IMO a very sane behavior and I can think that many people would be surprised if the view suddenly moves when they close the story editor.

Anyway, I see little chances that somebody steps up, makes her hands dirty and works on changing the current behavior.
But I will  not be unhappy to be contradicted... most of all if somebody starts specifying / programming a new and modern story editor!

deifert

Quote from: GarryP on June 09, 2016, 10:32:34 AM
Darrell, what you've said sounds quite obvious but it doesn't take multiple edits into account.

If you make changes in two (or more) places in the text, each change being something that modifies the text that is seen in different frames on different pages, which frame/page would you expect to be looking at once the editing was complete?

You said you want to be "where [you] finished the edits" but is this the location of where the editing last occurred or the location of the edited text furthest through the text? Do you mean "last in time" or "last in position"?


A very reasonable thought.  But in my experience, when I have begun to edit a document with extensive textual changes, I will always check the visual results for every edit to see if margins, widows / orphans, indents, etc. have been affected.  I may also make several changes to multiple pages, but I always want to see the end result of those changes, which is usually at the final cursor point, then paging back to see the sequence of changes.

The text editor is an excellent tool for making fast edits using a set of predefined styles, starting from page 1 and searching for the text to be changed.  But if I make a change "somewhere deep in the document" and then exit the editor, I am back to the beginning.  I will have to rather tediously scroll through the pages until I happen upon the edits and see the results. 

Even a simple visual cue in the editor to tell me on which page I'm editing would be helpful - I could then jump directly to that page after exiting the editor.

Another solution would be to mimic what most WP and DP programs do, and that is while the cursor is active in a text frame (normal mode) a text / properties search box will take me to the page where the text needs to be changed, and edits can be made directly on that page without entering the editor.  I've attempted to use the search box / Cntrl+F while in an active text frame, but nothing appears to happen.  What I would expect is something like  "jump to the page containing my search string and highlight it in blue".

Failing any of this, what about a simple check box in Preferences? "Update text frame and exit at cursor position"  /  "Update text frame and exit" (default)

Again, thank you to all who took the time to weigh in on this ...

-- Darrell

Nermander

I think the whole point with the introduction of the story editor was to be able to edit a complete text story without having to mess with pages.

The story editor gives you the text in one flowing story, no page breaks, no different column widths, one column of text even if the frame is two column etc.

From the beginning I think it was not even possible to edit text directly on the canvas. But today text can be edited directly on the canvas, and the story editor have been more or less abandoned by the developers. If I don't recall wrong it has even been considered for removal (but many users asked it to be left).

So yes, the current situation is not anywhere near optimal. But the story editor would need a huge rewrite. And editing on the canvas should be made as easy as in the story editor. But that is most likely several versions into the future. For the story editor I don't even think someone has a plan.


a.l.e

well, nermander: the story editor has been indeed created while it was not possible to edit the text in the frame.

and one can still feel that :-(

imo it should indeed be removed.
and replaced later by a new story editor that is thought for power users.
for the beginners, we should focus on optimizing their experience of the in frame editing.

currently, afaik the only real use case, where it's worth to start the current story editor is when a text frame is "badly" rotated... in all other cases, i'm better served by the text frame (and for the cases where i'm not i expect the devs to improve the user experience in the frame!).

but there are users who have never learned to double click on a frame and are scared of losing something. (and a few power users who indeed use the story editor in edge cases, are happy that it exist, but want a power story editor).

amen.

deifert

Quote from: Nermander on June 10, 2016, 10:53:08 AM
But today text can be edited directly on the canvas, and the story editor have been more or less abandoned by the developers.

And editing on the canvas should be made as easy as in the story editor. But that is most likely several versions into the future.

Again, perhaps I am missing something obvious, but it appears that in such an incredibly powerful program there is no way do do the simplest of word processor functions, i.e.

1) Set your cursor in a text frame on page 1.
2) Open a search box and enter a word, phrase or text attribute
3) See / land on the page containing your search string with the text highlighted and ready for editing (probably around page 64 - I don't know the page number, that's why I attempted to use the 'search' function).

Seriously, am I really the only person who needs to do this?  Do people actually scroll back and forth through their documents looking for the place to start an editing session?

a.l.e

You're not the only person wanting this.

But nobody, until now, was so in need of it to be ready to pay somebody for programming it... or to program it herself...

Well, not nobody: Cezary has programmed it: http://www.scribus-ece.info/ ... but for a reason unknown to me, it was never integrated into Scribus.

That being said, i'm currently working on implementing the table of contents (also based on Cezary's work) and once that is done, i can think that it should be easy to use the same code to also add a simple search (and maybe replace) plugin.
(A table of contents is some sort of search :-)

deifert

Quote from: a.l.e on June 18, 2016, 05:35:06 PM
You're not the only person wanting this.

But nobody, until now, was so in need of it to be ready to pay somebody for programming it... or to program it herself...

Well, not nobody: Cezary has programmed it: http://www.scribus-ece.info/ ... but for a reason unknown to me, it was never integrated into Scribus.

That being said, i'm currently working on implementing the table of contents (also based on Cezary's work) and once that is done, i can think that it should be easy to use the same code to also add a simple search (and maybe replace) plugin.
(A table of contents is some sort of search :-)

Many thanks for your current work towards a solution .. I was unaware that Cezary had worked on the problem.  Is there any way (without being a pest) that users can lobby the Scribus development team to look again at adopting that feature?

Best,
-- Darrell

a.l.e

hi darrel,

no, lobbying does not help that much.

but users can help out!
i know, that's much more demanding than a +1 button, but scribus currently needs people getting their hands dirty... cheering efforts are nice but won't make scribus improve.

i don't know what you're good at, but i'm sure that scribus can use your skills! :-)
(and, no, not everybody has to contribute. just being a user is also fine... but since you asked...)

deifert

Quote from: a.l.e on June 20, 2016, 09:19:15 AM
hi darrel,

but users can help out!
i know, that's much more demanding than a +1 button, but scribus currently needs people getting their hands dirty... cheering efforts are nice but won't make scribus improve.

A very good point, but in this case it appears that someone else has already written the code for the function that I would like to see implemented.  If I was able to write or pay for duplicate code, would I have any better luck in seeing that code accepted?

-- Darrell

a.l.e

cezary's code seems not to be in a shape that it allows putting it as is in the scribus code.

and there are lot of things people can do beside paying and programming... (but without programming, of course, a project like scribus cannot improve :-)