From: "Drew Adams" <drew.adams@oracle.com>
To: 10040@debbugs.gnu.org
Subject: bug#10040: 24.0.91; isearch.el - binding of user options
Date: Sun, 13 Nov 2011 11:26:45 -0800 [thread overview]
Message-ID: <6857C0631DA84C638B3B9FA7F89B90D6@us.oracle.com> (raw)
1. I do not hold, as Emacs Dev apparently does (at least has in the
past), that code should never bind user options. Especially user code
and 3rd-party code. Code is, after all, one way for users to express
their preferences.
2. But doing so is supposedly a no-no from your point of view, based on
preaching I've heard from you over the years.
3. And yet you do it, so perhaps you would like to consider code where
you do it as bugs. Assuming that, let me help by pointing out that you
do it in each of the Isearch help commands: isearch-help-for-help,
isearch-describe-bindings, and isearch-describe-key. The user options
you let-bind are `same-window-names' and `same-window-regexps'.
4. Just as you apparently find a "need" to do this here, so
user/3rd-party code can sometimes find it convenient to bind user
options.
In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600) of 2011-11-07 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.6) --no-opt --cflags
-I"D:/devel/emacs/libs/libXpm-3.5.8/include"
-I"D:/devel/emacs/libs/libXpm-3.5.8/src"
-I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include"
-I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include"
-I"D:/devel/emacs/libs/giflib-4.1.4-1/include"
-I"D:/devel/emacs/libs/jpeg-6b-4/include"
-I"D:/devel/emacs/libs/tiff-3.8.2-1/include"
-I"D:/devel/emacs/libs/gnutls-2.10.1/include" --ldflags
-L"D:/devel/emacs/libs/gnutls-2.10.1/lib"'
next reply other threads:[~2011-11-13 19:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-13 19:26 Drew Adams [this message]
2011-11-15 19:17 ` bug#10040: 24.0.91; isearch.el - binding of user options Juri Linkov
2011-11-22 18:53 ` Juri Linkov
2011-11-22 22:36 ` Stefan Monnier
2012-11-04 3:26 ` Chong Yidong
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=6857C0631DA84C638B3B9FA7F89B90D6@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=10040@debbugs.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).