Re: isearch for doc-view.el

[Tassilo Horn <tassilo@member.fsf.org>]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> After spending quite some time to make isearch working I have given
>> up.  It seems to be rather complicated, so I only changed the current
>> search facility to use an isearch-like UI.  Now you hit C-s and enter
>> the regexp and each additional C-s or C-r jumps to the next/previous
>> match.  To enter a new regexp, you have to provide a prefix arg to
>> C-s or C-r.
>
> The patch you sent earlier seemed to work (more or less), so please
> add a big comment in the code describing as much as you can of your
> experience: what you did and what were the problems you encountered.

I attach the latest version of doc-view.el using the isearch approach.
The problem was that the function doing the search
(doc-view-search-forward) was called in a loop when entering something
at the isearch-prompt, e.g. I enter "p" at the prompt and then
isearch-search-string calls the function in isearch-search-fun-function
(doc-view-isearch-function) which calls doc-view-search-forward
endlessly.  I don't know why, but I don't know how isearch works
exactly.

But even if we'd get that working no real isearch feeling comes up due
to the missing match highlighting.  Currently I display all lines
containing a match in a tooltip and each C-s or C-r jumps directly to
the next/previous page with a match.  With isearch we could only display
the current match.  So we had to decide if another C-s jumps to the next
page with a match (thus only the first match in a page will be displayed
in a tooltip) or to the next match, which would do nothing visible
(except the tooltip) if the next match is on the same page.

And it's much slower than the current search facility, because isearch
really searches for each step forward or backward wheras the current
approach searches once and then it knows to which pages to jump.


[-- Attachment #2: doc-view.el --]
[-- Type: application/emacs-lisp, Size: 32896 bytes --]

[-- Attachment #3: Type: text/plain, Size: 699 bytes --]


>> Then I tried fixing the auto-compression-mode bug Reiner poined out
>> in <v9640nx9n9.fsf@marauder.physik.uni-ulm.de>.  Because I could not
>> find an elegant solution to work with compressed files transparently
>> I took a trivial approach: doc-view-mode now offers to save the
>> uncompressed file somewhere and then this file is viewed.
>
> A possibly related problem is when the buffer's content is not in-sync
> with the file's: doc-view "should" then show the rendition of the
> buffer's content rather than the file's.

I don't get you.  When you edit the document in an editing mode and hit
`C-c C-c' you'll be queried to save the changes before the conversion is
started.

Bye,
Tassilo

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel