bug#58193: 29.0.50; Screen flickers on with-locale-environment

[Pedro Andres Aranda Gutierrez]

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 <eliz@gnu.org> wrote:

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: paaguti@gmail.com,  58193@debbugs.gnu.org
> Date: Fri, 30 Sep 2022 19:43:11 +0200
>
> Eli Zaretskii <eliz@gnu.org> 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