Custom vtable.el sorters

Custom vtable.el sorters

[Kristoffer Balintona]

Hello,

I recently discovered the wonderful vtable.el built-in package. As far
as I can tell, vtable is meant to eventually be a drop-in replacement
for tabulated-list-mode (despite (elisp) Tabulated List Mode mentioning
that vtable is geared toward variable pitch fonts, whereas
tabulated-list mode is for monospace fonts) -- please correct me if I am
wrong.

In any case, I noticed that in vtable.el, vtable--sort (which appears to
be where column sorting is implemented) has hard-coded behavior for
sorting, namely, simple numerical and string sorters. I would like to
ask about whether there any plans to add the ability for users to set
custom sorters for their columns. Tabulated-list-mode has a version of
this by setting tabulated-list-format: every column can use its own
sorter.

-- 
With appreciation,
Kristoffer

Re: Custom vtable.el sorters

[Adam Porter]

Hi Kristoffer,

> I recently discovered the wonderful vtable.el built-in package. As far
> as I can tell, vtable is meant to eventually be a drop-in replacement
> for tabulated-list-mode (despite (elisp) Tabulated List Mode mentioning
> that vtable is geared toward variable pitch fonts, whereas
> tabulated-list mode is for monospace fonts) -- please correct me if I am
> wrong.
> 
> In any case, I noticed that in vtable.el, vtable--sort (which appears to
> be where column sorting is implemented) has hard-coded behavior for
> sorting, namely, simple numerical and string sorters. I would like to
> ask about whether there any plans to add the ability for users to set
> custom sorters for their columns. Tabulated-list-mode has a version of
> this by setting tabulated-list-format: every column can use its own
> sorter.

I can't find any bug reports mentioning "vtable sort", so I guess there 
are no such plans yet.  The Vtable manual indeed says that only 
numerical and string sorting is done, depending on the type of value 
returned by the getter function.  But it seems like a reasonable idea to 
me, to allow custom sort functions.  So, patches welcome, I guess.  :)

--Adam

Re: Custom vtable.el sorters

[Kristoffer Balintona]

On Thu, Oct 03 2024, Adam Porter wrote:

> Hi Kristoffer,
>
>> I recently discovered the wonderful vtable.el built-in package. As far
>> as I can tell, vtable is meant to eventually be a drop-in replacement
>> for tabulated-list-mode (despite (elisp) Tabulated List Mode mentioning
>> that vtable is geared toward variable pitch fonts, whereas
>> tabulated-list mode is for monospace fonts) -- please correct me if I am
>> wrong.
>>
>> In any case, I noticed that in vtable.el, vtable--sort (which appears to
>> be where column sorting is implemented) has hard-coded behavior for
>> sorting, namely, simple numerical and string sorters. I would like to
>> ask about whether there any plans to add the ability for users to set
>> custom sorters for their columns. Tabulated-list-mode has a version of
>> this by setting tabulated-list-format: every column can use its own
>> sorter.
>
> I can't find any bug reports mentioning "vtable sort", so I guess there
> are no such plans yet.  The Vtable manual indeed says that only
> numerical and string sorting is done, depending on the type of value
> returned by the getter function.  But it seems like a reasonable idea to
> me, to allow custom sort functions.  So, patches welcome, I guess.  :)

I see. I could definitely try my hand at implementing such a feature.
However, I'm very new to the Emacs development process and have never
contributed to Emacs before. (I am aware of the FSF copyright assignment
process though.) Would I just attach a patch to an email sent to
emacs-devel@gnu.org and wait for some input?

Although I haven't tried yet, another concern of mine is that whatever
implementation I think up wouldn't be that great--I can't help but feel
like someone more qualified should do the job of writing the code for
what could be a widely used feature in the future.

I apologize if these questions are naive. I thought it'd be better to
ask anyway.

-- 
With appreciation,
Kristoffer

Re: Custom vtable.el sorters

[Emanuel Berg]

Kristoffer Balintona wrote:

> I see. I could definitely try my hand at implementing such
> a feature.

Then you should do it, sure!

-- 
underground experts united
https://dataswamp.org/~incal

Re: Custom vtable.el sorters

[Adam Porter]

On 10/4/24 19:44, Kristoffer Balintona wrote:

> I see. I could definitely try my hand at implementing such a feature.
> However, I'm very new to the Emacs development process and have never
> contributed to Emacs before. (I am aware of the FSF copyright assignment
> process though.) Would I just attach a patch to an email sent to
> emacs-devel@gnu.org and wait for some input?

