From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pedro Andres Aranda Gutierrez Newsgroups: gmane.emacs.bugs Subject: bug#58193: 29.0.50; Screen flickers on with-locale-environment Date: Sat, 1 Oct 2022 08:14:36 +0200 Message-ID: References: <87wn9l3q5i.fsf@gnus.org> <83sfk8db0m.fsf@gnu.org> <87mtag4vhi.fsf@gnus.org> <83mtagdall.fsf@gnu.org> <87ill44v2o.fsf@gnus.org> <83leq0d83g.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e49bca05e9f30771" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8156"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 58193@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 01 08:16:20 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oeVnQ-0001vQ-LX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 01 Oct 2022 08:16:20 +0200 Original-Received: from localhost ([::1]:34194 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oeVnP-0004Fu-53 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 01 Oct 2022 02:16:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oeVn8-0004FJ-Db for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2022 02:16:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44408) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oeVn8-0003pC-6A for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2022 02:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oeVn7-0001tO-T6 for bug-gnu-emacs@gnu.org; Sat, 01 Oct 2022 02:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pedro Andres Aranda Gutierrez Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Oct 2022 06:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58193 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 58193-submit@debbugs.gnu.org id=B58193.16646049117204 (code B ref 58193); Sat, 01 Oct 2022 06:16:01 +0000 Original-Received: (at 58193) by debbugs.gnu.org; 1 Oct 2022 06:15:11 +0000 Original-Received: from localhost ([127.0.0.1]:43481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oeVmI-0001s8-Es for submit@debbugs.gnu.org; Sat, 01 Oct 2022 02:15:10 -0400 Original-Received: from mail-ej1-f43.google.com ([209.85.218.43]:33338) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oeVmG-0001ri-Dv for 58193@debbugs.gnu.org; Sat, 01 Oct 2022 02:15:09 -0400 Original-Received: by mail-ej1-f43.google.com with SMTP id lc7so12999528ejb.0 for <58193@debbugs.gnu.org>; Fri, 30 Sep 2022 23:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=g0VoBtjnJL4PrbMWknmwRwantOvrD0IUhK23MInDf3Y=; b=bepZfx0zh3c54NgSsKB86bdyWFj3vEqUFN1kd82rOL+dC1PtQKmiSINDNfxUb7OwYS 8qoDS0ay+TFsvfRa6C2/tsl/f9CMQRIoC/epE/DhjFXwL6iNMClWUq6LbMC8G916L8JI jN3l/jSzz/zDR/f5BDgTsJghD5FLUBnPtcNMoKRdpzWkLpKA6w6M5WIewF/xO1wq/LZv Vu/dAtTLFOvu/oCCD/CGnMKbnhtPFiBwrqWjGRVVputOO/QURD9x9WSYdwZNj7Jv4gmS btF9sg1tD9r9hT+ul4IOHw8slSQSsJQz6Y+DuwOhwiafocSnlmTNcomQn4ftGtSGCl/D oh/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=g0VoBtjnJL4PrbMWknmwRwantOvrD0IUhK23MInDf3Y=; b=F+eb4LI7j5Z1UnK2Qguc+S5q97Hrw0qK0VpOxEcadqGkrrlnp0L/8ZEticcuejgMYh wzSbvrxOz+UE9hUlD9WG8gQlVZcB1i2w2k2GEgs1BX69XOgAfN8u322V9C/1wx/6JswQ vP/DauXIB4OocBqobQFZBOKrQuTULiO6CdQ9fa2fh8YmLffhqTbr4fz+lPTA4BTUX9NI 0cmOZqqjzgRr5VZVzzlKTkTnOFA7Hn9sAScbcxRk8hoJ9SgdItIkBaDt05fdHTUrr3Mb FOd1RlXo97y6JEyexVNiBjLuAcUxjG6Kgycs9oik2+kp56u5quCGIa7GBDqpQglau5eV CaTA== X-Gm-Message-State: ACrzQf3DKlWtsDdry+PMT9/PbzdI9+DA4IHjJg3SBMX4rhkfwgoGE5he ZhPEF5az0zYWI5tFJ5gR40mC15fvsEI1VmC6xGI5Ba/Dltw= X-Google-Smtp-Source: AMsMyM4a1IxRZ1Ad9Czuv+7wEqnZ+paEpFWjBmNvqLB3vukErs5nUcz2HS8IaVQ+ktmLil/LxcTa8N6LLych1a+ixN8= X-Received: by 2002:a17:907:d15:b0:781:e347:723 with SMTP id gn21-20020a1709070d1500b00781e3470723mr8599197ejc.723.1664604902299; Fri, 30 Sep 2022 23:15:02 -0700 (PDT) In-Reply-To: <83leq0d83g.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:244076 Archived-At: --000000000000e49bca05e9f30771 Content-Type: text/plain; charset="UTF-8" Hi Eli, Lars I fear in my case it's the other way round. IMHO, I think I have a minimal clue of what it does ;-) Let me expand a bit: My use case is that of a multi-lingual writer/programmer who needs the date to appear in the language used in the text which is currently being edited. My default locale is "C" because it fits my needs when programming, but then I also produce 'text documents' (.tex, .org, .md, .txt) in 3-4 languages. I'm lucky, because most of "my multi-linguality" can be handled by changing ispell-dictionary and with \date in LaTEX. But in a couple of cases, I need the date to appear 'burnt in fire' in the text. My questioning the way with-locale-environment works comes from my use case. I need the date to adhere to a 'temporary' locale which only needs to be valid when I generate a string that I then insert into the buffer. And to have the screen flickering because I have generated a string is not a 'nice' UI design principle IMvvHO. Maybe we should leave this macro as-is because of the legacy and work towards something in the line of the cl-setlocale function in Common LISP. If you look at 'man setlocale' as an inspiration of what I would be dreaming of... My .001 c, /PA On Fri, 30 Sept 2022 at 20:34, Eli Zaretskii wrote: > > From: Lars Ingebrigtsen > > Cc: paaguti@gmail.com, 58193@debbugs.gnu.org > > Date: Fri, 30 Sep 2022 19:43:11 +0200 > > > > Eli Zaretskii writes: > > > > > IMO, that assumes to much knowledge on the part of the caller. I'd > > > prefer a variable that would tell the macro that the body does include > > > display. > > > > It's a macro that changes the locale. It doesn't say anything about > > doing redisplay at all, so anybody that wants to do redisplay (for > > whatever reason) will use the normal ways of doing that. > > > > I.e., there's no particular knowledge needed. > > Many Lisp programmers don't realize what the macro does, in enough > detail to understand that it might affect the display. Suppressing > redrawing of the frame by default is IMO the wrong default: the > flicker in case redrawing wasn't needed is just an annoyance, whereas > failure to redraw when it is needed is a much more serious problem. > > So if we want to make the caller responsible for whether the frame > should be redrawn, the default should to redraw it, and callers that > want to avoid that would need to take some measures to that end. > Which is the opposite of what we have now. > -- Fragen sind nicht da um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler Headaches with a Juju log: unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet --000000000000e49bca05e9f30771 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eli, Lars

