Change terminology to better align users’ experience with modern GUIs

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Change terminology to better align users’ experience with modern GUIs

조성빈
Is there any intent or interest in updating the terminology of Emacs documentation/function names to better align users’ experience with modern GUIs?

For example, `window' and `buffer' in emacs is more meaningful when explained as `pane' or `document'.

Especially the term `window' is a frequent source of confusion to Emacs newcomers which confuse them to `frame'.

IMO in my ideal world, there should be no division between `window' and `buffer', the difference should be abstracted away so that users don’t have to know the `window' notion at all.
However that currently isn’t the case, there are multiple occurrences (and a dedicated chapter) in the Emacs manual about `window' and `buffer'.

Changing the `window' term to `pane' or something else seems like a low-hanging fruit for people who would like to try using Emacs; I’m interested/curious on other people’s opinions about this.

(Sorry about my bad English skills :-()

Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Jean Louis
* 조성빈 <[hidden email]> [2019-07-23 08:47]:
> Is there any intent or interest in updating the terminology of Emacs documentation/function names to better align users’ experience with modern GUIs?
>
> For example, `window' and `buffer' in emacs is more meaningful when
> explained as `pane' or `document'.

One word may have different definitions, right?

The Emacs manual explains the definitions.

I understand your viewpoint, you learned some other definitions for
same words and now you face little confusion. But imagine how many
people are there, so many of them would come from random environments
and would be faced with new definitions, so it would not be feasible
to change definitions to satisfy each particular wish, but I know that
changes and modifications are made by Emacs developers whenever it
benefits the majority.

In Emacs `buffer' is not necessarily connected to any file
document. Do you know?

> Especially the term `window' is a frequent source of confusion to
> Emacs newcomers which confuse them to `frame'.

Me not sure about that. I did not have confusion since 1999, since I
started using Emacs and stopped using that other system. But I did
take my time to read the books and manuals, and there were too many
new definitions of commands and terminology in the GNU/Linux system.

So facing the new terminology ALWAYS take place when learning some new
subject.

I hope that you can generally understand the situation. It applies in
every subject, not only computing.

When a new student in mining university learns definition of a
"sample", he cannot just try to adapt it to his previous understanding
of it, but he shall rather learn the new definition and apply it
properly in the context how and where it is used.

The word `sample' may be small part of something inteded as
representative of the whole (reference Wordnet). It could be a bite of
watermelon before its purchase.

But in mining, the word sample has quite different definition such as
"collection of fragments or pieces from a deposit which contains
exactly the same minerals in exactly the same proportions as they
exist in the deposit".

While it would be easier for student to simply go on with those known
definitions, it would create disaster in the subject of mining if his
definition of the word `sample' would be used.

That is why developers are pretty careful and try to find consensus
when making such modification.

> IMO in my ideal world, there should be no division between `window' and `buffer', the difference should be abstracted away so that users don’t have to know the `window' notion at all.
> However that currently isn’t the case, there are multiple occurrences (and a dedicated chapter) in the Emacs manual about `window' and `buffer'.
>
> Changing the `window' term to `pane' or something else seems like a low-hanging fruit for people who would like to try using Emacs; I’m interested/curious on other people’s opinions about this.

I am also not native English speaker. It should be logical from
physical world that a window consists of frames and panes eventually.

Those definitions are different from Emacs terminology.

And I would leave it how it is. Do you know why?

Because Emacs is an important part of civilization and development of
many other apparently not related pieces of software.

It brings to easier understanding of its history. I have here a
document AI Memo 554, from October 22nd 1981, EMACS Manual for ITS
Users. Now I am not sure if they had any graphical environment at that
time.

That company that sells operating system Windows maybe started in the
same year some plans for it, but nothing was released until
1985. https://en.wikipedia.org/wiki/Microsoft_Windows#Early_versions

And in the EMACS Manual for ITS Users the words "windows" are
mentioned.

What if they did not use graphical system? Then it was a console or
terminal based application. Monitor would not be considered a window
so that screen tilings become pane.

I think that logic of "window" comes from the console or terminal
based operation.

And Emacs is widely used through terminal modes, so changing
terminology would break the logic for those users.

Jean

Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

조성빈


> 2019. 7. 23. 오후 6:37, Jean Louis <[hidden email]> 작성:
>
> * 조성빈 <[hidden email]> [2019-07-23 08:47]:
>> Is there any intent or interest in updating the terminology of Emacs documentation/function names to better align users’ experience with modern GUIs?
>>
>> For example, `window' and `buffer' in emacs is more meaningful when
>> explained as `pane' or `document'.
>
> One word may have different definitions, right?
>
> The Emacs manual explains the definitions.
>
> I understand your viewpoint, you learned some other definitions for
> same words and now you face little confusion. But imagine how many
> people are there, so many of them would come from random environments
> and would be faced with new definitions, so it would not be feasible
> to change definitions to satisfy each particular wish, but I know that
> changes and modifications are made by Emacs developers whenever it
> benefits the majority.

No, I’ve been using Emacs for about ~2 years, definitely not an Emacs guru
but done enough elisp that I understand what each term means.

> In Emacs `buffer' is not necessarily connected to any file
> document. Do you know?

I’m aware of that.
The reason why I was suggesting `document' is because that’s what other
editors usually call that; I would be totally fine for another kind of term
that’s meanings are clear to new users.

>> Especially the term `window' is a frequent source of confusion to
>> Emacs newcomers which confuse them to `frame'.
>
> Me not sure about that. I did not have confusion since 1999, since I
> started using Emacs and stopped using that other system. But I did
> take my time to read the books and manuals, and there were too many
> new definitions of commands and terminology in the GNU/Linux system.
>
> So facing the new terminology ALWAYS take place when learning some new
> subject.

Yes, it is true. When learning a new subject (especially when it comes
to emacs) people should look forwards to learn new terminology.
However, it might be good practice to lower the barriers to approach Emacs
to a lot of people, considering that the majority of people who are using
computers have used graphical window systems.

>> IMO in my ideal world, there should be no division between `window' and `buffer', the difference should be abstracted away so that users don’t have to know the `window' notion at all.
>> However that currently isn’t the case, there are multiple occurrences (and a dedicated chapter) in the Emacs manual about `window' and `buffer'.
>>
>> Changing the `window' term to `pane' or something else seems like a low-hanging fruit for people who would like to try using Emacs; I’m interested/curious on other people’s opinions about this.
>
> I am also not native English speaker. It should be logical from
> physical world that a window consists of frames and panes eventually.
>
> Those definitions are different from Emacs terminology.
>
> And I would leave it how it is. Do you know why?
>
> Because Emacs is an important part of civilization and development of
> many other apparently not related pieces of software.

Because Emacs is an important part of civilization and development,
it might be better to adopt with the ‘outer world’ so that it can keep
gathering people.

> It brings to easier understanding of its history. I have here a
> document AI Memo 554, from October 22nd 1981, EMACS Manual for ITS
> Users. Now I am not sure if they had any graphical environment at that
> time.
>
> That company that sells operating system Windows maybe started in the
> same year some plans for it, but nothing was released until
> 1985. https://en.wikipedia.org/wiki/Microsoft_Windows#Early_versions
>
> And in the EMACS Manual for ITS Users the words "windows" are
> mentioned.

I understand the ‘why’ part of the original terminology; however, while
ITS has been discontinued for a long time, Emacs is used in the 21th
century where windowing systems are common (the majority).
Updating the terminology in a way that doesn’t interfere with the original
ones doesn’t harm IMO.

> What if they did not use graphical system? Then it was a console or
> terminal based application. Monitor would not be considered a window
> so that screen tilings become pane.

I’m not sure if the term `pane' implies that, for example people use
the terminology `pane' in tmux, a terminal multiplexer.

> I think that logic of "window" comes from the console or terminal
> based operation.
>
> And Emacs is widely used through terminal modes, so changing
> terminology would break the logic for those users.

While I know such people who use Emacs exclusively in terminals, most of them
have used/use window systems; they are very familiar with the usual `window’
terminology in general.
IMHO, the change of terminology wouldn’t be an issue to terminal users as the
terminology `pane’ also makes sense in terminals.

> Jean
>


Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Tomas Zerolo
In reply to this post by 조성빈
On Tue, Jul 23, 2019 at 03:46:31PM +0900, 조성빈 wrote:
> Is there any intent or interest in updating the terminology
> of Emacs documentation/function names to better align users’
> experience with modern GUIs?

Patience, young padovan :-)

