From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: A modern-mode? Date: Wed, 16 Sep 2020 14:04:41 +0100 Message-ID: References: <20200916094819.GB13405@tuxteam.de> <20200916102001.GC13405@tuxteam.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d588d505af6de93f" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21756"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, emacs-devel To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 16 15:05:51 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kIX8B-0005VA-O5 for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Sep 2020 15:05:51 +0200 Original-Received: from localhost ([::1]:49014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kIX8A-0003PY-QE for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Sep 2020 09:05:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47560) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kIX7I-0002wa-72 for emacs-devel@gnu.org; Wed, 16 Sep 2020 09:04:56 -0400 Original-Received: from mail-io1-xd2b.google.com ([2607:f8b0:4864:20::d2b]:37995) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kIX7G-0001uW-6h for emacs-devel@gnu.org; Wed, 16 Sep 2020 09:04:55 -0400 Original-Received: by mail-io1-xd2b.google.com with SMTP id h4so8137681ioe.5 for ; Wed, 16 Sep 2020 06:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qY7mycCyyLFiueZCGE5JBj9CfoC1teuTgThYJodsZlU=; b=bepzpW8jKcpwxI/uBdpDSUz7GnEQ/EHgj7d9I3O5HBYiddkz+99ezI25Y51prFJsPI 6gp5tfqa0hPFwi5bEeA2OPdYkbPdaiEF+BHARCcaQ7NOmSY0N3ghGY0locOOO8MZ1E3J tBhUBdd0SCTY3ZWaW+KzTqCikC0gsB/jgSNMzbogtu6cD7ohsr0+zSNrOk0GHfcQ7e3N cYGvi/BRlH4ZEvB83Qk2ycSjUhF+JhNhajSDbZw9GKEQMgtvN3qZdVmmRBbHnMsOKD1E DtN7UtvNSvyF+prabfJBfIIDmxRRg0qZjVNNQxbt2kfYitaV3WovVBIigaeIuL9cQdFm jHLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qY7mycCyyLFiueZCGE5JBj9CfoC1teuTgThYJodsZlU=; b=qJhMptjLLjSfY6jAl+DpUFKN6OZbD0TofD/AE1sJixWDZjnAzmBWoAwKrC+o3ZkJ2w /1VgM/eyDc9CiEQ7o+HhJGK/dD0DWgTLpdHlp3huDQ/IXvTTiBpk7BsG2+C7HoRDeS9R U7VovTUR7oJ4IRot1c1vF3lQ5vDbIFAEdcAGKf5dtuVmtBszqHvMlkyp4Dv7PkQClSBn Zsz8TWECfrNYTC5+7/PCuIGaAiB2rimp8XFz3T7gbGexddVGRD1J+OPdVwMGN0k5HPcj lt5LPgKpSIjdok5jhe+jVUI+8tLeGVYaU/Ae1IgkhEORpbKJMJ499MaAq9vHBBWmodZj OA/g== X-Gm-Message-State: AOAM530JZwd+dDAGnWWmMl4toIO+QW1uatMBd+hCEr41ibRRhSNgV9me rbuSeES/CazLPrF1IZB7NNdwFSzE2NCDphe+j50= X-Google-Smtp-Source: ABdhPJz3pC8dz43ImSIrJ90nH5nZTSfaYJriZKOOdRHMZbngNyfT/EbvwdujvvV5trozvKjtLNKNPJrXRl0pJ4u7vmU= X-Received: by 2002:a02:6995:: with SMTP id e143mr21427357jac.78.1600261492933; Wed, 16 Sep 2020 06:04:52 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::d2b; envelope-from=joaotavora@gmail.com; helo=mail-io1-xd2b.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:255867 Archived-At: --000000000000d588d505af6de93f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 16, 2020 at 1:40 PM Arthur Miller wrote: > Jo=C3=A3o T=C3=A1vora writes: > > > I just meant the "custom-themes" > > infrastructure should be enough to accommodate enough of > > the proposed "modern-mode". Not sure if it is (as I don't use it). > No, it is not. It lacks unified framework to use as logicla names for > color use; someting similar to what you have in

,

, ... in > html, just as example. Instead people use rgb values directly in their > packages, and when user changes a theme, packages does not follow. So > theme engine in Emacs needs a little additional work. > In theming, Emacs works with faces, not with colors. Those would seem to be sufficient logical placeholders for various types of colors. But indeed my message suffered from this confusion, too. > > I'm > > almost always wary of giants or grand reinventions of things. > > For the "base" Emacs experience that is, in their setups people > > can use all the ivys, dooms, helms and magits they want. > I understand your sentiment, but then, you could say this for any > feature, inclusive fido-mode or icomplete or even find-file. > I don't think you can. It's because of their simplicity that they are much better integrated into Emacs's infrastructure. Compare the number of lines and the number of configuration options in fido-mode/icomplete-mode to the same number in those other packages. These are leaner packages, they follow the existing infrastructure as much as possible, rather than reinvent it. But if the complexity comparison isn't satisfying to you, it's easy to note that changes to the infrastructure, i.e. completion styles, are "naturally" absorbed by icomplete-mode and fido-mode, whereas a package such as Helm had to go through great efforts to support them (reasonably recently). And Ivy still doesn't support them, as far as I know. In another example, multiple reinventions of the "imenu" display frontend, which read the menu item information directly have failed to account for recent augmentation of that format. Fido-mode provides a different visualization of M-x imenu without suffering from those problems, playing along with M-x imenu, rather than re-implemeting it. Reinventing a parallel infrastructure, easy as it is to do in Lisp/Emacs, has those very real drawbacks. Just as an illustration one could argue that "simpler" open-file as > found in other software packages is what "casual" users would expext. > Yes, you can argue that. I would maybe agree, though I wouldn't agree we should give those users exactly what they "expect", because they "expect" VSCode, I guess. But making a custom theme allow such modifications is what is needed, in my opinion. Then, if I'm mistaken, enabling that idea is just a few clicks away. Personally I would like to see ffap being enabled as default ... > Don't understand this bit. I use ffap a lot and don't need to "enable" anything, just M-x ffap. Is it a mode? Jo=C3=A3o --000000000000d588d505af6de93f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Sep 16, 2020 at 1:40 PM Arthur Miller <arthur.miller@live.com> wrote:
Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com= > writes:

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 I just meant the "custom-themes"
> infrastructure should be enough to accommodate enough of
> the proposed "modern-mode".=C2=A0 Not sure if it is (as I do= n't use it).
No, it is not. It lacks unified framework to use as logicla names for
color use; someting similar to what you have in <h1>, <h2>, ...= <h8> in
html, just as example. Instead people use rgb values directly in their
packages, and when user changes a theme, packages does not follow. So
theme engine in Emacs needs a little additional work.
=
In theming, Emacs works with faces, not with colors. Those <= br>
would seem to be sufficient logical placeholders for
various types of colors.=C2=A0 But indeed my message suffered
<= div>from this confusion, too.
=C2=A0
>=C2=A0 I'm
> almost always wary of giants or grand reinventions of things.
> For the "base" Emacs experience that is, in their setups peo= ple
> can use all the ivys, dooms, helms and magits they want.
I understand your sentiment, but then, you could say this for any
feature, inclusive fido-mode or icomplete or even find-file.

I don't think you can. It's because of their = simplicity that they
are much better integrated into Emacs&#= 39;s infrastructure. Compare
the number of lines and the number o= f configuration options
in fido-mode/icomplete-mode to the same number= in those other
packages. These are le= aner packages, they follow the existing
inf= rastructure as much as possible, rather than reinvent it.

But if the complexity= comparison isn't satisfying to you, it's easy
to note that changes to the infrastructure, i.e. completion sty= les,
are "naturally" absorbed by = icomplete-mode and fido-mode,
whereas = a package such as Helm had to go through great
efforts to support them (reasonably recently).=C2=A0 And Ivy still
=
doesn't support them, as far as I know= . In another example,
multiple reinventions= of the "imenu" display frontend, which read
the menu item information directly have failed to account for
recent augmentation of that format.=C2=A0 Fi= do-mode provides a
different visualiza= tion of M-x imenu without suffering from
those problems, playing along with M-x imenu, rather than
re-implemeting it.=C2=A0 Reinventing a parallel infrastru= cture, easy as
it is to do in Lisp/Ema= cs, has those very real drawbacks.

=
Just as an illustration one could argue that "simpler" open-file = as
found in other software packages is what "casual" users would exp= ext.

Yes, you can argue that.=C2=A0 I w= ould maybe agree, though I wouldn't agree
we should give thos= e users exactly what they "expect", because they
"= expect" VSCode, I guess. But making a custom theme allow such
modifications is what is needed, in my opinion. Then, if I'm mis= taken,
enabling that idea is just a few clicks away.

Personally I would like to see ffap being enabled as default ...

Don't understand this bit.=C2=A0 I use ffap = a lot and don't need to "enable"
anything, just M-x= ffap. Is it a mode?

Jo=C3=A3o
--000000000000d588d505af6de93f--