GNU ELPA package proposal: visual-fill-column

GNU ELPA package proposal: visual-fill-column

[Joost Kremers]

Hi list,

Philip Kaludercic asked me if I would be interested in adding my package
`visual-fill-column` to GNU ELPA.[1] While I'm still a bit hazy on the details
(though I'm sure it will all clear itself up it due time), I do know the process
starts with a copyright assignment. I haven't done that yet, so my first
question is: how do I do that?

Another question that occurred to me: the package is currently available on
Melpa. I know there are packages that exist both on MELPA and on GNU ELPA, but
for `visual-fill-column`, that doesn't seem to make a lot of sense. If the
package is added to GNU ELPA and removed from MELPA, would that cause any
inconvenience for existing users? Would `package.el` be smart enough to update
existing users to the GNU ELPA version, once a new version is published there?
Or would it be better to keep the MELPA version to avoid any disruptions?

TIA,

Joost


Footnotes:
[1]  https://github.com/joostkremers/visual-fill-column/issues/52

-- 
Joost Kremers
Life has its moments

Re: GNU ELPA package proposal: visual-fill-column

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Tue, 26 Oct 2021 10:38:23 +0200
> 
> Philip Kaludercic asked me if I would be interested in adding my package
> `visual-fill-column` to GNU ELPA.[1] While I'm still a bit hazy on the details
> (though I'm sure it will all clear itself up it due time), I do know the process
> starts with a copyright assignment. I haven't done that yet, so my first
> question is: how do I do that?

Given that Emacs 27 has display-fill-column-indicator-mode built-in,
what would be the point of offering this package from ELPA?

Thanks.

Re: GNU ELPA package proposal: visual-fill-column

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Given that Emacs 27 has display-fill-column-indicator-mode built-in,
> what would be the point of offering this package from ELPA?

Was my first thought, too - but it seems to do something different from
simply visualizing the fill column.

Michael.

Re: GNU ELPA package proposal: visual-fill-column

[Daniel Martín]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Joost Kremers <joostkremers@fastmail.fm>
>> Date: Tue, 26 Oct 2021 10:38:23 +0200
>> 
>> Philip Kaludercic asked me if I would be interested in adding my package
>> `visual-fill-column` to GNU ELPA.[1] While I'm still a bit hazy on the details
>> (though I'm sure it will all clear itself up it due time), I do know the process
>> starts with a copyright assignment. I haven't done that yet, so my first
>> question is: how do I do that?
>
> Given that Emacs 27 has display-fill-column-indicator-mode built-in,
> what would be the point of offering this package from ELPA?
>

The functionality it offers is not the same.  I believe this proposed
visual-fill-column package is like visual-line-mode, but where the word
wrap position is not the window edge, but the fill-column position.

If there is interest in the functionality it offers, it may make sense
to see if it can be implemented in C, as an extension of either
visual-line-mode or display-fill-column-indicator-mode.

Re: GNU ELPA package proposal: visual-fill-column

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: Joost Kremers <joostkremers@fastmail.fm>,  emacs-devel@gnu.org
> Date: Tue, 26 Oct 2021 15:47:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Given that Emacs 27 has display-fill-column-indicator-mode built-in,
> > what would be the point of offering this package from ELPA?
> >
> 
> The functionality it offers is not the same.  I believe this proposed
> visual-fill-column package is like visual-line-mode, but where the word
> wrap position is not the window edge, but the fill-column position.

That should be in the display engine, not in Lisp, IMNSHO.

> If there is interest in the functionality it offers, it may make sense
> to see if it can be implemented in C, as an extension of either
> visual-line-mode or display-fill-column-indicator-mode.

The former, obviously.  yes, I think implementing this in display code
is the way to go.

Re: GNU ELPA package proposal: visual-fill-column

[Stefan Monnier]

> Philip Kaludercic asked me if I would be interested in adding my package
> `visual-fill-column` to GNU ELPA.[1]

Sounds great!

> While I'm still a bit hazy on the details (though I'm sure it will all
> clear itself up it due time), I do know the process starts with
> a copyright assignment.  I haven't done that yet, so my first question
> is: how do I do that?

Fill the form below and email it as instructed to the FSF so they can
send you the relevant paperwork to sign.

> Another question that occurred to me: the package is currently available on
> Melpa. I know there are packages that exist both on MELPA and on GNU ELPA, but
> for `visual-fill-column`, that doesn't seem to make a lot of sense. If the
> package is added to GNU ELPA and removed from MELPA, would that cause any
> inconvenience for existing users? Would `package.el` be smart enough to update
> existing users to the GNU ELPA version, once a new version is published there?
> Or would it be better to keep the MELPA version to avoid any disruptions?

No, `package.el` is not smart enough.  The reason is that the version
numbers used by MELPA don't match the ones used in GNU ELPA, so the
MELPA versions always seem to be "much higher" than the ones in GNU ELPA
(e.g. 20180223.223 > 5.7.2).  The users can explicitly "downgrade" to
the GNU ELPA version, of course, but it won't happen
automatically/transparently.

The same problem plagues transitions from MELPA to MELPA-Stable,
but not between MELPA-Stable and GNU ELPA ;-)


        Stefan


Please email the following information to assign@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]

