* Xref Fallback
@ 2020-08-10 17:10 75% Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-08-10 17:10 UTC (permalink / raw)
To: emacs-devel
Hi,
a few weeks ago, I managed to port "dumb-jump"[0] to use Xref instead of
it's own custom interface[1]. Part of the transition was to deprecate
the old commands[2], that has lead to some complaints among
"lsp-mode"[3] users, because lsp-mode doesn't fall back on dumb-jump if
it has no results[4].
Part of the issue is that LSP's Xref activation function just returns
"'xref-lsp", the symbol that is specializes it's xref methods on,
without any checking -- which is fairly common from what I see. But if
that fails, Xref won't go on searching, even though the next backend
could have more to offer.
Before writing this message, I was fairly sure that there were some
discussions on this issue, but I couldn't find them in the archives
anymore, so just to be safe, I re-iterated the problem.
What I would want to know, is if there have been discussion on this
issue, what the status is, and if not what would have to be done. I can
imagine, that falling back onto the next backend isn't always desirable
(especially if etags is next, and it demands a TAGS file that doesn't
exist).
[0] For those unfamiliar, dumb-jump is a package for finding places
where functions or variables are defined, but without any permanent
external tools such as etags or indexing servers, but by using grep
or grep-like tools and a search-database
(https://github.com/jacktasia/dumb-jump).
[1] https://github.com/jacktasia/dumb-jump/pull/343
[2] https://github.com/jacktasia/dumb-jump/pull/349
[3] https://github.com/emacs-lsp/lsp-mode/
[4] https://github.com/jacktasia/dumb-jump/issues/353#issuecomment-671462247
[5] https://github.com/emacs-lsp/lsp-mode/blob/00fcee92ae2e57055fdb31d25741b9637fe96215/lsp-mode.el#L6174
^ permalink raw reply [relevance 75%]
* Re: Xref Fallback
@ 2020-08-11 18:19 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-08-11 18:19 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Dmitry Gutov <dgutov@yandex.ru> writes:
>> What I would want to know, is if there have been discussion on this
>> issue, what the status is, and if not what would have to be done. I can
>> imagine, that falling back onto the next backend isn't always desirable
>> (especially if etags is next, and it demands a TAGS file that doesn't
>> exist).
>
> How would you feel about creating an xref backend that would implement
> the fallback logic? It would basically only do the combining, without
> having any navigation logic of its own.
>
> This way users could include it in the xref-backend-functions to enable
> fallback mechanics. The said combinator backend could also hardcode some
> particular backends to skip.
This sounds interesting, I'll try to get something like this
working. Would this be merged into Xref, or should it be a separate package?
^ permalink raw reply [relevance 99%]
* Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions
@ 2020-09-05 19:06 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-05 19:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, dgutov
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Why do we need to invent a small language for that?
>> Check out the discussion in bug#42386.
>
> In that case, could someone try and make this "set of buffers" work not
> just for project-kill-buffers but also for all those other places where
> we want a similar specification, such as `font-lock-global-modes`,
> `desktop-buffers-not-to-save`, ... ?
Sure, but wouldn't that mean that this functionality would have to be
published in it's own ELPA package or project.el would have to depend on
something like Emacs 27.2?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions
@ 2020-09-06 21:42 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-06 21:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, dgutov
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Sure, but wouldn't that mean that this functionality would have to be
>> published in it's own ELPA package or project.el would have to depend on
>> something like Emacs 27.2?
>
> That'd be a very secondary problem, to which we can easily imagine
> various solutions, so that shouldn't stop us from doing the right thing.
Of course, but the main problem seems to be to decide which solution to
pick. The code (project--kill-buffer-check and project--buffers-to-kill)
is already close-to generic enough to be easily moved around.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Changes for emacs 28
@ 2020-09-09 17:01 91% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-09 17:01 UTC (permalink / raw)
To: Göktuğ Kayaalp
Göktuğ Kayaalp <self@gkayaalp.com> writes:
> On 2020-09-09 14:22 +03, Gregory Heytings via Emacs development discussions. <emacs-devel@gnu.org> wrote:
>> Would it not be better to have a "guided tour" (something like C-h t,
>> but shorter and more "modern") for first-time users (those without a
>> .emacs / .emacs.d)? This is quite common in "modern" software, so it
>> would not surprise anyone.
> [...]
>> (In fact, it would perhaps make sense to create a few guided tours,
>> with an initial question "Are you a programmer? a scientist? a
>> teacher? a writer?" with which the set of options could be narrowed.)
>
> Why not instead just have nicer introductory material? E.g. videos that
> walk through initial customisation for different setups, that discuss
> and explain things, talk about tangents.
>
> This actually is produced by the community, but it’s scattered around
> YouTube. We could ask prolific producers to prepare 20-30min videos for
> some particular setup, showing how to get going with Emacs in that
> particular niche.
Why 20-30 minutes? I think limiting it to 2-3 minutes for specific
problems would be more helpful. After all, a video that demonstrates
one thing well (search, buffer or window management, etc.) is better
than mentioning a few topics over the timespan of half an hour. I hope
I'm not the only one who tends to forget most of the points made in a
longer video, and often gives up half-way through if it gets too
boring.
> The wizard idea from another thread is nice, but I’m not a fan of a
> whole guided tour. Most probably people would want to skip it. A
> blocker just as your first boot a program is not nice.
I think I've suggested this before, but a manually invoked wizard could
be interesting. Typing "M-x intro" and getting a selection of
"interactive tutorials" -- again short and with a progress indicator --
would probably help a lot of people learn the basics quicker than
reading the manual or C-h t.
--
Philip K.
^ permalink raw reply [relevance 91%]
* Re: Changes for emacs 28
@ 2020-09-09 17:14 85% ` Philip K.
2 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-09 17:14 UTC (permalink / raw)
To: Ergus
Ergus <spacibba@aol.com> writes:
> Hi Emacs:
>
> As 27 has just been released I think it is time to start considering
> changes for the release 28. I will add some points I think we could
> discuss (specially implying defaults) in order to hear opinions and have
> enough time to discuss/implement them.
Most of the discussions seems to have revolved around user-facing
changes, but I think it might also be time to clean-up some of the
internal code. There are vast discrepancies in style between newer
modules such as xref or project and older systems such as hippie-expand
and Rmail.
My hope would be that with easier interfaces to work with, that leverage
Elisp improvements, that more people would be interested in using,
supporting and extending OOTB packages/modules. My fear is that
backwards compatibility would be at risk.
---
And regarding modernizing defaults, how about bundling a few "themes"
that enable/disable a few settings. It might be confusing at first, as
most people associate themes with visual customisations, but since Emacs
interprets the term more generally, adding themes such as "Modern" that
enables more bells and whistles (I'm not too enthusiastic about the
name, some might have chosen "Hipster" instead :^)), "Minimal" that
reduces UI, etc. might be a compromise between the fractions that want
to make Emacs appealing to newcomers and those that don't want to break
Emacs' way-of-operating by default.
--
Philip K.
^ permalink raw reply [relevance 85%]
* Re: Changes for emacs 28
@ 2020-09-10 15:08 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-10 15:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: spacibba, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: "Philip K." <philipk@posteo.net>
>> Gcc: nnfolder+archive:sent.2020-09
>> Date: Wed, 09 Sep 2020 19:14:29 +0200
>>
>> And regarding modernizing defaults, how about bundling a few "themes"
>> that enable/disable a few settings. It might be confusing at first, as
>> most people associate themes with visual customisations, but since Emacs
>> interprets the term more generally, adding themes such as "Modern" that
>> enables more bells and whistles (I'm not too enthusiastic about the
>> name, some might have chosen "Hipster" instead :^)), "Minimal" that
>> reduces UI, etc. might be a compromise between the fractions that want
>> to make Emacs appealing to newcomers and those that don't want to break
>> Emacs' way-of-operating by default.
>
> We already have a couple of such themes, so the issue of us accepting
> such themes doesn't exist.
Oh, I didn't know that? Is this being done in a separate feature branch?
> P.S. Please review your MUA settings, because they just caused Emacs
> to exclude the mailing list from the recipients, something that is
> unwanted.
My apologies, again, I use Gnus to follow the mailing list, but forget
that unlike Rmail, it doesn't reply to every when 'R' is pressed.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Changes for emacs 28
@ 2020-09-11 7:04 91% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-11 7:04 UTC (permalink / raw)
To: Richard Stallman; +Cc: Gregory Heytings, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > I'm not a maintainer, but FWIW my opinion is that what will most likely
> > happen is that they will never agree to do this. Menus are not "modern".
>
> What in the world? This strikes me as incomprehensible.
>
> Who thinks "Menus are not modern"? Why?
> What do they use instead of menus?
>
> (Perhaps they use a different kind of menu
> but do not think of it as a manu.)
I think that this is the case, most programmes seem to use the
"Hamburger Menu"[0] instead of a transitional top-menu. I'm not sure
what the reason for this change was, but I have a hunch one of the
motivating reasons was the attempt to merge applications and the window
frames (as GNOME does in the free software world, but Chrome, MS Office,
etc. do in the non-free world). When no space is left between the
application and it's frame, the menu must be moved somewhere
else. Another reason is probably the influence of mobile applications,
that use these kinds of menus due to lack of space.
[0] https://en.wikipedia.org/wiki/Hamburger_button
--
Philip K.
^ permalink raw reply [relevance 91%]
* Re: Changes for emacs 28
@ 2020-09-11 10:55 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-11 10:55 UTC (permalink / raw)
To: Ergus; +Cc: self, rms, emacs-devel
Ergus <spacibba@aol.com> writes:
> On Fri, Sep 11, 2020 at 12:16:13AM -0400, Richard Stallman wrote:
>>[[[ To any NSA and FBI agents reading my email: please consider ]]]
>>[[[ whether defending the US Constitution against all enemies, ]]]
>>[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>Does anyone want to _make_ videos for Emacs?
>>
>>It is no use discussing what sort of videos we
>>would like if nobody wants to make them.
>>Let's stick to ideas we can implement.
>
> Actually there are series of videos in youtube about emacs. Some of them
> very long with more than 40 episodes. So their producers could be
> contacted and they could help making things on demand. (not centered in
> external packages but in included features or elpa packages only)
>
> The real problem is: If we cannot refer to youtube then: Where these
> videos can be offloaded that we could link to?
I was thinking about using Peertube for something like that. It works
fairly well, the interface is clean enough, and it even has fediverse
integration.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Changes for emacs 28
@ 2020-09-11 12:12 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-11 12:12 UTC (permalink / raw)
To: Ergus; +Cc: self, rms, emacs-devel
Ergus <spacibba@aol.com> writes:
> Good: I didn't know about it.
In case anyone else is not familiar with the Project, here's the link:
https://joinpeertube.org/
> In this case we could start trying to contact the authors of the videos
> already existent in youtube asking to copy them to peertube so we can
> link them.
>
> In principle they can keep a copy in youtube but we won't refer to
> them.
>
> Is it possible to create channels in peertube? If so, then maybe we
> could create an "official" emacs channel and then some playlists there
> for the creators.
Yes, it's possible to create a channel
https://docs.joinpeertube.org/#/use-create-upload-video
and playlists can be created too:
https://docs.joinpeertube.org/#/use-library?id=playlist
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Changes for emacs 28
@ 2020-09-11 15:44 97% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-11 15:44 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Ergus <spacibba@aol.com> writes:
>
>> 1) Improve the default theme: Maybe set a default dark theme to make
>> emacs feel more modern.
>
> If you just set your background to some dark color, the stock Emacs
> default faces are actually very nice, see:
>
> https://functional.cafe/web/statuses/104411970368324669
>
> So just a default face light/dark toggle which doesn't use a theme but
> the standard faces seems like a good idea.
>
> Bye,
> Tassilo
That actually looks fairly similar to my own "dark mode":
(defun reverse-face (face &optional frame)
"Set FACE (in FRAME) to RGB inverse."
(interactive (list (read-face-name "Reverse face" (face-at-point t))))
(require 'color)
(ignore-errors
(let ((fg (face-attribute face :foreground frame))
(bg (face-attribute face :background frame)))
(set-face-attribute
face frame
:foreground (color-complement-hex fg)
:background (color-complement-hex bg)))))
(defun toggle-dark-mode ()
"Toggle dark mode."
(interactive)
(dolist (face '(mode-line default))
(reverse-face face)))
--
Philip K.
^ permalink raw reply [relevance 97%]
* Re: "modern" colors Re: Changes for emacs 28
@ 2020-09-11 23:29 67% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-11 23:29 UTC (permalink / raw)
To: Ergus; +Cc: emacs-devel
Ergus <spacibba@aol.com> writes:
>>In what way have the "fully redesigned the mode-line"? The link you
>>provided has no mode-lines.
>>
> https://github.com/jonathanchu/emacs-powerline
> https://github.com/TheBB/spaceline
> https://github.com/domtronn/spaceline-all-the-icons.el
> https://seagle0128.github.io/doom-modeline
> https://www.spacemacs.org/ (there are pictures)
If this is modern, I'd very much argue against modernizing.
First of all, most of these changes are either non-functional or just
changes for the sake of change. They also remind me of the prompts some
people use in their shell, that use those modified fonts to create the
illusion of pentagon-like shape. That's already existed for a few years,
and from my experience, after reaching a critical-mass and it looses it
novelty value, it will look even more outdated (or perhaps even
"cringe") than what we have no. Think of those 3D, hyper-detail desktops
that were cool 10-15 years ago. Or the skeuomorphism found on Apple
operating systems. What use to be cool, fresh and new, was that only
because it managed to make use of new technical capabilities, that
previously limited the design (higher density displays, enough spare
computational power to render excessive animations, etc.).
These tendencies usually go too far, and eventually this excess is
commonly understood. But until then, the movement is recognized as
modern, and following it's style doesn't make sense for everyone. For a
new programme, without an established user-base, appearances are a lot
more important, because "first look" count. But established applications
can suffer from it, as I often hear from MS Office users, who lament the
frequent changes in the UI. While a change of theme or mode-line isn't
that drastic, I think the analogy can be recognized.
Secondly, design reflects mentality. One can say a lot about a person,
by looking at their living room furniture. Most would consider VS Code
or Atom to have modern UIs and designs, but I don't think that it could
or should be disconnected from the UX. I'd argue: The UX or an "ideal"
work flow in Emacs doesn't match that of VSC or Atom, and by reflecting
that in the design, we don't stand to gain a modern UI, but "break" the
UX. Emacs is different, and to a certain degree this should be reflected
in the way it looks (which doesn't mean everything should stay the
same).
Maybe it would be better to aim for "Timeless", instead of "Modern".
(I recognize that the argument is a bit flimsy, but I'm writing this
around half past one in the morning, so mistakes are bound to happen.)
--
Philip K.
^ permalink raw reply [relevance 67%]
* Re: Interactive guide for new users
@ 2020-09-13 12:13 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-13 12:13 UTC (permalink / raw)
To: Ergus; +Cc: ghe, Eli Zaretskii, casouri, emacs-devel
Ergus <spacibba@aol.com> writes:
> IMO we should focus in at least 5-10 minutes users more than 3 minutes
> ones. Because to focus in the 3 minutes ones emacs will require at
> least a permanent visible bindings bar somewhere (like nano) or change
> many things to make them familiar for external users. And we won't do
> that I think :/
Why does that follow? And even so, if you have a video on "moving text",
"help system basics" or "managing buffers", you're going to handle 3-4
keybindings and their functions at most, and that's something that could
already be pasted into the scratch buffer (or some other buffer) to
begin with.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Context menus and mouse-3 [was: Changes for emacs 28]
@ 2020-09-17 21:58 84% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-17 21:58 UTC (permalink / raw)
To: Ergus; +Cc: rms, juri, self, arthur.miller, dgutov, ghe, emacs-devel,
drew.adams
Ergus <spacibba@aol.com> writes:
> But after all I understood that it is very hard to convince anyone
> (students, colleges, projects managers) to invest so much time and
> reading to learn how to do something simple they already know how to do
> everywhere else.
I sometimes feel this aspect is overstated. Yes, you might be a bit
confused at first, but learning the basics of *using* Emacs isn't a
intellectual endeavour. Arrow keys work, "Home", "End", "Delete"
too. "Copy-Pasting" is probably the first big hurdle, but that's just a
1:1 mapping at first. Buffer and window management are 3-4 keybindings
each. Working with files really only requires understating how to open
files and how to save them. With these few keybindings, you already know
the basics. I've seen people stick to vim just because it's cool knowing
less about the editor.
Sure, if someone's in a hurry to edit a file, they don't want to learn
how to use a proper Editor first, but I don't think that Emacs should be
geared towards that demographic either. If you want to open a file via
the GUI, change a few words and forget about it, Gedit/Kwrite/Mousepad
is probably a better choice (with better DE integration).
--
Philip K.
^ permalink raw reply [relevance 84%]
* Re: A proposal for a friendlier Emacs
@ 2020-09-19 15:50 97% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-19 15:50 UTC (permalink / raw)
To: Thibaut Verron; +Cc: Nicola Manca, Alfred M. Szmidt, Stefan Kangas, emacs-devel
Thibaut Verron <thibaut.verron@gmail.com> writes:
> Le ven. 18 sept. 2020 à 20:26, Alfred M. Szmidt <ams@gnu.org> a écrit :
>>
>> > On first start, the wizard would offer the option to create an empty
>> > .emacs and never bother you again.
>> >
>> > The issue is that it would bother you on first start, at all.
>>
>> On balance this a good thing, IMO. And if you disagree, it will only
>> bother you once.
>>
>> No, it will bother _each_ and _every_ time I start a new Emacs where I
>> have not done so previously. That is a fairly common situation, both
>> for new users, but also for experienced users who are the majority of
>> Emacs users.
>>
>> Lets not make Emacs annoying to use, OK?
>
> I, for one, would be happy to have a one-click option to set a bunch
> of reasonable defaults whenever I start Emacs on a new device.
I've seen new users keep the splash screen open all the time they are
using Emacs, not bothering to close it (mostly because they open it via
their graphical file manager or something along those
lines). Additionally having a wizard pop up would use even more screen
space, and is probably not what we want.
--
Philip K.
^ permalink raw reply [relevance 97%]
* Re: Interactive guide for new users
@ 2020-09-19 17:16 97% ` Philip K.
1 sibling, 0 replies; 200+ results
From: Philip K. @ 2020-09-19 17:16 UTC (permalink / raw)
To: Eduardo Mercovich
Cc: Göktuğ Kayaalp, Yuan Fu, Eli Zaretskii, Stefan Kangas,
emacs-devel
An issue I can imagine is that a lot of the options that would be
displayed in a wizard like this wouldn't mean too much to
newcomers. "Helm" or "Ivy"? "Projectile"? Even Emacs-native packages are
often confusing ("Hippie-Expand", "Xref", etc.). Without a way to test
and find out what these options _mean_, you would only be helping people
that could already help themselves.
--
Philip K.
^ permalink raw reply [relevance 97%]
* Re: Interactive guide for new users
@ 2020-09-20 9:26 91% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-20 9:26 UTC (permalink / raw)
To: Eduardo Mercovich; +Cc: self, casouri, eliz, stefankangas, emacs-devel
Eduardo Mercovich <eduardo@mercovich.net> writes:
> Hi Philip, thanks for your kind and fast feedback.
>
> Sorry I replied to everyone in the thread, just wanted a slower jump
> into this pond. It looks like I'm now completely in the water. :D
>
>> An issue I can imagine is that a lot of the options that would be
>> displayed in a wizard like this wouldn't mean too much to newcomers.
>> [...]
>
> That's why a sample step/screen is included. The options are
> (proposed to be) phrased in a way that could be understood without
> knowing emacs.
>
> I was actually doubting even to include in each a link to it's canonical
> URL (I assume that it would be the one already in the package manager).
>
> In the org-mode preferences "section" (let's call it that way because it
> may have many steps) for example, leading stars should be explained (of
> course, a screenshot would be the best):
>
> --8<---------------cut here---------------start------------->8---
>
> Org-mode defines heading hierarchy with asteriscs (stars) as the 1st character and arrange the left-alignment according to the heading level: 1 close to the left margin and other ones moving to the right.
> Some people prefer to have a simpler visual display and use only the
> alignment (and the font size and/or color) to show the heading hierarchy.
>
> Please select your option:
>
> (1) Hide the leading stars
>
> (2) Leave visible the leading stars
>
> (9) I'd like to leave this step for now (you can always make it later).
> (0) I want to stop this wizard now.
> --8<---------------cut here---------------end--------------->8---
>
> In this way, the User can always choose to stop, jump this option for
> now, or take one of them.
>
> Also, there should be a way to go back (not included in this rough
> draft).
Even with the ability to skip and go back, I still think that a total
newcomer won't be able to gain a lot from options like these. Maybe I'm
just bad, but in my case, I would skim over the text or wouldn't be too
interested in reading it in detail, to imagine what the differences
would be like. If anything, a visualisation would be needed. For example
in a separate window.
>> Without a way to test and find out what these options _mean_,
>> you would only be helping people that could already help themselves.
>
> Testing with users is one of my specialties, I would happily make a
> testing protocol before making the design, tests and development. In a
> way, it is like TDD, but with interaction design...
I'm not sure we're talking about the same testing here? I had more of a
"playground" like approach, where you can immediately or quickly see
what this option means, but I don't know if that's what you had in mind
too.
--
Philip K.
^ permalink raw reply [relevance 91%]
* Re: [ELPA] New package: splash-screen
@ 2020-09-21 11:09 98% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-21 11:09 UTC (permalink / raw)
To: Nicolas P. Rougier; +Cc: Alfred M. Szmidt, monnier, emacs-devel
"Nicolas P. Rougier" <nicolas.rougier@inria.fr> writes:
> Here is a new mockup:
>
> +——————————––––––––––––––––––––––––––––————————————————————+
> | |
> | |
> | |
> | |
> | |
> | |
> | www.gnu.org |
Why www.gnu.org and not https://www.gnu.org/software/emacs/?
> | GNU Emacs version XX.Y |
> | Free/libre text editor |
> | |
> | |
> | |
> | |
> | GNU Emacs comes with ABSOLUTELY NO WARRANTY |
> | Copyright (C) 2020 Free Software Foundation, Inc. |
> | |
> +––––––––––––––––––––––––––––––––––––––————————————————————+
>
> Any key but <escape>, <space>, <return>, "q", "x" will open
> the about-emacs page.
Shouldn't that be mentioned? Or at least how to close the splash screen?
Wouldn't it make more sense that most keys kill or bury the buffer?
Also, what happens when you invoke Emacs in the shell like
$ emacs myfile.c
how will the splash screen then behave?
--
Philip K.
^ permalink raw reply [relevance 98%]
* Re: [ELPA] New package: splash-screen
@ 2020-09-21 15:24 99% ` Philip K.
2020-09-21 16:40 95% ` Philip K.
1 sibling, 0 replies; 200+ results
From: Philip K. @ 2020-09-21 15:24 UTC (permalink / raw)
To: Nicolas P. Rougier; +Cc: ams, monnier, emacs-devel
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: splash-screen
2020-09-21 15:24 99% ` Philip K.
@ 2020-09-21 16:40 95% ` Philip K.
1 sibling, 0 replies; 200+ results
From: Philip K. @ 2020-09-21 16:40 UTC (permalink / raw)
To: Nicolas P. Rougier; +Cc: ams, monnier, emacs-devel
"Nicolas P. Rougier" <nicolas.rougier@inria.fr> writes:
> Philip K. <philipk@posteo.net> writes:
>
>
>> Why www.gnu.org and not https://www.gnu.org/software/emacs/?
>
> I think it's much easier to remember www.gnu.org rather than
> www.gnu.org/software/emacs/. Once on www.gnu.org, it is easy to
> find emacs.
> Also, from a purely aesthetic point of view, www.gnu.org fits
> better.
So how about "www.gnu.org/s/emacs" or "gnu.org/s/emacs"?
>>> Any key but <escape>, <space>, <return>, "q", "x" will open
>>> the about-emacs page.
>> Shouldn't that be mentioned? Or at least how to close the splash
>> screen?
>> Wouldn't it make more sense that most keys kill or bury the
>> buffer?
>
> The default behavior is to fall back to the about-emacs page since
> we can suspect a more experienced user would disable this
> splash-screen anyway. There's also an idle timer (5 seconds) that
> open the about-emacs buffer.
So what's the point then? As far as I understand, this is supposed to be
an ELPA package, but my understanding of splash screens is that they are
displayed while an application is loading, to ensure the user that
something is being done, or the computer didn't freeze. A spash-screen
for the sake of it seems counter-intuitive, or am I missing something?
--
Philip K.
^ permalink raw reply [relevance 95%]
* Re: Interactive guide for new users
@ 2020-09-22 9:06 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-22 9:06 UTC (permalink / raw)
To: Richard Stallman
Cc: casouri, emacs-devel, eduardo, stefankangas, self, eliz,
Drew Adams
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I think it is ok to call these things "Emacs distributions" -- just
> don't abbreviate that to "distributions".
>
> I think "modified Emacs releases" would be a better term to use.
They aren't real "releases" though, usually installing them just
requires downloading a preconfigured .emacs.d directory.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Interactive guide for new users
@ 2020-09-23 12:49 94% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-23 12:49 UTC (permalink / raw)
To: rms; +Cc: casouri, emacs-devel, eduardo, stefankangas, self, eliz,
drew.adams
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > > I think "modified Emacs releases" would be a better term to use.
>
> > They aren't real "releases" though, usually installing them just
> > requires downloading a preconfigured .emacs.d directory.
>
> In that case, the word "distribution" does not fit them either.
> How about "Emacs configurations"?
Everyone with a .emacs file has a configuration, but that's not what
Doom, Spacemacs, etc. provide. In a sense, they forked Emacs, without
forking the core code, instead providing a patch-set in Elisp form + a
DSL.
I agree, that distributions is the wrong term -- it's not the same as
with BSD or GNU/Linux, where a distribution bundles various software
into a self-sufficient form. That doesn't make sense here, as opposed to
the Linux kernel, Emacs can exist on it's own.
--
Philip K.
^ permalink raw reply [relevance 94%]
* [ELPA] New package: shell-command+
@ 2020-09-25 12:56 78% Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-25 12:56 UTC (permalink / raw)
To: emacs-devel
[ I tried to send this message yesterday already, but for some reason it
never appeared in the archive. I'm assuming the fault was on my side,
so I'm resending it again. ]
Hi,
I wanted to submit this package I wrote a while ago. It provides an
interactive command named "shell-command+", that is used in the same way
as one uses shell-command.
The difference is that shell-command+ pre-processes the user-input,
before passing it to shell-command or related functions. I think what it
does is best explained by the examples given in the commentary section:
> wc -l
Count all lines in a buffer, and display the result in the
minibuffer.
.. < ls -l
Replace the current region (or buffer in no region is selected)
with a directory listing of the parent directory.
| tr -d a-z
Delete all instances of the charachters a, b, c, ..., z, in the
selected region (or buffer, if no region was selected).
... make
Run Eshell's make (i.e. `compile') in the parent's parent
directory.
I have previously submitted the package under the name "bang" to
MELPA[0], but have since decided that the name isn't expressive and
could therefore confuse users. This version also includes a few
improvements that I have not yet added to bang.
It should also be noted, that the file is currently licensed under the
CC0 1.0 Universal (CC0 1.0) Public Domain Dedication[1] license, which
I'm not sure if it is OK.
[0] https://melpa.org/#/bang
[1] https://creativecommons.org/publicdomain/zero/1.0/
--
Philip K.
^ permalink raw reply [relevance 78%]
* Re: [ELPA] New package: shell-command+
@ 2020-09-25 13:52 51% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-25 13:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I wanted to submit this package I wrote a while ago. It provides an
>> interactive command named "shell-command+", that is used in the same way
>> as one uses shell-command.
>
> Sounds good. Do you have a pointer to the code?
Oh, I forgot to attach it:
[-- Attachment #2: shell-command+.el --]
[-- Type: text/plain, Size: 5285 bytes --]
;;; shell-command+.el --- An extended shell-command -*- lexical-binding: t -*-
;; Author: Philip K. <philipk@posteo.net>
;; Version: 1.0.3
;; Keywords: unix, processes, convenience
;; Package-Requires: ((emacs "24.1"))
;; URL: http://elpa.gnu.org/packages/shell-command+.html
;; This file is NOT part of Emacs.
;;
;; This file is in the public domain, to the extent possible under law,
;; published under the CC0 1.0 Universal license.
;;
;; For a full copy of the CC0 license see
;; https://creativecommons.org/publicdomain/zero/1.0/legalcode
;;; Commentary:
;;
;; `shell-command+' is a `shell-command' substitute, that extends the
;; regular Emacs command with several features.
;;
;; A few examples of what `shell-command+' can do:
;;
;;
;; > wc -l
;;
;; Count all lines in a buffer, and display the result in the
;; minibuffer.
;;
;;
;; .. < ls -l
;;
;; Replace the current region (or buffer in no region is selected)
;; with a directory listing of the parent directory.
;;
;;
;; | tr -d a-z
;;
;; Delete all instances of the charachters a, b, c, ..., z, in the
;; selected region (or buffer, if no region was selected).
;;
;;
;; ... make
;;
;; Run Eshell's make (i.e. `compile') in the parent's parent
;; directory.
(eval-when-compile (require 'rx))
(require 'eshell)
;;; Code:
(defgroup shell-command+ nil
"An extended `shell-command'"
:group 'external
:prefix "shell-command+-")
(defcustom shell-command+-use-eshell t
"Check if there is an eshell-handler for each command."
:type 'boolean)
(defconst shell-command+--command-regexp
(rx bos
;; ignore all preceding whitespace
(* space)
;; check for working directory string
(? (group (or (: ?. (not (any "/"))) ?/ ?~)
(* (not space)))
(+ space))
;; check for redirection indicator
(? (or (group ?<) (group ?>) (group ?|) ?!))
;; allow whitespace after indicator
(* space)
;; actual command (and command name)
(group (: (group (*? not-newline))
(? space))
(+ not-newline))
eos)
"Regular expression to parse `shell-command+' input.")
(defun shell-command+-expand-path (path)
"Expand any PATH into absolute path with additional tricks.
Furthermore, replace each sequence with three or more `.'s with a
proper upwards directory pointers. This means that '....' becomes
'../../../..', and so on."
(expand-file-name
(replace-regexp-in-string
(rx (>= 2 "."))
(lambda (sub)
(mapconcat #'identity (make-list (1- (length sub)) "..") "/"))
path)))
;;;###autoload
(defun shell-command+ (command beg end)
"Intelligently execute string COMMAND in inferior shell.
If COMMAND is prefixed with an absolute or relative path, the
created process will the executed in the specified path.
When COMMAND starts with...
< the output of COMMAND replaces the current selection
> COMMAND is run with the current selection as input
| the current selection is filtered through COMMAND
! COMMAND is simply executed (same as without any prefix)
If `shell-command+-use-eshell' is non-nil, and the the first
argument of COMMAND has a defined `eshell'-function, use that.
Inside COMMAND, % is replaced with the current file name. To
insert a literal % quote it using a backslash.
These extentions can all be combined with one-another.
In case a region is active, `shell-command+' will only work with the region
between BEG and END. Otherwise the whole buffer is processed."
(interactive (list (read-shell-command "Shell command: ")
(if (use-region-p) (region-beginning) (point-min))
(if (use-region-p) (region-end) (point-max))))
(save-match-data
(unless (string-match shell-command+--command-regexp command)
(error "Invalid command"))
(let ((path (match-string-no-properties 1 command))
(cmd (match-string-no-properties 6 command))
(rest (condition-case nil
(replace-regexp-in-string
(rx (* ?\\ ?\\) (or ?\\ (group "%")))
buffer-file-name
(match-string-no-properties 5 command)
nil nil 1)
(error (match-string-no-properties 5 command)))))
(let ((default-directory (shell-command+-expand-path (or path "."))))
(cond ((match-string-no-properties 2 command) ;<
(delete-region beg end)
(shell-command rest t shell-command-default-error-buffer)
(exchange-point-and-mark))
((match-string-no-properties 3 command) ;>
(shell-command-on-region
beg end rest nil nil
shell-command-default-error-buffer t))
((match-string-no-properties 4 command) ;|
(shell-command-on-region
beg end rest t t
shell-command-default-error-buffer t))
((and shell-command+-use-eshell
(intern-soft (concat "eshell/" cmd)))
(eshell-command rest (and current-prefix-arg t)))
(t (shell-command rest (and current-prefix-arg t)
shell-command-default-error-buffer)))))))
(provide 'shell-command+)
;;; shell-command+.el ends here
[-- Attachment #3: Type: text/plain, Size: 611 bytes --]
> I don't see your name in the list of people with copyright assignments.
> Then again, I do see some "Philip K..." but I can't be sure it's
> indeed you. Did you sign the paperwork already?
Yes, I signed it last year when my address was philip@warpmail.net.
>> It should also be noted, that the file is currently licensed under the
>> CC0 1.0 Universal (CC0 1.0) Public Domain Dedication[1] license, which
>> I'm not sure if it is OK.
>
> That's not a problem for us, but we'd change it to GPLv3+ when we add it
> to GNU ELPA. Not sure if that would be OK with you.
No problem with that.
--
Philip K.
^ permalink raw reply [relevance 51%]
* Re: [ELPA] New package: shell-command+
@ 2020-09-26 9:38 94% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-26 9:38 UTC (permalink / raw)
To: Ergus; +Cc: emacs-devel
Ergus <spacibba@aol.com> writes:
> May I suggest (in spite of it is very simple) you to add the
> configuration lines in the Readme and package description for new users?
>
> If you want to add also the use-package config I have this in my init
> file too:
>
> (use-package bang
> :ensure t
> :bind ("M-!" . bang))
The README for bang still has a line like this, but I removed it for
shell-command+, as use-package isn't in ELPA. My hope was that the line
`shell-command+' is a `shell-command' substitute
would be enough, but maybe
(global-set-key (kbd "M-!") #'shell-command+)
would help? shell-command+ is auto-loaded, so it should be the same, and
anyone using use-package or similar packages should be able to translate
this into their language.
The only issue is that I can't commit anything to the ELPA repo, who
would I have to contact to request that access?
--
Philip K.
^ permalink raw reply [relevance 94%]
* Re: How to make Emacs popular again.
@ 2020-09-26 13:59 95% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-09-26 13:59 UTC (permalink / raw)
To: James Lu; +Cc: emacs-devel
James Lu <jamtlu@gmail.com> writes:
> a la Don't Make Me Think by Steve Krug.
I'm not familiar with the book, but from from [0]
> The book's premise is that a good software program or web site should
> let users accomplish their intended tasks as easily and directly as
> possible.
I guess I agree, but it seems to be a truism. Nobody wants to make
software intentionally unusable, it's hard to imagine that people would
still be using Emacs after all this time if that were the case.
The question I see is should it be "Don't make me think" or "Don't make
me learn". I get the first one, but you limit yourself to what you
already know, if you want everything to already be familiar.
[0] https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think
--
Philip K.
^ permalink raw reply [relevance 95%]
* Re: How to make Emacs popular again.
@ 2020-10-01 8:11 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-01 8:11 UTC (permalink / raw)
To: rms; +Cc: spacibba, eduardoochs, bugs, emacs-devel, dgutov, jamtlu
Richard Stallman <rms@gnu.org> writes:
> > On many other GNU/Linux systems, dictionaries can be
> > easier downloaded and installed on local system.
>
> When you do that, can 'dict' refer directly to the local copies?
yes, you just have to start the dictd deamon locally and point the
client to localhost.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]
@ 2020-10-02 19:21 91% ` Philip K.
1 sibling, 0 replies; 200+ results
From: Philip K. @ 2020-10-02 19:21 UTC (permalink / raw)
To: Drew Adams; +Cc: emacs-devel, Thibaut Verron, T.V Raman
Drew Adams <drew.adams@oracle.com> writes:
> 3. There's been a tendency recently to give Emacs
> even more default key bindings. Two cases come
> to mind, both in 2020:
>
> a. `C-x p' was taken by Emacs as a prefix key for
> `project.el' commands.
> b. `C-x t' was taken by Emacs as a prefix key for
> `tabbar.el' commands.
>
> Maybe those deserve prefix keys (?). But you see
> the tendency - less and less for users; more taken
> by default bindings.
>
> That's 2 excellent prefix keys just removed, in
> effect, from the user/3rd-party space. Poof!
I get that they were in effect removed from the 3rd-party space, but the
user is still the final arbiter in what is bound or not. Do you really
loose anything, if you rebind C-x p, if you don't use project.el? Same
goes for C-x t if you don't use tabs.
My point is that there seem to be varying degrees of importance to
key-bindings: Rebinding C-c, let alone a self-insert key is far more
disruptive than M-/, C-o, C-x, C-x a, etc. -- it's just difficult to
draw the line.
--
Philip K.
^ permalink raw reply [relevance 91%]
* Re: Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?]
@ 2020-10-02 22:31 94% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-02 22:31 UTC (permalink / raw)
To: Ergus; +Cc: emacs-devel, Thibaut Verron, Drew Adams, T.V Raman
Ergus <spacibba@aol.com> writes:
> On Fri, Oct 02, 2020 at 11:14:48AM -0700, Drew Adams wrote:
>>> Perhaps it's time we opened up some additional keymaps...
>
> AFAIR:
>
> C-x is reserved for emacs internal use.
> C-c for users.
According to "(elisp) Key Binding Conventions":
> Sequences consisting of ‘C-c’ followed by a control character or a
> digit are reserved for major modes.
(not the exceptions listed in the info node)
while C-x is a lot safer for users. It would be very unusual for a major
mode to rebind "C-x ...", which is why I bind most of my local functions
to that map. On the other hand, something like C-c C-... will often be
shadowed by a major mode minor mode, hence I don't bother trying.
--
Philip K.
^ permalink raw reply [relevance 94%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-08 17:27 81% ` Philip K.
2020-10-19 16:20 99% ` Philip K.
2 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-08 17:27 UTC (permalink / raw)
To: Adrien Brochard; +Cc: emacs-devel
Adrien Brochard <abrochard@gmx.com> writes:
> Hi everyone,
>
> I posted on reddit.com/r/emacs yesterday a proposal to craft and
> distribute a survey for Emacs users to better grasp the diversity and
> various usages out there. I got some very good feedback but there could
> always be more.
>
> The main points that need to be worked out are:
> 1. the actual questions to be asked
> 2. the platform to collect responses
I think a major problem is how to get as many emacs users -- and not
only reddit -- to participate. There are plenty of Emacs users who
neither follow the mailing lists, nor use sites like Reddit. Many of
them have had similar setups for years, and don't need to think about
it. Of course I can inform those I am antiquated with, but that approach
has it's limits.
There is a disconnect between these two groups. Of course, neither is
"right". I've seen "traditional users" who didn't know that M-x could be
invoked using the alt key (instead pressing escape and then "x"), and
newer users who use try to get as much of emacs out of the way, to use
things like org or magit. My fear is that those in the latter group are
more likely to hear about a poll like this, and be overrepresented at
the expense of the former. And without a way to prove anything, either
way, no real progress could be achieved -- one group will keep on saying
that "it's time to become vs code" and the others will invoke a virtual
"silent minority".
> Regarding the questions, I have a decent skeleton and a lot of suggestions.
>
> But the for the platform to collect responses, this is where it gets
> difficult. Something like a Google survey might the easiest/cheapest to
> make and distribute and will work on most devices, but it obviously has
> privacy concerns. On the other hand, doing something like self-hosting a
> no-JS form is very time consuming. I was also thinking of allowing
> responses via email for people who do not want to bother with a survey
> link and then manually reconcile responses.
Why not just create a simple HTML form with a captcha (not Google's
thing, but a simple library that generates an image)?
> Links to the posts with the tentative questions:
> -
> https://www.reddit.com/r/emacs/comments/j6x7ad/proposal_for_an_emacs_user_survey/
> -
> https://www.reddit.com/r/emacs/comments/b2fh4y/help_reviewprovide_feedback_on_state_of_emacs/
>
> Thank you for reading!
> Best,
> Adrien
>
>
--
Philip K.
^ permalink raw reply [relevance 81%]
* Re: Integration of dictionary package
@ 2020-10-08 17:33 94% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-08 17:33 UTC (permalink / raw)
To: Torsten Hilbrich; +Cc: emacs-devel
Torsten Hilbrich <emacs.nolkaf@hilbrich.tk> writes:
> Hello,
>
> by suggestion of Jean Louis I have started integrating the dictionary
> package (found on https://github.com/myrkr/dictionary-el/).
>
> The work can be found on the feature/integration-of-dictionary-el branch.
>
> It contains the following commits:
>
> b6227446d9 Importing dictionary module
> 658ec3ccee Renamed connection.el
> e2ebffdd62 Renamed link.el
I was reading and rewriting parts of dictionary.el, and was wondering if
connection.el and link.el should be kept if the package were to be
merged into the core. Connection.el seems to just be a wrapper around
the regular networking operations, and link.el should be replaceable by
the button mechanism, shouldn't it?
> 723906c444 Removed some compability parts in dictionary
>
> I plan to integrate some future changes:
>
> - support for dictionary-search to have the highlighted region as
> default
How will this be handled? If I select more than one word, will every
word be queried?
> - support for initially looking up on localhost and the switching to
> dict.org
Will this be enabled by default? And in case there is no local server,
will this slow operations down, or do you plan on caching the connected
server?
> Thanks for reviewing,
>
> Torsten
--
Philip K.
^ permalink raw reply [relevance 94%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-09 11:30 98% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-09 11:30 UTC (permalink / raw)
To: Adrien Brochard; +Cc: emacs-devel
Adrien Brochard <abrochard@gmx.com> writes:
>> Why not just create a simple HTML form with a captcha (not Google's
>> thing, but a simple library that generates an image)?
>
> I know it sounds easy, but it can rapidly become a considerable amount
> of work. The captcha is not trivial and then there's the question of the
> backend and where the data goes. To limit barrier of entry, the survey
> must be as easy to fill out as possible. That means that we can't have
> downtime, lag, and work on mobile too. I am more inclined to trust that
> work to professionals and have to pay a little for it.
For the fun of it, I wrote a simple survey application[0] that includes
a self-hosted captcha (without tracking anyone), requires no Javascript,
is mobile friendly and should be fairly fast. Of course it can be
improved. I wrote it as a quick and dirty evening project, but I
think it demonstrates that this kind of an approach is practicable.
[0] https://git.sr.ht/~zge/survey
--
Philip K.
^ permalink raw reply [relevance 98%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-09 18:17 87% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-09 18:17 UTC (permalink / raw)
To: Adrien Brochard; +Cc: emacs-devel
Adrien Brochard <abrochard@gmx.com> writes:
>> For the fun of it, I wrote a simple survey application[0] that includes
>> a self-hosted captcha (without tracking anyone), requires no Javascript,
>> is mobile friendly and should be fairly fast. Of course it can be
>> improved. I wrote it as a quick and dirty evening project, but I
>> think it demonstrates that this kind of an approach is practicable.
>>
>> [0] https://git.sr.ht/~zge/survey
>
> Thank you! I really like reading go code (no sarcasm).
> It it clear that this approach will work but the remaining 20% are the
> hardest. I'm concerned with:
> - cleaner UI, not just HTML embedded in the code
What would you have in mind? I know that my example is simple, but I
prefer that to sites that take forever to load and reload everything all
the time, for no apparent reason.
> - mysql instead of sqlite, which also implies a mysql instance running
SQLite is actually surprisingly resilient, according to [0]:
> SQLite works great as the database engine for most low to medium traffic
> websites (which is to say, most websites). The amount of web traffic
> that SQLite can handle depends on how heavily the website uses its
> database. Generally speaking, any site that gets fewer than 100K
> hits/day should work fine with SQLite. The 100K hits/day figure is a
> conservative estimate, not a hard upper bound. SQLite has been
> demonstrated to work with 10 times that amount of traffic.
But either way, I used sqlite to avoid setting up a RDBMS.
[0] https://www.sqlite.org/whentouse.html
> - DOS protection, maybe some rate-limiting and IP blocking
> - HTTPS, thankfully it's easier now
AFAIK these things can usually be handled by a frond-end such as NGINX.
> - monitoring, how do we know the service is running as expected
> - logging, and how to store logs for debug
If there is any interest, extending the example to support this would be
feasible. The "20%" you mention aren't easy, but from what I see it
shouldn't be too hard either.
> My greatest fear is people clicking on the link, filling out the form,
> trying to submit, seeing an error page, and never coming back to it.
The reason I suggested using a simple HTML form and implemented the demo
was because I think simplicity helps avoid a lot of issues. With fewer
dependencies, secondary services, modules, etc. the chance of one of
these failing decreases. And having a smaller footprint should also
reduce the network load.
> Best,
> Adrien
--
Philip K.
^ permalink raw reply [relevance 87%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-10 9:36 94% ` Philip K.
0 siblings, 1 reply; 200+ results
From: Philip K. @ 2020-10-10 9:36 UTC (permalink / raw)
To: rms; +Cc: abrochard, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > The most obvious reason to me is that user error handling is pretty
> > poor. Because there is no JS, we cannot offer front-end validation, that
> > means that the backend server is responsible for validating fields
> > submitted.
>
> If we want to learn what users think, we should not limit their
> responses to a small set of 'valid" possible answers. The plan
> I designed for inquiries asks users to answer in their own words.
But wouldn't that make it needlessly hard to analyse the results,
especially if the question should be numerically quantified? I get the
value of plain text responses, but recognizing that the answer to the
question "how long have you been using emacs", could result in:
- "Since 1996"
- "24 Years"
- "January 1996"
- "Around the second time Clinton got sworn into office"
- "1896" (but actually a typo)
All of these basically mean the same, but the effort to recognize this
automatically (which would be necessary, if you want to see how factors
correlate) would not be worth it.
--
Philip K.
^ permalink raw reply [relevance 94%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-10 10:35 89% ` Philip K.
0 siblings, 2 replies; 200+ results
From: Philip K. @ 2020-10-10 10:35 UTC (permalink / raw)
To: Adrien Brochard; +Cc: emacs-devel
Adrien Brochard <abrochard@gmx.com> writes:
>>> - cleaner UI, not just HTML embedded in the code
>>
>> What would you have in mind? I know that my example is simple, but I
>> prefer that to sites that take forever to load and reload everything all
>> the time, for no apparent reason.
>
> The most obvious reason to me is that user error handling is pretty
> poor. Because there is no JS, we cannot offer front-end validation, that
> means that the backend server is responsible for validating fields
> submitted. If validation does not pass, the page must "reload" for the
> user and it needs to show exactly what went wrong and preserve the user
> input. That's my definition of a site that reloads all the time.
That could be mitigated with a "graceful degradation" approach, since
most people do have javascript activated by default. HTML5 also has a
few attributes that could help, such as pattern or required, depending
on what questions are being asked.
>>> - mysql instead of sqlite, which also implies a mysql instance running
>>
>> SQLite is actually surprisingly resilient, according to [0]:
>>
>>> SQLite works great as the database engine for most low to medium traffic
>>> websites (which is to say, most websites). The amount of web traffic
>>> that SQLite can handle depends on how heavily the website uses its
>>> database. Generally speaking, any site that gets fewer than 100K
>>> hits/day should work fine with SQLite. The 100K hits/day figure is a
>>> conservative estimate, not a hard upper bound. SQLite has been
>>> demonstrated to work with 10 times that amount of traffic.
>>
>> But either way, I used sqlite to avoid setting up a RDBMS.
>>
>> [0] https://www.sqlite.org/whentouse.html
>
> SQLite is resilient but it's dangerous to use it with multiple threads
> like how your go server does. You could use a single channel model to
> write records one at a time but now you have a risk to lose data from
> memory if your service restarts.
I'm familiar with the danger, but it shouldn't be a problem. As pointed
out in [0], one can activate the SQLite mutex per flag. But at the same
time, even sites as popular as Hacker News are alleged to use SQLite as
their backend.
[0] https://github.com/mattn/go-sqlite3/issues/249
>>
>>> - DOS protection, maybe some rate-limiting and IP blocking
>>> - HTTPS, thankfully it's easier now
>>
>> AFAIK these things can usually be handled by a frond-end such as NGINX.
>
> That's true it can, but that means you need to deploy and configure one.
> https://www.nginx.com/blog/rate-limiting-nginx/
> https://nginx.org/en/docs/http/configuring_https_servers.html
Perhaps using Guix could make that easier:
https://guix.gnu.org/manual/devel/en/html_node/Web-Services.html#NGINX?
>>> - monitoring, how do we know the service is running as expected
>>> - logging, and how to store logs for debug
>>
>> If there is any interest, extending the example to support this would be
>> feasible. The "20%" you mention aren't easy, but from what I see it
>> shouldn't be too hard either.
>
> You're absolutely right. None of it is "too hard". But the problem is
> just how much time and effort are we willing to put into it. If the goal
> is to make an open source polling platform that we can re-use in the
> future, then absolutely all of this can be done. But if we treat this as
> a one-off and see how it turns out, the scope seems exaggerated.
Depending on how many people participate, it would be interesting the
repeat the survey year-by-year, so that trends and changes in the
user-base can be recognized.
--
Philip K.
^ permalink raw reply [relevance 89%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-10 13:50 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-10 13:50 UTC (permalink / raw)
To: Thibaut Verron; +Cc: Adrien Brochard, Richard Stallman, emacs-devel
Thibaut Verron <thibaut.verron@gmail.com> writes:
>> ** Do you use mail client in Emacs?
>> - Mu4e
>> - Gnus
>> - Mut
>> - notmuch
>> - do not use
>
> Here too, "other" should be an option.
The list is incomplete, but are there really that many mail clients that
they couldn't be listed. Emacswiki[0] lists:
- Rmail
- Gnus
- MH-E
- Wanderlust
- Mew
- VM
- Notmuch
- mu4e
- mutt
and a few more unmaintained ones. I guess if other could stand for those?
[0] https://www.emacswiki.org/emacs/CategoryMail
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-11 17:47 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-11 17:47 UTC (permalink / raw)
To: Tomas Hlavaty; +Cc: emacs-devel
Tomas Hlavaty <tom@logand.com> writes:
> On Sat 10 Oct 2020 at 12:35, "Philip K." <philipk@posteo.net> wrote:
>> That could be mitigated with a "graceful degradation" approach, since
>> most people do have javascript activated by default.
>
> it should be possible to fill in the survey from emacs
Of course, that's what "graceful degradation" implies. If Javascript is
available, it will be used to improve the user experience. If not,
everything still continues working, just eg. without the interactivity
that Javascript might provide.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-11 17:59 82% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-11 17:59 UTC (permalink / raw)
To: Richard Stallman; +Cc: abrochard, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> > >>> - mysql instead of sqlite, which also implies a mysql instance running
> > >>
> > >> SQLite is actually surprisingly resilient, according to [0]:
>
> It would be a mistake to put the input into any sort of database
> program. That would only make things difficult and increase the
> special knowledge people would need in order to work on this.
>
> Here's the simple and clean way to do it.
>
> Each time a user responds, convert all the answers into a formulaic
> piece text which states the questions and answers. Email that to a
> certain address, which will accumulate these messages in one inbox
> file.
>
> Then it will be simple to do all sorts of counting or analysis on that
> file.
The issue I see here is that if you expert plain-text responses, someone
might just submit something that breaks the format, or even submit an
email written in HTML. So the data couldn't just be stored in plain
text, but would have to at least have some decoding to correctly parse
the message, and some encoding the safely store the message. You
wouldn't want someone who could submit 1000 fake or troll responses,
just because they know what what's going on behind the scenes.
> Database programs are useful when there are hundreds of thousands of
> records and you need to search for any one of them. Or when the data
> are being altered. We will not have so many answers, and each one
> will never change once sent.
Databases are useful whenever you've got data to work with. SQLite is
useful at whatever sale one is working at, from browsers to cars. And
besides, it's safer to use than directly writing to the file system (see
https://danluu.com/file-consistency/ for more details). And generally
speaking, file systems are also just databases, just that they are
directory-oriented, not record-oriented and usually have better support
in regards to OS primitives.
All in all, I don't this that this should be an issue, SQLite is well
documented, and can easily be extracted into whatever format someone
might need or want, just easier than with a mailbox or other classical
unix-like approaches.
--
Philip K.
^ permalink raw reply [relevance 82%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-11 18:33 94% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-11 18:33 UTC (permalink / raw)
To: Jean Louis; +Cc: Adrien Brochard, rms, emacs-devel
Jean Louis <bugs@gnu.support> writes:
> * Teemu Likonen <tlikonen@iki.fi> [2020-10-10 11:35]:
>> * 2020-10-09 19:12:23-04, Adrien Brochard wrote:
>>
>> > Please find the list of questions I have gathered at the end of this
>> > email.
>>
>> Great! I would like to see this survey conducted. It would be
>> interesting to see what people use Emacs for and some distribution of
>> answers. It's not easy to find good sample of users but if the survey is
>> published in some main communication platforms or communities it will be
>> good enough, I think.
>
> If survey is published, for example on Reddit, such survey is narrow
> and specific to Reddit users, and would represent only that
> communication channel.
>
> My proposal on how to publish a survey is to include that in the Help
> menu, and let people do it straight from Emacs. That is similar to bug
> reporting, but it is not a bug, it is feature request.
But if you have to have mail configured, you're also only going to have
a specific subset of all users.
I think the idea of having a survey that could be filled out from Emacs
is interesting (although we would only get to hear from current users,
not previous users). But it would have to work regardless of what the
user has configured or not. From what I see, that would either mean a
web form that can be filled out using EWW or a package that could be
downloaded from ELPA.
--
Philip K.
^ permalink raw reply [relevance 94%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-11 18:42 89% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-11 18:42 UTC (permalink / raw)
To: Jean Louis; +Cc: abrochard, rms, emacs-devel
Jean Louis <bugs@gnu.support> writes:
> * Philip K. <philipk@posteo.net> [2020-10-10 12:37]:
>> Richard Stallman <rms@gnu.org> writes:
>>
>> > [[[ To any NSA and FBI agents reading my email: please consider ]]]
>> > [[[ whether defending the US Constitution against all enemies, ]]]
>> > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>> >
>> > > The most obvious reason to me is that user error handling is pretty
>> > > poor. Because there is no JS, we cannot offer front-end validation, that
>> > > means that the backend server is responsible for validating fields
>> > > submitted.
>> >
>> > If we want to learn what users think, we should not limit their
>> > responses to a small set of 'valid" possible answers. The plan
>> > I designed for inquiries asks users to answer in their own words.
>>
>> But wouldn't that make it needlessly hard to analyse the results,
>> especially if the question should be numerically quantified?
>
> As I have done larger surveys for public relations and I know methods,
> I know how tedious it is to evaluate such survey, we have been
> employing many people, like 20 people, to just analyze what exactly
> did people check or did not check, what did they write, to read their
> handwriting, and then to properly analyze it.
>
> However, Emacs feature requests or survey about using Emacs need live
> user, not user as a number.
Of course, but there are still numbers that describe aggregate
phenomenons that individual users don't actively notice. A question I
would be interested in is what the correlation is between people who use
specific configuration-templates (Doom, Spacemacs, etc.) and how long
they have been using Emacs/Age. Depending on what the results are, we
would have a batter guess as to whether the popularity of these
templates is just because newer users aren't secure in configuring their
own Emacs, or if people just like these templates in general (what they
like is individual, that's where plain text responses are interesting).
Other than that, I don't see why both approaches should be possible.
Mixed, or separated, you can ask multiple/single choice questions for
"hard data", and plain text for individual opinions.
--
Philip K.
^ permalink raw reply [relevance 89%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-16 13:23 81% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-16 13:23 UTC (permalink / raw)
To: Thibaut Verron; +Cc: Richard Stallman, Jean Louis, emacs-devel
Thibaut Verron <thibaut.verron@gmail.com> writes:
> Le ven. 16 oct. 2020 à 05:59, Richard Stallman <rms@gnu.org> a écrit :
>> I hope that only a minority of Emacs users know about MELPA, and I'd
>> rather not inform the rest about it. But if something is going to
>> inform them anyway, it is better to do it with a denunciation.
>
> I believe that it is too late for such hopes, and that a majority of
> Emacs users know about Melpa and/or uses it. Some people know about it
> without using it (most of them probably read this list) and some
> people use it without knowing it (users of pre-configured emacs'es).
>
> For instance, those three links were on the first page of a duckduckgo
> search for "install emacs packages":
>
> https://www.emacswiki.org/emacs/InstallingPackages
> http://ergoemacs.org/emacs/emacs_package_system.html
> http://pragmaticemacs.com/emacs/install-packages/
And that's only if the user already knows that they want to install
packages (instead of "plug-ins" or "extensions", as other software would
refer to the concept). From my experience, almost every non-official
beginners tutorial will either mention or just give you the code to
configure MELPA. And with all the starter-packages that offer to
pre-configure Emacs, you don't even think about it.
But that's currently unavoidable, a lot of the advocacy for Emacs is
based on promoting certain packages (Magit, Evil, Org-mode extensions
such as Roam, etc.) that are for the most part only available on MELPA.
Non-GNU Elpa should help to mitigate this problem, as my impression is
that most people intrigued in Emacs, would quickly loose interest, if it
weren't for these specific packages.
(In general I think that that kind promotion isn't good, at least in the
long term. Emacs is seen as getting in the way of whatever package you
need, and they therefore follow whatever method they find to avoid
learning. While possible, it leaves many on a fragile tower of
abstractions and hacks, that could break at any moment.)
--
Philip K.
^ permalink raw reply [relevance 81%]
* Re: Proposal for an Emacs User Survey
` (2 preceding siblings ...)
@ 2020-10-16 13:30 98% ` Philip K.
3 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-16 13:30 UTC (permalink / raw)
To: Adrien Brochard; +Cc: emacs-devel
Adrien Brochard <abrochard@gmx.com> writes:
> ** How do you use Emacs?
> - GUI
> - Terminal (TUI)
> - Both
I'd suggest also asking how they use the GUI. Do they keep everything as
it is, or hide the scroll-, tool- and menu bar (or just parts).
Perhaps, if it turns out that most people disable some feature, it could
be turned off by default in the next release? If you ask me, just
removing the tool-bar would improve the default look more than anything
else.
--
Philip K.
^ permalink raw reply [relevance 98%]
* Re: Proposal for an Emacs User Survey
@ 2020-10-18 15:57 93% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-18 15:57 UTC (permalink / raw)
To: Richard Stallman; +Cc: Marcel Ventosa, thibaut.verron, bugs, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > In fact, I would go the extra mile and say Emacs should expressly warn
> > users over the dangers of installing proprietary software from
> > unofficial repositories
>
> That could be a good idea. What would be good occasions on which to warn?
>
> Perhaps in list-packages when it sees a non-GNU repo, or when it sees MELPA?
>
> Perhaps in describe-package and packageinstall, when the package comes
> from a non-GNU repo, or specifically from MELPA?
>
> Any other ideas?
This is a weaker suggestion: Maybe packages could have a tag to signal
that they are related to proprietary software, that could be then
displayed both via list-packages and describe-package? I'm fairly sure
that MELPA would encourage or even require people to add this tag.
Most software on MELPA is "ok", and people (like me) choose to use it
because is offers more packages than ELPA.
> (by the way, I always just assumed MELPA was
> > somehow official and related to ELPA, because its name is so similar to
> > ELPA).
>
> Yes, this is a source of confusion.
>
> Perhaps we should renamme GNU ELPA to a name that will avoid this confusion.
> Maybe GNU EP (GNU Emacs Packages)?
>
> EP is not meaningful to those who don't know what it means. But
> neither is ELPA. People understand it only if they have been told.
> So EP is no worse than ELPA.
>
> WDYT?
There shouldn't be any reason for ELPA to rename itself, it should be
clear that MELPA is not official, as it is not pre-configured.
--
Philip K.
^ permalink raw reply [relevance 93%]
* Re: Proposal for an Emacs User Survey
2020-10-08 17:27 81% ` Philip K.
@ 2020-10-19 16:20 99% ` Philip K.
2 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-19 16:20 UTC (permalink / raw)
To: emacs-devel
I can't seem to find anyone here mentioning it, but it seems the survey
has been opened today:
https://emacssurvey.org/
Sadly, it seems like they decided to use non-free JS for the web-form
variant :(
Adrien Brochard <abrochard@gmx.com> writes:
> Hi everyone,
>
> I posted on reddit.com/r/emacs yesterday a proposal to craft and
> distribute a survey for Emacs users to better grasp the diversity and
> various usages out there. I got some very good feedback but there could
> always be more.
>
> The main points that need to be worked out are:
> 1. the actual questions to be asked
> 2. the platform to collect responses
>
> Regarding the questions, I have a decent skeleton and a lot of suggestions.
>
> But the for the platform to collect responses, this is where it gets
> difficult. Something like a Google survey might the easiest/cheapest to
> make and distribute and will work on most devices, but it obviously has
> privacy concerns. On the other hand, doing something like self-hosting a
> no-JS form is very time consuming. I was also thinking of allowing
> responses via email for people who do not want to bother with a survey
> link and then manually reconcile responses.
>
> Links to the posts with the tentative questions:
> -
> https://www.reddit.com/r/emacs/comments/j6x7ad/proposal_for_an_emacs_user_survey/
> -
> https://www.reddit.com/r/emacs/comments/b2fh4y/help_reviewprovide_feedback_on_state_of_emacs/
>
> Thank you for reading!
> Best,
> Adrien
>
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA and release frequency
@ 2020-10-26 9:56 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-10-26 9:56 UTC (permalink / raw)
To: Antoine Kalmbach; +Cc: emacs-devel, rms, stefankangas
Antoine Kalmbach <ane@iki.fi> writes:
> Richard Stallman <rms@gnu.org> writes:
>
>> Would you like to help implement NonGNU ELPA?
>
> Sure.
I'd love to help to, just don't know what help is required.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Emacs Survey: Toolbars
@ 2020-12-15 17:07 97% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-12-15 17:07 UTC (permalink / raw)
To: Jean Louis; +Cc: Lars Ingebrigtsen, emacs-devel
Jean Louis <bugs@gnu.support> writes:
> Only small subset of users answered the survey. Emacs is used by much larger number of people. One can see that survey says that users who did answer the survey are on level higher.
>
> If you disable the toolbar you are doing it for those who answered the survey, not for those coming to Emacs, larger number of users.
>
> If I rememberv well survey also shows that large number of users use
> it since shorter time like one year meaning that larger number of
> users drop in the first year. Finding that cause and improving there
> would keep those users.
I guess it would be interesting to also find out what the connection is
between newer users and toolbar usage. I personally think that the
menu-bar is more than enough (though also not necessary), and that the
toolbar is inefficient, and even if it were, it's underutilized.
People who use the TUI mode or "distributions" also usually don't have
to disable it, so that might also be a factor that has to be considered.
> On December 15, 2020 5:30:20 AM UTC, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>>In that mega thread about modernising Emacs, there was a lot of talk
>>about getting more data about how people use Emacs, and then... do
>>something accordingly.
>>
>>Behold: https://emacssurvey.org/2020/
>>
>>So here's the first thread about actionable takeaways from the survey.
>>(Consider all arguments about the survey not being representative as
>>having been made already.)
>>
>>Of 7.3K respondents, 5K disable toolbars, which is more than two
>>thirds. So perhaps toolbars should default to off? I know toolbars
>>were all the rage in the 90s, but that's apparently not the case now.
>>
>>Opinions?
>
>
> Jean
>
>
--
Philip K.
^ permalink raw reply [relevance 97%]
* Re: Emacs Survey: Toolbars
@ 2020-12-15 18:48 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-12-15 18:48 UTC (permalink / raw)
To: Óscar Fuentes; +Cc: emacs-devel
Óscar Fuentes <ofv@wanadoo.es> writes:
>>>> and which may well be discouraging people from using Emacs
>>>> at all (because it looks useless and out of touch).
>>>
>>> We have no data to support that.
>>
>> I did, very carefully, not claim that we do.
>
> At some point on the past it was decided that having a toolbar was a
> good thing. Switching it off just because a very poorly executed survey
> barely resembles a democratic vote on its utility, without revisiting
> the original motivation, is questionable.
>
> Really, this kind of decissions should be based on guidance by UI
> experts. Sadly, it seems that we have none onboard, same as every other
> Free or Open Source projects around (and even most propietary ones).
> They are very scarce.
Maybe I'm too cynical, but can a non-Emacs UI expert really help with
something as other-worldly as Emacs? And I don't even mean this in an
elitist way, just that it has so many conventions and usage-patterns
from parallel UI traditions, that it might seem easier to just start all
over (which I'm not advocating for).
> BTW, I disable the toolbar (and the menu) on my config.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?]
@ 2020-12-21 16:59 92% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-12-21 16:59 UTC (permalink / raw)
To: Richard Stallman; +Cc: Adam Porter, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Would people please tell me what new capabilities you aim to have
> in this new facility? How would it be better than using url.el
> or running curl as a subprocess?
>
> What jobs do you think of using it for?
>
> I'm concerned that it may add a substantial amount of complexity
> that we could do without. I'm also concerned about how it might
> deal with Javascript code.
I think the main issue is that url.el can often be rather slow,
sometimes taking half a minute or more to complete a request that would
take curl or other libraries a blink of an eye.
If curl or whatever other method could be used to accelerate url.el, a
lot of application in Emacs would become more feasible to use, without
having to rewrite anything.
Request.el is another story, and I can't comment on that. It's probably
just like with dash/s/f/... where non-elisp developers dislike the
built-in API, but I'm just guessing.
--
Philip K.
^ permalink raw reply [relevance 92%]
* Re: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?]
@ 2020-12-21 23:51 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-12-21 23:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: adam, rms, arthur.miller, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Mon, 21 Dec 2020 18:41:02 +0100
>> Cc: adam@alphapapa.net, "Philip K." <philipk@posteo.net>, rms@gnu.org,
>> emacs-devel@gnu.org
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Before this is taken as an indication that using one of these
>> > libraries will automagically make Emacs as fast as the applications
>> > like curl, we should carefully profile url.el and find out which
>> > part(s) of it cause the slowness. Because it could well be that what
>> > makes url.el slow will also make Emacs using libcurl slow.
>>
>> Maybe this library can be of help while testing/profiling
>
> We have a built-in profiler in Emacs.
In that case, gnutls-negotiate seems to be the most suspicious function,
using over 50%-60% of the CPU time, at least on my machine. This also
makes sense, as TLS sites seem to take longer to load than regular,
non-encrypted ones.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?]
@ 2020-12-22 10:38 80% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-12-22 10:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: adam, rms, arthur.miller, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: "Philip K." <philipk@posteo.net>
>> Cc: arthur.miller@live.com, adam@alphapapa.net, rms@gnu.org,
>> emacs-devel@gnu.org
>> Date: Tue, 22 Dec 2020 00:51:08 +0100
>>
>> >> > Before this is taken as an indication that using one of these
>> >> > libraries will automagically make Emacs as fast as the applications
>> >> > like curl, we should carefully profile url.el and find out which
>> >> > part(s) of it cause the slowness. Because it could well be that what
>> >> > makes url.el slow will also make Emacs using libcurl slow.
>> >>
>> >> Maybe this library can be of help while testing/profiling
>> >
>> > We have a built-in profiler in Emacs.
>>
>> In that case, gnutls-negotiate seems to be the most suspicious function,
>> using over 50%-60% of the CPU time, at least on my machine. This also
>> makes sense, as TLS sites seem to take longer to load than regular,
>> non-encrypted ones.
>
> Please show the code you profiled and the fully expanded profile.
I sadly coudln't reproduce it, but this time the critical section looked
something like this:
- url-retrieve-synchronously 212 52%
- url-retrieve 149 36%
- url-retrieve-internal 149 36%
- url-http 136 33%
- url-http-find-free-connection 135 33%
- url-open-stream 135 33%
open-network-stream 134 33%
when evaluating
(url-retrieve-synchronously "http://textboard.org/sexp/prog/index")
in the *scratch* buffer. I used emacs -Q (GNU Emacs 27.1 (build 1,
x86_64-redhat-linux-gnu, GTK+ Version 3.24.22, cairo version 1.16.0) of
2020-08-21), but I don't know why that should make any
difference. I repeated the same test on the master branch and the
results were basically the same (±5%).
Either way, this simple request took over 2.5 minutes, whereas curl
requires a quarter of a second. Note that this is even unencrypted, so
this is not even taking the encryption overhead into account.
(FYI: I took textboard.org as an example, because I wrote a client for
this site in Elisp, that often takes a while to load, so I could
count on it for this test. An interesting observation is that the
first request might take a while, but sometimes the connection
time suddenly drops to basically nothing. I have yet to figure
out what the reason is. :/)
--
Philip K.
^ permalink raw reply [relevance 80%]
* Re: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?]
@ 2020-12-22 10:49 88% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-12-22 10:49 UTC (permalink / raw)
To: rms; +Cc: adam, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> > Request.el is another story, and I can't comment on that. It's probably
> > just like with dash/s/f/... where non-elisp developers dislike the
> > built-in API, but I'm just guessing.
>
> From what people have said here, it sounds unproblematical.
> But could you explain what you mean by comparing it with dash/s/f/?
In my experience, people use dash/s/f when they are either unfamiliar
with the built-in functions and macros, or when they find them too
cumbersome to use (I'm sure there are exceptions, but again, this is my
impression). So they want to write (s-join "+" '("abc" "def" "ghi"))
instead of (mapconcat #'identity '("abc" "def" "ghi") "+"), and add an
external dependency for this minor convenience.
And again, in my experience this often motivates people to use request,
though it might be a better example, because it actually does useful
stuff, even though I don't always think it's idiomatic. The built-in
url.el could use this as an inspiration, to add more macros/functions
that simplify code.
One notable difference is that it will use curl, the binary, instead of
url.el if it's installed, which does notably accelerate network
requests.
--
Philip K.
^ permalink raw reply [relevance 88%]
* Re: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?]
@ 2020-12-22 13:23 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-12-22 13:23 UTC (permalink / raw)
To: Jean Louis; +Cc: adam, rms, emacs-devel
Jean Louis <bugs@gnu.support> writes:
> * Philip K. <philipk@posteo.net> [2020-12-22 13:53]:
>> One notable difference is that it will use curl, the binary, instead of
>> url.el if it's installed, which does notably accelerate network
>> requests.
>
> Do you think Emacs could use some C library like gnurl or something
> else that could accelerate Emacs's network requests?
I don't know enough about how Emacs' networking currently works to say
for sure.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?]
@ 2020-12-22 16:59 79% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2020-12-22 16:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: adam, rms, arthur.miller, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: "Philip K." <philipk@posteo.net>
>> Cc: arthur.miller@live.com, adam@alphapapa.net, rms@gnu.org,
>> emacs-devel@gnu.org
>> Date: Tue, 22 Dec 2020 11:38:31 +0100
>>
>> >> In that case, gnutls-negotiate seems to be the most suspicious function,
>> >> using over 50%-60% of the CPU time, at least on my machine. This also
>> >> makes sense, as TLS sites seem to take longer to load than regular,
>> >> non-encrypted ones.
>> >
>> > Please show the code you profiled and the fully expanded profile.
>>
>> I sadly coudln't reproduce it, but this time the critical section looked
>> something like this:
>>
>> - url-retrieve-synchronously 212 52%
>> - url-retrieve 149 36%
>> - url-retrieve-internal 149 36%
>> - url-http 136 33%
>> - url-http-find-free-connection 135 33%
>> - url-open-stream 135 33%
>> open-network-stream 134 33%
>>
>> when evaluating
>>
>> (url-retrieve-synchronously "http://textboard.org/sexp/prog/index")
>>
>> in the *scratch* buffer. I used emacs -Q (GNU Emacs 27.1 (build 1,
>> x86_64-redhat-linux-gnu, GTK+ Version 3.24.22, cairo version 1.16.0) of
>> 2020-08-21), but I don't know why that should make any
>> difference. I repeated the same test on the master branch and the
>> results were basically the same (±5%).
>>
>> Either way, this simple request took over 2.5 minutes, whereas curl
>> requires a quarter of a second. Note that this is even unencrypted, so
>> this is not even taking the encryption overhead into account.
>
> That's strange, because I get here much faster times: 0.6 sec (with 3
> GC cycles) on the first attempt, and less than 0.1 sec afterwards.
Why did it take three GC cycles? benchmark-run says
(130.773534384 0 0.0)
and
(129.933227402 0 0.0)
for the first two runs, and
(0.044592597 0 0.0)
for the third one, a bit later.
> How come it's so slow on your system?
I can't say for sure, but I don't think it is due to some specific local
configuration. I reran the code on a university computer a few
kilometres away, and the behaviour stays basically the same, even though
their network is a lot better than mine. But when I ran it on a VPS in
Berlin (I'm currently in southern Germany), it was a lot faster, despite
probably running the same build (whatever it in the Debian Buster
repository). I looked up where textboard.org is located, and it seems to
be in France, or it at the very least has to pass through some Proxy in
France. Another interesting observation is that connections from my home
to my university are basically instantaneous using Eww, and vice
versa. The Server in Berlin takes a lot longer to connect to my local
network and my university server. The only exception to this rule is
that eww doesn't seem to take that long to connect to my VPS.
None of these effects are observable using curl.
I guess this should be reported as a proper bug, instead of being
discussed here.
--
Philip K.
^ permalink raw reply [relevance 79%]
* Re: Poll: Change xref-show-definitions-function's default?
@ 2021-01-02 10:24 99% ` Philip K.
2021-01-04 12:12 99% ` Philip K.
2 siblings, 0 replies; 200+ results
From: Philip K. @ 2021-01-02 10:24 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Dmitry Gutov <dgutov@yandex.ru> writes:
> Hi all,
>
> In commit 8c383456291185b029b469061338b5b797a49747 I have done a bit
> of cleanup and documented the existing alternative options.
I wanted to test it with a few more options, so I tried
xref-find-apropos, but that doesn't seem to be affected by chaining the
option. Is this intentional?
> What do you say we make one of them the default?
>
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Poll: Change xref-show-definitions-function's default?
@ 2021-01-02 10:26 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2021-01-02 10:26 UTC (permalink / raw)
To: martin rudalics; +Cc: emacs-devel, Dmitry Gutov
martin rudalics <rudalics@gmx.at> writes:
>> In commit 8c383456291185b029b469061338b5b797a49747 I have done a bit of cleanup and documented the existing alternative options.
>>
>> What do you say we make one of them the default?
>
> Sometimes I'd like to choose an alternative from a menu or some sort of
> drop down list. At least when I use the mouse. Would that be feasible
> to add, somehow?
Do you mean something like this:
https://github.com/fmdkdd/dotfiles/blob/master/emacs/.emacs.d/elisp/xref-posframe.el?
> martin
>
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Poll: Change xref-show-definitions-function's default?
2021-01-02 10:24 99% ` Philip K.
@ 2021-01-04 12:12 99% ` Philip K.
2 siblings, 0 replies; 200+ results
From: Philip K. @ 2021-01-04 12:12 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Dmitry Gutov <dgutov@yandex.ru> writes:
> Hi all,
>
> In commit 8c383456291185b029b469061338b5b797a49747 I have done a bit
> of cleanup and documented the existing alternative options.
Another idea, might be to have a "silent" option, that doesn't display
the buffer by default, but leaves a message that there are more results.
> What do you say we make one of them the default?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Poll: Change xref-show-definitions-function's default?
@ 2021-01-04 14:21 92% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2021-01-04 14:21 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Dmitry Gutov <dgutov@yandex.ru> writes:
> On 04.01.2021 14:12, Philip K. wrote:
>> Another idea, might be to have a "silent" option, that doesn't display
>> the buffer by default, but leaves a message that there are more results.
>
> What happens next, then? How will the user get to any of those results?
The idea would be that the interaction would look something like this:
1. The user invokes xref-find-definitions.
2. Instead of presenting the solutions, it jumps to the first one, and
if there are more, this is indicated in the minibuffer.
3. Other matches can be displayed using next-error/previous-error
4. At this point, the buffer could be opened, or one could stick to the
minibuffer and generate a message like "showing definition N out of
M".
I haven't looked into next-error/previous-error, so it might be that
this isn't feasible, without rewriting a lot of code.
It goes without saying that this should not be the default option.
--
Philip K.
^ permalink raw reply [relevance 92%]
* Re: POLL: make C-x o transient
@ 2021-01-25 16:38 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2021-01-25 16:38 UTC (permalink / raw)
To: aitor; +Cc: emacs-devel
aitor <a.soroa@gmail.com> writes:
> On Mon, Jan 25, 2021 at 09:39:00AM -0500, Stefan Monnier wrote:
>> > Which will make `C-x o` invoke a transient version of `other-window'
>> > like `text-scale-adjust’ does.
>>
>> I think the pattern is clear: `C-x <letter>` are good candidates ;-)
>
> Sorry to chime in with an off-topic issue, but I once wrote the following in my
> init.el file:
>
> ;; move thorugh windows
> (global-set-key (kbd "C-x <left>") 'windmove-left)
> (global-set-key (kbd "C-x <right>") 'windmove-right)
> (global-set-key (kbd "C-x <up>") 'windmove-up)
> (global-set-key (kbd "C-x <down>") 'windmove-down)
If you don't use the arrow keys for regular navigation, you could just
as well bind the windmove commands directly to up/down/left/right.
> and never have looked back since. This is very useful for me, particularly when
> dealing with many windows (gdb-many-windows, etc).
>
> best,
> aitor
>
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: POLL: make C-x o transient
@ 2021-01-28 7:46 99% ` Philip K.
1 sibling, 0 replies; 200+ results
From: Philip K. @ 2021-01-28 7:46 UTC (permalink / raw)
To: Juri Linkov; +Cc: condy0919@gmail.com, Stefan Monnier, Zhiwei Chen, emacs-devel
Juri Linkov <juri@linkov.net> writes:
>>>> Which will make `C-x o` invoke a transient version of `other-window'
>>>> like `text-scale-adjust’ does.
>>>
>>> I think the pattern is clear: `C-x <letter>` are good candidates ;-)
>>
>> And non-letters too, especially `C-x {`, `C-x }`, `C-x ^`, ...
>> need to be repeatable. I'm using such quite messy blob of code,
>> it would be nice if someone would generalize this mess
>> without using advice-add.
>
> Maybe something simple like:
>
> #+begin_src emacs-lisp
> (put 'other-window 'repeatable-command t)
> (put 'enlarge-window 'repeatable-command t)
> (put 'enlarge-window-horizontally 'repeatable-command t)
> (put 'shrink-window-horizontally 'repeatable-command t)
>
> (add-hook 'post-command-hook 'repeatable-command)
>
> (defun repeatable-command ()
> (when (get this-command 'repeatable-command)
> (let* ((keys (this-single-command-keys))
> (last-key (elt keys (1- (length keys)))))
> (set-transient-map
> (let ((map (make-sparse-keymap)))
> (define-key map (vector last-key) this-command)
> map)))))
> #+end_src
I like this idea, but would the hook be added by default?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: POLL: make C-x o transient
@ 2021-01-28 23:19 99% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2021-01-28 23:19 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Gregory Heytings, emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> Hello, Gregory.
>
> On Thu, Jan 28, 2021 at 19:13:22 +0000, Gregory Heytings wrote:
>
>
>> > Just switch the direction by the prefix arg '-'. Its handling could be
>> > easily implemented. It seems better to extend repeat.el to allow using
>> > the last key of the last command, add handling of universal arguments,
>> > and all this without using add-advice and hooks.
>
>> IMO it is would be much better to map the existing repeat command to a
>> single keystroke, it would make any command repeatable without changing
>> anything else, and it already handles universal arguments. I think C-=
>> would be the best key for this: not only is "=" a good mnemonic for "same
>> command", but it is also next to the "-" key to change the direction.
>
> It depends entirely on your keyboard layout. On a standard German
> keyboard, for example, = is <shift>0, so C-= would mean pressing three
> keys at the same time. Also on the same keyboard, - and = are nowhere
> near eachother.
>
> Also, does C-= even exist on a typical tty layout?
>
> Also[2], C-= is likely bound to many users' personal commands.
I know of at least one (MELPA) package that recommend this key:
https://github.com/magnars/expand-region.el#expand-regionel--
So I'd agree that this is a reasonable objection.
> So I think I would be against using C-= for this command.
--
Philip K.
^ permalink raw reply [relevance 99%]
* [ELPA] A Setup package
@ 2021-02-04 11:43 33% Philip K.
2021-02-04 11:47 37% ` Philip K.
0 siblings, 2 replies; 200+ results
From: Philip K. @ 2021-02-04 11:43 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 57 bytes --]
Hi,
I would like to propose adding a package to ELPA:
[-- Attachment #2: setup.el --]
[-- Type: text/plain, Size: 9193 bytes --]
;;; setup.el --- Helpful Configuration Macro -*- lexical-binding: t -*-
;; Author: Philip K. <philipk@posteo.net>
;; Maintainer: Philip K. <philipk@posteo.net>
;; Version: 0.1.0
;; Package-Requires: ((emacs "25.1"))
;; Keywords: lisp, local
;; This file is NOT part of Emacs.
;;
;; This file is in the public domain, to the extent possible under law,
;; published under the CC0 1.0 Universal license.
;;
;; For a full copy of the CC0 license see
;; https://creativecommons.org/publicdomain/zero/1.0/legalcode
;;; Commentary:
;; The `setup' macro simplifies repetitive configuration patterns.
;; For example, these macros:
;; (setup shell
;; (let ((key "C-c s"))
;; (global (key shell))
;; (bind (key bury-buffer))))
;;
;;
;; (setup (package paredit)
;; (hide-lighter)
;; (hook-into scheme-mode lisp-mode))
;; will be replaced with the functional equivalent of
;; (global-set-key (kbd "C-c s") #'shell)
;; (with-eval-after-load 'shell
;; (define-key shell-mode-map (kbd "C-c s") #'bury-buffer))
;;
;;
;; (unless (package-install-p 'paredit)
;; (package-install 'paredit ))
;; (delq (assq 'paredit-mode minor-mode-alist)
;; minor-mode-alist)
;; (add-hook 'scheme-mode-hook #'paredit-mode)
;; (add-hook 'lisp-mode-hook #'paredit-mode)
;; Additional "keywords" can be defined using `setup-define'.
;;; Code:
(eval-when-compile (require 'cl-macs))
\f
;;; `setup' macros
(defvar setup-macros nil
"Local macro definitions to be bound in `setup' bodies.")
(defun setup-after-load (body)
"Wrap BODY in a `with-eval-after-load'."
``(with-eval-after-load setup-name ,,body))
;;;###autoload
(defmacro setup (&rest body)
"Configure a feature or subsystem.
BODY may contain special forms defined by `setup-define', but
will otherwise just be evaluated as is."
(declare (indent defun))
(let* ((name (if (and (listp (car body))
(get (caar body) 'setup-get-name))
(funcall (get (caar body) 'setup-get-name)
(car body))
(car body)))
(mode (if (string-match-p "-mode\\'" (symbol-name name))
name
(intern (format "%s-mode" name)))))
(when (symbolp (car body))
(pop body))
`(let ((setup-name ',name)
(setup-mode ',mode) ;best guess
(setup-map ',(intern (format "%s-map" mode)))
(setup-hook ',(intern (format "%s-hook" mode))))
(ignore setup-name setup-mode setup-map setup-hook)
(catch 'setup-exit
(cl-macrolet ,setup-macros
,@body)))))
;;;###autoload
(defun setup-define (name fn &rest opts)
"Define `setup'-local macro NAME using function FN.
The plist OPTS may contain the key-value pairs:
:name
Specify a function to use, for extracting the feature name of a
NAME entry, if it is the first element in a setup macro.
:indent
Set the symbol property `lisp-indent-function' for NAME.
:wrap
Specify a function used to wrap the results of a NAME entry.
:sig
Give an advertised calling convention.
:doc
A documentation string."
(declare (indent 1))
(cl-assert (symbolp name))
(cl-assert (functionp fn))
(cl-assert (listp opts))
;; save metadata
(put name 'setup-get-name (plist-get opts :name))
(put name 'setup-documentation (plist-get opts :doc))
(put name 'setup-signature (plist-get opts :sig))
(put name 'lisp-indent-function (plist-get opts :indent))
;; forget previous definition
(setq setup-macros (delq (assq name setup-macros)
setup-macros))
;; define macro for `cl-macrolet'
(push (let ((arity (func-arity fn)))
(cl-flet ((wrap (result)
(if (plist-get opts :wrap)
(funcall (plist-get opts :wrap) result)
result)))
(cond ((eq (cdr arity) 'many)
`(,name (&rest args) ,(wrap `(apply #',fn args))))
((eq (cdr arity) 0)
`(,name () ,(wrap `(funcall #',fn))))
((= (car arity) (cdr arity))
`(,name (&rest args)
(unless (zerop (mod (length args) ,(car arity)))
(error "Illegal arguments"))
(let ((aggr (list 'progn)))
(while args
(let ((rest (nthcdr ,(car arity) args)))
(setf (nthcdr ,(car arity) args) nil)
(push (apply #',fn args) aggr)
(setq args rest)))
,(wrap `(nreverse aggr)))))
((error "Illegal function")))))
setup-macros)
(set-advertised-calling-convention name (plist-get opts :sig) nil))
(defun setup-help ()
"Generate and display a help buffer for the `setup' macro."
(interactive)
(with-help-window (help-buffer)
(princ "The `setup' macro defines the following local macros:\n\n")
(dolist (sym (mapcar #'car setup-macros))
(let ((doc (or (get sym 'setup-documentation)
"No documentation."))
(sig (if (get sym 'setup-signature)
(cons sym (get sym 'setup-signature))
(list sym))))
(princ (format "- %s\n\n%s\n\n" sig doc))))))
\f
;;; definitions of `setup' keywords
(setup-define 'with-mode
(lambda (mode &rest body)
`(let ((setup-mode ',mode)
(setup-map ',(intern (format "%s-map" mode)))
(setup-hook ',(intern (format "%s-hook" mode))))
(ignore setup-mode setup-map setup-hook)
,@body))
:sig '(MODE &body BODY)
:doc "Change the MODE that BODY is configuring."
:indent 1)
(setup-define 'with-map
(lambda (map &rest body)
`(let ((setup-map ',map))
,@body))
:sig '(MAP &body BODY)
:doc "Change the MAP that BODY will bind to"
:indent 1)
(setup-define 'with-hook
(lambda (hook &body body)
`(let ((setup-hook ',hook))
,@body))
:sig '(HOOK &body BODY)
:doc "Change the HOOK that BODY will use."
:indent 1)
(setup-define 'package
(lambda (package)
`(unless (package-installed-p ',package)
(package-install ',package)))
:sig '(PACKAGE *)
:doc "Install PACKAGE if it hasn't been installed yet."
:name #'cadr)
(setup-define 'global
(lambda (bind)
(let ((key (car bind))
(fn (cadr bind)))
`(global-set-key ,(if (atom key) `(kbd ,key) key) #',fn)))
:sig '((KEY FUNCTION)*)
:doc "Globally bind KEY to FUNCTION.
If KEY is an atom, the function `kbd' will be applied.")
(setup-define 'bind
(lambda (bind)
(let ((key (car bind))
(fn (cadr bind)))
`(define-key (eval setup-map) ,(if (atom key) `(kbd ,key) key) #',fn)))
:sig '((KEY FUNCTION)*)
:doc "Bind KEY to FUNCTION in current map.
If KEY is an atom, the function `kbd' will be applied."
:wrap #'setup-after-load)
(setup-define 'unbind
(lambda (key)
`(define-key (eval setup-map) ,(if (atom key) `(kbd ,key) key) nil))
:sig '(KEY *)
:doc "Unbind KEY in current map.
If KEY is an atom, the function `kbd' will be applied."
:wrap #'setup-after-load)
(setup-define 'hook
(lambda (hook)
`(add-hook setup-hook #',hook))
:sig '(FUNCTION *)
:doc "Add FUNCTION to current hook.")
(setup-define 'hook-into
(lambda (mode)
`(add-hook ',(intern (concat (symbol-name mode) "-hook"))
setup-mode))
:sig '(HOOK *)
:doc "Add current mode to HOOK.")
(setup-define 'option
(lambda (assign)
(let ((opt (car assign))
(val (cadr assign)))
`(progn
(customize-set-variable ',opt ,val)
(put ',opt 'saved-value nil))))
:sig '((NAME VAL) *)
:doc "Set the option NAME to VAL.")
(setup-define 'hide-lighter
(lambda ()
`(delq (assq setup-mode minor-mode-alist)
minor-mode-alist))
:doc "Hide the mode-line lighter of the current mode."
:body 'after-load)
(setup-define 'local-set
(lambda (assign)
(let ((var (car assign))
(val (cadr assign)))
`(add-hook setup-hook (lambda () (setq-local ,var ,val)))))
:sig '((VAR VAL) *)
:doc "Set the value of VAR to VAL in buffers of the current mode."
:wrap #'setup-after-load)
(setup-define 'local-hook
(lambda (entry)
(let ((hook (car entry))
(fn (cadr entry)))
`(add-hook setup-hook
(lambda ()
(add-hook ,hook #',fn nil t)))))
:sig '((HOOK FUNCTION) *)
:doc "Add FUNCTION to HOOK only in buffers of the current mode.")
(setup-define 'needs
(lambda (binary)
`(unless (executable-find ,binary)
(throw 'setup-exit nil)))
:sig '(PROGRAM *)
:doc "If PROGRAM is not in the path, stop here.")
(setup-define 'require
(lambda (feature) `(require ,feature))
:sig '(FEATURE)
:doc "Require FEATURE to be loaded."
:name #'cadr)
(setup-define 'when-loaded
(lambda (&rest body) `(progn ,@body))
:sig '(&body BODY)
:doc "Evaluate BODY after the current feature has been loaded."
:wrap #'setup-after-load)
(provide 'setup)
;;; setup.el ends here
[-- Attachment #3: Type: text/plain, Size: 1578 bytes --]
This can be compared to use-package. The difference is that instead of
the keyword-argument structure, it uses local macros that allow
interleaving regular lisp with the configuration syntax. In this sense,
it /might/ be compared to Common Lisp's Loop[0] and Iterate[1] control
structures.
I'll just quote an example from the commentary section to demonstrate
how this looks like:
The `setup' macro simplifies repetitive configuration patterns.
For example, these macros:
(setup shell
(let ((key "C-c s"))
(global (key shell))
(bind (key bury-buffer))))
(setup (package paredit)
(hide-lighter)
(hook-into scheme-mode lisp-mode))
will be replaced with the functional equivalent of
(global-set-key (kbd "C-c s") #'shell)
(with-eval-after-load 'shell
(define-key shell-mode-map (kbd "C-c s") #'bury-buffer))
(unless (package-install-p 'paredit)
(package-install 'paredit ))
(delq (assq 'paredit-mode minor-mode-alist)
minor-mode-alist)
(add-hook 'scheme-mode-hook #'paredit-mode)
(add-hook 'lisp-mode-hook #'paredit-mode)
If there are any comments/improvements on the code itself, I'd be glad
to fix them. I am the only author, so there should be no copyright
issues.
[0] http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm
[1] https://common-lisp.net/project/iterate/doc/Don_0027t-Loop-Iterate.html
--
Philip K.
^ permalink raw reply [relevance 33%]
* Re: [ELPA] A Setup package
2021-02-04 11:43 33% [ELPA] A Setup package Philip K.
@ 2021-02-04 11:47 37% ` Philip K.
1 sibling, 0 replies; 200+ results
From: Philip K. @ 2021-02-04 11:47 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 216 bytes --]
I just noticed that I accidentally inserted the file inline instead of
attaching it. Here's the fixed message:
"Philip K." <philipk@posteo.net> writes:
> Hi,
>
> I would like to propose adding a package to ELPA:
[-- Attachment #2: setup.el --]
[-- Type: text/plain, Size: 9193 bytes --]
;;; setup.el --- Helpful Configuration Macro -*- lexical-binding: t -*-
;; Author: Philip K. <philipk@posteo.net>
;; Maintainer: Philip K. <philipk@posteo.net>
;; Version: 0.1.0
;; Package-Requires: ((emacs "25.1"))
;; Keywords: lisp, local
;; This file is NOT part of Emacs.
;;
;; This file is in the public domain, to the extent possible under law,
;; published under the CC0 1.0 Universal license.
;;
;; For a full copy of the CC0 license see
;; https://creativecommons.org/publicdomain/zero/1.0/legalcode
;;; Commentary:
;; The `setup' macro simplifies repetitive configuration patterns.
;; For example, these macros:
;; (setup shell
;; (let ((key "C-c s"))
;; (global (key shell))
;; (bind (key bury-buffer))))
;;
;;
;; (setup (package paredit)
;; (hide-lighter)
;; (hook-into scheme-mode lisp-mode))
;; will be replaced with the functional equivalent of
;; (global-set-key (kbd "C-c s") #'shell)
;; (with-eval-after-load 'shell
;; (define-key shell-mode-map (kbd "C-c s") #'bury-buffer))
;;
;;
;; (unless (package-install-p 'paredit)
;; (package-install 'paredit ))
;; (delq (assq 'paredit-mode minor-mode-alist)
;; minor-mode-alist)
;; (add-hook 'scheme-mode-hook #'paredit-mode)
;; (add-hook 'lisp-mode-hook #'paredit-mode)
;; Additional "keywords" can be defined using `setup-define'.
;;; Code:
(eval-when-compile (require 'cl-macs))
\f
;;; `setup' macros
(defvar setup-macros nil
"Local macro definitions to be bound in `setup' bodies.")
(defun setup-after-load (body)
"Wrap BODY in a `with-eval-after-load'."
``(with-eval-after-load setup-name ,,body))
;;;###autoload
(defmacro setup (&rest body)
"Configure a feature or subsystem.
BODY may contain special forms defined by `setup-define', but
will otherwise just be evaluated as is."
(declare (indent defun))
(let* ((name (if (and (listp (car body))
(get (caar body) 'setup-get-name))
(funcall (get (caar body) 'setup-get-name)
(car body))
(car body)))
(mode (if (string-match-p "-mode\\'" (symbol-name name))
name
(intern (format "%s-mode" name)))))
(when (symbolp (car body))
(pop body))
`(let ((setup-name ',name)
(setup-mode ',mode) ;best guess
(setup-map ',(intern (format "%s-map" mode)))
(setup-hook ',(intern (format "%s-hook" mode))))
(ignore setup-name setup-mode setup-map setup-hook)
(catch 'setup-exit
(cl-macrolet ,setup-macros
,@body)))))
;;;###autoload
(defun setup-define (name fn &rest opts)
"Define `setup'-local macro NAME using function FN.
The plist OPTS may contain the key-value pairs:
:name
Specify a function to use, for extracting the feature name of a
NAME entry, if it is the first element in a setup macro.
:indent
Set the symbol property `lisp-indent-function' for NAME.
:wrap
Specify a function used to wrap the results of a NAME entry.
:sig
Give an advertised calling convention.
:doc
A documentation string."
(declare (indent 1))
(cl-assert (symbolp name))
(cl-assert (functionp fn))
(cl-assert (listp opts))
;; save metadata
(put name 'setup-get-name (plist-get opts :name))
(put name 'setup-documentation (plist-get opts :doc))
(put name 'setup-signature (plist-get opts :sig))
(put name 'lisp-indent-function (plist-get opts :indent))
;; forget previous definition
(setq setup-macros (delq (assq name setup-macros)
setup-macros))
;; define macro for `cl-macrolet'
(push (let ((arity (func-arity fn)))
(cl-flet ((wrap (result)
(if (plist-get opts :wrap)
(funcall (plist-get opts :wrap) result)
result)))
(cond ((eq (cdr arity) 'many)
`(,name (&rest args) ,(wrap `(apply #',fn args))))
((eq (cdr arity) 0)
`(,name () ,(wrap `(funcall #',fn))))
((= (car arity) (cdr arity))
`(,name (&rest args)
(unless (zerop (mod (length args) ,(car arity)))
(error "Illegal arguments"))
(let ((aggr (list 'progn)))
(while args
(let ((rest (nthcdr ,(car arity) args)))
(setf (nthcdr ,(car arity) args) nil)
(push (apply #',fn args) aggr)
(setq args rest)))
,(wrap `(nreverse aggr)))))
((error "Illegal function")))))
setup-macros)
(set-advertised-calling-convention name (plist-get opts :sig) nil))
(defun setup-help ()
"Generate and display a help buffer for the `setup' macro."
(interactive)
(with-help-window (help-buffer)
(princ "The `setup' macro defines the following local macros:\n\n")
(dolist (sym (mapcar #'car setup-macros))
(let ((doc (or (get sym 'setup-documentation)
"No documentation."))
(sig (if (get sym 'setup-signature)
(cons sym (get sym 'setup-signature))
(list sym))))
(princ (format "- %s\n\n%s\n\n" sig doc))))))
\f
;;; definitions of `setup' keywords
(setup-define 'with-mode
(lambda (mode &rest body)
`(let ((setup-mode ',mode)
(setup-map ',(intern (format "%s-map" mode)))
(setup-hook ',(intern (format "%s-hook" mode))))
(ignore setup-mode setup-map setup-hook)
,@body))
:sig '(MODE &body BODY)
:doc "Change the MODE that BODY is configuring."
:indent 1)
(setup-define 'with-map
(lambda (map &rest body)
`(let ((setup-map ',map))
,@body))
:sig '(MAP &body BODY)
:doc "Change the MAP that BODY will bind to"
:indent 1)
(setup-define 'with-hook
(lambda (hook &body body)
`(let ((setup-hook ',hook))
,@body))
:sig '(HOOK &body BODY)
:doc "Change the HOOK that BODY will use."
:indent 1)
(setup-define 'package
(lambda (package)
`(unless (package-installed-p ',package)
(package-install ',package)))
:sig '(PACKAGE *)
:doc "Install PACKAGE if it hasn't been installed yet."
:name #'cadr)
(setup-define 'global
(lambda (bind)
(let ((key (car bind))
(fn (cadr bind)))
`(global-set-key ,(if (atom key) `(kbd ,key) key) #',fn)))
:sig '((KEY FUNCTION)*)
:doc "Globally bind KEY to FUNCTION.
If KEY is an atom, the function `kbd' will be applied.")
(setup-define 'bind
(lambda (bind)
(let ((key (car bind))
(fn (cadr bind)))
`(define-key (eval setup-map) ,(if (atom key) `(kbd ,key) key) #',fn)))
:sig '((KEY FUNCTION)*)
:doc "Bind KEY to FUNCTION in current map.
If KEY is an atom, the function `kbd' will be applied."
:wrap #'setup-after-load)
(setup-define 'unbind
(lambda (key)
`(define-key (eval setup-map) ,(if (atom key) `(kbd ,key) key) nil))
:sig '(KEY *)
:doc "Unbind KEY in current map.
If KEY is an atom, the function `kbd' will be applied."
:wrap #'setup-after-load)
(setup-define 'hook
(lambda (hook)
`(add-hook setup-hook #',hook))
:sig '(FUNCTION *)
:doc "Add FUNCTION to current hook.")
(setup-define 'hook-into
(lambda (mode)
`(add-hook ',(intern (concat (symbol-name mode) "-hook"))
setup-mode))
:sig '(HOOK *)
:doc "Add current mode to HOOK.")
(setup-define 'option
(lambda (assign)
(let ((opt (car assign))
(val (cadr assign)))
`(progn
(customize-set-variable ',opt ,val)
(put ',opt 'saved-value nil))))
:sig '((NAME VAL) *)
:doc "Set the option NAME to VAL.")
(setup-define 'hide-lighter
(lambda ()
`(delq (assq setup-mode minor-mode-alist)
minor-mode-alist))
:doc "Hide the mode-line lighter of the current mode."
:body 'after-load)
(setup-define 'local-set
(lambda (assign)
(let ((var (car assign))
(val (cadr assign)))
`(add-hook setup-hook (lambda () (setq-local ,var ,val)))))
:sig '((VAR VAL) *)
:doc "Set the value of VAR to VAL in buffers of the current mode."
:wrap #'setup-after-load)
(setup-define 'local-hook
(lambda (entry)
(let ((hook (car entry))
(fn (cadr entry)))
`(add-hook setup-hook
(lambda ()
(add-hook ,hook #',fn nil t)))))
:sig '((HOOK FUNCTION) *)
:doc "Add FUNCTION to HOOK only in buffers of the current mode.")
(setup-define 'needs
(lambda (binary)
`(unless (executable-find ,binary)
(throw 'setup-exit nil)))
:sig '(PROGRAM *)
:doc "If PROGRAM is not in the path, stop here.")
(setup-define 'require
(lambda (feature) `(require ,feature))
:sig '(FEATURE)
:doc "Require FEATURE to be loaded."
:name #'cadr)
(setup-define 'when-loaded
(lambda (&rest body) `(progn ,@body))
:sig '(&body BODY)
:doc "Evaluate BODY after the current feature has been loaded."
:wrap #'setup-after-load)
(provide 'setup)
;;; setup.el ends here
[-- Attachment #3: Type: text/plain, Size: 1650 bytes --]
> This can be compared to use-package. The difference is that instead of
> the keyword-argument structure, it uses local macros that allow
> interleaving regular lisp with the configuration syntax. In this sense,
> it /might/ be compared to Common Lisp's Loop[0] and Iterate[1] control
> structures.
>
> I'll just quote an example from the commentary section to demonstrate
> how this looks like:
>
> The `setup' macro simplifies repetitive configuration patterns.
> For example, these macros:
>
> (setup shell
> (let ((key "C-c s"))
> (global (key shell))
> (bind (key bury-buffer))))
>
> (setup (package paredit)
> (hide-lighter)
> (hook-into scheme-mode lisp-mode))
>
> will be replaced with the functional equivalent of
>
> (global-set-key (kbd "C-c s") #'shell)
> (with-eval-after-load 'shell
> (define-key shell-mode-map (kbd "C-c s") #'bury-buffer))
>
> (unless (package-install-p 'paredit)
> (package-install 'paredit ))
> (delq (assq 'paredit-mode minor-mode-alist)
> minor-mode-alist)
> (add-hook 'scheme-mode-hook #'paredit-mode)
> (add-hook 'lisp-mode-hook #'paredit-mode)
>
>
> If there are any comments/improvements on the code itself, I'd be glad
> to fix them. I am the only author, so there should be no copyright
> issues.
>
> [0] http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.htm
> [1] https://common-lisp.net/project/iterate/doc/Don_0027t-Loop-Iterate.html
--
Philip K.
^ permalink raw reply [relevance 37%]
* Re: PROPOSAL: Repurpose one key and reserve it for third-party packages
[not found] ` <8ed9b43502ae9a36b057@heytings.org>
@ 2021-02-09 23:18 70% ` Philip K.
0 siblings, 0 replies; 200+ results
From: Philip K. @ 2021-02-09 23:18 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 4298 bytes --]
Gregory Heytings <gregory@heytings.org> writes:
>>> When such packages need to bind a command to a key, they can (1)
>>> either suggest users to bind it to a key reserved for users (for
>>> example, org-mode suggests to globally bind "C-c c" to
>>> org-capture), or (2) bind it to a key currently unused by Emacs
>>> (for example, Magit binds "C-x g" to magit-status in buffers
>>> visiting a file in a Git repository).
>>>
>>> Neither of these solutions are optimal: (1) requires an explicit
>>> configuration by the user, something which might confuse newcomers,
>>> and which other users might not want to do because they already use
>>> the keys reserved for users for other purposes, and (2) might
>>> conflict with the evolution of Emacs when one or more commands are
>>> bound to a yet unused key.
>>
>> I don't think this is a good idea, because situation (1) is good,
>> actually. Configuring a package, that provides a command as it's
>> interface, should be done by binding it to a key reserved for
>> users. Just like how configuring a minor mode is done by adding it
>> to a hook or a major mode by adding it to auto-mode-alist.
>>
>
> Situation (1) might be good in theory, it was probably good twenty
> years ago, but at least nowadays it is, in practice, not good. What
> most users do is that they install third-party packages through their
> distro package manager, or through Elpa or Melpa, and they just expect
> / would like it to work. That's what would happen when you install
> extension packages in most (if not all) other software (editors,
> browsers, ...): you don't have to manually fiddle with configuration
> files to make them work.
If I install ffmpeg via apt on a Debian system, I expect it to work, in
the sense that I can invoke the command from the terminal whenever I
want to use it. I don't think the analogy works for browsers, since
add-ons are usually filters or added to right-click menus. I don't know
enough about other extensible editors, but if they do too-smart-for-me
guessing, that's probably why I don't use them.
What might be interesting would be something like the gnu-elpa
package[0], or something that goes in the other direction, where a
package can recommend a keybinding, hook, etc. and "automatically"
configure itself if the user agrees.
The problem I see is that key-bindings are usually user configuration,
and e.g. Magit *works* without them. I can do M-x magit-status, right
after installing it. No extra configuration necessary. But if I want to
have it easier, it's easy to add.
> It's probably not without reasons that packages such as Magit bind
> keys globally.
AFAIK this was discussed in [1], but I don't get it, and I think it was
a bad decision.
>>
>> If you ask me, packages should try to minimize change the
>> environment when they are installed, as I've argued in [0]. In
>> other words, package-install shouldn't have any side-effects, beyond
>> installing a package.
>>
>
> That's not what most users expect. When you install a package, you
> just expect it to work. If they install a package to edit, say,
> Python code, they expect it will be used the next time they open a .py
> file. If they install Magit, they expect it will work when they open
> a file in a git repository. If they install Ivy, they expect it will
> take over C-x C-f, C-x b, and so forth.
I think Ivy is a good example where this should *not* be the case,
because it changes the user-interface that can be confusing. Major modes
might be ok, but the edge-cases is where it's critical: Let's say there
were two third-party packages for perl and prolog. It's common for both
to use the ".pl" extension, but which should get it. If I have been
using perl for a while, and I install prolog, should the new package
just "steal" the extension? Same goes for key-bindings. This should not
be done automatically, and reserving a name-space to solve this issue is
the wrong approach.
But setting that aside, I think that this expectation is just "wrong".
Packaging doesn't do configuration, and we shouldn't encourage this
misunderstanding. What works for some, breaks stuff for other people,
and that should be respected.
[0] http://elpa.gnu.org/packages/gnu-elpa.html
[1] https://github.com/magit/magit/pull/4237
--
Philip K.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]
^ permalink raw reply [relevance 70%]
* Re: [ELPA] A Setup package
@ 2021-02-09 23:42 71% ` Philip K.
2021-03-11 16:17 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip K. @ 2021-02-09 23:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 10729 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Hi Philip,
>
> Philip K. [2021-02-04 12:43:11] wrote:
>> I would like to propose adding a package to ELPA:
>
> Have you already signed the copyright paperwork?
> I see a possible matching "Philip K..." in the list, but its email is at
> warpmail rather than posteo. Is that you?
Yes, sorry about that. I changed providers last year, so it would be
better if that could be updated.
>> ;;; setup.el --- Helpful Configuration Macro -*- lexical-binding: t -*-
>>
>> ;; Author: Philip K. <philipk@posteo.net>
>> ;; Maintainer: Philip K. <philipk@posteo.net>
>> ;; Version: 0.1.0
>> ;; Package-Requires: ((emacs "25.1"))
>> ;; Keywords: lisp, local
>
> Is this file available in a Git repository somewhere?
I created one yesterday: https://git.sr.ht/~zge/setup. I'll push the
improvements to this repository, and notify this thread when I am done.
>> ;;; Commentary:
>>
>> ;; The `setup' macro simplifies repetitive configuration patterns.
>> ;; For example, these macros:
>>
>> ;; (setup shell
>> ;; (let ((key "C-c s"))
>> ;; (global (key shell))
>> ;; (bind (key bury-buffer))))
>> ;;
>> ;;
>> ;; (setup (package paredit)
>> ;; (hide-lighter)
>> ;; (hook-into scheme-mode lisp-mode))
>
> Ah, so it's to `use-package` a bit like `iterate` is to `loop`?
> I like that.
>
>> (eval-when-compile (require 'cl-macs))
>
> Please use (require 'cl-lib) rather than (require 'cl-macs) because the
> division of labor between those files is an internal detail.
Ok.
>> (defun setup-after-load (body)
>> "Wrap BODY in a `with-eval-after-load'."
>> ``(with-eval-after-load setup-name ,,body))
>
> Hmm... that's a fairly subtle semantics.
I'm not proud of it, but I haven't found a better solution yet.
>> ;;;###autoload
>> (defmacro setup (&rest body)
>> "Configure a feature or subsystem.
>> BODY may contain special forms defined by `setup-define', but
>> will otherwise just be evaluated as is."
>> (declare (indent defun))
>> (let* ((name (if (and (listp (car body))
>> (get (caar body) 'setup-get-name))
>> (funcall (get (caar body) 'setup-get-name)
>> (car body))
>> (car body)))
>
> Hmm.. why do you use (&rest body) instead of (name &rest body)?
>
> AFAICT this `setup-get-name` is so that you can say
>
> (setup (require shell)
> ...)
>
> which like (setup shell ...) except that it `require`s shell eagerly.
> And similarly
>
> (setup (package ivy)
> ...)
>
> will try and install `ivy` if it's not installed yet.
Yes, that is the idea, though it wanted, the signature might just as
well be (name &rest body).
> Is it worth this complexity? It seems you could get similar result
> without this trick using a syntax like:
>
> (setup ivy
> (:get-package)
> (:require)
> ...)
>
> which would save you this `setup-get-name` here and the corresponding
> `:name` in `setup-define`.
I don't know how to say if it is worth the complexity or not. I like it,
because it is more compact, but I might be biased.
>> ;;;###autoload
>> (defun setup-define (name fn &rest opts)
>> "Define `setup'-local macro NAME using function FN.
>> The plist OPTS may contain the key-value pairs:
>>
>> :name
>> Specify a function to use, for extracting the feature name of a
>> NAME entry, if it is the first element in a setup macro.
>>
>> :indent
>> Set the symbol property `lisp-indent-function' for NAME.
>>
>> :wrap
>> Specify a function used to wrap the results of a NAME entry.
>>
>> :sig
>> Give an advertised calling convention.
>>
>> :doc
>> A documentation string."
>
> Here are some of the problem I see:
> - You should add support for Edebug!
I have only ever used Edebug, never added support for it. I'll look into
this.
> - `:indent` will set the `lisp-indent-function` property on the symbol,
> making it apply globally rather than only within `setup`.
> [ The same problem will plague the `:sig` and the Edebug support, BTW. ]
> This is the reason why in `define-inline` I decided to prefix all the
> local macros with `inline-` :-(
> I don't have a really good solution for that (clearly, we'd like to
> allow `lisp-indent-function` (and Edebug's equivalent) to take some
> context into account, but that's not currently available.
> Patches welcome).
> But maybe to reduce the problem, you could use local macros with names
> that start with a `:`, as in:
>
> (setup shell
> (let ((key "C-c s"))
> (:global (key shell))
> (:bind (key bury-buffer))))
This was a problem I was thinking about, but couldn't solve. The idea to
use keywords might work though.
> - I'm not sure the generality of `:wrap` is worthwhile, since it seems
> it's only ever used for eval-after-load.
It might be worth dropping for a first version, and replacing it with a
:after-loaded keyword.
>> ;; define macro for `cl-macrolet'
>> (push (let ((arity (func-arity fn)))
>> (cl-flet ((wrap (result)
>> (if (plist-get opts :wrap)
>> (funcall (plist-get opts :wrap) result)
>> result)))
>> (cond ((eq (cdr arity) 'many)
>> `(,name (&rest args) ,(wrap `(apply #',fn args))))
>> ((eq (cdr arity) 0)
>> `(,name () ,(wrap `(funcall #',fn))))
>> ((= (car arity) (cdr arity))
>> `(,name (&rest args)
>> (unless (zerop (mod (length args) ,(car arity)))
>> (error "Illegal arguments"))
>> (let ((aggr (list 'progn)))
>> (while args
>> (let ((rest (nthcdr ,(car arity) args)))
>> (setf (nthcdr ,(car arity) args) nil)
>> (push (apply #',fn args) aggr)
>> (setq args rest)))
>> ,(wrap `(nreverse aggr)))))
>> ((error "Illegal function")))))
>> setup-macros)
>
> IIUC this expands calls that have "more args" into repeated calls, right?
> I suggest you make that behavior optional via some `:repeatable` keyword
> argument, which will be an opportunity to document that feature.
> That will also make it possible to accept `fn` values that allow optional
> arguments.
Will try.
>> (defun setup-help ()
>> "Generate and display a help buffer for the `setup' macro."
>> (interactive)
>> (with-help-window (help-buffer)
>> (princ "The `setup' macro defines the following local macros:\n\n")
>> (dolist (sym (mapcar #'car setup-macros))
>> (let ((doc (or (get sym 'setup-documentation)
>> "No documentation."))
>> (sig (if (get sym 'setup-signature)
>> (cons sym (get sym 'setup-signature))
>> (list sym))))
>> (princ (format "- %s\n\n%s\n\n" sig doc))))))
>
> Take a look at the definition of `pcase` to see how you can merge the
> above right into the normal function's doc, so you don't need a separate
> command and `C-h o setup` will directly give you that info.
Will do, thank you for the pointer.
>> (setup-define 'with-mode
>> (lambda (mode &rest body)
>> `(let ((setup-mode ',mode)
>> (setup-map ',(intern (format "%s-map" mode)))
>> (setup-hook ',(intern (format "%s-hook" mode))))
>> (ignore setup-mode setup-map setup-hook)
>> ,@body))
>> :sig '(MODE &body BODY)
>> :doc "Change the MODE that BODY is configuring."
>> :indent 1)
>
> It would be nice to use this macro in the `setup` macro, to reduce the
> code duplication between the two.
Can do.
>> (setup-define 'global
>> (lambda (bind)
>> (let ((key (car bind))
>> (fn (cadr bind)))
>> `(global-set-key ,(if (atom key) `(kbd ,key) key) #',fn)))
>
> `atom`? I think you only want to use `kbd` is `key` is a string, and
> not if it's a vector, for example.
I had to take atom, because otherwise the example
(setup shell
(let ((key "C-c s"))
(global (key shell))
(bind (key bury-buffer))))
wouldn't work, as "key" is a symbol. The alternative would be
(or (stringp key) (symbolp key))
that might be better, because I forgot that vectors are atoms (which
doesn't make sense, IMO).
> I find the syntax
>
> (bind (key bury-buffer))
>
> a bit confusing from a Lisp point of view. It would be nice to make it
> into a *function* (or at least use the syntax that corresponds to
> a function) so there's no confusion with a call to function `key`:
>
> (bind key 'bury-buffer)
>
> An alternative would be to go the other way and use
>
> (bind ((key bury-buffer))
I think the first alternative would be better, because it reminds me of
setq, but I get your point.
> BTW, I think it'd be good to allow `setup` to have not only local macros
> but also local functions (I think we should generally refrain from using
> macros when functions work about as well; it simplifies the overall
> system, leads to simpler semantics, and helps when debugging).
The idea behind using macros is that setup doesn't have to be loaded,
and can be byte-compiled away. Functions would either have to be
re-defined every time or aliased locally, which would require loading
setup. I'm not sure how I feel about this...
>> (setup-define 'hide-lighter
>> (lambda ()
>> `(delq (assq setup-mode minor-mode-alist)
>> minor-mode-alist))
>> :doc "Hide the mode-line lighter of the current mode."
>> :body 'after-load)
>
> I don't see `:body` handled anywhere.
Thank your for the node, that was an old definition I forgot to update.
>> (setup-define 'local-set
>> (lambda (assign)
>> (let ((var (car assign))
>> (val (cadr assign)))
>> `(add-hook setup-hook (lambda () (setq-local ,var ,val)))))
>> :sig '((VAR VAL) *)
>> :doc "Set the value of VAR to VAL in buffers of the current mode."
>> :wrap #'setup-after-load)
>
> Why after-load?
It is probably not necessary, but I'm not sure if there were some issues
with byte compilation if I didn't add it.
> Stefan
--
Philip K.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]
^ permalink raw reply [relevance 71%]
* Re: [External] : Re: Concern about new binding.
@ 2021-02-13 8:22 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-02-13 8:22 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: gregory, Drew Adams, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 415 bytes --]
"Alfred M. Szmidt" <ams@gnu.org> writes:
> You don't seem to be hearing that I want more
> than just reserving one prefix key, `C-o'.
>
> Most (All?) keyboards today have a Super key -- why not allocate that
> or parts of it to global third-party packages?
I can imagine that window managers shadow that key for their own
functionality -- this danger exists for all super keys.
--
Philip K.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]
^ permalink raw reply [relevance 99%]
* Clarifying the C-c letter guideline
@ 2021-02-14 12:12 76% Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-02-14 12:12 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1976 bytes --]
Hi,
a few days ago, there was a discussion on help-gnu-emacs[0],
specifically on this one paragraph from (elisp) Key Binding Conventions:
> • Don’t define ‘C-c LETTER’ as a key in Lisp programs. Sequences
> consisting of ‘C-c’ and a letter (either upper or lower case) are
> reserved for users; they are the *only* sequences reserved for
> users, so do not block them.
There seems to be some uncertainty in how this should be
interpreted. Does this mean that...
- No package/library/third-party code may ever bind a command or map to
C-c LETTER, under any circumstances (in the letter of the law).
- A package/library/third-party code may bind a command or a map to C-c
LETTER, if the user is explicitly asked and he or she gives
permission (in the spirit of the law).
I lean towards the second interpretation, which would allow something
like
(defcustom foobar-bind-to nil
"Bind command `foobar' to C-c LETTER."
:set (lambda (sym val)
(cond (val (global-set-key (format "%c" val) #'foobar))
((where-is-internal #'foobar)
(global-set-key (car (where-is-internal #'foobar)) nil)))
(set-default sym val))
:type '(choice (const :tag "Don't bind" nil)
(character :tag "Bind to")))
(even though I don't think code like this is necessary in the first
place, but this is just an example).
The background of this discussion is to settle the question, whether/how
packages might suggest binding a global command, if their interface is
not a major or minor mode, but a specific command
(e.g. magit-status). Using defcustom is probably not the best idea, but
something I think that something along these lines might be interesting
to have.
So I'd be interested in what the mailing list has to say on this
question. Should this section be rephrased to clarify the guideline?
[0] https://lists.gnu.org/archive/html/help-gnu-emacs/2021-02/msg00426.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]
^ permalink raw reply [relevance 76%]
* Re: Clarifying the C-c letter guideline
@ 2021-02-14 18:14 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-02-14 18:14 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
Jean Louis <bugs@gnu.support> writes:
> * Philip Kaludercic <philipk@posteo.net> [2021-02-14 15:14]:
>>
>> Hi,
>>
>> a few days ago, there was a discussion on help-gnu-emacs[0],
>> specifically on this one paragraph from (elisp) Key Binding Conventions:
>>
>> > • Don’t define ‘C-c LETTER’ as a key in Lisp programs. Sequences
>> > consisting of ‘C-c’ and a letter (either upper or lower case) are
>> > reserved for users; they are the *only* sequences reserved for
>> > users, so do not block them.
>>
>> There seems to be some uncertainty in how this should be
>> interpreted. Does this mean that...
>>
>> - No package/library/third-party code may ever bind a command or map to
>> C-c LETTER, under any circumstances (in the letter of the law).
>
> Convention is not a law, rather normative example. There are third
> party packages that are not public, or not free software, you may bind
> such as you wish and do what you wish at your home or office, it is
> free software, you can bind keys as you really wish and want.
Well, of course. The only reason I'm using the word "Law" is in
reference to the dichotomy of the "spirit" and the "letter" of some law,
or for our sake guideline. I might just as well have said a "literal
interpretation" or a "interpretation assuming indent".
--
Philip K.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]
^ permalink raw reply [relevance 99%]
* Re: Current mode command discovery
@ 2021-02-14 21:20 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-02-14 21:20 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Óscar Fuentes, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]
Alan Mackenzie <acm@muc.de> writes:
> Hello, Óscar
>
> On Sun, Feb 14, 2021 at 20:53:18 +0100, Óscar Fuentes wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> >> Now that we have mode markup, should there be a command like `M-x', but
>> >> instead lists only those commands that are specifically relevant to the
>> >> current buffer?
>
>> > Like I said before: instead of removing what seems irrelevant, make
>> > them appear after the relevant parts. Otherwise we will lose
>> > information when we guess wrong (which is an easy mistake to make,
>> > since the assumption that the user always wants only the commands from
>> > the current major mode is not always true).
>
>> That defeats the purpose of the feature, which is showing what is
>> relevant and ignore the rest.
>
>> Listing the irrelevant commands would only serve to confuse and overload
>> the user.
>
> For the way I use M-x, I absolutely need what you call "irrelevant"
> commands. Suggesting that these "confuse and overload" me is not a nice
> thing to do.
What might be interesting is to filter out commands that have to be used
with a certain major or minor mode. E.g. do python-mode commands have
to be shown when I'm in a c-mode buffer?
--
Philip K.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]
^ permalink raw reply [relevance 99%]
* Infrastructure for packages to suggest customizations
@ 2021-02-16 1:12 34% Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-02-16 1:12 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 2141 bytes --]
Hi,
in the recent discussion on reserving a keymap for packages, I proposed
extending package.el to support a sort of formal specification of what a
user should or could customize. As there were some supportive comments,
I attempted to improve on an earlier proof-of-concept[0], resulting in
the attached patch.
This introduces the following changes:
- User option `package-query-suggestions', to enable or disable these
suggestions. I have disabled this feature by default, because it might
be annoying. It is probably better for template-configurations or a
theme to enable it.
- Variable pacakge-configuration-suggestions, that packages add their
suggestions to. Here's an example how this could look like for avy:
;;;###autoload
(add-to-list 'pacakge-configuration-suggestions
`(avy (key "Avy's entry-point are commands like avy-goto-char\
that have to be bound globally"
,(kbd "C-:")
avy-goto-char)))
Beside keys, one can currently also specify options and hook. It might
be worth distinguishing between options and global minor-modes.
- Function package-suggest-configuration, that generates the
configuration. It is automatically called by package-install, but can
also be invoked manually.
There are a few things I am not satisfied with, such as that the default
behaviour for package-suggest-configuration is to just append the
generated configuration to `custom-file' or `user-init-file'. Part of my
intention was to generate code that can easily be changed and adapted by
the user (unlike custom-set-variables), so I don't analyse the files
themselves. This might not look nice in some cases, but then again,
these people are probably not the ones using this feature
Another point is that package-suggest-configuration has an option such
that the command will not change anything (PREVIEW, activated with a
prefix argument). I was wondering if it would make sense to make this
the default behaviour whenever the command is invoked interactively.
[0] https://lists.gnu.org/archive/html/help-gnu-emacs/2021-02/msg00305.html
Interested in your comments,
Philip K.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-Add-package-suggest-configuration.patch --]
[-- Type: text/x-patch, Size: 9642 bytes --]
From 4d6737ac59b3d9319a8d94b45ab514d92bd771e4 Mon Sep 17 00:00:00 2001
From: Philip K <philipk@posteo.net>
Date: Thu, 11 Feb 2021 16:30:09 +0100
Subject: [PATCH] Add package-suggest-configuration
---
lisp/emacs-lisp/package.el | 154 +++++++++++++++++++++++++++++++++----
1 file changed, 140 insertions(+), 14 deletions(-)
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 90b7b88d58..a7c957dccd 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -146,7 +146,9 @@
(require 'cl-lib)
(eval-when-compile (require 'subr-x))
(eval-when-compile (require 'epg)) ;For setf accessors.
+(eval-when-compile (require 'pcase))
(require 'seq)
+(require 'rmc)
(require 'tabulated-list)
(require 'macroexp)
@@ -424,6 +426,13 @@ package-archive-column-width
:type 'number
:version "28.1")
+(defcustom package-query-suggestions nil
+ "How to treat configuration suggestions by packages.
+If non-nil, ask the user if they are interested in what a package
+has to suggest. Otherwise ignore the suggestions."
+ :type 'boolean
+ :version "28.1")
+
\f
;;; `package-desc' object definition
;; This is the struct used internally to represent packages.
@@ -2087,6 +2096,135 @@ package--archives-initialize
(unless package-archive-contents
(package-refresh-contents)))
+(defvar pacakge-configuration-suggestions nil
+ "An alist of advertised default configuration.
+Each entry has the form (PACKAGE . SUGGESTIONS), where PACAKGE is a
+symbol designating the package, and SUGGESTIONS is another alist.
+SUGGESTIONS have the form (TYPE EXPLAIN . DATA), where TYPE says
+what kind of a suggestion is being made, EXPLAIN is a string that
+legitimatises the suggestion and DATA is the content of the
+suggestion. Currently, the following values for TYPE are
+understood:
+
+- `key', where DATA has the form (KEY FUNCTION). It suggests
+ binding FUNCTION globally to KEY, unless KEY is already bound.
+ KEY is passed to the function `kbd'.
+
+- `option', where DATA has the form (OPT VAL). It setting the
+ symbol OPT to the value VAL.
+
+- `hook', where DATA has the form (HOOK FUNCTION). It suggests
+ adding FUNCTION to the hook HOOK.
+
+All other values for TYPE are ignored.")
+
+(defun package--query-name (&optional kind verb)
+ "Query the user for a package name.
+If KIND is nil, prompt for all kinds of packages. If KIND is
+`installed' only prompt for installed packages. If KIND is
+`not-installed', only prompt for packages that have not been
+installed. VERB modified to prompt."
+ ;; Initialize the package system to get the list of package
+ ;; symbols for completion.
+ (package--archives-initialize)
+ (intern (completing-read
+ (format "%s package: " (or verb "Select"))
+ (delq nil (mapcar (lambda (elt)
+ (when (cond
+ ((eq kind 'installed)
+ (package-installed-p (car elt)))
+ ((eq kind 'not-installed)
+ (not (package-installed-p (car elt))))
+ ((null kind))
+ (t (error "Invalid kind")))
+ (symbol-name (car elt))))
+ package-archive-contents))
+ nil t)))
+
+(defun package--show-explanation (doc)
+ "Show explanation DOC in a help buffer."
+ (ignore-errors (kill-buffer "*explain*"))
+ (with-current-buffer (get-buffer-create "*explain*")
+ (erase-buffer)
+ (with-help-window (current-buffer)
+ (princ (substitute-command-keys doc)))))
+
+(defun package-suggest-configuration (package &optional preview)
+ "Query the user to automatically configure PACKAGE.
+If PREVIEW is non-nil, do not save and load the new
+customization."
+ (interactive (list (package--query-name 'installed) current-prefix-arg))
+ (when (or (called-interactively-p 'any) package-query-suggestions)
+ (with-temp-buffer
+ (let ((standard-output (current-buffer)))
+ (unless (cdr (assq package pacakge-configuration-suggestions))
+ (message "Nothing to configure."))
+ (dolist (sug (cdr (assq package pacakge-configuration-suggestions)))
+ (terpri nil t)
+ (save-window-excursion ;restore explain buffers
+ (pcase sug
+ (`(key ,explain ,key ,command)
+ (unless (or (where-is-internal command) (key-binding key))
+ (let ((key (cl-loop
+ for ch = (read-multiple-choice
+ (format "%s suggests binding `%s' to %s. Do you want to bind it? "
+ package command (key-description key))
+ '((?y "yes" "Bind command to the suggested key")
+ (?n "no" "Ignore the suggestion")
+ (?e "explain" "Ask the package why is suggests this")
+ (?o "other" "Bind key to a different key")))
+ when (eq (car ch) ?y) return key
+ when (eq (car ch) ?n) return nil
+ when (eq (car ch) ?e) do (package--show-explanation explain)
+ when (eq (car ch) ?o) do
+ (let* ((alt (read-key-sequence "Bind to: " ))
+ (bound (key-binding alt)))
+ (if (not bound)
+ (cl-return alt)
+ (message "%s is already bound to %s"
+ (key-description alt)
+ (key-binding alt))
+ (sit-for 2))))))
+ (when key
+ (prin1 `(global-set-key
+ (kbd ,(key-description key))
+ #',command))))))
+ (`(option ,explain ,option ,value)
+ (when (cl-loop
+ for ch = (read-multiple-choice
+ (format "%s suggests setting the option `%s' to %s. Do you want to set it? "
+ package option value)
+ '((?y "yes" "Set the option")
+ (?n "no" "Ignore the suggestion")
+ (?e "explain" "Ask the package why is suggests this")))
+ when (eq (car ch) ?y) return t
+ when (eq (car ch) ?n) return nil
+ when (eq (car ch) ?e) do (package--show-explanation explain))
+ (prin1 `(customize-set-variable ',option ,value))))
+ (`(hook ,explain ,hook ,function)
+ (when (cl-loop
+ for ch = (read-multiple-choice
+ (format "%s suggests adding `%s' to %s. Do you want to add it? "
+ package function hook)
+ '((?y "yes" "Add to hook")
+ (?n "no" "Ignore the suggestion")
+ (?e "explain" "Ask the package why is suggests this")))
+ when (eq (car ch) ?y) return t
+ when (eq (car ch) ?n) return nil
+ when (eq (car ch) ?e) do (package--show-explanation explain))
+ (prin1 `(add-hook ',hook #',function)))))))
+ (when (/= (point-min) (point-max))
+ (if preview
+ (let ((buf (get-buffer-create (format "*suggested configuration for %s*"
+ package))))
+ (with-current-buffer buf
+ (emacs-lisp-mode))
+ (copy-to-buffer buf (point-min) (point-max))
+ (pop-to-buffer buf))
+ (eval-buffer)
+ (append-to-file (point-min) (point-max)
+ (or custom-file user-init-file))))))))
+
;;;###autoload
(defun package-install (pkg &optional dont-select)
"Install the package PKG.
@@ -2103,20 +2241,7 @@ package-install
If PKG is a `package-desc' and it is already installed, don't try
to install it but still mark it as selected."
- (interactive
- (progn
- ;; Initialize the package system to get the list of package
- ;; symbols for completion.
- (package--archives-initialize)
- (list (intern (completing-read
- "Install package: "
- (delq nil
- (mapcar (lambda (elt)
- (unless (package-installed-p (car elt))
- (symbol-name (car elt))))
- package-archive-contents))
- nil t))
- nil)))
+ (interactive (list (package--query-name 'not-installed "Install")))
(package--archives-initialize)
(add-hook 'post-command-hook #'package-menu--post-refresh)
(let ((name (if (package-desc-p pkg)
@@ -2134,6 +2259,7 @@ package-install
(progn
(package-download-transaction transaction)
(package--quickstart-maybe-refresh)
+ (with-local-quit (package-suggest-configuration pkg))
(message "Package `%s' installed." name))
(message "`%s' is already installed" name))))
--
2.29.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]
^ permalink raw reply related [relevance 34%]
* Re: Infrastructure for packages to suggest customizations
@ 2021-02-16 11:18 87% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-02-16 11:18 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> in the recent discussion on reserving a keymap for packages, I proposed
>> extending package.el to support a sort of formal specification of what a
>> user should or could customize. As there were some supportive comments,
>> I attempted to improve on an earlier proof-of-concept[0], resulting in
>> the attached patch.
>
> Thanks. Could we "simply" make it a Custom group?
> For keys I'd imagine something like
>
> (defcustom avy-global-goto-key nil
> :group 'suggestions
> :type 'key-sequence
> :options '("C-:")
> :set (lambda (symbol value)
> (if value (global-set-key value 'avy-goto-char))))
>
>> Part of my intention was to generate code that can easily be changed
>> and adapted by the user (unlike custom-set-variables), so I don't
>> analyse the files themselves. This might not look nice in some cases,
>> but then again, these people are probably not the ones using this
>> feature
>
> I don't understand what you mean to say here, sorry.
No, it's my mistake, I'll try to rephrase it:
The suggestion you've made above was also something I considered:
Relying on the customize system makes it easier to implement the
functionality but it at the same time hides it behind the complexity of
customize. So while the absolute beginner wouldn't notice or care, the
next step of a beginner might be confused how the keys were bound, and
how to change it.
That is why the patch generates "real" configuration code, not "hiding"
what is going on, but demonstrating what and how changing your Emacs is
done.
The downside to this is that because there is no interface like
customize, it can't just find and replace a previous global-set-key,
because that would require modifying regular code in a user
configuration, that might not even be in .emacs or init.el.
Hope that clarifies the intention.
> Stefan
>
--
Philip K.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]
^ permalink raw reply [relevance 87%]
* Re: goto-line-history should not be buffer local.
@ 2021-02-18 10:53 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-02-18 10:53 UTC (permalink / raw)
To: Rolf Ade; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
Rolf Ade <rolf@pointsman.de> writes:
> Matt Armstrong <matt@rfc20.org> writes:
>>
>> Who are the people who would set the option back to buffer local
>> history?
>
> I will do. (Would prefer it's the default.)
Seconding this.
> What meaning have a certain line number from one buffer in another
> buffer?
One argument was that you might accidentally type M-g M-g in the wrong
buffer, and would want to easily switch the buffer and repeat the last
goto-line request.
--
Philip K.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]
^ permalink raw reply [relevance 99%]
* Re: Add project-name function
@ 2021-03-06 14:10 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-03-06 14:10 UTC (permalink / raw)
To: Ivan Sokolov; +Cc: emacs-devel
Ivan Sokolov <ivan-p-sokolov@ya.ru> writes:
> I hope I am doing everything right, this is my first patch for Emacs.
>
> From 0aa1b0417f2fd4f8fdef24194c55304611711cfa Mon Sep 17 00:00:00 2001
> From: Ivan Sokolov <ivan-p-sokolov@ya.ru>
> Date: Sat, 6 Mar 2021 01:43:30 +0300
> Subject: [PATCH] lisp/progmodes/project.el: Add 'project-name'
>
> ---
> lisp/progmodes/project.el | 23 +++++++++++++----------
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index abe563bec0..3abae8606f 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -888,6 +888,13 @@ PREDICATE, HIST, and DEFAULT have the same meaning as in
> (interactive)
> (vc-dir (project-root (project-current t))))
>
> +;;;###autoload
> +(defun project-name (project)
> + "Return PROJECT's name."
Without reading the rest of the code, I wasn't sure what a project's
name is. I think the docstring should explain that it just takes the
basename of the root directory.
It might be worth considering turning this into a method, in case a
project knows a better name.
> + (file-name-nondirectory
> + (directory-file-name
> + (project-root project))))
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] A Setup package
2021-02-09 23:42 71% ` Philip K.
@ 2021-03-11 16:17 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-03-11 16:17 UTC (permalink / raw)
To: emacs-devel; +Cc: Stefan Monnier
"Philip K." <philipk@posteo.net> writes:
I think all the issues should now be resolved. I just pushed a commit
adding edebug support. setup-help was moved into setup's docstring, a
lot of the macros were redefined to look more like setq, and all macros
were redefined to use keywords (for now).
The source code can be found here:
https://git.sr.ht/~zge/setup/tree/master/item/setup.el
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] A Setup package
@ 2021-03-13 19:44 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-03-13 19:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I think all the issues should now be resolved. I just pushed a commit
>> adding edebug support. setup-help was moved into setup's docstring, a
>> lot of the macros were redefined to look more like setq, and all macros
>> were redefined to use keywords (for now).
>
> [ I have some further suggestions for the code, but they'll come later. ]
>
> I was about to add it to GNU ELPA, but I noticed two problems:
>
> 1- The file is missing a copyright notice and it is using the CC0 license.
> See the patch below to fix those issues (the copyright part reflects
> the fact that you consider the package as being covered by your
> copyright assignment and the license change is because we want to
> distribute all GNU ELPA packages under the GPLv3 license; you're of
> course perfectly free to also distribute this package under any other
> license you want, but we want to use the GPLv3 for the copy we
> distribute).
Done.
> 2- AFAIK you rebased (or force-pushed or something like that) your
> branch, which makes it painful for any"one" tracking your branch, such
> as elpa.git. In order for the elpa.git branch tracking your
> SourceHut repository to work sanely it'll be important not to rebase
> (or force-push...) in the future.
I actually created a new repository, because it seemed cleaner compared
to pushing all the changes as commits. But I will keep this in mind for
the future.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] A Setup package
@ 2021-03-14 16:21 90% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-03-14 16:21 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> OK, we now have:
>
> http://elpa.gnu.org/devel/setup.html
Thank you!
> We don't yet have http://elpa.gnu.org/packages/setup.html OTOH because
> the 0.1.0 version of the code is missing the copyright changes (the
> release is made from the commit in which you bump the version number).
> So if you want to make a release based on this code, you'll want to bump
> up the version number.
What exactly is missing? My understanding was that I had to update the
header and the COPYING file.
> Here's some other suggestions.
I like most of the suggestions, would you mind me committing them with
you as the author?
> Obviously the use of `help--make-usage` is problematic since the `--`
> indicates it's not supposed to be used by "outsiders", so we should
> change help.el or help-fns.el to provide a proper function for that
> (pcase uses `help-fns--signature` instead, which suffers from the same
> problem).
Why use help--make-usage at all? Something along the same lines could
be simplified (eg. without default values and unused variables) and
directly implemented in setup.
> (let (specs)
> (dolist (name (mapcar #'car setup-macros))
> (let ((body (cond ((eq (get name 'setup-debug) 'none) nil)
> ((get name 'setup-debug) nil)
> ('(sexp)))))
> - (push (if (get name 'setup-repeatable)
> + (push (if (plist-get opts :repeatable)
This doesn't work! The specification is regenerated for every
setup-define call, and if the implicit rest uses opts, all macros will
be treated the same way.
It might be better to save the specification in a separate variable and
modify this destructively for every setup-define call, so as to avoid
the overhead of redefining the entire specification all the time.
--
Philip K.
^ permalink raw reply [relevance 90%]
* Re: [ELPA] A Setup package
@ 2021-03-14 23:39 95% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-03-14 23:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> We don't yet have http://elpa.gnu.org/packages/setup.html OTOH because
>>> the 0.1.0 version of the code is missing the copyright changes (the
>>> release is made from the commit in which you bump the version number).
>>> So if you want to make a release based on this code, you'll want to bump
>>> up the version number.
>> What exactly is missing?
>
> You missed this part:
>
> (the release is made from the commit in which you bump the version
> number)
>
> the commit in which you changed `Version:` to the current 0.1.0 did not
> have a "copyright FSF" line.
Oops, my bad. I get it now.
>> Why use help--make-usage at all?
>
> To avoid reinvent the wheel.
I could reduce it to
(mapcar (lambda (arg)
(if (string-match "\\`&" (symbol-name arg))
arg
(intern (upcase (symbol-name arg)))))
(get sym 'setup-signature))
which does the job.
>> It might be better to save the specification in a separate variable and
>> modify this destructively for every setup-define call, so as to avoid
>> the overhead of redefining the entire specification all the time.
>
> I wouldn't bother, no. In the patch below I instead did the
> spec-processing when setting `setup-debug` (and I also dropped the
> `none` support because I don't see what it gains: for a macro that
> takes no arguments, `&rest sexp` works as well).
> And there is a better option for Emacs-28 and after.
The reason I introduced `none` was that :hide-mode is not repeatable and
has no arguments, resulting in the edebug specification
(":hide-mode" sexp)
However this always fails to match. I am thinking about solving this by
checking for a non-nil signature. The only thing I'm not yet sure of if
this could have unintended side effects.
--
Philip K.
^ permalink raw reply [relevance 95%]
* Re: [ELPA] A Setup package
@ 2021-03-15 10:09 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-03-15 10:09 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> Why use help--make-usage at all?
>>> To avoid reinvent the wheel.
>> I could reduce it to
>>
>> (mapcar (lambda (arg)
>> (if (string-match "\\`&" (symbol-name arg))
>> arg
>> (intern (upcase (symbol-name arg)))))
>> (get sym 'setup-signature))
>>
>> which does the job.
>
> Sounds good (but it still shows there's a need for Emacs to provide
> a function that does that).
Yes, this is just a temporary compromise.
>> The reason I introduced `none` was that :hide-mode is not repeatable and
>> has no arguments, resulting in the edebug specification
>>
>> (":hide-mode" sexp)
>>
>> However this always fails to match.
>
> Indeed that was wrong. Same problem for non-repeatable macros with more
> than one argument. But in the code I sent in the last message I fixed
> this by always using `&rest sexp` for those Setup macros without debug
> spec (just like Edebug for normal macros).
I've ended up doing something similar now, just also taking :repeatable
into consideration. Either way, I with this working, I'll bump the
version to 0.1.1, to create an official release.
Thank you for all you help, your comments significantly improved the
package!
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Suggested experimental test
@ 2021-03-22 11:37 98% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-03-22 11:37 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Eli Zaretskii, ams, emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
> M-n and M-p: were initially unused, became what they are now in Emacs 17
M-n and M-p are still unused? Or did the convention
A major mode can also rebind the keys ‘M-n’, ‘M-p’ and ‘M-s’. The
bindings for ‘M-n’ and ‘M-p’ should normally be some kind of moving
forward and backward, but this does not necessarily mean cursor
motion.
(elisp) Major Mode Conventions
not exist before Emacs 17?
--
Philip K.
^ permalink raw reply [relevance 98%]
* Re: Suggested experimental test
@ 2021-03-23 12:28 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-03-23 12:28 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Jean Louis, emacs-devel, gregory, stefankangas, dgutov, larsi
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Tue, 23 Mar 2021 08:22:19 +0300
>> From: Jean Louis <bugs@gnu.support>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, gregory@heytings.org,
>> Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefankangas@gmail.com>,
>> emacs-devel@gnu.org
>>
>> That way experiments go in parallel not disturbing the default key
>> bindings and users aware or willing to participate may do so.
>
> That just delays the dispute to the point when we want to consider
> making some of the bindings the default. So it basically may solve a
> secondary problem -- how to conduct the experiment -- but not the main
> problem, which is whether and how to change bindings that existed in
> Emacs since about forever.
Forgive me for asking, maybe I'm missing something, but why should the
changes be made default?
Isn't the idea of providing a theme to change the behaviour that users
can enable or disable them easily, without the defaults having to change?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Suggested experimental test
@ 2021-03-23 13:27 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-03-23 13:27 UTC (permalink / raw)
To: Dmitry Gutov
Cc: bugs, emacs-devel, gregory, stefankangas, Eli Zaretskii, larsi
Dmitry Gutov <dgutov@yandex.ru> writes:
> On 23.03.2021 14:41, Eli Zaretskii wrote:
>> But eventually, the intent is to change the default behavior, because
>> rebinding any key to any command is already possible, and nothing
>> prevents users from doing that in their private init files. So
>> having a non-default theme that makes a bunch of such rebindings
>> makes little sense to me.
>
> I think the above is more important than the goal of making it a
> default (which might or might not happen in 10 years or so, if we end
> up reaching some critical mass of users who dislike Emacs's historical
> bindings).
>
> But even while the alternative keybindings theme is not the default,
> we would maintain it and keep it usable. Whenever we add something to
> the default set, we would consider adding a corresponding binding to
> that other theme, etc.
You mean new default commands, right?
> Having an alternative, well-considered set of bindings which new user
> can just toggle on and get comfortable should be valuable.
Yes, this was my understanding too. Ideally, the splash screen could
instruct new users how to change the UX theme, making it easier to get
comfortable.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Simple isearch concerns
@ 2021-04-03 11:28 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-03 11:28 UTC (permalink / raw)
To: Manuel Uberti; +Cc: emacs-devel
Manuel Uberti <manuel.uberti@inventati.org> writes:
> On 03/04/21 02:15, Ergus wrote:
>> Are there any WIP related?
>
> Along with the package mentioned by Thierry there is CTRLF[1].
I tried this package a few months ago, but still do not understand what
it does differently from isearch.
> [1] https://github.com/raxod502/ctrlf
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [GNU ELPA] New package proposal: aggressive-completion.el
@ 2021-04-03 11:53 92% ` Philip Kaludercic
2021-04-03 11:55 92% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-03 11:53 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Just tried out the package, and it seems to work very well! I just have
two annoyances:
1. Where there are too many options, lag is noticeable (eg. with C-h o).
2. The completion buffer keeps appearing and disappearing, shrinking and
growing.
The first would probably just be fixed by not auto-completing under a
certain number of characters like icomplete.
The second point isn't directly related to aggressive-completion, but
maybe it could provide a user-option to avoid the issue, seeing that it
is more noticeable when the completion buffer is automatically changing.
I tried setting window-min-height and temp-buffer-max-height (and
temp-buffer-resize-mode) to the same value, but that limits all windows.
--
Philip K.
^ permalink raw reply [relevance 92%]
* Re: [GNU ELPA] New package proposal: aggressive-completion.el
2021-04-03 11:53 92% ` Philip Kaludercic
@ 2021-04-03 11:55 92% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-03 11:55 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Just tried out the package, and it seems to work very well! I just have
two annoyances:
1. Where there are too many options, lag is noticeable (eg. with C-h o).
2. The completion buffer keeps appearing and disappearing, shrinking and
growing.
The first would probably just be fixed by not auto-completing under a
certain number of characters like icomplete.
The second point isn't directly related to aggressive-completion, but
maybe it could provide a user-option to avoid the issue, seeing that it
is more noticeable when the completion buffer is automatically changing.
I tried setting window-min-height and temp-buffer-max-height (and
temp-buffer-resize-mode) to the same value, but that limits all windows.
--
Philip K.
^ permalink raw reply [relevance 92%]
* Re: Simple isearch concerns
@ 2021-04-03 16:37 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-03 16:37 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Manuel Uberti, emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
>>> Along with the package mentioned by Thierry there is CTRLF[1].
>>>
>>> [1] https://github.com/raxod502/ctrlf
>>
>> I tried this package a few months ago, but still do not understand
>> what it does differently from isearch.
>>
>
> This is explained on [1]. I'm not sure I understand all arguments,
> but what I understood is:
I too have read the README and have installed the package, but even
then, I cannot really notice any specific difference. Something *feels*
different, but I cannot pinpoint what it is.
I am probably used to isearch on some more intuitive than conscious
level to really say what the difference is.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [GNU ELPA] New package proposal: aggressive-completion.El
@ 2021-04-03 17:22 87% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-03 17:22 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>> Just tried out the package, and it seems to work very well! I just
>> have two annoyances:
>>
>> 1. Where there are too many options, lag is noticeable (eg. with C-h o).
>
> There's a knob for that: `aggressive-completion-max-shown-completions'.
Sadly it still persists. All in all it is barley noticeable, and it only
affects the first letter in my case. Maybe you can replicate it:
C-h o
a
[wait]
on my system there is about half a second of lag between typing a and a
appearing on the screen. If I typo more letter, they are all delayed by
half a second.
>> 2. The completion buffer keeps appearing and disappearing, shrinking
>> and growing.
>
> The *Completions* buffer should appear as soon as there is at least one
> and at most `aggressive-completion-max-shown-completions' completions,
> and it'll disappear when completion selected a unique match. Do you see
> something different?
No, but if I remove a word and the completion is not unique any more, the
buffer re-appears.
> Wrt. the resizing: that's the standard completion help behavior you'd
> also see when double-TAB-ing during completion. Not sure if there's a
> way to restrict that window's height.
Yes, but my point was that the change in window height is in response to
a manual completion request. This might just be me, but I try to avoid
"undeterministic" behaviour, or at least effects that I cannot infer
from my actions. I cannot say for sure, but I think that if you could
force the completion buffer to stay at one place during the entire
completion, this would be preferable.
> Bye,
> Tassilo
>
>
--
Philip K.
^ permalink raw reply [relevance 87%]
* Re: Simple isearch concerns
@ 2021-04-03 18:36 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-03 18:36 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Manuel Uberti, emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
>>>>> Along with the package mentioned by Thierry there is CTRLF[1].
>>>>>
>>>>> [1] https://github.com/raxod502/ctrlf
>>>>
>>>> I tried this package a few months ago, but still do not understand
>>>> what it does differently from isearch.
>>>
>>> This is explained on [1]. I'm not sure I understand all arguments,
>>> but what I understood is:
>>
>> I too have read the README and have installed the package, but even
>> then, I cannot really notice any specific difference. Something
>> *feels* different, but I cannot pinpoint what it is.
>>
>
> You may have seen that what followed the above sentence were some
> concrete examples of these differences.
I tried all of them, but without paying attention, I wouldn't notice if
I'm using isearch or ctrlf (except for the N/M overlay).
Either way, it is not that important.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-05 20:49 66% ` Philip Kaludercic
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Philip Kaludercic @ 2021-04-05 20:49 UTC (permalink / raw)
To: T.V Raman; +Cc: Manuel Uberti, emacs-devel
I guess I can bring up a point I've been meaning to raise here for a
while, and have discussed on other forums.
> 1. Where invoked -- anywhere in emacs vs minibuffer.
> 2. When invoked -- as in find-file and friends vs everywhere
> something prompts in the minibuffer.
> 3. Using what? the various backends that populate the available
> choices.
> 4. How displayed: How the choices are displayed -- horizontal,
> vertical, and perhaps 3-d in the future.
> 5. How completed: tab, vs prefix vs fuzzy completion vs ...
I have the feeling all these completion systems are encouraging
confusion around how to use completing-read. That is the 0th point that
is missing here: Are you completing (expanding text) or selecting
(narrowing options).
Most completion frameworks I have looked at seem to limit themselves to
the latter. To simplify, they collect all the options of a collection
using all-completions and then narrow it depending on user input. Ido
and all it's descendents (Ivy, Helm, Selectrum and now vertico) seem to
be based on that approach.
Try-completion for partial completion seems to only be used by the
default completion system, which I think is a shame. I noticed this when
implementing a completion-style based on Peter Norvig's spell
checker[0], that would recognize minor typos such as M-x
evla-buffer. IIRC this kind of behaviour is not strictly correct for a
completing style, but that is another matter.
The issue I see here is how packages (in and outside of Emacs) use
completing-read. When package developers that use these newer completion
frameworks test their functions, they might tend to assume that
completing-read means "selecting-read", i.e. the user is presented a
list of options that they can choose from. A personal example is a
package I created a while back to insert eastern emoticons[1]
(¯\_(ツ)_/¯, ´ ▽ ` )ﾉ, Σ ◕ ◡ ◕, ...), that was convenient to use with
Ivy but since I have stopped using it has become inconvenient, as I
don't have most of the letters on my keyboard to complete such an
emoticon.
Nevertheless completing-read seems to have satisfied an existing need
for a simple mechanism to implement selection. There are packages in
Emacs that do this, but they all have to re-implement selection
interfaces, as there is no default way of doing it (that I know
of). Think of recentf's menu or more complex examples such as reftex's
TOC, that includes hierarchical structures.
It might therefore be necessary to actually implement a "selecting-read"
function, that could be used more or less like completing-read, but that
provides a better default UI not based around completing text but
actually selecting objects/items.
[0] https://norvig.com/spell-correct.html
[1] https://git.sr.ht/~zge/kaomoji
--
Philip K.
^ permalink raw reply [relevance 66%]
* Re: [PATCH] icomplete-vertical
@ 2021-04-05 23:04 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-05 23:04 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
> +;;;###autoload
> +(define-minor-mode icomplete-vertical-mode
> + "Toggle incremental minibuffer completion with vertical display.
> +
> +This global minor mode is identical to `icomplete-mode' (which see),
> +except that it displays the list of completions candidates vertically.
> +
> +As many completion candidates as possible are displayed, depending on
> +the value of `max-mini-window-height'."
> + :global t :group 'icomplete
> + (remove-hook 'icomplete-minibuffer-setup-hook
> + #'icomplete-vertical-minibuffer-setup)
> + (advice-remove 'icomplete-completions
> + #'icomplete-vertical-reformat-completions)
> + (icomplete-mode -1)
> + (when icomplete-vertical-mode
> + (icomplete-mode 1)
> + (setq icomplete-separator "\n")
> + (setq icomplete-hide-common-prefix nil)
> + ;; ask `icomplete-completions' to return enough completions candidates
> + (setq icomplete-prospects-height 25)
> + (add-hook 'icomplete-minibuffer-setup-hook
> + #'icomplete-vertical-minibuffer-setup)
> + (advice-add 'icomplete-completions
> + :filter-return #'icomplete-vertical-reformat-completions)))
> +
Why is this a patch that uses advice and hook instead of a user option
that changes the behaviour of icomplete directly?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] icomplete-vertical
@ 2021-04-06 8:54 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-06 8:54 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Eli Zaretskii, emacs-devel
Sorry for bringing this up again, but I still don't get why this is a
minor mode from a user perspective. Vertical or horizontal doesn't sound
like something that should be a (global) mode, but a regular
option. Wasn't there a patch or a branch that tried to implement it that
way?
(And yes I know that every minor mode is a user option)
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] icomplete-vertical
@ 2021-04-06 9:30 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-06 9:30 UTC (permalink / raw)
To: Gregory Heytings; +Cc: Eli Zaretskii, emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
> Do you really think it is better to ask users to set five options in
> their init file (icomplete-separator, icomplete-hide-common-prefix,
> icomplete-prospects-height, icomplete-minibuffer-setup-hook and
> icomplete-completions-filter-hook) instead of providing them right
> away with what they want with (icomplete-vertical-mode 1)?
No, I think it would be better to have one user option like
icomplete-presentation set to 'vertical or something like that.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] icomplete-vertical
@ 2021-04-06 15:17 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-06 15:17 UTC (permalink / raw)
To: Ergus; +Cc: Gregory Heytings, Eli Zaretskii, Stefan Monnier, emacs-devel
Ergus <spacibba@aol.com> writes:
> The use case I had in mind was exactly that. Because I was working on
> icomplete-vertical, icomplete-tabular, and some others that in general
> just require minimal differences between each other.
What would icomplete-tabular have looked like?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-07 14:15 69% ` Philip Kaludercic
[not found] ` <87eefm5fzl.fsf@posteo.net>
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Philip Kaludercic @ 2021-04-07 14:15 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
>> I have the feeling all these completion systems are encouraging
>> confusion around how to use completing-read. That is the 0th point
>> that is missing here: Are you completing (expanding text) or
>> selecting (narrowing options).
>>
>
> I've been thinking about this, and I'm not sure I understand what the
> real difference between "completing" and "selecting" is. Do I
> understand correctly that the difference is between, for example,
> expanding command names (completing), and choosing an emoji in a list
> (selecting)?
I think the main difference is in the UI. The default completion UI for
Emacs will expand text in-place. M-x tdoe <TAB> becomes
toggle-debug-on-error, with the initials style. This appears to make
sense for well structured text, such as commands or files.
Selection are probably situations where you want more visual feedback,
and it would make sense to present a list/tree by default. I don't think
that this has to be strictly about text.
Generally speaking, you can complete the textual representation of
anything or select the object themselves. I don't think that either is
always better, but I think we can do better than selecting textual
representations.
>> It might therefore be necessary to actually implement a
>> "selecting-read" function, that could be used more or less like
>> completing-read, but that provides a better default UI not based
>> around completing text but actually selecting objects/items.
>>
>
> Given that Emacs is primarily keyboard-driven, it seems to me that the
> most efficient way to select an item is, and will always be, to use a
> textual representation of the items in the list to select them. C-x 8
> RET does this, you (can) select an unicode character with its name.
> For example C-x 8 RET inf RET inserts the infinity symbol. Or course
> you could also navigate through the ~45000 unicode characters to
> select the one you want, but that would be far less efficient.
I don't think that something like selecting-read should just present a
list of string. One might imagine using methods to allow an extensible
way to control the presentation. Currently the standard procedure is to
generate a collection and it's labels before passing it to
completing-read. That's what insert-char does using ucs-names. I could
imagine that selecting-read takes a list of characters, and uses a
method to generate the textual representation of every entry. Ideally it
could lazily only calculate those entries that are currently being
displayed.
By not limiting yourself to precomputed text, the interaction can also
be improved. Taking insert-char as an example again, you might be
interested in the kind of character data that C-u C-x = provides. That
might just be a tab away. You might also be able to filter more
effectively, by narrowing the selection based on such properties.
I think I've also mentioned that selection can be hierarchical. I think
this too would be applicable to insert-char, considering how unicode
divided into groups and subgroups.
All of these features already exist, partially or only to the degree it
is found to be necessary. Eg. ibuffer has hierarchies and the ability to
filter by some preconfigured predicates. I think that there is a general
pattern here that can be exploited to make the overall experience more
uniform.
--
Philip K.
^ permalink raw reply [relevance 69%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
[not found] ` <3ec7e2e58a106c77370d@heytings.org>
@ 2021-04-07 14:33 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-07 14:33 UTC (permalink / raw)
To: Gregory Heytings
Gregory Heytings <gregory@heytings.org> writes:
> Note that you Cc'd "emacs-develo@gnu.org" instead of
> "emacs-devel@gnu.org".
Oh, I was wondering why my mail server kept rejecting the message. Sorry
about that.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-07 14:55 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-07 14:55 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Manuel Uberti, T.V Raman, emacs-devel, Dmitry Gutov
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Most completion frameworks I have looked at seem to limit themselves to
>>> the latter. To simplify, they collect all the options of a collection
>>> using all-completions and then narrow it depending on user input. Ido
>>> and all it's descendents (Ivy, Helm, Selectrum and now vertico) seem to
>>> be based on that approach.
>> I don't think that's true.
>
> I don't think the frequency of refreshing the list of candidates is what
> he was referring to, but rather the support for "TAB completion" which
> corresponds to the `(completion-)try-completion` operation which is
> expected to extract the commonality between the various candidates.
Just to confirm the point, yes, this was what I was referring
to.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-07 16:10 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-07 16:10 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
>>> I've been thinking about this, and I'm not sure I understand what
>>> the real difference between "completing" and "selecting" is. Do I
>>> understand correctly that the difference is between, for example,
>>> expanding command names (completing), and choosing an emoji in a
>>> list (selecting)?
>>
>> I think the main difference is in the UI. The default completion UI
>> for Emacs will expand text in-place. M-x tdoe <TAB> becomes
>> toggle-debug-on-error, with the initials style. This appears to make
>> sense for well structured text, such as commands or files.
>>
>> Selection are probably situations where you want more visual
>> feedback, and it would make sense to present a list/tree by
>> default. I don't think that this has to be strictly about text.
>>
>> Generally speaking, you can complete the textual representation of
>> anything or select the object themselves. I don't think that either
>> is always better, but I think we can do better than selecting
>> textual representations.
>>
>
> Okay, I think I understand your viewpoint (a bit) better now. But:
>
> 1. It seems to me that the UI you have in mind is closer to
> 'transient' than to 'completing-read'.
Perhaps, but my understanding of transient is that it tries to be a
better C-u.
> 2. That UI already exists to some extent in Emacs, for example dired,
> imenu (either in the menu bar or bound to a mouse event), ibuffer, the
> speedbar, ...
How is this a "but"?
> 3. Such a UI probably wouln't fit in the (by definition) limited space
> of a minibuffer.
I think so, I don't think that it should have to.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-07 16:20 84% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-07 16:20 UTC (permalink / raw)
To: Daniel Mendler; +Cc: emacs-devel
Daniel Mendler <daniel@mendler.net> writes:
> On 4/7/21 4:15 PM, Philip Kaludercic wrote:
>> I think I've also mentioned that selection can be hierarchical. I think
>> this too would be applicable to insert-char, considering how unicode
>> divided into groups and subgroups.
>
> I agree that hierarchical selection can be useful when browsing
> through a structure. However when doing a quick selection, I perceive
> it as slower. For example there is imenu, where you have to step
> through multiple layers of the hierarchy to reach the destination.
Well that is because imenu presents the options in the minibuffer, and
you have to go through the menu step-by-step. What I'm talking about is
a direct hierarchical visualisation, that should be navigable with the
intuitiveness of org-mode.
>> All of these features already exist, partially or only to the degree it
>> is found to be necessary. Eg. ibuffer has hierarchies and the ability to
>> filter by some preconfigured predicates. I think that there is a general
>> pattern here that can be exploited to make the overall experience more
>> uniform.
>
> I wonder how all these use cases could be unified under a common
> API. I would certainly not want to lose the current fast, flat
> selection mechanism via completion as offered by `completing-read'.
I don't think that selecting-read should replace completing-read. Rather
there are cases where completing-read is used like selecting-read, that
would profit from actually being selected by everyone, and not just
those who use completion frameworks that interpret completion as
selection.
> Regarding predicates, there is an idea how this could be integrated
> with completion. One can implement a completion style which support a
> filter language, depending on the completion category. The completion
> style can then execute the filter predicates on the corresponding
> objects. However such an approach certainly takes it a bit far as
> completion styles are concerned. I think Icicles offers options to
> filter within completion based on predicates?
I think there is more value in keeping completing-read simple, and focus
it on actual text expansion. Completing-read will probably never really
be overcome, just because there will always be software that continues
to use it.
In some sense the abundance of solutions around completion show that the
community wants something else than what completing-read provides by
default. I get why, as a lot of packages use completing-read. But it
might be better to start from the position we want to achieve, instead
of hacking our way towards that end.
> Daniel Mendler
>
>
--
Philip K.
^ permalink raw reply [relevance 84%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-07 17:40 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-07 17:40 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
>>> 1. It seems to me that the UI you have in mind is closer to
>>> 'transient' than to 'completing-read'.
>>
>> Perhaps, but my understanding of transient is that it tries to be a
>> better C-u.
>
> By 'transient', I meant the ELPA transient package. My understanding
> is that it makes it possible to navigate through a tree, with a visual
> feedback in a popup buffer.
But transient popups are static, right? You (usually) wouldn't compute
them on the fly. I get what you mean from the UI perspective, I don't
think that transient would be a good basis for something like
selecting-read.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-07 19:13 73% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-07 19:13 UTC (permalink / raw)
To: Daniel Mendler; +Cc: emacs-devel
Daniel Mendler <mail@daniel-mendler.de> writes:
> On 4/7/21 6:20 PM, Philip Kaludercic wrote:
>> Well that is because imenu presents the options in the minibuffer, and
>> you have to go through the menu step-by-step. What I'm talking about is
>> a direct hierarchical visualisation, that should be navigable with the
>> intuitiveness of org-mode.
>
> This is a bit vague. If we have a tree structure one can have some
> tree-like visualization (like the sidebar tree browsers) or have an
> outline like in org-mode. But how would you actually navigate quickly?
> Using Avy-like keys? What if the structure does not fit on the screen
> easily, what if there are cycles, ...?
I'm still thinking about all of this, and have to find the time to
implement a prototype. It might make sense to have a similar approach to
completing-read, where a variable like completing-read-function can
change everything.
A tree-like visualisation would probably make more sense, as long as it
can be manipulated using the keyboard. I mentioned org-mode thinking of
the org-cycle command, and how it allows you to hide and show subtrees.
> In the case of `completing-read` the current solutions are all pretty
> simple. If we ignore the special cases of dynamic completion tables,
> you just hand it this big flat list and filter until the data set
> becomes manageable. While some use cases seem to be a bit pressed into
> that framework (like if you have a hammer...), I think it works
> surprisingly well in many scenarios with a large number of
> unstructured candidates.
I use the default completion system, so for me it is not about filtering
a data set but expanding a string. Just to reiterate, this is exactly
the point I am bringing this up.
> To me it seems much harder to imagine something general which caters
> for all selection needs using an outline-like visualization.
It might be that it is too far fetched, but I have a (vague) idea how
selecting-read might look like and behave. A proper analysis of the
current situation and (imo) misuse of completing-read would probably be
necessary before actually building anything.
>> I don't think that selecting-read should replace completing-read. Rather
>> there are cases where completing-read is used like selecting-read, that
>> would profit from actually being selected by everyone, and not just
>> those who use completion frameworks that interpret completion as
>> selection.
>> I think there is more value in keeping completing-read simple, and focus
>> it on actual text expansion.
>
> Agree. Regarding "interpreting completion as selection" and "text
> expansion", I am unsure if there is a big difference. You always start
> with a set of possible completions and only for very few styles a
> prefix completion is possible. This has been mentioned before in this
> thread, I think.
I don't start with any set, I start with an (usually) empty prompt and
type a few letter, tab to check and then press enter. I try to avoid
unnecessary UI movement, which is why I have set
completion-cycle-threshold to t, so that I have to manually request a
"*Completions*" buffer. But even so, there are situations where
selection would be preferable. Usually when I don't know what my options
are.
>> In some sense the abundance of solutions around completion show that the
>> community wants something else than what completing-read provides by
>> default. I get why, as a lot of packages use completing-read. But it
>> might be better to start from the position we want to achieve, instead
>> of hacking our way towards that end.
>
> I am actually quite satisfied with the status quo given the many
> package options, where everyone seems to find a good fit. But maybe
> the name `completing-read` does not reflect anymore what it is since
> it is often used for something else than simple prefix expansion. The
> prefix/basic completion is baked pretty deeply in the completion APIs,
> e.g., `all-completions` and this got relaxed afterwards.
Well FWIW I'm not. I used Ivy for a long while, but ultimately gave it
up. There has been a lot of talk about {Selectrum,Embark,Orderless,...}
recently but I am not convinced that the approach these packages take
are on the right level. The only way to find out is to try something
else on the level I suspect there might be more potential for a better
solution.
> Daniel
>
--
Philip K.
^ permalink raw reply [relevance 73%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-07 19:22 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-07 19:22 UTC (permalink / raw)
To: Gregory Heytings; +Cc: emacs-devel
Gregory Heytings <gregory@heytings.org> writes:
> Yes, I meant something like the transient UI, but computed on the fly.
> I wasn't suggesting to use transient as a basis for something else, my
> remark was only about the look of the UI.
Maybe, but my knowledge of transient is too limited to say.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-07 22:31 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-07 22:31 UTC (permalink / raw)
To: Daniel Mendler; +Cc: emacs-devel
Daniel Mendler <mail@daniel-mendler.de> writes:
>> I use the default completion system, so for me it is not about filtering
>> a data set but expanding a string. Just to reiterate, this is exactly
>> the point I am bringing this up.
>
> Well, but what does this mean in the context of opening a file? I
> guess, you are not interested in the string (the file name) alone but
> in the end you want to select a file?
I'm not sure what you are asking here? I'm interested in the file, but I
designate it by it's name.
>> Well FWIW I'm not. I used Ivy for a long while, but ultimately gave it
>> up. There has been a lot of talk about {Selectrum,Embark,Orderless,...}
>> recently but I am not convinced that the approach these packages take
>> are on the right level. The only way to find out is to try something
>> else on the level I suspect there might be more potential for a better
>> solution.
>
> Why? I would love to hear a more detailed criticism since I am
> involved with those packages. You are again a bit vague.
My vagueness stems from my uncertainty. I just think that the general
idea (completion as selection) isn't what I am interested in, but I
don't want to make claims I am not sure of.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-07 22:59 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-07 22:59 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Dmitry Gutov <dgutov@yandex.ru> writes:
> What I was disagreeing in the previous message, is whether it's worth
> to create a semantic distinction between completing-read and
> selecting-read. How would a Lisp author choose between the two? The
> former should actually be more powerful (it will retain support for
> TAB completion, and yet it could still be supported by selection-style
> frameworks such as Company or Ivy);
completing-read can be more powerful, as it includes expanding text and
selecting items, but I if you are not interested in text-expansion you
should probably limit yourself to selection, so that everyone is ensured
to have the same presentation.
> the latter, on the other hand, would effectively mandate a minimum
> "niceness" of the UI (though not necessarily nicer than the former,
> depending on user customization), but would be unable to support more
> advanced completion tables. Such as ones with "fields" (which includes
> file name completion).
What do you mean by "niceness", and why would it not be able to support
more complex tables?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-08 14:44 99% ` Philip Kaludercic
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Philip Kaludercic @ 2021-04-08 14:44 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Dmitry Gutov <dgutov@yandex.ru> writes:
> On 08.04.2021 01:59, Philip Kaludercic wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>
>>> What I was disagreeing in the previous message, is whether it's worth
>>> to create a semantic distinction between completing-read and
>>> selecting-read. How would a Lisp author choose between the two? The
>>> former should actually be more powerful (it will retain support for
>>> TAB completion, and yet it could still be supported by selection-style
>>> frameworks such as Company or Ivy);
>> completing-read can be more powerful, as it includes expanding text
>> and
>> selecting items, but I if you are not interested in text-expansion you
>> should probably limit yourself to selection,
>
> Am "I" in this example the user, or the author of the caller code?
The I was probably a typo.
>> so that everyone is ensured
>> to have the same presentation.
>
> If that's the goal, why don't we make sure to include a "selection"
> interface that supports text-expansion as well, like both Company and
> Ivy do?
>
> What's the purpose of having that distinction?
My hypothisis is that selection is held back by completing-read, and
that a framework that is explicitly made for selection and not
retrofitted into the existing framework could stand to improve the user
experience.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-08 17:53 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-08 17:53 UTC (permalink / raw)
To: T.V Raman; +Cc: emacs-devel, Dmitry Gutov
"T.V Raman" <raman@google.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>
> In the spirit of exerimentation I'd second what Stefan suggested,
>
> Step 1: Create a selection oriented equivalent of completing-read
To clarify, this already exists with Helm, Ivy, etc. I'm working on a
framework that is primarily centred around selection.
> 2. See how that works out --
Yes, and this will probably take a few attempts to get right too. I hope
there will be interest to discuss different approaches on this list.
> 3. Then, compare it with completing-read -- and see if we can derive a
> master composite function that handles both use-cases well.
This might be possible, but I'm sceptical.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [External] : Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-08 18:03 82% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-08 18:03 UTC (permalink / raw)
To: Drew Adams; +Cc: emacs-devel@gnu.org, Dmitry Gutov
Drew Adams <drew.adams@oracle.com> writes:
>> > What's the purpose of having that distinction?
>>
>> My hypothisis is that selection is held back
>> by completing-read,
> Why do you think so? Held back in what way(s)?
> Details, please.
Can completing-read offer a hierarchical overview, allow inspection into
selected items, ensure that calls return values eq to the input, lazily
compute textual representations when they are needed? Starting from a
clean slate and intentionally designing an alternative function around
selection would seem to have the advantage that we already know that
people want, instead of having to fight what we already have.
>> and that a framework that is explicitly made for
>> selection and not retrofitted into the existing
>> framework could stand to improve the user experience.
>
> Again, why do you think so?
>
> This is as vague as a suggestion to rewrite Emacs
> so it uses Rust (or Python or Scheme or whatever)
> instead of Lisp, with no attempt to say what the
> need for that is or the advantages would be.
>
> I'm not arguing that `completing-read' has no
> room for improvement. In fact, I'm the first to
> say (and to have said, and shown) that there's
> plenty of room.
>
> (I've actually improved it in many ways, in my
> own code and practice. Lots of details and
> experience with my own "proposed" changes to it.)
>
> But a vague argument at the level of "selecting"
> versus "completing" doesn't cut it, in my book.
>
> Push the existing envelope first, to see where
> the real limits of `completing-read' are, before
> asking for an overhaul.
I am not proposing an overhaul, but to make the job easier for
completing-read. Instead of continuing to extend it by adding additional
special arguments and finding loopholes in the current implementations
of selection frameworks, I argue that a cleaner and more consistent
solution can be found in trying to understand when selection is wanted,
and how a solution that can be provided that directly solves the
problem.
I don't want to sound like a "Rewrite X in Y" kind of guy, because I
don't want to replace completing-read. I like it, and I like it
simple. Maybe it doesn't make sense to have both, but some
experimentation is necessary before that can be concluded.
--
Philip K.
^ permalink raw reply [relevance 82%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
2021-04-05 20:49 66% ` Philip Kaludercic
@ 2021-04-10 14:40 79% ` Philip Kaludercic
2021-04-21 9:20 79% ` Philip Kaludercic
2 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-04-10 14:40 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
> It might therefore be necessary to actually implement a "selecting-read"
> function, that could be used more or less like completing-read, but that
> provides a better default UI not based around completing text but
> actually selecting objects/items.
I attached a primitive version of selecting-read to this message. The UI
is horridly primitive, but the basic idea should be understandable.
Using generic functions, methods can be defined determining how an
object is handled. In this iteration, three generic functions are used:
- (selecting-read-represent object)
Return a string representing the object. This is the only necessary
method.
- (selecting-read-properties object)
Return a plist denoting properties of the object
- (selecting-read-children object)
Return a list of children of this object
It seems that these three functions are enough, and that adding more
would risk becoming too complicated.
When evaluating a nonsensical query like
(selecting-read '((node "one" "one.1" "one.2" "one.3")
(node ("two" :property "propertied" :key "value")
"two.1" "two.2")
"three"))
a child window appears and the user can select an object, that
selecting-read returns directly (eq).
Additional arguments are passed as keywords. A simple example is
:multiple that lets selecting-read give me a list of items that were
marked
(selecting-read '((node "one" "one.1\n" "one.2" "one.3")
(node ("two" :property "propertied" :key "value")
"two.1" "two.2")
"three")
:multiple t)
Because I'm not just now primarily concerned with what completing-read
might look like, it doesn't do "automatic narrowing" like Helm or
Ivy. The framework I sketched here should be flexible enough to support
something like that, if preferred.
--
Philip K.
[-- Attachment #2: selecting-read.el --]
[-- Type: application/emacs-lisp, Size: 6753 bytes --]
^ permalink raw reply [relevance 79%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-11 11:18 86% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-04-11 11:18 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Dmitry Gutov <dgutov@yandex.ru> writes:
> - It uses data structures quite different from what completing-read
> uses. That's pretty inconvenient, and requires a mental switch. I'd
> rather the two functions (or some future versions of them) were more
> similar in shape, yet (obviously) different in behavior.
I think it would be possible to also support alists, hash tables,
vectors but I'm not sure if it is necessary. Functions might be
interesting to consider.
But this raises a more general question, of whether selecting-read and
completing-read should be drop-in replacements of one another. I would
hesitate, as completing-read isn't the cleanest interface. Instead it
might be cleaner to also provide a compatibility function with the same
interface as completing-read to translate into selecting-read.
> - It's not pretty/comfortable to use (yet?). A lot of discussion and
> decisions might come from trying reaching the state where people
> like it.
>
> Speaking of what I see in selecting-read-mode-map, in particular
>
> (define-key map (kbd "/") #'selecting-read-narrow)
>
> , it invokes the image of a more ponderous, explicit interaction than
> the snappy selection UIs I've used and liked in the past.
Of course, this was the product of maybe 1-2 hours of programming. I
don't have much experience with designing Emacs UIs, so I didn't get
much done. Ideally the UI should either be configurable or multiple UIs
should be provided to please every taste.
>> Because I'm not just now primarily concerned with what completing-read
> might look like, it doesn't do "automatic narrowing" like Helm or
> Ivy.
>
> It doesn't do quick cycling with TAB either, though.
Yes, I'd like to have that too, but I first wanted to get some comments
on the internal architecture, before I spend more time with the UI.
--
Philip K.
^ permalink raw reply [relevance 86%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-11 12:24 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-11 12:24 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Eli Zaretskii, dgutov, monnier, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> > Right away, i.e. even without the user typing anything? that'd produce
>>> > a huge list of candidates, which would be impractical to display.
>>> This is what e.g. ivy does on M-x, and it works well in practice.
>>>
>>> I find it much better to display candidates this way, and I think it
>>> would be a step forward if Emacs dit this itself OOTB.
>>
>> For me, it would be a step back. I never use completion for
>> discovery, I always have a pretty good idea what I'm about to type
>> when I do.
>
> The fact that this UI paradigm is so ubiquitous suggests that you might
> be in the minority here.
I don't think that that should delegitimize the preference though.
>>> (It's also a popular choice elsewhere, try for example entering
>>> something into the search bar on Google or DuckDuckGo. The same
>>> paradigm you see there is used in a lot of desktop software.)
>>
>> Those are for selection, not for completion. I thought we'd already
>> established that the two are quite different. We should not conflate
>> them, nor force users use only one of them where both could make
>> sense, IMO.
>
> I don't think the distinction matters here. We are discussing if
> candidates should be shown eagerly, and my answer is "yes".
Are you using an alternative completion framework? I find it interesting
how some people agree with the distinction and others don't, and wonder
if the way they use Emacs shapes their opinion.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-11 15:53 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-11 15:53 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Jean Louis <bugs@gnu.support> writes:
> One way I use for complex data structures is to have some kind of ID
> and visual description, then by using the ID I fetch the data
> structure later.
I'm not sure I completely understood your example. What do hash tables
offer over lists of objects that can have a programmed representation?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-11 16:14 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-11 16:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, dgutov
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Sun, 11 Apr 2021 13:18:47 +0200
>> Cc: emacs-devel@gnu.org
>>
>> But this raises a more general question, of whether selecting-read and
>> completing-read should be drop-in replacements of one another.
>
> I think they should strive to, because it's conceivable that we will
> have a user option to determine which one to call where currently we
> call completing-read.
But why should that mean that both interfaces should be identical? It
seems cleaner to instead have a sr->cr translation layer, as to prevent
unnecessary dependencies between the two interfaces?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-11 17:39 94% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-11 17:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, dgutov
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: dgutov@yandex.ru, emacs-devel@gnu.org
>> Date: Sun, 11 Apr 2021 18:14:02 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> But this raises a more general question, of whether selecting-read and
>> >> completing-read should be drop-in replacements of one another.
>> >
>> > I think they should strive to, because it's conceivable that we will
>> > have a user option to determine which one to call where currently we
>> > call completing-read.
>>
>> But why should that mean that both interfaces should be identical? It
>> seems cleaner to instead have a sr->cr translation layer, as to prevent
>> unnecessary dependencies between the two interfaces?
>
> I don't understand what you mean by "translation layer".
completing-read has it's existing interface, and let's say that
selecting-read would not try to copy this interface 1:1. Instead a third
function could attempt to "translate" completing-read calls into
selecting-read calls, reducing the complexity of selecting-read.
I hope I'm not the only one, but writing "nil nil nil nil" just to
access a specific argument is cumbersome, and harder to extend. If it is
possible to keep a new interface cleaner, I think that this would help
it be more forwards-compatible.
--
Philip K.
^ permalink raw reply [relevance 94%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-11 21:52 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-11 21:52 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel
Dmitry Gutov <dgutov@yandex.ru> writes:
>>> It would still miss the ability to quickly accept one of them
>>> with RET.
>> Right, but the cycle-threshold helps with that, no?
>
> At the moment, IIUC, the UI either lets you cycle, or shows the
> *Completions* buffer, but not both at the same time.
I get the *Completions* buffer if I press '?', or do you mean something else?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Add buffer name option for project-compile
@ 2021-04-12 8:13 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-12 8:13 UTC (permalink / raw)
To: Ivan Sokolov; +Cc: emacs-devel
Ivan Sokolov <ivan-p-sokolov@ya.ru> writes:
> +(defun project--compilation-buffer-name (mode)
> + (concat "*"
> + (file-name-nondirectory
> + (directory-file-name default-directory))
Should this be the default directory or the project root?
> + "-"
> + (downcase mode)
> + "*"))
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-12 10:14 98% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-12 10:14 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Jean Louis <bugs@gnu.support> writes:
> * Philip Kaludercic <philipk@posteo.net> [2021-04-11 18:53]:
>> Jean Louis <bugs@gnu.support> writes:
>>
>> > One way I use for complex data structures is to have some kind of ID
>> > and visual description, then by using the ID I fetch the data
>> > structure later.
>>
>> I'm not sure I completely understood your example. What do hash tables
>> offer over lists of objects that can have a programmed
>> representation?
>
> Completing read supports hash tables, once representation candidate
> has been selected one can then use the key to get value of some quite
> different or very complex data structure.
>
> (setq h (make-hash-table :test 'equal))
> (puthash "United States" [("ABC" 30 t)] h)
> (puthash "Australia" 2 h)
> (puthash "United Kingdom" 3 h)
>
> (message "%s" (gethash (completing-read "Choice: " h) h)) ⇒ "[(ABC 30 t)]"
But don't you think that it is weird that completing-read returns the
representation and not the object itself. That is exactly what I want to
avoid by having the representation computed using a method.
The best I can think of is using hash-maps to generate anonymous methods
but even that seems to be looking at the issue backwards.
--
Philip K.
^ permalink raw reply [relevance 98%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-12 11:30 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-12 11:30 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
Jean Louis <bugs@gnu.support> writes:
> How I understand, you want to use values or some variable data to
> compute representation, fine and I hope it will not break standard
> completion.
You don't have to worry about that, I'm playing with the concept of
selection.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Getting ready to land native-compilation on master
@ 2021-04-14 9:45 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-14 9:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andrea Corallo, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> If no significant issues pop up within a week, I will ask Andrea to
> merge the branch onto master the next weekend (i.e. around 17th of
> April).
I have been trying out the branch for the last few days and I didn't
notice any functional issues.
What was is annoying is the "sudden" warning buffers pop up, triggered
by from what I understand is the asynchronous (?) compilation. Is there
a way to mitigate this, and if so, it should be documented.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Miscategorised project.el user options
@ 2021-04-14 9:52 99% Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-14 9:52 UTC (permalink / raw)
To: emacs-devel
Hi,
I have noticed that the user options project-switch-commands and
project-switch-use-entire-map are missing :group tags. Therefore they
are added to the project-vc group, as this is the last group that was
defined. Fixing this is too trivial for a patch, so I just wanted to
report it.
(P.S. Would it be OK to push directly to master if I find minor issues
like these?)
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Getting ready to land native-compilation on master
@ 2021-04-14 10:35 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-14 10:35 UTC (permalink / raw)
To: Andrea Corallo; +Cc: Eli Zaretskii, emacs-devel
Andrea Corallo <akrl@sdf.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> If no significant issues pop up within a week, I will ask Andrea to
>>> merge the branch onto master the next weekend (i.e. around 17th of
>>> April).
>>
>> I have been trying out the branch for the last few days and I didn't
>> notice any functional issues.
>>
>> What was is annoying is the "sudden" warning buffers pop up, triggered
>> by from what I understand is the asynchronous (?) compilation. Is there
>> a way to mitigate this, and if so, it should be documented.
>
> I Philip,
>
> one can act on the `comp-async-report-warnings-errors' customize setting
> it to nil (default is t).
That should do it, thank you.
Does it make sense to have this enabled by default? At the very least,
ELPA packages should be addressed that trigger needless issues such as
overlong lines.
> Thanks
>
> Andrea
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Getting ready to land native-compilation on master
@ 2021-04-14 12:57 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-14 12:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, akrl
Eli Zaretskii <eliz@gnu.org> writes:
>> At the very least, ELPA packages should be addressed that trigger
>> needless issues such as overlong lines.
>
> I don't understand how overlong lines are significant in this context,
> please elaborate.
If I'm not mistaken, packages such as yasnippet generated warnings
(again, several minutes after Emacs itself was started) including more
or more or less trivial issues such as overlong lines.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Getting ready to land native-compilation on master
@ 2021-04-14 14:00 92% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-14 14:00 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, akrl
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: akrl@sdf.org, emacs-devel@gnu.org
>> Date: Wed, 14 Apr 2021 14:57:44 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> At the very least, ELPA packages should be addressed that trigger
>> >> needless issues such as overlong lines.
>> >
>> > I don't understand how overlong lines are significant in this
>> > context,
>> > please elaborate.
>>
>> If I'm not mistaken, packages such as yasnippet generated warnings
>> (again, several minutes after Emacs itself was started) including
>> more
>> or more or less trivial issues such as overlong lines.
>
> Please show such a message, because I still don't think I understand,
> perhaps because I don't know enough about yasnippet.
From what I understand it is the regular compiler warning, just like you
would get without native-compile. So it is not related to yasnippet or
any other package itself. I tried it out, and in my case it looked like
this:
Compiling file /home/philip/.config/emacs/elpa/yasnippet-0.14.0/yasnippet.el at Wed Apr 14 15:57:58 2021
yasnippet.el:475:1: Warning: defvar `yas-after-exit-snippet-hook' docstring
wider than 80 characters
yasnippet.el:557:1: Warning: custom-declare-variable `yas-keymap-disable-hook'
docstring wider than 80 characters
The difference being that this is not generated when the package is
installed, but suddenly appears in a buffer.
--
Philip K.
^ permalink raw reply [relevance 92%]
* Re: Getting ready to land native-compilation on master
@ 2021-04-14 14:42 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-14 14:42 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Eli Zaretskii, akrl, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> From what I understand it is the regular compiler warning, just like you
>> would get without native-compile. So it is not related to yasnippet or
>> any other package itself. I tried it out, and in my case it looked like
>> this:
>>
>> Compiling file /home/philip/.config/emacs/elpa/yasnippet-0.14.0/yasnippet.el at Wed Apr 14 15:57:58 2021
>> yasnippet.el:475:1: Warning: defvar `yas-after-exit-snippet-hook' docstring
>> wider than 80 characters
>> yasnippet.el:557:1: Warning: custom-declare-variable `yas-keymap-disable-hook'
>> docstring wider than 80 characters
>
> These warnings should be fixed in yasnippet itself.
Of course.
>> The difference being that this is not generated when the package is
>> installed, but suddenly appears in a buffer.
>
> This shouldn't be a problem once we flip
> `comp-async-report-warnings-errors' to nil by default. AFAIK, the plan
> is to do that in time for Emacs 28. As others have explained, we keep
> it set to t for now as it indicates real problems.
Good to hear, that certainly sounds sensible.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
2021-04-10 14:40 79% ` Philip Kaludercic
@ 2021-04-21 9:20 79% ` Philip Kaludercic
1 sibling, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-04-21 9:20 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 57 bytes --]
Here is an updated version, not with improved visuals:
[-- Attachment #2: selecting-read.el --]
[-- Type: application/emacs-lisp, Size: 12118 bytes --]
[-- Attachment #3: Type: text/plain, Size: 3832 bytes --]
For the most part, the suggestion is the same, I just added an
additional generic function
(selecting-read-flags object)
that returns a list of flags, to indicate if an object is selectable,
should be folded by default, etc.
As a demonstration, the option selecting-read-auto-narrow enabled a
behaviour that is similar to what selecting completion framework
provide.
I have also mentioned that a "translation function" could be written to
translate completing-read calls into selecting-read. Here is an example
that could be set to completing-read-function, even if it does not
implement the entire interface:
--8<---------------cut here---------------start------------->8---
(defun selecting-read-<-completing-read (prompt collection &optional
predicate
require-match
initial-input
_hist
default
_inherit-input-method)
"Translation interface for `completing-read' to `selecting-read'.
PROMPT, COLLECTION, PREDICATE, REQUIRE-MATCH, INITIAL-INPUT and
DEFAULT are all interpreted as by `completing-read'."
(or (selecting-read (all-completions "" collection predicate)
:must-select (not (memq require-match
'(confirm-after-completion
confirm
nil)))
:initial-query initial-input
:prompt prompt)
(cond ((listp default) (car default))
((null default) "")
(default))))
--8<---------------cut here---------------end--------------->8---
There are still issues, especially with large collections (try C-h o and
wait). When I get around to working on this again, I'll try to implement
the lazy selection generation, as mentioned before.
Philip Kaludercic <philipk@posteo.net> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> It might therefore be necessary to actually implement a "selecting-read"
>> function, that could be used more or less like completing-read, but that
>> provides a better default UI not based around completing text but
>> actually selecting objects/items.
>
> I attached a primitive version of selecting-read to this message. The UI
> is horridly primitive, but the basic idea should be understandable.
>
> Using generic functions, methods can be defined determining how an
> object is handled. In this iteration, three generic functions are used:
>
> - (selecting-read-represent object)
>
> Return a string representing the object. This is the only necessary
> method.
>
> - (selecting-read-properties object)
>
> Return a plist denoting properties of the object
>
> - (selecting-read-children object)
>
> Return a list of children of this object
>
> It seems that these three functions are enough, and that adding more
> would risk becoming too complicated.
>
> When evaluating a nonsensical query like
>
> (selecting-read '((node "one" "one.1" "one.2" "one.3")
> (node ("two" :property "propertied" :key "value")
> "two.1" "two.2")
> "three"))
>
> a child window appears and the user can select an object, that
> selecting-read returns directly (eq).
>
> Additional arguments are passed as keywords. A simple example is
> :multiple that lets selecting-read give me a list of items that were
> marked
>
> (selecting-read '((node "one" "one.1\n" "one.2" "one.3")
> (node ("two" :property "propertied" :key "value")
> "two.1" "two.2")
> "three")
> :multiple t)
>
> Because I'm not just now primarily concerned with what completing-read
> might look like, it doesn't do "automatic narrowing" like Helm or
> Ivy. The framework I sketched here should be flexible enough to support
> something like that, if preferred.
--
Philip K.
^ permalink raw reply [relevance 79%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-21 10:27 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-04-21 10:27 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Wed, 21 Apr 2021 09:20:24 +0000
>>
>> Here is an updated version, not with improved visuals:
>
> It looks like this only supports displaying selection lists and
> interacting with users via buffers? If so, I think we should also
> support doing that via GUI dialogs (in Emacs configurations that
> support dialogs, which nowadays means almost every build). This is
> what many other applications do, so I think we had better did the
> same, at least as an option.
>
> Of course, selections via dialogs not always make sense, so this
> should be one of the possible UIs we support, not the only one.
Ideally yes, but is it possible to have a menu that can be both selected
and expanded? If not, I think the interface for selecting-read should be
updated to reflect this restriction (making every object with children
non-selectable).
> Thanks.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-21 12:50 94% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-21 12:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Ideally yes, but is it possible to have a menu that can be both selected
>> and expanded?
>
> I don't think I understand what you mean by "expanded" here. There
> are submenus, if that's what you meant.
The current model I am using assumes that selecting-read is passed a
list of objects, and each object can have sub-objects (children).
Every object has it's representation calculated and is displayed in the
popup buffer. Any objects can be selected, even those with children.
Most GUI menu interfaces I am familiar with do not allow selecting a
menu that has children, but only "leaf nodes". If selecting-read should
both have a buffer interface as well as a GUI interface, the abstraction
should be restricted so that it fits both paradigms.
--
Philip K.
^ permalink raw reply [relevance 94%]
* Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
@ 2021-04-21 14:21 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-21 14:21 UTC (permalink / raw)
To: Daniel Mendler; +Cc: emacs-devel
Daniel Mendler <mail@daniel-mendler.de> writes:
> On 4/21/21 11:20 AM, Philip Kaludercic wrote:
>>>> It might therefore be necessary to actually implement a "selecting-read"
>>>> function, that could be used more or less like completing-read, but that
>>>> provides a better default UI not based around completing text but
>>>> actually selecting objects/items.
>>>
>>> I attached a primitive version of selecting-read to this message. The UI
>>> is horridly primitive, but the basic idea should be understandable.
>>
>> Here is an updated version, not with improved visuals:
>
> I think it is interesting to experiment with actual use cases. Maybe
> it is a good demonstration to write a `read-buffer-function` and a
> `read-file-function` based on such a `selecting-read` API? The buffer
> selector is not hierarchical (at least as long as one leaves out
> perspectives or other levels), but there can be properties for
> filtering. In the case of the file selector one can experiment with
> hierarchical objects, and dynamic generation of the object
> tree. Partial-completion/initials can be used to filter/restrict the
> hierarchy.
I will try to look into this as practical examples, after the
performance has been improved and the query language is more than just
regular expressions. It hope that it would demonstrate limitations of
the current interface.
> As with `completing-read` it should be possible to decouple the
> components in ui, filtering language and backend/object
> representation.
Of course, the current implementation also provides this with the
generic functions on the one side and selecting-read-function on the
other. The current UI is pretty hacky, so I'd expect people with more
experience and enthusiasm when it comes to come up with better
solutions.
>> I have also mentioned that a "translation function" could be written to
>> translate completing-read calls into selecting-read. Here is an example
>> that could be set to completing-read-function, even if it does not
>> implement the entire interface:
>
> This translation function implements only a small part of the
> `completing-read` interface (static completion tables). Did you look
> into how dynamic tables could be supported? Or is this something you
> would rather leave out to introduce a separation of `completing-read`
> and `selecting-read`? Separating the completion and selection use case
> may be technically cleaner. Going with a unified API could lead to a
> more consistent system overall?
The translation function is currently more of a POC, as there were some
messages on that topic in previous thread. It is entirely debatable if
selecting-read should provide a super-set of features that
completing-read provides, or it should just have an intersection.
I haven never really used dynamic tables for completing-read, so I'll
have to look into that and see how it might apply to selecting-read, if
at all.
> Daniel
>
>
--
Philip K.
^ permalink raw reply [relevance 86%]
* On the stability of Xref
@ 2021-04-22 9:57 80% Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-22 9:57 UTC (permalink / raw)
To: emacs-devel
Hi,
I wanted to ask what the consensus is on the stability of the Xref
interface. xref.el starts with the unsettling warning
;; NOTE: The xref API is still experimental and can change in major,
;; backward-incompatible ways. Everyone is encouraged to try it, and
;; report to us any problems or use cases we hadn't anticipated, by
;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
that scares some people away from using the mode (see for example [0]).
git blame tells me that that this note was added more than 5 years ago,
and I'm not sure how much has changed in the interface since then.
At the same time, several external packages have implemented the Xref
interface, including the aforementioned dumb-jump, that is among the
most used packages on MELPA[1]. Eglot and lsp-mode both implement the
interface as is.
The question I am getting at is whether or not it is time to remove the
warning and accept the Xref interface as it is, or to make use of the
warning and update what should be updated? I personally am a big fan of
the functionality it provides generically, and prefer it over having
every mode do it's own thing, as I assume many others do too. Not having
to worry about it changing would be appreciated.
[0] https://github.com/jacktasia/dumb-jump/issues/365#issuecomment-824357478
[1] https://melpa.org/#/dumb-jump
--
Philip K.
^ permalink raw reply [relevance 80%]
* Re: Adding transient to Emacs core
@ 2021-04-26 12:54 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-26 12:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Madhu, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Madhu <enometh@meer.net>
>> Date: Mon, 26 Apr 2021 08:00:37 +0530
>>
>> I think transient.el has serious design problems with respect to emacs.
>
> Then please describe those problems in detail, preferably in a bug
> report. (You allude here to some discussions you had with Jonas, but
> we weren't part of them, and so those references tell us nothing
> useful.)
It seems Madhu is referencing this commit:
https://github.com/magit/transient/commit/c7ad1f01f4ff9e5125bcec99dfb9c3dedadfc369
and these discussions
https://github.com/magit/transient/issues/34
https://github.com/magit/transient/issues/44
that claim transient breaks with an unusual display-buffer-alist
configuration.
>> Until these issues are addressed I would prefer that new code in the
>> core not use transient.el
>
> We cannot agree with this conclusion unless we understand the details.
>
> Thanks.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Adding transient to Emacs core
@ 2021-04-27 10:51 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-27 10:51 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: Madhu, emacs-devel
Jonas Bernoulli <jonas@bernoul.li> writes:
> I have addressed this by let-binding that variable to t around the call
> to display-buffer. There's just no way around that because transient's
> buffer just has to be displayed somewhere other than the selected
> window.
What is the issue with displaying the buffer in the selected window? It
seems like something interesting, if I don't want my frames to be
rearranged.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Adding transient to Emacs core
@ 2021-04-27 15:21 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-04-27 15:21 UTC (permalink / raw)
To: Jonas Bernoulli; +Cc: Gregory Heytings, Madhu, emacs-devel
Jonas Bernoulli <jonas@bernoul.li> writes:
> Any Emacs command can be added as the suffix of a transient prefix
> command, for example:
>
> (transient-define-prefix my-buffer-commands ()
> "Do stuff to buffers."
> [:description (lambda () (format "Act on current buffer (%s)" (current-buffer)))
> ("k" "kill the current buffer" kill-this-buffer)])
>
> (global-set-key [f1] 'my-buffer-commands)
I just tried this out, and it seems that transient it very different
compared to magit-popup, that powers my local version of magit (from
MELPA Stable).
I am uncertain how I feel about this, as it seems to be something
completely different than what I was thinking about all the time.
At the same time it does not seem obvious why, especially with transient
menus that may contain a lot of options (say a ffmpeg interface)
shouldn't be able to use the entire frame. Especially from a user
perspective.
> If the selected window were repurposed to display transient's buffer,
> then that would change what buffer is the current buffer and it would
> become impossible to act on the buffer that was previously the current
> buffer or on "the thing under the cursor" in that buffer.
What do you mean by "what buffer is the current buffer"? I am somewhat
confused by what you are trying to say here.
> Re-purposing the selected window would massively reduce the usefulness
> of a huge number of commands or even make them completely useless.
Again, I do not see how this follows? My verison of Magit has
magit-display-buffer-function, that allows me to display the buffer in
the selected window, with no loss of functionality. What does transient
do or need that prevents this?
--
Philip K.
^ permalink raw reply [relevance 86%]
* [PATCH] Speed up project-kill-buffers
@ 2021-05-03 9:43 80% Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-05-03 9:43 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
Hi,
I've noticed that sometimes project-kill-buffers is noticeably slow, and
it seems like it's has to do with project--buffer-list working on remote
files. The function goes through every buffer and calls
(project-current), even if the buffer is related to a remote file that
cannot be part of the current project.
The patch I attach below is a simple fix to avoid checking files that
cannot be part of the current project. Or are there any edge-cases that
this code approach breaks?
--
Philip K.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Avoid-Tramp-buffers-when-possible.patch --]
[-- Type: text/x-diff, Size: 1246 bytes --]
From 8b45502da8281826fa2da02a317546bc99f51069 Mon Sep 17 00:00:00 2001
From: Philip K <philipk@posteo.net>
Date: Mon, 3 May 2021 11:35:41 +0200
Subject: [PATCH] Avoid Tramp buffers when possible
* project.el (project--buffer-list): Add file-remote-p check
---
lisp/progmodes/project.el | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index d47d9d77e6..33827136a1 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1120,11 +1120,14 @@ project-kill-buffer-conditions
(defun project--buffer-list (pr)
"Return the list of all buffers in project PR."
- (let (bufs)
+ (let ((remote-project-p (file-remote-p (project-root pr)))
+ bufs)
(dolist (buf (buffer-list))
- (when (equal pr
- (with-current-buffer buf
- (project-current)))
+ (when (and (let ((remote (file-remote-p (buffer-local-value 'default-directory buf))))
+ (if remote-project-p remote (not remote)))
+ (equal pr
+ (with-current-buffer buf
+ (project-current))))
(push buf bufs)))
(nreverse bufs)))
--
2.30.2
^ permalink raw reply related [relevance 80%]
* Re: [PATCH] Speed up project-kill-buffers
@ 2021-05-03 13:06 84% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-05-03 13:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> (defun project--buffer-list (pr)
>> "Return the list of all buffers in project PR."
>> - (let (bufs)
>> + (let ((remote-project-p (file-remote-p (project-root pr)))
>> + bufs)
>> (dolist (buf (buffer-list))
>> - (when (equal pr
>> - (with-current-buffer buf
>> - (project-current)))
>> + (when (and (let ((remote (file-remote-p (buffer-local-value 'default-directory buf))))
>> + (if remote-project-p remote (not remote)))
>> + (equal pr
>> + (with-current-buffer buf
>> + (project-current))))
>> (push buf bufs)))
>> (nreverse bufs)))
>
> How 'bout using `file-in-directory-p`?
I didn't know about that function! Just tried it out and it seems that
the patch below is even faster, as project-current does not have to be
invoked for every buffer, remote or not.
> Stefan
>
--
Philip K.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Reduce-number-of-method-invocations-in-project-buffe.patch --]
[-- Type: text/x-diff, Size: 1136 bytes --]
From eb9f32e1007eaa90a1b5487ac009b38182d6260b Mon Sep 17 00:00:00 2001
From: Philip K <philipk@posteo.net>
Date: Mon, 3 May 2021 11:35:41 +0200
Subject: [PATCH] Reduce number of method invocations in project--buffer-list
* project.el (project--buffer-list): Use file-in-directory-p
---
lisp/progmodes/project.el | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index d47d9d77e6..aa2fc1690f 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1120,11 +1120,12 @@ project-kill-buffer-conditions
(defun project--buffer-list (pr)
"Return the list of all buffers in project PR."
- (let (bufs)
+ (let ((root (project-root pr))
+ bufs)
(dolist (buf (buffer-list))
- (when (equal pr
- (with-current-buffer buf
- (project-current)))
+ (when-let ((file (or (buffer-file-name buf)
+ (buffer-local-value 'default-directory buf)))
+ ((file-in-directory-p file root)))
(push buf bufs)))
(nreverse bufs)))
--
2.30.2
^ permalink raw reply related [relevance 84%]
* Re: [PATCH] Speed up project-kill-buffers
@ 2021-05-03 17:25 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-05-03 17:25 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I didn't know about that function! Just tried it out and it seems that
>> the patch below is even faster, as project-current does not have to be
>> invoked for every buffer, remote or not.
>
> I think it might misbehave if you have projects nested in the directory
> of other projects, tho.
That is true, but this leads to the more general question of whether a
sub-project is part of the super-project or not? Is there any reason to
intrinsically prefer one over the other?
> Stefan
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Speed up project-kill-buffers
@ 2021-05-08 12:30 99% ` Philip Kaludercic
2021-05-08 13:05 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-05-08 12:30 UTC (permalink / raw)
To: Stephen Leake; +Cc: Stefan Monnier, emacs-devel
Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I didn't know about that function! Just tried it out and it seems that
>>> the patch below is even faster, as project-current does not have to be
>>> invoked for every buffer, remote or not.
>>
>> I think it might misbehave if you have projects nested in the directory
>> of other projects, tho.
>
> There are also projects that do not have a single root; an Emacs elisp
> project (which has load-path as roots), any project with dependent
> external libraries.
>
> You can check (member file (project-files prj)), but that's about the
> same as your first patch.
So maybe something like
(let ((root (project-root proj))
(extr (project-external-roots proj)))
(member file (project-files proj (cons root extr))))
?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Speed up project-kill-buffers
2021-05-08 12:30 99% ` Philip Kaludercic
@ 2021-05-08 13:05 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-05-08 13:05 UTC (permalink / raw)
To: Stephen Leake; +Cc: Stefan Monnier, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> So maybe something like
>
> (let ((root (project-root proj))
> (extr (project-external-roots proj)))
> (member file (project-files proj (cons root extr))))
I realize that one issue here is that external roots could be shared by
multiple projects, so you wouldn't want to kill them when cleaning up
after a project even if you would want to have them listed.
> ?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [ELPA] New package: evdocs
@ 2021-05-29 12:05 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-05-29 12:05 UTC (permalink / raw)
To: Augusto Stoffel; +Cc: emacs-devel
Augusto Stoffel <arstoffel@gmail.com> writes:
> [About the silly name: "devdocs" is already taken by a MELPA package.
> That package is quite different and doesn't provide a viewer; it simply
> calls `browse-url' on a suitable https://devdocs.io location.]
Couldn't you just call it dev-docs, in that case?
--
Philip K.
^ permalink raw reply [relevance 99%]
* [PATCH] Fix random selection of keyserver
@ 2021-05-30 18:36 77% Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-05-30 18:36 UTC (permalink / raw)
To: emacs-devel
* epa-ks.el (epa-keyserver-list): Add new variable
(epa-keyserver): Use epa-keyserver-list to generate type
(epa-ks--fetch-key): Check if epa-keyserver is 'random
(epa-search-keys): Check if epa-keyserver is 'random
---
lisp/epa-ks.el | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/lisp/epa-ks.el b/lisp/epa-ks.el
index a33025b112..dcdbefc57b 100644
--- a/lisp/epa-ks.el
+++ b/lisp/epa-ks.el
@@ -38,18 +38,23 @@ epa-ks
:version "28.1"
:group 'epa)
+(defvar epa-keyserver-list
+ '("keyring.debian.org"
+ "keys.gnupg.net"
+ "keyserver.ubuntu.com"
+ "pgp.mit.edu"
+ "pool.sks-keyservers.net"
+ "zimmermann.mayfirst.org")
+ "List of default keyservers.")
+
(defcustom epa-keyserver "pgp.mit.edu"
"Domain of keyserver.
This is used by `epa-ks-lookup-key', for looking up public keys."
- :type '(choice :tag "Keyserver"
+ :type `(choice :tag "Keyserver"
(const random)
- (const "keyring.debian.org")
- (const "keys.gnupg.net")
- (const "keyserver.ubuntu.com")
- (const "pgp.mit.edu")
- (const "pool.sks-keyservers.net")
- (const "zimmermann.mayfirst.org")
+ ,@(mapcar (lambda (server) `(const ,server))
+ epa-keyserver-list)
(string :tag "Custom keyserver"))
:version "28.1")
@@ -145,7 +150,10 @@ epa-ks--fetch-key
"Send request to import key with specified ID."
(url-retrieve
(format "https://%s/pks/lookup?%s"
- epa-keyserver
+ (if (eq epa-keyserver 'random)
+ (nth (random (length epa-keyserver-list))
+ epa-keyserver-list)
+ epa-keyserver)
(url-build-query-string
`(("search" ,(concat "0x" (url-hexify-string id)))
("options" "mr")
@@ -225,7 +233,10 @@ epa-search-keys
(epa-ks-search-mode))
(url-retrieve
(format "https://%s/pks/lookup?%s"
- epa-keyserver
+ (if (eq epa-keyserver 'random)
+ (nth (random (length epa-keyserver-list))
+ epa-keyserver-list)
+ epa-keyserver)
(url-build-query-string
(append `(("search" ,query)
("options" "mr")
--
2.30.2
^ permalink raw reply related [relevance 77%]
* Re: [PATCH] Fix random selection of keyserver
@ 2021-05-30 19:46 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-05-30 19:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Sun, 30 May 2021 18:36:29 +0000
>>
>> * epa-ks.el (epa-keyserver-list): Add new variable
>> (epa-keyserver): Use epa-keyserver-list to generate type
>> (epa-ks--fetch-key): Check if epa-keyserver is 'random
>> (epa-search-keys): Check if epa-keyserver is 'random
>
> I think it's better to have a :set function for the defcustom, which
> would create a list from what the user customized, and then you can
> randomly select from what the user defined, not from the standard list
> out of user's control. Right?
Perhaps, the intent of this patch was just to fix the currently broken
behaviour suggested by epa-keyserver's type.
I am not sure if a :set function could be used to randomize the
keyserver for every request. Then again, is might not even really be
necessary to provide such a feature.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Fix random selection of keyserver
@ 2021-05-31 11:13 66% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-05-31 11:13 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Perhaps, the intent of this patch was just to fix the currently broken
>> behaviour suggested by epa-keyserver's type.
>>
>> I am not sure if a :set function could be used to randomize the
>> keyserver for every request. Then again, is might not even really be
>> necessary to provide such a feature.
>
> I wonder whether it might make sense instead to allow `epa-keyserver' to
> be a list, and if so, then choose a random server from that list.
> That'd give users control over what servers to use when randomising.
That does seem to be a better approach, how does the patch below look
like?
--
Philip K.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Improve-random-selection-of-keyservers.patch --]
[-- Type: text/x-diff, Size: 3278 bytes --]
From fdbb17539a465c49aad93cef4e0b8b4b76699561 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Sun, 30 May 2021 20:34:54 +0200
Subject: [PATCH] Improve random selection of keyservers
* epa-ks.el (epa-keyserver): Interpret a list as a pool
(epa-ks--query-url): Add new auxiliary function
(epa-ks--fetch-key): Use epa-ks--query-url
(epa-search-keys): Use epa-ks--query-url
---
lisp/epa-ks.el | 42 +++++++++++++++++++++++++-----------------
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/lisp/epa-ks.el b/lisp/epa-ks.el
index a33025b112..1d17c1399c 100644
--- a/lisp/epa-ks.el
+++ b/lisp/epa-ks.el
@@ -42,8 +42,9 @@ epa-keyserver
"Domain of keyserver.
This is used by `epa-ks-lookup-key', for looking up public keys."
- :type '(choice :tag "Keyserver"
- (const random)
+ :type `(choice :tag "Keyserver"
+ (repeat :tag "Random pool"
+ (string :tag "Keyserver address"))
(const "keyring.debian.org")
(const "keys.gnupg.net")
(const "keyserver.ubuntu.com")
@@ -141,20 +142,33 @@ epa-ks-do-key-to-fetch
(epa-ks--fetch-key id))))
(tabulated-list-clear-all-tags))
+(defun epa-ks--query-url (query exact)
+ "Return URL for QUERY.
+If EXACT is non-nil, don't accept approximate matches."
+ (format "https://%s/pks/lookup?%s"
+ (cond ((null epa-keyserver)
+ (user-error "Empty keyserver pool"))
+ ((listp epa-keyserver)
+ (nth (random (length epa-keyserver))
+ epa-keyserver))
+ ((stringp epa-keyserver)
+ epa-keyserver)
+ ((error "Invalid type for `epa-keyserver'")))
+ (url-build-query-string
+ (append `(("search" ,query)
+ ("options" "mr")
+ ("op" "index"))
+ (and exact '(("exact" "on")))))))
+
(defun epa-ks--fetch-key (id)
"Send request to import key with specified ID."
(url-retrieve
- (format "https://%s/pks/lookup?%s"
- epa-keyserver
- (url-build-query-string
- `(("search" ,(concat "0x" (url-hexify-string id)))
- ("options" "mr")
- ("op" "get"))))
+ (epa-ks--query-url (concat "0x" (url-hexify-string id)) t)
(lambda (status)
(when (plist-get status :error)
(error "Request failed: %s"
- (caddr (assq (caddr (plist-get status :error))
- url-http-codes))))
+ (caddr (assq (caddr (plist-get status :error))
+ url-http-codes))))
(forward-paragraph)
(save-excursion
(goto-char (point-max))
@@ -224,13 +238,7 @@ epa-search-keys
(erase-buffer))
(epa-ks-search-mode))
(url-retrieve
- (format "https://%s/pks/lookup?%s"
- epa-keyserver
- (url-build-query-string
- (append `(("search" ,query)
- ("options" "mr")
- ("op" "index"))
- (and exact '(("exact" "on"))))))
+ (epa-ks--query-url query exact)
(lambda (status)
(when (plist-get status :error)
(when buf
--
2.30.2
^ permalink raw reply related [relevance 66%]
* Re: [PATCH] Fix random selection of keyserver
@ 2021-05-31 12:04 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-05-31 12:04 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Lars Ingebrigtsen, Eli Zaretskii, emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> On Mai 31 2021, Philip Kaludercic wrote:
>
>> diff --git a/lisp/epa-ks.el b/lisp/epa-ks.el
>> index a33025b112..1d17c1399c 100644
>> --- a/lisp/epa-ks.el
>> +++ b/lisp/epa-ks.el
>> @@ -42,8 +42,9 @@ epa-keyserver
>> "Domain of keyserver.
>>
>> This is used by `epa-ks-lookup-key', for looking up public keys."
>> - :type '(choice :tag "Keyserver"
>> - (const random)
>> + :type `(choice :tag "Keyserver"
>> + (repeat :tag "Random pool"
>> + (string :tag "Keyserver address"))
>
> The backquote is no longer needed.
Yes, of course. Should I resubmit the patch, or can it be corrected
before applying it?
> Andreas.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Cleaning up rcirc
@ 2021-06-04 15:16 6% Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-06-04 15:16 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]
Hi,
I attach a series of patches suggesting a few improvements and things
that can be cleaned up. The background is that I am planning to
implement support for IRCv3, and these are issues I noticed while
reading through the code.
I'll summarize the changes here:
- 0001: Use libera.chat instead of freenode.net. This might be
controversial, but besides that it also checks if gnutls is
available.
- 0002: Use auth-source to check if the user has a password for the
current server. I suggest this because my personal bouncer has a
server, and I am currently querying .authinfo.gpg every time during
startup. This needlessly slows down my startup time.
- 0003: Instead of duplicating a regular expression for URLs, use the
one defined in browse-url.
- 0004: This is big changeset attempting to document every variable and
function. There was a lot of missing documentation, from what I see
since the first time rcirc was imported ~16 years ago, that I guess
nobody ever bothered to document.
- 0005: I merged the command formatting functionality into
rcirc-send-string itself, while preserving backwards
compatibility. This removes a lot of duplicate and hack'y code around
formatting IRC commands
- 0006: Instead of having rcirc-process-input-line call
rcirc-process-command that in turn calls rcirc-process-message if
the command is escaped, check if a command was escaped in
rcirc-process-command.
- 0007: rcirc-mode was a function, and not a "derived mode". This patch
tries to convert rcirc-mode into a proper major mode, but has to deal
with the fact that rcirc-mode requires two arguments that have to
fall away. Instead, rcirc-initialize is used for creating a new buffer
and setting the major mode. This might require some more hacking to
fix issues if some external code calls rcirc-mode directly.
- 0008: The function rcirc-delete-process just calls delete-process, and
has no additional functionality. From what I see, it used to do more,
but that was removed a while back, so there should be no need for this
function any more.
- 0009: The variable rcirc-last-sender appears to have never been used
or defined, so I dared to remove it.
- 0010: Update the activity string directly after moving to the next
active buffer. This avoids an annoyance where the mode line is not
updated, even though you have read new messages.
There is more that can be done (particularly with using when, unless,
subr-x macros, ...), but this is what I managed to root out until now.
--
Philip K.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Default-to-libera.chat-instead-of-freenode.net.patch --]
[-- Type: text/x-diff, Size: 1470 bytes --]
From aca90f1fb7cc2defc4c668b43b5934dacceb8453 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 4 Jun 2021 14:00:03 +0200
Subject: [PATCH 01/11] Default to libera.chat instead of freenode.net
---
lisp/net/rcirc.el | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 4fdb63e2eb..90b61badf0 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -56,10 +56,10 @@ rcirc
:group 'applications)
(defcustom rcirc-server-alist
- '(("chat.freenode.net" :channels ("#rcirc")
- ;; Don't use the TLS port by default, in case gnutls is not available.
- ;; :port 7000 :encryption tls
- ))
+ (if (gnutls-available-p)
+ '(("irc.libera.chat" :channels ("#rcirc")
+ :port 6697 :encryption tls))
+ '(("irc.libera.chat" :channels ("#rcirc"))))
"An alist of IRC connections to establish when running `rcirc'.
Each element looks like (SERVER-NAME PARAMETERS).
@@ -120,7 +120,8 @@ rcirc-server-alist
(:channels (repeat string))
(:encryption (choice (const tls)
(const plain)))
- (:server-alias string)))))
+ (:server-alias string))))
+ :version "28.1")
(defcustom rcirc-default-port 6667
"The default port to connect to."
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Check-auth-source-for-server-password.patch --]
[-- Type: text/x-diff, Size: 1228 bytes --]
From 7d7c360ad9a7c249a19d8d8f7ac1afd2f9678a77 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 4 Jun 2021 14:03:54 +0200
Subject: [PATCH 02/11] Check auth-source for server password
---
lisp/net/rcirc.el | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 90b61badf0..67dcf3e4ea 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -44,6 +44,7 @@
(require 'cl-lib)
(require 'ring)
(require 'time-date)
+(require 'auth-source)
(eval-when-compile (require 'subr-x))
(defconst rcirc-id-string (concat "rcirc on GNU Emacs " emacs-version))
@@ -500,6 +501,12 @@ rcirc
(encryption (plist-get (cdr c) :encryption))
(server-alias (plist-get (cdr c) :server-alias))
contact)
+ (when-let (((not password))
+ (auth (auth-source-search :host server
+ :user user-name
+ :port port))
+ (fn (plist-get (car auth) :secret)))
+ (setq password (funcall fn)))
(when server
(let (connected)
(dolist (p (rcirc-process-list))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-Define-rcirc-url-regexp-using-browse-url-button-rege.patch --]
[-- Type: text/x-diff, Size: 1653 bytes --]
From 47e95361abb5ab7445feedf4a701ffaabde2dc44 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 4 Jun 2021 14:04:34 +0200
Subject: [PATCH 03/11] Define rcirc-url-regexp using browse-url-button-regexp
---
lisp/net/rcirc.el | 21 ++-------------------
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 67dcf3e4ea..00d48ba0e2 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -45,6 +45,7 @@
(require 'ring)
(require 'time-date)
(require 'auth-source)
+(require 'browse-url)
(eval-when-compile (require 'subr-x))
(defconst rcirc-id-string (concat "rcirc on GNU Emacs " emacs-version))
@@ -2414,25 +2415,7 @@ rcirc-facify
(rcirc-add-face 0 (length string) face string)
string))
-(defvar rcirc-url-regexp
- (concat
- "\\b\\(\\(www\\.\\|\\(s?https?\\|ftp\\|file\\|gopher\\|"
- "nntp\\|news\\|telnet\\|wais\\|mailto\\|info\\):\\)"
- "\\(//[-a-z0-9_.]+:[0-9]*\\)?"
- (if (string-match "[[:digit:]]" "1") ;; Support POSIX?
- (let ((chars "-a-z0-9_=#$@~%&*+\\/[:word:]")
- (punct "!?:;.,"))
- (concat
- "\\(?:"
- ;; Match paired parentheses, e.g. in Wikipedia URLs:
- "[" chars punct "]+" "(" "[" chars punct "]+" ")" "[" chars "]"
- "\\|"
- "[" chars punct "]+" "[" chars "]"
- "\\)"))
- (concat ;; XEmacs 21.4 doesn't support POSIX.
- "\\([-a-z0-9_=!?#$@~%&*+\\/:;.,]\\|\\w\\)+"
- "\\([-a-z0-9_=#$@~%&*+\\/]\\|\\w\\)"))
- "\\)")
+(defvar rcirc-url-regexp browse-url-button-regexp
"Regexp matching URLs. Set to nil to disable URL features in rcirc.")
;; cf cl-remove-if-not
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-Fix-checkdoc-complaints-and-related-issues.patch --]
[-- Type: text/x-diff, Size: 47855 bytes --]
From 599cd7c092fe0f7675a93ba63b3b0af177ed1a5a Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 4 Jun 2021 14:14:35 +0200
Subject: [PATCH 04/11] Fix checkdoc complaints and related issues
---
lisp/net/rcirc.el | 434 +++++++++++++++++++++++++++++++++++-----------
1 file changed, 334 insertions(+), 100 deletions(-)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 00d48ba0e2..1f925b00b1 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -25,7 +25,7 @@
;;; Commentary:
;; Internet Relay Chat (IRC) is a form of instant communication over
-;; the Internet. It is mainly designed for group (many-to-many)
+;; the Internet. It is mainly designed for group (many-to-many)
;; communication in discussion forums called channels, but also allows
;; one-to-one communication.
@@ -47,6 +47,7 @@
(require 'auth-source)
(require 'browse-url)
(eval-when-compile (require 'subr-x))
+(eval-when-compile (require 'rx))
(defconst rcirc-id-string (concat "rcirc on GNU Emacs " emacs-version))
@@ -110,8 +111,9 @@ rcirc-server-alist
`:server-alias'
-VALUE must be a string that will be used instead of the server name for
-display purposes. If absent, the real server name will be displayed instead."
+VALUE must be a string that will be used instead of the server
+name for display purposes. If absent, the real server name will
+be displayed instead."
:type '(alist :key-type string
:value-type (plist :options
((:nick string)
@@ -182,17 +184,18 @@ rcirc-url-max-length
(integer :tag "Number of characters")))
(defvar-local rcirc-ignore-buffer-activity-flag nil
- "If non-nil, ignore activity in this buffer.")
+ "Non-nil means ignore activity in this buffer.")
(defvar-local rcirc-low-priority-flag nil
- "If non-nil, activity in this buffer is considered low priority.")
+ "Non-nil means activity in this buffer is considered low priority.")
(defcustom rcirc-omit-responses
'("JOIN" "PART" "QUIT" "NICK")
"Responses which will be hidden when `rcirc-omit-mode' is enabled."
:type '(repeat string))
-(defvar rcirc-prompt-start-marker nil)
+(defvar rcirc-prompt-start-marker nil
+ "Marker indicating the beginning of the message prompt.")
(define-minor-mode rcirc-omit-mode
"Toggle the hiding of \"uninteresting\" lines.
@@ -231,8 +234,7 @@ rcirc-buffer-maximum-lines
(integer :tag "Number of lines")))
(defcustom rcirc-scroll-show-maximum-output t
- "If non-nil, scroll buffer to keep the point at the bottom of
-the window."
+ "Non-nil means scroll to keep the point at the bottom of the window."
:type 'boolean)
(defcustom rcirc-authinfo nil
@@ -293,8 +295,9 @@ rcirc-prompt
%s is the server.
%t is the buffer target, a channel or a user.
-Setting this alone will not affect the prompt;
-use either M-x customize or also call `rcirc-update-prompt'."
+Setting this alone will not affect the prompt; use either
+\\[execute-extended-command] customize or also call
+`rcirc-update-prompt'."
:type 'string
:set #'rcirc-set-changed
:initialize 'custom-initialize-default)
@@ -388,11 +391,14 @@ rcirc-kill-channel-buffers
:version "24.3"
:type 'boolean)
-(defvar rcirc-nick nil)
+(defvar rcirc-nick nil
+ "The nickname used for the current connection.")
-(defvar rcirc-prompt-end-marker nil)
+(defvar rcirc-prompt-end-marker nil
+ "Marker indicating the end of the message prompt.")
-(defvar rcirc-nick-table nil)
+(defvar rcirc-nick-table nil
+ "Hash table mapping nicks to channels.")
(defvar rcirc-recent-quit-alist nil
"Alist of nicks that have recently quit or parted the channel.")
@@ -405,8 +411,8 @@ rcirc-nick-syntax-table
table)
"Syntax table which includes all nick characters as word constituents.")
-;; each process has an alist of (target . buffer) pairs
-(defvar rcirc-buffer-alist nil)
+(defvar rcirc-buffer-alist nil
+ "Alist of (TARGET . BUFFER) pairs.")
(defvar rcirc-activity nil
"List of buffers with unviewed activity.")
@@ -432,7 +438,8 @@ rcirc-timeout-seconds
"Kill connection after this many seconds if there is no activity.")
\f
-(defvar rcirc-startup-channels nil)
+(defvar rcirc-startup-channels nil
+ "List of channel names to join after authenticating.")
(defvar rcirc-server-name-history nil
"History variable for \\[rcirc] call.")
@@ -539,23 +546,43 @@ rcirc
(defalias 'irc 'rcirc)
\f
-(defvar rcirc-process-output nil)
-(defvar rcirc-topic nil)
-(defvar rcirc-keepalive-timer nil)
-(defvar rcirc-last-server-message-time nil)
-(defvar rcirc-server nil) ; server provided by server
-(defvar rcirc-server-name nil) ; server name given by 001 response
-(defvar rcirc-timeout-timer nil)
-(defvar rcirc-user-authenticated nil)
-(defvar rcirc-user-disconnect nil)
-(defvar rcirc-connecting nil)
-(defvar rcirc-connection-info nil)
-(defvar rcirc-process nil)
+(defvar rcirc-process-output nil
+ "Partial message response.")
+(defvar rcirc-topic nil
+ "Topic of the current channel.")
+(defvar rcirc-keepalive-timer nil
+ "Timer for sending KEEPALIVE message.")
+(defvar rcirc-last-server-message-time nil
+ "Timestamp for the last server response.")
+(defvar rcirc-server nil
+ "Server provided by server.")
+(defvar rcirc-server-name nil
+ "Server name given by 001 response.")
+(defvar rcirc-timeout-timer nil
+ "Timer for determining a network timeout.")
+(defvar rcirc-user-authenticated nil
+ "Flag indicating if the user is authenticated.")
+(defvar rcirc-user-disconnect nil
+ "Flag indicating if the connection was broken.")
+(defvar rcirc-connecting nil
+ "Flag indicating if the connection is being established.")
+(defvar rcirc-connection-info nil
+ "Information about the current connection.
+If defined, it is a list of this form (SERVER PORT NICK USER-NAME
+FULL-NAME STARTUP-CHANNELS PASSWORD ENCRYPTION SERVER-ALIAS).
+See `rcirc-connect' for more details on these variables.")
+(defvar rcirc-process nil
+ "Network process for the current connection.")
;;;###autoload
(defun rcirc-connect (server &optional port nick user-name
full-name startup-channels password encryption
server-alias)
+ "Connect to SERVER.
+The arguments PORT, NICK, USER-NAME, FULL-NAME, PASSWORD,
+ENCRYPTION, SERVER-ALIAS are interpreted as in
+`rcirc-server-alist'. STARTUP-CHANNELS is a list of channels
+that are joined after authentication."
(save-excursion
(message "Connecting to %s..." (or server-alias server))
(let* ((inhibit-eol-conversion)
@@ -619,11 +646,13 @@ rcirc-connect
process)))
(defmacro with-rcirc-process-buffer (process &rest body)
+ "Evaluate BODY in the buffer of PROCESS."
(declare (indent 1) (debug t))
`(with-current-buffer (process-buffer ,process)
,@body))
(defmacro with-rcirc-server-buffer (&rest body)
+ "Evaluate BODY in the server buffer of the current channel."
(declare (indent 0) (debug t))
`(with-current-buffer rcirc-server-buffer
,@body))
@@ -659,14 +688,18 @@ rcirc-keepalive
(setq rcirc-keepalive-timer nil)))
(defun rcirc-handler-ctcp-KEEPALIVE (process _target _sender message)
+ "Uptime header in PROCESS buffer.
+MESSAGE should contain a timestamp, indicating when the KEEPALIVE
+message was generated."
(with-rcirc-process-buffer process
(setq header-line-format
(format "%f" (float-time
(time-since (string-to-number message)))))))
-(defvar rcirc-debug-buffer "*rcirc debug*")
+(defvar rcirc-debug-buffer "*rcirc debug*"
+ "Buffer name for debugging messages.")
(defvar rcirc-debug-flag nil
- "If non-nil, write information to `rcirc-debug-buffer'.")
+ "Non-nil means write information to `rcirc-debug-buffer'.")
(defun rcirc-debug (process text)
"Add an entry to the debug log including PROCESS and TEXT.
Debug text is appended to `rcirc-debug-buffer' if `rcirc-debug-flag'
@@ -728,6 +761,8 @@ rcirc-sentinel
(run-hook-with-args 'rcirc-sentinel-functions process sentinel))))
(defun rcirc-disconnect-buffer (&optional buffer)
+ "Disconnect BUFFER.
+If BUFFER is nil, default to the current buffer."
(with-current-buffer (or buffer (current-buffer))
;; set rcirc-target to nil for each channel so cleanup
;; doesn't happen when we reconnect
@@ -765,6 +800,7 @@ rcirc-filter
(rcirc-process-server-response process line))))))
(defun rcirc-reschedule-timeout (process)
+ "Update timeout indicator for PROCESS."
(with-rcirc-process-buffer process
(when (not rcirc-connecting)
(with-rcirc-process-buffer process
@@ -776,8 +812,10 @@ rcirc-reschedule-timeout
(defun rcirc-delete-process (process)
(delete-process process))
-(defvar rcirc-trap-errors-flag t)
+(defvar rcirc-trap-errors-flag t
+ "Non-nil means Lisp errors are degraded to error messages.")
(defun rcirc-process-server-response (process text)
+ "Parse TEXT as received from PROCESS."
(if rcirc-trap-errors-flag
(condition-case err
(rcirc-process-server-response-1 process text)
@@ -786,13 +824,21 @@ rcirc-process-server-response
(format "\"%s\" %s" text err) t)))
(rcirc-process-server-response-1 process text)))
-(defun rcirc-process-server-response-1 (process text)
+(defconst rcirc-process-regexp
;; See https://tools.ietf.org/html/rfc2812#section-2.3.1. We're a
;; bit more accepting than the RFC: We allow any non-space
;; characters in the command name, multiple spaces between
;; arguments, and allow the last argument to omit the leading ":",
;; even if there are less than 15 arguments.
- (if (string-match "^\\(:\\([^ ]+\\) \\)?\\([^ ]+\\)" text)
+ (rx line-start
+ (optional
+ (group ":" (group (one-or-more (not (any " ")))) " "))
+ (group (one-or-more (not (any " ")))))
+ "Regular expression used for parsing server response.")
+
+(defun rcirc-process-server-response-1 (process text)
+ "Parse TEXT as received from PROCESS."
+ (if (string-match rcirc-process-regexp text)
(let* ((user (match-string 2 text))
(sender (rcirc-user-nick user))
(cmd (match-string 3 text))
@@ -820,12 +866,17 @@ rcirc-responses-no-activity
"Responses that don't trigger activity in the mode-line indicator.")
(defun rcirc-handler-generic (process response sender args _text)
- "Generic server response handler."
+ "Generic server response handler.
+This handler is called, when no more specific handler could be
+found. PROCESS, SENDER and RESPONSE are passed on to
+`rcirc-print'. ARGS are concatenated into a single string and
+used as the message body."
(rcirc-print process sender response nil
(mapconcat 'identity (cdr args) " ")
(not (member response rcirc-responses-no-activity))))
(defun rcirc--connection-open-p (process)
+ "Check if PROCESS is open or running."
(memq (process-status process) '(run open)))
(defun rcirc-send-string (process string)
@@ -839,6 +890,7 @@ rcirc-send-string
(process-send-string process string)))
(defun rcirc-send-privmsg (process target string)
+ "Send TARGET the message in STRING via PROCESS."
(cl-check-type target string)
(rcirc-send-string process (format "PRIVMSG %s :%s" target string)))
@@ -846,6 +898,7 @@ rcirc-send-ctcp
(let ((args (if args (concat " " args) "")))
(rcirc-send-privmsg process target
(format "\C-a%s%s\C-a" request args))))
+ "Send TARGET a REQUEST via PROCESS."
(defun rcirc-buffer-process (&optional buffer)
"Return the process associated with channel BUFFER.
@@ -908,13 +961,18 @@ rcirc-send-message
(unless silent
(rcirc-print process (rcirc-nick process) response target msg)))))
-(defvar rcirc-input-ring nil)
-(defvar rcirc-input-ring-index 0)
+(defvar rcirc-input-ring nil
+ "Ring object for input.")
+
+(defvar rcirc-input-ring-index 0
+ "Current position in the input ring.")
(defun rcirc-prev-input-string (arg)
+ "Move ARG elements ahead in the input ring."
(ring-ref rcirc-input-ring (+ rcirc-input-ring-index arg)))
(defun rcirc-insert-prev-input ()
+ "Insert previous element in input ring."
(interactive)
(when (<= rcirc-prompt-end-marker (point))
(delete-region rcirc-prompt-end-marker (point-max))
@@ -922,6 +980,7 @@ rcirc-insert-prev-input
(setq rcirc-input-ring-index (1+ rcirc-input-ring-index))))
(defun rcirc-insert-next-input ()
+ "Insert next element in input ring."
(interactive)
(when (<= rcirc-prompt-end-marker (point))
(delete-region rcirc-prompt-end-marker (point-max))
@@ -966,8 +1025,11 @@ rcirc-completion-at-point
rcirc-target))))
(list beg (point) table))))
-(defvar rcirc-completions nil)
-(defvar rcirc-completion-start nil)
+(defvar rcirc-completions nil
+ "List of possible completions to cycle through.")
+
+(defvar rcirc-completion-start nil
+ "Point indicating where completion starts.")
(defun rcirc-complete ()
"Cycle through completions from list of nicks in channel or IRC commands.
@@ -997,12 +1059,12 @@ rcirc-complete
(t completion))))))
(defun set-rcirc-decode-coding-system (coding-system)
- "Set the decode coding system used in this channel."
+ "Set the decode CODING-SYSTEM used in this channel."
(interactive "zCoding system for incoming messages: ")
(setq-local rcirc-decode-coding-system coding-system))
(defun set-rcirc-encode-coding-system (coding-system)
- "Set the encode coding system used in this channel."
+ "Set the encode CODING-SYSTEM used in this channel."
(interactive "zCoding system for outgoing messages: ")
(setq-local rcirc-encode-coding-system coding-system))
@@ -1040,7 +1102,8 @@ rcirc-short-buffer-name
(defvar rcirc-mode-hook nil
"Hook run when setting up rcirc buffer.")
-(defvar rcirc-last-post-time nil)
+(defvar rcirc-last-post-time nil
+ "Timestamp indicating last user action.")
(defvar rcirc-log-alist nil
"Alist of lines to log to disk when `rcirc-log-flag' is non-nil.
@@ -1161,7 +1224,7 @@ rcirc-update-prompt
'front-sticky t 'rear-nonsticky t))))))))
(defun rcirc-set-changed (option value)
- "Set OPTION to VALUE and do updates after a customization change."
+ "Set OPTION to VALUE and update after a customization change."
(set-default option value)
(cond ((eq option 'rcirc-prompt)
(rcirc-update-prompt 'all))
@@ -1204,10 +1267,11 @@ rcirc-kill-buffer-hook
(kill-buffer (cdr channel))))))
(defun rcirc-change-major-mode-hook ()
- "Part the channel when changing the major-mode."
+ "Part the channel when changing the major mode."
(rcirc-clean-up-buffer "Changed major mode"))
(defun rcirc-clean-up-buffer (reason)
+ "Clean up current buffer and part with REASON."
(let ((buffer (current-buffer)))
(rcirc-clear-activity buffer)
(when (and (rcirc-buffer-process)
@@ -1296,6 +1360,8 @@ rcirc-send-input
(setq rcirc-input-ring-index 0))))))
(defun rcirc-fill-paragraph (&optional justify)
+ "Implementation for `fill-paragraph-function'.
+The argument JUSTIFY is passed on to `fill-region'."
(interactive "P")
(when (> (point) rcirc-prompt-end-marker)
(save-restriction
@@ -1305,12 +1371,14 @@ rcirc-fill-paragraph
(defun rcirc-process-input-line (line)
(if (string-match "^/\\([^ ]+\\) ?\\(.*\\)$" line)
+ "Process LINE as a message or a command."
(rcirc-process-command (match-string 1 line)
(match-string 2 line)
line)
(rcirc-process-message line)))
(defun rcirc-process-message (line)
+ "Process LINE as a message to be sent."
(if (not rcirc-target)
(message "Not joined (no target)")
(delete-region rcirc-prompt-end-marker (point))
@@ -1329,6 +1397,9 @@ rcirc-process-command
(if (string= command "me")
(rcirc-print process (rcirc-buffer-nick)
"ACTION" rcirc-target args)
+ "Process COMMAND with arguments ARGS.
+LINE is the raw input, from which COMMAND and ARGS was
+extracted."
(rcirc-print process (rcirc-buffer-nick)
"COMMAND" rcirc-target line))
(set-marker rcirc-prompt-end-marker (point))
@@ -1337,9 +1408,14 @@ rcirc-process-command
(rcirc-send-string process
(concat command " :" args)))))))
-(defvar-local rcirc-parent-buffer nil)
+
+(defvar-local rcirc-parent-buffer nil
+ "Message buffer that requested a multiline buffer.")
(put 'rcirc-parent-buffer 'permanent-local t)
-(defvar rcirc-window-configuration nil)
+
+(defvar rcirc-window-configuration nil
+ "Window configuration before creating multiline buffer.")
+
(defun rcirc-edit-multiline ()
"Move current edit to a dedicated buffer."
(interactive)
@@ -1435,9 +1511,10 @@ rcirc-response-formats
:value-type string))
(defun rcirc-format-response-string (process sender response target text)
- "Return a nicely-formatted response string, incorporating TEXT
-\(and perhaps other arguments). The specific formatting used
-is found by looking up RESPONSE in `rcirc-response-formats'."
+ "Return a formatted response string from SENDER, incorporating TEXT.
+The specific formatting used is found by looking up RESPONSE in
+`rcirc-response-formats'. PROCESS is the process object used for
+communication."
(with-temp-buffer
(insert (or (cdr (assoc response rcirc-response-formats))
(cdr (assq t rcirc-response-formats))))
@@ -1491,7 +1568,8 @@ rcirc-format-response-string
(buffer-substring (point-min) (point-max))))
(defun rcirc-target-buffer (process sender response target _text)
- "Return a buffer to print the server response."
+ "Return a buffer to print the server response from SENDER.
+PROCESS is the process object for the current connection."
(cl-assert (not (bufferp target)))
(with-rcirc-process-buffer process
(cond ((not target)
@@ -1507,8 +1585,9 @@ rcirc-target-buffer
((or (rcirc-get-buffer process target)
(rcirc-any-buffer process))))))
-(defvar-local rcirc-activity-types nil)
(defvar-local rcirc-last-sender nil)
+(defvar-local rcirc-activity-types nil
+ "List of symbols designating kinds of activities in a buffer.")
(defcustom rcirc-omit-threshold 100
"Lines since last activity from a nick before `rcirc-omit-responses' are omitted."
@@ -1521,14 +1600,16 @@ rcirc-log-process-buffers
(defun rcirc-last-quit-line (process nick target)
"Return the line number where NICK left TARGET.
-Returns nil if the information is not recorded."
+Returns nil if the information is not recorded.
+PROCESS is the process object for the current connection."
(let ((chanbuf (rcirc-get-buffer process target)))
(when chanbuf
(cdr (assoc-string nick (with-current-buffer chanbuf
rcirc-recent-quit-alist))))))
(defun rcirc-last-line (process nick target)
- "Return the line from the last activity from NICK in TARGET."
+ "Return the line from the last activity from NICK in TARGET.
+PROCESS is the process object for the current connection."
(let ((line (or (cdr (assoc-string target
(gethash nick (with-rcirc-server-buffer
rcirc-nick-table)) t))
@@ -1539,7 +1620,8 @@ rcirc-last-line
nil)))
(defun rcirc-elapsed-lines (process nick target)
- "Return the number of lines since activity from NICK in TARGET."
+ "Return the number of lines since activity from NICK in TARGET.
+PROCESS is the process object for the current connection."
(let ((last-activity-line (rcirc-last-line process nick target)))
(when (and last-activity-line
(> last-activity-line 0))
@@ -1551,7 +1633,6 @@ rcirc-markup-text-functions
rcirc-markup-urls
rcirc-markup-keywords
rcirc-markup-bright-nicks)
-
"List of functions used to manipulate text before it is printed.
Each function takes two arguments, SENDER, and RESPONSE. The
@@ -1561,7 +1642,8 @@ rcirc-markup-text-functions
(defun rcirc-print (process sender response target text &optional activity)
"Print TEXT in the buffer associated with TARGET.
Format based on SENDER and RESPONSE. If ACTIVITY is non-nil,
-record activity."
+record activity. PROCESS is the process object for the current
+connection."
(or text (setq text ""))
(unless (and (or (member sender rcirc-ignore-list)
(member (with-syntax-table rcirc-nick-syntax-table
@@ -1690,6 +1772,7 @@ rcirc-print
process sender response target text)))))
(defun rcirc-generate-log-filename (process target)
+ "Return filename for log file based on PROCESS and TARGET."
(if target
(rcirc-generate-new-buffer-name process target)
(process-name process)))
@@ -1711,7 +1794,9 @@ rcirc-log-filename-function
:type 'function)
(defun rcirc-log (process sender response target text)
- "Record line in `rcirc-log', to be later written to disk."
+ "Record TEXT from SENDER to TARGET to be logged.
+The message is logged in `rcirc-log', and is later written to
+disk. PROCESS is the process object for the current connection."
(let ((filename (funcall rcirc-log-filename-function process target)))
(unless (null filename)
(let ((cell (assoc-string filename rcirc-log-alist))
@@ -1750,14 +1835,17 @@ rcirc-view-log-file
rcirc-log-directory)))
(defun rcirc-join-channels (process channels)
- "Join CHANNELS."
+ "Join CHANNELS.
+PROCESS is the process object for the current connection."
(save-window-excursion
(dolist (channel channels)
(with-rcirc-process-buffer process
(rcirc-cmd-join channel process)))))
\f
;;; nick management
-(defvar rcirc-nick-prefix-chars "~&@%+")
+(defvar rcirc-nick-prefix-chars '(?~ ?& ?@ ?% ?+)
+ "List of junk characters to strip from nick prefixes.")
+
(defun rcirc-user-nick (user)
"Return the nick from USER. Remove any non-nick junk."
(save-match-data
@@ -1767,7 +1855,8 @@ rcirc-user-nick
user)))
(defun rcirc-nick-channels (process nick)
- "Return list of channels for NICK."
+ "Return list of channels for NICK.
+PROCESS is the process object for the current connection."
(with-rcirc-process-buffer process
(mapcar (lambda (x) (car x))
(gethash nick rcirc-nick-table))))
@@ -1777,7 +1866,7 @@ rcirc-put-nick-channel
Update the associated linestamp if LINE is non-nil.
If the record doesn't exist, and LINE is nil, set the linestamp
-to zero."
+to zero. PROCESS is the process object for the current connection."
(let ((nick (rcirc-user-nick nick)))
(with-rcirc-process-buffer process
(let* ((chans (gethash nick rcirc-nick-table))
@@ -1789,12 +1878,14 @@ rcirc-put-nick-channel
rcirc-nick-table))))))
(defun rcirc-nick-remove (process nick)
- "Remove NICK from table."
+ "Remove NICK from table.
+PROCESS is the process object for the current connection."
(with-rcirc-process-buffer process
(remhash nick rcirc-nick-table)))
(defun rcirc-remove-nick-channel (process nick channel)
- "Remove the CHANNEL from list associated with NICK."
+ "Remove the CHANNEL from list associated with NICK.
+PROCESS is the process object for the current connection."
(with-rcirc-process-buffer process
(let* ((chans (gethash nick rcirc-nick-table))
(newchans
@@ -1808,7 +1899,8 @@ rcirc-remove-nick-channel
(remhash nick rcirc-nick-table)))))
(defun rcirc-channel-nicks (process target)
- "Return the list of nicks associated with TARGET sorted by last activity."
+ "Return the list of nicks associated with TARGET sorted by last activity.
+PROCESS is the process object for the current connection."
(when target
(if (rcirc-channel-p target)
(with-rcirc-process-buffer process
@@ -1827,8 +1919,9 @@ rcirc-channel-nicks
(list target))))
(defun rcirc-ignore-update-automatic (nick)
- "Remove NICK from `rcirc-ignore-list'
-if NICK is also on `rcirc-ignore-list-automatic'."
+ "Check if NICK is in `rcirc-ignore-list-automatic'.
+If so, remove from `rcirc-ignore-list'. PROCESS is the process
+object for the current connection."
(when (member nick rcirc-ignore-list-automatic)
(setq rcirc-ignore-list-automatic
(delete nick rcirc-ignore-list-automatic)
@@ -1836,7 +1929,7 @@ rcirc-ignore-update-automatic
(delete nick rcirc-ignore-list))))
\f
(defun rcirc-nickname< (s1 s2)
- "Return t if IRC nickname S1 is less than S2, and nil otherwise.
+ "Return non-nil if IRC nickname S1 is less than S2, and nil otherwise.
Operator nicknames (@) are considered less than voiced
nicknames (+). Any other nicknames are greater than voiced
nicknames. The comparison is case-insensitive."
@@ -2032,6 +2125,7 @@ rcirc-update-activity-string
(run-hooks 'rcirc-update-activity-string-hook)))
(defun rcirc-activity-string (buffers)
+ "Generate activity string for all BUFFERS."
(mapconcat (lambda (b)
(let ((s (substring-no-properties (rcirc-short-buffer-name b))))
(with-current-buffer b
@@ -2050,7 +2144,7 @@ rcirc-short-buffer-name
(or rcirc-short-buffer-name (buffer-name))))
(defun rcirc-visible-buffers ()
- "Return a list of the visible buffers that are in rcirc-mode."
+ "Return a list of the visible buffers that are in `rcirc-mode'."
(let (acc)
(walk-windows (lambda (w)
(with-current-buffer (window-buffer w)
@@ -2058,13 +2152,16 @@ rcirc-visible-buffers
(push (current-buffer) acc)))))
acc))
-(defvar rcirc-visible-buffers nil)
+(defvar rcirc-visible-buffers nil
+ "List of visible IRC buffers.")
+
(defun rcirc-window-configuration-change ()
+ "Clear activity and overlay arrows, unless minibuffer is active."
(unless (minibuffer-window-active-p (minibuffer-window))
(rcirc-window-configuration-change-1)))
(defun rcirc-window-configuration-change-1 ()
- ;; clear activity and overlay arrows
+ "Clear activity and overlay arrows."
(let* ((old-activity rcirc-activity)
(hidden-buffers rcirc-visible-buffers))
@@ -2090,6 +2187,7 @@ rcirc-window-configuration-change-1
\f
;;; buffer name abbreviation
(defun rcirc-update-short-buffer-names ()
+ "Update variable `rcirc-short-buffer-name' for IRC buffers."
(let ((bufalist
(apply 'append (mapcar (lambda (process)
(with-rcirc-process-buffer process
@@ -2101,10 +2199,15 @@ rcirc-update-short-buffer-names
(setq rcirc-short-buffer-name (car i)))))))
(defun rcirc-abbreviate (pairs)
+ "Generate alist of abbreviated buffer names to buffers.
+PAIRS is the concatenated value of all `rcirc-buffer-alist'
+values, from each process."
(apply 'append (mapcar 'rcirc-rebuild-tree (rcirc-make-trees pairs))))
-(defun rcirc-rebuild-tree (tree &optional acc)
- (let ((ch (char-to-string (car tree))))
+(defun rcirc-rebuild-tree (tree)
+ "Merge prefix TREE into alist of unique prefixes to buffers."
+ (let ((ch (char-to-string (car tree)))
+ acc)
(dolist (x (cdr tree))
(if (listp x)
(setq acc (append acc
@@ -2116,6 +2219,12 @@ rcirc-rebuild-tree
acc))
(defun rcirc-make-trees (pairs)
+ "Generate tree prefix tree of buffer names.
+PAIRS is a list of (TARGET . BUFFER) entries. The resulting tree
+is a list of (CHAR . CHILDREN) cons-cells, where CHAR is the
+leading character and CHILDREN is either BUFFER when a unique
+prefix could be found or another tree if it shares the same
+prefix with another element in PAIRS."
(let (alist)
(mapc (lambda (pair)
(if (consp pair)
@@ -2148,9 +2257,13 @@ rcirc-make-trees
;; the current buffer/channel/user, and ARGS, which is a string
;; containing the text following the /cmd.
-(defmacro defun-rcirc-command (command argument docstring interactive-form
- &rest body)
- "Define a command."
+(defmacro defun-rcirc-command (command argument
+ docstring interactive-form
+ &rest body)
+ "Define COMMAND that operates on ARGUMENT.
+This macro internally defines an interactive function, prefixing
+COMMAND with `rcirc-cmd-'. DOCSTRING, INTERACTIVE-FORM and BODY
+are passed directly to `defun'."
`(progn
(add-to-list 'rcirc-client-commands ,(concat "/" (symbol-name command)))
(defun ,(intern (concat "rcirc-cmd-" (symbol-name command)))
@@ -2323,6 +2436,8 @@ kick
(rcirc-send-string process (concat "KICK " target " " argstring))))
(defun rcirc-cmd-ctcp (args &optional process _target)
+ "Handle ARGS as a CTCP command.
+PROCESS is the process object for the current connection."
(if (string-match "^\\([^ ]+\\)\\s-+\\(.+\\)$" args)
(let* ((target (match-string 1 args))
(request (upcase (match-string 2 args)))
@@ -2334,11 +2449,14 @@ rcirc-cmd-ctcp
"usage: /ctcp NICK REQUEST")))
(defun rcirc-ctcp-sender-PING (process target _request)
- "Send a CTCP PING message to TARGET."
+ "Send a CTCP PING message to TARGET.
+PROCESS is the process object for the current connection."
(let ((timestamp (format-time-string "%s")))
(rcirc-send-ctcp process target "PING" timestamp)))
(defun rcirc-cmd-me (args process target)
+ "Send an action message ARGS to TARGET.
+PROCESS is the process object for the current connection."
(when target (rcirc-send-ctcp process target "ACTION" args)))
(defun rcirc-add-or-remove (set &rest elements)
@@ -2348,6 +2466,7 @@ rcirc-add-or-remove
(delete elt set)
(cons elt set)))))
set)
+ "Toggle membership of ELEMENTS in SET."
(defun-rcirc-command ignore (nick)
"Manage the ignore list.
@@ -2441,11 +2560,13 @@ rcirc-browse-url
arg)))
\f
(defun rcirc-markup-timestamp (_sender _response)
+ "Insert a timestamp."
(goto-char (point-min))
(insert (rcirc-facify (format-time-string rcirc-time-format)
'rcirc-timestamp)))
(defun rcirc-markup-attributes (_sender _response)
+ "Highlight IRC markup, indicated by ASCII control codes."
(while (re-search-forward "\\([\C-b\C-_\C-v]\\).*?\\(\\1\\|\C-o\\)" nil t)
(rcirc-add-face (match-beginning 0) (match-end 0)
(cl-case (char-after (match-beginning 1))
@@ -2463,6 +2584,9 @@ rcirc-markup-attributes
(delete-region (match-beginning 0) (match-end 0))))
(defun rcirc-markup-my-nick (_sender response)
+ "Highlight the users nick.
+If RESPONSE indicates that the nick was mentioned in a message,
+highlight the entire line and record the activity."
(with-syntax-table rcirc-nick-syntax-table
(while (re-search-forward (concat "\\b"
(regexp-quote (rcirc-nick
@@ -2477,6 +2601,7 @@ rcirc-markup-my-nick
(rcirc-record-activity (current-buffer) 'nick)))))
(defun rcirc-markup-urls (_sender _response)
+ "Highlight and activate URLs."
(while (and rcirc-url-regexp ; nil means disable URL catching.
(re-search-forward rcirc-url-regexp nil t))
(let* ((start (match-beginning 0))
@@ -2500,6 +2625,10 @@ rcirc-markup-urls
(push (cons url start) rcirc-urls)))))
(defun rcirc-markup-keywords (sender response)
+ "Highlight keywords as specified by `rcirc-keywords'.
+Keywords are only highlighted in messages (as indicated by
+RESPONSE) when they were not written by the user (as indicated by
+SENDER)."
(when (and (string= response "PRIVMSG")
(not (string= sender (rcirc-nick (rcirc-buffer-process)))))
(let* ((target (or rcirc-target ""))
@@ -2514,6 +2643,9 @@ rcirc-markup-keywords
(rcirc-record-activity (current-buffer) 'keyword))))))
(defun rcirc-markup-bright-nicks (_sender response)
+ "Highlight nicks brightly as specified by `rcirc-bright-nicks'.
+This highlighting only takes place in name lists (as indicated by
+RESPONSE)."
(when (and rcirc-bright-nicks
(string= response "NAMES"))
(with-syntax-table rcirc-nick-syntax-table
@@ -2523,6 +2655,8 @@ rcirc-markup-bright-nicks
(defun rcirc-markup-fill (_sender response)
(when (not (string= response "372")) ; /motd
+ "Fill messages as configured by `rcirc-fill-column'.
+MOTD messages are not filled (as indicated by RESPONSE)."
(let ((fill-prefix
(or rcirc-fill-prefix
(make-string (- (point) (line-beginning-position)) ?\s)))
@@ -2539,8 +2673,11 @@ rcirc-markup-fill
;; server or a user, depending on the command, the ARGS, which is a
;; list of strings, and the TEXT, which is the original server text,
;; verbatim
-(defun rcirc-handler-001 (process sender args text)
- (rcirc-handler-generic process "001" sender args text)
+(defun rcirc-handler-001 (process sender args _text)
+ "Handle welcome message.
+SENDER and ARGS are used to initialize the current connection.
+PROCESS is the process object for the current connection."
+ (rcirc-handler-generic process "001" sender args nil)
(with-rcirc-process-buffer process
(setq rcirc-connecting nil)
(rcirc-reschedule-timeout process)
@@ -2564,11 +2701,16 @@ rcirc-handler-001
(rcirc-join-channels process rcirc-startup-channels))))
(defun rcirc-join-channels-post-auth (process)
- "Join `rcirc-startup-channels' after authenticating."
+ "Join `rcirc-startup-channels' after authenticating.
+PROCESS is the process object for the current connection."
(with-rcirc-process-buffer process
(rcirc-join-channels process rcirc-startup-channels)))
(defun rcirc-handler-PRIVMSG (process sender args text)
+ "Handle a (private) message from SENDER.
+ARGS should have the form (TARGET MESSAGE). TEXT is the verbatim
+message as received from the server. PROCESS is the process
+object for the current connection."
(rcirc-check-auth-status process sender args text)
(let ((target (if (rcirc-channel-p (car args))
(car args)
@@ -2582,6 +2724,10 @@ rcirc-handler-PRIVMSG
(rcirc-put-nick-channel process sender target rcirc-current-line))))
(defun rcirc-handler-NOTICE (process sender args text)
+ "Handle a notice message from SENDER.
+ARGS should have the form (TARGET MESSAGE).
+TEXT is the verbatim message as received from the server.
+PROCESS is the process object for the current connection."
(rcirc-check-auth-status process sender args text)
(let ((target (car args))
(message (cadr args)))
@@ -2591,7 +2737,7 @@ rcirc-handler-NOTICE
(rcirc-print process sender "NOTICE"
(cond ((rcirc-channel-p target)
target)
- ;;; -ChanServ- [#gnu] Welcome...
+ ;; -ChanServ- [#gnu] Welcome...
((string-match "\\[\\(#[^] ]+\\)\\]" message)
(match-string 1 message))
(sender
@@ -2603,7 +2749,9 @@ rcirc-handler-NOTICE
(defun rcirc-check-auth-status (process sender args _text)
"Check if the user just authenticated.
If authenticated, runs `rcirc-authenticated-hook' with PROCESS as
-the only argument."
+the only argument. ARGS should have the form (TARGET MESSAGE).
+SENDER is used the determine the authentication method. PROCESS
+is the process object for the current connection."
(with-rcirc-process-buffer process
(when (and (not rcirc-user-authenticated)
rcirc-authenticate-before-join
@@ -2633,9 +2781,17 @@ rcirc-check-auth-status
(remove-hook 'rcirc-authenticated-hook 'rcirc-join-channels-post-auth t))))))
(defun rcirc-handler-WALLOPS (process sender args _text)
+ "Handle WALLOPS message from SENDER.
+ARGS should have the form (MESSAGE).
+PROCESS is the process object for the current
+connection."
(rcirc-print process sender "WALLOPS" sender (car args) t))
(defun rcirc-handler-JOIN (process sender args _text)
+ "Handle JOIN message from SENDER.
+ARGS should have the form (CHANNEL).
+PROCESS is the process object for the current
+connection."
(let ((channel (car args)))
(with-current-buffer (rcirc-get-buffer-create process channel)
;; when recently rejoining, restore the linestamp
@@ -2657,6 +2813,8 @@ rcirc-handler-JOIN
;; PART and KICK are handled the same way
(defun rcirc-handler-PART-or-KICK (process _response channel _sender nick _args)
+ "Remove NICK from CHANNEL.
+PROCESS is the process object for the current connection."
(rcirc-ignore-update-automatic nick)
(if (not (string= nick (rcirc-nick process)))
;; this is someone else leaving
@@ -2674,6 +2832,9 @@ rcirc-handler-PART-or-KICK
(rcirc-disconnect-buffer buffer)))))
(defun rcirc-handler-PART (process sender args _text)
+ "Handle PART message from SENDER.
+ARGS should have the form (CHANNEL REASON).
+PROCESS is the process object for the current connection."
(let* ((channel (car args))
(reason (cadr args))
(message (concat channel " " reason)))
@@ -2685,6 +2846,9 @@ rcirc-handler-PART
(rcirc-handler-PART-or-KICK process "PART" channel sender sender reason)))
(defun rcirc-handler-KICK (process sender args _text)
+ "Handle PART message from SENDER.
+ARGS should have the form (CHANNEL NICK REASON).
+PROCESS is the process object for the current connection."
(let* ((channel (car args))
(nick (cadr args))
(reason (nth 2 args))
@@ -2697,7 +2861,8 @@ rcirc-handler-KICK
(rcirc-handler-PART-or-KICK process "KICK" channel sender nick reason)))
(defun rcirc-maybe-remember-nick-quit (process nick channel)
- "Remember NICK as leaving CHANNEL if they recently spoke."
+ "Remember NICK as leaving CHANNEL if they recently spoke.
+PROCESS is the process object for the current connection."
(let ((elapsed-lines (rcirc-elapsed-lines process nick channel)))
(when (and elapsed-lines
(< elapsed-lines rcirc-omit-threshold))
@@ -2713,6 +2878,8 @@ rcirc-maybe-remember-nick-quit
rcirc-recent-quit-alist))))))))))
(defun rcirc-handler-QUIT (process sender args _text)
+ "Handle QUIT message from SENDER.
+PROCESS is the process object for the current connection."
(rcirc-ignore-update-automatic sender)
(mapc (lambda (channel)
;; broadcast quit message each channel
@@ -2723,6 +2890,9 @@ rcirc-handler-QUIT
(rcirc-nick-remove process sender))
(defun rcirc-handler-NICK (process sender args _text)
+ "Handle NICK message from SENDER.
+ARGS should have the form (NEW-NICK).
+PROCESS is the process object for the current connection."
(let* ((old-nick sender)
(new-nick (car args))
(channels (rcirc-nick-channels process old-nick)))
@@ -2755,20 +2925,29 @@ rcirc-handler-NICK
(defun rcirc-handler-PING (process _sender args _text)
(rcirc-send-string process (concat "PONG :" (car args))))
+ "Respond to a PING with a PONG.
+ARGS should have the form (MESSAGE). MESSAGE is relayed back to
+the server. PROCESS is the process object for the current
+connection."
(defun rcirc-handler-PONG (_process _sender _args _text)
- ;; do nothing
- )
+ "Ignore all incoming PONG messages.")
(defun rcirc-handler-TOPIC (process sender args _text)
+ "Note the topic change from SENDER.
+PROCESS is the process object for the current connection."
(let ((topic (cadr args)))
(rcirc-print process sender "TOPIC" (car args) topic)
(with-current-buffer (rcirc-get-buffer process (car args))
(setq rcirc-topic topic))))
-(defvar rcirc-nick-away-alist nil)
+(defvar rcirc-nick-away-alist nil
+ "Alist from nicks to away messages.")
+
(defun rcirc-handler-301 (process _sender args text)
- "RPL_AWAY"
+ "Handle away messages (RPL_AWAY).
+ARGS should have the form (NICK AWAY-MESSAGE).
+PROCESS is the process object for the current connection."
(let* ((nick (cadr args))
(rec (assoc-string nick rcirc-nick-away-alist))
(away-message (nth 2 args)))
@@ -2782,7 +2961,9 @@ rcirc-handler-301
rcirc-nick-away-alist))))))
(defun rcirc-handler-317 (process sender args _text)
- "RPL_WHOISIDLE"
+ "Handle idle messages from SENDER (RPL_WHOISIDLE).
+ARGS should have the form (NICK IDLE-SECS SIGNON-TIME).
+PROCESS is the process object for the current connection."
(let* ((nick (nth 1 args))
(idle-secs (string-to-number (nth 2 args)))
(idle-string (format-seconds "%yy %dd %hh %mm %z%ss" idle-secs))
@@ -2793,15 +2974,20 @@ rcirc-handler-317
(rcirc-print process sender "317" nil message t)))
(defun rcirc-handler-332 (process _sender args _text)
- "RPL_TOPIC"
+ "Update topic when notified by server (RPL_TOPIC).
+ARGS should have the form (CHANNEL TOPIC).
+PROCESS is the process object for the current connection."
(let ((buffer (or (rcirc-get-buffer process (cadr args))
(rcirc-get-temp-buffer-create process (cadr args)))))
(with-current-buffer buffer
(setq rcirc-topic (nth 2 args)))))
(defun rcirc-handler-333 (process sender args _text)
- "333 says who set the topic and when.
-Not in rfc1459.txt"
+ "Update when and who set the current topic.
+ARGS has the form (CHANNEL SETTER TIME). SENDER is passed on to
+`rcirc-print'. PROCESS is the process object for the current
+connection. This is a non-standard extension, not specified in
+RFC1459."
(let ((buffer (or (rcirc-get-buffer process (cadr args))
(rcirc-get-temp-buffer-create process (cadr args)))))
(with-current-buffer buffer
@@ -2812,10 +2998,17 @@ rcirc-handler-333
(format "%s (%s on %s)" rcirc-topic setter time))))))
(defun rcirc-handler-477 (process sender args _text)
- "ERR_NOCHANMODES"
+ "Notify user that CHANNEL does not support modes (ERR_NOCHANMODES).
+ARGS has the form (CHANNEL MESSAGE). SENDER is passed on to
+`rcirc-print'. PROCESS is the process object for the current
+connection."
(rcirc-print process sender "477" (cadr args) (nth 2 args)))
(defun rcirc-handler-MODE (process sender args _text)
+ "Handle MODE messages.
+ARGS should have the form (TARGET . MESSAGE-LIST).
+SENDER is passed on to `rcirc-print'.
+PROCESS is the process object for the current connection."
(let ((target (car args))
(msg (mapconcat 'identity (cdr args) " ")))
(rcirc-print process sender "MODE"
@@ -2836,7 +3029,9 @@ rcirc-get-temp-buffer-create
(get-buffer-create tmpnam)))
(defun rcirc-handler-353 (process _sender args _text)
- "RPL_NAMREPLY"
+ "Start handling list of users (RPL_NAMREPLY).
+ARGS should have the form (TYPE CHANNEL . NICK-LIST).
+PROCESS is the process object for the current connection."
(let ((channel (nth 2 args))
(names (or (nth 3 args) "")))
(mapc (lambda (nick)
@@ -2849,7 +3044,9 @@ rcirc-handler-353
(insert (car (last args)) " "))))
(defun rcirc-handler-366 (process sender args _text)
- "RPL_ENDOFNAMES"
+ "Handle end of user list (RPL_ENDOFNAMES).
+SENDER is passed on to `rcirc-print'.
+PROCESS is the process object for the current connection."
(let* ((channel (cadr args))
(buffer (rcirc-get-temp-buffer-create process channel)))
(with-current-buffer buffer
@@ -2859,7 +3056,10 @@ rcirc-handler-366
(kill-buffer buffer)))
(defun rcirc-handler-433 (process sender args text)
- "ERR_NICKNAMEINUSE"
+ "Warn user that nick is used (ERR_NICKNAMEINUSE).
+ARGS should have the form (NICK CHANNEL WARNING).
+SENDER is passed on to `rcirc-handler-generic'.
+PROCESS is the process object for the current connection."
(rcirc-handler-generic process "433" sender args text)
(with-rcirc-process-buffer process
(let* ((length (string-to-number
@@ -2868,8 +3068,10 @@ rcirc-handler-433
(rcirc-cmd-nick (rcirc--make-new-nick (cadr args) length) nil process))))
(defun rcirc--make-new-nick (nick length)
- ;; If we already have some ` chars at the end, then shorten the
- ;; non-` bit of the name.
+ "Attempt to create a unused nickname out of NICK.
+A new nick may at most be LENGTH characters long. If we already
+have some ` chars at the end, then shorten the non-` bit of the
+name."
(when (= (length nick) length)
(setq nick (replace-regexp-in-string "[^`]\\(`+\\)\\'" "\\1" nick)))
(concat
@@ -2879,7 +3081,14 @@ rcirc--make-new-nick
"`"))
(defun rcirc-handler-005 (process sender args text)
- "ERR_NICKNAMEINUSE"
+ "Register supported server features (RPL_ISUPPORT).
+ARGS should be a list of string feature parameters, either of the
+form \"PARAMETER\" to enable a feature, \"PARAMETER=VALUE\" to
+configure a specific option or \"-PARAMETER\" to disable a
+previously specified feature. SENDER is passed on to
+`rcirc-handler-generic'. PROCESS is the process object for the
+current connection. Note that this is not the behaviour as
+specified in RFC2812, where 005 stood for RPL_BOUNCE."
(rcirc-handler-generic process "005" sender args text)
(with-rcirc-process-buffer process
(setq rcirc-server-parameters (append rcirc-server-parameters args))))
@@ -2924,12 +3133,27 @@ rcirc-authenticate
(format "AUTH %s %s" nick (car args))))))))))
(defun rcirc-handler-INVITE (process sender args _text)
+ "Notify user of an invitation.
+SENDER and ARGS (in concatenated form) are passed on to
+`rcirc-print'. PROCESS is the process object for the current
+connection."
(rcirc-print process sender "INVITE" nil (mapconcat 'identity args " ") t))
(defun rcirc-handler-ERROR (process sender args _text)
+ "Print a error message.
+SENDER and ARGS (in concatenated form) are passed on to
+`rcirc-print'. PROCESS is the process object for the current
+connection."
(rcirc-print process sender "ERROR" nil (mapconcat 'identity args " ")))
(defun rcirc-handler-CTCP (process target sender text)
+ "Handle Client-To-Client-Protocol message TEXT.
+The message is addressed from SENDER to TARGET. Attempt to find
+an appropriate handler, by invoicing the function
+`rcirc-handler-ctcp-REQUEST', where REQUEST is the message type
+as extracted from TEXT. If no handler was found, an error
+message will be printed. PROCESS is the process object for the
+current connection."
(if (string-match "^\\([^ ]+\\) *\\(.*\\)$" text)
(let* ((request (upcase (match-string 1 text)))
(args (match-string 2 text))
@@ -2944,22 +3168,31 @@ rcirc-handler-CTCP
(rcirc-print process sender "CTCP" target
(format "%s" text) t))))))
-(defun rcirc-handler-ctcp-VERSION (process _target sender _args)
+(defun rcirc-handler-ctcp-VERSION (process _target sender _message)
+ "Handle a CTCP VERSION message from SENDER.
+PROCESS is the process object for the current connection."
(rcirc-send-string process
(concat "NOTICE " sender
" :\C-aVERSION " rcirc-id-string
"\C-a")))
-(defun rcirc-handler-ctcp-ACTION (process target sender args)
+(defun rcirc-handler-ctcp-ACTION (process target sender message)
+ "Handle a CTCP ACTION MESSAGE from SENDER to TARGET.
+PROCESS is the process object for the current connection."
(rcirc-print process sender "ACTION" target args t))
-(defun rcirc-handler-ctcp-TIME (process _target sender _args)
+(defun rcirc-handler-ctcp-TIME (process _target sender _message)
+ "Respond to CTCP TIME message from SENDER.
+PROCESS is the process object for the current connection."
(rcirc-send-string process
(concat "NOTICE " sender
" :\C-aTIME " (current-time-string) "\C-a")))
(defun rcirc-handler-CTCP-response (process _target sender message)
+ "Handle CTCP response MESSAGE from SENDER.
+PROCESS is the process object for the current connection."
(rcirc-print process sender "CTCP" nil message t))
+
\f
(defgroup rcirc-faces nil
"Faces for rcirc."
@@ -3075,11 +3308,12 @@ rcirc-keyword
;; When using M-x flyspell-mode, only check words after the prompt
(put 'rcirc-mode 'flyspell-mode-predicate 'rcirc-looking-at-input)
(defun rcirc-looking-at-input ()
- "Return true if point is past the input marker."
+ "Return non-nil if point is past the input marker."
(>= (point) rcirc-prompt-end-marker))
\f
(defun rcirc-server-parameter-value (parameter)
+ "Traverse `rcirc-server-parameters' for PARAMETER."
(cl-loop for elem in rcirc-server-parameters
for setting = (split-string elem "=")
when (and (= (length setting) 2)
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: 0005-Improve-formatting-of-rcirc-send-string.patch --]
[-- Type: text/x-diff, Size: 10378 bytes --]
From ec58a1a3cd3fb60bb5f0d14bde535cb1d5c0a457 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 4 Jun 2021 16:29:27 +0200
Subject: [PATCH 05/11] Improve formatting of rcirc-send-string
---
lisp/net/rcirc.el | 91 ++++++++++++++++++++++++++---------------------
1 file changed, 50 insertions(+), 41 deletions(-)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 1f925b00b1..ab5634d75d 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -630,10 +630,9 @@ rcirc-connect
;; identify
(unless (zerop (length password))
- (rcirc-send-string process (concat "PASS " password)))
- (rcirc-send-string process (concat "NICK " nick))
- (rcirc-send-string process (concat "USER " user-name
- " 0 * :" full-name))
+ (rcirc-send-string process "PASS" password))
+ (rcirc-send-string process "NICK" nick)
+ (rcirc-send-string process "USER" user-name 0 "*" : full-name)
;; setup ping timer if necessary
(unless rcirc-keepalive-timer
@@ -879,9 +878,23 @@ rcirc--connection-open-p
"Check if PROCESS is open or running."
(memq (process-status process) '(run open)))
-(defun rcirc-send-string (process string)
- "Send PROCESS a STRING plus a newline."
- (let ((string (concat (encode-coding-string string rcirc-encode-coding-system)
+(defun rcirc-send-string (process &rest parts)
+ "Send PROCESS a PARTS plus a newline.
+PARTS may contain a `:' symbol, to designate that the next string
+is the message, that should be prefixed by a colon. If the last
+element in PARTS is a list, append it to PARTS."
+ (let ((last (car (last parts))))
+ (when (listp last)
+ (setf parts (append (butlast parts) last))))
+ (when-let (message (memq : parts))
+ (cl-check-type (cadr message) 'string)
+ (setf (cadr message) (concat ":" (cadr message))
+ parts (remq : parts)))
+ (let ((string (concat (encode-coding-string
+ (mapconcat
+ (apply-partially #'format "%s")
+ parts " ")
+ rcirc-encode-coding-system)
"\n")))
(unless (rcirc--connection-open-p process)
(error "Network connection to %s is not open"
@@ -892,13 +905,15 @@ rcirc-send-string
(defun rcirc-send-privmsg (process target string)
"Send TARGET the message in STRING via PROCESS."
(cl-check-type target string)
- (rcirc-send-string process (format "PRIVMSG %s :%s" target string)))
+ (rcirc-send-string process "PRIVMSG" target : string))
+
+(defun rcirc-ctcp-wrap (&rest args)
+ "Join ARGS into a string wrapped by ASCII 1 charterers."
+ (concat "\C-a" (string-join (delq nil args) " ") "\C-a"))
(defun rcirc-send-ctcp (process target request &optional args)
- (let ((args (if args (concat " " args) "")))
- (rcirc-send-privmsg process target
- (format "\C-a%s%s\C-a" request args))))
"Send TARGET a REQUEST via PROCESS."
+ (rcirc-send-privmsg process target (rcirc-ctcp-wrap request args)))
(defun rcirc-buffer-process (&optional buffer)
"Return the process associated with channel BUFFER.
@@ -957,7 +972,7 @@ rcirc-send-message
(let ((response (if noticep "NOTICE" "PRIVMSG")))
(rcirc-get-buffer-create process target)
(dolist (msg (rcirc-split-message message))
- (rcirc-send-string process (concat response " " target " :" msg))
+ (rcirc-send-string process response target : msg)
(unless silent
(rcirc-print process (rcirc-nick process) response target msg)))))
@@ -1282,7 +1297,7 @@ rcirc-clean-up-buffer
(rcirc-update-short-buffer-names)
(if (rcirc-channel-p rcirc-target)
(rcirc-send-string (rcirc-buffer-process)
- (concat "PART " rcirc-target " :" reason))
+ "PART" rcirc-target : reason)
(when rcirc-target
(rcirc-remove-nick-channel (rcirc-buffer-process)
(rcirc-buffer-nick)
@@ -2313,7 +2328,7 @@ join
(rcirc-get-buffer-create process ch))
split-channels))
(channels (mapconcat 'identity split-channels ",")))
- (rcirc-send-string process (concat "JOIN " channels))
+ (rcirc-send-string process "JOIN" channels)
(when (not (eq (selected-window) (minibuffer-window)))
(dolist (b buffers) ;; order the new channel buffers in the buffer list
(switch-to-buffer b)))))
@@ -2326,7 +2341,7 @@ invite
(with-rcirc-server-buffer rcirc-nick-table))
" "
(read-string "Channel: "))))
- (rcirc-send-string process (concat "INVITE " nick-channel)))
+ (rcirc-send-string process "INVITE" nick-channel))
(defun-rcirc-command part (channel)
"Part CHANNEL.
@@ -2342,15 +2357,14 @@ part
(setq channel (if (match-beginning 1)
(match-string 1 channel)
target)))
- (rcirc-send-string process (concat "PART " channel " :" msg))))
+ (rcirc-send-string process "PART" : msg)))
(defun-rcirc-command quit (reason)
"Send a quit message to server with REASON."
(interactive "sQuit reason: ")
- (rcirc-send-string process (concat "QUIT :"
- (if (not (zerop (length reason)))
+ (rcirc-send-string process "QUIT" : (if (not (zerop (length reason)))
reason
- rcirc-default-quit-reason))))
+ rcirc-default-quit-reason)))
(defun-rcirc-command reconnect (_)
"Reconnect to current server."
@@ -2370,7 +2384,7 @@ nick
(interactive "i")
(when (null nick)
(setq nick (read-string "New nick: " (rcirc-nick process))))
- (rcirc-send-string process (concat "NICK " nick)))
+ (rcirc-send-string process "NICK" nick))
(defun-rcirc-command names (channel)
"Display list of names in CHANNEL or in current channel if CHANNEL is nil.
@@ -2382,7 +2396,7 @@ names
(let ((channel (if (> (length channel) 0)
channel
target)))
- (rcirc-send-string process (concat "NAMES " channel))))
+ (rcirc-send-string process "NAMES" channel)))
(defun-rcirc-command topic (topic)
"List TOPIC for the TARGET channel.
@@ -2390,32 +2404,32 @@ topic
(interactive "P")
(if (and (called-interactively-p 'interactive) topic)
(setq topic (read-string "New Topic: " rcirc-topic)))
- (rcirc-send-string process (concat "TOPIC " target
- (when (> (length topic) 0)
- (concat " :" topic)))))
+ (if (> (length topic) 0)
+ (rcirc-send-string process "TOPIC" : topic)
+ (rcirc-send-string process "TOPIC")))
(defun-rcirc-command whois (nick)
"Request information from server about NICK."
(interactive (list
(completing-read "Whois: "
(with-rcirc-server-buffer rcirc-nick-table))))
- (rcirc-send-string process (concat "WHOIS " nick)))
+ (rcirc-send-string process "WHOIS" nick))
(defun-rcirc-command mode (args)
"Set mode with ARGS."
(interactive (list (concat (read-string "Mode nick or channel: ")
" " (read-string "Mode: "))))
- (rcirc-send-string process (concat "MODE " args)))
+ (rcirc-send-string process "MODE" args))
(defun-rcirc-command list (channels)
"Request information on CHANNELS from server."
(interactive "sList Channels: ")
- (rcirc-send-string process (concat "LIST " channels)))
+ (rcirc-send-string process "LIST" channels))
(defun-rcirc-command oper (args)
"Send operator command to server."
(interactive "sOper args: ")
- (rcirc-send-string process (concat "OPER " args)))
+ (rcirc-send-string process "OPER" args))
(defun-rcirc-command quote (message)
"Send MESSAGE literally to server."
@@ -2430,10 +2444,8 @@ kick
(rcirc-buffer-process)
rcirc-target))
(read-from-minibuffer "Kick reason: "))))
- (let* ((arglist (split-string arg))
- (argstring (concat (car arglist) " :"
- (mapconcat 'identity (cdr arglist) " "))))
- (rcirc-send-string process (concat "KICK " target " " argstring))))
+ (let ((args (split-string arg)))
+ (rcirc-send-string process "KICK" target (car args) : (cdr args))))
(defun rcirc-cmd-ctcp (args &optional process _target)
"Handle ARGS as a CTCP command.
@@ -2924,11 +2936,11 @@ rcirc-handler-NICK
(when rcirc-auto-authenticate-flag (rcirc-authenticate))))))
(defun rcirc-handler-PING (process _sender args _text)
- (rcirc-send-string process (concat "PONG :" (car args))))
"Respond to a PING with a PONG.
ARGS should have the form (MESSAGE). MESSAGE is relayed back to
the server. PROCESS is the process object for the current
connection."
+ (rcirc-send-string process "PONG" : (car args)))
(defun rcirc-handler-PONG (_process _sender _args _text)
"Ignore all incoming PONG messages.")
@@ -3171,22 +3183,19 @@ rcirc-handler-CTCP
(defun rcirc-handler-ctcp-VERSION (process _target sender _message)
"Handle a CTCP VERSION message from SENDER.
PROCESS is the process object for the current connection."
- (rcirc-send-string process
- (concat "NOTICE " sender
- " :\C-aVERSION " rcirc-id-string
- "\C-a")))
+ (rcirc-send-string process "NOTICE" sender :
+ (rcirc-ctcp-wrap "VERSION" rcirc-id-string)))
(defun rcirc-handler-ctcp-ACTION (process target sender message)
"Handle a CTCP ACTION MESSAGE from SENDER to TARGET.
PROCESS is the process object for the current connection."
- (rcirc-print process sender "ACTION" target args t))
+ (rcirc-print process sender "ACTION" target message t))
(defun rcirc-handler-ctcp-TIME (process _target sender _message)
"Respond to CTCP TIME message from SENDER.
PROCESS is the process object for the current connection."
- (rcirc-send-string process
- (concat "NOTICE " sender
- " :\C-aTIME " (current-time-string) "\C-a")))
+ (rcirc-send-string process "NOTICE" sender :
+ (rcirc-ctcp-wrap "TIME" (current-time-string))))
(defun rcirc-handler-CTCP-response (process _target sender message)
"Handle CTCP response MESSAGE from SENDER.
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #7: 0006-Recognize-quoted-commands-in-rcirc-process-input-lin.patch --]
[-- Type: text/x-diff, Size: 2496 bytes --]
From 195d57c93b1fa23b51b6feb7a8f0973c0051a508 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 4 Jun 2021 16:32:14 +0200
Subject: [PATCH 06/11] Recognize quoted commands in rcirc-process-input-line
---
lisp/net/rcirc.el | 33 ++++++++++++++-------------------
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index ab5634d75d..040eb60538 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -1385,8 +1385,8 @@ rcirc-fill-paragraph
(fill-region (point-min) (point-max) justify)))))
(defun rcirc-process-input-line (line)
- (if (string-match "^/\\([^ ]+\\) ?\\(.*\\)$" line)
"Process LINE as a message or a command."
+ (if (string-match "^/\\([^/ ][^ ]*\\) ?\\(.*\\)$" line)
(rcirc-process-command (match-string 1 line)
(match-string 2 line)
line)
@@ -1401,28 +1401,23 @@ rcirc-process-message
(setq rcirc-last-post-time (current-time))))
(defun rcirc-process-command (command args line)
- (if (eq (aref command 0) ?/)
- ;; "//text" will send "/text" as a message
- (rcirc-process-message (substring line 1))
- (let ((fun (intern-soft (concat "rcirc-cmd-" command)))
- (process (rcirc-buffer-process)))
- (newline)
- (with-current-buffer (current-buffer)
- (delete-region rcirc-prompt-end-marker (point))
- (if (string= command "me")
- (rcirc-print process (rcirc-buffer-nick)
- "ACTION" rcirc-target args)
"Process COMMAND with arguments ARGS.
LINE is the raw input, from which COMMAND and ARGS was
extracted."
+ (let ((fun (intern-soft (concat "rcirc-cmd-" command)))
+ (process (rcirc-buffer-process)))
+ (newline)
+ (with-current-buffer (current-buffer)
+ (delete-region rcirc-prompt-end-marker (point))
+ (if (string= command "me")
(rcirc-print process (rcirc-buffer-nick)
- "COMMAND" rcirc-target line))
- (set-marker rcirc-prompt-end-marker (point))
- (if (fboundp fun)
- (funcall fun args process rcirc-target)
- (rcirc-send-string process
- (concat command " :" args)))))))
-
+ "ACTION" rcirc-target args)
+ (rcirc-print process (rcirc-buffer-nick)
+ "COMMAND" rcirc-target line))
+ (set-marker rcirc-prompt-end-marker (point))
+ (if (fboundp fun)
+ (funcall fun args process rcirc-target)
+ (rcirc-send-string process command : args)))))
(defvar-local rcirc-parent-buffer nil
"Message buffer that requested a multiline buffer.")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #8: 0007-Define-rcirc-mode-using-rcirc-initialize.patch --]
[-- Type: text/x-diff, Size: 6009 bytes --]
From 32b1f35ada7006fabf9a7c8d7302769662250a0e Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 4 Jun 2021 16:35:05 +0200
Subject: [PATCH 07/11] Define rcirc-mode using rcirc-initialize
---
lisp/net/rcirc.el | 56 ++++++++++++++++++++++++++---------------------
1 file changed, 31 insertions(+), 25 deletions(-)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 040eb60538..92d7b383d8 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -774,7 +774,7 @@ rcirc-process-list
(mapc (lambda (p)
(when (buffer-live-p (process-buffer p))
(with-rcirc-process-buffer p
- (when (eq major-mode 'rcirc-mode)
+ (when (derived-mode-p 'rcirc-mode)
(setq ps (cons p ps))))))
(process-list))
ps))
@@ -1128,17 +1128,22 @@ rcirc-current-line
"The current number of responses printed in this channel.
This number is independent of the number of lines in the buffer.")
-(defun rcirc-mode (process target)
- ;; FIXME: Use define-derived-mode.
- "Major mode for IRC channel buffers.
+(defun rcirc-initialize (process target)
+ "Initialize current buffer for IRC.
+PROCESS is the process object that the buffer uses to
+communicate. TARGET designates who the buffer is used to
+communicate to (channel, username)."
+ (let ((rcirc-process process)
+ (rcirc-target target))
+ (rcirc-mode)))
+
+(define-derived-mode rcirc-mode text-mode "rcirc"
+ "Major mode for IRC channel buffers."
+ :interactive nil
+ (cl-assert rcirc-process nil "The variable `rcirc-process' must by bound and non-nil")
+ (cl-assert rcirc-target nil "The variable `rcirc-target' must by bound and non-nil")
-\\{rcirc-mode-map}"
- (kill-all-local-variables)
- (use-local-map rcirc-mode-map)
- (setq mode-name "rcirc")
- (setq major-mode 'rcirc-mode)
(setq mode-line-process nil)
-
(setq-local rcirc-input-ring
;; If rcirc-input-ring is already a ring with desired
;; size do not re-initialize.
@@ -1147,8 +1152,8 @@ rcirc-mode
rcirc-input-ring-size))
rcirc-input-ring
(make-ring rcirc-input-ring-size)))
- (setq-local rcirc-server-buffer (process-buffer process))
- (setq-local rcirc-target target)
+ (setq-local rcirc-server-buffer (process-buffer rcirc-process))
+ (setq-local rcirc-target rcirc-target)
(setq-local rcirc-topic nil)
(setq-local rcirc-last-post-time (current-time))
(setq-local fill-paragraph-function 'rcirc-fill-paragraph)
@@ -1171,8 +1176,8 @@ rcirc-mode
(dolist (i rcirc-coding-system-alist)
(let ((chan (if (consp (car i)) (caar i) (car i)))
(serv (if (consp (car i)) (cdar i) "")))
- (when (and (string-match chan (or target ""))
- (string-match serv (rcirc-server-name process)))
+ (when (and (string-match chan (or rcirc-target ""))
+ (string-match serv (rcirc-server-name rcirc-process)))
(setq-local rcirc-decode-coding-system
(if (consp (cdr i)) (cadr i) (cdr i)))
(setq-local rcirc-encode-coding-system
@@ -1192,17 +1197,17 @@ rcirc-mode
(add-hook 'kill-buffer-hook 'rcirc-kill-buffer-hook nil t)
;; add to buffer list, and update buffer abbrevs
- (when target ; skip server buffer
+ (when rcirc-target ; skip server buffer
(let ((buffer (current-buffer)))
- (with-rcirc-process-buffer process
- (setq rcirc-buffer-alist (cons (cons target buffer)
+ (with-rcirc-process-buffer rcirc-process
+ (setq rcirc-buffer-alist (cons (cons rcirc-target buffer)
rcirc-buffer-alist))))
(rcirc-update-short-buffer-names))
(add-hook 'completion-at-point-functions
- 'rcirc-completion-at-point nil 'local)
+ 'rcirc-completion-at-point nil 'local))
- (run-mode-hooks 'rcirc-mode-hook))
+(set-advertised-calling-convention 'rcirc-mode '() "28.1")
(defun rcirc-update-prompt (&optional all)
"Reset the prompt string in the current buffer.
@@ -1269,7 +1274,7 @@ rcirc-kill-buffer-hook
If `rcirc-kill-channel-buffers' is non-nil and the killed buffer
is a server buffer, kills all of the channel buffers associated
with it."
- (when (eq major-mode 'rcirc-mode)
+ (when (derived-mode-p 'rcirc-mode)
(when (and rcirc-log-flag
rcirc-log-directory)
(rcirc-log-write))
@@ -1337,7 +1342,7 @@ rcirc-get-buffer-create
(let ((new-buffer (get-buffer-create
(rcirc-generate-new-buffer-name process target))))
(with-current-buffer new-buffer
- (rcirc-mode process target)
+ (rcirc-initialize process target)
(rcirc-put-nick-channel process (rcirc-nick process) target
rcirc-current-line))
new-buffer)))))
@@ -1486,7 +1491,7 @@ rcirc-any-buffer
(let ((buffer (window-buffer)))
(if (and buffer
(with-current-buffer buffer
- (and (eq major-mode 'rcirc-mode)
+ (and (derived-mode-p 'rcirc-mode)
(eq (rcirc-buffer-process) process))))
buffer
(process-buffer process)))))
@@ -1750,7 +1755,7 @@ rcirc-print
(let ((window (get-buffer-window)))
(when window
(with-selected-window window
- (when (eq major-mode 'rcirc-mode)
+ (when (derived-mode-p 'rcirc-mode)
(when (<= (- (window-height)
(count-screen-lines (window-point)
(window-start))
@@ -2034,7 +2039,8 @@ rcirc-bury-buffers
"Bury all RCIRC buffers."
(interactive)
(dolist (buf (buffer-list))
- (when (eq 'rcirc-mode (with-current-buffer buf major-mode))
+ (when (provided-mode-derived-p (buffer-local-value buf 'major-mode)
+ 'rcirc-mode)
(bury-buffer buf) ; buffers not shown
(quit-windows-on buf)))) ; buffers shown in a window
@@ -2158,7 +2164,7 @@ rcirc-visible-buffers
(let (acc)
(walk-windows (lambda (w)
(with-current-buffer (window-buffer w)
- (when (eq major-mode 'rcirc-mode)
+ (when (derived-mode-p 'rcirc-mode)
(push (current-buffer) acc)))))
acc))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #9: 0008-Replace-rcirc-delete-process-with-delete-process.patch --]
[-- Type: text/x-diff, Size: 988 bytes --]
From 7682fa1e9f9128fe1dcfb9dddb60d476a2daa099 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 4 Jun 2021 16:41:10 +0200
Subject: [PATCH 08/11] Replace rcirc-delete-process with delete-process
---
lisp/net/rcirc.el | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 92d7b383d8..073dbc118c 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -805,12 +805,9 @@ rcirc-reschedule-timeout
(with-rcirc-process-buffer process
(when rcirc-timeout-timer (cancel-timer rcirc-timeout-timer))
(setq rcirc-timeout-timer (run-at-time rcirc-timeout-seconds nil
- 'rcirc-delete-process
+ 'delete-process
process))))))
-(defun rcirc-delete-process (process)
- (delete-process process))
-
(defvar rcirc-trap-errors-flag t
"Non-nil means Lisp errors are degraded to error messages.")
(defun rcirc-process-server-response (process text)
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #10: 0009-Remove-unused-variable-rcirc-last-sender.patch --]
[-- Type: text/x-diff, Size: 701 bytes --]
From 5704a82a77733dc077043121f3e28fadfc71bbaa Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 4 Jun 2021 16:41:30 +0200
Subject: [PATCH 09/11] Remove unused variable rcirc-last-sender
---
lisp/net/rcirc.el | 1 -
1 file changed, 1 deletion(-)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 073dbc118c..944df4a1bf 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -1597,7 +1597,6 @@ rcirc-target-buffer
((or (rcirc-get-buffer process target)
(rcirc-any-buffer process))))))
-(defvar-local rcirc-last-sender nil)
(defvar-local rcirc-activity-types nil
"List of symbols designating kinds of activities in a buffer.")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #11: 0010-Call-rcirc-update-activity-string-after-rcirc-next-a.patch --]
[-- Type: text/x-diff, Size: 850 bytes --]
From 1c967de181a14787fa9579c45ac2af9a2400b8eb Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 4 Jun 2021 16:41:57 +0200
Subject: [PATCH 10/11] Call rcirc-update-activity-string after
rcirc-next-active-buffer
---
lisp/net/rcirc.el | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 944df4a1bf..202d12b892 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -2059,7 +2059,8 @@ rcirc-next-active-buffer
(concat
" Type C-u " (key-description (this-command-keys))
" for low priority activity.")
- "")))))
+ ""))))
+ (rcirc-update-activity-string))
(define-obsolete-variable-alias 'rcirc-activity-hooks
'rcirc-activity-functions "24.3")
--
2.30.2
^ permalink raw reply related [relevance 6%]
* Re: Cleaning up rcirc
@ 2021-06-04 18:09 98% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-06-04 18:09 UTC (permalink / raw)
To: Andreas Schwab; +Cc: emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> On Jun 04 2021, Philip Kaludercic wrote:
>
>> @@ -846,6 +898,7 @@ rcirc-send-ctcp
>> (let ((args (if args (concat " " args) "")))
>> (rcirc-send-privmsg process target
>> (format "\C-a%s%s\C-a" request args))))
>> + "Send TARGET a REQUEST via PROCESS."
>>
>> (defun rcirc-buffer-process (&optional buffer)
>> "Return the process associated with channel BUFFER.
>
> That looks like a pasto.
Hmm, I wrote most of the code then tried to selectively separate out
each change into it's own commit. Must have added that docstring at the
wrong point...
Either way, I also noticed there were other issues with the code, that I
have since fixed. Would it be ok to push the changes as a feature
branch, so that I don't have to re-send all the patches again and again?
> Andreas.
--
Philip K.
^ permalink raw reply [relevance 98%]
* Re: Cleaning up rcirc
@ 2021-06-06 21:09 99% ` Philip Kaludercic
2021-06-10 15:50 83% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-06 21:09 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Andreas Schwab, emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Either way, I also noticed there were other issues with the code, that
>> I have since fixed. Would it be ok to push the changes as a feature
>> branch, so that I don't have to re-send all the patches again and
>> again?
>
> IMHO, yes. It would also make testing much easier. I'm a rcirc user so
> I'd be happy to give it a whirl.
Ok, so unless there are any objections I'll try to push the changes
after having have made sure that the commits are internally consistent.
> Bye,
> Tassilo
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Cleaning up rcirc
@ 2021-06-07 13:20 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-07 13:20 UTC (permalink / raw)
To: Zhiwei Chen; +Cc: emacs-devel@gnu.org
Zhiwei Chen <chenzhiwei03@kuaishou.com> writes:
> It seems like color is not supported in rcirc. Screenshot follows:
That is true, rcirc-markup-text-functions, or more precisely
rcirc-markup-attributes only specified bold, italic and underlined
formatting.
> [cid:AE6727FC-4F88-4EE3-9414-F19650355A9A]
>
> \x05 = red.
I found this document that explains various formatting options
https://modern.ircdocs.horse/formatting.html. It seems like something
that could be added, unless there is a technical reason not to do so.
> --
> Zhiwei Chen
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Cleaning up rcirc
2021-06-06 21:09 99% ` Philip Kaludercic
@ 2021-06-10 15:50 83% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-10 15:50 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Lars Ingebrigtsen, Andreas Schwab, emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Either way, I also noticed there were other issues with the code, that
>> I have since fixed. Would it be ok to push the changes as a feature
>> branch, so that I don't have to re-send all the patches again and
>> again?
>
> IMHO, yes. It would also make testing much easier. I'm a rcirc user so
> I'd be happy to give it a whirl.
Just pushed the changes to feature/rcirc-update.
I rewrote the commits and remove the define-derived-mode change, because
that broke requiring more refactoring to fix.
A few IRCv3 specs have already been implemented, as listed in the new
option rcirc-implemented-capabilities. I plan to add these sooner or
later:
- https://ircv3.net/specs/extensions/account-notify
- https://ircv3.net/specs/extensions/account-tag
- https://ircv3.net/specs/extensions/extended-join
- https://ircv3.net/specs/extensions/away-notify
- https://ircv3.net/specs/extensions/echo-message
- https://ircv3.net/specs/extensions/labeled-response
- https://ircv3.net/specs/extensions/multiline
- https://ircv3.net/specs/extensions/sasl-3.1
and
- https://ircv3.net/specs/client-tags/reply
- https://ircv3.net/specs/client-tags/react
- https://ircv3.net/specs/extensions/chathistory
as soon as they become reliable. I have experimented with chathistory,
and in principle it works. What this would also require is a proper UI
to allow general queries. What is doable now is something like "request
the last 20 messages right after joining a new channel", and they will
be printed with the right timestamps.
--
Philip K.
^ permalink raw reply [relevance 83%]
* Re: [PATCH] 0001-Add-icomplete-count-format
@ 2021-06-10 16:23 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-10 16:23 UTC (permalink / raw)
To: tumashu; +Cc: emacs-devel@gnu.org
tumashu <tumashu@163.com> writes:
> From 6074e1f4c5564e5d9e56041cc7db6fd7125571cb Mon Sep 17 00:00:00 2001
> From: Feng Shu <tumashu@163.com>
> Date: Thu, 10 Jun 2021 15:48:51 +0800
> Subject: [PATCH] Add icomplete-count-format.
>
> * lisp/icomplete.el (icomplete-count-format): New variable.
> (icomplete-exhibit): Use icomplete-count-format.
> ---
> lisp/icomplete.el | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/lisp/icomplete.el b/lisp/icomplete.el
> index 08b4ef2030..0881bade98 100644
> --- a/lisp/icomplete.el
> +++ b/lisp/icomplete.el
> @@ -70,6 +70,10 @@ icomplete-hide-common-prefix
> :type 'boolean
> :version "24.4")
>
> +(defcustom icomplete-count-format (cons "%-7s" "%s/%s ")
> + "Format string used for the candidate count."
> + :type '(choice (const nil) (cons string string)))
You need a
:version "28.1"
here.
> (defvar icomplete-tidy-shadowed-file-names nil
> "If non-nil, automatically delete superfluous parts of file names.
> For example, if the user types ~/ after a long path name,
> @@ -696,12 +700,13 @@ icomplete-exhibit
> (overlay-put
> icomplete-overlay 'before-string
> (and icomplete-scroll
> - (let ((past (length icomplete--scrolled-past)))
> - (format
> - "%s/%s "
> - (1+ past)
> - (+ past
> - (safe-length completion-all-sorted-completions))))))
> + (format (car icomplete-count-format)
Does this really have to be another format string? Or would this always
just be used for justification?
> + (let ((past (length icomplete--scrolled-past)))
> + (format
> + (cdr icomplete-count-format)
> + (1+ past)
> + (+ past
> + (safe-length completion-all-sorted-completions)))))))
> (overlay-put icomplete-overlay 'after-string text))))))))
>
> (defun icomplete--affixate (md prospects)
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Cleaning up rcirc
@ 2021-06-10 21:54 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-10 21:54 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
>> A few IRCv3 specs have already been implemented, as listed in the new
>> option rcirc-implemented-capabilities. I plan to add these sooner or
>> later:
>>
>> - https://ircv3.net/specs/extensions/account-notify
>> - https://ircv3.net/specs/extensions/account-tag
>> - https://ircv3.net/specs/extensions/extended-join
>> - https://ircv3.net/specs/extensions/away-notify
>> - https://ircv3.net/specs/extensions/echo-message
>> - https://ircv3.net/specs/extensions/labeled-response
>> - https://ircv3.net/specs/extensions/multiline
>> - https://ircv3.net/specs/extensions/sasl-3.1
>>
>> and
>>
>> - https://ircv3.net/specs/client-tags/reply
>> - https://ircv3.net/specs/client-tags/react
>> - https://ircv3.net/specs/extensions/chathistory
>
> I'm afraid I'm not a very knowledgeable IRC user. I know how to chat,
> /msg, /join, and /part, or how to identify to NickServ. That's about
> it. So I can report back if something very basic breaks but if you
> would like me to test some more advanced things, you have to guide me a
> bit.
I'm not sure if that will happen without a bouncer, but rcirc-print
tries to order the messages by the server-time, and I've noticed edge
cases where the messages don't appear in the right order. But other than
that, I hope that I didn't break any of the basic stuff.
> Bye,
> Tassilo
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Cleaning up rcirc
@ 2021-06-11 8:09 97% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-11 8:09 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>> I'm not sure if that will happen without a bouncer, but rcirc-print
>> tries to order the messages by the server-time, and I've noticed edge
>> cases where the messages don't appear in the right order. But other
>> than that, I hope that I didn't break any of the basic stuff.
>
> It seems like you didn't. It's working fine for me. :-)
>
> You've mentioned that one can now do something like "request the last 20
> messages" after joining a channel. How would I do that?
I did not commit the code to do that, because it requires the drafted
capability "chathistory". This is still not widely supported, and the
specification is not final, so I hesitate to add it just yet.
> Also, is there something like "request all mentions of my nick while
> I've been offline"? That would be super-useful.
The spec does not allow that just yet (for now you can request before T,
after T, latest, around T, between T and S), but we might be able to
make use of the draft status to suggest adding this functionality.
> Bye,
> Tassilo
--
Philip K.
^ permalink raw reply [relevance 97%]
* Re: Cleaning up rcirc
@ 2021-06-11 9:08 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-11 9:08 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Hi Philip,
>
>> It seems like you didn't. It's working fine for me. :-)
>
> Here's one thing I noticed just now but which is probably not caused by
> your changes, but who knows: I use `rcirc-track-minor-mode' which
> displays abbreviated channels with activity in the mode-line like
> [#emacs,#git] and makes it possible to switch/cycle through them with
> `rcirc-next-active-buffer'.
>
> With the indicator above and a 2-side-by-side window configuration
> (terminal frame, if that matters) I call the latter function twice. In
> the current mode-line, the indicator becomes [] (no unseen activity),
> however, in the other window it is still [#emacs,#git] and becomes []
> not before switching to that other window.
Hmm, I did not change anything about rcirc-track-minor-mode, but I do
remember trying out adding (rcirc-update-activity-string) to the end of
rcirc-next-active-buffer. Does that change anything in your case?
> Bye,
> Tassilo
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Cleaning up rcirc
@ 2021-06-11 9:44 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-11 9:44 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Hi Philip,
>
>>> Here's one thing I noticed just now but which is probably not caused by
>>> your changes, but who knows: I use `rcirc-track-minor-mode' which
>>> displays abbreviated channels with activity in the mode-line like
>>> [#emacs,#git] and makes it possible to switch/cycle through them with
>>> `rcirc-next-active-buffer'.
>>>
>>> With the indicator above and a 2-side-by-side window configuration
>>> (terminal frame, if that matters) I call the latter function twice. In
>>> the current mode-line, the indicator becomes [] (no unseen activity),
>>> however, in the other window it is still [#emacs,#git] and becomes []
>>> not before switching to that other window.
>>
>> Hmm, I did not change anything about rcirc-track-minor-mode, but I do
>> remember trying out adding (rcirc-update-activity-string) to the end
>> of rcirc-next-active-buffer. Does that change anything in your case?
>
> No, not really. `rcirc-update-activity-string' just updates
> `rcirc-activity-string'. Maybe that should call
>
> (force-mode-line-update t)
>
> at least if the new and old activity string aren't equal?
I cannot reproduce the issue (at least in my GUI instance, I'll take a
look at TUI). Can you observe it making a difference?
> Bye,
> Tassilo
>
>
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [feature/rcirc-update] Reconnects don't seem to work anymore
@ 2021-06-11 10:57 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-11 10:57 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Hi Philip,
>
> at 11:59 I was disconnected from libera.chat. In the server buffer I
> have
>
> 10:59 *** tsdh QUIT Ping timeout: 264 seconds
>
> and in channels, there is
>
> 0:59 !!! irc.libera.chat: connection broken by remote peer (closed)
>
> Usually, if that happened I'd just `M-x rcirc RET' again, and it would
> re-connect to all servers in `rcirc-server-alist' which are not
> connected anymore.
If you were to use /reconnect would that change anything? That is what I
tested, and I hope worked. But your method should continue working.
> Well, it still does that, i.e., I'm connected to irc.libera.chat again
> in *irc.libera.chat* but all channel buffers of that network show
> "(rcirc:disconnected)" in the mode-line and don't seem to receive any
> messages anymore.
I did encounter something similar, the issue was that rcirc-buffer-alist
was nil'ed unintentionally. What is the value of rcirc-buffer-alist in
the server buffer before and after reconnecting?
> That's a thing which used to work before your patches, I think.
>
> Bye,
> Tassilo
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [feature/rcirc-update] Reconnects don't seem to work anymore
@ 2021-06-11 14:50 99% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-11 14:50 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> If you were to use /reconnect would that change anything? That is what I
>> tested, and I hope worked. But your method should continue working.
>
> Not sure. In the current state it just says "Server buffer is alive"
> which is true.
Yes, because the server buffer is reconnected. The issue is that the
existing buffers are not reused.
Another issue I also intend so solve is reconnecting to buffers used for
direct chat. These usually break and then I have to manually /msg the
other person again to continue a conversation.
>> I did encounter something similar, the issue was that
>> rcirc-buffer-alist was nil'ed unintentionally. What is the value of
>> rcirc-buffer-alist in the server buffer before and after reconnecting?
>
> It still knows about the buffers:
>
> (("##rust" . #<buffer ##rust@irc.libera.chat>)
> ("#git" . #<buffer #git@irc.libera.chat>)
> ("#archlinux" . #<buffer #archlinux@irc.libera.chat>)
> ("#fsf-members" . #<buffer #fsf-members@irc.libera.chat>)
> ("#fsf" . #<buffer #fsf@irc.libera.chat>)
> ("#gnu" . #<buffer #gnu@irc.libera.chat>)
> ("#gnus" . #<buffer #gnus@irc.libera.chat>)
> ("#rcirc" . #<buffer #rcirc@irc.libera.chat>)
> ("#emacs-beginners" . #<buffer #emacs-beginners@irc.libera.chat>)
> ("#emacs" . #<buffer #emacs@irc.libera.chat>)
> ("#sway" . #<buffer #sway@irc.libera.chat>)
> ("#sr.ht" . #<buffer #sr.ht@irc.libera.chat>))
> Local in buffer *irc.libera.chat*; global value is nil
This is most unusual... I'll try to look into this.
> I'm now restarting emacs. The next time I get a disconnect, I'll try
> /reconnect instead.
>
> Bye,
> Tassilo
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Cleaning up rcirc
@ 2021-06-11 14:51 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-11 14:51 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Hi Philip,
>
>>> No, not really. `rcirc-update-activity-string' just updates
>>> `rcirc-activity-string'. Maybe that should call
>>>
>>> (force-mode-line-update t)
>>>
>>> at least if the new and old activity string aren't equal?
>>
>> I cannot reproduce the issue (at least in my GUI instance, I'll take a
>> look at TUI). Can you observe it making a difference?
>
> Yes, with this patch it works for me on my TUI instance. (I'm not sure
> if that's the right thing to do, though.)
>
> modified lisp/net/rcirc.el
> @@ -2154,7 +2154,8 @@ rcirc-next-active-buffer
> (concat
> " Type C-u " (key-description (this-command-keys))
> " for low priority activity.")
> - "")))))
> + "")))
> + (rcirc-update-activity-string)))
>
> (define-obsolete-variable-alias 'rcirc-activity-hooks
> 'rcirc-activity-functions "24.3")
> @@ -2229,7 +2230,8 @@ rcirc-update-activity-string
> ((not (null (rcirc-process-list)))
> "[]")
> (t "[]")))
> - (run-hooks 'rcirc-update-activity-string-hook)))
> + (run-hooks 'rcirc-update-activity-string-hook)
> + (force-mode-line-update t)))
Hmm, it is probably worth adding this then.
> (defun rcirc-activity-string (buffers)
> "Generate activity string for all BUFFERS."
>
> Bye,
> Tassilo
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [feature/rcirc-update] Reconnects don't seem to work anymore
@ 2021-06-15 16:17 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-15 16:17 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Tassilo Horn <tsdh@gnu.org> writes:
>
>> I'm now restarting emacs. The next time I get a disconnect, I'll try
>> /reconnect instead.
>
> I got disconnected from freenode, and this time I've tried /reconnect
> instead of `M-x rcirc RET'. However, that reconnected to the server but
> again all channel buffers still show rcirc:disconnected. The
> `rcirc-buffer-alist' in the server buffer for freenode is still
> populated with the right buffers as previously.
I am still not able to consistently reproduce this issue. Just to be
sure, what commit are you on?
> Also, after /reconnect it seems I got an error during nickserv
> authentication as configured by `rcirc-authinfo':
>
> (setq rcirc-authinfo
> `(("freenode" nickserv ,rcirc-default-nick ,th/nickserv-password-freenode)
> ("libera" nickserv ,rcirc-default-nick ,th/nickserv-password-liberachat)
> ("oftc" nickserv ,rcirc-default-nick ,th/nickserv-password-oftc)
> ("gnome" nickserv "tsdh80" ,th/nickserv-password-gnome)))
>
>
> The error was:
>
> 06:58 -*.freenode.net- *** You are connected to chat.freenode.net using TLS
> (SSL) cipher 'TLSv1.3-TLS_AES_256_GCM_SHA384'
> 06:58 !!! "@msgid=446~1623712485~22272;inspircd.org/service;inspircd.org/bot
> :NickServ!services@services.freenode.net NOTICE tsdh :Nick tsdh
> isn't registered." (wrong-type-argument arrayp nil)
From your other message, it seems like this is specificity related to
freenode, right?
> Bye,
> Tassilo
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [feature/rcirc-update] Reconnects don't seem to work anymore
@ 2021-06-15 21:49 94% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-06-15 21:49 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Hi,
Tassilo Horn <tsdh@gnu.org> writes:
> I'm on fd96e3a0d9. I've just pulled again and 8 new commits appeared,
> the oldest being from 5 days ago. I'm pretty confident I've pulled at
> least every other day in order to see if there's something new. Did you
> forget to push?
No, that was not the issue, I just wanted to make sure
> Anyway, I've updated to the current branch HEAD and restarted my
> rcirc-emacs.
>
>>> 06:58 -*.freenode.net- *** You are connected to chat.freenode.net using TLS
>>> (SSL) cipher 'TLSv1.3-TLS_AES_256_GCM_SHA384'
>>> 06:58 !!! "@msgid=446~1623712485~22272;inspircd.org/service;inspircd.org/bot
>>> :NickServ!services@services.freenode.net NOTICE tsdh :Nick tsdh
>>> isn't registered." (wrong-type-argument arrayp nil)
>>
>> From your other message, it seems like this is specificity related to
>> freenode, right?
>
> Yes, only freenode and only since today with no changes on rcirc in the
> meantime. When I do
>
> /msg nickserv help
>
> in the *chat.freenode.org* buffer, I get the response
>
> 20:42 *** 401 n No such nick
>
> and in the buffer N@chat.freenode.org there is
>
> 20:42 <tsdh> ickserv help
This was an issue caused by the new rcirc-define-command macro. The
intention was to improve defun-rcirc-command by adding integrated
argument parsing, and in this case, the regular expression was nor
correctly generated, as it did not require at least one whitespace
between arguments. I hope the last commits have fixes those issues, but
I might have to rethink some more fundamental things about how that
macro works.
> So now that user N has my nickserv password and I can't change it
> because freenode seems broken...
>
> I've asked on #help and the answers are:
>
> 1. I should use "/ns IDENTIFY password" instead of "/msg NickServ".
> 2. I should look into using SASL for identificiation.
Part of the IRCv3 improvements should also include this.
> 3. "/quote nickserv identify password" also gives an
> (wrong-type-argument arrayp nil) error but finally told be that
> tsdh is not a registered nick.
>
> And then I was told that the original freenode with its user database is
> now on classic.freenode.org and irc.freenode.org is something set up
> completely anew without the previous data...
>
> I was also told that "/msg foobar text" only works if the user foobar is
> online. If not, it'll select the first online user whose nick is a
> prefix of foobar and send the remainder as message. (That's why the
> user N received my NickServ IDENTIFY message.)
>
> I've just tried "/msg totototoXXX this is a test" on libera.chat and
> it's the same there. The user t received a message "otototoXXX this is
> a test". :-(
>
> So it would make sense that rcirc checked if there is an online user
> NickServ before sending the IDENTIFY message to prevent password leakage
> to random users as has happended to me.
>
> Bye,
> Tassilo
--
Philip K.
^ permalink raw reply [relevance 94%]
* Re: [feature/rcirc-update] Reconnects don't seem to work anymore
@ 2021-06-16 7:41 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-16 7:41 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>>> Yes, only freenode and only since today with no changes on rcirc in
>>> the meantime. When I do
>>>
>>> /msg nickserv help
>>>
>>> in the *chat.freenode.org* buffer, I get the response
>>>
>>> 20:42 *** 401 n No such nick
>>>
>>> and in the buffer N@chat.freenode.org there is
>>>
>>> 20:42 <tsdh> ickserv help
>>
>> This was an issue caused by the new rcirc-define-command macro. The
>> intention was to improve defun-rcirc-command by adding integrated
>> argument parsing, and in this case, the regular expression was nor
>> correctly generated, as it did not require at least one whitespace
>> between arguments. I hope the last commits have fixes those issues,
>> but I might have to rethink some more fundamental things about how
>> that macro works.
>
> I'm now on 1181c606b3 but still "/msg nickservx test" will message
> "ickservx test" to the user N on libera.chat. I'd much prefer if that
> told me that there is no (online) user nickservx rather than messaging
> some mostly random stranger.
I can imagine that both use-cases could be of interest, so it would
probably be best to add a flag to regulate this.
>>> 2. I should look into using SASL for identificiation.
>>
>> Part of the IRCv3 improvements should also include this.
>
> Great.
>
> Bye,
> Tassilo
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [feature/rcirc-update] Reconnects don't seem to work anymore
@ 2021-06-16 8:01 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-16 8:01 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>>> I'm on fd96e3a0d9. I've just pulled again and 8 new commits appeared,
>>> the oldest being from 5 days ago. I'm pretty confident I've pulled at
>>> least every other day in order to see if there's something new. Did you
>>> forget to push?
>>
>> No, that was not the issue, I just wanted to make sure
>>
>>> Anyway, I've updated to the current branch HEAD and restarted my
>>> rcirc-emacs.
>
> By the way, I can still reproduce the issue that
> `rcirc-next-active-buffer' adapts the activity string which is then
> displayed correctly in the current TTY window but not other TTY windows.
>
> When we talked about that, I've mentioned that I had to add a
> (force-mode-line-update t) to `rcirc-update-activity-string'.
Pushed the fix, I forgot that force-mode-line-update appears to be
necessary in the TUI.
> Bye,
> Tassilo
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [feature/rcirc-update] Reconnects don't seem to work anymore
@ 2021-06-16 8:21 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-16 8:21 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
> Hi Philip,
>
>>> I'm now on 1181c606b3 but still "/msg nickservx test" will message
>>> "ickservx test" to the user N on libera.chat. I'd much prefer if
>>> that told me that there is no (online) user nickservx rather than
>>> messaging some mostly random stranger.
>>
>> I can imagine that both use-cases could be of interest, so it would
>> probably be best to add a flag to regulate this.
>
> Fine with me but I'm keen to learn about the use-case where the current
> behavior is wanted. I guess there is a use-case because otherwise the
> IRC server wouldn't have that implemented as-is.
I was thinking about when you want to message a friend who is currently
marked as away.
> And IMHO when messaging nickserv or other service bots receiving
> confidential data, the current behavior is not acceptable. I'm not sure
> if the automatic authentication in terms of `rcirc-authinfo' checks if
> nickserv (or whatever) is actually available and, if not, falls into
> that trap just as I did by messaging the non-existent NickServ manually.
That is true. It shouldn't be hard to add a check to ensure this.
> Bye,
> Tassilo
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [feature/rcirc-update] Reconnects don't seem to work anymore
@ 2021-06-16 8:48 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-16 8:48 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tsdh@gnu.org> writes:
>>> Fine with me but I'm keen to learn about the use-case where the
>>> current behavior is wanted. I guess there is a use-case because
>>> otherwise the IRC server wouldn't have that implemented as-is.
>>
>> I was thinking about when you want to message a friend who is
>> currently marked as away.
>
> "Marked as being away" is different to offline/doesn't exist, right? So
> if I'd "/msg philipk Hello" I'd still want that only philipk receives
> the message and not some other user p, ph, phi, or whoever.
Yes, of course. If rcirc is parsing any substring of a token, something
else is broken. My hope is that the changes to rcirc-define-command
should have fixed it (for now).
>>> And IMHO when messaging nickserv or other service bots receiving
>>> confidential data, the current behavior is not acceptable. I'm not sure
>>> if the automatic authentication in terms of `rcirc-authinfo' checks if
>>> nickserv (or whatever) is actually available and, if not, falls into
>>> that trap just as I did by messaging the non-existent NickServ manually.
>>
>> That is true. It shouldn't be hard to add a check to ensure this.
>
> Great.
>
> Bye,
> Tassilo
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Emacs CLA requirement
@ 2021-06-16 9:37 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-16 9:37 UTC (permalink / raw)
To: Andrei Kuznetsov; +Cc: emacs-devel
Andrei Kuznetsov <r12451428287@163.com> writes:
> Furthermore, a contributor license agreement allows the FSF to migrate
> Emacs' grant of license at any time -- whilst the regular "or later"
> clause only allows Emacs to also be available under a later version of
> the GPL; If a malicious actor relying on hypothetical system X, which is
> resolved in a hypothetical GPLv4 in the future, decides to redistribute
> a future Emacs under system X, then he would be able to do so after
> removing the small portion of contributions made under the "GPLv4 or
> later" clause. That seems like a rather big problem.
What do you mean by "system X"? Could you give a more concrete example?
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Emacs CLA requirement
@ 2021-06-16 10:22 99% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-06-16 10:22 UTC (permalink / raw)
To: Andrei Kuznetsov; +Cc: emacs-devel
Andrei Kuznetsov <r12451428287@163.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> What do you mean by "system X"? Could you give a more concrete example?
>
> I can't think of one right now; I'm not a lawyer.
>
> However, tivolization was one of the issues resolved by the GPLv3 in the
> past.
But isn't the issue, that previous releases have still been released
under the old GPL version? Apple continues distributing GPLv2 software
even though the newer versions have had their versions updated.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Emacs CLA requirement
@ 2021-06-16 11:53 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-16 11:53 UTC (permalink / raw)
To: tomas; +Cc: Andrei Kuznetsov, emacs-devel
<tomas@tuxteam.de> writes:
> On Wed, Jun 16, 2021 at 10:22:24AM +0000, Philip Kaludercic wrote:
>> Andrei Kuznetsov <r12451428287@163.com> writes:
>>
>> > Philip Kaludercic <philipk@posteo.net> writes:
>> >
>> >> What do you mean by "system X"? Could you give a more concrete example?
>> >
>> > I can't think of one right now; I'm not a lawyer.
>> >
>> > However, tivolization was one of the issues resolved by the GPLv3 in the
>> > past.
>>
>> But isn't the issue, that previous releases have still been released
>> under the old GPL version? Apple continues distributing GPLv2 software
>> even though the newer versions have had their versions updated.
>
> You sure? I remember them shipping an old version of bash, the last one
> under GPLV2. Even after some security hole appeared.
Yes, that is what I mean. They just stopped updating e.g. bash, so they
didn't have to use the GPLv3 license. Why, I too never understood.
> I didn't follow this story, these days I haven't much to do with Apple
> at all.
>
> Fortunately.
>
> Cheers
> - t
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: Emacs CLA requirement
@ 2021-06-16 12:55 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-16 12:55 UTC (permalink / raw)
To: Andrei Kuznetsov; +Cc: emacs-devel
Andrei Kuznetsov <r12451428287@163.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> But isn't the issue, that previous releases have still been released
>> under the old GPL version? Apple continues distributing GPLv2 software
>> even though the newer versions have had their versions updated.
>
> That's true, but I don't understand how it would be any better if the
> FSF cannot relicense Emacs at all (which is likely to be the case if
> Emacs drops the CLA requirement)
You're right, it wouldn't be better but I don't see how it would be
worse either. My point was that this is just not a particularly
convincing argument.
--
Philip K.
^ permalink raw reply [relevance 99%]
* NonGNU ELPA work (Was: Emacs CLA requirement)
@ 2021-06-16 21:34 97% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-06-16 21:34 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Adam Tack, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Wouldn't we all? ;-)
> BTW, I'll take this opportunity to remind people that NonGNU ELPA not
> only exists but would welcome help to include new packages (especially
> important packages like Magit).
I believe this question was already raised before, but I'd like to make
sure if anything has changes, as I would be interesting in helping to
improve NonGNU ELPA: What is to be done? How can one help? Is there
checklist somewhere with what is missing, or do we just need to gather
packages? What is the procedure for adding or suggesting new packages
(and what is blocking Magit)?
--
Philip K.
^ permalink raw reply [relevance 97%]
* Re: [PATCH] 0001-Add-icomplete-count-format
@ 2021-06-17 8:02 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-17 8:02 UTC (permalink / raw)
To: tumashu; +Cc: emacs-devel@gnu.org
tumashu <tumashu@163.com> writes:
> Hello
>
>
> What is the state of this patch? refused?
It's not up to me to decide, but I think some motivation and a more
detailed explanation in the doc-string would be helpful.
> feng
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA work
@ 2021-06-17 8:36 81% ` Philip Kaludercic
2021-08-04 11:08 47% ` Philip Kaludercic
1 sibling, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-06-17 8:36 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Adam Tack, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Philip Kaludercic [2021-06-16 21:34:32] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Wouldn't we all? ;-)
>>> BTW, I'll take this opportunity to remind people that NonGNU ELPA not
>>> only exists but would welcome help to include new packages (especially
>>> important packages like Magit).
>> I believe this question was already raised before, but I'd like to make
>> sure if anything has changes, as I would be interesting in helping to
>> improve NonGNU ELPA: What is to be done? How can one help? Is there
>> checklist somewhere with what is missing, or do we just need to gather
>> packages?
>
> The NonGNU ELPA archive is operational, so all we need is to add
> packages to it. The main criteria:
> - Important enough that we want them in NonGNU even though we can't get
> copyright paperwork for it.
> - Acceptable: can be used without (and doesn't advertise or promote)
> proprietary software and only requires packages in Emacs or
> GNU/NonGNU ELPA.
From browsing MELPA's homepage, these would be my suggestions:
- pdf-tools
- geiser
- erlang-mode
- web-mode
- macrostep
- cider
- dumb-jump
- multiple-cursors
- haskell-mode
- htmlize
- paredit
- json-mode
- go-mode
- rust-mode
- editorconfig
- yasnippet-snippets
- wgrep
- lua-mode
- smartparens
- evil
and their respective dependencies.
These have all more than 100000 downloads on MELPA, and are often
mentioned in Emacs communities. I think adding more language support is
self-evidently good (I am especially invested in go-mode, because the
development of the package has stagnated).
I'd have to check the number of contributors and the number of
contributors with assignments first/number of contributors with
significant contributions and no assignment. Some of these packages are
based on a lot of little contributions (dumb-jump, yasnippet-snippets)
that can easily exceed the 15-line rule, and trying to contact all the
contributors can be pretty hard.
Others are used by GNU projects and/or packages that are bundled with
Emacs (Org has a weak dependency on htmlize, geiser is used by Guix).
Other than these, there are a lot of themes around the 100000 downloads
point, that also might be of interest.
>> What is the procedure for adding or suggesting new packages
>
> At the minimum send an email suggesting a particular package (with
> a URL to its Git repository).
> Better if it comes with some argument why we want it.
> Even better if it comes with a patch to nongnu.git's `elpa-packages`.
I would be glad to contribute patches for all the packages I have
enumerated above.
>> (and what is blocking Magit)?
>
> Good question. My guess is that Jonas has just been busy with
> other things, so you may want to ask him in which way you can help.
>
> Stefan
>
--
Philip K.
^ permalink raw reply [relevance 81%]
* Re: NonGNU ELPA work
@ 2021-06-17 9:55 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-17 9:55 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Adam Tack, emacs-devel
Jean Louis <bugs@gnu.support> writes:
> * Stefan Monnier <monnier@iro.umontreal.ca> [2021-06-17 01:25]:
>> > What is the procedure for adding or suggesting new packages
>>
>> At the minimum send an email suggesting a particular package (with
>> a URL to its Git repository).
>> Better if it comes with some argument why we want it.
>> Even better if it comes with a patch to nongnu.git's
>> `elpa-packages`.
>
> Suggestions or NonGNU ELPA, not requiring outside packages
> ==========================================================
>
> Markdown mode:
> URL: https://jblevins.org/projects/markdown-mode/
Markdown-mode has already been added: http://elpa.nongnu.org/nongnu/markdown-mode.html
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA work
@ 2021-06-18 9:06 95% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-18 9:06 UTC (permalink / raw)
To: Richard Stallman; +Cc: emacs-devel, Stefan Monnier, adam.tack.513
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> We still have a few questions to resolve about how to manage nonGNU
> ELPA, so that it will avoid the problems that MELPA has.
What are the main issues? The ones I am familiar with is the broken
versioning system and the fact that new package versions are created for
(roughly) every commit by default, and that the "stable" variation is
the alternative. I also remember the conversation about MELPA including
packages that promote and/or depend on non-free software, but that was
already ruled out.
> Some of us were discussing this in January, and since then I've had a
> series of crises so I could not try to find solutions.
What thread was that discussed in? I just checked the archives, and
there were multiple conversations that could be related to this.
> That remains the case now. unfortunately.
>
> Please don't add more packages to NonGNU ELPA until we resolve the
> problems of the right way to do that.
--
Philip K.
^ permalink raw reply [relevance 95%]
* Reloading themes in user option setters
@ 2021-06-25 19:12 69% Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-25 19:12 UTC (permalink / raw)
To: emacs-devel; +Cc: info
Hi,
in a recent discussion on the modus-themes issue tracker[0], the concept
of reloading a user theme in the :set function of a user option was
debated. The plan is to add this to the next version, that might or
might not be part of the next Emacs release.
For those who don't know, modus-themes provides a number of user options
to change details, e.g. the usage of variable-pitch outside of buffers
(modus-themes-variable-pitch-UI).
About a month ago I wanted to make it easier to explore the space for
customization, by adding a custom setter to all applicable options, that
reload the current modus-theme, when the value is changed[1]. The idea
was to resemble the way that Emacs immediately changes faces when the
user changes something. The feature worked and it was merged.
In the aforementioned thread[0], we noticed that this can result in a
significant increase of the time needed to load the theme. It turns out
that the combination of customizing user options by adding them to the
"user" theme and using load-theme results in the theme being reloaded
for every user option.
One way to avoid this is to in the setter check if `custom--inhibit-theme-enable' is
set to nil[2], before reloading the themes. This works,
because enable-theme sets the value to nil. The issue here is that
custom--inhibit-theme-enable is designated to be an internal variable,
so we were not sure whether or not this is a good solution, considering
that this change might eventually be added to the core.
For that reason we would be interested in hearing opinions from the
readers of this list on the proposed solution or on the feature
itself. I am uncertain if the behaviour should or should not be
considered a bug, but even if that were to be the case, modus-themes
cannot rely on a bug fix in the next version because it still targets
older versions.
[0] https://gitlab.com/protesilaos/modus-themes/-/issues/213
[1] https://gitlab.com/protesilaos/modus-themes/-/merge_requests/38
[2] https://gitlab.com/protesilaos/modus-themes/-/issues/213#note_606022214
--
Philip K.
^ permalink raw reply [relevance 69%]
* Re: About SASL authentication in rcirc
@ 2021-06-29 8:04 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-06-29 8:04 UTC (permalink / raw)
To: amk; +Cc: emacs-devel, Tassilo Horn
Sorry for my late response,
amk@amk.ie writes:
> June 28, 2021 11:36 AM, "Tassilo Horn" <tsdh@gnu.org> wrote:
>
>> Hi Alex,
>>
>> thanks for bringing SASL authentication to rcirc. I'm using the
>> rcirc-update branch of Philip for my IRC needs where Philip has
>> cherry-picked your commit implementing SASL authentication for rcirc.
>> So obviously I wanted to try that out and changed my
>>
>> --8<---------------cut here---------------start------------->8---
>> (setq rcirc-authinfo
>> `(("libera" nickserv "tsdh" ,th/nickserv-password-liberachat)))
>> --8<---------------cut here---------------end--------------->8---
>>
>> to
>>
>> --8<---------------cut here---------------start------------->8---
>> (setq rcirc-authinfo
>> `(("libera" sasl "tsdh" ,th/nickserv-password-liberachat)))
>> --8<---------------cut here---------------end--------------->8---
>>
>> and restarted my rcirc session after rebuilding emacs.
>>
>> After that, the *irc.libera.chat* buffer contained a message that tsdh
>> is a registered nick but not the message afterwards that I'm
>> successfully registered now (as it is the case with nickserv
>> authentication). And when querying NickServ, it told me that I'm not
>> logged it.
>>
>> If I understand SASL/IRC correctly, it should have logged in immediately
>> on connecting, right?
>>
>> So apparently, it seems that it didn't work when I've tried. I'd be
>> happy to debug where it fails if you give me some pointers what to look
>> for.
>>
>> Bye,
>> Tassilo
>
> Hey,
>
> Correct, It should authenticate automatically
>
> I think the issue is that some of the original sasl commit got lost in
> cherry picking. I've attached a patch that fixes it, I'm not sure if
> there is a better place to send a patch to a branch.
That was probably the issue, I didn't get around to properly test it
yet. Sorry about that.
> Thanks,
> Alex
>
>
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: On the adoption of transient.el
@ 2021-07-05 14:24 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-07-05 14:24 UTC (permalink / raw)
To: Gabriel; +Cc: emacs-devel
Gabriel <gabriel376@hotmail.com> writes:
> Hi,
>
> With the inclusion of the wonderful transient.el library into Emacs
> (commit afcdd4cab3 Apr 20 2021), I wonder what are the plans to leverage
> it inside Emacs (gnus, help, project etc) out-of-the-box. I see many
> opportunities in this regard although I didn't find any discussion in
> #emacs-devel. The technical aspects seems to be straightforward to
> implement, but perhaps it's a big topic to decide 'if' or 'how' Emacs
> will leverage transient.el and the possible impacts on users. I would
> love to hear more about it.
Do you have any concrete examples where it could be used?
> Regards,
> Gabriel
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: On the adoption of transient.el
@ 2021-07-05 18:09 96% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-07-05 18:09 UTC (permalink / raw)
To: Yuri Khan; +Cc: Gabriel, Emacs developers
Yuri Khan <yuri.v.khan@gmail.com> writes:
> On Mon, 5 Jul 2021 at 21:25, Philip Kaludercic <philipk@posteo.net> wrote:
>
>> Do you have any concrete examples where it could be used?
>
> Every time I do an ‘M-x rgrep’, I am asked three to infinity
> questions, in a sequence:
This is interesting, from my understanding transient makes for a good
interface for calling commands with a lot of flags (git, ffmpeg, pandoc,
...). On the other hand something has always felt off about transient,
in the sense that it is breaking some expected behaviour or couldn't
pin-point yet, but just unconsciously stumble over.
I think that the best path of action is to make concrete suggestions,
to discuss and improve.
--
Philip Kaludercic
^ permalink raw reply [relevance 96%]
* Re: Cleaning up rcirc
@ 2021-07-22 22:14 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-07-22 22:14 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Andreas Schwab, emacs-devel
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Either way, I also noticed there were other issues with the code, that I
>> have since fixed. Would it be ok to push the changes as a feature
>> branch, so that I don't have to re-send all the patches again and again?
>
> Sure, putting the changes on a feature branch would be nice.
After having a few people test it, we were thinking about merging a
first version the branch back into master. Would you have any objections
to that?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: access to ELPA development packages?
@ 2021-07-23 11:04 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-07-23 11:04 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: emacs-devel
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> So, this gnu-devel repo is in essence something similar to MELPA,
> right? I agree that it'd be nice if was publicized a bit more (I had
> never heard of it until now), so packages can get more testing during
> their development cycles.
I fear that promoting the devel repo might have people use it even if
they don't have to, leading to the same kinds of issues that MELPA has.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Add Maildir support to RMAIL
@ 2021-07-26 8:35 92% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-07-26 8:35 UTC (permalink / raw)
To: csh; +Cc: ane, emacs-devel
csh <csh@bluehome.net> writes:
> Fellow Emacsites,
>
> I really love the simplicity of reading mail with RMAIL, but most
> email providers no longer use the mbox format for mail. Is there any
> way someone could get RMAIL working with Maildir mailboxes?
I have thought about this in the past, but I don't think it would be
possible without rewriting RMAIL to a significant degree. RMAIL can be
seen as a major mode for mbox files, and translating that onto Maildir
would probably turn out messy if backwards compatibility is to be
maintained.
It would probably be better to create a new client, that might use Gnus
code, but tries to provide a Rmail-like interface (and not trying to
abstract over all possible news sources, but just limiting itself to
email). I started writing code for a client like this some while ago,
but gave up because Gnus is good enough for me.
> The only thing I could find on the matter was a blog entry[1], but the solution did not seem complete. It was more of a workaround, and I don't know how well it would work day-to-day.
>
> Thanks,
> Caleb Herbert
>
> CC: Antoine Kalmbach.
>
> [1]: Kalmbach, Antoine. "Back to Rmail." URI: <https://ane.github.io/2020/09/09/rmail.html>.
>
--
Philip Kaludercic
^ permalink raw reply [relevance 92%]
* Re: Add Maildir support to RMAIL
@ 2021-07-26 8:35 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-07-26 8:35 UTC (permalink / raw)
To: csh; +Cc: Eli Zaretskii, ane, emacs-devel
csh <csh@bluehome.net> writes:
> Eli Zaretskii <eliz@gnu.org> wrote ..
>> Would it be possible to lift some code or ideas from Gnus?
>
> Maybe, but Gnus is the opposite of what I want. Its interface is too
> overwhelming for me to use, and it frequently makes Emacs lock up. Not
> something I want for a common task like email.
>
> Plus, I absolutely love "C-x m" or whatever the default mail composition
> buffer/mode is called.
It is either mail-mode or message-mode.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: access to ELPA development packages?
@ 2021-07-26 20:52 69% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-07-26 20:52 UTC (permalink / raw)
To: Richard Stallman; +Cc: bozhidar, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > I fear that promoting the devel repo might have people use it even if
> > they don't have to, leading to the same kinds of issues that MELPA has.
>
> I don't know whether this is a valid concern, but I think the issue is
> important enough that we need to discuss whether it is a valid concern.
>
> Could you please explain the problematical usage scenario that you
> have in mind?
MELPA primarily advertises the non-stable channel, that creates a new
package version for commit in a package repository (like ELPA devel).
The problems that arise from this is that different users receive more
or less random snapshots, which is especially critical when packages
depend on one another, updating packages involves a lot more "luck" than
should be necessary. I think the argument has been insinuated in this
thread, that this makes it easier to catch bugs early, but I don't think
every user should have to deal with that (after all, any freedom,
including software freedom, should also include the freedom to say
"no"). And setting that aside, package.el doesn't provide a good basis
for development and contributing -- if you want to do more than
debugging or changing something that should be more persistent, you'll
have to clone the source manually.
Two issues specific to MELPA is that a lot of "stable" packages depend
on "unstable" packages, that might have not received a stable release,
or marked as such (MELPA requires manual tagging of releases using git
tags), so that some packages just do not release stable versions at all,
splitting the repository. The second issue is that MELPA (unstable)
generates version tags directly from the commit data, resulting in
versions like "20210721.2003". ELPA devel handles this better by
appending the date to the actual version: "0.9.13.0.20210721.211455"
(both of these version tags were taken from the company package). This
makes switching between repositories easer to handle.
For most users, there is simply no reason to deal with the devel
repository. And speaking from experience, when someone starts dealing
with Emacs, they are very likely to just copy random code off blogs and
fora until something appears to work. Having development versions of
ELPA advertised with ready-to-copy code will just break stuff. I guess
mentioning it doesn't inherently pose an issue. Either way, the reason
I am interested in seeing GNU and NonGNU ELPA is that this incentives
stable package releases as the default mode of operation, so that is
where I am coming from with this line of argumentation.
--
Philip Kaludercic
^ permalink raw reply [relevance 69%]
* Re: access to ELPA development packages?
@ 2021-07-27 8:12 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-07-27 8:12 UTC (permalink / raw)
To: dick; +Cc: bozhidar, Richard Stallman, emacs-devel
dick <dick.r.chiang@gmail.com> writes:
> You've explained this poorly, and at too esoteric a level of detail.
>
> Donning my anti-flak jacket in preparation for RMS's justifiable indignation
> at my having spoken for his eminence, RMS is more concerned about the public's
> conflation of MELPA with GNU, the former having accrued enough name
> recognition over the years to become metonymous with the emacs community despite
> flouting FSF doctrine.
> The MELPA versioning deficiencies are irksome yes, but in no way deleterious
> to MELPA's popularity or basic function, which is two-fold, to provide a
> package archive unconstrained by FSF doctrine, and to feed our narcissism as
> programmers. To expand on the latter, more than ninety percent of the
> packages hosted on MELPA are pet projects of dubious practical value.
>
> To those ends, MELPA provides real value, the objections of ideologues notwithstanding.
My issues with MELPA are not ideological. I know that they have non-free
adjacent software and a lot of weird stuff -- and good stuff too -- but
I am really just conceder with MELPA "unstable" being the default
repository a lot of people use.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Silence checkdoc for symbols designating major and minor modes
@ 2021-07-27 21:50 79% Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-07-27 21:50 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 730 bytes --]
Hi,
an issue I have been having when documenting code is that checkdoc wants
me to disambiguate symbols referring to major or minor modes. That
usually means adding "function", "command" "variable", "option" or
"symbol" but in my experience these usually do not fit. In fact, most of
the time it is obvious what is meant when referring to a major/minor
mode.
... Foo when `bar-mode' is active ...
The patch I added below silences the disambiguation request when a
symbol ends in "-mode". Alternatively, one could also add a "minor mode"
and "major mode" to the list of accepted keywords, but I think that
would sound to repetitive:
... Foo when minor mode `bar-mode' is active ...
Opinions?
--
Philip K.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ignore-ambiguous-symbols-that-end-in-mode.patch --]
[-- Type: text/x-diff, Size: 891 bytes --]
From afbfcec6f0da120c99ff1ff3e0355544c768cb8c Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Tue, 27 Jul 2021 23:43:13 +0200
Subject: [PATCH] Ignore ambiguous symbols that end in "-mode"
* checkdoc.el (checkdoc-this-string-valid-engine): Check if bound and
fbound symbol ends in "-mode"
---
lisp/emacs-lisp/checkdoc.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/lisp/emacs-lisp/checkdoc.el b/lisp/emacs-lisp/checkdoc.el
index 00cc7777e1..9831a5aa06 100644
--- a/lisp/emacs-lisp/checkdoc.el
+++ b/lisp/emacs-lisp/checkdoc.el
@@ -1559,6 +1559,7 @@ checkdoc-this-string-valid-engine
(setq mb (match-beginning 1)
me (match-end 1))
(if (and sym (boundp sym) (fboundp sym)
+ (not (string-match-p "-mode\\'" (symbol-name sym)))
(save-excursion
(goto-char mb)
(forward-word-strictly -1)
--
2.30.2
^ permalink raw reply related [relevance 79%]
* Re: Silence checkdoc for symbols designating major and minor modes
@ 2021-07-28 14:46 92% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-07-28 14:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Tue, 27 Jul 2021 21:50:43 +0000
>>
>> an issue I have been having when documenting code is that checkdoc wants
>> me to disambiguate symbols referring to major or minor modes. That
>> usually means adding "function", "command" "variable", "option" or
>> "symbol" but in my experience these usually do not fit. In fact, most of
>> the time it is obvious what is meant when referring to a major/minor
>> mode.
First of all, I have to correct myself: This only applies to minor
modes, because they are both bound and fbound.
>>
>> ... Foo when `bar-mode' is active ...
>>
>> The patch I added below silences the disambiguation request when a
>> symbol ends in "-mode". Alternatively, one could also add a "minor mode"
>> and "major mode" to the list of accepted keywords, but I think that
>> would sound to repetitive:
>>
>> ... Foo when minor mode `bar-mode' is active ...
>>
>> Opinions?
>
> First, the code, if installed, should have a comment explaining why
> these strings are being exempted.
Of course, this was just a first suggestion.
> More generally, could you please show an example of a doc string and
> the warning(s) it triggers? I'm not sure I understand the problem
> well enough to make up my mind. (Do all of our existing modes suffer
> from this problem?)
I noticed this when updating the rcirc docstrings. For example, I still
have the issue here:
(defcustom rcirc-omit-responses
'("JOIN" "PART" "QUIT" "NICK")
"Responses which will be hidden when `rcirc-omit-mode' is enabled."
:type '(repeat string))
triggering this response:
Disambiguate rcirc-omit-mode by preceding w/ function,command,variable,option or symbol.
Browsing through the repository, I also discovered the same issue in
turn-on-eldoc-mode's docstring. There are other examples in third-party
code I remember, but couldn't find right now.
> Thanks.
--
Philip Kaludercic
^ permalink raw reply [relevance 92%]
* Re: Silence checkdoc for symbols designating major and minor modes
@ 2021-07-30 11:17 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-07-30 11:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 28 Jul 2021 14:46:57 +0000
>>
>> (defcustom rcirc-omit-responses
>> '("JOIN" "PART" "QUIT" "NICK")
>> "Responses which will be hidden when `rcirc-omit-mode' is enabled."
>> :type '(repeat string))
>>
>> triggering this response:
>>
>> Disambiguate rcirc-omit-mode by preceding w/ function,command,variable,option or symbol.
>
> FWIW, I think this warning should be removed wholesale. It is too
> harsh to require such finesses in doc strings.
I am inclined to agree, as in my experience, I have only ever seen
false-positives being highlighted by this rule.
> But if we want to keep it, I think we should include in the regexp
> also the "enabled" and "disabled" part that follows it. Just
> exempting "-mode" sounds too general for a heuristic.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA work
2021-06-17 8:36 81% ` Philip Kaludercic
@ 2021-08-04 11:08 47% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-04 11:08 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Adam Tack, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
Philip Kaludercic <philipk@posteo.net> writes:
>>>> What is the procedure for adding or suggesting new packages
>>>
>>> At the minimum send an email suggesting a particular package (with
>>> a URL to its Git repository).
>>> Better if it comes with some argument why we want it.
>>> Even better if it comes with a patch to nongnu.git's `elpa-packages`.
>>
>> I would be glad to contribute patches for all the packages I have
>> enumerated above.
I have been trying to prepare the patches for the last few days, but
there seem to be issues with the build system (or hopefully I'm doing
something wrong):
$ make build-all
emacs --batch -Q -l admin/elpa-admin.el \
-f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk
emacs --batch -l /home/philip/Code/src/nongnu/admin/elpa-admin.el \
-f elpaa-batch-make-all-packages
Updating worktree in "/home/philip/Code/src/nongnu/packages/geiser/"
Updated geiser: merge: refs/remotes/origin/elpa/geiser - not something we can merge
Updating worktree in "/home/philip/Code/src/nongnu/packages/smartparens/"
Updated smartparens: fatal: No remote for the current branch.
Updating worktree in "/home/philip/Code/src/nongnu/packages/lua-mode/"
Updated lua-mode: fatal: No remote for the current branch.
Updating worktree in "/home/philip/Code/src/nongnu/packages/wgrep/"
Updated wgrep: fatal: No remote for the current branch.
...
I have attached the current version of the elpa-packages file below, in
case there should be anything wrong with that:
[-- Attachment #2: Type: text/plain, Size: 4483 bytes --]
;; -*- lisp-data -*-
;; List of packages.
;; The list is made of elements of the form (NAME . PLIST)
;; Every package needs a corresponding Git branch in the repository
;; with name `externals/NAME`.
;;
;; See "Specifications" in the admin/README file for the properties
;; that can be used in PLIST.
(
("caml" :url "https://github.com/ocaml/caml-mode"
;; The version 4.7.1 from Melpa-stable seems to correspond to
;; revision a9134009.
:version-map ((nil "4.7.1" "a9134009bd037a39cbda21806867d0534d340bca")))
;; ("magit" :url "https://github.com/magit/magit"
;; :lisp-dir "lisp")
("markdown-mode" :url "https://github.com/jrblevin/markdown-mode"
:readme "README.md"
;; Not needed any more:
;; :dont-release "-dev\\'"
)
("request" :url "https://github.com/tkf/emacs-request"
:ignored-files ("tests" "doc" "COPYING"))
("org-contrib" :url "https://git.sr.ht/~bzg/org-contrib"
:lisp-dir "lisp"
:readme "README.org"
:ignored-files ("README.md"))
("sly" :url "https://github.com/joaotavora/sly"
:texinfo "doc/sly.texi"
;; Not needed any more:
;; :version-map (("1.0.0-beta-3" "1.0.0beta3"))
)
("tuareg" :url "https://github.com/ocaml/tuareg.git")
;; ("with-editor" :url "https://github.com/magit/with-editor"
;; )
("geiser" :url "https://gitlab.com/emacs-geiser/geiser.git"
:lisp-dir "elisp"
:readme "readme.org"
:doc "news.org"
:doc "doc/geiser.texi")
("geiser-chez" :url "https://gitlab.com/emacs-geiser/chez.git")
("geiser-chez" :url "https://gitlab.com/emacs-geiser/chez.git")
("geiser-chibi" :url "https://gitlab.com/emacs-geiser/chibi.git")
("geiser-chicken" :url "https://gitlab.com/emacs-geiser/chicken.git")
("geiser-gambit" :url "https://gitlab.com/emacs-geiser/gambit.git")
("geiser-gauche" :url "https://gitlab.com/emacs-geiser/gauche.git")
("geiser-guile" :url "https://gitlab.com/emacs-geiser/guile.git")
("geiser-kawa" :url "https://gitlab.com/emacs-geiser/kawa.git"
:lisp-dir "elisp"
:ignored-files ("elisp/tests"))
("geiser-mit" :url "https://gitlab.com/emacs-geiser/mit.git")
("geiser-racket" :url "https://gitlab.com/emacs-geiser/racket.git")
("geiser-stklos" :url "https://gitlab.com/emacs-geiser/stklos.git")
("goto-chg" :url "https://github.com/emacs-evil/goto-chg")
("evil" :url "https://github.com/emacs-evil/evil"
:ignored-files ("lib" "scripts" "doc")
:doc "doc/build/texinfo/evil.texi")
("smartparens" :url "https://github.com/Fuco1/smartparens"
:ignored-files ("dev" "doc" "images" "test")
;; See https://github.com/Fuco1/smartparens/releases/tag/1.11.0
:version-map ((nil "1.11.0" "4873352b5d0a1c5142658122de1b6950b8fe7e4d")))
("lua-mode" :url "https://github.com/immerrr/lua-mode/"
:ignored-files ("test" "travis" "init-tryout.el"))
("wgrep" :url "https://github.com/mhayashi1120/Emacs-wgrep")
("yasnippet-snippets" :url "https://github.com/AndreaCrotti/yasnippet-snippets"
:ignored-files ("report" "snippets.html"))
("editorconfig" :url "https://github.com/editorconfig/editorconfig-emacs"
:doc "doc/editorconfig.texi"
:news "CHANGELOG.md"
:ignored-files ("bin" "ert-tests"))
("rust-mode" :url "https://github.com/rust-lang/rust-mode"
:ignored-files ("test-project"
"run_rust_emacs_tests.sh"
"run_rust_emacs_tests_docker.sh"
"test-by-cp"
"test-from-git"
"triagebot.toml"))
("go-mode" :url "https://github.com/dominikh/go-mode.el"
:ignored-files ("generate_authors.sh"))
("paredit" :url "https://mumble.net/~campbell/git/paredit.git"
:ignored-files ("check.sh" "genhtml.sh" "test.el"))
("htmlize" :url "https://github.com/hniksic/emacs-htmlize"
:ignored-files ("htmlize.el.html"))
("haskell-mode" :url "https://github.com/haskell/haskell-mode"
:doc "doc/haskell-mode.texi"
:ignored-files ("images" "test" "logo.svg")
;; See https://github.com/haskell/haskell-mode/releases/tag/17.2
:version-map ((nil "17.2" "e72677668f5fc7cc148008e885a0f256e245dd43")))
("multiple-cursors" :url "https://github.com/magnars/multiple-cursors.el"
:ignored-files ("features"))
("macrostep" :url "https://github.com/joddie/macrostep"
:ignored-files ("lib" "macrostep-test.el"))
("web-mode" :url "https://github.com/fxbois/web-mode"
:ignored-files ("issues" "tests" "run.sh"))
("erlang" :url "https://github.com/erlang/otp"
:lisp-dir "lib/tools/emacs"
:ignored-files ("internal_doc" "tags.3" "vsn.mk"))
("slime" :url "https://github.com/slime/slime"
:doc "doc/slime.texi")
)
[-- Attachment #3: Type: text/plain, Size: 278 bytes --]
Then there is also the issue that 'all-in-place' keeps failing because
of byte-compilation issues in the packages. They can be solved, but it
might also make sense to not compile everything indicated by
:ignored-files. Or is this behaviour intentional?
--
Philip Kaludercic
^ permalink raw reply [relevance 47%]
* Re: On the adoption of transient.el
@ 2021-08-04 11:22 86% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-04 11:22 UTC (permalink / raw)
To: Rudolf Adamkovič; +Cc: Gabriel, Yuri Khan, Emacs developers
Rudolf Adamkovič <salutis@me.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> On the other hand something has always felt off about transient, in
>> the sense that it is breaking some expected behaviour or couldn't
>> pin-point yet, but just unconsciously stumble over.
>
> This is exactly how I feel about the "modern" interfaces in Emacs. I
> reported a bug in Embark recently, and because I could not select and
> copy the text, I ended up re-typing the text that was right in front
> of me in Emacs. Say what? For me, Emacs is a program where I expect to
> never waste time re-typing anything. Magit has a similar feel to it,
> and I can never be sure if the program will allow me to select text in
> the diverse parts of its user interface. In my opinion, such
> uncertainty is bad for power users. I would expect this from Apple or
> Microsoft software, because their latest “UX designers” surely know
> better than anyone, but in Emacs?
I am not sure if this is something specific to modern interfaces, or
rather an overreaching when it comes to binding. After a while I managed
to "pin-point" what was irritating me, and it was the missing ability to
search (something that I seem to do so passively that i didn't even
notice it). Having C-s work is especially useful when there are a lot of
transient options. This cannot be solved by binding C-s manually,
as just because that might work for me, there is some other behaviour
someone else is expecting (eg. your example of selecting and copying
text).
What I understand transient and certain other packages do is basically
override most keys, even those it doesn't use. This is more invasive
than special-mode, that just doesn't bind self-insert-command to most
keys. What I wonder is why this is done/why it might be necessary.
> R+
--
Philip Kaludercic
^ permalink raw reply [relevance 86%]
* Re: NonGNU ELPA work
@ 2021-08-04 18:41 26% ` Philip Kaludercic
2021-08-04 18:44 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-04 18:41 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Adam Tack, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I have been trying to prepare the patches for the last few days, but
>> there seem to be issues with the build system (or hopefully I'm doing
>> something wrong):
>>
>> $ make build-all
>> emacs --batch -Q -l admin/elpa-admin.el \
>> -f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk
>> emacs --batch -l /home/philip/Code/src/nongnu/admin/elpa-admin.el \
>> -f elpaa-batch-make-all-packages
>> Updating worktree in "/home/philip/Code/src/nongnu/packages/geiser/"
>> Updated geiser: merge: refs/remotes/origin/elpa/geiser - not something we can merge
>>
>> Updating worktree in "/home/philip/Code/src/nongnu/packages/smartparens/"
>> Updated smartparens: fatal: No remote for the current branch.
>>
>> Updating worktree in "/home/philip/Code/src/nongnu/packages/lua-mode/"
>> Updated lua-mode: fatal: No remote for the current branch.
>>
>> Updating worktree in "/home/philip/Code/src/nongnu/packages/wgrep/"
>> Updated wgrep: fatal: No remote for the current branch.
>
> This seems to point to a problem in the "setup" of your directory.
> Maybe `origin` isn't pointing to the nongnu,git repository?
It seems to be pointing to the right destination:
icterid$ git remote -v
gnu-elpa https://git.sv.gnu.org/r/emacs/elpa.git (fetch)
gnu-elpa https://git.sv.gnu.org/r/emacs/elpa.git (push)
origin zge@git.savannah.gnu.org:/srv/git/emacs/nongnu.git (fetch)
origin zge@git.savannah.gnu.org:/srv/git/emacs/nongnu.git (push)
> `build-all` is really meant for `elpa.gnu.org` and you shouldn't need to
> use it unless you really want to reproduce the whole NonGNU archive.
>
> Instead you can use things like `make build/lua-mode` or `make
> lua-mode.tar` to test a particular package spec.
I was using build-all for the sake of convenience, but the same issue
appears when making build/lua-mode. lua-mode.tar seems to work, so I'm
adding the patches for all the packages I have tested until now:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-geiser-Add-packages.patch --]
[-- Type: text/x-diff, Size: 1574 bytes --]
From 92d4a9347656ecced427e0f30ec713cf0635b4db Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 17:43:30 +0200
Subject: [PATCH 01/17] * elpa-packages (geiser): Add packages
---
elpa-packages | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index b495e00db1..9242fb7a4e 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -14,6 +14,25 @@
;; revision a9134009.
:version-map ((nil "4.7.1" "a9134009bd037a39cbda21806867d0534d340bca")))
+ ("geiser" :url "https://gitlab.com/emacs-geiser/geiser.git"
+ :lisp-dir "elisp"
+ :readme "readme.org"
+ :doc "doc/geiser.texi")
+
+ ("geiser-chez" :url "https://gitlab.com/emacs-geiser/chez.git")
+ ("geiser-chez" :url "https://gitlab.com/emacs-geiser/chez.git")
+ ("geiser-chibi" :url "https://gitlab.com/emacs-geiser/chibi.git")
+ ("geiser-chicken" :url "https://gitlab.com/emacs-geiser/chicken.git")
+ ("geiser-gambit" :url "https://gitlab.com/emacs-geiser/gambit.git")
+ ("geiser-gauche" :url "https://gitlab.com/emacs-geiser/gauche.git")
+ ("geiser-guile" :url "https://gitlab.com/emacs-geiser/guile.git")
+ ("geiser-kawa" :url "https://gitlab.com/emacs-geiser/kawa.git"
+ :lisp-dir "elisp"
+ :ignored-files ("elisp/tests"))
+ ("geiser-mit" :url "https://gitlab.com/emacs-geiser/mit.git")
+ ("geiser-racket" :url "https://gitlab.com/emacs-geiser/racket.git")
+ ("geiser-stklos" :url "https://gitlab.com/emacs-geiser/stklos.git")
+
;; ("magit" :url "https://github.com/magit/magit"
;; :lisp-dir "lisp")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-elpa-packages-evil-Add-packages.patch --]
[-- Type: text/x-diff, Size: 1077 bytes --]
From 5ad8cb0fd74ac5914b7a45bbd566338d3c6da81e Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 17:52:35 +0200
Subject: [PATCH 02/17] * elpa-packages (evil): Add packages
---
elpa-packages | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 9242fb7a4e..b8031c4090 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -14,6 +14,10 @@
;; revision a9134009.
:version-map ((nil "4.7.1" "a9134009bd037a39cbda21806867d0534d340bca")))
+ ("evil" :url "https://github.com/emacs-evil/evil"
+ :ignored-files ("lib" "scripts" "doc")
+ :doc "doc/build/texinfo/evil.texi")
+
("geiser" :url "https://gitlab.com/emacs-geiser/geiser.git"
:lisp-dir "elisp"
:readme "readme.org"
@@ -33,6 +37,8 @@
("geiser-racket" :url "https://gitlab.com/emacs-geiser/racket.git")
("geiser-stklos" :url "https://gitlab.com/emacs-geiser/stklos.git")
+ ("goto-chg" :url "https://github.com/emacs-evil/goto-chg")
+
;; ("magit" :url "https://github.com/magit/magit"
;; :lisp-dir "lisp")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-elpa-packages-smartparens-Add-package.patch --]
[-- Type: text/x-diff, Size: 870 bytes --]
From 3f4222c8bfe95f068dd2583954e9a09b41f89b73 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 17:55:29 +0200
Subject: [PATCH 03/17] * elpa-packages (smartparens): Add package
---
elpa-packages | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index b8031c4090..93678222ae 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -62,6 +62,11 @@
;; :version-map (("1.0.0-beta-3" "1.0.0beta3"))
)
+ ("smartparens" :url "https://github.com/Fuco1/smartparens"
+ :ignored-files ("dev" "doc" "images" "test")
+ ;; See https://github.com/Fuco1/smartparens/releases/tag/1.11.0
+ :version-map ((nil "1.11.0" "4873352b5d0a1c5142658122de1b6950b8fe7e4d")))
+
("tuareg" :url "https://github.com/ocaml/tuareg.git")
;; ("with-editor" :url "https://github.com/magit/with-editor"
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-elpa-packages-lua-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 686 bytes --]
From e1a57e4553e5a16e5eb1337f7203ed6659abfc25 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 17:59:43 +0200
Subject: [PATCH 04/17] * elpa-packages (lua-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 93678222ae..dcf10b97f2 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -39,6 +39,9 @@
("goto-chg" :url "https://github.com/emacs-evil/goto-chg")
+ ("lua-mode" :url "https://github.com/immerrr/lua-mode/"
+ :ignored-files ("test" "travis" "init-tryout.el"))
+
;; ("magit" :url "https://github.com/magit/magit"
;; :lisp-dir "lisp")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: 0005-elpa-packages-wgrep-Add-package.patch --]
[-- Type: text/x-diff, Size: 570 bytes --]
From 2cb37e0760059b6bb02c08286fa7d41862fd4863 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:06:20 +0200
Subject: [PATCH 05/17] * elpa-packages (wgrep): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index dcf10b97f2..9bd42cabba 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -74,4 +74,7 @@
;; ("with-editor" :url "https://github.com/magit/with-editor"
;; )
+
+ ("wgrep" :url "https://github.com/mhayashi1120/Emacs-wgrep")
+
)
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #7: 0006-elpa-packages-editorconfig-Add-package.patch --]
[-- Type: text/x-diff, Size: 844 bytes --]
From 91157f29f3119a62df2fb8c367261f5bcc292931 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:10:32 +0200
Subject: [PATCH 06/17] * elpa-packages (editorconfig): Add package
---
elpa-packages | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 9bd42cabba..17d074e580 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -14,6 +14,11 @@
;; revision a9134009.
:version-map ((nil "4.7.1" "a9134009bd037a39cbda21806867d0534d340bca")))
+ ("editorconfig" :url "https://github.com/editorconfig/editorconfig-emacs"
+ :doc "doc/editorconfig.texi"
+ :news "CHANGELOG.md"
+ :ignored-files ("bin" "ert-tests"))
+
("evil" :url "https://github.com/emacs-evil/evil"
:ignored-files ("lib" "scripts" "doc")
:doc "doc/build/texinfo/evil.texi")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #8: 0007-elpa-packages-yasnippet-snippets-Add-package.patch --]
[-- Type: text/x-diff, Size: 639 bytes --]
From 678176b32770f946d5be6cd8fb8e531767f4705f Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:21:23 +0200
Subject: [PATCH 07/17] * elpa-packages (yasnippet-snippets): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 17d074e580..ff78f16d78 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -82,4 +82,7 @@
("wgrep" :url "https://github.com/mhayashi1120/Emacs-wgrep")
+ ("yasnippet-snippets" :url "https://github.com/AndreaCrotti/yasnippet-snippets"
+ :ignored-files ("report" "snippets.html"))
+
)
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #9: 0008-elpa-packages-rust-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 873 bytes --]
From 90da51346502ba08abb0ea5db5c6e222d35f2f62 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:22:44 +0200
Subject: [PATCH 08/17] * elpa-packages (rust-mode): Add package
---
elpa-packages | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index ff78f16d78..42407f8632 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -59,6 +59,14 @@
("request" :url "https://github.com/tkf/emacs-request"
:ignored-files ("tests" "doc" "COPYING"))
+ ("rust-mode" :url "https://github.com/rust-lang/rust-mode"
+ :ignored-files ("test-project"
+ "run_rust_emacs_tests.sh"
+ "run_rust_emacs_tests_docker.sh"
+ "test-by-cp"
+ "test-from-git"
+ "triagebot.toml"))
+
("org-contrib" :url "https://git.sr.ht/~bzg/org-contrib"
:lisp-dir "lisp"
:readme "README.org"
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #10: 0009-elpa-packages-go-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 796 bytes --]
From f38950de1db84d620d753e695dcde45f2b885f43 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:27:35 +0200
Subject: [PATCH 09/17] * elpa-packages (go-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 42407f8632..7a0bc31fd2 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -42,6 +42,9 @@
("geiser-racket" :url "https://gitlab.com/emacs-geiser/racket.git")
("geiser-stklos" :url "https://gitlab.com/emacs-geiser/stklos.git")
+ ("go-mode" :url "https://github.com/dominikh/go-mode.el"
+ :ignored-files ("generate_authors.sh"))
+
("goto-chg" :url "https://github.com/emacs-evil/goto-chg")
("lua-mode" :url "https://github.com/immerrr/lua-mode/"
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #11: 0010-elpa-packages-paredit-Add-package.patch --]
[-- Type: text/x-diff, Size: 691 bytes --]
From 317975b280a25dae246e1424b5a67213b507b515 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:36:29 +0200
Subject: [PATCH 10/17] * elpa-packages (paredit): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 7a0bc31fd2..655690002b 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -59,6 +59,9 @@
;; :dont-release "-dev\\'"
)
+ ("paredit" :url "https://mumble.net/~campbell/git/paredit.git"
+ :ignored-files ("check.sh" "genhtml.sh" "test.el"))
+
("request" :url "https://github.com/tkf/emacs-request"
:ignored-files ("tests" "doc" "COPYING"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #12: 0011-elpa-packages-htmlize-Add-package.patch --]
[-- Type: text/x-diff, Size: 710 bytes --]
From 2e1506e61edac37d5bb9796194a88dbf8fa585a1 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:36:53 +0200
Subject: [PATCH 11/17] * elpa-packages (htmlize): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 655690002b..c7021984ae 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -47,6 +47,9 @@
("goto-chg" :url "https://github.com/emacs-evil/goto-chg")
+ ("htmlize" :url "https://github.com/hniksic/emacs-htmlize"
+ :ignored-files ("htmlize.el.html"))
+
("lua-mode" :url "https://github.com/immerrr/lua-mode/"
:ignored-files ("test" "travis" "init-tryout.el"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #13: 0012-elpa-packages-haskell-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 893 bytes --]
From dbbb79a31def3d2da5c8956130a8ece7e8396d15 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:41:02 +0200
Subject: [PATCH 12/17] * elpa-packages (haskell-mode): Add package
---
elpa-packages | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index c7021984ae..ba537c3ccd 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -47,6 +47,12 @@
("goto-chg" :url "https://github.com/emacs-evil/goto-chg")
+ ("haskell-mode" :url "https://github.com/haskell/haskell-mode"
+ :doc "doc/haskell-mode.texi"
+ :ignored-files ("images" "test" "logo.svg")
+ ;; See https://github.com/haskell/haskell-mode/releases/tag/17.2
+ :version-map ((nil "17.2" "e72677668f5fc7cc148008e885a0f256e245dd43")))
+
("htmlize" :url "https://github.com/hniksic/emacs-htmlize"
:ignored-files ("htmlize.el.html"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #14: 0013-elpa-packages-multiple-cursors-Add-package.patch --]
[-- Type: text/x-diff, Size: 705 bytes --]
From c92969f11b31f2af4f12970f03d01ca4db8c4348 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:54:45 +0200
Subject: [PATCH 13/17] * elpa-packages (multiple-cursors): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index ba537c3ccd..7a04133a4f 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -68,6 +68,9 @@
;; :dont-release "-dev\\'"
)
+ ("multiple-cursors" :url "https://github.com/magnars/multiple-cursors.el"
+ :ignored-files ("features"))
+
("paredit" :url "https://mumble.net/~campbell/git/paredit.git"
:ignored-files ("check.sh" "genhtml.sh" "test.el"))
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #15: 0014-elpa-packages-macrostep-Add-package.patch --]
[-- Type: text/x-diff, Size: 732 bytes --]
From a79dfdd419e2a9217b6dc8673d8ce541e99cc546 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:55:04 +0200
Subject: [PATCH 14/17] * elpa-packages (macrostep): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 7a04133a4f..da5c78abb6 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -62,6 +62,9 @@
;; ("magit" :url "https://github.com/magit/magit"
;; :lisp-dir "lisp")
+ ("macrostep" :url "https://github.com/joddie/macrostep"
+ :ignored-files ("lib" "macrostep-test.el"))
+
("markdown-mode" :url "https://github.com/jrblevin/markdown-mode"
:readme "README.md"
;; Not needed any more:
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #16: 0015-elpa-packages-erlang-Add-package.patch --]
[-- Type: text/x-diff, Size: 763 bytes --]
From c5fe34db33baa0f532eb3c0caa71914722f52275 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:56:55 +0200
Subject: [PATCH 15/17] * elpa-packages (erlang): Add package
---
elpa-packages | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index da5c78abb6..3003b8ff90 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -19,6 +19,10 @@
:news "CHANGELOG.md"
:ignored-files ("bin" "ert-tests"))
+ ("erlang" :url "https://github.com/erlang/otp"
+ :lisp-dir "lib/tools/emacs"
+ :ignored-files ("internal_doc" "tags.3" "vsn.mk"))
+
("evil" :url "https://github.com/emacs-evil/evil"
:ignored-files ("lib" "scripts" "doc")
:doc "doc/build/texinfo/evil.texi")
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #17: 0016-elpa-packages-slime-Add-package.patch --]
[-- Type: text/x-diff, Size: 667 bytes --]
From 527fc422fa907c863fe6e8522ddaab4b87a3f5d7 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:57:11 +0200
Subject: [PATCH 16/17] * elpa-packages (slime): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 3003b8ff90..6f6030ad9f 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -97,6 +97,9 @@
:readme "README.org"
:ignored-files ("README.md"))
+ ("slime" :url "https://github.com/slime/slime"
+ :doc "doc/slime.texi")
+
("sly" :url "https://github.com/joaotavora/sly"
:texinfo "doc/sly.texi"
;; Not needed any more:
--
2.30.2
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #18: 0017-elpa-packages-web-mode-Add-package.patch --]
[-- Type: text/x-diff, Size: 670 bytes --]
From 2c98a8c00d84fd03670aeaa0f736cc290374a07e Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Wed, 4 Aug 2021 18:57:16 +0200
Subject: [PATCH 17/17] * elpa-packages (web-mode): Add package
---
elpa-packages | 3 +++
1 file changed, 3 insertions(+)
diff --git a/elpa-packages b/elpa-packages
index 6f6030ad9f..0c2c85d994 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -113,6 +113,9 @@
("tuareg" :url "https://github.com/ocaml/tuareg.git")
+ ("web-mode" :url "https://github.com/fxbois/web-mode"
+ :ignored-files ("issues" "tests" "run.sh"))
+
;; ("with-editor" :url "https://github.com/magit/with-editor"
;; )
--
2.30.2
[-- Attachment #19: Type: text/plain, Size: 74 bytes --]
If you want to, I can push the commits directly.
--
Philip Kaludercic
^ permalink raw reply related [relevance 26%]
* Re: NonGNU ELPA work
2021-08-04 18:41 26% ` Philip Kaludercic
@ 2021-08-04 18:44 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-04 18:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Adam Tack, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I have been trying to prepare the patches for the last few days, but
>>> there seem to be issues with the build system (or hopefully I'm doing
>>> something wrong):
>>>
>>> $ make build-all
>>> emacs --batch -Q -l admin/elpa-admin.el \
>>> -f elpaa-batch-pkg-spec-make-dependencies .pkg-descs.mk
>>> emacs --batch -l /home/philip/Code/src/nongnu/admin/elpa-admin.el \
>>> -f elpaa-batch-make-all-packages
>>> Updating worktree in "/home/philip/Code/src/nongnu/packages/geiser/"
>>> Updated geiser: merge: refs/remotes/origin/elpa/geiser - not something we can merge
>>>
>>> Updating worktree in "/home/philip/Code/src/nongnu/packages/smartparens/"
>>> Updated smartparens: fatal: No remote for the current branch.
>>>
>>> Updating worktree in "/home/philip/Code/src/nongnu/packages/lua-mode/"
>>> Updated lua-mode: fatal: No remote for the current branch.
>>>
>>> Updating worktree in "/home/philip/Code/src/nongnu/packages/wgrep/"
>>> Updated wgrep: fatal: No remote for the current branch.
>>
>> This seems to point to a problem in the "setup" of your directory.
>> Maybe `origin` isn't pointing to the nongnu,git repository?
>
> It seems to be pointing to the right destination:
>
> icterid$ git remote -v
> gnu-elpa https://git.sv.gnu.org/r/emacs/elpa.git (fetch)
> gnu-elpa https://git.sv.gnu.org/r/emacs/elpa.git (push)
> origin zge@git.savannah.gnu.org:/srv/git/emacs/nongnu.git (fetch)
> origin zge@git.savannah.gnu.org:/srv/git/emacs/nongnu.git (push)
Some further testing indicated that the issue only arose when no
origin/elpa/... branch could be found on the remote target. As I had
unintentionally pushed a few branches a few days ago, I could test and
see that these were being build as intended.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Make ELPA and nongnu elpa more accessible
@ 2021-08-04 21:14 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-04 21:14 UTC (permalink / raw)
To: Fu Yuan; +Cc: emacs-devel
Fu Yuan <casouri@gmail.com> writes:
> I think both ELPA could use some improvement on accessibility, eg,
> change the raw readme file to a html, mention nongnu on ELPA and vice
> versa, add a link to readme on nongnu ELPA, etc. I plan to clone it
> and add/edit some html files. Is there anything I need to know before
> I start?
Should HTML files really be added to the repository itself? If there is
no way to view the rendered results in a git browser, it seems no better
than using a plain-text readable markup format like Org and converting
that to HTML.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: NonGNU ELPA work
@ 2021-08-05 9:16 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-05 9:16 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Adam Tack, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Some further testing indicated that the issue only arose when no
>> origin/elpa/... branch could be found on the remote target. As I had
>> unintentionally pushed a few branches a few days ago, I could test and
>> see that these were being build as intended.
>
> Hmm... I just tried here to add
>
> ("lua-mode" :url "https://github.com/immerrr/lua-mode/"
> :ignored-files ("test" "travis" "init-tryout.el"))
>
> to `elpa-packages` in my clone of nongnu, and then I did
>
> make fetch/lua-mode
> make build/lua-mode
>
> and it "worked for me". I tried re-running `make build/lua-mode`
> a second time (after deleting the tarballs) and again it worked:
>
> % make build/lua-mode
> emacs --batch -l /home/monnier/src/emacs/nongnu/admin/elpa-admin.el \
> -f elpaa-batch-make-one-package lua-mode
> Updating worktree in "/home/monnier/src/emacs/nongnu/packages/lua-mode/"
> Updated lua-mode: fatal: No remote for the current branch.
>
> Warning: lm-maintainer is obsolete!
> Built new package archive-devel/lua-mode-20210802.0.20210802.174715.tar!
> Built new package archive/lua-mode-20210802.tar!
> %
I just tried it out, and it seems that this issue seems to resolve
itself, after making sync/lua-mode.
> Indeed I also see the "No remote for the current branch" error
> message, but it doesn't prevent the production of the tarballs.
So the package specifications should all be ok?
> Stefan
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [ANN] EmacsConf 2021 Call for Proposals
@ 2021-08-07 22:39 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-07 22:39 UTC (permalink / raw)
To: quiliro
Cc: emacs-tangents, Amin Bandali, emacs-devel, emacsconf-org,
emacs-orgmode, emacsconf-discuss
quiliro@riseup.net writes:
> What a great call for papers. If it was created using Emacs, it would
> be great to have a talk or a howto for how it was made.
It seems to me like it is just an org-mode document, converted to
plain text using one of the built-in exporters.
> Congratulations
> for the organizers for making this a free software event and not just an
> event with free software.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* [ELPA] New package: vc-backup
@ 2021-08-07 23:32 99% Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-07 23:32 UTC (permalink / raw)
To: emacs-devel
Hi,
I mentioned this package a few months ago, but only recently got around
to smoothing out a few of the rough edges:
https://git.sr.ht/~pkal/vc-backup
The gist of it is that it provides a vc backend not based on some
external SCM-system, but just using Emacs built-in backups. As I have
mentioned, I have been testing the package for a few months now, and it
seems to have been working well.
--
Philip K.
^ permalink raw reply [relevance 99%]
* Re: [nongnu] main 23c23ad: * elpa-packages (smartparens): Add package
@ 2021-08-08 8:00 99% ` Philip Kaludercic
2021-08-19 9:23 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-08 8:00 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Philip Kaludercic [2021-08-07 19:11:09] wrote:
>> + ("smartparens" :url "https://github.com/Fuco1/smartparens"
>> + :ignored-files ("dev" "doc" "images" "test")
>> + ;; See https://github.com/Fuco1/smartparens/releases/tag/1.11.0
>> + :version-map ((nil "1.11.0" "4873352b5d0a1c5142658122de1b6950b8fe7e4d")))
>
> Thanks Philip,
>
> Even better than this URL would be a link to an issue/bugreport
> requesting the version number be added in the file.
I'll update both the smartparens and the haskell-mode package
specification to add those links.
>
> Stefan
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: ELPA: add flymake-proselint
@ 2021-08-08 14:07 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-08 14:07 UTC (permalink / raw)
To: Manuel Uberti; +Cc: emacs-devel
Manuel Uberti <manuel.uberti@inventati.org> writes:
> Hi,
>
> I would like to submit the attached package to ELPA.
You should probably add a link to a repository where you work on the
package, so that it can be added to ELPA more easily.
> This package adds a Flymake backend for proselint[1]. For instance, it
> can be used like this:
>
> (add-hook 'markdown-mode-hook #'flymake-proselint-setup)
>
>
> Thank you
>
> [1] http://proselint.com/
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Easy configuration of a site-lisp directory
@ 2021-08-08 15:40 89% Philip Kaludercic
2021-08-19 9:25 99% ` Philip Kaludercic
0 siblings, 2 replies; 200+ results
From: Philip Kaludercic @ 2021-08-08 15:40 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 119 bytes --]
Hi,
I have been using something along these lines for a while now, and
wanted to suggest adding this to Emacs/ELPA:
[-- Attachment #2: site-lisp.el --]
[-- Type: application/emacs-lisp, Size: 2891 bytes --]
[-- Attachment #3: Type: text/plain, Size: 656 bytes --]
The fundamental idea is to have an easy-to-use ~/.emacs.d/site-lisp/
directory where a user can clone any repository or create their own,
without having to manually add these to load-path, generate autoloads or
byte compile.
All my personal packages are managed this way without any issues that I
have noticed. My hope is that something like this would ease working on
and contributing to packages.
The above attachment is a stand-alone file, while my version is just a
blob at the beginning of my init.el. If there is any interest, it might
also be possible to add it to an existing file, but I was not sure where
it would fit in best.
--
Philip K.
^ permalink raw reply [relevance 89%]
* Re: Easy configuration of a site-lisp directory
@ 2021-08-08 18:53 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-08 18:53 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Philip Kaludercic [2021-08-08 15:40:57] wrote:
>> I have been using something along these lines for a while now, and
>> wanted to suggest adding this to Emacs/ELPA:
> [...]
>> The fundamental idea is to have an easy-to-use ~/.emacs.d/site-lisp/
>> directory where a user can clone any repository or create their own,
>> without having to manually add these to load-path, generate autoloads or
>> byte compile.
>
> FWIW, I use `elpa-admin.el` for that.
> The advantage being that the package.el is made aware of them.
What is the advantage in making package.el aware?
> Admittedly, `elpa-admin.el` doesn't provide that "out of the box", but
> I'd welcome changes to improve this use case. It go become an
> alternative to `straight.el`.
On the topic of package.el, a more general idea I had was to make
package.el more generic, with different backends. Then you could have
one backend for elpa packages, one for local "packages", etc. But that
would certainly take more effort to design and implement that what I
have suggested here.
>
> Stefan
>
>
>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Obtaining the version of an installed package
@ 2021-08-09 15:35 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-09 15:35 UTC (permalink / raw)
To: Bozhidar Batsov; +Cc: Emacs Devel
"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> I guess that could work, although from what I gathered it operates
> only on the current package. I was hoping to find something like an
> API like `(package-get-version 'package-name)`.
Extracting the code from package-get-version, I would get something
like
(require 'find-func)
(require 'lisp-mnt)
(defun get-library-version (library)
"Return a version string for LIBRARY."
(with-temp-buffer
(insert-file-contents (find-library-name library))
(or (lm-header "package-version")
(lm-header "version"))))
and it seems to work
(get-library-version "auctex") ;=> "13.0.12"
> On Mon, Aug 9, 2021, at 3:58 PM, Stefan Monnier wrote:
>> > I'm wondering if there's an API for obtaining metadata about installed
>> > packages, in particular the version information.
>> > For years I was using this function from pkg-info
>> > https://github.com/emacsorphanage/pkg-info/blob/master/pkg-info.el#L65, but
>> > I'm wondering if it'd be easy to strip one dependency from my packages.
>>
>> Are you looking for `package-get-version`?
>>
>>
>> Stefan
>>
>>
>>
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: [nongnu] main 23c23ad: * elpa-packages (smartparens): Add package
2021-08-08 8:00 99% ` Philip Kaludercic
@ 2021-08-19 9:23 99% ` Philip Kaludercic
0 siblings, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-19 9:23 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Philip Kaludercic [2021-08-07 19:11:09] wrote:
>>> + ("smartparens" :url "https://github.com/Fuco1/smartparens"
>>> + :ignored-files ("dev" "doc" "images" "test")
>>> + ;; See https://github.com/Fuco1/smartparens/releases/tag/1.11.0
>>> + :version-map ((nil "1.11.0" "4873352b5d0a1c5142658122de1b6950b8fe7e4d")))
>>
>> Thanks Philip,
>>
>> Even better than this URL would be a link to an issue/bugreport
>> requesting the version number be added in the file.
>
> I'll update both the smartparens and the haskell-mode package
> specification to add those links.
It has been requested to remove haskell-mode for now, because the
maintainers are not sure how their release procedure interacts with
ELPA:
https://github.com/haskell/haskell-mode/issues/1755#issuecomment-896127958
Would there be any issue in just commenting the specification out?
>>
>> Stefan
>>
As a side-note, would be make sense to extend elpa-admin to handle git
tags if requested?
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Easy configuration of a site-lisp directory
2021-08-08 15:40 89% Easy configuration of a site-lisp directory Philip Kaludercic
@ 2021-08-19 9:25 99% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-19 9:25 UTC (permalink / raw)
To: emacs-devel
Just wanted to ping this message to check if there is any interest in
doing something with my initial suggestion?
Philip Kaludercic <philipk@posteo.net> writes:
> Hi,
>
> I have been using something along these lines for a while now, and
> wanted to suggest adding this to Emacs/ELPA:
>
>
>
> The fundamental idea is to have an easy-to-use ~/.emacs.d/site-lisp/
> directory where a user can clone any repository or create their own,
> without having to manually add these to load-path, generate autoloads or
> byte compile.
>
> All my personal packages are managed this way without any issues that I
> have noticed. My hope is that something like this would ease working on
> and contributing to packages.
>
> The above attachment is a stand-alone file, while my version is just a
> blob at the beginning of my init.el. If there is any interest, it might
> also be possible to add it to an existing file, but I was not sure where
> it would fit in best.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
* Re: Collaborative editing.
@ 2021-08-19 9:32 97% ` Philip Kaludercic
2021-08-19 9:33 97% ` Philip Kaludercic
1 sibling, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-19 9:32 UTC (permalink / raw)
To: Ergus; +Cc: qhong, Perry E. Metzger, Jean Louis, emacs-devel
Ergus <spacibba@aol.com> writes:
> Could we try to add crdt to Elpa? Is the author somehow opposed to do the paperwork or so?
The package still seems to be on version 0.0.0, and the HACKING[0] file
indicates that a few intended items are not implemented yet. It might
make sense to push for a preliminary version to be published as to
provide a basic collaborative environment available on ELPA (or NonGNU
ELPA if necessary), and then later work on full-compatibility.
[0] https://code.librehq.com/qhong/crdt.el/-/raw/master/HACKING.org
> On August 15, 2021 7:46:43 AM GMT+02:00, Jean Louis <bugs@gnu.support> wrote:
>>* Perry E. Metzger <perry@piermont.com> [2021-08-13 02:44]:
>>> I know there have been some experiments with collaborative editing modes in
>>> the past that were written purely in Elisp but none seem to be currently
>>> maintained and I'm not sure if any were actually very good to begin with.
>>
>>CRDT works just fine and is well maintained, you can contact author
>>Qiantan Hong <qhong@mit.edu> at any time you wish.
>>
>>Do:
>>
>>$ git clone https://code.librehq.com/qhong/crdt.el.git
>>
>>Let me know if you need any help or assistance to start with
>>collaborative editing.
>>
>>
>>--
>>Jean
>>
>>Take action in Free Software Foundation campaigns:
>>https://www.fsf.org/campaigns
>>
>>In support of Richard M. Stallman
>>https://stallmansupport.org/
>>
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
* Re: Collaborative editing.
2021-08-19 9:32 97% ` Philip Kaludercic
@ 2021-08-19 9:33 97% ` Philip Kaludercic
1 sibling, 1 reply; 200+ results
From: Philip Kaludercic @ 2021-08-19 9:33 UTC (permalink / raw)
To: Ergus; +Cc: qhong, Perry E. Metzger, Jean Louis, emacs-devel
Ergus <spacibba@aol.com> writes:
> Could we try to add crdt to Elpa? Is the author somehow opposed to do the paperwork or so?
The package still seems to be on version 0.0.0, and the HACKING[0] file
indicates that a few intended items are not implemented yet. It might
make sense to push for a preliminary version to be published as to
provide a basic collaborative environment available on ELPA (or NonGNU
ELPA if necessary), and then later work on full-compatibility.
[0] https://code.librehq.com/qhong/crdt.el/-/raw/master/HACKING.org
> On August 15, 2021 7:46:43 AM GMT+02:00, Jean Louis <bugs@gnu.support> wrote:
>>* Perry E. Metzger <perry@piermont.com> [2021-08-13 02:44]:
>>> I know there have been some experiments with collaborative editing modes in
>>> the past that were written purely in Elisp but none seem to be currently
>>> maintained and I'm not sure if any were actually very good to begin with.
>>
>>CRDT works just fine and is well maintained, you can contact author
>>Qiantan Hong <qhong@mit.edu> at any time you wish.
>>
>>Do:
>>
>>$ git clone https://code.librehq.com/qhong/crdt.el.git
>>
>>Let me know if you need any help or assistance to start with
>>collaborative editing.
>>
>>
>>--
>>Jean
>>
>>Take action in Free Software Foundation campaigns:
>>https://www.fsf.org/campaigns
>>
>>In support of Richard M. Stallman
>>https://stallmansupport.org/
>>
--
Philip Kaludercic
^ permalink raw reply [relevance 97%]
* Re: [nongnu] main 23c23ad: * elpa-packages (smartparens): Add package
@ 2021-08-19 15:31 92% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-19 15:31 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Would there be any issue in just commenting the specification out?
>
> Not that I can think of.
Ok, I'll update that then until the upstream repo changes their mind.
>> As a side-note, would be make sense to extend elpa-admin to handle git
>> tags if requested?
>
> No, because tags from one package would collide with tags from
> other packages.
I see. There might be the possibility of checking the remote repository
for new tags, without having to clone these into the repository
itself. According to [0] the command
git ls-remote --tags </url/to/upstream/repo>
could generate such a listing. And in fact,
$ git ls-remote --tags https://github.com/haskell/haskell-mode
e72677668f5fc7cc148008e885a0f256e245dd43 refs/tags/17.2
8c49232e5e507cd978aaa5a33cbf8dda7b43518f refs/tags/2_5_1
72d395fc5fe49834116c0aaeb25d1731fa47d72c refs/tags/2_5_1^{}
22a963b80c32cd9c16f804341cdbe41c801470e8 refs/tags/2_6
4a16cc3367aa067a71d8dd74bab1d6de45b09bfa refs/tags/2_6^{}
753421777852b0dde5c8f899ccbd6920c10f2f43 refs/tags/2_6_1
...
gives me a list of commits and tags, that could be sorted to find the
newest version.
[0] https://stackoverflow.com/a/25987962
>
> Stefan
>
--
Philip Kaludercic
^ permalink raw reply [relevance 92%]
* Re: Collaborative editing.
@ 2021-08-19 15:36 93% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-19 15:36 UTC (permalink / raw)
To: Ergus; +Cc: qhong, Perry E. Metzger, Jean Louis, emacs-devel
Ergus <spacibba@aol.com> writes:
> On Thu, Aug 19, 2021 at 09:33:28AM +0000, Philip Kaludercic wrote:
>>Ergus <spacibba@aol.com> writes:
>>
>>> Could we try to add crdt to Elpa? Is the author somehow opposed to do the paperwork or so?
>>
>>The package still seems to be on version 0.0.0, and the HACKING[0] file
>>indicates that a few intended items are not implemented yet. It might
>
>>make sense to push for a preliminary version to be published as to
>>provide a basic collaborative environment available on ELPA (or NonGNU
>>ELPA if necessary), and then later work on full-compatibility.
>
> This is the point. When some users know about the package searching in
> the packages-list; maybe they will want to collaborate or report issues,
> so it won't becomes a single man effort. IMHO a package doesn't really
> exist until it is in Elpa or at least Melpa.
I agree, though in this case there is also the issue of having a package
that is hard to debug and test on your own, because the real bugs will
probably only pop up in hard to replicate configurations
(transcontinental-collaboration, obscure network configurations, etc.)
> Otherwise in a couple of years there will be someone starting again
> another similar effort from scratch.
I'd be intersted to see what Qiantan has to say about all of this. It
seems like he changed his email address according to the last commit in
the repository, so I update the CC'ed address in this thread too in case
he is missing out on the conversation.
>>
>>[0] https://code.librehq.com/qhong/crdt.el/-/raw/master/HACKING.org
>>
>>> On August 15, 2021 7:46:43 AM GMT+02:00, Jean Louis <bugs@gnu.support> wrote:
>>>>* Perry E. Metzger <perry@piermont.com> [2021-08-13 02:44]:
>>>>> I know there have been some experiments with collaborative editing modes in
>>>>> the past that were written purely in Elisp but none seem to be currently
>>>>> maintained and I'm not sure if any were actually very good to begin with.
>>>>
>>>>CRDT works just fine and is well maintained, you can contact author
>>>>Qiantan Hong <qhong@mit.edu> at any time you wish.
>>>>
>>>>Do:
>>>>
>>>>$ git clone https://code.librehq.com/qhong/crdt.el.git
>>>>
>>>>Let me know if you need any help or assistance to start with
>>>>collaborative editing.
>>>>
>>>>
>>>>--
>>>>Jean
>>>>
>>>>Take action in Free Software Foundation campaigns:
>>>>https://www.fsf.org/campaigns
>>>>
>>>>In support of Richard M. Stallman
>>>>https://stallmansupport.org/
>>>>
>>
>> -- Philip Kaludercic
>
--
Philip Kaludercic
^ permalink raw reply [relevance 93%]
* Re: Easy configuration of a site-lisp directory
@ 2021-08-19 21:59 94% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-19 21:59 UTC (permalink / raw)
To: Arthur Miller; +Cc: emacs-devel
Arthur Miller <arthur.miller@live.com> writes:
> Arthur Miller <arthur.miller@live.com> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>
>>>> Just wanted to ping this message to check if there is any interest in
>>>> doing something with my initial suggestion?
>>>
>>> I do something similar as you do, but I use it only for some loose
>>> files I write myself, and for some I download from emacs wiki etc.
>>>
>>>>> The fundamental idea is to have an easy-to-use ~/.emacs.d/site-lisp/
>>>>> directory where a user can clone any repository or create their own,
>>>>> without having to manually add these to load-path, generate autoloads or
>>>>> byte compile.
>>>
>>> I have a question: is it desirable to use a working git directory as
>>> installed package? When I write my own files, I usually don't wish to
>>> copy them over to my "lisp" directory which I autoload in Emacs, untill
>>> I am done. Admittedly I started doing so before git has entered the
>>> scene. Now I guess one can switch branches every time one works on a package
>>> between some development branch and some stable, but isn't it a bit tedious?
I do think this is useful, because it prevents confusion with xref. When
I am working on my own packages/packages I am contributing to, I want
M-. to jump to the actual definition I can work on, not a copy that
might get lost.
>> I just looked at package.el and realized that it is already possible to
>> install directories, I wasn't aware of that fact. So the only extra work
>> is to make it recognize local paths in a list package-archives list, in
>> principle.
I assume you mean package-install-file?
> And I also realized that package-archives can already deal with local
> directories. So everything is there.
>
> Users can already install from local repos.
The issue is that this is just a repository, that might be helpful in
some situations, but at the very least adds a redundant step (fetch the
code, install the code) and always makes it harder to work on local
repositories, because package-sources are unversioned.
--
Philip Kaludercic
^ permalink raw reply [relevance 94%]
* Re: [ELPA] New package: vc-backup
@ 2021-08-19 22:04 99% ` Philip Kaludercic
0 siblings, 0 replies; 200+ results
From: Philip Kaludercic @ 2021-08-19 22:04 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> I mentioned this package a few months ago, but only recently got around
> to smoothing out a few of the rough edges:
>
> https://git.sr.ht/~pkal/vc-backup
>
> Thank you, you just made my list of things to do one line shorter.
> This is something I've wanted for several years, but never got around
> to doing.
After some private correspondence, I have installed a few improvements
suggested by Alfred that have now been pushed to the repository.
In case nobody objects, I would be ready to add the package to ELPA
myself.
--
Philip Kaludercic
^ permalink raw reply [relevance 99%]
Results 1-200 of ~1750 next (newer) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2020-08-10 17:10 75% Xref Fallback Philip K.
2020-08-10 19:01 Dmitry Gutov
2020-08-11 18:19 99% ` Philip K.
2020-09-05 18:19 master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions Stefan Monnier
2020-09-05 19:06 99% ` Philip K.
2020-09-05 19:39 Stefan Monnier
2020-09-06 21:42 99% ` Philip K.
2020-09-08 16:02 Changes for emacs 28 TEC
2020-09-08 17:01 ` Yuan Fu
2020-09-08 18:15 ` TEC
2020-09-09 16:05 ` Stefan Monnier
2020-09-09 16:45 ` TEC
2020-09-09 18:35 ` Stefan Monnier
2020-09-10 10:47 ` Göktuğ Kayaalp
2020-09-10 17:39 ` Drew Adams
2020-09-10 17:56 ` Yuri Khan
2020-09-10 18:21 ` Eli Zaretskii
2020-09-10 21:01 ` Göktuğ Kayaalp
2020-09-10 21:21 ` Gregory Heytings via Emacs development discussions.
2020-09-11 4:16 ` Richard Stallman
2020-09-11 7:04 91% ` Philip K.
2020-09-09 16:57 ` Ergus
2020-09-10 9:09 ` "modern" colors " Alfred M. Szmidt
2020-09-10 10:20 ` Ergus
2020-09-10 10:29 ` Alfred M. Szmidt
2020-09-10 11:08 ` Ergus
2020-09-11 13:15 ` Alfred M. Szmidt
2020-09-11 13:42 ` Ergus
2020-09-11 23:29 67% ` Philip K.
2020-09-08 18:48 Gather a list of confusions beginner tend to have Göktuğ Kayaalp
2020-09-08 19:30 ` Yuan Fu
2020-09-09 14:01 ` Eli Zaretskii
2020-09-10 23:20 ` Yuan Fu
2020-09-11 0:20 ` Interactive guide for new users (was: Re: Gather a list of confusions beginner tend to have) Stefan Kangas
2020-09-19 15:20 ` Eduardo Mercovich
2020-09-19 17:02 ` Drew Adams
2020-09-21 14:50 ` Eduardo Mercovich
2020-09-21 16:07 ` Drew Adams
2020-09-22 3:40 ` Richard Stallman
2020-09-22 9:06 99% ` Interactive guide for new users Philip K.
2020-09-19 17:16 97% ` Philip K.
[not found] <20200906133719.cu6yaldvenxubcqq.ref@Ergus>
2020-09-06 13:37 ` Changes for emacs 28 Ergus
2020-09-06 14:44 ` Eli Zaretskii
2020-09-06 16:34 ` Ergus
2020-09-06 19:32 ` Alfred M. Szmidt
2020-09-06 20:38 ` Ergus
2020-09-06 21:51 ` Alfred M. Szmidt
2020-09-06 22:01 ` Lars Ingebrigtsen
2020-09-09 11:22 ` Gregory Heytings via Emacs development discussions.
2020-09-09 15:04 ` Göktuğ Kayaalp
2020-09-09 17:01 91% ` Philip K.
2020-09-09 17:14 85% ` Philip K.
2020-09-11 7:50 ` Tassilo Horn
2020-09-11 15:44 97% ` Philip K.
2020-09-10 9:40 Eli Zaretskii
2020-09-10 15:08 99% ` Philip K.
2020-09-11 8:15 Interactive guide for new users (was: Re: Gather a list of confusions beginner tend to have) Gregory Heytings via Emacs development discussions.
2020-09-11 14:04 ` Yuan Fu
2020-09-11 14:38 ` Gregory Heytings via Emacs development discussions.
2020-09-11 14:49 ` Eli Zaretskii
2020-09-11 15:20 ` Gregory Heytings via Emacs development discussions.
2020-09-11 15:28 ` Eli Zaretskii
2020-09-11 15:46 ` Gregory Heytings via Emacs development discussions.
2020-09-11 15:51 ` Eli Zaretskii
2020-09-11 16:00 ` Gregory Heytings via Emacs development discussions.
2020-09-11 18:43 ` Eli Zaretskii
2020-09-11 19:48 ` Ergus
2020-09-12 6:02 ` Eli Zaretskii
2020-09-12 9:33 ` Ergus
2020-09-13 12:13 99% ` Interactive guide for new users Philip K.
2020-09-11 10:36 Changes for emacs 28 Ergus
2020-09-11 10:55 99% ` Philip K.
2020-09-11 11:13 Ergus
2020-09-11 12:12 99% ` Philip K.
2020-09-17 8:50 A proposal for a friendlier Emacs Nicola Manca
2020-09-17 9:04 ` Alfred M. Szmidt
2020-09-17 9:27 ` Nicola Manca
2020-09-17 12:24 ` Alfred M. Szmidt
2020-09-17 12:35 ` Thibaut Verron
2020-09-17 13:22 ` Alfred M. Szmidt
2020-09-17 13:26 ` Thibaut Verron
2020-09-17 13:31 ` Alfred M. Szmidt
2020-09-17 13:34 ` Thibaut Verron
2020-09-17 14:27 ` Alfred M. Szmidt
2020-09-18 16:49 ` Stefan Kangas
2020-09-18 18:25 ` Alfred M. Szmidt
2020-09-18 18:59 ` Thibaut Verron
2020-09-19 15:50 97% ` Philip K.
2020-09-17 20:10 Context menus and mouse-3 [was: Changes for emacs 28] Ergus
2020-09-17 21:58 84% ` Philip K.
2020-09-19 17:53 Interactive guide for new users Eduardo Mercovich
2020-09-20 9:26 91% ` Philip K.
2020-09-20 8:35 [ELPA] New package: splash-screen Nicolas P. Rougier
2020-09-20 13:16 ` Stefan Monnier
2020-09-20 14:50 ` Nicolas P. Rougier
2020-09-20 17:50 ` Stefan Monnier
2020-09-20 20:33 ` Nicolas P. Rougier
2020-09-21 5:47 ` Alfred M. Szmidt
2020-09-21 6:06 ` Nicolas P. Rougier
2020-09-21 11:09 98% ` Philip K.
2020-09-21 11:42 Nicolas P. Rougier
2020-09-21 15:24 99% ` Philip K.
2020-09-21 16:40 95% ` Philip K.
2020-09-23 3:40 Interactive guide for new users Richard Stallman
2020-09-23 12:49 94% ` Philip K.
2020-09-25 12:56 78% [ELPA] New package: shell-command+ Philip K.
2020-09-25 13:43 Stefan Monnier
2020-09-25 13:52 51% ` Philip K.
2020-09-25 23:38 Ergus
2020-09-26 9:38 94% ` Philip K.
2020-09-26 13:38 How to make Emacs popular again James Lu
2020-09-26 13:59 95% ` Philip K.
2020-10-01 4:14 Richard Stallman
2020-10-01 8:11 99% ` Philip K.
2020-10-02 18:14 Emacs default key bindings [was: Opening Up More Keymaps Re: Standardizing more key bindings?] Drew Adams
2020-10-02 19:21 91% ` Philip K.
2020-10-02 19:24 ` Ergus
2020-10-02 22:31 94% ` Philip K.
2020-10-08 15:30 Proposal for an Emacs User Survey Adrien Brochard
2020-10-08 17:27 81% ` Philip K.
2020-10-09 3:35 ` Richard Stallman
2020-10-09 23:12 ` Adrien Brochard
2020-10-10 8:09 ` Teemu Likonen
2020-10-11 10:32 ` Jean Louis
2020-10-11 18:33 94% ` Philip K.
2020-10-10 10:54 ` Thibaut Verron
2020-10-10 13:50 99% ` Philip K.
2020-10-11 5:23 ` Richard Stallman
2020-10-11 7:35 ` Vasilij Schneidermann
2020-10-11 12:08 ` Jean Louis
2020-10-11 12:50 ` Vasilij Schneidermann
2020-10-12 2:04 ` Richard Stallman
2020-10-12 3:32 ` Thibaut Verron
2020-10-12 5:04 ` Jean Louis
2020-10-12 5:33 ` Thibaut Verron
2020-10-13 3:53 ` Richard Stallman
2020-10-13 5:27 ` Jean Louis
2020-10-16 3:59 ` Richard Stallman
2020-10-16 6:02 ` Marcel Ventosa
2020-10-18 4:10 ` Richard Stallman
2020-10-18 15:57 93% ` Philip K.
2020-10-16 7:05 ` Thibaut Verron
2020-10-16 13:23 81% ` Philip K.
2020-10-16 13:30 98% ` Philip K.
2020-10-19 16:20 99% ` Philip K.
2020-10-08 16:01 Integration of dictionary package Torsten Hilbrich
2020-10-08 17:33 94% ` Philip K.
2020-10-08 17:45 Proposal for an Emacs User Survey Adrien Brochard
2020-10-09 11:30 98% ` Philip K.
2020-10-09 17:23 Adrien Brochard
2020-10-09 18:17 87% ` Philip K.
2020-10-09 19:52 Adrien Brochard
2020-10-10 10:35 89% ` Philip K.
2020-10-11 5:24 ` Richard Stallman
2020-10-11 17:59 82% ` Philip K.
2020-10-11 7:31 ` Tomas Hlavaty
2020-10-11 17:47 99% ` Philip K.
2020-10-10 3:56 Richard Stallman
2020-10-10 9:36 94% ` Philip K.
2020-10-11 10:46 ` Jean Louis
2020-10-11 18:42 89% ` Philip K.
2020-10-24 3:45 NonGNU ELPA and release frequency Richard Stallman
2020-10-24 13:51 ` Antoine Kalmbach
2020-10-26 9:56 99% ` Philip K.
2020-12-15 5:30 Emacs Survey: Toolbars Lars Ingebrigtsen
2020-12-15 10:00 ` Jean Louis
2020-12-15 17:07 97% ` Philip K.
2020-12-15 14:17 ` Eric S Fraga
2020-12-15 14:50 ` Lars Ingebrigtsen
2020-12-15 15:14 ` Óscar Fuentes
2020-12-15 15:33 ` Lars Ingebrigtsen
2020-12-15 17:47 ` Óscar Fuentes
2020-12-15 18:48 99% ` Philip K.
2020-12-17 12:11 How to contribute new package to GNU ELPA? stardiviner
2020-12-19 6:22 ` Stefan Monnier
2020-12-19 7:08 ` stardiviner
2020-12-19 15:35 ` Stefan Monnier
2020-12-20 2:12 ` stardiviner
2020-12-20 12:29 ` Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?] Adam Porter
2020-12-21 5:47 ` Richard Stallman
2020-12-21 16:59 92% ` Philip K.
2020-12-21 18:13 Eli Zaretskii
2020-12-21 23:51 99% ` Philip K.
2020-12-22 3:35 Eli Zaretskii
2020-12-22 10:38 80% ` Philip K.
2020-12-22 5:20 Richard Stallman
2020-12-22 10:49 88% ` Philip K.
2020-12-22 12:03 Jean Louis
2020-12-22 13:23 99% ` Philip K.
2020-12-22 16:02 Eli Zaretskii
2020-12-22 16:59 79% ` Philip K.
2020-12-29 18:28 Poll: Change xref-show-definitions-function's default? Dmitry Gutov
2021-01-01 7:59 ` martin rudalics
2021-01-02 10:26 99% ` Philip K.
2021-01-02 10:24 99% ` Philip K.
2021-01-04 12:12 99% ` Philip K.
2021-01-04 12:22 Dmitry Gutov
2021-01-04 14:21 92% ` Philip K.
2021-01-24 6:12 POLL: make C-x o transient Zhiwei Chen
2021-01-25 14:39 ` Stefan Monnier
2021-01-25 15:30 ` aitor
2021-01-25 16:38 99% ` Philip K.
2021-01-25 17:01 ` Juri Linkov
2021-01-27 17:55 ` Juri Linkov
2021-01-28 7:46 99% ` Philip K.
2021-01-28 9:40 ` martin rudalics
2021-01-28 18:43 ` Juri Linkov
2021-01-28 19:13 ` Gregory Heytings
2021-01-28 21:58 ` Alan Mackenzie
2021-01-28 23:19 99% ` Philip K.
2021-02-02 15:21 Concern about new binding Kévin Le Gouguec
2021-02-03 17:13 ` [External] : " Eli Zaretskii
2021-02-03 18:01 ` spacibba--- via Emacs development discussions.
2021-02-03 18:14 ` Eli Zaretskii
2021-02-03 22:16 ` Ergus
2021-02-04 0:41 ` Stefan Kangas
2021-02-04 7:00 ` Ergus
2021-02-04 15:05 ` Eli Zaretskii
2021-02-04 16:06 ` Drew Adams
2021-02-05 5:49 ` Richard Stallman
2021-02-05 9:21 ` Gregory Heytings
2021-02-05 18:26 ` [External] : " Drew Adams
2021-02-05 20:26 ` Gregory Heytings
2021-02-05 20:54 ` Drew Adams
2021-02-05 21:41 ` Gregory Heytings
2021-02-05 22:43 ` Drew Adams
2021-02-05 23:38 ` Gregory Heytings
2021-02-06 0:45 ` Drew Adams
2021-02-06 9:29 ` Gregory Heytings
2021-02-06 18:09 ` Drew Adams
2021-02-12 8:21 ` Alfred M. Szmidt
2021-02-13 8:22 99% ` Philip Kaludercic
2021-02-04 11:43 33% [ELPA] A Setup package Philip K.
2021-02-04 11:47 37% ` Philip K.
2021-02-09 21:56 ` Stefan Monnier
2021-02-09 23:42 71% ` Philip K.
2021-03-11 16:17 99% ` Philip Kaludercic
2021-03-13 19:14 ` Stefan Monnier
2021-03-13 19:44 99% ` Philip Kaludercic
2021-03-14 15:07 ` Stefan Monnier
2021-03-14 16:21 90% ` Philip Kaludercic
2021-03-14 20:19 ` Stefan Monnier
2021-03-14 23:39 95% ` Philip Kaludercic
2021-03-15 4:15 ` Stefan Monnier
2021-03-15 10:09 99% ` Philip Kaludercic
2021-02-07 22:05 PROPOSAL: Repurpose one key and reserve it for third-party packages Gregory Heytings
[not found] ` <8735y56naf.fsf@posteo.net>
[not found] ` <8ed9b43502ae9a36b057@heytings.org>
2021-02-09 23:18 70% ` Philip K.
2021-02-14 12:12 76% Clarifying the C-c letter guideline Philip Kaludercic
2021-02-14 17:38 ` Jean Louis
2021-02-14 18:14 99% ` Philip Kaludercic
2021-02-14 17:19 Current mode command discovery Lars Ingebrigtsen
2021-02-14 17:51 ` Eli Zaretskii
2021-02-14 19:53 ` Óscar Fuentes
2021-02-14 20:25 ` Alan Mackenzie
2021-02-14 21:20 99% ` Philip Kaludercic
2021-02-14 19:18 goto-line-history should not be buffer local Alan Mackenzie
2021-02-14 23:08 ` Óscar Fuentes
2021-02-14 23:31 ` Richard Copley
2021-02-15 8:17 ` martin rudalics
2021-02-15 21:12 ` Alan Mackenzie
2021-02-16 17:13 ` Juri Linkov
2021-02-16 20:57 ` Alan Mackenzie
2021-02-16 22:52 ` Matt Armstrong
2021-02-18 0:26 ` Rolf Ade
2021-02-18 10:53 99% ` Philip Kaludercic
2021-02-16 1:12 34% Infrastructure for packages to suggest customizations Philip Kaludercic
2021-02-16 2:37 ` Stefan Monnier
2021-02-16 11:18 87% ` Philip Kaludercic
2021-03-05 22:48 Add project-name function Ivan Sokolov
2021-03-06 14:10 99% ` Philip Kaludercic
2021-03-20 9:03 Suggested experimental test Gregory Heytings
2021-03-21 6:53 ` Lars Ingebrigtsen
2021-03-21 8:35 ` Alfred M. Szmidt
2021-03-21 13:20 ` Gregory Heytings
2021-03-21 18:16 ` Alfred M. Szmidt
2021-03-21 22:16 ` Gregory Heytings
2021-03-22 3:33 ` Eli Zaretskii
2021-03-22 10:05 ` Gregory Heytings
2021-03-22 11:37 98% ` Philip Kaludercic
2021-03-21 10:48 ` Gregory Heytings
2021-03-22 12:06 ` Lars Ingebrigtsen
2021-03-22 17:40 ` Eli Zaretskii
2021-03-22 18:17 ` Lars Ingebrigtsen
2021-03-22 18:50 ` Eli Zaretskii
2021-03-22 19:09 ` Lars Ingebrigtsen
2021-03-22 19:55 ` Lars Ingebrigtsen
2021-03-22 22:02 ` Stefan Kangas
2021-03-22 22:44 ` Dmitry Gutov
2021-03-23 5:22 ` Jean Louis
2021-03-23 7:43 ` Eli Zaretskii
2021-03-23 12:28 99% ` Philip Kaludercic
2021-03-23 12:41 ` Eli Zaretskii
2021-03-23 13:09 ` Dmitry Gutov
2021-03-23 13:27 99% ` Philip Kaludercic
2021-04-03 7:53 [GNU ELPA] New package proposal: aggressive-completion.el Tassilo Horn
2021-04-03 11:53 92% ` Philip Kaludercic
2021-04-03 11:55 92% ` Philip Kaludercic
2021-04-03 13:43 ` Tassilo Horn
2021-04-03 17:22 87% ` [GNU ELPA] New package proposal: aggressive-completion.El Philip Kaludercic
[not found] <20210403001539.x4rb55dvh46rmhb3.ref@Ergus>
2021-04-03 0:15 ` Simple isearch concerns Ergus
2021-04-03 6:33 ` Manuel Uberti
2021-04-03 11:28 99% ` Philip Kaludercic
2021-04-03 12:26 ` Gregory Heytings
2021-04-03 16:37 99% ` Philip Kaludercic
2021-04-03 17:31 ` Gregory Heytings
2021-04-03 18:36 99% ` Philip Kaludercic
2021-04-05 10:22 [ELPA] New package: vertico Daniel Mendler
2021-04-05 14:27 ` Manuel Uberti
2021-04-05 18:30 ` Stepping Back: A Wealth Of Completion systems " T.V Raman
2021-04-05 20:49 66% ` Philip Kaludercic
2021-04-07 12:09 ` Gregory Heytings
2021-04-07 14:15 69% ` Philip Kaludercic
[not found] ` <87eefm5fzl.fsf@posteo.net>
[not found] ` <3ec7e2e58a106c77370d@heytings.org>
2021-04-07 14:33 99% ` Philip Kaludercic
2021-04-07 15:17 ` Daniel Mendler
2021-04-07 16:20 84% ` Philip Kaludercic
2021-04-07 16:57 ` Daniel Mendler
2021-04-07 19:13 73% ` Philip Kaludercic
2021-04-07 20:03 ` Daniel Mendler
2021-04-07 22:31 99% ` Philip Kaludercic
2021-04-07 15:24 ` Gregory Heytings
2021-04-07 16:10 99% ` Philip Kaludercic
2021-04-07 16:49 ` Gregory Heytings
2021-04-07 17:40 99% ` Philip Kaludercic
2021-04-07 17:48 ` Gregory Heytings
2021-04-07 19:22 99% ` Philip Kaludercic
2021-04-07 13:01 ` Dmitry Gutov
2021-04-07 14:44 ` Stefan Monnier
2021-04-07 14:55 99% ` Philip Kaludercic
2021-04-07 21:56 ` Dmitry Gutov
2021-04-07 22:59 99% ` Philip Kaludercic
2021-04-08 0:48 ` Dmitry Gutov
2021-04-08 14:44 99% ` Philip Kaludercic
2021-04-08 16:40 ` T.V Raman
2021-04-08 17:53 99% ` Philip Kaludercic
2021-04-08 17:21 ` [External] : " Drew Adams
2021-04-08 18:03 82% ` Philip Kaludercic
2021-04-08 18:59 ` Dmitry Gutov
2021-04-09 5:56 ` Eli Zaretskii
2021-04-09 23:12 ` Dmitry Gutov
2021-04-09 23:48 ` Stefan Monnier
2021-04-10 1:56 ` Dmitry Gutov
2021-04-10 4:04 ` Stefan Monnier
2021-04-10 13:11 ` Dmitry Gutov
2021-04-11 21:52 99% ` Philip Kaludercic
2021-04-10 7:20 ` Eli Zaretskii
2021-04-10 10:56 ` Stefan Kangas
2021-04-10 11:11 ` Eli Zaretskii
2021-04-11 11:37 ` Stefan Kangas
2021-04-11 12:24 99% ` Philip Kaludercic
2021-04-10 14:40 79% ` Philip Kaludercic
2021-04-11 0:18 ` Dmitry Gutov
2021-04-11 11:18 86% ` Philip Kaludercic
2021-04-11 13:31 ` Jean Louis
2021-04-11 15:53 99% ` Philip Kaludercic
2021-04-12 9:24 ` Jean Louis
2021-04-12 10:14 98% ` Philip Kaludercic
2021-04-12 10:56 ` Jean Louis
2021-04-12 11:30 99% ` Philip Kaludercic
2021-04-11 13:34 ` Eli Zaretskii
2021-04-11 16:14 99% ` Philip Kaludercic
2021-04-11 16:53 ` Eli Zaretskii
2021-04-11 17:39 94% ` Philip Kaludercic
2021-04-21 9:20 79% ` Philip Kaludercic
2021-04-21 9:29 ` Eli Zaretskii
2021-04-21 10:27 99% ` Philip Kaludercic
2021-04-21 12:00 ` Eli Zaretskii
2021-04-21 12:50 94% ` Philip Kaludercic
2021-04-21 13:14 ` Daniel Mendler
2021-04-21 14:21 86% ` Philip Kaludercic
2021-04-05 22:23 [PATCH] icomplete-vertical Gregory Heytings
2021-04-05 23:04 99% ` Philip Kaludercic
2021-04-05 23:09 ` Gregory Heytings
2021-04-06 1:08 ` Stefan Kangas
2021-04-06 2:31 ` Eli Zaretskii
2021-04-06 7:44 ` Gregory Heytings
2021-04-06 8:54 99% ` Philip Kaludercic
2021-04-06 9:10 ` Gregory Heytings
2021-04-06 9:30 99% ` Philip Kaludercic
2021-04-06 10:20 ` Gregory Heytings
2021-04-06 13:20 ` Stefan Monnier
2021-04-06 14:25 ` Ergus
2021-04-06 15:17 99% ` Philip Kaludercic
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
2021-04-14 9:45 99% ` Philip Kaludercic
2021-04-14 10:14 ` Andrea Corallo via Emacs development discussions.
2021-04-14 10:35 99% ` Philip Kaludercic
2021-04-14 10:45 ` Eli Zaretskii
2021-04-14 12:57 99% ` Philip Kaludercic
2021-04-14 13:10 ` Eli Zaretskii
2021-04-14 14:00 92% ` Philip Kaludercic
2021-04-14 14:35 ` Stefan Kangas
2021-04-14 14:42 99% ` Philip Kaludercic
2021-04-11 23:19 [PATCH] Add buffer name option for project-compile Ivan Sokolov
2021-04-12 8:13 99% ` Philip Kaludercic
2021-04-14 9:52 99% Miscategorised project.el user options Philip Kaludercic
2021-04-19 15:51 Adding transient to Emacs core Jonas Bernoulli
2021-04-26 2:30 ` Madhu
2021-04-26 11:51 ` Eli Zaretskii
2021-04-26 12:54 99% ` Philip Kaludercic
2021-04-26 13:27 ` Jonas Bernoulli
2021-04-26 17:33 ` Madhu
2021-04-27 9:00 ` Jonas Bernoulli
2021-04-27 10:51 99% ` Philip Kaludercic
2021-04-27 11:01 ` Gregory Heytings
2021-04-27 12:05 ` Jonas Bernoulli
2021-04-27 15:21 86% ` Philip Kaludercic
2021-04-22 9:57 80% On the stability of Xref Philip Kaludercic
2021-05-03 9:43 80% [PATCH] Speed up project-kill-buffers Philip Kaludercic
2021-05-03 12:46 ` Stefan Monnier
2021-05-03 13:06 84% ` Philip Kaludercic
2021-05-03 13:24 ` Stefan Monnier
2021-05-03 17:25 99% ` Philip Kaludercic
2021-05-08 12:03 ` Stephen Leake
2021-05-08 12:30 99% ` Philip Kaludercic
2021-05-08 13:05 99% ` Philip Kaludercic
2021-05-29 11:54 [ELPA] New package: evdocs Augusto Stoffel
2021-05-29 12:05 99% ` Philip Kaludercic
2021-05-30 18:36 77% [PATCH] Fix random selection of keyserver Philip Kaludercic
2021-05-30 18:57 ` Eli Zaretskii
2021-05-30 19:46 99% ` Philip Kaludercic
2021-05-31 9:00 ` Lars Ingebrigtsen
2021-05-31 11:13 66% ` Philip Kaludercic
2021-05-31 11:43 ` Andreas Schwab
2021-05-31 12:04 99% ` Philip Kaludercic
2021-06-04 15:16 6% Cleaning up rcirc Philip Kaludercic
2021-06-04 16:55 ` Andreas Schwab
2021-06-04 18:09 98% ` Philip Kaludercic
2021-06-06 18:41 ` Tassilo Horn
2021-06-06 21:09 99% ` Philip Kaludercic
2021-06-10 15:50 83% ` Philip Kaludercic
2021-06-10 19:13 ` Tassilo Horn
2021-06-10 21:54 99% ` Philip Kaludercic
2021-06-11 5:02 ` Tassilo Horn
2021-06-11 6:35 ` Tassilo Horn
2021-06-11 9:08 99% ` Philip Kaludercic
2021-06-11 9:27 ` Tassilo Horn
2021-06-11 9:44 99% ` Philip Kaludercic
2021-06-11 11:10 ` Tassilo Horn
2021-06-11 14:51 99% ` Philip Kaludercic
2021-06-11 8:09 97% ` Philip Kaludercic
2021-06-07 9:55 ` Lars Ingebrigtsen
2021-07-22 22:14 99% ` Philip Kaludercic
2021-06-07 13:08 ` Zhiwei Chen
2021-06-07 13:20 99% ` Philip Kaludercic
2021-06-10 7:51 [PATCH] 0001-Add-icomplete-count-format tumashu
2021-06-10 16:23 99% ` Philip Kaludercic
2021-06-11 0:09 ` tumashu
2021-06-17 3:24 ` tumashu
2021-06-17 8:02 99% ` Philip Kaludercic
2021-06-11 9:38 [feature/rcirc-update] Reconnects don't seem to work anymore Tassilo Horn
2021-06-11 10:57 99% ` Philip Kaludercic
2021-06-11 10:59 ` Tassilo Horn
2021-06-11 14:50 99% ` Philip Kaludercic
2021-06-15 5:13 ` Tassilo Horn
2021-06-15 16:17 99% ` Philip Kaludercic
2021-06-15 18:39 ` Tassilo Horn
2021-06-15 21:49 94% ` Philip Kaludercic
2021-06-16 4:54 ` Tassilo Horn
2021-06-16 7:41 99% ` Philip Kaludercic
2021-06-16 7:43 ` Tassilo Horn
2021-06-16 8:21 99% ` Philip Kaludercic
2021-06-16 8:35 ` Tassilo Horn
2021-06-16 8:48 99% ` Philip Kaludercic
2021-06-16 5:22 ` Tassilo Horn
2021-06-16 8:01 99% ` Philip Kaludercic
2021-06-16 5:25 Emacs CLA requirement Andrei Kuznetsov
2021-06-16 9:37 99% ` Philip Kaludercic
2021-06-16 10:05 ` Andrei Kuznetsov
2021-06-16 10:22 99% ` Philip Kaludercic
2021-06-16 11:40 ` tomas
2021-06-16 11:53 99% ` Philip Kaludercic
2021-06-16 12:42 ` Andrei Kuznetsov
2021-06-16 12:55 99% ` Philip Kaludercic
2021-06-16 13:23 ` Christopher Dimech
2021-06-16 14:34 ` Adam Tack
2021-06-16 14:47 ` Stefan Monnier
2021-06-16 15:13 ` Adam Tack
2021-06-16 15:44 ` Stefan Monnier
2021-06-16 21:34 97% ` NonGNU ELPA work (Was: Emacs CLA requirement) Philip Kaludercic
2021-06-16 22:24 ` NonGNU ELPA work Stefan Monnier
2021-06-17 8:36 81% ` Philip Kaludercic
2021-06-17 14:13 ` Stefan Monnier
2021-06-17 19:33 ` Richard Stallman
2021-06-18 9:06 95% ` Philip Kaludercic
2021-08-04 11:08 47% ` Philip Kaludercic
2021-08-04 16:21 ` Stefan Monnier
2021-08-04 18:41 26% ` Philip Kaludercic
2021-08-04 18:44 99% ` Philip Kaludercic
2021-08-04 22:42 ` Stefan Monnier
2021-08-05 9:16 99% ` Philip Kaludercic
2021-06-17 9:41 ` Jean Louis
2021-06-17 9:55 99% ` Philip Kaludercic
2021-06-25 19:12 69% Reloading themes in user option setters Philip Kaludercic
2021-06-28 10:36 About SASL authentication in rcirc Tassilo Horn
2021-06-28 12:46 ` amk
2021-06-29 8:04 99% ` Philip Kaludercic
2021-07-03 21:13 On the adoption of transient.el Gabriel
2021-07-05 14:24 99% ` Philip Kaludercic
2021-07-05 16:50 ` Yuri Khan
2021-07-05 18:09 96% ` Philip Kaludercic
2021-08-01 20:19 ` Rudolf Adamkovič
2021-08-04 11:22 86% ` Philip Kaludercic
2021-07-22 0:23 access to ELPA development packages? Stephen Leake
2021-07-22 13:17 ` Stephen Leake
2021-07-23 6:26 ` Bozhidar Batsov
2021-07-23 11:04 99% ` Philip Kaludercic
2021-07-26 0:16 ` Richard Stallman
2021-07-26 20:52 69% ` Philip Kaludercic
2021-07-26 22:01 ` dick
2021-07-27 8:12 99% ` Philip Kaludercic
2021-07-25 12:02 Add Maildir support to RMAIL csh
2021-07-26 8:35 92% ` Philip Kaludercic
2021-07-25 12:56 Eli Zaretskii
2021-07-25 13:50 ` csh
2021-07-26 8:35 99% ` Philip Kaludercic
2021-07-27 21:50 79% Silence checkdoc for symbols designating major and minor modes Philip Kaludercic
2021-07-28 11:33 ` Eli Zaretskii
2021-07-28 14:46 92% ` Philip Kaludercic
2021-07-28 16:08 ` Eli Zaretskii
2021-07-30 11:17 99% ` Philip Kaludercic
2021-08-03 13:51 Make ELPA and nongnu elpa more accessible Fu Yuan
2021-08-04 21:14 99% ` Philip Kaludercic
2021-08-05 15:45 [ANN] EmacsConf 2021 Call for Proposals Amin Bandali
2021-08-07 21:00 ` quiliro
2021-08-07 22:39 99% ` Philip Kaludercic
2021-08-07 23:32 99% [ELPA] New package: vc-backup Philip Kaludercic
2021-08-07 23:53 ` Alfred M. Szmidt
2021-08-19 22:04 99% ` Philip Kaludercic
[not found] <20210807231108.10378.42095@vcs0.savannah.gnu.org>
[not found] ` <20210807231109.E658220BD3@vcs0.savannah.gnu.org>
2021-08-08 3:24 ` [nongnu] main 23c23ad: * elpa-packages (smartparens): Add package Stefan Monnier
2021-08-08 8:00 99% ` Philip Kaludercic
2021-08-19 9:23 99% ` Philip Kaludercic
2021-08-19 13:08 ` Stefan Monnier
2021-08-19 15:31 92% ` Philip Kaludercic
2021-08-08 10:49 ELPA: add flymake-proselint Manuel Uberti
2021-08-08 14:07 99% ` Philip Kaludercic
2021-08-08 15:40 89% Easy configuration of a site-lisp directory Philip Kaludercic
2021-08-08 18:18 ` Stefan Monnier
2021-08-08 18:53 99% ` Philip Kaludercic
2021-08-19 9:25 99% ` Philip Kaludercic
2021-08-19 20:24 ` Arthur Miller
2021-08-19 21:43 ` Arthur Miller
2021-08-19 21:47 ` Arthur Miller
2021-08-19 21:59 94% ` Philip Kaludercic
2021-08-09 8:28 Obtaining the version of an installed package Bozhidar Batsov
2021-08-09 12:58 ` Stefan Monnier
2021-08-09 14:03 ` Bozhidar Batsov
2021-08-09 15:35 99% ` Philip Kaludercic
2021-08-12 23:43 Collaborative editing Perry E. Metzger
2021-08-15 5:46 ` Jean Louis
2021-08-15 11:24 ` Ergus
2021-08-19 9:32 97% ` Philip Kaludercic
2021-08-19 9:33 97% ` Philip Kaludercic
2021-08-19 14:18 ` Ergus
2021-08-19 15:36 93% ` Philip Kaludercic
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).