I fear in my case it's= the other way round. IMHO, I think I have a minimal clue of what it does ;= -)
Let me expand a bit:

My use case is t= hat of a multi-lingual writer/programmer who needs the date to appear in th= e language used in the text which is currently being edited.=C2=A0
My default locale is "C" because it fits my needs when programm= ing, but then I also produce 'text documents' (.tex, .org, .md, .tx= t) in 3-4 languages.
I'm lucky, because most of "my mult= i-linguality" can be handled by changing ispell-dictionary and with \d= ate in LaTEX. But in a couple of
cases, I need the date to appear= 'burnt in fire' in the text.

My questioni= ng the way with-locale-environment works comes from my use case.=C2=A0
I need the date to adhere to a 'temporary' locale which only = needs to be valid when I generate a string that I then insert into the buff= er.=C2=A0
And to have the screen flickering because I have genera= ted a string is not a 'nice' UI design principle IMvvHO.
=
Maybe we should leave this macro as-is because of the legacy= and work towards something in the line of the cl-setlocale function in Com= mon LISP.
If you look at 'man setlocale' as an inspiratio= n of what I would be dreaming of...

My .001 c, /PA=

On Fri, 30 Sept 2022 at 20:34, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: paaguti@gma= il.com,=C2=A0 58193@debbugs.gnu.org
> Date: Fri, 30 Sep 2022 19:43:11 +0200
>
> Eli Zaretskii <el= iz@gnu.org> writes:
>
> > IMO, that assumes to much knowledge on the part of the caller.=C2= =A0 I'd
> > prefer a variable that would tell the macro that the body does in= clude
> > display.
>
> It's a macro that changes the locale.=C2=A0 It doesn't say any= thing about
> doing redisplay at all, so anybody that wants to do redisplay (for
> whatever reason) will use the normal ways of doing that.
>
> I.e., there's no particular knowledge needed.

Many Lisp programmers don't realize what the macro does, in enough
detail to understand that it might affect the display.=C2=A0 Suppressing redrawing of the frame by default is IMO the wrong default: the
flicker in case redrawing wasn't needed is just an annoyance, whereas failure to redraw when it is needed is a much more serious problem.

So if we want to make the caller responsible for whether the frame
should be redrawn, the default should to redraw it, and callers that
want to avoid that would need to take some measures to that end.
Which is the opposite of what we have now.


--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um = gestellt zu werden
Georg Kreisler

Headach= es with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.u= niter.operation we should run a leader-deposed hook here, but we can't = yet

--000000000000e49bca05e9f30771--