From: Dmitry Gutov <dmitry@gutov.dev>
To: Po Lu <luangruo@yahoo.com>
Cc: emacs-devel@gnu.org, Stephen Berman <stephen.berman@gmx.net>
Subject: Re: Upcoming merge of adaptive-wrap
Date: Sun, 28 Jan 2024 20:01:11 +0200 [thread overview]
Message-ID: <0318d26c-a09d-49e1-ae6d-cdc5badde9a6@gutov.dev> (raw)
In-Reply-To: <87il3dh6wd.fsf@yahoo.com>
On 28/01/2024 16:25, Po Lu wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
>
>> Ah, no. Installing software and browsing packages are both activities
>> that most computer users are implicitly familiar with.
>
> Reading is an activity most literate _humans_ are intimately familar
> with, but I'll humor you: the package list, in its present state as a
> list of compact one-line descriptions, is not the sort of graphical
> package manager computer users are well acquainted with. The search
> facilities available in such package managers source their results from
> thorough descriptions provided by package authors at the time their
> packages are submitted, most unlike our cascade of package names and
> keywords.
Yeah, actually it could be a worthwhile addition. We have commands like
package-menu-filter-by-description, but what they're actually filter by
is the one-line summary, nor the full description from Commentary. This
would require certain changes in the package archives, since currently
those descriptions are fetched separately on-demand.
>> People's capabilities are not static, but designing features which
>> impose fewer requirements on such is likely to help more people,
>> altogether.
>
> We are imposing no new requirements, but providing _new_ and _more
> helpful_ venues through which adaptive-wrap might be discovered and
> enabled.
I imagine the adaptive-wrap package will be removed from ELPA sooner or
later. We might as well discuss the tradeoffs.
>> From the menu? Options -> Manage Emacs Packages. Either way, the fact
>
> Why, you have neglected to mention Option -> Line Wrapping in This
> Buffer -> Visual Wrap Prefix, complete with a tooltip describing its
> function.
This is another example where the user is supposed to recognize the
feature by its short summary, right? "Visual Wrap Prefix Mode".
A the "tooltip describing its function" is
Display continuation lines with visual context-dependent prefix
If you think it describes it well, seems like a good package summary?
>> that Emacs does have packages is a widely advertised fact, everywhere
>> online.
>
> And why is the fact that Emacs has a manual not suitably advertised? It
> is advertised on the splash screen, literally the first screen presented
> to a new Emacs user.
Use this command and search the list for keywords
vs
Open one of these big books and look for the thing you wanted
I wonder what would be considered easier (people go and Google instead).
>> And once you reach the packages' list, you can search across all of
>> them (that appear there) using a uniform approach.
>
> No doubt, it will be an immeasurable relief to our users that the
> technique for searching the package list is uniform, despite never
> returning satisfactory results. Over the course of my year-long tenure
> as a moderator of an Emacs instant messenger group with roughly 1000
> members, not once have I seen the package list credited with the
> discovery of a package shared in the group.
Your group seems to have some particular qualities that go across most
of my experience, and those experiences I've seen conveyed on the web.
Perhaps it has to do something with the particular ecosystem (it is a
company which has SunOS installed somewhere, right?).
The packages list even has a specific feature that highlights the
packages that have been added recently (since your last viewing). All in
the name of discovery. And I've taken advantage of it many times myself.
>> I'm still unclear on what is missing from the summary, to be honest.
>>
>> The NEWS entry is more verbose, sure, but that should also apply when
>> the user finds a package based on the summary and clicks on it to read
>> the full description to verify if that's what they wanted to use.
>
> How about "source code comments", "unbroken appearance", or any of the
> myriad of other applications for adaptive-wrap that users might seek
> solutions for?
These seem like words for additional context, but not the terms for
describing the thing to search for. Or I misunderstand something.
next prev parent reply other threads:[~2024-01-28 18:01 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <878r4eqjh8.fsf.ref@yahoo.com>
2024-01-25 1:39 ` Upcoming merge of adaptive-wrap Po Lu
2024-01-25 4:44 ` Adam Porter
2024-01-25 10:01 ` Stephen Berman
2024-01-25 11:32 ` Po Lu
2024-01-25 12:37 ` Eli Zaretskii
2024-01-25 13:15 ` Po Lu
2024-01-26 8:05 ` Kévin Le Gouguec
2024-01-26 10:21 ` Po Lu
2024-01-26 11:26 ` Joost Kremers
2024-01-26 12:40 ` Eli Zaretskii
2024-01-26 13:47 ` Joost Kremers
2024-01-31 19:18 ` Stefan Monnier
2024-02-02 4:41 ` Madhu
2024-02-02 7:22 ` Eli Zaretskii
2024-01-25 17:10 ` Dmitry Gutov
2024-01-25 20:01 ` Stefan Kangas
2024-01-25 20:11 ` Dmitry Gutov
2024-01-26 1:45 ` Po Lu
2024-01-26 2:08 ` Dmitry Gutov
2024-01-26 2:22 ` Po Lu
2024-01-26 2:30 ` Dmitry Gutov
2024-01-26 4:03 ` Po Lu
2024-01-27 1:44 ` Dmitry Gutov
2024-01-27 3:58 ` Po Lu
2024-01-27 16:56 ` Dmitry Gutov
2024-01-27 22:59 ` Stefan Kangas
2024-01-28 0:18 ` [External] : " Drew Adams
2024-01-28 9:02 ` Michael Albinus
2024-01-28 9:36 ` Po Lu
2024-01-28 13:03 ` Dmitry Gutov
2024-01-29 1:56 ` Po Lu
2024-01-28 15:32 ` Drew Adams
2024-01-28 9:34 ` Po Lu
2024-01-28 13:11 ` Dmitry Gutov
2024-01-28 14:25 ` Po Lu
2024-01-28 18:01 ` Dmitry Gutov [this message]
2024-01-29 1:55 ` Po Lu
2024-01-26 1:54 ` Po Lu
2024-01-26 7:50 ` Eli Zaretskii
2024-01-26 10:24 ` Po Lu
2024-01-25 20:05 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0318d26c-a09d-49e1-ae6d-cdc5badde9a6@gutov.dev \
--to=dmitry@gutov.dev \
--cc=emacs-devel@gnu.org \
--cc=luangruo@yahoo.com \
--cc=stephen.berman@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.