unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: floyd@barrow.com (Floyd L. Davidson)
Subject: Re: Newbie: Interactive goto-line ?!
Date: Thu, 26 Feb 2004 11:47:26 -0900	[thread overview]
Message-ID: <87ad35va8x.fld@barrow.com> (raw)
In-Reply-To: x5u11dpupb.fsf@lola.goethe.zz

David Kastrup <dak@gnu.org> wrote:
>Jesper Harder <harder@myrealbox.com> writes:
>>
>> I agree.  Which begs the question: Why on earth is it turned _off_
>> by default?
>
>I have it turned off.  I use Emacs mostly for TeX programming, and
>there its competence in analysing complex TeX documents is not
>convincing (complex TeX documents can hardly be tackled by anything
>but TeX, since syntax categories in this macro language change on the
>fly).
>
>I am exposed to large amounts of text all the time.  The contrast on
>screen is already much lower than on paper, I need not lower it more
>artificially.  In a typical TeX macro document, more than half of the
>important text consists of comments.  Making those less readable by
>casting them into some weird color is contraproductive.

This is indeed a significant problem.  I've tried, with no
success, to find a way to change font-lock face colors when
switching between major modes.  That is because what for me is
appropriate for C or Lisp programming is one set, which just
makes TeX too hard to look at, or the other way around.  I can
manage to set up manually invoked reconfigurations of face
properties, but I've not had any luck at all trying to change
them automatically when switching from one buffer to another
where different major modes are being used in the two buffers.

That is something I would really like to have.

>Colored text is also disadvantaging people with reading disabilities.
>Using a full-contrast display at the start for configuring an
>unreadable one is easier than using an unreadable one for configuring
>a full-contrast display.

!!  However, I'm somewhat the opposite, and try to avoid eye
strain by reducing the contrast, or even more, by reducing the
overall brightness of the screen (I can't tolerate a white
background for very long, as an example).  Yet widely varying
levels of contrast between different colored text is just
extremely annoying to me.  So the trick is to find different
color combinations that are about the same level of contrast for
any text that I want to read.  Then I choose low contrast for
text that I want to become invisible yet available to verify
that it does exist (but does not need to be actually read).  And
I want only things that need immediate attention to be either
bright or high contrast.  If I want to force my attention to it
immediately, it can be bright white or bright red, because I
can't stand having either of them on the screen!

>On of the few customizations I use when testing things with XEmacs is
>to turn off its default font lock mode.

Regardless, the idea that next-error eliminates the need for
using goto-line is only true for people doing certain kinds of
editing.  It is great for C programming, but even there it
doesn't solve all problems (and the suggestion that the
compilation buffer is still available is ridiculous compared to
the ease of using M-g for goto-line).

I think the significance of all this is that we all use a
very configurable editor *because* we do so many different things
in so many different ways.  It doesn't bother me a bit that GNU
Emacs uses one binding for M-g and XEmacs uses a different binding,
because in either case it is easy to bind M-g to whatever I want.

I do take offense at someone suggesting that M-g should not be
rebound to goto-line (or whatever).  Bindings aren't sacred at
the user level.  And command usage varies with each user and
with the type of work being done.

--
Floyd L. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com

  reply	other threads:[~2004-02-26 20:47 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-24 10:55 Newbie: Interactive goto-line ?! Karel Kubat
2004-02-24 10:58 ` Maurizio Loreti
2004-02-24 11:42   ` Gian Uberto Lauri
2004-02-24 16:08     ` Brad Collins
2004-02-24 11:00 ` Karel Kubat
2004-02-24 11:34 ` Jiri Pejchal
2004-02-24 22:21   ` Johan Bockgård
2004-02-24 18:35 ` Floyd Davidson
2004-02-24 21:01   ` Kevin Rodgers
2004-02-24 23:38     ` Floyd Davidson
2004-02-25  5:33       ` Eli Zaretskii
2004-02-25 16:47       ` Kevin Rodgers
2004-02-25 17:35         ` Floyd Davidson
     [not found]       ` <mailman.436.1077687252.340.help-gnu-emacs@gnu.org>
2004-02-25  6:31         ` Floyd Davidson
2004-02-25  8:56           ` Kai Grossjohann
2004-02-25 10:05           ` Eli Zaretskii
     [not found]           ` <mailman.452.1077703465.340.help-gnu-emacs@gnu.org>
2004-02-25 16:29             ` Floyd Davidson
2004-02-26 17:32               ` Eli Zaretskii
     [not found]               ` <mailman.580.1077816762.340.help-gnu-emacs@gnu.org>
2004-02-26 17:50                 ` Jesper Harder
2004-02-26 18:22                   ` David Kastrup
2004-02-26 20:47                     ` Floyd L. Davidson [this message]
2004-02-27  9:17                       ` Alan Mackenzie
2004-02-27 12:56                         ` Eli Zaretskii
2004-02-27 15:17                         ` Johan Bockgård
2004-02-27 15:29                           ` David Kastrup
2004-02-27 16:04                             ` Johan Bockgård
2004-02-29 15:29                       ` Kai Grossjohann
2004-03-01  4:07                         ` Floyd L. Davidson
2004-03-01  4:47                           ` Johan Bockgård
2004-03-01  6:12                             ` Floyd L. Davidson
2004-02-27 16:42                     ` Stefan Monnier
2004-02-27 16:58                       ` David Kastrup
2004-02-27 18:07                         ` Stefan Monnier
2004-02-27 18:22                           ` David Kastrup
2004-02-27 20:46                             ` Stefan Monnier
2004-02-26 19:03                   ` Eli Zaretskii
     [not found]                   ` <mailman.586.1077822322.340.help-gnu-emacs@gnu.org>
2004-02-26 19:28                     ` David Kastrup
2004-02-26 21:25                       ` Kevin Rodgers
2004-02-27 12:59                       ` Eli Zaretskii
     [not found]                       ` <mailman.648.1077887747.340.help-gnu-emacs@gnu.org>
2004-02-27 16:47                         ` Stefan Monnier
2004-02-27 17:56                           ` Eli Zaretskii
2004-02-26 17:36             ` Dan Katz
2004-02-25 17:58         ` Stefan Monnier
2004-02-26  6:04           ` Eli Zaretskii
     [not found]           ` <mailman.541.1077775437.340.help-gnu-emacs@gnu.org>
2004-02-27 16:31             ` Stefan Monnier
2004-02-27 17:59               ` Eli Zaretskii
2004-02-25 18:01       ` Stefan Monnier
2004-02-26  7:08         ` Kai Grossjohann
2004-02-26 19:38           ` Alan Mackenzie

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.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=87ad35va8x.fld@barrow.com \
    --to=floyd@barrow.com \
    /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.
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).