emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: emacs-orgmode@gnu.org
Subject: bug: isearch creates useless ellipses
Date: Tue, 21 Aug 2012 10:01:27 -0700	[thread overview]
Message-ID: <CAJcAo8tZ+8htWaH0u+0gVkArVB+M+RorCqJ9EyQGcoo6Lu5cYg@mail.gmail.com> (raw)

This is likely not a quick fix.

When an Org file is folded, and I do isearch on a string in the body,
then press RET, the very first line gets ellipses.

Here is an example.  Iniitially the buffer might be like this:

=== beginning of window
* blog...
=== end of window

Point is at beginning of buffer.

That is expected because the entire subtree is folded.

Then I search for "sloppy emulsion" and press RET.

I get this:

=== beginning of window
...
******* Above all
Above all, it is a collapse of the uneasy and corrupt
identification of science -- that principled, unbiased, at
times necessarily subversive, transparent, open-minded, and
often selfless search for natural reality -- with rank
authority.  The sloppy emulsion of water in oil.
=== end of window

Note the "..." on the first line.  (Above that is merely ordinary body
text in a sibling.)

This hides things that do not need hiding (because we know that there
are lines above the top of the window), is highly distracting, and
reduces the number of lines visible by a significant amount for people
with small monitors, mobile devices, or very large fonts.  (You might
need to set near-maximum font sizes to reproduce.)

Over many years, I have of course tried org-show-* variables, isearch
hooks, and many other things to try to solve this and related
problems.

To give you some context, my visibility goal with Org is to *always*
have the buffer show what can be generated using TAB and movement
commands alone.  I call this canonical visibility.

In addition, showing ellipsis on a line by themselves at the top or
bottom of the window as a result of isearch or a similar operation is
non-canonical.

Canonical visibility throughout all of Org, including all corner cases
like jumping from agenda and isearch, does not seem to be possible.

(org-reveal t) seems to create those ellipses, or at least used to.

It might be an Emacs bug, not an Org one, but I have reached my limit in
trying to fix this.  There will certainly be somebody on this
list who knows more about how visibility is accomplished in Org.

I don't know if anybody will be able to reproduce this particular
non-canonicality as it might be a specific OSX implementation issue.

Thanks.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

                 reply	other threads:[~2012-08-21 17:01 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJcAo8tZ+8htWaH0u+0gVkArVB+M+RorCqJ9EyQGcoo6Lu5cYg@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).