That's one way to do it, yes.  You could also submit it as a bug report 
with the patch attached, which helps ensure that it doesn't get lost. 
If you do, feel free to cc me; I'm not the vtable.el maintainer, but I 
have worked on it recently and don't mind helping out where I can.

> Although I haven't tried yet, another concern of mine is that whatever
> implementation I think up wouldn't be that great--I can't help but feel
> like someone more qualified should do the job of writing the code for
> what could be a widely used feature in the future.

Many people who've contributed to Emacs don't feel like they are expert 
programmers, and most aren't, anyway.  And remember that some of the 
first Emacs users and programmers also weren't programmers by 
profession.  One of the best ways to learn is by writing code and 
getting feedback from experienced developers like the Emacs maintainers 
(whom I can't speak for, but I can try to imitate them a little).

> I apologize if these questions are naive. I thought it'd be better to
> ask anyway.

Not at all.  Contributions and questions from motivated users are always 
welcome.  We all start somewhere--and with Emacs, once you get started, 
it can be hard to stop!  :)

--Adam

Re: Custom vtable.el sorters

[Kristoffer Balintona]

On Fri, Oct 04, 2024 at 09:24 PM Adam Porter <adam@alphapapa.net> wrote:

> On 10/4/24 19:44, Kristoffer Balintona wrote:
>
>> I see. I could definitely try my hand at implementing such a feature.
>> However, I'm very new to the Emacs development process and have never
>> contributed to Emacs before. (I am aware of the FSF copyright assignment
>> process though.) Would I just attach a patch to an email sent to
>> emacs-devel@gnu.org and wait for some input?
>
> That's one way to do it, yes.  You could also submit it as a bug report
> with the patch attached, which helps ensure that it doesn't get lost.
> If you do, feel free to cc me; I'm not the vtable.el maintainer, but I
> have worked on it recently and don't mind helping out where I can.
>

Will do.

>> Although I haven't tried yet, another concern of mine is that whatever
>> implementation I think up wouldn't be that great--I can't help but feel
>> like someone more qualified should do the job of writing the code for
>> what could be a widely used feature in the future.
>
> Many people who've contributed to Emacs don't feel like they are expert
> programmers, and most aren't, anyway.  And remember that some of the
> first Emacs users and programmers also weren't programmers by
> profession.  One of the best ways to learn is by writing code and
> getting feedback from experienced developers like the Emacs maintainers
> (whom I can't speak for, but I can try to imitate them a little).
>
>> I apologize if these questions are naive. I thought it'd be better to
>> ask anyway.
>
> Not at all.  Contributions and questions from motivated users are always
> welcome.  We all start somewhere--and with Emacs, once you get started,
> it can be hard to stop!  :)

Thank you for the supportive words. In the past, I've been quite daunted
by how different Emacs' development process is and how upstream Emacs
feels more "official" than much smaller packages. You've been very
encouraging, so I think I'll try and work on vtable sorting in the
coming days/weeks. Thanks again.

-- 
In gratitude,
Kristoffer

emacs-lisp-project [was: Re: Custom vtable.el sorters]

[Emanuel Berg]

Kristoffer Balintona wrote:

> Thank you for the supportive words. In the past, I've been
> quite daunted by how different Emacs' development process is
> and how upstream Emacs feels more "official" than much
> smaller packages. You've been very encouraging, so I think
> I'll try and work on vtable sorting in the coming
> days/weeks. Thanks again.

What one could do, is split emacs-devel into `emacs-devel' and
`emacs-project' (or maybe `emacs-lisp-project').

emacs-project would then be supportive of anyone being active
with emacs at their own (any) level, emacs-devel OTOH there
some elitism would be expected since there it is only about
pushing code to core Emacs and associated packages.

That said, some projects would eventually make their way all
the way into very central packages if not core Emacs.

So it would more be trying to have a culture to fit
the purpose of the moment.

Yes, where are you suppose to talk about your Emacs projects?
If they are about Emacs, they are not off-topic here, and also
not at #emacs, still, trust me, it can feel contrary to all
instinct to bring them up. So it should be the other way
around, we should have a place where this feel natural.

-- 
underground experts united
https://dataswamp.org/~incal

Re: emacs-lisp-project [was: Re: Custom vtable.el sorters]

[Richard Stallman]

[[[ 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. ]]]

  > What one could do, is split emacs-devel into `emacs-devel' and
  > `emacs-project' (or maybe `emacs-lisp-project').

What would be the _topic_ for the second list?

  > emacs-project would then be supportive of anyone being active
  > with emacs at their own (any) level,

