From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: Gap buffer problem? Date: Wed, 11 Dec 2024 19:11:12 +0100 Message-ID: References: <86wmg7bso1.fsf@gnu.org> <87cyhzmzbp.fsf@telefonica.net> <87bjximwnj.fsf@protonmail.com> <87ttbal9qx.fsf@protonmail.com> <877c86l1aj.fsf@protonmail.com> <86o71i2m2e.fsf@gnu.org> <87o71i3yhg.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25839"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , pipcet@protonmail.com, emacs-devel@gnu.org, ofv@wanadoo.es To: Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 11 19:12:06 2024 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 1tLRBu-0006Ra-Bl for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 19:12:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLRBA-0001Mj-G5; Wed, 11 Dec 2024 13:11:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLRB9-0001Lb-E5 for emacs-devel@gnu.org; Wed, 11 Dec 2024 13:11:19 -0500 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tLRB7-00067o-Q9; Wed, 11 Dec 2024 13:11:19 -0500 Original-Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-434a852bb6eso67290055e9.3; Wed, 11 Dec 2024 10:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733940676; x=1734545476; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=60Ybonj98ErF71ibkjJbUKRcStpxBBaZJQMrZctoYZg=; b=GWckGtlbcxLSxGdAOzR0iUbZvZ7oeXwawvh8vEVi0nKH4p56KJWPdoTBBvbMQkqyGQ o14Jq1lc1hjWBNgS+HzySCuFQ/QpauhuFjFce+At2kLF4SuFE0vP7JXVmP0tsHCtpiL9 HLlFly53iUpMxSQZ/pEijKDK2v8Zb7QARP+hdd705Z6cQSWj/kCha2HPPIcXOPhGGASt hZdPbupepTL/zmuZTj/TfZE4PdoFmmP4/yShHtQ8o2V916uoryZ92plyT2ncMFS2eYdM BFtNQjztxDtW/wTyOxPPfHDhT0+iYexeh92btb9872z0kIUPuENIGzgtyG/1sjcE4NyN cMNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733940676; x=1734545476; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=60Ybonj98ErF71ibkjJbUKRcStpxBBaZJQMrZctoYZg=; b=uyP9S+HUEsTzIqNa9Qiatt1nhWEm95tslLVICoDXQSzO+KYuPbE5hZDZsnR7/wiVsY T5SvhaPLXzrN8XBn8IJk87Q7UAtkuBGrGuBeJ2J0iwKAXIo14nI34jcDH2Gk9CUSfzul VW3jsw/griqkGAopdeihUBjf5BA/nkbWeFexMeyn+1muJusftuP0/n5wLQAftYGzqnvR MBBMXSkDGyQmj/PvChjRv5Z35LQKNrxB7U3QsDV81u5Hdq8FD1QXMVGKU3VlOVaXrkHc egDGR4TZRq2dajZPSutlJ86l2ExhAgfv4xxXn4dcGon0wShlTdM2EFKdij4S6O7wV5Kq Pl9Q== X-Forwarded-Encrypted: i=1; AJvYcCVOM1G86S70mIZZPYR9oyr+k0UJweagT/EtFREn8bW7o0hWT2d4pjEQSqIorMFugxI/YUS2wXhNkSDfcg==@gnu.org X-Gm-Message-State: AOJu0YyVYmXACbdAz6fSJ/4k+ynUcSYFkmsCh1cyBGJr8ofh18WPQO9g DUqoWDezO3m8boKG3o1qO0kfyRnIfbqfBDNAhJ3ES8VJdzbJJMW1 X-Gm-Gg: ASbGncuokpe2ZJmqAoSF3+xLMlRqHcfkAi/1C5WpR3e2VhfyJN2+Kk5+BU8ltEx/k+p ve1RURz8awekDqZdiJrNX5DBEJL3HZup46QFieEH0FH1O2qIcQb/MVuFBVrEcoYfSbpZRWSEkaM QgSBueeD0fkFx1Ntfc0tWX/DBtV2E2tybiwS3ERB1WQlNvvKzPpC17CPNbqDG9aivF+fgguBTYG QYASwlqnELoMC/NjUqFUvHtiMVcAOt7XXgGIVbp4wB69RESsXgfNpJRexz0wBAUVi7b8epiENMG oCPgzu/riCxGjRaVqQMYQtNLkkae0biwv2vEOMoJfVNihLuXq+HH4Pe7KICN/OuL0PIiNqlBNZ4 fL7Wvrg== X-Google-Smtp-Source: AGHT+IGdSfn642q1qVRyWwguoWmE6N5zRZgBvDUg2ezZL+J+WwRBRP1iYXuWJZg+AEOFJ1xo1l+kVQ== X-Received: by 2002:a05:600c:4e54:b0:434:a8ef:442f with SMTP id 5b1f17b1804b1-4361c430efemr25425995e9.32.1733940675634; Wed, 11 Dec 2024 10:11:15 -0800 (PST) Original-Received: from pro2 (p200300e0b709ba00c5d5596d9959c8a7.dip0.t-ipconnect.de. [2003:e0:b709:ba00:c5d5:596d:9959:c8a7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4361b7a46c1sm34837265e9.33.2024.12.11.10.11.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Dec 2024 10:11:14 -0800 (PST) In-Reply-To: <87o71i3yhg.fsf@gmail.com> (Robert Pluim's message of "Wed, 11 Dec 2024 18:45:15 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::333; envelope-from=gerd.moellmann@gmail.com; helo=mail-wm1-x333.google.com 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, 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.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326374 Archived-At: Robert Pluim writes: >>>>>> On Wed, 11 Dec 2024 18:13:41 +0100, Gerd M=C3=B6llmann said: > > Gerd> Eli Zaretskii writes: > >>> From: Gerd M=C3=B6llmann > >>> Cc: "Pip Cet via \"Emacs development discussions.\"" , > >>> =C3=93scar Fuentes > >>> Date: Wed, 11 Dec 2024 16:33:18 +0100 > >>>=20 > >>> Pip Cet writes: > >>>=20 > >>> > This may be a very stupid idea, but why not use a separate proc= ess? > >>>=20 > >>> Not stupid at all. I thought about something similar in a differe= nt > >>> context, namely if one could decouple the GUI part of Emacs from = the > >>> rest. > >>=20 > >> If it can be done by two processes, it can also be done by two thr= eads > >> in the same process. Right? > > Gerd> Yes, I think so. > > But then you have to throw a lock over all the memory in the > non-display thread that might affect redisplay (although come to think > of it, you=CA=BCd probably need that even when using fork) > > Robert Well, it depends. Assume you have a solution that works in a second process. That solution wouldn't use things in the first process because it can't. Now move that code of the second process to the first process, and make two threads out of the two process, and replace process communication with inter-thread message passing like in an actor model.