Re: GNU ELPA package proposal: visual-fill-column

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> No, `package.el` is not smart enough.  The reason is that the version
> numbers used by MELPA don't match the ones used in GNU ELPA, so the
> MELPA versions always seem to be "much higher" than the ones in GNU ELPA
> (e.g. 20180223.223 > 5.7.2).

Maybe we should fix that.  Could it be as easy as looking for version
numbers starting with "YYYYMMDD", and if there is no package available
with a version formatted that way, just assume that the currently
highest numbered "normally versioned" package is more recent?

It's easy to think of hypothetical scenarios where it would break, but
it should work for the specific case of GNU ELPA, NonGNU ELPA and
MELPA, at least.

Re: GNU ELPA package proposal: visual-fill-column

[Stefan Monnier]

Stefan Kangas [2021-10-26 17:17:16] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> No, `package.el` is not smart enough.  The reason is that the version
>> numbers used by MELPA don't match the ones used in GNU ELPA, so the
>> MELPA versions always seem to be "much higher" than the ones in GNU ELPA
>> (e.g. 20180223.223 > 5.7.2).
> Maybe we should fix that.  Could it be as easy as looking for version
> numbers starting with "YYYYMMDD", and if there is no package available
> with a version formatted that way, just assume that the currently
> highest numbered "normally versioned" package is more recent?

Assuming would definitely not be a good idea because scenarios where
this is a bad idea aren't sufficiently hypothetical, IMO.

But we could add a hack that would detect such cases are prompt the user.

Better if we could get the release date of the package version 5.7.2 ;-)


        Stefan

Re: GNU ELPA package proposal: visual-fill-column

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> But we could add a hack that would detect such cases are prompt the user.

Right, I was thinking more along the lines of a hack.

> Better if we could get the release date of the package version 5.7.2 ;-)

Agreed.  There is some metadata that we don't currently keep track of
but would be very useful to have, starting with which archive a
package was installed from.

Re: GNU ELPA package proposal: visual-fill-column

[Joost Kremers]

On Tue, Oct 26 2021, Eli Zaretskii wrote:
>> From: Daniel Martín <mardani29@yahoo.es>
>> The functionality it offers is not the same.  I believe this proposed
>> visual-fill-column package is like visual-line-mode, but where the word
>> wrap position is not the window edge, but the fill-column position.

Yes, though it should be noted that it extends visual-line-mode, it does not
replace it. What visual-fill-column does, essentially, is widen the margin so
that the text area is narrowed. And it does its best to make sure that the right
thing happens when the window width changes.

>> If there is interest in the functionality it offers, it may make sense
>> to see if it can be implemented in C, as an extension of either
>> visual-line-mode or display-fill-column-indicator-mode.
>
> The former, obviously.  yes, I think implementing this in display code
> is the way to go.

To be honest, I always thought that made more sense, as well. But since that is
clearly beyond my abilities, I decided to write it in Lisp. And although I think
it works fairly well, it's not without its problems and limitations.

One limitation in particular comes to mind, which can perhaps be lifted in a C
implementation: since `visual-fill-column` achieves its effect by narrowing the
margin, it is not possible to disable word wrap for specific parts of the
buffer. That would be very practical in some cases, however, for example in Org
tables, which normally shouldn't be wrapped.

As to whether there is interest in this functionality: `visual-fill-column` has
about 380.000 downloads on Melpa. Nothing like dash or magit, obviously, but
still. Admittedly, most of these probably result from the fact that
`visual-fill-column` is a dependency of another package of mine,
`writeroom-mode`, which has about 315.000 downloads. But `writeroom-mode` would
probably also benefit from a C implementation of the functionality offered by
`visual-fill-column`.