That proposes an _attitude_ for the list, but it needs to say what topics
are to be discussed there.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: emacs-lisp-project [was: Re: Custom vtable.el sorters]

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 12 Oct 2024 23:32:23 -0400
> 
>   > What one could do, is split emacs-devel into `emacs-devel' and
>   > `emacs-project' (or maybe `emacs-lisp-project').
> 
> What would be the _topic_ for the second list?
> 
>   > emacs-project would then be supportive of anyone being active
>   > with emacs at their own (any) level,
> 
> That proposes an _attitude_ for the list, but it needs to say what topics
> are to be discussed there.

From where I stand, creating yet another mailing list related to Emacs
development is not a good idea, primarily because we will never be
able to separate the issues well enough for such a division to be
effective.  The clear disadvantage of this is that there will be
another mailing list to manage, so the advantages need to be very
clear to outweigh that, and they don't in this case.

Re: emacs-lisp-project [was: Re: Custom vtable.el sorters]

[Philip Kaludercic]

Emanuel Berg <incal@dataswamp.org> writes:

> Kristoffer Balintona wrote:
>
>> Thank you for the supportive words. In the past, I've been
>> quite daunted by how different Emacs' development process is
>> and how upstream Emacs feels more "official" than much
>> smaller packages. You've been very encouraging, so I think
>> I'll try and work on vtable sorting in the coming
>> days/weeks. Thanks again.
>
> What one could do, is split emacs-devel into `emacs-devel' and
> `emacs-project' (or maybe `emacs-lisp-project').
>
> emacs-project would then be supportive of anyone being active
> with emacs at their own (any) level, emacs-devel OTOH there
> some elitism would be expected since there it is only about
> pushing code to core Emacs and associated packages.
>
> That said, some projects would eventually make their way all
> the way into very central packages if not core Emacs.
>
> So it would more be trying to have a culture to fit
> the purpose of the moment.
>
> Yes, where are you suppose to talk about your Emacs projects?
> If they are about Emacs, they are not off-topic here, and also
> not at #emacs, still, trust me, it can feel contrary to all
> instinct to bring them up. So it should be the other way
> around, we should have a place where this feel natural.

Why don't you use help-gnu-emacs@gnu.org, if you have questions?  Or
more generally a personal website?  That is usually what people use for
a personal blog.

-- 
	Philip Kaludercic on icterid

Re: emacs-lisp-project [was: Re: Custom vtable.el sorters]

[Kristoffer Balintona]

On Sun, Oct 13 2024, Philip Kaludercic wrote:

> Emanuel Berg <incal@dataswamp.org> writes:
>
>> Kristoffer Balintona wrote:
>>
>>> Thank you for the supportive words. In the past, I've been
>>> quite daunted by how different Emacs' development process is
>>> and how upstream Emacs feels more "official" than much
>>> smaller packages. You've been very encouraging, so I think
>>> I'll try and work on vtable sorting in the coming
>>> days/weeks. Thanks again.
>>
>> What one could do, is split emacs-devel into `emacs-devel' and
>> `emacs-project' (or maybe `emacs-lisp-project').
>>
>> emacs-project would then be supportive of anyone being active
>> with emacs at their own (any) level, emacs-devel OTOH there
>> some elitism would be expected since there it is only about
>> pushing code to core Emacs and associated packages.
>>
>> That said, some projects would eventually make their way all
>> the way into very central packages if not core Emacs.
>>
>> So it would more be trying to have a culture to fit
>> the purpose of the moment.
>>
>> Yes, where are you suppose to talk about your Emacs projects?
>> If they are about Emacs, they are not off-topic here, and also
>> not at #emacs, still, trust me, it can feel contrary to all
>> instinct to bring them up. So it should be the other way
>> around, we should have a place where this feel natural.
>
> Why don't you use help-gnu-emacs@gnu.org, if you have questions?  Or
> more generally a personal website?  That is usually what people use for
> a personal blog.

Regarding using emacs-devel@gnu.org versus help-gnu-emacs@gnu.org, I
think Emanuel's intent was most evident here:

    So it would more be trying to have a culture to fit the purpose of
    the moment.

I think the proposed emacs-lisp-project mailing list would be geared
for an audience coming from a different background, thereby perceiving
the mailing list as a foreign and intimidating place to "put yourself
out there." Newcomers and non-programmers (or both) are the first to
come to mind.

I think Emanuel hopes that another mailing list could cater towards
those who are as experienced in programming or serious in contributing
to Emacs (Emanuel mentioned how emacs-devel sometimes comes with a
degree of elitism--at least from the eyes of a newcomer). "Culturally"
(or "conventionally," if you wish) it seems like help-gnu-emacs is the
mailing list for "I just need help, potentially for basic questions,"
while emacs-devel is where the critical and extensive contributions and
discussions occur.

