GNU bug report logs - #72241
31.0.50; [PATCH] Use a dedicated buffer for `doc-view-open-text'

Previous Next

Full log

View this message in rfc822 format

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 72241 <at> debbugs.gnu.org
Subject: bug#72241: 31.0.50; [PATCH] Use a dedicated buffer for `doc-view-open-text'
Date: Tue, 23 Jul 2024 10:10:32 +0200

Tassilo Horn <tsdh <at> gnu.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Tassilo Horn <tsdh <at> gnu.org>
>>> Date: Mon, 22 Jul 2024 20:11:34 +0200
>>> 
>>> I'm not sure if a NEWS entry is needed for that change.  It certainly
>>> changes existing behavior but not in a way that usage patterns/muscle
>>> memory would need to be adapted...
>>
>> Can you tell in what way the behavior will change after this?  I'd
>> like to think whether a NEWS entry is necessary and what to day there.
>
> Right now, when you open foo.pdf you see the images generated from the
> PDF.  When you do C-c C-t, it'll replace the foo.pdf buffer contents
> with the plain text contents of the PDF.  With another C-c C-c, the
> contents are again replaced with the PDF and you see the images again.

FWIW, this is not the current behaviour that I see:

      - C-c C-t replace the buffer contents with the text version
      
      - C-c C-c, DocView switches back to the "edit" view: the raw
        content of a PDF for instance is displayed into the buffer.

      - another C-c C-c, DocView switches to the "display" view where
        you see the images again

Maybe while here, we should clarify how DocView cycles through those 3
view: display, edit and text.  Or maybe, there is no 3-states cycling
and the "text contents" view is just considered a "side" view.  WDYT?
-- 
Manuel Giraud

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.