From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark Oteiza Newsgroups: gmane.emacs.devel Subject: Re: On removing some obsolete code from subr and core Date: Sat, 5 Nov 2016 09:50:05 -0400 Message-ID: References: <878tsznpuq.fsf@udel.edu> <83fun6jpeq.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114abe8275fe4405408e11ac X-Trace: blaine.gmane.org 1478353842 17426 195.159.176.226 (5 Nov 2016 13:50:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 5 Nov 2016 13:50:42 +0000 (UTC) Cc: Emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 05 14:50:37 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c31MK-0001CJ-U8 for ged-emacs-devel@m.gmane.org; Sat, 05 Nov 2016 14:50:13 +0100 Original-Received: from localhost ([::1]:48727 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c31MN-0003WN-TV for ged-emacs-devel@m.gmane.org; Sat, 05 Nov 2016 09:50:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c31MG-0003Sf-7f for emacs-devel@gnu.org; Sat, 05 Nov 2016 09:50:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c31MF-0005m0-DT for emacs-devel@gnu.org; Sat, 05 Nov 2016 09:50:08 -0400 Original-Received: from mail-it0-x235.google.com ([2607:f8b0:4001:c0b::235]:34059) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c31MF-0005jz-7c for emacs-devel@gnu.org; Sat, 05 Nov 2016 09:50:07 -0400 Original-Received: by mail-it0-x235.google.com with SMTP id f129so5529255itc.1 for ; Sat, 05 Nov 2016 06:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8ojsnPTpKBhrw00YTAVEjCY5I26RyUNLpWPdf1ZI24M=; b=yOAWQDwFP0ghgUUyqUJWszaVyQ/gQjvpOxd4O95SDop3Z+JAWzWNMIg/oF7xCp90X5 dMqoznGDIeAoMZr/j4bAVnQm5AIVsuXx2yp1BBjQjuqQZ0byaVX48WEOmu2iUerxaFVC SCf43vGVlZo2VJY33EkyhL5dbPm1OxNVdRL5xqSoLxVyyY81FYTyZt+HQBPuuKPagLd2 X6CqaJkZY3FiYyMm9fArihRoidmox0q112TBZ3TMH2Getrob5Jt1k6YkTY04dgxRW3UM yGPuX8TDrdPRke0by2NC6ppi8eyX1y49G1ZOb6/wGZnne2GF7035p292+F6y6rt00gBX fkqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8ojsnPTpKBhrw00YTAVEjCY5I26RyUNLpWPdf1ZI24M=; b=T5fKayQakfjSR/+6c1f7XjsuiJckMwyOzCavKAWY46V6pBOHothrJPLmg+aZ9M6DHv lJuyeCK6dZJl5+aInXdIpqu2aliF+ipUxSdaG10EjBYs2mUJmsEkdTKYArBpXia8ZcXa C2pzxgqmCvYJOLjrrz0WzBrb+ST/CXszmURMVaHO5WtdQKdqmIOjb+eVEts4Vbd7dpSc vgQxS7h37E07fgAlXITk5y+2c8Y9y0/TSa+bbZG+znLk2GVTjjqPYzDxD4lq5DyB6thR ql3L9scDwQXpE14eOeJc+WLq8AYeEoWjL/EUY/T3cZISG2rLgPwrZgJHdzC81ROpZMkJ /Phw== X-Gm-Message-State: ABUngvdoH5Y0tjJAF6OCNnEW0JU/yBB872AN0vH62/m9qtlzrtgI6m8vA9bEOj41T6j/Oe6VcCo7Gef3+iL18DtA X-Received: by 10.107.182.193 with SMTP id g184mr17245472iof.215.1478353806024; Sat, 05 Nov 2016 06:50:06 -0700 (PDT) Original-Received: by 10.107.135.40 with HTTP; Sat, 5 Nov 2016 06:50:05 -0700 (PDT) Original-Received: by 10.107.135.40 with HTTP; Sat, 5 Nov 2016 06:50:05 -0700 (PDT) In-Reply-To: <83fun6jpeq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c0b::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209184 Archived-At: --001a114abe8275fe4405408e11ac Content-Type: text/plain; charset=UTF-8 On Nov 5, 2016 4:34 AM, "Eli Zaretskii" wrote: > > > From: Mark Oteiza > > Date: Fri, 04 Nov 2016 12:59:09 -0400 > > > > I was eyeing some code in subr.el that deprecated in 22, and was > > wondering if there is any concern with ripping it out. In particular, > > the bits included in the following patch. > > Removing obsolete stuff is an ungrateful job, as we need to brace for > complaints and have a Plan B for if/when they need to be brought back. > For removed symbols, bringing back the ones that are still needed is > easy. But what do we do with the default-FOO variables, once the > machinery for their generation is removed? > > In any case, this needs a NEWS entry listing all the removed > variables. > > > The parts for buffer_defaults is incomplete of course, there are many > > references to this structure. Just searching through, uses of > > buffer_defaults look very easy to remove, but I may be missing something > > subtle. > > Why do we need to remove buffer_defaults? Once it is not exposed to > Lisp as variables, what's the harm? None aside from (presumably) dead code. Perhaps it will be removed someday, but if leaving it there is fine with you then great! I'll be sure to add a NEWS entry. Thanks --001a114abe8275fe4405408e11ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Nov 5, 2016 4:34 AM, "Eli Zaretskii" <eliz@gnu.org> wrote:
>
> > From: Mark Oteiza <mvotei= za@udel.edu>
> > Date: Fri, 04 Nov 2016 12:59:09 -0400
> >
> > I was eyeing some code in subr.el that deprecated in 22, and was<= br> > > wondering if there is any concern with ripping it out.=C2=A0 In p= articular,
> > the bits included in the following patch.
>
> Removing obsolete stuff is an ungrateful job, as we need to brace for<= br> > complaints and have a Plan B for if/when they need to be brought back.=
> For removed symbols, bringing back the ones that are still needed is > easy.=C2=A0 But what do we do with the default-FOO variables, once the=
> machinery for their generation is removed?
>
> In any case, this needs a NEWS entry listing all the removed
> variables.
>
> > The parts for buffer_defaults is incomplete of course, there are = many
> > references to this structure.=C2=A0 Just searching through, uses = of
> > buffer_defaults look very easy to remove, but I may be missing so= mething
> > subtle.
>
> Why do we need to remove buffer_defaults?=C2=A0 Once it is not exposed= to
> Lisp as variables, what's the harm?

None aside from (presumably) dead code. Perhaps it will be r= emoved someday, but if leaving it there is fine with you then great!

I'll be sure to add a NEWS entry. Thanks

--001a114abe8275fe4405408e11ac--