Given that, what if a user wants to share their tinkering (with or
without the intent of having it eventually merged into upstream Emacs)
with others to receive feedback? emacs-devel would be more appropriate
than help-gnu-emacs, but the user might feel that their tinkering is
out-of-place when beside discussions of e.g. the intricacies of the C
core and significant patches to well-known built-ins.

In any case, this was just my attempt at trying to understand Emanuel's
initial proposition. Eli Zaretskii mentioned the additional overhead of
managing another mailing list, so I tend to agree that we should keep
emacs-devel and help-gnu-emacs as is. But perhaps Emanuel can chime in
again.

-- 
With appreciation,
Kristoffer

Re: emacs-lisp-project [was: Re: Custom vtable.el sorters]

[Ship Mints]

[-- Attachment #1: Type: text/plain, Size: 3715 bytes --]

https://www.reddit.com/r/emacs/ seems like a good place for people to
congregate and it leaves the mailing lists for less casual use.

On Mon, Oct 14, 2024 at 1:45 AM Kristoffer Balintona <
krisbalintona@gmail.com> wrote:

> On Sun, Oct 13 2024, Philip Kaludercic wrote:
>
> > Emanuel Berg <incal@dataswamp.org> writes:
> >
> >> Kristoffer Balintona wrote:
> >>
> >>> Thank you for the supportive words. In the past, I've been
> >>> quite daunted by how different Emacs' development process is
> >>> and how upstream Emacs feels more "official" than much
> >>> smaller packages. You've been very encouraging, so I think
> >>> I'll try and work on vtable sorting in the coming
> >>> days/weeks. Thanks again.
> >>
> >> What one could do, is split emacs-devel into `emacs-devel' and
> >> `emacs-project' (or maybe `emacs-lisp-project').
> >>
> >> emacs-project would then be supportive of anyone being active
> >> with emacs at their own (any) level, emacs-devel OTOH there
> >> some elitism would be expected since there it is only about
> >> pushing code to core Emacs and associated packages.
> >>
> >> That said, some projects would eventually make their way all
> >> the way into very central packages if not core Emacs.
> >>
> >> So it would more be trying to have a culture to fit
> >> the purpose of the moment.
> >>
> >> Yes, where are you suppose to talk about your Emacs projects?
> >> If they are about Emacs, they are not off-topic here, and also
> >> not at #emacs, still, trust me, it can feel contrary to all
> >> instinct to bring them up. So it should be the other way
> >> around, we should have a place where this feel natural.
> >
> > Why don't you use help-gnu-emacs@gnu.org, if you have questions?  Or
> > more generally a personal website?  That is usually what people use for
> > a personal blog.
>
> Regarding using emacs-devel@gnu.org versus help-gnu-emacs@gnu.org, I
> think Emanuel's intent was most evident here:
>
>     So it would more be trying to have a culture to fit the purpose of
>     the moment.
>
> I think the proposed emacs-lisp-project mailing list would be geared
> for an audience coming from a different background, thereby perceiving
> the mailing list as a foreign and intimidating place to "put yourself
> out there." Newcomers and non-programmers (or both) are the first to
> come to mind.
>
> I think Emanuel hopes that another mailing list could cater towards
> those who are as experienced in programming or serious in contributing
> to Emacs (Emanuel mentioned how emacs-devel sometimes comes with a
> degree of elitism--at least from the eyes of a newcomer). "Culturally"
> (or "conventionally," if you wish) it seems like help-gnu-emacs is the
> mailing list for "I just need help, potentially for basic questions,"
> while emacs-devel is where the critical and extensive contributions and
> discussions occur.
>
> Given that, what if a user wants to share their tinkering (with or
> without the intent of having it eventually merged into upstream Emacs)
> with others to receive feedback? emacs-devel would be more appropriate
> than help-gnu-emacs, but the user might feel that their tinkering is
> out-of-place when beside discussions of e.g. the intricacies of the C
> core and significant patches to well-known built-ins.
>
> In any case, this was just my attempt at trying to understand Emanuel's
> initial proposition. Eli Zaretskii mentioned the additional overhead of
> managing another mailing list, so I tend to agree that we should keep
> emacs-devel and help-gnu-emacs as is. But perhaps Emanuel can chime in
> again.
>
> --
> With appreciation,
> Kristoffer
>
>

[-- Attachment #2: Type: text/html, Size: 4797 bytes --]