Emacs has a working and dedicated community. If you just enter
through the door and say "Hello, everybody: how about we change
all names of things, like, now?"... how do you think people
will react?

Nevertheless you do have a strong point: the Emacs jargon, evolved
over a long time (few software packages in productive usage can look
back on thirty years of history) definitely poses a barrier to entry
for newcomers. Nobody wants that, thus constructive proposals to
change that are, I'm sure, welcome.

Change in Emacs is gradual (but still can be radical [1]), this
is a thing many of its users appreciate highly (I do, for one:
Emacs is one of my main tools, and I can afford to live on the
bleeding edge and compile for me the "newest Emacs" every week
or so. I wouldn't dare to do that with most other software out
there)!

So a good strategy, if you're really hot & willing to change
things would be to grab the documentation, and perhaps write
a companion to the documentation "Glossary" (let's call it
"Anti-Glossary" which translates "current" terms into the
Emacs terminology. So someone searching for "window", "pane",
"cursor", etc. has a chance to hit on the relevant documentation.

A next step might be to cross-index those "current" terms
with the "traditional" ones.

Whether you manage to convince enough people to really change
the language is anyone's guess, but you can start some steps
into that general direction.

P.S: Sorry if this mail comes across as somewhat... condescending.
This is not my intention at all! If that's the case, it is more
due to my inability to put things shortly and clearly.

Sorry for that.

Cheers

[1] I'd highly recommend reading
    https://www.iro.umontreal.ca/~monnier/hopl-4-emacs-lisp.pdf
    It's only about the Lisp part of Emacs but gives an impression
    on how much has happened over time.

-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Noam Postavsky
In reply to this post by 조성빈
On Tue, 23 Jul 2019 at 02:46, 조성빈 <[hidden email]> wrote:

> IMO in my ideal world, there should be no division between `window' and `buffer', the difference should be abstracted away so that users don’t have to know the `window' notion at all.

I don't see how that would even be possible.

> Changing the `window' term to `pane' or something else seems like a low-hanging fruit for people who would like to try using Emacs; I’m interested/curious on other people’s opinions about this.

This could be helpful, but there are a *lot* of function names using
'window'. That means adding a lot of aliases for backwards
compatibility.

Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Stefan Monnier
>> IMO in my ideal world, there should be no division between `window' and
>> `buffer', the difference should be abstracted away so that users don’t
>> have to know the `window' notion at all.
> I don't see how that would even be possible.

Indeed.  A given window can show display different buffers at different
times, and a buffer can be displayed in any number of buffers at any one
time, so the two are really quite different.

>> Changing the `window' term to `pane' or something else seems like
>> a low-hanging fruit for people who would like to try using Emacs; I’m
>> interested/curious on other people’s opinions about this.
> This could be helpful, but there are a *lot* of function names using
> 'window'. That means adding a lot of aliases for backwards
> compatibility.

Yes, we discussed doing such a change a few years back (renaming window
to pane, and then renaming frame to window), but since those names
appear as part of functions's and variables's names, it implies
a massive renaming.  In order not to break external packages and users's
configs, the old names would still have to be preserved as aliases for
many years (meaning that there would need to be many years between the
renaming of windows to panes and the subsequent renaming of frames to
windows).

I think "many years" above can be estimated at about of 10 years (there
are still several important packages which consider it important to
be compatible with Emacs<23 and Emacs-23 was released 10 years ago).

So the way I see it, we're talking about 20 years of transition.
That makes "pane" rhyme with "pain".


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

MBR-2
I see this as the Emacs equivalent to the efforts to get the U.S. to
switch from the English system of measurement to the Metric system.  And
we all know how well that has gone.

Once a community has been using core terminology for an extended period
of time, the only way to change it is to completely replace the members
of the community.  And doing that would kill Emacs itself, which would
make the notion of changing the terminology irrelevant.

    Mark Rosenthal

On 7/23/19 9:00 AM, Stefan Monnier wrote:

>>> IMO in my ideal world, there should be no division between `window' and
>>> `buffer', the difference should be abstracted away so that users don’t
>>> have to know the `window' notion at all.
>> I don't see how that would even be possible.
> Indeed.  A given window can show display different buffers at different
> times, and a buffer can be displayed in any number of buffers at any one
> time, so the two are really quite different.
>
>>> Changing the `window' term to `pane' or something else seems like
>>> a low-hanging fruit for people who would like to try using Emacs; I’m
>>> interested/curious on other people’s opinions about this.
>> This could be helpful, but there are a *lot* of function names using
>> 'window'. That means adding a lot of aliases for backwards
>> compatibility.
> Yes, we discussed doing such a change a few years back (renaming window
> to pane, and then renaming frame to window), but since those names
> appear as part of functions's and variables's names, it implies
> a massive renaming.  In order not to break external packages and users's
> configs, the old names would still have to be preserved as aliases for
> many years (meaning that there would need to be many years between the
> renaming of windows to panes and the subsequent renaming of frames to
> windows).
>
> I think "many years" above can be estimated at about of 10 years (there
> are still several important packages which consider it important to
> be compatible with Emacs<23 and Emacs-23 was released 10 years ago).
>
> So the way I see it, we're talking about 20 years of transition.
> That makes "pane" rhyme with "pain".
>
>
>          Stefan
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Tomas Zerolo
In reply to this post by Stefan Monnier
On Tue, Jul 23, 2019 at 09:00:03AM -0400, Stefan Monnier wrote:

[...]

> Yes, we discussed doing such a change a few years back (renaming window
> to pane [...]

> I think "many years" above can be estimated at about of 10 years [...]

And who knows what the "terminology du jour" will be in 10 years. This
industry is currently very much fad-driven.

So imagine Emacs (painfully) changes window -> pane and frame -> window,
and the dominant technology talks about "trays" and "vanes". Or something.

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Noam Postavsky
On Tue, 23 Jul 2019 at 09:40, <[hidden email]> wrote:

> And who knows what the "terminology du jour" will be in 10 years. This
> industry is currently very much fad-driven.

The term "window" has been pretty long-lived.

> So imagine Emacs (painfully) changes window -> pane and frame -> window,
> and the dominant technology talks about "trays" and "vanes". Or something.

That would still be better, because we wouldn't have the Emacs-window
vs Other-Gui-window meaning conflict.

Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Tomas Zerolo
On Tue, Jul 23, 2019 at 09:46:39AM -0400, Noam Postavsky wrote:
> On Tue, 23 Jul 2019 at 09:40, <[hidden email]> wrote:
>
> > And who knows what the "terminology du jour" will be in 10 years. This
> > industry is currently very much fad-driven.
>
> The term "window" has been pretty long-lived.

That's true. Perhaps (?) it was in use already with PARC's Alto, so around
1973.

But I think at that time terminology wasn't so clear. "Windows" were
also of the non-overlapping kind (think tiling window manager these
days), i.e. exactly what Emacs is doing :-)

> > So imagine Emacs (painfully) changes window -> pane and frame -> window,
> > and the dominant technology talks about "trays" and "vanes". Or something.
>
> That would still be better, because we wouldn't have the Emacs-window
> vs Other-Gui-window meaning conflict.

:-)

