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

[Pedro Andres Aranda Gutierrez <paaguti@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3887 bytes --]