Re: my posts don't appear on gnu.emacs.help
> Date: Sat, 30 Dec 2023 19:50:36 +0200 > From: Eli Zaretskii > Cc: emacs-tangents@gnu.org > > > From: Emanuel Berg > > Date: Sat, 30 Dec 2023 15:47:38 +0100 > > > > My posts don't appear in gnu.emacs.help anymore. > > Maybe you are blocked by the list administrators? But now I see that you are not blocked: your message just appeared on help-gnu-emacs. --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
Re: my posts don't appear on gnu.emacs.help
> From: Emanuel Berg > Date: Sat, 30 Dec 2023 15:47:38 +0100 > > My posts don't appear in gnu.emacs.help anymore. Maybe you are blocked by the list administrators? --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
Re: Blog post
> Cc: Eshel Yaron , Emacs-tangents@gnu.org > Date: Thu, 14 Dec 2023 17:20:56 +0100 > From: Christopher Dimech via Emacs news and miscellaneous discussions > outside the scope of other > Emacs mailing lists > > I put the emphasis on the maintainers themselves to eliminate chaos within > their project. The latter could be the specific area where our opinions > differ. > Users typically focus upon specific details, whereas software designers focus > on > making everything work well together. From my experience, being a maintainer > requires > a higher level of concentration and control of the external. It is quite clear to me from what you wrote above that your mental model and vision of maintainership of a project like Emacs are very different from the reality, starting from what does it mean to be a maintainer of such a project and what is its job description. Given that, your criticism is mostly off-mark. --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
Re: A simple(perhaps dumb) idea for a more responsive emacs
> From: Barry Fishman > Date: Thu, 05 Oct 2023 17:34:01 -0400 > > I was just suggesting that rather that waiting for some global solution > to be found, a less complex approach be considered in the mean time. > Where "pain points" could be considered a case by case basis, but still > provide a common mechanism to use. See, I'm not sure even this suggestion (that is already rather radical in its implications) will do. Because, apart of buffers, we have the rest of the huge global state in Emacs, and Lisp programs are quite cavalier in relying on that, and there's a rare Lisp program in Emacs that doesn't access that global state in some way. Something needs to be done about that as well. --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
Re: A simple(perhaps dumb) idea for a more responsive emacs
> From: Barry Fishman > Date: Thu, 05 Oct 2023 08:49:20 -0400 > > Otherwise it would put the buffers in read-only mode, and spawn a thread > to do the slow operation and return. When that thread completed, an > event would start second thunk which would update the buffers, and then > the original mode of the buffers would be restored. Making buffers unwritable while the slow operation runs is probably problematic, as it doesn't allow the user to keep working on the buffer while the operation runs. > This would allow a slow operation not to hold up the user from doing > anything except changing the effected buffers. It would still let the > buffer and screen update happen in the appropriate threads, which might > be limited by the window system being used. Displaying a buffer sometimes modifies the buffer (via font-lock). --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
Re: Shrinking the C core
> From: Emanuel Berg > Date: Fri, 15 Sep 2023 19:11:22 +0200 > > Eli Zaretskii wrote: > > >> I think the biggest problem with uncooperative > >> multi-threading in Emacs is that Emacs has so much global > >> state. As a consequence, it's unsafe to let two threads use > >> anything in the C code in parallel. > > > > Indeed, that's the main problem. Just adding threads to Lisp > > is easy. > > Is there a part that is safe to access in parallel? No. The global state cannot be possibly accessed in parallel from two or more threads. > If not, or for the part that is unsafe, where is > synchronization of access to be done, in Lisp or in C? Both.
Re: Shrinking the C core
> From: Gerd Möllmann > Cc: emacs-tangents@gnu.org > Date: Thu, 14 Sep 2023 15:03:00 +0200 > > I think the biggest problem with uncooperative multi-threading in Emacs > is that Emacs has so much global state. As a consequence, it's unsafe > to let two threads use anything in the C code in parallel. Indeed, that's the main problem. Just adding threads to Lisp is easy. > Maybe one could think of using some Python-like GIL, but that's kind > of pointless, isn't it? We already have that with the Lisp threads that we have in Emacs.
Re: [External] : Re: Shrinking the C core
> From: Arthur Miller > Cc: Gerd Möllmann , > e...@thyrsus.com, > r...@gnu.org, drew.ad...@oracle.com, a...@muc.de, luang...@yahoo.com, > emacs-tangents@gnu.org > Date: Tue, 12 Sep 2023 21:58:43 +0200 > > Eli Zaretskii writes: > > > [Redirected to emacs-tangents] > > > >> From: Gerd Möllmann > >> Cc: Richard Stallman , Drew Adams , > >> arthur.mil...@live.com, a...@muc.de, luang...@yahoo.com, > >> emacs-de...@gnu.org > >> Date: Tue, 12 Sep 2023 06:38:00 +0200 > >> > >> "Eric S. Raymond" writes: > >> > >> > But it could be done. There is a technical path forward to it. > >> > >> Which would have to cope with buffer-local bindings. > > > > Right. And the display code. And text en/decoding. And input queue. > > And faces. Etc. etc. -- these are all written in C, but are full of > > Lisp data structures and calls into Lisp, so separating them is > > anything but easy or even straightforward. > > > > People who have enough talents, knowledge, and energy to do this kind > > of job will be better off, and will serve the community better, if > > they design an Emacs differently, taking into consideration the main > > lessons we've learned. > > I don't know what you have learned, but I have learned that Guy Steel > was correct when he told the world back in 1998 already: don't really on > a few people for the development, instead make things extensible by > the users. In an applicaiton that is almost a life style for many users > and where most of users are developers as well it makes sense to use the > same implementation and extension language, because it removes a barrier > for design and experimentation. For web developers it might make sense > to write their tools in JS, for Lisp developers it make sense to use > Lisp for their tools. That would make for more sustainable development. > > > lessons we've learned. That "neo-Emacs" could have a mode whereby it > > worked in a way compatible with the current Emacs, so that people who > > must run the old applications could run them without changes. But it > > Such a "mode" would still require you to implement al that stuff you > have now, there is no way around, and I am quite sure you know it. > > Also; there is nothing that says that you can't have different > implementation under the hood. There is so much narrow-mindedness and > assumptions from you. Instead of assuming bunch of what I think or don't > think, as you always do, why don't you just ask me? I didn't answered > further in our private correspondence because of your constant assuming > what I think or don't think and so on. Ask me instead; if I haven't think > of something, or thought wrong, I'll be glad to learn about it. > > > should be based on different, more modern architectural decisions. > > Handling of buffer text, GC, the display engine, threads -- all these > > and more needs to be rethought and preferably replaced with more > > modern solutions, to avoid bumping into the same limitations right > > from the get-go. > > Yes, and what in your opinion *is* a suggestion to completely remove the > C code, which actually was a very relevant in a thread about shrinking > the C core? Also, to answer all those who can't put 1 + 1 togther by > themselves: I have suggested to remove completely C core in a thread > about shrinking the C core. I think a "maximal shrink" of C core is > quite on topic :-). > > About your "neo-design", just implementing the editor in a Lisp machine > instead of having a Lisp machine in the editor is itself already a > radical design change. Not to mention that the Lisp machine suggested > already has threading and some other tools that would make life much > easier so you could concentrate on actually improving the editor instead > of the Lisp machine. Look at other similar applications already doing it > in that "clumsy" CL; Lem already has several rendering backends. How > many do you have? > > Nobody says that you have to implement stuff under the hood the same > way; I have said we need C core and elisp semantics implemented in > CL. It is laborous but possible. Under the hood it could be implemented > with any changes needed, and in the future design could be exchanged for > something else, complemented etc. > > Anyway, your rhetorics give allusion that Emacs is dead, users should go > to greener pastures you who want something more modern dead suites their > needs. I don't know, but those are vibes I get from your
Re: Shrinking the C core
> X-Spam-Status: No, score=-1.01 tagged_above=-999 required=6.2 > tests=[ALL_TRUSTED=-1, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=disabled > From: joa...@verona.se > Cc: Eli Zaretskii , Arthur Miller , > emacs-tangents@gnu.org > Date: Tue, 12 Sep 2023 21:07:41 +0200 > > - if I'm connected to an emacs session by ssh, and mistakenly make a > cli command dump tens of megabytes of spewage to the shell buffer, I'm in > trouble > and cant easily get out of it. I need to open a new ssh session and > kill the rampaging cli. This is quite tedious. Would concurrency fix this? This should be doable, and doesn't come anywhere near the "rewrite" job. You just need a way of blocking the output from the shell, and then use Emacs commands to kill it. > - Same for long-lines, this is still not a solved problem. You didn't try Emacs 29 yet, did you? > - Gnus refreshes slowly, maybe that could be helped with concurrency, > but it could also be helped with more async work in gnus. Concurrency can help you keep reading messages while Gnus refreshes in parallel, but it won't easily help you refresh faster, unless someone comes up with a way of collecting the update in parallel chunks (in which case they should be able to do that today with the emacs-async package, I think).
Re: Shrinking the C core
> From: chad > Date: Tue, 12 Sep 2023 14:22:57 -0400 > Cc: Arthur Miller , emacs-tangents@gnu.org > > I do think that a very early step needs to be "figure out how to handle > concurrent analysis and editing > across multiple cores and perhaps machines", but that probably just reflects > a bunch of my personal > interests. One of the main advantages of multithreading in Emacs is to have a separate UI thread, so that we wouldn't have Emacs appear frozen when it does some computation. To have such a separate thread in Emacs is tricky, because we allow to run Lisp both on input and on output (redisplay). This is one of the main reasons why Emacs is so powerful, so giving this up would be a huge loss. So someone would need to figure out how to keep this feature and still run I/O in a separate thread...
Re: [External] : Re: Shrinking the C core
[Redirected to emacs-tangents] > From: Gerd Möllmann > Cc: Richard Stallman , Drew Adams , > arthur.mil...@live.com, a...@muc.de, luang...@yahoo.com, > emacs-de...@gnu.org > Date: Tue, 12 Sep 2023 06:38:00 +0200 > > "Eric S. Raymond" writes: > > > But it could be done. There is a technical path forward to it. > > Which would have to cope with buffer-local bindings. Right. And the display code. And text en/decoding. And input queue. And faces. Etc. etc. -- these are all written in C, but are full of Lisp data structures and calls into Lisp, so separating them is anything but easy or even straightforward. People who have enough talents, knowledge, and energy to do this kind of job will be better off, and will serve the community better, if they design an Emacs differently, taking into consideration the main lessons we've learned. That "neo-Emacs" could have a mode whereby it worked in a way compatible with the current Emacs, so that people who must run the old applications could run them without changes. But it should be based on different, more modern architectural decisions. Handling of buffer text, GC, the display engine, threads -- all these and more needs to be rethought and preferably replaced with more modern solutions, to avoid bumping into the same limitations right from the get-go.
Re: Shrinking the C core
[Redirected to emacs-tangents.] > From: Arthur Miller > CC: emacs-de...@gnu.org > Date: Tue, 12 Sep 2023 05:46:37 +0200 > > Mnjah; you know as well as I, and I have written it in the very first > mail why I want Emacs in Lisp. There are already other applications and > editors inpsired by Emacs, that is not the question. Problem with them > is they can't run Emacs applications and they don't have Emacs manual > and the well written documentation. I think it would be waste of the > effort of many people to throw it away. You may disagree and that is OK. It will not be a waste of effort if the "neo-Emacs" will take into consideration the main lessons we learned during those 40 years, and will have a different architectural design to avoid the pitfalls and allow extensions we cannot currently support. Reimplementing the same design in a different language, be it SBCL, Python, Go, Rust, or whatever -- that _is_ a waste of effort, because you will have the same Emacs with the same basic restrictions and limitations, which are really not expected from a modern GUI program. We tolerate them in Emacs because in return we get so much and because the performance is still reasonable as long as we can live with the limitations, but starting a radically new implementation from the same point with the same basic design means that we will have to tolerate those same limitations for decades in the future, and that's simply silly. The net result will be a huge effort, lots of work to stabilize the result to be anywhere close to what we have now, and all that for what? Which is why anyone who understands the internals well enough to do the job will never do it. Yes, this can be done in principle. But it shouldn't. P.S. And don't be afraid of losing some of the applications and the documentation -- these should be the least of your worries. Sticking to the same design for these reasons is ... I don't even have civilized words to describe this kind of thinking.
Re: [External] : Re: master 127ab231be 1/2: Attempt to clarify Input Focus documentation
> From: chad > Date: Thu, 22 Sep 2022 12:16:59 -0400 > Cc: Drew Adams , Eli Zaretskii , > "greg...@heytings.org" , "la...@gnus.org" > , Po Lu > > Back in the day, X programs knew how to distinguish between windows > appearing/disappearing on their own > and the window under the mouse being changed by the window manager, and focus > could be managed > appropriately. WM's of the time also had (configurable) thresholds for > whether such accidental movements > would trigger focus changes or not. Ironically, the MS-Windows implementation of this feature also has such thresholds. Like how much time should the mouse hover over a window before that window gets focus.
Re: Free software politics, not world politics please
You don't get the hint, do you? So now you are moderated here. Congratulations! P.S. This will happen with others as well, if they don't get the hint.
Re: Free software politics, not world politics please
Please note, all of you, that you are quickly approaching the line where this will not be appropriate even for emacs-tangents. There's nothing event remotely related to Emacs in this discussion.
Re: no to war in Ukraine
> From: Emanuel Berg via Emacs news and miscellaneous discussions outside the > scope of other > Emacs mailing lists > > Jean Louis wrote: > > > I agree to stop discussion on mailing list as it is not > > related to Emacs. > > Wars of aggression should be explicitly inconsistent with the > ideals behind free software. Once again, please stop posting off-topic messages to this list.
Re: no to war in Ukraine
> Date: Sun, 6 Mar 2022 12:49:25 +0300 > From: Jean Louis > Cc: emacs-tangents@gnu.org > > > >> Should have Adolf Hitler also be stopped peacefully be talking? > > >> Should the Holocaust be stopped by talking? Really? > > > > > > > Of course. > > > > > > I thought that was a rhetoric question but you took it seriously. > > So I am curious how is this supposed to have worked. > > By watching human rights abuses and having mechanism to immediately > act. Would we have fundamental principles globally established then we > could all act in time. Please stop these off-topic discussions here. This has nothing to do with Emacs whatsoever. We've had enough of that already. There are other forums where you can speak about this, so please take this there. Thanks in advance.
Re: Time to dial back the dialectic? [was: Re: Privileges and practicalities]
> From: dick > Date: Mon, 04 Oct 2021 09:46:49 -0400 > Cc: emacs-tangents@gnu.org > > herr Doctor, > > I'd wager the hundred or so guys who identify most with GNU would, if a > referendum were taken, say that: > > 1. Non-free is not an injustice, > > 2. *Gratis* is far and away more important to our users than *libre*, and > > 3. Non-free software can be used without compunction to improve our own *free* > software, and in countless ways, already does. > > In other words, I'll book an emission-intensive flight to the climate > conference if it means I don't have to join Greta on her toilet-less > trans-Atlantic catamaran. > > I presume NonGNU Elpa was your idea, and it was the right one. Now we just > need to take that initiative to its logical conclusion. Please don't use GNU mailing list for arguing with our views on Free Software; that is inappropriate. We have a special mailing list for such discussions: gnu-misc-disc...@gnu.org. If you want to have such a discussion, please take it there.
Re: Emacs-Lua: question about the license of one file
> From: Eduardo Ochs > Date: Tue, 7 Sep 2021 01:09:04 -0300 > > I am working on a package that contains a module written in C++ that > loads a Lua interpreter, and that implements a REPL that lets us run > that interpreter interactively from Emacs. It is here: > > https://github.com/edrx/emacs-lua > > At this moment my package is just a poorly-documented prototype, but I > would like to submit it to ELPA when it grows up. > > QUESTION. The code in the module in C++ was written by a guy who sent > it to the Lua mailing list. His message is here: > > http://lua-users.org/lists/lua-l/2021-03/msg00084.html > > Here is my version of his code: > > https://raw.githubusercontent.com/edrx/emacs-lua/main/emlua.cpp > http://angg.twu.net/emacs-lua/emlua.cpp.html > http://angg.twu.net/emacs-lua/emlua.cpp > > When my REPL became functional I sent him an e-mail saying that I > would like to prepare the package to submit it to ELPA in the future, > and asked him what he thought about doing the paperwork thing... and I > told him that if he preferred a paperworkless way that _I guessed_ > that he could just send an e-mail to the Lua mailing list declaring > his code to be in the public domain, but I would have to check that > possibility with people who are more knowledgeable than me - and he > said something equivalent to "wow, yes, great, please check!"... > > So: can we do that? And are there any other licenses that you would > recommend besides public domain? I think using a PD code may also need some paperwork, some kind of disclaimer? Richard, what are the rules in these cases?
Re: Is Bootstrap JS (MIT license) compatible with FSF?
> From: Arthur Miller > Date: Wed, 01 Sep 2021 01:21:19 +0200 > Cc: help-gnu-em...@gnu.org > > https://getbootstrap.com/docs/4.0/about/license/ Yes, this is OK.
Re: Help building Pen.el (GPT for emacs)
> Date: Sat, 24 Jul 2021 20:57:42 +0300 > From: Jean Louis > Cc: r...@gnu.org, ste...@marxist.se, mullik...@gmail.com, > emacs-tangents@gnu.org > > * Eli Zaretskii [2021-07-24 19:46]: > > > > I have never stated it is incompatible with free software, I have > > > asked how is GPL licensing compliance solved. > > > > No, you said we shouldn't use this. > > Sorry for misunderstandings. To avoid such misunderstandings, I suggest to tone down your language when you are talking about licensing issues associated with some technologies or products, so that what you write couldn't be interpreted as saying that there are legal problems which prevent our use of those technologies and products. > Question was directed to author of Pen.el and there was no clear > answer neither from you, so I found myself from online research that > at least in US for now it is based on "fair use" doctrine. > > When we take the word "fair" in its original definition, it should be > obvious from online comments that many GPL authors do not really find > it "fair". It is however one defense that all of present similar AI > models have in common, they are to use "fair use" doctrine. We will > see that. That is a separate issue, which is IMO completely unrelated. Emacs is Free Software, and is distributed under GPL, so for Emacs it is OK to allow users to use other GPL code out there in their programs. That there are producers of proprietary software who use pieces of GPL code in their proprietary products without complying with GPL is completely unrelated to what the Emacs project can do with this technology.
Re: Help building Pen.el (GPT for emacs)
> Date: Sat, 24 Jul 2021 19:18:02 +0300 > From: Jean Louis > Cc: r...@gnu.org, ste...@marxist.se, mullik...@gmail.com, > emacs-tangents@gnu.org > > * Eli Zaretskii [2021-07-24 12:00]: > > So please don't discourage independent assessment of this technology > > by posting half-baked "legal" opinions from people with questionable > > motivation (present company excluded, of course) representing that > > this technology is legally incompatible with Free Software. IMO, we > > don't yet know enough for any such definitive opinions and > > conclusions. > > Quite contrary, the GPL licensing compliance question is related to > adoption and expansion of free software. > > I have never stated it is incompatible with free software, I have > asked how is GPL licensing compliance solved. No, you said we shouldn't use this.
Re: Help building Pen.el (GPT for emacs)
> Date: Sat, 24 Jul 2021 19:16:34 +0300 > From: Jean Louis > Cc: mullik...@gmail.com, ste...@marxist.se, emacs-tangents@gnu.org, > r...@gnu.org > > > > For example when there is recommendation of proprietary software I > > > will say that GNU project does not endorse such. > > > Please consider adding "AFAIK" or somesuch, otherwise this sounds like > > you are speaking for the project. > > Thanks, but no, all opinions are private. Again, yours don't sound private, and many people will become confused at best. > You have said your opinion though you did not mention not even one > legal reference to the questions about licensing compliance that I > have mentioned. So I keep it as your differing opinion though without > references to legalities I do not find it relevant. This is a public list. It is important for me to state my differing opinions so that people could make up their own minds. > You seem to personally chase me that I stop asking questions? No. I'm trying to correct the wrong impression your postings could have made on people reading them. > It does not really seem welcoming, it seems like I did something bad > to you and you are pushing with force to stop me asking such simple > banal question. I said exactly what I think was wrong with your postings. I wish you would change the style and wording when you speak on these issues, but I have no real control on what you will do. > You please make it easy, as I am asking logical question, don't call > me radical as that has negative connotations. I explained in detail why I said that. I'm sorry to conclude that you disregard that.
Re: Help building Pen.el (GPT for emacs)
> From: Philip Kaludercic > Cc: r...@gnu.org, mullik...@gmail.com, emacs-tangents@gnu.org, > ste...@marxist.se, bugs@gnu.support > Date: Sat, 24 Jul 2021 14:49:02 + > > > How would one know it's 'long' and not some other data type? > > I am not sure what you mean? "long" makes sense here because Java will > automatically up-cast any other type to fit. So you came up with perhaps the single example that exists in the whole world where the issues I mentioned _might_ not matter, and even that only under some assumptions. A feature that aspires to be generally useful cannot possibly depend on such problematic assumptions. > >> since it is mentioned over 6000 times on GitHub (and this method even > >> has a bug, as the article explains -- but that is a totally different > >> issue). > > > > That's not how AI works: it doesn't just count the number of times > > something is mentioned. That usually leads to unsatisfactory results. > > Of course, that would be oversimplifying. At the same time, if the > training samples have common patterns, a model is more likely to > reproduce that behaviour. No, that's not it: a single example repeated in identical form many times doesn't reinforce the learned pattern. You need many similar, but different code samples, and most probably in different languages.
Re: Help building Pen.el (GPT for emacs)
> From: Philip Kaludercic
> Cc: r...@gnu.org, mullik...@gmail.com, emacs-tangents@gnu.org,
> ste...@marxist.se, bugs@gnu.support
> Date: Sat, 24 Jul 2021 14:16:55 +
>
> > Sorry, I don't understand what you have in mind. Can you show an
> > example of useful code that could be copied verbatim into a program
> > without at least some renaming, without breaking the program?
>
> To take the example from the article I mentioned above
>
> public static String humanReadableByteCount(long bytes, boolean si) {
> int unit = si ? 1000 : 1024;
> if (bytes < unit) return bytes + " B";
> int exp = (int) (Math.log(bytes) / Math.log(unit));
> String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp-1) + (si ? "" :
> "i");
> return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);
> }
>
> can be copied into a Java program, and assuming that there is no other
> method called humanReadableByteCount in the same class, it should
> compile and run without renaming or re-typing.
How would one know it's 'long' and not some other data type?
> CoPilot might generate this from a comment like,
>
> // Convert a byte count to a human-readable string
>
> since it is mentioned over 6000 times on GitHub (and this method even
> has a bug, as the article explains -- but that is a totally different
> issue).
That's not how AI works: it doesn't just count the number of times
something is mentioned. That usually leads to unsatisfactory results.
Re: Help building Pen.el (GPT for emacs)
> From: Philip Kaludercic > Cc: r...@gnu.org, mullik...@gmail.com, emacs-tangents@gnu.org, > ste...@marxist.se, bugs@gnu.support > Date: Sat, 24 Jul 2021 09:31:38 + > > >> Not necessarily, if it generates a pure, top-level function. Someone > >> could type something like "Sort list of postcodes" and it generates a > >> Radix Sort function. And if this is part of some code that was copied a > >> lot, the model might tend to generate this verbatim even more likely. > > > > A sort function must state at least the data type before it can be > > compiled. And if you are talking about pseudo-code that is data-type > > agnostic, then that's an algorithm, and is not copyrightable, AFAIK. > > No, I was thinking about concrete code, that depending on the language > might even just rely on the standard library, especially if the language > has generics. Seeing how often SO code has been found in random > repositories[0], I don't think it is improbable that the trained models > might notice these patterns. Sorry, I don't understand what you have in mind. Can you show an example of useful code that could be copied verbatim into a program without at least some renaming, without breaking the program?
Re: Help building Pen.el (GPT for emacs)
> Date: Sat, 24 Jul 2021 11:35:41 +0300 > From: Jean Louis > Cc: r...@gnu.org, ste...@marxist.se, mullik...@gmail.com, > emacs-tangents@gnu.org > > There are no doubts that code may be copied verbatin, as here is > authorized and official documentation by Github related to Copilot: > https://docs.github.com/en/github/copilot/research-recitation So we won't use that Github stuff. Which we won't anyway, because we avoid Github in general. How does this help us decide about general usability of this technology? It doesn't. > At this moment there is no verified legal statement by let us say FSF > attorneys or legal experts or some other organization that will > confirm legal status of such generated code or text on international > level. I suggest to leave the legal stuff to the legal experts. We should assess the data and provide them with facts, not make the decisions for them. Which means this discussion, and your suggestions that we should already stay away of this technology, are premature at best, if not in the wrong place at the wrong time. So please don't discourage independent assessment of this technology by posting half-baked "legal" opinions from people with questionable motivation (present company excluded, of course) representing that this technology is legally incompatible with Free Software. IMO, we don't yet know enough for any such definitive opinions and conclusions.
Re: Help building Pen.el (GPT for emacs)
> Date: Sat, 24 Jul 2021 10:54:07 +0300 > From: Jean Louis > Cc: mullik...@gmail.com, ste...@marxist.se, emacs-tangents@gnu.org, > r...@gnu.org > > * Eli Zaretskii [2021-07-24 10:33]: > > > I have never said nor implied "you work for me" and I cannot see how > > > is that relevant to the question. > > > > You consistently take the stance that implies, and many times > > explicitly states, that (a) you represent the views of the GNU > > project > > I have never in my life said so, you please stop with it. Please re-read your postings. They say otherwise. I realize that you didn't intend that, but that's how your words sound, here and elsewhere. If you want to avoid such interpretation, please take great care to tone down your categorical statements, use qualifiers like IMO and AFAIK and "I think", and generally make sure your words say that's your opinion, not an absolute truth, let alone something the GNU project decided to do or is doing. > For example when there is recommendation of proprietary software I > will say that GNU project does not endorse such. Please consider adding "AFAIK" or somesuch, otherwise this sounds like you are speaking for the project. > I was interested to find out how is legality solved when re-using the > code generated by AI. Nothing else beyond that. And I have found > references and made conclusions. And I challenged your conclusions. Nothing beyond that. > > That's not what the above document concludes. Quote: > > My conclusions are not what document conclude. I never said so. You didn't say otherwise, either. Someone who didn't have time to read the document could think that it's what the document concluded. That's why I posted the actual quotation, so that people could draw their own conclusions, or decide they do want to read the document itself. > The document is related exclusively to US jurisdiction and its final > determination is vague. It is their proposal, and not a court > decision. They have openly said that they are financially strong > enough and will try to defend any cases by using "fair use" doctrine > in the US. All true, but the same can be said about all the other posts and blogs you quoted. Which leaves us none the wiser about the problem. We still need to assess the original facts and data and make our own conclusions. I did, and my conclusions are starkly different from yours. > Everything from that document relates to US jurisdiction only. It is > one-sided thus biased document, clearly opposing the views of many GPL > authors. > > It is the corporations defense argument for ripping off the GPL > software. They found the way and wish to play on that card. > > It is document of conflict, not document of friendship or > collaboration. It is document of one-sidede defense, not a document > that contributes to free software. > > It is document that defend proprietary software, not document that > fosters free software. > > Thus it does not resolve anything in the community. It serves to one > party only. And yet you draw conclusions from it about how GNU and Emacs should behave about this technology? How does that make sense? > > > Conclusion as of 2021-07-24 is that authors cannot be sure as there > > > are legal uncertainties. > > > > Those are your personal conclusions. > > Personal definitely, but not as the only one with the same opinion, How does that make any difference? Should GNU and Emacs take the fact that several people expressed this opinion as meaning it is the truth for our purposes? Especially since some (perhaps many) of them are driven by motivation that is explicitly anti-Free Software? > which should be clear from references which left probably unread. Please don't assume I didn't read those references. You have no basis for making such nasty assumptions about me, let alone expressing them publicly here. > Legality of free software on the planet was ensured by the GPL > license. Maybe the license was never planned to be international, but > it does function well internationally. > > Legality of AI generated code and "free use" doctrine in the US is at > this point of development yet far from functioning well > internationally. Which, to me, says that we should carefully examine this issue by ourselves, not draw any premature conclusions from the hoop-la out there.
Re: Help building Pen.el (GPT for emacs)
> Date: Sat, 24 Jul 2021 10:33:57 +0300 > From: Jean Louis > Cc: r...@gnu.org, ste...@marxist.se, mullik...@gmail.com, > emacs-tangents@gnu.org > > > Eli, I do take care of licensing when re-using somebody's software, > and when publishing software or distributing it. > > There is nothing "radical" about it. Considering the license of the code is not radical, indeed. But the criteria you personally apply when considering that _are_ radical. You posted enough opinions about these matters to make that abundantly clear. There's nothing wrong with having such views, they are your personal views, and are entirely legitimate. All I'm saying is that the Emacs project should not be guided by such views, for the reasons I explained. > Concerns of other people are also not radical. No, but your interpretation of those "concerns" is. > Intention of authors is not respected even if there is legal > circumvention in the US such as "fair use", that does not fly in > other jurisdictions. So you agree that the problems you raised don't seem to exist at least in the US? > I do understand you have some unsolved issues or something you cannot > handle related to licensing No, I don't have any unsolved issues. > as you are more for technical side ??? What is that supposed to mean? > but please don't call it "radical" as that does not teach people > about GPL licensing. When I see a radical view, I call it "radical". Promoting Free Software requires healthy pragmatism, because we want the Free Software to flourish and remain relevant by picking up the advances in technology. Rejecting such new technologies just because there's some doubts expressed by someone in some blog is "radical", and IMO eventually detrimental to Free Software development. We should instead carefully and independently assess the issues and make our own judgment based on specific details of each such development. We cannot run away of every idea because some people say it might cause trouble in some cases.
Re: Help building Pen.el (GPT for emacs)
> From: Philip Kaludercic > Cc: r...@gnu.org, mullik...@gmail.com, emacs-tangents@gnu.org, > ste...@marxist.se, bugs@gnu.support > Date: Sat, 24 Jul 2021 07:41:21 + > > > It cannot be a verbatim copy, because at least the variables, and > > sometimes also the data types, need to be renamed. Whether the result > > is still under the original copyright cannot be established without > > actually comparing the two versions of the code. So any general > > flat rejection of the idea of these services on these grounds is not > > serious, IMO. > > Not necessarily, if it generates a pure, top-level function. Someone > could type something like "Sort list of postcodes" and it generates a > Radix Sort function. And if this is part of some code that was copied a > lot, the model might tend to generate this verbatim even more likely. A sort function must state at least the data type before it can be compiled. And if you are talking about pseudo-code that is data-type agnostic, then that's an algorithm, and is not copyrightable, AFAIK.
Re: Help building Pen.el (GPT for emacs)
> Date: Sat, 24 Jul 2021 06:07:18 +0300 > From: Jean Louis > Cc: mullik...@gmail.com, ste...@marxist.se, emacs-tangents@gnu.org, > r...@gnu.org > > * Eli Zaretskii [2021-07-23 22:34]: > > > Here are references disputing how "it cannot be true": > > > > You take everything you read in these blogs for granted? Did you > > actually see the original code which these allude to? > > In case of Copilot, Github admits: > https://docs.github.com/en/github/copilot/research-recitation Yes, and there are cases of real code stealing out there. The only thing that proves is that some mistaken or dishonest operators can do this. > > > I would appreciate if you find solution to that or stay on that > > > subject, as if I am wrong or right is not relevant, what I wish is to > > > have assurance that it is free software. Prove me wrong by providing > > > exact references in not only on country's law but also other > > > countries' laws, the lows that make it legal, or how otherwise the > > > legality of such code is justified and how users may get free > > > software. > > > > I'm sorry, but I don't work for you. If you have problems with using > > code from these services, then the onus is on you to do the research > > and make up your own mind. The discussion here is not about the code > > these services give their users, it's whether and how Emacs can make > > use of those services. Emacs allows the user to write proprietary > > code, and there's no legal issues when the user does that. Emacs also > > allows the user to copy someone else's code without permission, and > > that's not a problem for Emacs when the user does that. > > If you don't wish to correspond, don't, you are free. > > I have never said nor implied "you work for me" and I cannot see how > is that relevant to the question. You consistently take the stance that implies, and many times explicitly states, that (a) you represent the views of the GNU project, and (b) the GNU project should or should not do this and that. Then, when people like me object, you demand that they prove something to you, or else. But no one here is under any obligation of proving anything to you, and your views and opinions (which are quite radical, I must say) are your own and no one else's. They are your own responsibility, and if you want them to be proven or dis-proven, you should do that yourself. > If you participate in discussion and respond to my question relating > to licensing compliance, then provide a reference justifying its > legality. Or simply say you don't have such. Your employment is not > subject of my question nor relevant. I could ask you to do the same. You never provided any reference justifying the legality, just a lot of blogs that spread FUD (whose motivation, which many times is struggle against Free Software, I described in my previous message). If you demand something of your correspondents, please live up to the same high standards, or stop demanding that others do. Quoting a random selection of blog postings is NOT research and does NOT justify anything, except that the issue is being "discussed" by some people. It doesn't even mean that those discussions are serious, let alone that whoever posts those opinions doesn't have an agenda. > I am not user of proprietary software and I don't consider options of > writing proprietary software. Neither I am participating in discussion > to foster ideas of creation of proprietary software. > > I am free software user and for that specific case I am interested how > the licensing issue is solved. You are free to do whatever you like in your work; that is your prerogative and no one else's. But here we discuss what the Emacs project should or should not do about this technology, not your private decisions. > 2. OpenAI_RFC-84-FR-58141.pdf > https://www.uspto.gov/sites/default/files/documents/OpenAI_RFC-84-FR-58141.pdf > > Conclusions are: > > - legal justifications exists for US jurisdiction as the companies > providing the AI are strong enough to find their ways, they are > playing on the card as given in references above; as somebody > already said, I doubt they would use "fair use" doctrine if the AI > would be trained on proprietary software such as Windows; > > - conflict is serious and it is out there among the people and remains > unsolved; AI has been trained on GPL and other free software and is > used by corporations to generate new code without attributions; > people complain that it is misuse of intentions of authors; > > - overall international legal situation is t
Re: Help building Pen.el (GPT for emacs)
> From: Richard Stallman > Date: Fri, 23 Jul 2021 21:14:23 -0400 > Cc: ste...@marxist.se, e...@gnu.org, mullik...@gmail.com, > emacs-tangents@gnu.org > > > > That's not what happens with these services: they don't _copy_ code > > > from other software (that won't work, because the probability of the > > > variables being called by other names is 100%, and thus such code, if > > > pasted into your program, will not compile). What they do, they > > > extract ideas and algorithms from those other places, and express them > > > in terms of your variables and your data types. So licenses are not > > > relevant here. > > > According to online reviews chunks of code is copied even verbatim and > > people find from where. Even if modified, it still requires licensing > > compliance. > > From what I have read, it seems that the behavior of copilot runs on a > spectrum from the first description to the second description. I > expect that in many cases, nothing copyrightable has been copied, but > in some cases copilot does copy a substantial amount from a > copyrighted work. It cannot be a verbatim copy, because at least the variables, and sometimes also the data types, need to be renamed. Whether the result is still under the original copyright cannot be established without actually comparing the two versions of the code. So any general flat rejection of the idea of these services on these grounds is not serious, IMO. Of course, someone like Jean will not use any code until a bunch of lawyers submit an official opinion about the legal implications, but IMO that's a radical view that doesn't make a lot of sense, especially since none of the code accessible openly via the net can be proprietary, for obvious reasons. Jean could do whatever he personally likes, but his radical views don't necessarily bind the GNU project in general and Emacs in particular. Moreover, ironically Jean bases his views on opinions and issues expressed by clear opponents of Free Software. The strongest drive behind many of these blogs' aversion from these services is the fear that GPL-licensed code creeps into proprietary software produced by enterprises and their software subcontractors, because that would require them to make the sources available or at least put them at a risk of lawsuits. It is a well-known fact that most, if not all, software contracts for proprietary software nowadays include explicit prohibition of using GPL-licensed code in the product. It is those people that serve these contracts and enterprises who drive the whoop-la about licensing issues in code offered by these AI-based services. So before embracing their FUD and biased opinions, I really suggest to actually look at the code, compare it with the original, and make an independent assessment of both whether it's a "copy" from the copyright POV and of the licenses of the original code.
Re: Help building Pen.el (GPT for emacs)
> Date: Fri, 23 Jul 2021 15:47:21 +0300 > From: Jean Louis > Cc: mullik...@gmail.com, ste...@marxist.se, emacs-tangents@gnu.org, > r...@gnu.org > > * Eli Zaretskii [2021-07-23 14:51]: > > > According to online reviews chunks of code is copied even verbatim and > > > people find from where. > > > > That cannot be true. It is nonsense to copy unrelated code into a > > program and tell people this is what they should use. > > I wonder how sure you are in that, did you do the online research? It > is not about related or unrelated, I do believe that AI finds and > generates related code. But > > Here are references disputing how "it cannot be true": You take everything you read in these blogs for granted? Did you actually see the original code which these allude to? > > > If code compiles or not is irrelevant. If one runs it or not is also > > > irrelevant, code need not even run. > > > > A feature or service that is based on this idea will never fly, > > believe me. Which program would want to have code pasted into his/her > > program that would cause compilation errors or, worse, break it at run > > time? > > Of course people want code to fun. Just that copyright laws don't > handle technical functionality. It is irrelevant if program works or > does not work. For copyright purposes, it doesn't. But for the programmer who uses the code it very much does. So if these services give them code that doesn't work they will not use it, and eventually will stop using the services. > > Once again, your assumptions are all wrong, so your conclusions are > > also wrong. Why not try one of these services and see what they > > actually do, before you pass your (quite harsh) judgment on them, and > > on the modern state of AI in general? > > I can hear you how I am wrong, conclusions are wrong, though I gave > you references enough to research it on Internet that will tell that > there are possible serious licensing problems with such generated > code. See above. > Question is very particular, specific and concrete: > ━━━ > > How does Pen.el and background AI services ensure of licensing > compliance? > > I would appreciate if you find solution to that or stay on that > subject, as if I am wrong or right is not relevant, what I wish is to > have assurance that it is free software. Prove me wrong by providing > exact references in not only on country's law but also other > countries' laws, the lows that make it legal, or how otherwise the > legality of such code is justified and how users may get free > software. I'm sorry, but I don't work for you. If you have problems with using code from these services, then the onus is on you to do the research and make up your own mind. The discussion here is not about the code these services give their users, it's whether and how Emacs can make use of those services. Emacs allows the user to write proprietary code, and there's no legal issues when the user does that. Emacs also allows the user to copy someone else's code without permission, and that's not a problem for Emacs when the user does that. > As long as you don't tackle those subjects there is no legal solution > for Pen.el and background AI to be used with assurance that software > is truly free software. You confuse "free software" with "software being used to write free programs". They are not the same.
Re: Help building Pen.el (GPT for emacs)
> Date: Fri, 23 Jul 2021 14:32:00 +0300 > From: Jean Louis > Cc: mullik...@gmail.com, ste...@marxist.se, emacs-tangents@gnu.org, > r...@gnu.org > > > That's not what happens with these services: they don't _copy_ code > > from other software (that won't work, because the probability of the > > variables being called by other names is 100%, and thus such code, if > > pasted into your program, will not compile). What they do, they > > extract ideas and algorithms from those other places, and express them > > in terms of your variables and your data types. So licenses are not > > relevant here. > > According to online reviews chunks of code is copied even verbatim and > people find from where. That cannot be true. It is nonsense to copy unrelated code into a program and tell people this is what they should use. > If code compiles or not is irrelevant. If one runs it or not is also > irrelevant, code need not even run. A feature or service that is based on this idea will never fly, believe me. Which program would want to have code pasted into his/her program that would cause compilation errors or, worse, break it at run time? > I do not believe that any of the AI-s so far "extract ideas". I never > heard of it. Which algorithms is there on this planet that may extract > idea? That's a very general question, it is impossible to answer it in a post to a mailing list. If you are really interested, you will have to read up on that. But you are wrong in your beliefs. > If newly generated code is modification from other code, what we know > now that it is, and is based on, that requires licensing > attributions. Once again, your assumptions are all wrong, so your conclusions are also wrong. Why not try one of these services and see what they actually do, before you pass your (quite harsh) judgment on them, and on the modern state of AI in general? > That licenses are relevant one can see from online discussions related > to Github Copilot: That people ask these questions and discuss this doesn't mean the problem is real. many people don't really understand what copyright means and how to apply it to program code. People also ask questions about the GPL, and there's a vociferous group of people who think the copyright assignment of code to the FSF means you give up all your rights in the code you've written. None of that is true, but still the rumors and the heated discussions go on and on. Their existence proves nothing, except that some people misunderstand something.
Re: Help building Pen.el (GPT for emacs)
> Date: Fri, 23 Jul 2021 13:12:12 +0300 > From: Jean Louis > Cc: Eli Zaretskii , Stefan Kangas , > emacs-tangents@gnu.org, r...@gnu.org > > You are using artificial intelligence, but in fact pieces of codes are > in chunks copied from other sources without attribution and without > knowing if licenses are compatible. That's not what happens with these services: they don't _copy_ code from other software (that won't work, because the probability of the variables being called by other names is 100%, and thus such code, if pasted into your program, will not compile). What they do, they extract ideas and algorithms from those other places, and express them in terms of your variables and your data types. So licenses are not relevant here.
Re: Require "this program is free software .... " notice to be preserved on the splash screen
> From: Dmitry Gutov > Date: Sat, 13 Feb 2021 14:04:29 +0200 > Cc: Richard Stallman > > On 11.02.2021 08:04, James Lu wrote: > > "You may convey verbatim copies of the Program's source code as you > > receive it, in any medium, **provided that you conspicuously and > > appropriately publish on each copy an appropriate copyright notice**; > > keep intact all notices stating that this License and any non-permissive > > term" > > Spacemacs and similar "distributions" actually don't redistribute Emacs > itself. They're just collections of extensions together with > instructions for installing them. > > So I don't think this condition can apply, legally speaking. > > (IANAL, though.) Please continue this discussion on emacs-tangents (replies redirected there).
Re: Require "this program is free software .... " notice to be preserved on the splash screen
> Date: Sat, 13 Feb 2021 13:48:05 +0300 > From: Jean Louis > Cc: Richard Stallman , emacs-de...@gnu.org > > * James Lu [2021-02-13 08:13]: > > Some distributions of Emacs, such as Spacemacs, replace Emacs' splash > > screen with one that heeds no mention to free software. (Spacemacs includes > > a logo of Spacemacs, a bunch of menu items, and a changelog.) > > > > In order to avoid another fiasco of the sort of the GNU/Linux controversy, > > where a variant of GNU software was called something else and disassociated > > from free software, I propose we exercise section 7.4 of GPLv3 to require > > "require preservation of specified reasonable legal notices or author > > attributions in that material or in the Appropriate Legal Notices displayed > > by works containing it" > > That is right. Is the bug reported to Spacemacs? What is the reaction? PLEASE take this discussion to emacs-tangents. I've redirected the response there.
Re: [ELPA] New package: repology.el
> From: Richard Stallman > Cc: a...@gnu.org, dgu...@yandex.ru, e...@gnu.org, bugs@gnu.support, > u...@gentoo.org, emacs-tangents@gnu.org > Date: Tue, 12 Jan 2021 01:10:34 -0500 > > > I think the problem at hand here is how we, or some people, define > > actively promoting something. Is a mere reference to existence a > > promotion of something? > > In some cases it is. Spreading the word about an obscure program > is promoting it, since that information would lead some people to > use them. I think nowadays the information is so pervasive and so easily found that refraining from mentioning some program or site has no real advantages. It does have disadvantages: for example, we let our enemies mock us.
Re: [ELPA] New package: repology.el
> From: Richard Stallman > Cc: a...@gnu.org, e...@gnu.org, bugs@gnu.support, > arthur.mil...@live.com, u...@gentoo.org, emacs-tangents@gnu.org > Date: Sat, 09 Jan 2021 01:41:30 -0500 > > > If you are making an emphasis on never mentioning "wrong" programs, you > > make a conscious choice toward ignoring them, as opposed to studying > > them and overtaking them. > > Of course. We intentionally, specifically, avoid mentioning obscure > nonfree programs as options to be used. Providing information about a program is not "using" that program. > (We may mention them to condemn them.) So there _are_ situations where mentioning such packages is okay. repology.org is a site that would allow us do that, by providing the information we need to use for the decision of whether they should or shouldn't be condemned. Therefore, I conclude that repology.org does a job that is useful for us, and we shouldn't refrain from using that site, definitely not as a dogmatic postulate some people here presented.
Re: [ELPA] New package: repology.el
> From: Richard Stallman > Cc: bugs@gnu.support, emacs-tangents@gnu.org, u...@gentoo.org, > a...@gnu.org, arthur.mil...@live.com, dgu...@yandex.ru > Date: Sat, 09 Jan 2021 01:41:21 -0500 > > > I want help them because I don't see how these references cause any > > damage to the Free Software cause. Promoting non-free software and > > inviting users to use it is indeed against our cause, but just telling > > where it's stored isn't. > > Telling people that the package _exists_ is what we want to avoid. I'm quite sure this is a misguided effort. For example, there's no reason not to tell them it exists, if you at the same time tell them it's non-free and urge them to use a free replacement instead. Thus, the urge to avoid divulging this information is not absolute, and we should talk about when it's okay and when it isn't, instead of flatly refusing to divulge the information as an absolute principle. > > I don't think the GNU project is about concealing information. I hope > > it isn't. > > The information is available to the public without our help, so > we are not concealing it. But we have no obligation to go out > of our way to spread the word. Having a single package that works with a single site is a far cry from going out of our way. Let's not exaggerate, please. > > Not mentioning a program does nothing towards eliminating it, > > Actually it does, sometimes. If we avoid mentioning a program we > avoid recruiting more users for it. That's an assumption, and I don't think it's true in this era of abundance of information. > That can eventually contribute to its elimination. That's another assumption, which I think is even less true. I could argue the opposite: by not mentioning such a program we leave the field to those who will promote it and lure users to use it. Whereas if we do mention it and say that it's non-free or has other issues (like spying on its users) we allow the users to make better decisions regarding its use. > The point is, it avoids leading people to use that program. But it does that badly, if it ever does. > A nonfree program denies freedom to its users. If we lead a person > to use the nonfree program, we lead per to surrender freedom to it. > Therefore we try to avoid that. I'm not arguing for leading people towards using such programs. I'm saying that pretending they don't exist is a very inefficient strategy, to say the least, towards the goal of leading users away from them.
Re: [ELPA] New package: repology.el
> From: Richard Stallman > Cc: e...@gnu.org, bugs@gnu.support, arthur.mil...@live.com, > dgu...@yandex.ru, u...@gentoo.org, emacs-tangents@gnu.org > Date: Sat, 09 Jan 2021 01:37:13 -0500 > > >You are saying those programs are breaking the law? > > > The GNU project policy is to not legitimizes non-free software, what > > the law says is irrelevant here. So I fail to see what law has to do > > with anything. > > I think there is a linguistic misunderstanding here. "Legitimate" can > mean "legitimate according to the law" or "legitimate according to > standards of right and wrong". I generally use it in the latter > sense, and I think you do too. Maybe Eli applied the first > interpretation. We have a rule not to use "illegal" for anything that isn't a violation of the law, and we have that rule for a good reason. Why should we treat "legitimize" any differently? it has the same issue.
Re: [ELPA] New package: repology.el
> From: Richard Stallman > Cc: dgu...@yandex.ru, e...@gnu.org, bugs@gnu.support, > arthur.mil...@live.com, u...@gentoo.org, emacs-tangents@gnu.org > Date: Sat, 09 Jan 2021 01:37:10 -0500 > > The issue about repology.org is not about that. It is whether we > should tell the public about its existence, for instance by including > in Emacs a program specifically aimed at that site. I'm part of that public, so if you don't tell me about that site, I won't know about it.
Re: [ELPA] New package: repology.el
> From: Richard Stallman > Date: Sat, 09 Jan 2021 01:35:54 -0500 > Cc: emacs-tangents@gnu.org, bugs@gnu.support, u...@gentoo.org, a...@gnu.org, > arthur.mil...@live.com, dgu...@yandex.ru > > > Just saying that a package exists and showing where its repository is > > etc. is nowhere near promotion, it's simply information. > > Please see the node References in the GNU Coding Standards for an > explanation of why informing people that an obscure package exists is > a form of promoting it. As I explained elsewhere, I think this part of GSoC is a mistake and should be fixed. It goes too far in its desire to avoid promoting non-free software, and that extremism in this case harms our own cause. The wording should be more balanced, or we should have some qualifications in the text to the effect that neutral information about software packages is not promotion.
Re: [ELPA] New package: repology.el
> From: Richard Stallman > Cc: bugs@gnu.support, arthur.mil...@live.com, a...@gnu.org, > dgu...@yandex.ru, u...@gentoo.org, emacs-tangents@gnu.org > Date: Sat, 09 Jan 2021 01:35:54 -0500 > > So if using repology.org helps you work on Emacs, by all means use it. > (Did anyone here say you shouldn't?) > > But we shouldn't refer _the public_ to repology.org. I'm part of that public, and so are the other GNU maintainers. I see no reason why I should know about repology.org, but other Emacs users cannot. Your words could also be interpreted to mean that every single user of Emacs can know about repology.org, but all of them together shouldn't. That interpretation sounds very strange and even absurd to me, but the way you (and others) worded this rule speaks for itself.
Re: [ELPA] New package: repology.el
> Date: Fri, 8 Jan 2021 21:27:42 +0300 > From: Jean Louis > Cc: emacs-tangents@gnu.org, r...@gnu.org, u...@gentoo.org, a...@gnu.org, > arthur.mil...@live.com, dgu...@yandex.ru > > > We develop Emacs because we think it helps users. We don't develop it > > as some academic exercise to be shown in some ivory tower, nor as > > merely an example of what Free Software can become. > > > > I came to Emacs because it helped me do my everyday's work, and I've > > taken upon myself the burden of being its maintainer because I want it > > to help others, and become better at helping them. > > > > Thus, whether I personally can access that site is immaterial. I > > don't need your, or anybody's, permission to do whatever I want with > > my systems. It's the Emacs user community that I'm trying to help, > > and I believe I'm not the only one who needs to do those tasks that I > > described. Refusal to make this, or any other package that has the > > similar audacity of showing information about software in a completely > > neutral way, to be available from GNU ELPA diminishes from the > > community, and thus hurts me in my effort to help the community > > members to enjoy software freedom. That is why I'm speaking up. > > If I understand it better you wish to help general Emacs users without > regard if GNU as project would be giving all those references to > non-free software. I want help them because I don't see how these references cause any damage to the Free Software cause. Promoting non-free software and inviting users to use it is indeed against our cause, but just telling where it's stored isn't. Our users aren't babies from whom we should hide potentially dangerous stuff, they can make their own informed decisions. > you have known that GNU project is about free software. I don't think the GNU project is about concealing information. I hope it isn't.
Re: [ELPA] New package: repology.el
> From: "Alfred M. Szmidt" > Date: Fri, 08 Jan 2021 12:22:36 -0500 > Cc: emacs-tangents@gnu.org, r...@gnu.org, bugs@gnu.support, u...@gentoo.org, > arthur.mil...@live.com, e...@gnu.org > >> If the goal of the GNU project is to eliminate non-free software, >> why > >Eliminate it by ignoring it, I take it. > > Not mentioning a program isn't the same as ignoring its existance. Not mentioning a program does nothing towards eliminating it, so it is not a means to that end.
Re: [ELPA] New package: repology.el
> From: "Alfred M. Szmidt" > Cc: dgu...@yandex.ru, bugs@gnu.support, arthur.mil...@live.com, > r...@gnu.org, u...@gentoo.org, emacs-tangents@gnu.org > Date: Fri, 08 Jan 2021 12:22:38 -0500 > > I do not understand what is so confusing here, how you as a person (in > the capacity of a mainainter or not) wish to figure out stuff and what > the GNU project links to are two entierly orthogonal issues. They aren't: I _want_ to use GNU software. I do use it as much as I can. Otherwise I wouldn't be here. I do not understand how this simple idea is so hard to understand.
Re: [ELPA] New package: repology.el
> Date: Fri, 08 Jan 2021 13:56:40 + > CC: emacs-tangents@gnu.org, r...@gnu.org, u...@gentoo.org, a...@gnu.org, > arthur.mil...@live.com, dgu...@yandex.ru > From: Jean Louis > > Does that mean you wish to exclusively include repology.el into GNU ELPA? > > Like you can't use that package without including it in GNU ELPA? Can you use > website directly? > > I can. > > What is real problem there? I thought it was obvious. Since it's evidently isn't, let me cross the t's and dot the i's for you: We develop Emacs because we think it helps users. We don't develop it as some academic exercise to be shown in some ivory tower, nor as merely an example of what Free Software can become. I came to Emacs because it helped me do my everyday's work, and I've taken upon myself the burden of being its maintainer because I want it to help others, and become better at helping them. Thus, whether I personally can access that site is immaterial. I don't need your, or anybody's, permission to do whatever I want with my systems. It's the Emacs user community that I'm trying to help, and I believe I'm not the only one who needs to do those tasks that I described. Refusal to make this, or any other package that has the similar audacity of showing information about software in a completely neutral way, to be available from GNU ELPA diminishes from the community, and thus hurts me in my effort to help the community members to enjoy software freedom. That is why I'm speaking up.
Re: [ELPA] New package: repology.el
> Date: Fri, 08 Jan 2021 11:48:53 + > CC: r...@gnu.org, u...@gentoo.org, arthur.mil...@live.com, > dgu...@yandex.ru > From: Jean Louis > > That is maybe your way of finding free software. Since 1999 I find it from > distributions and if I don't believe it enough I will look into license. I'm not talking about finding free software, I'm talking about determining whether a given package is free software, and under what license it is distributed. The FSD doesn't give me that information. It also doesn't give me enough information about related components, like fonts, for example. Finding the facts about these components is the bread and butter of every GNU maintainer for a more-or-less complex GNU package. Not being able to do this part of my job with GNU-endorsed free software is a major blow. And the most painful part of that blow is that I cannot understand the reasons for it. Once again, repology.org does NOT promote any software packages it lists, regardless of what you'd like to represent. Likewise, such limitations prevents users from being able to study source code of any package that shows its code, something I think is detrimental to free exchange of ideas about software, which I always thought was the important goal of GNU.
Re: [ELPA] New package: repology.el
> From: "Alfred M. Szmidt" > Cc: dgu...@yandex.ru, bugs@gnu.support, arthur.mil...@live.com, > r...@gnu.org, u...@gentoo.org, emacs-tang...@gnu.org > Date: Thu, 07 Jan 2021 16:07:17 -0500 > >I presented a practical problem I have every day in my role as a GNU >maintainer. Why can't you respond to that specific problem, which is >both of practical interest and of relevance to Emacs? > > Because I don't see how it is a problem that the GNU project is going > to solve. Nor is it one _I_ wish to help you solve either, because I > think non-free software is bad so I'm won't be helping with that. It > is also not a task that you must solve as a GNU maintainer, you can > fully ignore it infact if you so want to -- but that is up to you. How can I ignore a package before I _know_ that it is non-free? And how can I know it's non-free except by looking at it?
Re: [ELPA] New package: repology.el
> From: "Alfred M. Szmidt" > Cc: e...@gnu.org, bugs@gnu.support, arthur.mil...@live.com, > r...@gnu.org, u...@gentoo.org, emacs-tangents@gnu.org > Date: Thu, 07 Jan 2021 16:07:13 -0500 > >> You are exagerating. Nobody is saying don't do research, I'm quite >> sure you are capable of finding that information on your own. But it >> is a different thing for GNU do provide that information for you. > >But GNU software shouldn't help me in research? > > In the research of non-free software, obviously no. And that is a serious problem, because GNU maintainers need to do that quite frequently, as part of their job they do for GNU. And other software users and professionals are likely to do that as well, in order to study software algorithms and implementations. Let me remind you that (AFAIK) one of the main reasons for starting GNU was the inability to share ideas about software design and implementation, due to commercial entities' enforcement of a system where showing the code was prohibited. It would be ironic if the GNU project prevented its followers from exercising the same freedom, by denying us the information about where to find that source code to begin with.
Re: [ELPA] New package: repology.el
> Date: Fri, 8 Jan 2021 00:00:36 +0300 > From: Jean Louis > Cc: arthur.mil...@live.com, r...@gnu.org, a...@gnu.org, > dgu...@yandex.ru, u...@gentoo.org, emacs-tangents@gnu.org > > > > I see that repology.org does not make any distinction and it cannot do > > > that easily technically. So it does not make neither free software nor > > > proprietary better or worse by any reasons. And that is the problem. > > > > How is it a problem? where's the promotion, please? > > A WWW index of hyperlinks is promotion of hyperlinks. Simple placement > of a hyperlink on anybody's website is promotion of the other > website. That doesn't match the meaning of the word, please re-read its definition. Reference and promotion are not the same thing. > Since 2021, GNU project did not provide references to proprietary > software. What GNU project does is not sacred. The policy is set by humans, and the reasoning for that policy is human reasoning. Thus, arguments about what we have been doing are not valid as reasons against changes in that policy, because new convincing reasoning, as well as specific new practical use cases brought to light, can legitimately change or augment existing policies. Failure to do so, or even to consider changes, would mean that GNU is a dogmatic movement, which it isn't, and never has been. > I would be surprised if GNU project begins doing that from 2021, as > if we continue disintegrating the basic principles of GNU project, > by 2031 we may expect something worse, maybe total disappearance of > GNU project in its sense of free software teaching center. Forgive me my language, but this is FUD. You have no real basis for spreading such fears. It isn't like what's proposed here is cancellation of the GNU Manifesto or anything basic like that.
Re: [ELPA] New package: repology.el
> Date: Thu, 7 Jan 2021 23:31:47 +0300 > From: Jean Louis > Cc: arthur.mil...@live.com, r...@gnu.org, a...@gnu.org, > dgu...@yandex.ru, u...@gentoo.org, emacs-tangents@gnu.org > > > Where do you see the "in order to increase its popularity" part? That > > would mean to say something about the non-free packages that would > > represent them as beneficial or better than others or worthy of > > installing and using. I see none of that. > > I see that repology.org does not make any distinction and it cannot do > that easily technically. So it does not make neither free software nor > proprietary better or worse by any reasons. And that is the problem. How is it a problem? where's the promotion, please? > > GNU ELPA is not the issue here. The issue here is total rejection of > > software that dares to provide information about software packages > > which might not be Free Software. I explained why finding such > > information is important to me in my role as a GNU maintainer. > > I am only talking about GNU ELPA and if repology.org should be in GNU > ELPA as that way we would influence millions of people by giving them > references to non-free software. It would speak badly of GNU project. > > But that you use the package yourself, that is freedom of choice. But that's immoral, isn't it? If some other maintainer asks me how to do this job, I cannot tell him or her about repology.org, can I? If I do, Jean Louis will pounce on me and say that it's against GNU policies, right?
Re: [ELPA] New package: repology.el
> Date: Thu, 7 Jan 2021 22:38:15 +0300 > From: Jean Louis > Cc: arthur.mil...@live.com, r...@gnu.org, a...@gnu.org, > dgu...@yandex.ru, u...@gentoo.org, emacs-tangents@gnu.org > > Software repository is promotion of software. repostory.org is not a repository of software. It is a list of software. > Repository package descriptions are promotion of software. > > The Wiktionary describes it as "dissemination of information in order > to increase its popularity" in the context of what we speak of: Where do you see the "in order to increase its popularity" part? That would mean to say something about the non-free packages that would represent them as beneficial or better than others or worthy of installing and using. I see none of that. Just saying that a package exists and showing where its repository is etc. is nowhere near promotion, it's simply information. > In general I am surprised that some people like or wish to get access > to descriptions of non-free software packages through GNU ELPA. GNU ELPA is not the issue here. The issue here is total rejection of software that dares to provide information about software packages which might not be Free Software. I explained why finding such information is important to me in my role as a GNU maintainer.
Re: [ELPA] New package: repology.el
> From: "Alfred M. Szmidt" > Cc: bugs@gnu.support, arthur.mil...@live.com, r...@gnu.org, > dgu...@yandex.ru, u...@gentoo.org, emacs-tangents@gnu.org > Date: Thu, 07 Jan 2021 13:18:35 -0500 > >> The GNU project doesn't want to give non-free software the remote >> changes of success, so mentioning or linking to it unless it is >> very well known would be working against its own goals. > >So you are basically saying that no GNU package can ever help me >find out information about potentially non-free software? > > Why should a GNU project ever give any legitimacy to a (specifically, > unknown) non-free software program? E.g., by listing information > about it or linking to it. I explained why. You elided that. I guess you are unwilling to engage in a serious discussion of a practical problem. Oh well. >I see no problem here, either: repology.org doesn't promote or >legitimize any of the packages whose information it records. > > It does so by listing (describing) them; that legitimizes the non-free > programs. You are saying those programs are breaking the law? >Maybe we should continue this discussion on another, more suitable >GNU list. > > When I remeber, I try to replace emacs-devel@ -- but sometimes one > forgets. I've replaced emacs-devel@ with emacs-tangents@; maybe some > other list might be more appropriate? I see no reason to continue, since you basically ignore all the substance. I presented a practical problem, and you instead chose to respond on an abstract philosophical level. Sorry, not interested.
Re: Emacs User Survey 2020 Results
> From: Samuel Wales > Date: Thu, 10 Dec 2020 14:30:01 -0700 > Cc: emacs-tangents@gnu.org, Adrien Brochard > > (as an analogy, if you go to a doctor who does not treat you, you will > not go back to that doctor. but the doctor might think that you were > cured because you did not go back. this is a serious problem in > medicine.) But since we are not talking about one person, but many different persons, it is still surprising that we don't get such bug reports, because surely some of these persons may not know or assume up front that these problems are unlikely to be fixed. It isn't like there's a secret cabal of people who spread the idea that these problems are unlikely to be fixed and therefore shouldn't be reported. The law or large numbers should have won here. It is surprising that it didn't.
Re: TODO crdt-stop-session, selecting deleted buffer, fails to remove session from the list
> Date: Fri, 23 Oct 2020 11:10:28 +0300 > From: Jean Louis > Cc: emacs-tangents@gnu.org > > I will post this to emacs-tangents, maybe other people wish to > contribute to this package. emacs-tangents is not for discussing Emacs development in general and Emacs packages in particular. That should happen on emacs-devel. This list is for issues that are only tangentially related to Emacs.
Re: [ANNOUNCE] mailaprop: modern popup-style autofill for email addresses
> From: Lars Ingebrigtsen > Cc: kfo...@red-bean.com, emacs-tangents@gnu.org > Date: Wed, 17 Jan 2018 11:53:23 +0100 > > Eli Zaretskii writes: > > > Thanks, but as with any documentation fixes, this should have been > > done on the release branch. > > I assumed that the release branch was too close to release for > non-regression patches; even doc string additions. No, we are not there yet. > I'll cherry-pick the patch and push it. Thanks.
Re: [ANNOUNCE] mailaprop: modern popup-style autofill for email addresses
> From: Lars Ingebrigtsen > Date: Tue, 16 Jan 2018 14:54:11 +0100 > Cc: Emacs Tangents > > And I've now added doc strings and comments to ecomplete.el on master. Thanks, but as with any documentation fixes, this should have been done on the release branch.
Re: The poor state of documentation of pcase like things.
> Cc: dan...@dancol.org, michael_heerde...@web.de, d...@gnu.org, > emacs-tangents@gnu.org > From: Dmitry Gutov > Date: Sun, 3 Jan 2016 06:08:35 +0200 > > On 01/03/2016 05:47 AM, Eli Zaretskii wrote: > > > The syntax of 'when' is nowhere as complex as that of 'pcase'. > > Obviously. > > But the given example uses a simple, small subset of pcase syntax. If > you don't want to use even that, it seems to indicate that you're going > to avoid the more complex uses of it even more so. And thus, never use > pcase at all. > > Which doesn't seem like a good choice, from my perspective. But that's not my choice. My choice is to use 'pcase' where it's really needed.