Cheers
-- t

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Stefan Monnier
In reply to this post by Tomas Zerolo
>> I think "many years" above can be estimated at about of 10 years [...]
> And who knows what the "terminology du jour" will be in 10 years.

OTOH Emacs-24 was released in 2012, so by 2022 the vast majority of
packages will depend on this version of Emacs, which came with
package.el, so we can expect that by then all those packages will be
distributed via ELPA.

That means packages could start using the "pane" terminology with
Emacs-24 already, assuming we provide a forward-compatibility package
(like I did for cl-lib) adding the "pane" aliases.

That might help speed up the transition a bit.


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Eli Zaretskii
In reply to this post by Tomas Zerolo
> Date: Tue, 23 Jul 2019 12:44:48 +0200
> From: <[hidden email]>
>
> So a good strategy, if you're really hot & willing to change
> things would be to grab the documentation, and perhaps write
> a companion to the documentation "Glossary" (let's call it
> "Anti-Glossary" which translates "current" terms into the
> Emacs terminology. So someone searching for "window", "pane",
> "cursor", etc. has a chance to hit on the relevant documentation.

There's no need for "Anti-Glossary".  Our Glossary already includes
some terminology from "other applications", such as "cut", "paste",
and "syntax highlighting".  It could easily accommodate a few more.

> A next step might be to cross-index those "current" terms
> with the "traditional" ones.

These are already in the Glossary.

Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Tomas Zerolo
On Tue, Jul 23, 2019 at 05:43:28PM +0300, Eli Zaretskii wrote:

[...]

> There's no need for "Anti-Glossary" [...]

> > A next step might be to cross-index those "current" terms
> > with the "traditional" ones.
>
> These are already in the Glossary.

Thanks for the clarifications, Eli. Still, I feel that someone
"entering" this world might be a bit... lost. Obviously some
phantasy is needed to come up with a helpful scheme which doesn't
bring about too much collateral damage?

Cheers
-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Eli Zaretskii
> Date: Tue, 23 Jul 2019 18:15:56 +0200
> From: <[hidden email]>
>
> > There's no need for "Anti-Glossary" [...]
>
> > > A next step might be to cross-index those "current" terms
> > > with the "traditional" ones.
> >
> > These are already in the Glossary.
>
> Thanks for the clarifications, Eli. Still, I feel that someone
> "entering" this world might be a bit... lost. Obviously some
> phantasy is needed to come up with a helpful scheme which doesn't
> bring about too much collateral damage?

Sure.  I just wanted to point out that if we want to add to the
Glossary a few more of the widespread terms for which Emacs has its
own names, we could.

Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Gerhard Wolfstieg
In reply to this post by Jean Louis
     Hallo all together!

Before exchanging the words, could you please reconsider, why the
people behind emacs called the visible work area „window“ – and not the
whole thing? For me it is stupendous logic.

Please don’t give up the best while the modern one isn’t it. (What is
modern?)

     Grüße, Gerhard



Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Tomas Zerolo
On Tue, Jul 23, 2019 at 07:03:55PM +0200, Gerhard Wolfstieg wrote:
>      Hallo all together!
>
> Before exchanging the words, could you please reconsider, why the
> people behind emacs called the visible work area „window“ – and not the
> whole thing? For me it is stupendous logic.
>
> Please don’t give up the best while the modern one isn’t it. (What is
> modern?)

Still there is merit in easing access to newcomers. So the idea is
good and shouldn't be dismissed off-hand.

Cheers
-- tomás

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Stefan Monnier
In reply to this post by Gerhard Wolfstieg
> Before exchanging the words, could you please reconsider, why the
> people behind emacs called the visible work area „window“ – and not the
> whole thing? For me it is stupendous logic.

Not sure what was the "logic" or even if any particular terminology here
is more "logical", but FWIW, Emacs's notion of "window" was inherited
from earlier Emacsen (ITS Emacs and Multics Emacs at least had these
kinds of "panes" and called them "windows": these were before the days
of GUIs).

GNU Emacs and the X Window System were started at around the same time,
so Emacs could have used the "new" terminology I guess, but it would
have had to be "forward looking", whereas it took it another 10 years
(i.e. until Emacs-19) before it started to break out of the "text
terminal" mold.


        Stefan


Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Emanuel Berg-5
In reply to this post by Tomas Zerolo
tomas wrote:

> Emacs has a working and dedicated community.
> If you just enter through the door and say
> "Hello, everybody: how about we change all
> names of things, like, now?"... how do you
> think people will react?

Wait, I think I know the answer to this
question! It is "exactly in the way they
reacted", yes?

> Emacs jargon, evolved over a long time (few
> software packages in productive usage can
> look back on thirty years of history)
> definitely poses a barrier to entry
> for newcomers.

We have heard many versions of this tale,
namely that Emacs is difficult to learn, and
difficult to use, and this scares new users
away; and if those were only more easy to do,
more people would!

I don't know how much truth there is to any of
that, to be honest.

And, unless I'm brained damaged by too much
Emacs, there isn't that much "Emacs jargon",
is it?

> So a good strategy, if you're really hot &
> willing to change things would be to grab the
> documentation, and perhaps write a companion
> to the documentation "Glossary" (let's call
> it "Anti-Glossary" which translates "current"
> terms into the Emacs terminology. So someone
> searching for "window", "pane", "cursor",
> etc. has a chance to hit on the
> relevant documentation.

Well, one can do that for sure, but it comes
down to a policy decision. I can't say I care
if there is a terminology mismatch from the
GUI world to the Emacs ditto, but in general,
obviously it is good to strive at a unified
terminology, while it can be done practically
(perhaps some workaround must be put in place,
so not to break code already written but not
maintained, code which is outside of the core
Emacs binary).

> P.S: Sorry if this mail comes across as
> somewhat... condescending. This is not my
> intention at all! If that's the case, it is
> more due to my inability to put things
> shortly and clearly.

Nah, stop it.

> Sorry for that.

It's OK.

--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal


Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Emanuel Berg-5
In reply to this post by Noam Postavsky
Noam Postavsky wrote:

> This could be helpful, but there are a *lot*
> of function names using 'window'. That means
> adding a lot of aliases for
> backwards compatibility.

Well, if one can add one alias, one can almost
just as easily add two, etc etc.

--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal


Reply | Threaded
Open this post in threaded view
|

Re: Change terminology to better align users’ experience with modern GUIs

Emanuel Berg-5
In reply to this post by Tomas Zerolo
tomas wrote:

> And who knows what the "terminology du jour"
> will be in 10 years. This industry is
> currently very much fad-driven.
>
> So imagine Emacs (painfully) changes window
> -> pane and frame -> window, and the dominant
> technology talks about "trays" and "vanes".
> Or something.

Another scenario that the EFI (The Emacs Future
Institue) has considered is that an asteroid
with an estimated diameter of fourteen
kilometers will smash into the Far East, along
with multiple fragments dislodged by the
atmosphere on entry. The impact will shake the
planet, blow away the ozone layer, and even
tilt the earth's axis. The vast meteorite will
carve out a giant crater, 230 kilometers in
diameter, and kick massive amounts of dust into
the stratosphere. Thick clouds will encompass
the entire planet, and soon the earth will
freeze over. Winter will come... the long, cold
Impact Winter!

--
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal


12