all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: { SPAM 2 }::Re: Proposed new minor mode
Date: Sat, 7 Jun 2003 08:52:12 -0500 (CDT)	[thread overview]
Message-ID: <200306071352.h57DqCD29459@eel.dms.auburn.edu> (raw)
In-Reply-To: <x5smqmjh9k.fsf@lola.goethe.zz> (David.Kastrup@t-online.de)

David Kastrup wrote:

   Sure, but if we have an inconsistency there, the solution is to fix it
   instead of providing a command nobody would ever think of using,
   because it only uglifies the current buffer and does not cause
   anything different to be yanked to the destination buffer.

I actually agree with this.

However, people have argued that the hidden information is so
important that it should _never_ be hidden.  Other people, including
you, have argued that it is so unimportant it should be erased.  Not
erasing it, but making it invisible is a compromise solution.  But
that compromise makes no sense if you do not support it.  The `v'
command I propose would allow an extremely easy hiding and reappearing
of that information.  To me, it seems to work instantaneously, it is
not slow stuff like an inflatable airbag.  Saying that nobody would
ever use the mode in info for anything else than debugging purposes
(although I actually do find it very useful while debugging
invisibility related stuff in all kinds of situations) is more or less
arguing that the information in question is of no interest to anybody.
(In which case it should be erased, not hidden).  But, some people
find it interesting enough to set Info-hide-note-references to nil.
This command would seem to me to provide some kind of "best of both
worlds".

    because it only uglifies the current buffer

The fact that it uglifies the buffer to the extent it does is due to
imperfections in Stefan's implementation.  I believe these could be
fixed.  (But that would make no sense if we would decide to go for
deletion.)  The "only" means that you consider the hidden text
useless.  Not everybody agrees with that.  I personally have no strong
opinions on the subject.

    and does not cause anything different to be yanked to the
    destination buffer.

But hiding that text instead of deleting it means that you _want_ the
text to be yanked, you _want_ the text to be copied to files, you
_want_ the text to be printed out to hardcopy.  Fine.  But then the
user has to know it is there and needs convenient access to it.

    Sure, but if we have an inconsistency there, the solution is to
    fix it

Of course, the only question is in which direction.  I know and
respect your opinion on the matter.  Other people have other
opinions.  I actually can live with all of them, all the way from
Robert's to yours, let us just be consistent.

If we go for hiding, rather than outright deletion or outright visible
inclusion, I believe that consistency means easy toggling.

Sincerely,

Luc.

  parent reply	other threads:[~2003-06-07 13:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-07  1:51 Proposed new minor mode Luc Teirlinck
2003-06-07  1:57 ` Luc Teirlinck
2003-06-07  6:55 ` David Kastrup
2003-06-07  9:13   ` Eli Zaretskii
2003-06-07 10:30     ` Luc Teirlinck
2003-06-07 10:47       ` David Kastrup
2003-06-07 11:59         ` Luc Teirlinck
2003-06-07 13:52         ` Luc Teirlinck [this message]
2003-06-07  9:52   ` { SPAM 2 }::Re: " Luc Teirlinck
2003-06-07 12:20   ` Miles Bader
2003-06-07  9:11 ` Eli Zaretskii
2003-06-07  9:45   ` Luc Teirlinck
2003-06-08  1:09 ` Richard Stallman

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

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

  git send-email \
    --in-reply-to=200306071352.h57DqCD29459@eel.dms.auburn.edu \
    --to=teirllm@dms.auburn.edu \
    --cc=emacs-devel@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.