From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Heerdegen via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#73431: Add `setf` support for `stream.el` in ELPA Date: Sat, 28 Sep 2024 01:55:43 +0200 Message-ID: <87bk08odmo.fsf@web.de> References: <827cc7fc-10be-4b93-bd67-f275193e5d84@protonmail.com> <87ikultl1v.fsf@posteo.net> <2522160a-761c-4f23-a9c7-4740b49681f1@protonmail.com> <87o74bqy9g.fsf@posteo.net> <87jzexqgg8.fsf@posteo.net> Reply-To: Michael Heerdegen Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33457"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Okamsn , Nicolas Petton , Stefan Monnier , 73431@debbugs.gnu.org To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 28 01:55:53 2024 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 1suKoT-0008YS-3N for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 28 Sep 2024 01:55:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1suKoC-00083M-Si; Fri, 27 Sep 2024 19:55:37 -0400 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 1suKo9-000831-5X for bug-gnu-emacs@gnu.org; Fri, 27 Sep 2024 19:55:34 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1suKo8-0006Kn-TV for bug-gnu-emacs@gnu.org; Fri, 27 Sep 2024 19:55:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=nvRsIG5FZt8YVusUiXec6MZgO5O2y426UUuETI6/UM8=; b=v79DB/GymXvu4q9EnWQROR9KoHA8uckwxe6QjLXcmQtEWV3lNkkN5T+X7rE2gFbW8XTZLkLO5bo0pfueL6+FX/0W97rue1ARBy3tqMsP8baej5rucZa0KFgB7J4aCpS/550Iy3GbUC0wbhvoPHTdwcRGanWpXYKjwIM9qxZ0Yh5EuEGj1HKrHnANiGDpo3VnY5N6ihW3Y1TbpolpQr5TPQGcux1mP2eLIAUlRT1xzai6bNs+XWAm9uoB2S1tc/bz7oklA1lbseqg3BkpSvNWF8n3rTBkm1oib2yWQqZ1X6rJlrW5oFBUSOkYrH18rwCkmecGroMUUPV5+TDfJ6i2LA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1suKob-0003KB-TM for bug-gnu-emacs@gnu.org; Fri, 27 Sep 2024 19:56:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Sep 2024 23:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73431 X-GNU-PR-Package: emacs Original-Received: via spool by 73431-submit@debbugs.gnu.org id=B73431.172748133512394 (code B ref 73431); Fri, 27 Sep 2024 23:56:01 +0000 Original-Received: (at 73431) by debbugs.gnu.org; 27 Sep 2024 23:55:35 +0000 Original-Received: from localhost ([127.0.0.1]:58214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1suKoA-0003Dc-Ks for submit@debbugs.gnu.org; Fri, 27 Sep 2024 19:55:35 -0400 Original-Received: from mout.web.de ([212.227.15.14]:58499) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1suKo7-0003BD-R8 for 73431@debbugs.gnu.org; Fri, 27 Sep 2024 19:55:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=web.de; s=s29768273; t=1727481287; x=1728086087; i=michael_heerdegen@web.de; bh=nvRsIG5FZt8YVusUiXec6MZgO5O2y426UUuETI6/UM8=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=hJ+JlBLGhuXdw5KAh4YvTyg/wt581x0AHT/9JSNE0nRbWks4CzZZqv/wKBiQxNTi rKy7rt5El2Jt1+4PqOaMBUWlVsxf4iL0fNnl05HBYrlfMO+IlolUaXHPGdqWuOpZZ 5k1auZiJRctV/R0FZrocV/RoWq72UnOv+6du/7xm8dlurwTCq5xF1ZW8QJLY95n2C wjVudluNLXsRZx7xaPPUU0bpbhQXbVhQ5C1XGRL3y+sVQwCww3+NkdbJx9who0Cvu EOiDhdZazD2bat2Q/RW/ibFo5wRKp41+c4ZeHkJ1n5jRBqb4V+RnvCY/QcVnicTku yUnAzdBqPGy9BmhABw== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Original-Received: from drachen.dragon ([92.75.138.227]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MiMAE-1sFEsz0wFC-00dqtP; Sat, 28 Sep 2024 01:54:47 +0200 In-Reply-To: <87jzexqgg8.fsf@posteo.net> (Philip Kaludercic's message of "Fri, 27 Sep 2024 15:11:51 +0000") X-Provags-ID: V03:K1:DFjvEtOY53JKWGcXiOy9ZhSZodWq4Ipu0HSzseEcyLqeb3z5PC0 G69wOq0NktKpzWM32WwetPVy51CDoX8HUKgS/qiDha4MqljoZSgbr3rZideiydfYvB53adw tiYrs/NQVSdZkpdveW4XVo+CpSdbc63sqlmcO4iO3tdCnQqBbFn3GuqYeavCVl2LuH9ctXn 8GAUQcWH5GLdL+dkyaT9w== UI-OutboundReport: notjunk:1;M01:P0:pmwqtcd8nNQ=;opcF7dPYxH0re0PTrgWPVSh4b+9 guhNBuGk2AB3k+OOn/9/kjerJbEURSAkilR1VU7Yyc/XJjKdCXv0EX3BqB++wpCItRb0Yo1dd 7QZ+q8qmLfeE2XarkxA7kBwmXE74D0hX8HC9QtYrTRZHoL+WFDfYDGBMjIvcAkTohgQPia+r5 Uwpg/yNpHiLAOw/Y/DJDIyk04/XJkN/EmVxPq5ZJ+Hs2WjwYNmUuso/Mdnu/63WqDmLp2IFVs KXZmmq5vc520Bwjlm8TL0ZBse/MVV6OxBNjK4RCLXEwGUo+d4Zg2EGiG/RbTns10sks2M/47r al/asOKHJnjP7ol2VdsyWBxtbyXZlSLlfORoY7afM48SfdAwSxGfY5x5ifU87eWjDvxZOhCsV 9wnFJvWGeDcbLLjfkVynae+fVp+yOh0GYr3oWNcNZJoQzq9WP3IR8J7rXj/kAT0Q7oVtBvytL 9Ba+pQ1h6RX55+JoAxCTShExODrUDyelRs0BicezFU7b24TYHLy/jwCSn1c6nHF8K2XbF3fVb la+uIjqYimLM/iGryDwx/btg8FitR3lS8beo2jWg41MVxA95wwJMD6t/l6IdaQzDLOr/RFhyE OopkOnNaw2YsietDETWpoi5gYIQR96Mkum/WtfvXXeWW6Far1awjVDq4uYhGci43YnJ0jDFm9 CQQi6zaQsgdj1nWG6Q9/cRFO1/UWVUPzsWEl8RKmDvVrLtW8nslTIAqpBA5w66Buk6SuVi8XQ hwq3IYvFtxU7Z2i4lhPic/12OoafNxMTvLLJkHam9x8sfT0PS9wcBYxG+yuRBRWJkbjxXUHT 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292541 Archived-At: Hi, I agree to what Stefan is saying. Philip Kaludercic writes: > Being able to modify the head of a buffer-stream using setf seems like > something that could be useful, and certainly more efficient than what > many people want to do with splitting the return value of > (buffer-string). AFAIK, what you normally do in this situation is creating a new stream reusing the tail of the given one, like in this toy example: #+begin_src emacs-lisp (cl-labels ((integers (&optional from) (let ((from (or from 1))) (stream-cons from (integers (1+ from)))))) (let ((my-natural-numbers (integers 1))) ;a stream of the natural numbers: 1, 2, ... (let ((my-natural-numbers-with-head-replaced ;let's "replace" the first element: (stream-cons 'not-1 (stream-rest my-natural-numbers)))) ;; Test: what are the first 10 elements of this second stream? (seq-into (seq-subseq my-natural-numbers-with-head-replaced 0 10) 'list)))) #+end_src Modifying elements later in the stream conflicts a bit with the idea of a delayed data structure. The above idea can be modified to work in this case too, though. Creating a new stream even makes more transparent what is going on... I don't want to tell anybody how to work with these guys, but that's how I learned it at university. In typical scenarios the elements before the one to change already have been processed and been thrown away, and the element you actually are interested in is the head element most of the time. Like for a queue. For buffer contents listing streams I could imagine that one could make such a thing invalidate itself when the buffer has been modified; like here [I only added few lines to the (stream ((buffer buffer) &optional pos)) implementation]: #+begin_src emacs-lisp (cl-defmethod my-buffer-chars (buffer &optional pos) (let ((mods (buffer-modified-tick))) ; added (with-current-buffer buffer (unless pos (setq pos (point-min))) (if (>= pos (point-max)) (stream-empty)) (stream-cons (with-current-buffer buffer (save-excursion (save-restriction (widen) (goto-char pos) (char-after (point))))) (if (not (eq mods (buffer-modified-tick))) ; added (error "Buffer has been modified") ; added (my-buffer-chars buffer (1+ pos))))))) #+end_src Already generated elements normally can't "invalidate themselves", unless you make them functions. But a whole stream that regenerates or recomputes itself doesn't seem natural to me. You would rather check whether the stream is still valid _explicitly_ - and if not, just call the function that returned that stream (most of the time a named function, like above) again to create a new stream - in the above example, possibly with an adopted POS argument. My two cents. Michael.