From: Paul Eggert <eggert@cs.ucla.edu>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: Tom Tromey <tromey@redhat.com>, Chong Yidong <cyd@gnu.org>,
12215@debbugs.gnu.org, Dmitry Antipov <dmantipov@yandex.ru>
Subject: bug#12215: CSET is unnecessarily confusing
Date: Fri, 24 Aug 2012 17:17:41 -0700 [thread overview]
Message-ID: <503819A5.10908@cs.ucla.edu> (raw)
In-Reply-To: <jwvsjbc6lu2.fsf-monnier+emacs@gnu.org>
On 08/24/2012 02:12 PM, Stefan Monnier wrote:
> I'm actually quite happy keeping xVAR accessor macros ... and xSET
> setter macros ..., to make it easier to experiment on branches.
Ah, sorry, I misunderstood. But still, currently the people
who are actually doing those experiments (Dmitry, Tom) don't
need these macros and don't particularly want them. And
Chong is calling BVAR "horrible". And I too would rather
avoid these macros absent a proven need for them. If
there's anything that Dmitry's and Tom's experiences have
shown, it's that speculative changes often don't pan out.
We currently have a patch that will get rid of the setters
and of the xVAR and xSET macros, reverting to the pre-23.3
coding style. With some more work, I can change this patch
to keep the BVAR and KVAR macros, reverting it to the 24.2
coding style. With still more work I could introduce xSET
macros (assuming we come up on a style for them), resulting
in a new style.
I'd like to avoid this extra work if possible, so how about
this idea for moving forward? I'll install the
abovementioned patch. If anyone actually needs the xVAR
and/or xSET macros, I'll volunteer to do the tedious work to
put them into the trunk. (This offer is good for one year
or 10,000 edits, whichever comes first. :-)
That way, if we don't need those macros I'll save some work,
and if we do need them I won't cost myself any more work
than I'd do under your proposal.
next prev parent reply other threads:[~2012-08-25 0:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-17 0:04 bug#12215: CSET is unnecessarily confusing Paul Eggert
2012-08-17 4:12 ` Dmitry Antipov
2012-08-21 16:55 ` Stefan Monnier
2012-08-22 3:25 ` Paul Eggert
2012-08-22 13:27 ` Stefan Monnier
2012-08-22 16:35 ` Paul Eggert
2012-08-22 16:50 ` Dmitry Antipov
2012-08-23 7:02 ` Paul Eggert
2012-08-23 12:26 ` Stefan Monnier
2012-08-23 14:40 ` Paul Eggert
2012-08-24 3:46 ` Chong Yidong
2012-08-24 3:57 ` Paul Eggert
2012-08-24 4:26 ` Dmitry Antipov
2012-08-24 15:10 ` Stefan Monnier
2012-08-24 17:19 ` Paul Eggert
2012-08-24 17:27 ` Tom Tromey
2012-08-24 18:11 ` Paul Eggert
2012-08-24 21:12 ` Stefan Monnier
2012-08-25 0:17 ` Paul Eggert [this message]
2012-08-25 1:58 ` Stefan Monnier
2012-08-26 5:05 ` Paul Eggert
2012-08-21 17:55 ` Stefan Monnier
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=503819A5.10908@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=12215@debbugs.gnu.org \
--cc=cyd@gnu.org \
--cc=dmantipov@yandex.ru \
--cc=monnier@IRO.UMontreal.CA \
--cc=tromey@redhat.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.
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.