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 20:09:51 +0100 Message-ID: References: <87bjximwnj.fsf@protonmail.com> <87ttbal9qx.fsf@protonmail.com> <877c86l1aj.fsf@protonmail.com> <86o71i2m2e.fsf@gnu.org> <87v7vqjexy.fsf@protonmail.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="29569"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org, ofv@wanadoo.es To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 11 20:10:35 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 1tLS6T-0007XJ-Eq for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Dec 2024 20:10:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLS5x-0003JP-1L; Wed, 11 Dec 2024 14:10:01 -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 1tLS5t-0003IU-Fx for emacs-devel@gnu.org; Wed, 11 Dec 2024 14:09:57 -0500 Original-Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tLS5q-0004YQ-T1; Wed, 11 Dec 2024 14:09:56 -0500 Original-Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-43618283dedso18231425e9.3; Wed, 11 Dec 2024 11:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733944193; x=1734548993; 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=D8d1yBj9SzT/z19pSS+uZlC529tNjJ8zpEA5muIGL1s=; b=eus7fKV4Z2C0yPMbwibRM5kzuK67Dp3dLGONsS3J3C1z93VBL6vkjB4no24g01rCWU tN6fqZRgxRFFXg1V+wSVBuuwrIoH7duYPIkmrO2B6FOAQ/sGlAQl+tdrMPeSudCKtyoN TbNWYNwYEB92H52QYbyllZX/qNR9cqKi0x37X+k65K1mdEAhxm/++Tz2aUCrnOYsVGwM gbP6Gs0Xt14VNGUaS3fWWRrZTIde2qBY5PJKb/K7IsRRXpjMp8fyVhI+MFsl8kjzJ9Fl adx/NgysGi4TobymGNaBY+ycptPGD+YDZ/Gvwk85zofI58PwUMD1x7TMll3bCondBAtR zo/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733944193; x=1734548993; 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=D8d1yBj9SzT/z19pSS+uZlC529tNjJ8zpEA5muIGL1s=; b=Y89tnNSmFeBMpWj9SCWuISyTcFaeehW8by++AS9zMLunG6Hy7TNNF0Eu7Gju+hN3/K USQyFoXWOiDxE9FsgbG0trtnxYvPnbnOvKCRCvu3FDjXP1xbVx3dwduYCZbt073+an3K P0bMJlXaw/j8CyK9adTaJjl2Yk9BPLH4nHbxp1wDuic+94bnzF1W8WGMl6/jljzBT3U5 ysfYZOCiTLsKi1cXPDz+ycjIJso0vQ4tn8+KbDuClKvQI7r7Kdl+Yk1lLSTo4HH/JB2L db7jZ4ktlogKFmUXhvVYcccnERI2s/Zln2XL41lKSD7Gq58bwY1YsLCVmK4s8LWEcaYr B3Ew== X-Forwarded-Encrypted: i=1; AJvYcCUbfTVPGEHXusA/4/+D47W5x9y87LYyIYYChtsCoyOqegmhaf163ocCxdFrX4FgI41SK0n1JYGe1wdTzA==@gnu.org X-Gm-Message-State: AOJu0YyXHfD0FM+mfXsQqRJUcWsy706bZseVB0d+F2T+65OWhITn+dwN 8lsJlIDBlVh5iveeVWRwMlSQ+1SUIXfB9cfelN099oUBZK1NmxKS X-Gm-Gg: ASbGncuI5akp3F7JD67ffdS06awmWlIJXRxUh75nupMCRhVDjwL0F1UHu1s3WBKIyxU rom6rxW+wtuTwWQphz6tiX7f65ojHrkyB0hDHlFn78pvDQt12/u6m9EfNZyCI9K+8FfpbySeEHl 8f9aUdlg3nCFYoeKCqva7wOur1kI6b39q2lhT886rpep1A8DSMIu8QukyUkhaKZcR7PQzQgSnxB tbdKlfc8VW2bdTzRo4+90pYUJNwbaarFljV13VnKVt8AGVK9iPq6N/xMMALe7ZVgSQ73UIXGuE5 1F5uHwWQJyEH6Ob1qXzug6s+ewtPV3pabAtNIeOHHZs0tglfCCqg4wdSGD7mTJs= X-Google-Smtp-Source: AGHT+IG2n7pkiTMa88vh8q6WJRFKbB7ydAsIcUVXJmbWK8FtK8AMXk6yZnB0YTXfwLmyEQ1tCei6Bw== X-Received: by 2002:a05:600c:1c82:b0:434:a815:2b57 with SMTP id 5b1f17b1804b1-4362286399fmr6820325e9.20.1733944192775; Wed, 11 Dec 2024 11:09:52 -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 ffacd0b85a97d-387824bf249sm1908258f8f.52.2024.12.11.11.09.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Dec 2024 11:09:52 -0800 (PST) In-Reply-To: <87v7vqjexy.fsf@protonmail.com> (Pip Cet's message of "Wed, 11 Dec 2024 17:41:29 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::32d; envelope-from=gerd.moellmann@gmail.com; helo=mail-wm1-x32d.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:326378 Archived-At: Pip Cet writes: > "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 >>> >>> Pip Cet writes: >>> >>> > This may be a very stupid idea, but why not use a separate process? >>> >>> Not stupid at all. I thought about something similar in a different >>> context, namely if one could decouple the GUI part of Emacs from the >>> rest. >> >> If it can be done by two processes, it can also be done by two threads >> in the same process. Right? > > AFAIU: No, not right. > > I may have misunderstood, but if the idea is to preserve a consistent > state of all Lisp data and buffer text for redisplay to use, the easiest > way to ensure that consistency is fork(). The other ways, such as > copying all heap objects that might be used by redisplay (and adjusting > all internal pointers in such heap objects to point to the copy rather > than the original data), probably will end up either being a lot slower > or being very specific to the system we're running on. I may also be misunderstanding, but in principle, I agree with Eli. Say we have processes A and B communicating with each other. Take the code of A and move it to B, possibly with some automatic transformations if A and B have the same source code. Make two threads in the result process for A and B. Replace inter-process message passing with inter-thread message passing. Initial message may be "fork" transferring the world of thread A to thread B. But I'm also thinking too abstract sometimes.