all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>,
	"help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>
Subject: RE: [External] : view-remove-frame-by-deleting ignored?
Date: Wed, 12 Oct 2022 15:33:14 +0000	[thread overview]
Message-ID: <SJ0PR10MB54880418766D4D068DC3FEE3F3229@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <83tu49d2mp.fsf@gnu.org>

> > > I generally use 26.3, as later releases
> > > broke too much for me. :-(
> >
> > Too bad.  I see this a lot with Emacs users
> > as of late, where they pick some version of
> > Emacs that has not seen development in years
> > (or even decades) and stick to it, because
> > we break too much.
> 
> FTR, in this particular case, our requests that
> Drew helps us debug the problem which caused him
> stick to 26.3 were met with refusal.

That is _absolutely_ untrue.  A completely unfair
characterization.

I provided the info I could, with the time and
know-how I have available.  Trying to track down
the problem in more detail is beyond me, as I've
explained.  I never once complained that someone
else needs to do something to investigate the
problem.

It's my problem.  Never said otherwise.  I don't
know what Emacs changes led to the problems.

I'm not expecting Emacs development to cater to
my setup.  Never have.  I can't make good use of
Emacs after release 26, but I don't expect that
to change.

I use Emacs 26 and earlier, and unless something
unexpectedly fixes the problems I have with later
releases I'll no doubt continue to use 26.  It's
not the end of the world, for me at least.  I'm a
happy camper (even though I'd prefer to benefit
from the good that's been done in later releases).

I haven't complained that Emacs hasn't fixed what
got broken.  I've only reported the problems
(what little I can).

I've anyway held out a glimmer of hope (without
any expectation) that, whether by accident or by
discovery (e.g. someone else having such problems
at some point, and able to provide a reproducible
recipe), some fixes might just happen - that's
happened in the past (in particular wrt frame /
window / minibuffer problems).

I'm not waiting for that.  I can use Emacs 26
with my full setup.  That works for me.  And I
of course test my libraries with more recent
releases, for the benefit of other users.

It's only with my standalone minibuffer frame
that I experience the minibuffer focus-change
problems.  I don't know of any problems with my
libraries.  (And yes, I prefer Emacs 26 with my
standalone minibuffer to later releases without
it.)

> No one else reported or experienced those problems,

I never claimed otherwise.  Although I believe
that Stefan Monnier (cc'd) has also indicated,
more than once, that he has/had some similar
problems wrt minibuffer frame focus.  I believe
he said the problems he experience[ds] started
with Emacs 26.  (I can use 26 OK, generally.)
Both he and I use a standalone minibuffer frame.

To be clear, I don't/can't speak for Stefan,
and I don't believe he's given any more info
about his problems in this regard.  But I think
he did chime in a few times to say that he
experience[ds] similar focus problems.  He'll
correct me if I'm mistaken.

> so without Drew's help we cannot make any progress.

I never claimed or expected otherwise.  I've
moved on.  I have a life to live. ;-)

> This is all in the archives of the bug tracker.

And I invite anyone interested to dig it all out
of there.  I don't recall the bug (or emacs-devel)
threads, but perhaps you'll point folks to them,
instead of just insinuating things?

For some reason Eli, you never miss an opportunity
to attack me personally.  Too bad.  Hope it does
you some good, somehow.  Beyond that, I hope, for
your sake, you get past that need someday.



  reply	other threads:[~2022-10-12 15:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-08 20:32 view-remove-frame-by-deleting ignored? Thorsten Bonow
2022-10-08 21:15 ` [External] : " Drew Adams
2022-10-08 21:29   ` Drew Adams
2022-10-08 23:45     ` Michael Heerdegen
2022-10-09  2:16       ` Drew Adams
2022-10-09 19:14         ` Thorsten Bonow
2022-10-09 19:24           ` Drew Adams
2022-10-09 19:31             ` Emanuel Berg
2022-10-11 15:17               ` Drew Adams
2022-10-12  0:57                 ` Po Lu
2022-10-12  1:39                   ` Drew Adams
2022-10-12  5:36                   ` Eli Zaretskii
2022-10-12 15:33                     ` Drew Adams [this message]
2022-10-12 16:04                       ` Eli Zaretskii
2022-10-12 17:13                         ` Drew Adams
2022-10-12 19:16                           ` Michael Heerdegen
2022-10-12 19:59                   ` Emanuel Berg
2022-10-09 19:48             ` Thorsten Bonow
2022-10-09 20:42               ` Drew Adams
2022-10-09 21:08           ` Michael Heerdegen
2022-10-10 15:15             ` Thorsten Bonow
2022-10-10 23:46               ` Michael Heerdegen

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=SJ0PR10MB54880418766D4D068DC3FEE3F3229@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /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.