From: "Richard M. Stallman" <rms@gnu.org>
Cc: emacs-devel@gnu.org, miles@gnu.org
Subject: Re: fringe buffer-boundary bitmaps
Date: Fri, 24 Jun 2005 20:31:25 -0400 [thread overview]
Message-ID: <E1DlyZx-000469-AG@fencepost.gnu.org> (raw)
In-Reply-To: <m3vf44noav.fsf@kfs-l.imdomain.dk> (storm@cua.dk)
I understand that, but I don't see why we need two different ways to
modify them -- you can redefine the standard bitmap directly, so I
don't see why do we need an extra level of indirection here (which has
to be done at the C level to an already quite complex piece of code).
Currently, what we have are standard bitmaps for "bob-left",
"bob-right", "eob-left", "eob-right" etc...
But, rather than following the existing pattern of naming them after
their purpose (like "continuation-line", "left-truncation" etc), I
have named them after their visual appearence, e.g. "top-left-angle",
"top-right-angle", "bottom-left-angle", etc...
That is a bug IMO, so I agree with Miles that those names should be
changed to match their purpose rather their appearence.
I would not say we "need" the extra level--that word is too
strong--but I think it would be cleaner.
It would be cleaner to name each bitmap after what it looks like, such
as top-left-angle, then specify by name one of these bitmaps to use
for a given purpose, such as beginning-of-buffer.
It's like defining a function with your own choice of name and then
putting that name in a hook or variable with a standard fixed name,
instead of redefining a function with a fixed name.
next prev parent reply other threads:[~2005-06-25 0:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-22 0:51 fringe buffer-boundary bitmaps Miles Bader
2005-06-22 6:28 ` Miles Bader
2005-06-22 7:28 ` Miles Bader
2005-06-22 22:52 ` Kim F. Storm
2005-06-22 12:49 ` Robert J. Chassell
2005-06-23 0:19 ` Miles Bader
2005-06-23 7:45 ` Kim F. Storm
2005-06-23 8:05 ` Miles Bader
2005-06-23 21:14 ` Robert J. Chassell
2005-06-24 5:35 ` Richard M. Stallman
2005-06-22 22:48 ` Kim F. Storm
2005-06-22 15:42 ` Richard M. Stallman
2005-06-23 8:03 ` Kim F. Storm
2005-06-24 5:36 ` Richard M. Stallman
2005-06-24 8:37 ` Kim F. Storm
2005-06-25 0:31 ` Richard M. Stallman [this message]
2006-02-20 22:38 ` Kim F. Storm
2006-02-21 6:44 ` Miles Bader
2006-02-21 11:12 ` Giorgos Keramidas
2006-02-21 11:40 ` Kim F. Storm
2006-02-21 12:21 ` Giorgos Keramidas
2006-02-21 14:55 ` Chong Yidong
2006-02-22 5:24 ` Richard M. Stallman
2006-02-23 23:45 ` Juri Linkov
2006-02-24 13:45 ` Kim F. Storm
2006-02-24 23:27 ` Juri Linkov
2006-02-24 19:40 ` Richard Stallman
2005-06-22 19:03 ` Markus Gritsch
2005-06-22 22:43 ` Kim F. Storm
2005-06-23 9:53 ` Lute Kamstra
2005-06-23 10:08 ` Miles Bader
2005-06-23 12:18 ` Lute Kamstra
2005-06-23 13:49 ` Juanma Barranquero
2005-06-23 13:59 ` Juanma Barranquero
2005-06-23 15:15 ` Luc Teirlinck
2005-06-23 15:35 ` Juanma Barranquero
2005-06-23 18:20 ` Luc Teirlinck
2005-06-23 22:15 ` Juanma Barranquero
2005-06-24 14:12 ` Stefan Monnier
2005-06-23 15:23 ` Luc Teirlinck
2005-06-24 5:36 ` Richard M. 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
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=E1DlyZx-000469-AG@fencepost.gnu.org \
--to=rms@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=miles@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.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).