-- 
Joost Kremers
Life has its moments

Re: GNU ELPA package proposal: visual-fill-column

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Stefan Kangas [2021-10-26 17:17:16] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> No, `package.el` is not smart enough.  The reason is that the version
>>> numbers used by MELPA don't match the ones used in GNU ELPA, so the
>>> MELPA versions always seem to be "much higher" than the ones in GNU ELPA
>>> (e.g. 20180223.223 > 5.7.2).
>> Maybe we should fix that.  Could it be as easy as looking for version
>> numbers starting with "YYYYMMDD", and if there is no package available
>> with a version formatted that way, just assume that the currently
>> highest numbered "normally versioned" package is more recent?
>
> Assuming would definitely not be a good idea because scenarios where
> this is a bad idea aren't sufficiently hypothetical, IMO.

Yes, there are packages on both GNU and NonGNU ELPA that use this as
their stable versioning scheme.

> But we could add a hack that would detect such cases are prompt the user.

How about introducing a package header to indicate that the versioning
scheme, so that package.el can fix it?

> Better if we could get the release date of the package version 5.7.2 ;-)
>
>
>         Stefan

-- 
	Philip Kaludercic

Re: GNU ELPA package proposal: visual-fill-column

[Philip Kaludercic]

Joost Kremers <joostkremers@fastmail.fm> writes:

> Hi list,
>
> Philip Kaludercic asked me if I would be interested in adding my package
> `visual-fill-column` to GNU ELPA.[1] While I'm still a bit hazy on the details
> (though I'm sure it will all clear itself up it due time), I do know the process
> starts with a copyright assignment. I haven't done that yet, so my first
> question is: how do I do that?

So should visual-fill-column be added or not? I think it is a popular
enough package to warrant adding now, even if the functionality might
later be reimplemented in C.

-- 
	Philip Kaludercic

Re: GNU ELPA package proposal: visual-fill-column

[Stefan Monnier]

>> Philip Kaludercic asked me if I would be interested in adding my package
>> `visual-fill-column` to GNU ELPA.[1] While I'm still a bit hazy on the details
>> (though I'm sure it will all clear itself up it due time), I do know the process
>> starts with a copyright assignment. I haven't done that yet, so my first
>> question is: how do I do that?
> So should visual-fill-column be added or not? I think it is a popular
> enough package to warrant adding now, even if the functionality might
> later be reimplemented in C.

Of course.


        Stefan

Re: GNU ELPA package proposal: visual-fill-column

[Daniel Martín]

Philip Kaludercic <philipk@posteo.net> writes:

> Joost Kremers <joostkremers@fastmail.fm> writes:
>
>> Hi list,
>>
>> Philip Kaludercic asked me if I would be interested in adding my package
>> `visual-fill-column` to GNU ELPA.[1] While I'm still a bit hazy on the details
>> (though I'm sure it will all clear itself up it due time), I do know the process
>> starts with a copyright assignment. I haven't done that yet, so my first
>> question is: how do I do that?
>
> So should visual-fill-column be added or not? I think it is a popular
> enough package to warrant adding now, even if the functionality might
> later be reimplemented in C.

Yes, I think it would be nice to have it in ELPA.  The C implementation
is still a wish, but the Elisp package is already developed and has lots
of users.

Re: GNU ELPA package proposal: visual-fill-column

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Philip Kaludercic asked me if I would be interested in adding my package
>>> `visual-fill-column` to GNU ELPA.[1] While I'm still a bit hazy on the details
>>> (though I'm sure it will all clear itself up it due time), I do know the process
>>> starts with a copyright assignment. I haven't done that yet, so my first
>>> question is: how do I do that?
>> So should visual-fill-column be added or not? I think it is a popular
>> enough package to warrant adding now, even if the functionality might
>> later be reimplemented in C.
>
> Of course.

Ok, has Joost completed the copyright assignment?

-- 
	Philip Kaludercic

Re: GNU ELPA package proposal: visual-fill-column

[Stefan Monnier]

> Ok, has Joost completed the copyright assignment?

Not yet, AFAIK,


        Stefan

Re: GNU ELPA package proposal: visual-fill-column

[Joost Kremers]

On Mon, Nov 01 2021, Stefan Monnier wrote:
>> Ok, has Joost completed the copyright assignment?
>
> Not yet, AFAIK,

No, not yet, sorry about that. I just sent the request form.

-- 
Joost Kremers
Life has its moments